Subject: plain text version of 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 11:47:36 -0700

i misclicked on my previous message and sent out styled text in my 
message. that has caused problems for some of you. here is the 
message in plain text

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