RE: CRL version number discrepancy

[Sharon Boeyen <sharon.boeyen@xxxxxxxxxxx>]

Here are the details from the X.509 side:

This correction to X.509 is being made, as agreed at the April 1999 meeting,
through defect report DR 220. The nature of the defect is described as:

"The current text requires that, if no extensions defined as critical are
included 
in a CRL, the version element be absent from that CRL. While this may be
helpful 
in some environments where backward compatibility with version 1 CRLs, this
should 
not be mandatory behaviour. An issuer should be able to mark its CRL as v2 
regardless of whether or not critical extensions are present. Note that some

profiles (e.g. PKIX) require that all CRLs be v2."

The changes to the text are currently under ballot and contained in DTC 3 to

the 97 X.509 text and read as follows:

In Note 3, in the second sentence replace "shall be absent" with "may be
absent".

In Note 3, at the beginning of the 3rd sentence, replace "This may permit"
with 
"If version is absent, this may permit"

In Note 3, at the beginning of the 4th sentence, replace "An implementation
that 
supports version 2 (or greater) CRLs may" with "An implementation that
supports 
version 2 (or greater) CRLs, in the absence of version, may also" 

The ballot closes in early November and at this point we are not
anticipating
any problems with approval.

If anyone wants to see the documents themselves (defect report and DTC) here

are links to them:

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509/DR_
220
ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigend
a/X.509/8-DTC3(3rd).doc

Sharon
-----Original Message-----
From: Hoyt.Kesterson@bull.com [mailto:Hoyt.Kesterson@bull.com]
Sent: Wednesday, August 25, 1999 9:27 AM
To: Hans Nilsson
Cc: ietf-pkix@imc.org
Subject: Re: CRL version number discrepancy


actually we have had this debate. the text is correct in 509 but it was
considered an unnecessary complication in the pkix profile. the 509 text was
to
broaden the amount of interworking between different versions. i understood
the
pkix position to be that with minimal deployment of earlier versions, the
509
text didn't buy anything (other that possible confusion)

i (and the x500 group) considered the text still useful but decided to make
it
optional. the "shall" will be changed to a "may". this will allow a profile
to
broaden interaction if necessary. whatever pkix decides to do, there will be
no
conflict with the standard.

    hoyt




Hans Nilsson <hans.nilsson@iD2tech.com> on 08/24/99 11:34:06 PM

To:   ietf-pkix@imc.org
cc:    (bcc: Hoyt Kesterson/US/BULL)
Subject:  CRL version number discrepancy




There is a discrepancy between X.509 and RFC 2459.

X.509 states:

If any extensions included in a CertificateList are defined as critical, the
version element of the CertificateList shall be present.  If no extensions
defined as critical are included, the version element shall be absent. This
may permit a implementation that only supports version 1 CRLs to still use
the CRL if in its examination of the revokedCertificates sequence in the
CRL, it does not encounter an extension. An implementation that supports
version 2 (or greater) CRLs may be able to optimize its processing if it can
determine early in processing that no critical extensions are present in the
CRL.

RFC 2459 states that:

Conforming CAs that issue CRLs MUST issue version 2 CRLs,

and, later,

When extensions are used, as required by this profile, this field MUST be
present and MUST specify version 2 (the integer value is 1.

The question is now:
When we issue CRLS with non-crictical extensions, should the version number
be omitted (according to X.509) or present and set to 2 (according to RFC
2459?

Until further notice, we regard X.509 as having precedence over RFC 2459. Is
this correct?

Regards
Hans Nilsson