Subject: Re: CRL version field confusion

From: [email-masked]
Date: Thu, 18 Mar 1999 18:26:31 -0500

i don't know why the rfc says what it says.

we, the x.509 standard guys,  wrote the stuff in the standard to allow
maximum interoperability. under the rules of extensibility, one is supposed
to ignore fields that one does not understand.

let's suppose the verifying entity, x, that is checking the crl only
understands version 1 (the version field was introduced by defect
resolution and is to be supported by non-v2 implementations).

let's supposed that entity y is responsible for constructing a crl that can
be consumed by the largest number of verifiers possible.

if y constructs a crl that has extensions that are all non-critical, then y
can either:

1) signal that the crl is version 2; or

2) signal, or don't specify, the version number as version 1.

if the first approach is taken, the relying party x will see that the crl
is a higher version than x can accept and will go no farther.

if the second approach is taken, x  will ignore all of the extensions under
the rules of extensibility and can still use the crl. since the generator
of the crl, y, had not made any of the extensions critical, this is
acceptable

what we don't want is to have some implementation that knows nothing about
this stuff ignore critical extensions. the only way to ensure that the
verifier, e.g. x, won't ignore everything, including critical extensions,
is to have x check the version number. if the version number is greater
than 1, an old style verifier will not apply the rules of extensibility,
ignore everything (including critical), and accept the crl. that is, it
recognizes the version number field and it knows that it doesn't support
that version.

maybe the ietf group didn't care about the existence of old version
verifiers (i.e. all users of interest conform to the pkix profile). what i
can say is that the text in the standard is not an error. its phrasing was
discussed for some time. unfortunately, as in many places in the standard,
there is no explanation of why it states that.

    hoyt

Srinivas Pandrangi <[email-masked]> on 03/18/99 03:56:58 PM

To:   Ambarish Malpani <[email-masked]>
cc:   Martin Lindström <[email-masked]>, [email-masked],
      [email-masked], [email-masked] (bcc: Hoyt Kesterson/US/BULL)
Subject:  Re: CRL version field confusion

Ambarish,
X.509 does seem to say that version should be v1(0) if non-critical
crlExtensions are present. It suggests that only crlEntryExtensions (in
revokedCertificates), and "critical" crlExtensions imply a version of v2.
This is in contrast to PKIX which says that the presence of any extension
implies v2.
--Srinivas
Ambarish Malpani wrote:
> Actually it isn't an ambiguity. The default value for the version
> in CRLs, is v1 (i.e. 0). So if you are encoding a version 1
> CRL (ie. one with no extensions), you don't encode the version
> number.
>
> Hope this helps,
> Regards,
> Ambarish
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf
> Of Martin Lindström
> Sent: Thursday, March 18, 1999 12:48 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: CRL version field confusion
>
> I think I've found an ambiguity(?) between rfc2459 and the X.509
> in the way CRL version fields should be treated.
>
> X.509 says: "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"
>
> RFC2459 on the other hand says: "When extensions are used, as required
> by this profile, this field MUST be present and MUST specify version 2"
>
> Depending on which definition I use to encode a CRL having no critical
> extensions I get different results. Is this correct?
>
> /Martin
>
> ______________________________________
>          Entegrity Solutions
>
>   Martin Lindström
>   Senior Systems Engineer
>
>   Finlandsgatan 60
>   S-164 74 Kista, Sweden
>   Direct: +46-(0)8-477-7735
>   Fax:    +46-(0)8-477-7731
>   Cell:   +46-(0)70-483-0024
> ______________________________________
--
-------------------------------------------------------------------
Srinivas Pandrangi
XETI Inc.
[email-masked]
(650) 694 6804
-------------------------------------------------------------------

---

From: Stephen Kent <[email-masked]>
Date: Fri, 19 Mar 1999 12:26:59 -0500

Hoyt and David,

I apologize for my hasty conclusion re the correctness of the version #
issue with respect to  non-critical extensions.  I understand the
rationale, but I doubt that, in practice, most cert and CRL procesing
software operates as you say it ought to.  Based on your comments, one
could send any v3 non-critical extensions in certs, as well as CRLs, and
not mark the cert or crl as other than version one.  i think that the PKIX
prohibition against such usage is rooted in the belief that including any
extensions in a v1 crl or v1/2 cert usually would  result in unpleasant
behavior by most cert consuming software.

I think our constraints are appropriate, but I retract my comment about
X.509 being wrong.

Steve