- 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