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

Re: Comments on XML-Signature S&P draft

From: Joseph M. Reagle Jr. <reagle@w3.org>
Date: Tue, 03 Oct 2000 14:36:13 -0400
Message-Id: <4.3.2.7.2.20001003142602.034dd0f0@rpcp.mit.edu>
To: TAMURA Kent <kent@trl.ibm.co.jp>
Cc: w3c-ietf-xmldsig@w3.org
At 14:37 10/3/2000 +0900, TAMURA Kent wrote:
> > Both of these are the same issue. As we recommend you see what you sign, 
> and
> > the CanonicalizationMethod might tweak the content of SignedInfo, it 
> should
> > be processed and then processed. For instance, say at some point the 
> issue
> > of releative URIs results in a CanonicalizationMethod that rewrites URIs 
> in
> > a novel way, you should apply CanonicalizationMethod first before 
> processing
> > them. This text is there to ensure security, though I expect if 
> understood
> > by implementors it won't result in a big deal. If they know they only
> > support one CanonicalizationMethod, and that Method is safe then they 
> might
> > choose not to do this so as to optimize, but that's their choice and the
> > spec needs to be clear. There's a parenthetical comment in the latest 
> draft,
> > do we need more motivating text?
>
>Ok, I have understood the order of c14n and Reference
>processing.  But how about the order of c14n and obtaning a key
>(1 and 2 in 3.2.2)?  The SignedInfo has no reference to the
>KeyInfo.

Consider the following scenario:

Author creates signature that includes a reference to KeyInfo element (and 
consequently it is signed). This KeyInfo contains a RetrievalMethod with a 
relative URL; KeyInfo is canonicalized using an algorithm that resolved URLs 
(since the Signature Reference is an XPointer barename to it).

Consequently, shouldn't the SignatureValidation see the same thing as the 
ReferenceValidation?

__
Joseph Reagle Jr.
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/
Received on Tuesday, 3 October 2000 14:36:17 GMT

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