- 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
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 states: "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? Regards, Glenn Adams _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com
Received on Monday, 26 March 2001 16:48:14 UTC