Re: Poll: Limiting KeyValue to a single Instance?

This doesn't seem to be provoking much comment...so I'll toss in my
two cents.

My current inclinationn is to leave the specifciation that KeyInfo is
Inforamtion about one key.  Sure, you can express information about
that key in a wide variety of ways, but it all boils down to the
validation key.

I don't really think of the certificate chain mess as an exception to
this, even though you could, for example, end up with a KeyInfo that
has in it only a cert from the middle of a chain to the cert of the
validation key.  If you believe in hierarchical certification, you
need a chain of certs back to your trusted root, and maybe a CRL for
each of these certs, but some or most of these might already be cached
at the receiver.  Figuring out where in messages to put certs/CRLs
that are above the one with the validation key is sort of a mess even
with one signature.  It's worse when you have multiple signatures in a
message.  Putting the certs in with a signature seems like the best
way to do it but you don't want to put them in redundantly with each
signature if there are several signatures in on document that share
most of their cert chain.  At least we have RetrievalMethod, but I
believe that most protocols with this problem just tell the recipient
to dump all the certs associated with the signatures in a message into
a cache and sort it out themselves.

Anyway, if structures are needed for multiple keys, they should be
something other than KeyInfo.

Donald

From:  "Joseph M. Reagle Jr." <reagle@w3.org>
Message-Id:  <4.3.2.7.2.20010223191851.02b6ed10@rpcp.mit.edu>
Date:  Fri, 23 Feb 2001 19:39:11 -0500
To:  Brian LaMacchia <bal@microsoft.com>
Cc:  Blair Dillaway <blaird@microsoft.com>, "'Carl Ellison'" <cme@acm.org>,
            "'TAMURA Kent'" <kent@trl.ibm.co.jp>,
            "'w3c-ietf-xmldsig@w3.org'" <w3c-ietf-xmldsig@w3.org>,
            "'kent@trl.ibm.co.jp'" <kent@trl.ibm.co.jp>,
            "'cwallace@erols.com'" <cwallace@erols.com>
In-Reply-To:  <0C682B70CE37BC4EADED9D375809768A0D0545@red-msg-04.redmond.
	      corp.microsoft.com>

>As an exercise, I just quickly went through the Editor's [1] copy and 
>highlighted (<span class=".discuss"/>) those portions of the text that state 
>that "Multiple declarations within KeyInfo refer to the same key" so as to 
>have a sense of what we would have to loosen *if* we decided to loose that 
>semantic.
>
>There's been two semantics of KeyInfo we've been discussing. First, this 
>issue of whether all the information in a KeyInfo pertains to a single key. 
>Second, whether the key is for signature validation.
>
>On the first question, as the requirements stated this WG was only doing 
>simple signature validation, we were obviously and exclusively concerned 
>with providing information to find the key to do the job. Other information 
>might be provided (particularly in the X509 structures) for trust decisions 
>but that was out of scope and concern for this spec. So we defined the 
>semantic between the children of KeyInfo and their parent as "properties" of 
>a single key. (The counter argument is that this semantic should merely be 
>one of a bag or collection of key stuff with no particular relation between 
>themselves or their parent.) People that use our KeyInfo structure need to 
>understand and will take advantage of the semantic we define between KeyInfo 
>and its children, so we need to get that straight.
>
>On the second question, clearly the intent of KeyInfo as a child of 
>Signature is for signature validation. If it's a child of some other element 
>(like EncryptedData) its intent is defined by its parent (EncryptedData). So 
>I'm not worried about that, or needing to reconsider prose in KeyInfo about 
>"signature validation."
>
>So to return to the first question, I'll ask you folks a question:
>
>1. Who wants to take advantage of the "singular key semantic" whereby:
>   <KeyInfo><KeyName>joe</KeyName><KeyValue>123</KeyValue></KeyInfo>
>Means "there is some key with KeyName=joe and KeyValue=123."?
>
>2. Who wants to take advantage of the "generic key semantic" whereby the 
>same structure above merely means "here's some information about keys."?
>
>Regardless of this question, my present inclination from a stable/editorial 
>point of view is not to have to go through the spec tweaking this 
>substantive text though I certainly appreciate the scenario for option 2. 
>But let's here what people have to say!
>
>__
>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 Tuesday, 27 February 2001 15:11:40 UTC