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: <>
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

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 

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 UTC

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