W3C home > Mailing lists > Public > xml-encryption@w3.org > September 2001

Re: Encryption: Decryption Transform for XML Signature

From: Joseph Reagle <reagle@w3.org>
Date: Mon, 17 Sep 2001 17:59:56 -0400
To: "Takeshi Imamura" <IMAMU@jp.ibm.com>
Cc: "Hiroshi Maruyama" <MARUYAMA@jp.ibm.com>, "Kento Tamura" <TKENT@jp.ibm.com>, xenc <xml-encryption@w3.org>
Message-Id: <20010917215957.33B4387461@policy.w3.org>
On Monday 17 September 2001 06:48, Takeshi Imamura wrote:
> The file attached below contains a revised version of the spec.  We
> revised Section 2 and 3 to clarify the processing done by this transform,
> and such portions are written in red.  Any comments are welcome!

Ok, the spec is now up at (I tweaked the organization slightly):
  $Revision: 1.4 $ on $Date: 2001/09/17 21:28:42 $

> By the way, we have a concern about whether this transform supports
> decryption resulting in not an XML but an octet stream.  Do you have any
> idea?

My two comments are:
1. I know this is counter to an early decision, but in reading this for the 
first time for a while, I wonder if we should use an element name other 
that enc:DataReference. Since this parameter really has its own meaning as 
an excpetion, I'm think perhaps it would be better to call it et:Exception 
2. I think the process is well specified, but one of the things that's 
slightly unclear is the connection between the transform and the functions 
that are defined. If the input to the transform is a node-set, then I 
presume one applies noDecryptNodes(X, R) . Maybe this should be stated more 
explicitly, or could be moved before the decrypt(X, e, C) function? Also, 
is X in either function always the whole document, or can it be some subset?

3. To address your question above. To trace through an instance of an 
element that must be decrypted prior to signature validation using the 
example in section 5:

1. Apply noDecryptNodes(X, R)
1.1 The node e = <EncryptedData Id="enc2" /> is not in R, so we pass.
1.2 The node e = <EncryptedData Id="enc2" />  is in R, so we decrypt(X, e, 
1.2.1 X is canoncalized into octets according to Canonical XML. (Do these 
processing rules permit any other serialization?)
1.2.2 The octets are wrapped in dummy tags (as octets).
1.2.3 "Decrypt the element corresponding to e and replace it with the 
resulting octet stream according to the XML Encryption" So we find the approriate offset into the octets? These octets are 
then decrypted, and the result is interprated as UTF-8 encoded character 
1.2.4. "Parse the decrypted octet stream." Ok, so it's parsed back into 
nodesets again.
1.2.5  "Y is a node-set obtained by removing the root node, the dummy 
element node, and its associated set of attribute and namespace nodes"

So I'm sure there's a reason I'm forgetting, but why is it that the in 
steps 1 and 4 of decrypt() that the document is serialized and parsed? Why 
not just do the wrapping with the dummy nodes at the node-set level? (Which 
I think we would do in any case?)

Now, I'm not sure if I actaully addressed your question though!
Received on Monday, 17 September 2001 18:00:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:02 UTC