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

Re: Misleading sentence in 3.2.1 Reference Validation

From: Joseph Reagle <reagle@w3.org>
Date: Wed, 17 Oct 2001 13:11:33 -0400
To: Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de>
Cc: w3c-ietf-xmldsig@w3.org
Message-Id: <20011017171134.4A1AB8737E@policy.w3.org>
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-CanonicalizationMethod-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/
Received on Wednesday, 17 October 2001 13:37:02 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:14 GMT