RE: [widgets-digsig] Comment on use of X.509 v3

>    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