Subject: Fwd: RE: Inconsistency between X.509-97 and RFC 2459 (and son of RFC 2459)

From: "Hoyt L. Kesterson II" <[email-masked]>
Date: Mon, 15 May 2000 10:29:58 -0700

I sent out an email on this subject to this list some time ago.
We did raise a defect, 220, on this issue and have a approved a
Technical Corrigendum, 3. to the 3rd edition, 97, X.509 as
follows

This
corrects the defects reported in defect reports 9594/220.

Clause 11.2 note 3

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"

This allows PKIX implementors to be conformant to the 97
edition

I wasn't too happy that this nuance was not understood by PKIX
(it was first described as an X.509 error on this list) since I wrote
the original text with a goal of interoperability. However, I
understood that to many on this list interoperation with version 1
systems was not necessary. There I proposed, and the group agreed,
that the shall be soften to a may.

This allows the PKIX group to decide what its interoperability
requirement is. After some pondering I now believe this is the proper
approach for the standard and have taken this approach for several
enhancements that we added for the 4th edition.

hoyt

From: Warwick Ford
<[email-masked]>

To: "'Sam Schaen'" <[email-masked]>,

Ismo Heikkonen

<[email-masked]>

Cc: [email-masked]

Subject: RE: Inconsistency between X.509-97 and RFC 2459 (and son of
RFC 2

459)

Date: Mon, 15 May 2000 07:35:15 -0700

List-Archive: http://www.imc.org/ietf-pkix/mail-archive/

List-ID: <ietf-pkix.imc.org>

List-Unsubscribe: mailto:[email-masked]?body=unsubscribe

The intent was as follows. A V1 CRL
interpreter should correctly process a

CRL with extensions but with no version number -- it will ignore
the

extensions entirely, under the X.500 rules of extensibility (which is
OK,

provided no extensions are critical).  However, if a version
number is

present, a V1 CRL interpreter will break, since the version field

contravenes the extensibility rule -- deliberately, so as to ensure
critical

extensions don't slip through unnoticed.  Therefore, there is a
legitimate

reason for permitting CRLs with noncritical extensions but no
version

number.

X.509 97 probably went too far in *requiring* that configuration, and
you

will note that X.509 2000 pulled that back and made it optional. This
seems

the right thing to me, for the base standard.

This opens the way for PKIX to profile the version as mandatory
against the

2000 standard, although no PKIX CRL will ever work with a V1 CRL

interpreting product (is this important?). Also, as you point out,
you

cannot be consistent with both X.509 97 and PKIX, but that is
probably not

very important given the change in 2000.

Warwick

-----Original Message-----

From: Sam Schaen [mailto:[email-masked]]

Sent: Monday, May 15, 2000 6:02 AM

To: Ismo Heikkonen

Cc: [email-masked]

Subject: Re: Inconsistency between X.509-97 and RFC 2459 (and son of
RFC

2459)

We stumbled across this inconsistency while working on the US DOD
PKI

profile.  We elected to go with the RFC 2459
interpretation.  It seems

to make more sense, since a version 1 CRL interpreter would not

understand extensions at all.

Sam Schaen

MITRE

Ismo Heikkonen wrote:

> Hi,

> it seems to me that there is an inconsistencty between X.509-97
and RFC

2459 (and also son of RFC2459).

> In X.509 , in section 11.2  there is the following note
just after the CRL

definition:

> "3 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 ..."

> But RFC 2459 requires that version shall be present always when
the

> extensions are included:

> "5.1.2.1  Version

>    This optional field describes the version of
the encoded CRL.  When

>    extensions are used, as required by this
profile, this field MUST be

>    present and MUST specify version 2 (the
integer value is 1)."

> This means that I can not create CRLs which do not include any
critical

extensions so

> that they would be compatible with both X.509-97 and RFC
2459.

> Or are there any X.509 Defect reports available around this
topic?

> By the way  X.509 -2000 seems to be more flexible in this
sense.

> Ismo Heikkonen

> Sonera SmartTrust Ltd