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

Re: Decryption Transform processing question

From: Ari Kermaier <arik@phaos.com>
Date: Thu, 02 May 2002 12:16:13 -0400
Message-Id: <5.1.0.14.2.20020502120601.02b0c170@verio.phaos.com>
To: merlin <merlin@baltimore.ie>, "Takeshi Imamura" <IMAMU@jp.ibm.com>
Cc: "Hiroshi Maruyama" <MARUYAMA@jp.ibm.com>, reagle@w3.org, xml-encryption@w3.org
I strongly prefer number 2. I don't see the problem, though, with 
processing multiple levels of encryption. The outer iteration, as defined 
in the processing rules for decryptIncludedNodes(X, R), just has us select 
an EncryptedData element e in X. Since the result of decryptXML(X, e, C) 
replaces X, the next loop of the outer iteration begins with a new X and is 
free to select an EncryptedData element e that was not in X at the start of 
the previous iteration. If decryptIncludedNodes(X, R) continues until no e 
can be selected, then multiple levels of encryption can be successfully 
handled.

Ari

>Regardless, I think the current model requires at minimum one of
>the following changes:
>
>1. Stay with the current processing model; that is, for each
>EncryptedData we serialize, wrap, decrypt, insert, parse.
>In this case, we need to respecify Except. The URIs "#foo" and
>"#xpointer(/path/to/enc:EncryptedData)" are same-document references;
>they will never identify nodes in these new documents. Except would need
>to be changed to have an ID reference attribute (although not of type
>IDREF) and we should state that this ID will be used to identify an
>element of type enc:EncryptedData with matching Id attribute in the
>node set being processed.
>
>2. Change to a model where we decrypt all non-excepted EncryptedData in
>the input node set; then serialize, wrap, insert and parse the entire
>node set in one go. In this case, Except URIs will work because the
>references will identify EncryptedData elements in the original document.
>However, multiple levels of encryption will not be decrypted and it
>should be noted that the output node set will be of a different document
>than the input node set.
>
>Merlin
Received on Thursday, 2 May 2002 12:13:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:21 GMT