Re: Removing expired certificates from CRLs.....

["David A. Cooper" <david.cooper@xxxxxxxx>]

At 03:53 PM 9/5/01 +0200, Nada Kapidzic Cicovic wrote:
> Denis,
>
> I was making comments on the text which Ryan extracted in his mail,
> assuming that they were from the son-of-RFC2459.
>
> In particular the last sentence in this paragraph:
>
> The distributionPoint component contains the
> name of the distribution point in one or more name forms. If this field
> is absent, the CRL shall contain entries for all revoked certificates
> issued by the CRL issuer. After a certificate appears on a CRL, it
> is deleted from a subsequent CRL after the certificate's expiry.
>
> However, after getting your comment I realized that this sentence
> and the referred section 8.6.2.2 comes from the X.509 (the latest version
> that I have on my disk is X_509_4thEditionDraftV6, and it contains the
> above text). 

I have X_509_4thEditionDraftV8 on my computer and it appears that this
has been fixed. I now says "After a certificate appears on a CRL, it
may be deleted from a subsequent CRL after the certificate’s
expiry."  I didn't bother to look at son-of-2459.

In any case, both X.509 and son-of-2459 should say that a certificate may
be deleted from a CRL after it has expired.  In general, though, I
don't think there is much benefit to leaving expired certificates on
CRLs.  The problem is that, at the moment, if an expired certificate
is not listed on a CRL, there is no way to determine whether it is not
listed because it was never revoked or if it was revoked but is not
listed because it was removed after expiration.

Some time ago, there was a suggestion to create a new, non-critical CRL
extension that would specify whether an expired certificate was covered
by a CRL (e.g., the extension could state: "This CRL includes all
revoked certificates that expire(d) after Jan. 1, 2001 (i.e., notAfter
>= 010101000000Z)."). There didn't seem to be much support for
this idea, so the extension was never created.

> The current text of the son-of-RFC2459 does
> not seem to contain it or any other misleading sentences regarding this
> issue. 
>
> Sorry for the confusion.
>
> Nada