Re: Decryption Transform processing question

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 UTC