Re: Comments on XML-Signature S&P draft

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 UTC