RE: Poll: Limiting KeyValue to a single Instance?

At 17:10 2/21/2001 -0800, Brian LaMacchia wrote:
>I definitely disagree with the second clause of the AND, "applying to the
>validation key", because the common interpretation of that suggestion
>appears to be, "any key that appears in KeyValue MUST be the validation key
>for the signature."

Looking at the spec, I agree with Kent that it is hard to escape that that 
the intent of KeyInfo was to convery information about *a* key -- and this 
spec uses this key for signature validation. The native XML structures 
(KeyName and KeyValue) speak to this directly, and the translated structures 
(as an opaque blob) serve this purpose as well..

>http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/
>4.4 The KeyInfo Element
>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.1 The KeyName Element
>The KeyName element contains a string value which may be used by the signer 
>to communicate a key identifier to the recipient. Typically, KeyName 
>contains an identifier related to the key pair used to sign the message, 
>but it may contain other protocol-related information that indirectly 
>identifies a key pair.
>4.4.2 The KeyValue Element
>The KeyValue element contains a single public key that may be useful in 
>validating the signature.


>Assuming that's the intent of the second clause then I
>think it's broken because it assumes KeyValue (and thus KeyInfo) only
>appears within a Signature element and that's not true in something like
>XKMS.

There's sort of two issues here too. If you think of the data model (don't 
worry about syntax but draw classes) is KeyInfo a resource/key with a bunch 
of properties (KeyName, KeyValue, X509Data) that describes that resource? Or 
is it merely a bag of unrelated keys/resources. I think the present text 
speaks to the first meaning. The second issue is what is the intent of how 
that resource be used, in the Signature context its for signature 
validation. My concern for signature (and other applications) is that we get 
the meaning of the structures within ds:KeyInfo straight and its intent is 
application dependent (given by the parent element it is found within.)

So Kent's point was that while KeyInfo can include multiple structures they 
ultimately provide you a resource, that is useful for validating and 
trusting a signature. (I don't know if Kent is actually advocating this, but 
he's arguing that's what the spec says and I agree.) I think this semantic 
is useful, and could server other applications even, but that also means 
that if they just want a bag of key stuff, they'd need another container.

>Hmm, maybe the real problem here is the "Multiple declarations within
>KeyInfo refer to the same key" part, because that *does* seem to imply only
>a single KeyValue could occur.

Right.

>But I can't reconcile that with out X509Data
>position.  We've justified having multiple X509 certs within a single
>X509Data by saying that multiple certs "refer" to the same key if they're
>part of a chain that includes that key, but it seems weird that only
>X509Data would get this special dispensation.

I don't understand the disconnect.

Particularly when you look at the text in the editors' copy that Don wrote 
on X509Data when he closed [1] the issue on the ambiguity of IS, SKI and SN.

[1] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001JanMar/0088.html

http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001JanMar/0094.html
>     Any X509IssuerSerial, X509SKI, and X509SubjectName elements that
>     appear MUST refer to the certficiate or certificates containing
>     the validation key.  All such elements that refer to a
>     particular individual certificate MUST be grouped inside a
>     single X509Data element and if the certificate to which they
>     refer appears, it MUST also be in that X509Data element.
>
>     Any X509IssuerSerial, X509SKI, and X509SubjectName elements that
>     relate to the same key but different certificates MUST be
>     grouped within a single KeyInfo but MAY occur in multiple
>     X509Data elements.
>
>     All certificates appearing in an X509Data element MUST relate to
>     the validation key by either containing it or being part of a
>     certification chain that termiantes in a certificate containing
>     the validation key.


>I guess the bottom line problem is that KeyInfo has "grown up" and is/will
>be used in multiple specs, so perhaps what we really need is a general
>statement about the structure of KeyInfo/KeyValue and then a profile of that
>for use of KeyInfo/KeyValue in XMLDSIG.

We don't necessarily have to change our spec and step outside of scope 
because other young specs are going to use KeyInfo. If we are clear about 
what we mean it serves them as well. If other specifications want to send 
bags of keys they can trivially do either of the following:

<enc:KeyPackage>
   <ds:KeyInfo>...</ds:KeyInfo>
   <ds:KeyInfo>...</ds:KeyInfo>
</enc:KeyPackage>
(if they want to take advantage of the semantic that KeyInfo data pertains 
to a key)

or if they don't want to use that semantic:

<enc:Keys>
   <ds:KeyName/>
   <ds:PGPData/>
    etc...
</enc:Keys>


__
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 Thursday, 22 February 2001 11:59:50 UTC