- From: Donald E. Eastlake 3rd <lde008@dma.isg.mot.com>
- Date: Mon, 26 Mar 2001 14:29:09 -0500
- To: "Glenn Adams" <g_a_adams@email.msn.com>
- cc: w3c-ietf-xmldsig@w3.org
My comments pretty much parallel those of Joseph Reagle... >From: "Glenn Adams" <g_a_adams@email.msn.com> >To: <reagle@w3.org> >Subject: XML DSIG Questions >Date: Sun, 25 Mar 2001 10:26:14 -0500 > >Dear Mr. Reagle, > >I am the editor of the ATSC (Advanced Television Systems Committee) DASE (DTV >Application Software Environment) Standard in which we are attempting to make >use of the W3C XML-Signature Syntax and Processing specification under >development. We will use X.509v3 certificates for all public key >representations. > >I have a few questions/comments about the W3C XML DSIG (DS) recommendation: > >(1) regarding KeyInfo, it is unclear whether DS intends the KeyValue to >contain >the certificate data which contains the signing key or whether this would be >contained in KeyInfo directly; for example, is the following example what is >intended with respect to specifying the signing key? > ><KeyInfo> > <KeyValue> > <X509Data> > <X509IssuerSerial>...</X509IssuerSerial> > </X509Data> > </KeyValue> > <X509Data> > <!-- end-entity certificate --> > <X509Certificate>...</X509Certificate> > <!-- CA certificate 1 --> > <X509Certificate>...</X509Certificate> > <!-- CA certificate 2 --> > <X509Certificate>...</X509Certificate> > </X509Data> ></KeyInfo> 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. >This differs from the example of using <KeyInfo> found in Section 4.4.4 where >there appears no instance of KeyValue. > >Our requirements regarding the use of DS are: > >* The specific certificate (containing the public key) must be unambiguously >identified without resorting to conventions of X509Data usage or >heuristics. It >appears that by using X509Data within KeyValue to identify the certificate >satisifies this requirement. Although we aren't certain if this usage is >intended (i.e., specifying a reference to (name/identity of) the >certificate in >KeyValue as opposed to providing the key itself in KeyValue. No, you just want to use the IssuerSerial element or SKI or SubjectName in the X509Data element to indicate the certificate. >* The public key required to validate the signature must communicated solely >within a signed structure, namely, within an X509Certificate, and not be >extracted from the certificate into an unsigned structure, e.g., extracted >into >KeyValue. This requirement seems to be satisfied by only placing a >reference to >the certificate in KeyValue and placing the certificates into an X509Data >element which is a peer of KeyValue. Certificates are not allowed in KeyValue. You want to use IssuerSerial, SKI, or SubjectName inside the same X509Data to indicate the certificate. >(2) In general, it is difficult to determine the intentions of DS with >respect >to the use of X509Data directly within KeyInfo and the use of X509Data within >KeyValue. We would suggest adding more examples and better descriptions of >these >intentions. As indicated by Joseph, we hope we have improved the wording. >(3) What is the projected schedule for advancing to PR with this >recommendation? >Since we normatively reference this work, it will be necessary for it to >advance >to recommendation status prior to our balloting our standard. > >Regards, >Dr. Glenn Adams >Acting Chair, ATSC T3/S17 DASE Specialist Group While I hope the above information will solve your problem and we do specifically provide several ways to designate the certificate with the validation key, 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. Thanks, Donald ============================================================ Donald E. Eastlake 3rd Donald.Eastlake@motorola.com Motorola, MS: M2-450 +1 508-261-5434(w) 20 Cabot Boulevard dee3@torque.pothole.com Mansfield, MA 02048 USA +1 978-562-2827(h)
Received on Monday, 26 March 2001 14:29:13 UTC