- From: Hal Lockhart <hlockhar@bea.com>
- Date: Wed, 2 Apr 2008 13:07:40 -0700
- To: <olli.immonen@nokia.com>, <marcosscaceres@gmail.com>
- Cc: <public-appformats@w3.org>, <member-xmlsec-maintwg-request@w3.org>
> Implementations SHOULD be prepared to accept any version certificate. > At a minimum, conforming implementations MUST recognize version 3 > certificates. Since this is not well understood and the document is not generally accessible, you might want to repeat the above in your document. In fact, I would suggest changing it to say: Implementations MUST be prepared to accept any version certificate. Hal > -----Original Message----- > From: olli.immonen@nokia.com [mailto:olli.immonen@nokia.com] > Sent: Wednesday, April 02, 2008 3:33 AM > To: Hal Lockhart; marcosscaceres@gmail.com > Cc: public-appformats@w3.org; member-xmlsec-maintwg-request@w3.org > Subject: RE: [widgets-digsig] Comment on use of X.509 v3 > > Hi, > > To clarify the issue, [X.509v3] allows three version numbers, depending > on which data is included. Here is a quote from the definition > (available at http://www.itu.int/rec/T-REC-X.509-199708-S/en) > > Certificate ::= SIGNED { SEQUENCE { > version [0] Version DEFAULT v1, > serialNumber CertificateSerialNumber, > signature AlgorithmIdentifier, > issuer Name, > validity Validity, > subject Name, > subjectPublicKeyInfo SubjectPublicKeyInfo, > issuerUniqueIdentifier [1] IMPLICIT UniqueIdentifier OPTIONAL, > -- if present, version must be v2 or v3 > subjectUniqueIdentifier [2] IMPLICIT UniqueIdentifier OPTIONAL, > -- if present, version must be v2 or v3 > extensions [3] Extensions OPTIONAL > -- If present, version must be v3 -- } } > > Version ::= INTEGER { v1(0), v2(1), v3(2) } > > RFC3280 (a profile of X.509) states a bit more exactly which version > numbers to use: > > 4.1.2.1 Version > > This field describes the version of the encoded certificate. When > extensions are used, as expected in this profile, version MUST be 3 > (value is 2). If no extensions are present, but a UniqueIdentifier > is present, the version SHOULD be 2 (value is 1); however version MAY > be 3. If only basic fields are present, the version SHOULD be 1 (the > value is omitted from the certificate as the default value); however > the version MAY be 2 or 3. > > Implementations SHOULD be prepared to accept any version certificate. > At a minimum, conforming implementations MUST recognize version 3 > certificates. > > Generation of version 2 certificates is not expected by > implementations based on this profile. > --- > > So, stating conformance to [X509v3] does not imply that that only v3 > would be allowed. > > /Olli > > > >-----Original Message----- > >From: public-appformats-request@w3.org > >[mailto:public-appformats-request@w3.org] On Behalf Of ext Hal Lockhart > >Sent: 01 April, 2008 20:35 > >To: Marcos Caceres > >Cc: public-appformats@w3.org; member-xmlsec-maintwg-request@w3.org > >Subject: RE: [widgets-digsig] Comment on use of X.509 v3 > > > > > >Sorry for the delay. > > > >I am still unclear as to what you intend to require. I do not > >have easy access to [X.509v3], but I suspect that it says that > >a certificate MUST have a value of 2 (indicating v3) in the > >version field. > > > >Do you expect conforming implementations which perform > >signature validation to enforce this? If you do, you may run > >into interoperability problems. If you do not, then the > >document should explicitly say so. > > > >Hal > > > >> -----Original Message----- > >> From: Marcos Caceres [mailto:marcosscaceres@gmail.com] > >> Sent: Monday, March 24, 2008 11:15 PM > >> To: Hal Lockhart > >> Cc: public-appformats@w3.org; member-xmlsec-maintwg-request@w3.org > >> Subject: Re: [widgets-digsig] Comment on use of X.509 v3 > >> > >> HI Hal, > >> > >> > >> On Fri, Mar 21, 2008 at 10:13 PM, Hal Lockhart <hlockhar@bea.com> > >wrote: > >> > > >> > The current draft of Widgets 1.0: Digital Signature says: > >> > > >> > 3. The digital certificate format must be [X.509v3]. > >> > > >> > This actually is not well defined, however I will assume what is > >meant > >> > is that version field contains a value of 2 (indicating v3). > >> > > >> > Experience with interoperability testing has shown that some > >popular PK > >> > libraries will only mark certificates as v3 if one or more > >extension > >> > fields are present. Otherwise the version field will be > >set to zero > >> > (indicating version 1). The intention is to provide interoperation > >with > >> > older implementations which only support v1. > >> > > >> > If the intention is to require the use of extensions in > >certificates, > >> > then restricting certificates to v3 is reasonable. However I see > >> nothing > >> > in the document that suggests this. If not, you may want to > >consider > >> > allowing certificates to be labeled as either v1 or v3. > >> > >> Our intention was not to limit the certificate versions, but only to > >> say that a certificate must conform with the "[X509v3]" > >specification, > >> which is: > >> > >> ITU-T Recommendation X.509 version 3 (1997). "Information > >Technology - > >> Open Systems Interconnection - The Directory Authentication > >Framework" > >> ISO/IEC 9594-8:1997. > >> > >> Hopefully, the wording of the Widget DigSig spec reflects the XML > >> DigSig specification [1], which reads: > >> > >> "The X509Certificate element, which contains a > >base64-encoded [X509v3] > >> certificate..." > >> > >> The intent in our spec is that only the <X509Data> and > >> <X509Certificate> elements be used when signing a widget (hence > >> [X509v3]; other certificate types are not currently supported by > >> widgets). > >> I will change the text in the Widget Dig Sig spec to make it more > >> clear and possibly add a note reflecting your comments. > >> > >> Please let me know if that is suitable. > >> > >> Kind regards, > >> Marcos > >> > >> [1] http://www.w3.org/TR/xmldsig-core/#sec-X509Data > >> > >> -- > >> Marcos Caceres > >> http://datadriven.com.au > > > >
Received on Wednesday, 2 April 2008 20:08:35 UTC