- From: <olli.immonen@nokia.com>
- Date: Wed, 2 Apr 2008 10:32:39 +0300
- To: <hlockhar@bea.com>, <marcosscaceres@gmail.com>
- Cc: <public-appformats@w3.org>, <member-xmlsec-maintwg-request@w3.org>
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 07:33:44 UTC