Re: XML DSIG Questions


From:  "Glenn Adams" <>
Date:  Mon, 26 Mar 2001 16:45:48 -0500 (EST)
X-Originating-IP:  []
Old-Date:  Mon, 26 Mar 2001 16:44:39 -0500
Message-ID:  <>

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

implement != use

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

Yes, you can always just use one X509Data element.  I believe the
concept was that you might have multiple end certificates containing
the same key and authenticated via different chains, in which case you
can put each end-entity cert and chain in a seprate X509Data
element. However, of course, things can get complicated and it could
be that you have multiple end-entity certs for the same key in
different X509Data elements that are authenticated by a chain whose
root and perhaps near-root certs are the same, in which case you could
cose to watefully duplicate them between X509Data elements, assume an
intelligent cert cache that the certs were all dumped into which could
find chains, or lump everything into one X509Data element...

>Glenn Adams

 Donald E. Eastlake 3rd          
 155 Beaver Streeet               
 Milford, MA 01757 USA     +1 508-634-2066(h)   +1 508-261-5434(w)

Received on Wednesday, 28 March 2001 12:41:53 UTC