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

Re: Decryption Transform processing question

From: Joseph Reagle <reagle@w3.org>
Date: Mon, 17 Jun 2002 12:51:25 -0400
To: merlin <merlin@baltimore.ie>
Cc: "Takeshi Imamura" <IMAMU@jp.ibm.com>, xml-encryption@w3.org
Message-Id: <20020617165126.718DE187@policy.w3.org>

On Friday 14 June 2002 08:59 pm, merlin wrote:
> >Step 7 reparses this and provides it as a node-set.
> >Then according to xmldsig, if the last transform provides a node-set,
> > then c14n. The Signature should work, right?
> With c14n, when I first start out the node set will be:
>   [Document xml:foo="bar"]
>     <SignedInfo Id="signed-info" ... />
>     [Signature .../]
>   [/Document]
> Here, [] means parts out of the node set. When c14n hits
> the SignedInfo, it will result in:
>   <SignedInfo xml:foo="bar" Id="signed-info" ... />


> At verification time, we'll find this situation:
>   [Document xml:foo="bar"]
>     <EncryptedData Id="signed-info" ... />
>     [Signature .../]
>   [/Document]


> The EncryptedData has a replacement, which is the following
> node set:
>   [dummy]
>     <SignedInfo Id="signed-info" ... />
>   [/dummy]

Yes. Step 3 of section 1.4.2 [1] calls on [2] to decrypted the element, and 
will return a SignedInfo node without the wrapping.

Step 6 (the decryptions are done) of [1] then says c14n the document, and 
when I get to where the EncryptedData used to be, the SignedInfo node, I 
c14n that. Now, remember (to myself), N in [1] is not the whole of the 
document, but the input, so when I c14n it there's *only* the Encrypted 
Data to process. (I confused myself on this point.)
     <SignedInfo Id="signed-info" ... />

Step 7 says parse this to create a node. (Your limitation that the result 
of this needs to be well-formed XML is clear to me now, otherwise it won't 

The last step in xmldsig is then to c14n this yielding (again)

     <SignedInfo Id="signed-info" ... />

and you're right, this doesn't have the c14n'ized context.


> As a result, if we are to use c14n as the canonicalization
> algorithm at the end of this transform, we need to inherit
> those xml attributes as specified in my text.


> My clarification that my solution is broken is itself
> broken. The solution works fine because we specify that
> regular c14n is done by this transform at the end,
> prior to reparsing.

I'm a little lost here. So you are saying the treatment of xml:foo 
attributes as you did in [1] *is* necessary. And its presense as part of 
the decrypt-transform will behave regardless of whether the signature used 
exc-c14n or c14n?
Received on Monday, 17 June 2002 12:51:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:09 UTC