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

Re: XML DSIG Questions

From: Glenn Adams <g_a_adams@hotmail.com>
Date: Mon, 26 Mar 2001 16:45:48 -0500 (EST)
To: lde008@dma.isg.mot.com
Cc: w3c-ietf-xmldsig@w3.org
Message-ID: <F178EBWEVTPStw7Tsvo0000b339@hotmail.com>

Thanks. See further comments below.

>From: "Donald E. Eastlake 3rd" Date: Mon, 26 Mar 2001 14:29:09 -0500

>KeyValue is intended to include the actual key value and is an optional 
>field. If you are providing an X.509 certificate chain and are doing things 
>in the X.509 world, I don't know why you would include a KeyValue element.

We apparently misinterpreted the statement in Section 4.4 which says:

"compliant versions MUST implement KeyValue (section 4.4.2)"

It was not clear to us whether this required the use of KeyValue in content 
(i.e., in a Signature element) or required support for (the semantics of) 
KeyValue in an interpreting application.

>Certificates are not allowed in KeyValue. You want to use IssuerSerial, 
>SKI, or SubjectName inside the same X509Data to indicate the certificate.

Our reading of the DTD fragment:

<!ELEMENT KeyInfo %Key.ANY; >

was that X509Data was permitted in KeyValue, which, based on our 
misunderstanding about KeyValue being required, led us to conclude we could 
place a reference to an X509 certificate inside of X509Data inside KeyValue.

>... it sounds a bit like you are locking yourself into a design where you 
>have to include the certificate, or perhaps even the certificate chain, 
>with every signature. Since certificates tend to be bulky, some systems are 
>designed to minimize cerficiate transmissions and used cached certificates 
>where possible, requesting certificates when needed.

Our requirements at this time are based strictly on a broadcast only 
environment with no return channel, in which case we do require delivery of 
a certificate chain up to but not including some bridge CA certificate. 
Furthermore, we presently do not permit certificate caching due to lack of 
support for CRL distribution.

Our initial design is based on these constraints, which we expect to relax 
in the future when we add return channel support.

So, to return to our attempt to understand XML DSIG's support for X509, we 
understand that each Signature element can contain one KeyInfo element which 
can contain multiple X509Data elements. What isn't clear is, if we deliver 
multiple certificates within a KeyInfo element (including the end-entity 
certificate used to sign SignedInfo as well as one or more CA certificates 
useful in constructing one or more possible certification paths), whether 
these multiple certificates should be placed into a single X509Data element 
or into multiple X509Data elements. The present language of Section 4.4.4 

"different certificates (related to that single key) MUST be grouped within 
a single KeyInfo element but MAY occur in multiple X509Data elements"

This language seems to state that the certificates may appear in one or in 
multiple X509Data elements. In this regard, when would it be important to 
use one versus multiple X509Data elements? Can we limit our usage to one and 
only one X509Data element without significant loss of generality?

Glenn Adams

Get your FREE download of MSN Explorer at http://explorer.msn.com
Received on Monday, 26 March 2001 16:48:14 UTC

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