Re: C14N Argument

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