Re: Misleading sentence in 3.2.1 Reference Validation

Well, you only process a Manifest if it is pointed at by a Reference
in a SignedInfo or in a Manifest you are already processing (and if
your application provides for Manifest processing).

In fact, the Manifest you process should, it seems to me, be precisely
what results from the URI dereference and possible Transform
processing in the Reference that refers to this Manifest. There could
even be cases where the data pointed at by the URI is just some
control information which an XSLT transform uses to construct a
Manifest. So you don't need a CanonnicalizationMethod. You have a
whole Transforms element in the Reference to the Manifest which can
provide canonicalization and more. The only reason SignedInfo needs a
CanonicalizationMethod is that there isn't a higher level super
Reference to point to it and provide Transforms.

Donald

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

>Hi,
>
>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,
>Christian
>
>
>--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 Wednesday, 17 October 2001 12:23:02 UTC