Re: Poll: Limiting KeyValue to a single Instance?

Carl: I'm not sure if you argument is for multiple elements in general 
(which is already permitted), or the possibility of multiple KeyValues 
(which we are discussing, and I thought you previously opposed)?

I think I personally agree with Kent's point that given our semantics, you 
would only have one KeyValue: you only have on KeyInfo. Brian mentioned a 
change might damage dependent specs (XKMS) so I went to look at it [1] again 
wondering when this is the case. However, I don't see any of the examples 
using more than one KeyValue within a KeyInfo. I'm presuming the scenario is 
where one does a query and gets a couple keys back, but I presume you'd get 
more than one KeyInfo back. You don't have more than one KeyInfo in a 
Signature because the structure was designed to exchange key information 
necessary to validate, not generic key exchange. This can be easily remedied 
in XKMS or other applications as Kent suggests.
<foo:Keys>
   <ds:KeyInfo>
     <ds:KeyValue>...</ds:KeyValue>
   </ds:KeyInfo>
   <ds:KeyInfo>
     <ds:KeyValue>...</ds:KeyValue>
   </ds:KeyInfo>
</foo:Keys>

Brian: could you give us a specific scenario?

Kent: do you have a schema/dtd in mind that would express this constraint?


[1] http://www.verisign.com/rsc/wp/xml/xkms_spec/xkms_spec_wp.pdf

At 03:39 2/21/2001 -0800, Carl Ellison wrote:
> >4.4 The KeyInfo Element, 2nd paragraph:
> >>> Multiple declarations within KeyInfo refer to the same key.
> >
> >Multiple KeyValue elements in a KeyInfo element make no sense
> >according to this sentence.  If one wants to transfer multiple
> >keys at once, one should define container element, that includes
> >multiple KeyInfo elements.
>
>I can imagine the key info to back up use of a single key, not just the raw
>key.  We already provide for a variety of certificate forms in KeyInfo.  If
>you have certificates, you usually need one or more chains of them for the
>end certificate to be useful.  You might even need multiple end certificates
>on the same key.  For example, you might have my Intel key, with an X.509
>certificate issued by Intel IT department and binding my World-Wide ID Number
>to that key (WWID being Intel's only unique name for us) -- but in order to
>make a security decision on the signed message in question, the DSig might
>also need to contain an SPKI certificate (or certificate chain) whose (final)
>subject is that key, empowering it in some way.
>
>To me, that calls for multiple elements.


__
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 Wednesday, 21 February 2001 18:51:38 UTC