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

Re: Decryption Transform processing question

From: Ari Kermaier <arik@phaos.com>
Date: Wed, 29 May 2002 16:20:53 -0400
Message-Id: <>
To: reagle@w3.org, merlin <merlin@baltimore.ie>
Cc: "Takeshi Imamura" <IMAMU@jp.ibm.com>, xml-encryption@w3.org

Comments are inline below.

Ari Kermaier

At 03:27 PM 5/29/02 -0400, Joseph Reagle wrote:

>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.

Actually, it seems to me that the current spec does *not* select all e's at 
the start from the initial input node-set X. According to the description 
of the decryptIncludedNodes(X, R) function in Section 2.1.1, we:

         1. Within X, select any EncryptedData element e not in Except.
         2. Y = decryptXML(X, e, C); replace X with Y.
         [3. If e's Type attribute indicates octet content, decrypt and end.]
         4. Goto 1.

In Step 4, we return to Step 1 and select e from the *new* node-set X. This 
might include EncryptedData elements that resulted from the decryption in 
Step 2. So, according to my reading, the current spec implies recursive 
decryption of arbitrarily deep super-encrypted layers.

> > 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."

Me either -- I don't really see the problem with the evaluation context in 
the second round.

> > 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 $

Well, that seems to be the result of the decryptIncludedNodes(X, R) 
function, since the stopping condition of the iteration is either an error 
or inability to select e in X and not in Except.

> > 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 16:19:28 UTC

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