- 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
>. 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