W3C home > Mailing lists > Public > xml-encryption@w3.org > June 2002

Re: XML decryption transform number 13

From: Takeshi Imamura <IMAMU@jp.ibm.com>
Date: Mon, 3 Jun 2002 01:34:07 +0900
To: merlin <merlin@baltimore.ie>
Cc: xml-encryption@w3.org
Message-ID: <OF293E4D83.0B3A2B12-ON49256BCC.0059AF75@LocalDomain>



>. The &decrypt;Binary transform operates so:
>
>  o Decrypt each unexceptional EncryptedData in document
>    order and process it in accordance with the specification
>    of the Type attribute, or fail if that is unknown.
>
>  o Return the concatenation of the plaintexts.

I feel that concatenating the plaintexts is weird.  What kind of scenario
are you supposing?

>. The &decrypt;XML transform operates so:
>
>  o Decrypt every unexceptional EncryptedData in the node set
>    and process it in accordance with the specification of the
>    Type attribute, or fail if that is unknown. For example,
>    Type &gzip-xml; will be gunzipped; type &python-xml-pickle;
>    will be executed in python; type &xenc;(Content|Element);
>    will be untouched. Wrap the resulting octet stream in
>    a parsing context of the EncryptedData element (i.e.,
>    ...<dummy...), parse this, trim it and save the result.
>    These will be the node sets that should replace the
>    EncryptedData elements; they may be element or element
>    content.
>
>  o Canonicalize the input node set but, in place of every
>    unexceptional EncryptedData, canonicalize the replacement
>    node set. Note that the result may not be in canonical
>    form.
>
>  o Parse the resulting octet stream.

This looks good, but I think that it is a little redundant.  The
wrapping/parsing/trimming is required only for the plaintext resulting from
an EncryptedData element node which is the first node in the node-set, and
hence that for the other plaintexts could be omitted.

Thanks,
Takeshi IMAMURA
Tokyo Research Laboratory
IBM Research
imamu@jp.ibm.com
Received on Sunday, 2 June 2002 12:44:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:03 UTC