- 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