W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > October to December 2001

Re: Misleading sentence in 3.2.1 Reference Validation

From: Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de>
Date: Tue, 16 Oct 2001 08:56:51 +0200
To: reagle@w3.org
Cc: w3c-ietf-xmldsig@w3.org
Message-id: <2495231627.1003222611@pinkpanther>

I forgot something that supports this (I love to reply to my own e-mails 

In Section 5.1 The Manifest Element, we son't say how to verify a 
ds:Manifest, but I think it's abvious that the reference validation 
processing has to be applied to ds:Manifest as well. But this is not 
possible cause there's no CanonicalizationMethod inside a Manifest.

One reason more to omit the misleading sentence from 3.2.1.

Best regards,

--On Dienstag, 16. Oktober 2001 08:39 +0200 Christian Geuer-Pollmann 
<geuer-pollmann@nue.et-inf.uni-siegen.de> wrote:

> Hi Joseph,
> hi all,
> I know that we shouldn't apply big changes to the XML Signature spec to
> get it come fast through the standards process. But I think there's a
> sentence in the spec that probably adds confusion. The thread [1] also
> shows this.
> In section 3.2.1 Reference Validation, the first bulleted item says:
>    "Canonicalize the SignedInfo element based on the
>     CanonicalizationMethod in SignedInfo."
> After that, we don't say anything about what appens with these octets.
> Then we process the references. I think that we should delete this
> sentence, because
> 1: we don't give a guideline what to do with the bytes
> 2: AFAIK it does not make sense at this place
> 3: c14n of ds:SignedInfo is done in 3.2.2 Signature Validation, second
> step.
> In my implementation, I tried to interpret the sentence in question the
> following way: When I am asked to verify a ds:Signature, I work on a DOM
> structure. I canonicalize ds:SignedInfo, reparse it into a new document
> and replace the original not-canonicalized ds:SignedInfo by the re-parsed
> canonicalized one.
> From implementations point of view, this is complicated and error-prone
> and did not word very safe _AND_ I didn't heard that any of the other
> implementations makes something like this.
> So why do we have such a sentence of canonicalizing prior ro reference
> validation? The only reason that would make sense would be a security
> problem that would arise if I process an not-c14nized SignedInfo, e.g. if
> an attacker can modify the AlgorithmURI of a Signature method or other
> things that would semantically change the SignedInfo. But I don't see
> changes would make sense and would not break the reference processing.
> So my vote is: could we please delete this sentence and change the
> section to:
> --------------------
> 3.2.1 Reference Validation
> 1: For each Reference in SignedInfo:
> 2. Obtain the data object to be digested.
>    (For example, the signature application
>    may dereference the URI and execute Transforms
>    provided .......
> --------------------
> Christian
> [1]
> http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001OctDec/0026.html
> http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001OctDec/0030.html
Received on Tuesday, 16 October 2001 02:54:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:36 UTC