Re: Misleading sentence in 3.2.1 Reference Validation

Hi Joseph,

OK, this all means that I have to do it "the hard way" ;-)). I understood the points you mentioned and agree. Thanks,

Christian

--On Mittwoch, 17. Oktober 2001 13:11 -0400 Joseph Reagle <reagle@w3.org> wrote:

> On Tuesday 16 October 2001 2:39, Christian Geuer-Pollmann wrote:
>> 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.
>
> That is correct.
>
>> 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.
>
> If you will only support canonicalization methods that are known to be
> safe  in this capacity (of not re-writing the Reference URIs or
> DigestValues) you  can "optimize" by not having to implement. Otherwise
> this is an important  statement for the reasons stated:
>
> http://www.w3.org/Signature/Drafts/xmldsig-core/Overview.html#sec-Canonic
> alizationMethod-NOTE    NOTE: The signature application must exercise
> great care in accepting    and executing an arbitrary
> CanonicalizationMethod. For example, the    canonicalization method could
> rewrite the URIs of the References being    validated. Or, the method
> could massively transform SignedInfo so that    validation would always
> succeed (i.e., converting it to a trivial    signature with a known key
> over trivial data). Since
>    CanonicalizationMethod is inside SignedInfo, in the resulting
>    canonical form it could erase itself from SignedInfo or modify the
>    SignedInfo element so that it appears that a different
>    canonicalization function was used! Thus a Signature which appears to
>    authenticate the desired data with the desired key, DigestMethod, and
>    SignatureMethod, can be meaningless if a capricious
>    CanonicalizationMethod is used.
>
> Canonical XML and Exclusive Canonical XML do not rewrite URIs. In fact, I
> don't think any C14N or transform should be used that isn't standardized
> and reviewed. And any C14N that rewrote these URIs should have a stake
> driven through their hearts. But it's hard for us to specify the
> requirements of externally specified extensible algorithms (e.g., key
> size). So we have to specify our spec as securely as possible, even if it
> is a little akward.
>
>> 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.
>
> 1. Evil Eve creates statement G saying she "will pay Joseph $10" and a
> statement B, "ha-ha".
> 2. She creates a signature with a reference to G, but a digest of B and
> signs it using the Evil-C14N.
> 3. When I go to validate the signature (which appears to point to
> statement  G) Evil-C14N rewrites the URI to B and the digest checks.
>
> --
> 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/
>






Mit freundlichen Grüßen,

Christian Geuer-Pollmann


--------------------------------------------------------------------------
Institute for Data Communications Systems             University of Siegen
Hoelderlinstrasse 3                 D-57068 Siegen                 Germany

mail:  mailto:geuer-pollmann@nue.et-inf.uni-siegen.de
web:  <http://www.nue.et-inf.uni-siegen.de/~geuer-pollmann/>

Received on Wednesday, 17 October 2001 14:23:31 UTC