RE: Poll: Limiting KeyValue to a single Instance?

re: "applying to the validation key", this interpreation is definitely
contrary to how KeyInfo is being used within XKMS and the XML Encryption
proposal.

and I take back my earlier comment about allowing multiple keys being odd. I
don't believe the spec says the KeyValue and other elements under a KeyInfo
must refer to the same key.  So the usage pattern I was thinking of is only
one possible one.

I would agree with Brian there may be times where the ability to have
mutliple key values is useful.  So why limit it without a good reason.

Blair

-----Original Message-----
From: Brian LaMacchia 
Sent: Wednesday, February 21, 2001 5:11 PM
To: Blair Dillaway; 'Joseph M. Reagle Jr.'; 'Carl Ellison'
Cc: 'TAMURA Kent'; 'w3c-ietf-xmldsig@w3.org'; 'kent@trl.ibm.co.jp';
'cwallace@erols.com'
Subject: RE: Poll: Limiting KeyValue to a single Instance?


Well, part of my objection to the original proposal is that the poll option
was phrased as "should we also limit KeyValue to occurring once and applying
to the validation key".  There are two clauses, and I have problems with
both parts.

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."  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.  

Furthermore, I could imagine certain environments where KeyValue is used to
indicate an important key to the trust validation process but not the
validation key for the SignatureValue.  For example, if you were using X.509
certs you could choose to designate the ROOT of a trust chain using KeyValue
instead of a self-signed cert.  Self-signed certs are bulky and they don't
necessarily contain anything useful, so why not use KeyValue as a more
compact way to say what the chain roots are for the EE certs included in the
message?  That would allow a signature validator to decide quickley whether
there were any roots here of interest (policy-wise) and error early if not.

Regarding the first clause, "should we allow only one KeyValue within a
KeyInfo?", again I do not see a good argument for this requirement and such
a restriction may limit use of KeyInfo later in other specs.  If you want a
hypothetical example consider the root cert exchange/dance that SSL/TLS
servers & clients go through when setting up a connection.  The exchange of
trusted root keys (done by transporting a bag of self-signed root certs)
could be similarly accomplished in an XML protocol by sending a single
KeyInfo structure with multiple KeyValue elements inside.  Each KeyValue
element would similarly indicate a trusted root key.  Why preclude the
possibility of using KeyInfo/KeyValue to pass a bag of keys?

I could also see a desire to have multiple KeyValues in something like XML
Encryption...

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.  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 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.

					--bal

-----Original Message-----
From: Blair Dillaway 
Sent: Wednesday, February 21, 2001 4:39 PM
To: 'Joseph M. Reagle Jr.'; 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?


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 20:46:07 UTC