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

From: Philip Hallam-Baker <[email-masked]>
Date: Mon, 15 May 2000 07:05:06 -0700

When it comes to backwards compatibility I would (almost) always choose
the IETF standard over an ISO one.

In this particular case the ISO approach would appear to break legacy
implementations in unpredictable ways.

	Phill

-----Original Message-----
From: Sam Schaen [mailto:[email-masked]]
Sent: Monday, May 15, 2000 9: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

---

From: Warwick Ford <[email-masked]>
Date: Mon, 15 May 2000 07:35:15 -0700

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)

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
> "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 ..."
>    extensions are used, as required by this profile, this field MUST be
> This means that I can not create CRLs which do not include any critical
extensions so