- From: merlin <merlin@baltimore.ie>
- Date: Sat, 28 Jul 2001 13:26:34 +0100
- To: "Dournaee, Blake" <bdournaee@rsasecurity.com>
- Cc: w3c-ietf-xmldsig@w3.org
Hi Blake, The spec does not need any clarification or change; the reference processing model is explicit about what is done, and when. C14n will only be done implicitly if *required* (e.g., if we are attempting to digest a node set). The following two are the same in effect and computational cost. <Reference URI="#foo"> ... </Reference> <Reference URI="#foo"> <Transforms><Transform Algorithm="&c14n;" /></Transforms> ... </Reference> The obvious way to force a redundant c14n step to be performed is to have two *explicit* c14n transforms back to back. In terms of your example below, N -> XPATH(B) -> C14N(N) -> Convert(N) -> SHA1(), you are not processing according to the spec. See sections 4.3.3.2 and 4.3.3.5. The output of C14N is an octet stream. No implicit second canonicalization will be performed. Merlin r/bdournaee@rsasecurity.com/2001.07.27/16:21:58 >Joseph, John, All, > >The way I understand the spec is as follows. > >Consider the given <Reference> element: > ><Reference URI="#foo"> > <Transforms> > <Transform Algorithm="&xpath;">some Xpath</Transform> > </Transforms> ></Reference> > >When this is processed, the URI reference produces a node-set (I'll call >this "N"). Further, define two >functions XPATH() and Convert(). XPATH() accepts a node-set and produces a >node-set and Convert() is >the "conversion" from node-set to octet stream, using the "specified >canonicalization algorithm." Convert() is really equivalent to one run of >C14N. > >N -> XPATH(N) -> Convert(N)-> SHA1() > >Now, I would say that Canonicalization happens a single time here. > >Next, let's expand on the above example as follows: > ><Reference URI="#foo"> > <Transforms> > <Transform Algorithm="&xpath;">some Xpath</Transform> > <Transform Algorithm="$c14n;"/> > </Transforms> ></Reference> > >Now the processing looks like this: > >N -> XPATH(B) -> C14N(N) -> Convert(N) -> SHA1() > > >Here, I would say that canonicalization happened *twice*, once explicitly >and once implicitly. > >This is where I think people will get confused, thinking that they must >canonicalize when in reality >they are just wasting processing power. > >Is this clear?, or am I misunderstanding something here? > >The crux of the problem is that it is stated that the "octet stream must be >converted to a node-set", this >means, really, "Canonical XML" because this is the way the algorithm is >defined (to produce a physical representation). > >This is what I mean by implicit canonicalization. When you convert, you >canonicalize. You "convert" any time you >operate on a node-set somewhere in the transformation pipeline, therefore, >if you explicitly use C14N, the possibility >is there for redundant processing. > > > > > > >Blake Dournaee >Toolkit Applications Engineer >RSA Security > >"The only thing I know is that I know nothing" - Socrates > > > > >-----Original Message----- >From: Joseph M. Reagle Jr. [mailto:reagle@w3.org] >Sent: Friday, July 27, 2001 2:29 PM >To: Dournaee, Blake >Cc: 'w3c-ietf-xmldsig@w3.org' >Subject: RE: C14N Argument > > >At 17:24 7/27/2001, Dournaee, Blake wrote: >>"Canonicalization is used implicitly when a node-set is converted to an >>octet stream in the transformation pipeline. Care should be made not to >>include it unnecessarily as an explicit transform. Doing so may affect core >>processing performance." > >Hrmm... I don't want to encourage not using it explicitly. If I have a > > <Transform Algorithm="&xpath;">some Xpath</Transform> > <Transform Algorithm="$c14n;"/> > >Then exactly 1 canonicalization was done, the explicit one. (Could you given > >an example of a mistaken double c14n (implicit/explicit)?) > > >-- >Joseph Reagle Jr. http://www.w3.org/People/Reagle/ >W3C Policy Analyst mailto:reagle@w3.org >IETF/W3C XML-Signature Co-Chair http://www.w3.org/Signature >W3C XML Encryption Chair http://www.w3.org/Encryption/2001/ > ----------------------------------------------------------------------------- Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. http://www.baltimore.com
Received on Saturday, 28 July 2001 08:27:24 UTC