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

Decryption Transform processing question

From: Ari Kermaier <arik@phaos.com>
Date: Tue, 23 Apr 2002 15:34:42 -0400
Message-Id: <>
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 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 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' 

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

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