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

Re: Decryption Transform processing question

From: Ari Kermaier <arik@phaos.com>
Date: Thu, 02 May 2002 12:02:42 -0400
Message-Id: <5.1.0.14.2.20020502113507.023907b0@verio.phaos.com>
To: merlin <merlin@baltimore.ie>
Cc: reagle@w3.org, "Takeshi Imamura" <IMAMU@jp.ibm.com>, "Hiroshi Maruyama" <MARUYAMA@jp.ibm.com>, xml-encryption@w3.org

>My question would mirror Joseph's: What does it mean to replace
>an element node with an octet stream? It would be necessary to
>state something along the lines of:

That's why I included the phrase "which may require serializing X". In 
practice, my implementation does something similar to what you've described 
below, but I can imagine implementations that parse the decrypted octets 
and do DOM/node-set manipulations to effect the replacement. That's why it 
didn't seem appropriate to define exactly how the decrypt-and-replace is 
accomplished, beyond referring the implementor to the processing rules in 
XML-Encryption. However, that might not be a worthwhile consideration when 
weighed against clarity and explicitness of the processing rules we're 
considering.

>   1. Decrypt the element corresponding to e (which may require
>serializing and reparsing if the node set does not contain the entire
>subtree rooted at e). The result is an octet stream corresponding to
>UTF-8 serialized XML data, as specified in the XML Encryption
>specification [XML-Encryption].

Why would it be necessary to serialize and reparse if e's children were not 
in X? Since X is a set of nodes in a document tree, the normal XML 
decryption processing should be able to locate e's children as needed. In 
fact serializing X would mean that any nodes not originally in X would be 
completely inaccessible from within the document obtained by re-parsing the 
serialization. (Actually, this is another good argument for doing away with 
the current Step 1, which applies C14N to X.)

>    2.   Convert X to an octet stream as described in The Reference
>Processing Model (section 4.3.3.2) of the XML Signature specification
>[XML-Signature], but in place of e and its descendants, insert the
>octet stream obtained in step 1.
>    3. Wrap the resulting octet stream in the context of C as specified
>in Text Wrapping (Appendix A).
>    4. Parse the wrapped octet stream as described in The Reference
>Processing Model (section 4.3.3.2) of the XML Signature specification
>[XML-Signature], resulting in a node-set.
>    5. Y is the node-set obtained by removing the root node, the wrapping
>element node, and its associated set of attribute and namespace nodes
>from the node-set obtained in Step 4.
>    6. Return Y.


Ari Kermaier    arik@phaos.com
Senior Software Engineer
Phaos Technology Corp.    http://www.phaos.com/
Received on Thursday, 2 May 2002 11:59:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:21 GMT