- 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
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" ... /> Agreed. > At verification time, we'll find this situation: > [Document xml:foo="bar"] > <EncryptedData Id="signed-info" ... /> > [Signature .../] > [/Document] Yes. > 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 parse.) 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. [1] http://lists.w3.org/Archives/Public/xml-encryption/2002Jun/att-0028/01-xml-decrypt-13.html [2] http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/Overview.html#sec-Decrypt-Imp > 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. Yes. > 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