W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > January to March 2001

RE: Poll: Limiting KeyValue to a single Instance?

From: Blair Dillaway <blaird@microsoft.com>
Date: Wed, 21 Feb 2001 16:39:24 -0800
Message-ID: <AA19CFCE90F52E4B942B27D42349637921F8FF@red-msg-01.redmond.corp.microsoft.com>
To: "'Joseph M. Reagle Jr.'" <reagle@w3.org>, Carl Ellison <cme@acm.org>
Cc: TAMURA Kent <kent@trl.ibm.co.jp>, w3c-ietf-xmldsig@w3.org, kent@trl.ibm.co.jp, Brian LaMacchia <bal@microsoft.com>, cwallace@erols.com
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.


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

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:35 UTC