Re: Comments on XML-Signature S&P draft

At 17:28 10/6/2000 +0900, TAMURA Kent wrote:
>In message "Re: Comments on XML-Signature S&P draft"
>     on 00/10/05, "Joseph M. Reagle Jr." <reagle@w3.org> writes:
> > Forget about KeyInfo for the time being.
> >
> > In order for applications to do signature validation (3.2.2) it must use 
> the
> > specified SignatureMethod algorithm identifier. Since that is part of
> > SignedInfo, and SignedInfo is potentially altered by CanonicalizeMethod
> > before it is signed, signature validation should see the canonicalized 
> form
> > of the SignatureMethod algorithm identifier.
>
>Yes, that's right.
>
>But my question was that the order of canonicalizing SignedInfo
>(3.2.2 1) and obtaining the key (3.2.2 2) was really REQUIRED?

Hrmm... I think I understand now, and I suppose not. With respect to 
KeyInfo, what I should've (maybe) been arguing for was _not_ the c14n of 
SignedInfo, but the processing of any Reference to the KeyInfo. There's a 
slight disconnect about the "hint" nature of KeyInfo and the (valid) desire 
by some to make it more than a hint by signing it.

I've been assuming the following: if a KeyInfo is provided, that is the Key 
used to sign the Signature. This is based on the text, "KeyInfo is an 
optional element that enables the recipient(s) to obtain the key needed to 
validate the signature... Multiple declarations within KeyInfo refer to the 
same key." [4.4] However, given the processing model and the need to see 
what you sign (and vice versa) I've been concerned that there's ambiguity in 
the core validation...

Consider the following screw scenario (hopefully the last! <smile>).

1. author creates signature with an included KeyInfo and a reference with a 
transform that tweaks the KeyInfo to be the necessary one to validate the 
Signature.
2. verifier starts core validation.
2.1. Reference Validation: verifier checks all digests, including a digest 
resulting from the referencing of the KeyInfo and its transform. Digest 
checks.
2.2. Signature Validation: verifier takes the unaltered KeyInfo and uses 
that to check the Signature and the signature validation fails.

So we had an interop failure. Yes, doing transforms on the KeyInfo is 
probably stupid (and might open up a security hole) but should we say that 
the Signature application takes its validating key directly from KeyInfo 
regardless of what transforms are specified elsewhere? (This is important 
when you start considering our new RetrievalMethod...) If so, the resulting 
Signature Validation would look like:

>3.2.2 Signature Validation (unordered)
>B. Canonicalize the SignedInfo element based on the CanonicalizationMethod 
>in SignedInfo and use the specified SignatureMethod to validate the 
>SignatureValue over the SignedInfo element. Note, the SignatureMethod URI 
>may have been altered by the Canonicalization of SignedInfo (e.g., 
>absolutization of relative URIs) and it is the canonical form that should 
>be used.

However, I'm still unsure what to say about KeyInfo...? Kent (or any other 
implementor), when you process KeyInfo, has it (or its content) been 
canonicalized? Do we leave the text as is:

>A. Obtain the keying information from KeyInfo or from an external source.

Or say something more? Also with respect to the text above, if KeyInfo is 
provided MUST that be the ONLY Key the application should try, or can it try 
others at its discretion?


__
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, 10 October 2000 15:30:02 UTC