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

Re: Decryption Transform processing question

From: merlin <merlin@baltimore.ie>
Date: Thu, 02 May 2002 17:26:16 +0100
To: Ari Kermaier <arik@phaos.com>
Cc: reagle@w3.org, "Takeshi Imamura" <IMAMU@jp.ibm.com>, "Hiroshi Maruyama" <MARUYAMA@jp.ibm.com>, xml-encryption@w3.org
Message-Id: <20020502162616.994B0447DD@yog-sothoth.ie.baltimore.com>

Hi Ari,


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

I like the ambiguity of "which may require serializing X" because it
does open up the possibility of other implementations, however we
need to nail things down exactly. Allowing some implementations to
output a node set from the original document and others to output a
node set from a new document will result in interoperability
problems, and at intermediate stages you run into same-document
reference problems.

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

The serialization is necessary for bizarre node sets that cut out
parts of an EncryptedData, but that just introduces a whole bunch
of problems. It is probably easiest and best for many reasons if
we decrypt the element e, regardless of what children are present
in the node set. So:

   1. Decrypt the element corresponding to e (without regard to
which of its descendants are present in X). The result is an octet
stream corresponding to UTF-8 serialized XML data, as specified
in the XML Encryption specification [XML-Encryption].

>>    2.   Convert X to an octet stream as described in The Reference
>>Processing Model (section 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 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/

The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The 
unauthorised use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from alteration
of the contents of this message by a third party or as a result of any 
virus being passed on.

This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.
Received on Thursday, 2 May 2002 12:26:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:09 UTC