RE: Poll: Limiting KeyValue to a single Instance?

Your read of XKMS is correct.  When it is necessary to pass 
information on multiple keys, XKMS passes an array of 'structures' 
which include a KeyInfo.  It is implicit that each KeyInfo only 
includes nformation about a single key.

I think Brian is right to raise the issue given the number of 
other specs/proposals that have picked up the Signature KeyInfo 
structure and reused it.  But, I must admit I can't think of any 
examples of where its assumed multiple KeyValues are present 
in a single KeyInfo.  

Personally, this would strike me as quite odd given the overall 
structure.  If you supplied a KeyName, for example, would it 
mean that you now had 2 different keys that should be referred 
to using the same identifier?  Seems like a bad idea.

Blair  



-----Original Message-----
From: Joseph M. Reagle Jr. [mailto:reagle@w3.org]
Sent: Wednesday, February 21, 2001 3:51 PM
To: Carl Ellison
Cc: TAMURA Kent; w3c-ietf-xmldsig@w3.org; kent@trl.ibm.co.jp; Brian
LaMacchia; cwallace@erols.com
Subject: 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 19:52:57 UTC