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

Re: Decryption Transform processing question

From: Joseph Reagle <reagle@w3.org>
Date: Wed, 29 May 2002 15:27:34 -0400
To: merlin <merlin@baltimore.ie>
Cc: "Takeshi Imamura" <IMAMU@jp.ibm.com>, xml-encryption@w3.org
Message-Id: <20020529192735.CB7E985A94@aeon.w3.org>

On Wednesday 29 May 2002 02:59 pm, merlin wrote:
> >1. If more than one "layer" of decryption is required (to peel back
> >super-encrypted elements) then multiple decryption transforms should be
> >used, with the input of a later transform being the output of the
> > preceding decryption transform.
> This is what I advocate. That is, a single decryption transform
> operates on all the unexceptional EncryptedData elements in
> its input node set in a single phase, without iteration.

Ok, perhaps we all agree on this then? This is what I believe the spec 
currently specifies: decryptIncludedNodes() selects the e's it operates on 
at the start, so it wouldn't find new e that were super-encrypted and 
decryptXML doesn't recurse.

> If super-encryption has occurred then multiple decryption
> transforms are required. The second decryption transform
> will explicitly and clearly be operating in the context of
> a dummy-rooted document and so can be correctly constructed
> in this accord.

I fear this is one of the parts I don't understand yet. Isn't that dummy 
root removed? "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. Return Y."

> document. Subsequent decryption transforms will be operating
> on a dummy-rooted document and so their exception URIs can
> be easily constructed with this in mind.

I don't grok this yet.

> The current specification states that we shall iteratively
> and stochastically decrypt, wrap and parse elements until
> there are no more unexceptional EncryptedData.

Which part of [z] says this?

[z] http://www.w3.org/Encryption/2001/Drafts/xmlenc-decrypt.html
$Revision: 1.44 $

> The first
> element that is decrypted will have references and
> exceptions resolved with respect to the initial document.
> All subsequent will have then be processed within a dummy
> document. The random nature of this gives rise to the
> non-determinism for a single decryption transform.
> <Document>
>   <SignedPart>
>     <EncryptedData CipherReference=#data />
>     <EncryptedData <Data Id='data' /> />
>   </SignedPart>
>   <Data Id='data' />
> </Document>

Ah, this has the potential to be a useful example. So I understand well, 
"<Data Id='data' />" was the clear text encrypted? I'd also ask in what 
order were they encrypted? It should be peeled back in the order in which 
it was wrapped. If you're saying they were both available in the clear text 
form then this was an invalid document.

> If I decrypt EncryptedData #1 first, then it will get its
> data from the outer Data element. If I decrypt EncryptedData
> #2 first, then EncryptedData #1 will be processed in a document
> where only the new Data exists, so it will get its data from
> there. This is contrived but stochastic. The rules I suggest
> are deterministic: Both will be encrypted within the context
> of this document during a single phase.

achh, I'm loosing it again, but I'm getting a sense of where I'm loosing 
it. I'm saying there should be as many decryption transform "unwrappings" 
as there were encryption "wrappings." You seem to agree, but you're also 
arguing that more than one element can be encrypted in a layer/wrapping? I 
think I need your example played out over the steps to understand.
Received on Wednesday, 29 May 2002 15:28:49 UTC

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