- From: Ari Kermaier <arik@phaos.com>
- Date: Tue, 23 Apr 2002 15:34:42 -0400
- To: xml-encryption@w3.org
Dear All, I'm trying to implement the processing rules as defined in the current editor's copy [1], and I don't understand the processing rules for the decryptXML(X,e,C) function, when considered with the examples in Section 4 and Appendix A: 2.1.1 Functions [ ... ] Y = decryptXML(X, e, C) where X is a node-set, e is an element node with the type xenc:EncryptedData in X, and C is a parsing context of X. Y is a node-set obtained by the following steps: <AK> For the example in [1] Section 4: Let X be the node-set representation of the sub-tree rooted in the 'order' element. Let e be the EncryptedData element with Id="enc2". Let C contain the namespace in scope for the 'order' element, xmlns="http://www.w3.org/2000/09/xmldsig#". </AK> 1. 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]. <AK> Apply XML-C14N to node-set X defined above. </AK> 2. Decrypt the element corresponding to e (which may require parsing) and replace it with the resulting octet stream according to the XML Encryption specification [XML-Encryption]. <AK> Parse the canonicalized node-set into a new document, locate e (EncryptedData with Id="enc2") and perform a decrypt-and-replace procedure as defined in [2] Section 4.2 Decryption step 5. But do we really want to replace the EncryptedData element with the decrypted data before we've done the wrapping/parsing/unwrapping operation? </AK> 3. Wrap the decrypted octet stream in the context of C as specified in Text Wrapping (Appendix A). <AK> From the example in [1] Appendix A, it's clear that it is only the decrypted octets being wrapped, not the octets of the document obtained at the end of step 2 above. For the [1] Section 4 example, this is just the octets of the 'cardinfo' element. </AK> 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. <AK> Plain old well-formed XML parsing. </AK> 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. <AK> Unwrapping obtains a node-set containing the parsed, decrypted contents of the EncryptedData element e, but *not* containing the rest of node-set X (unless e was the first element in X). For the [1] Section 4 example, this just the node-set representation of the sub-tree rooted in the 'cardinfo' element, not the 'order' element. </AK> 6. Return Y. <AK> This result replaces the original input node-set in the decryptIncludedNodes(X,R) function with the 'cardinfo' element and it's children. Unfortunately, the signature references the whole 'order' element.</AK> So what's a poor implementer to do? [1] http://www.w3.org/Encryption/2001/Drafts/xmlenc-decrypt.html [2] http://www.w3.org/TR/2002/CR-xmlenc-core-20020304/ Ari Kermaier arik@phaos.com Senior Software Engineer Phaos Technology Corp. http://www.phaos.com/
Received on Tuesday, 23 April 2002 15:32:28 UTC