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

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Nada and Ryan,

> Ryan,
> 
> Some years ago we at Entegrity also had similar discussion. We were
> positive CRLs were not to contain the information about the expired
> certificates, until we came across some industry CA CRLs containing
> information about all revoked certificates. We then looked into 2459
> (draft in those days) and X.509 text and came to the conclusion that
> deleting info about expired certificates from a CRL is only an option.
> 
> I am not sure what was the intention of the original authors of X.509
> (perhaps Sharon and Hoyt know more about it), but the current industry
> practice seems to be a mixture of both approaches.

At the very beginning, when ISO started the work, non-repudiation was not
considered, but only authentication and data origin authentication.

> My personal opinion is that keeping all revoked certificates info in CRLs
> brings more problems than benefits. However, it is questionable whether
> PKIX needs to take a vote for one approach or the other.
> 
> In any case I would suggest that the text of 2459 be modified so that it
> has a MAY (or a MUST) consistently in all places where deleting expired
> certificates revocation info from CRLs is mentioned. The current text only
> brings confusion, as you have already pointed out.

In all the sentences that have been extracted below, I could not find a
place where a change would be necessary. So I believe that the current text
is OK : it tells how long revoked certificates MUST be kept in a CRL but
does not forbid to maintain them longer. I agree that maintaining them too
long would be a problem because of the increasing size of the CRL, hence why
CRL information should be captured when still available, in case a
non-repudiation service is supported.

We could add is a recommendation like: "Certificates identifiers
for certificates that contain the NR bit in the KeyUsage extension field
SHOULD be maintained in a CRL a few days or weeks after they have expired." 

However, it seems rather late to add such a sentence, since we passed IETF
last call. I leave the issue to the editors ...

Denis


> Nada
> 
> At 08:49 PM 9/4/01 -0700, Ryan Hurst wrote:
> 
> > I was speaking with Peter Williams today about the removal of expired
> > certificates from CRLs; I have always been under the belief that this
> > behavior was optional, I vaguely remembered reading text in 2459 along
> > those lines; additionally I know of several commercial CAs that do not
> > remove the expired certificates from their CRLs. Peter on the other hand
> > was under the impression that it was a mandate to remove CRLs; he too
> > remembered reading text in 2459 to support is position.
> >
> >
> >
> > So we each pulled out the RFC and found that we were both right!
> > Specifically both sections 3.3 and 8.6.2.2 have text on this subject:
> >
> >
> >
> > 3.3  Revocation
> >
> > When a certificate is issued, it is expected to be in use for its entire
> > validity period.  However, various circumstances may cause a certificate
> > to become invalid prior to the expiration of the validity period.
> >
> >
> >
> > ....
> >
> >
> >
> > An entry is added to the CRL as part of the next update following
> > notification of revocation. An entry may be removed from the CRL after
> > appearing on one regularly scheduled CRL issued beyond the revoked
> > certificate's validity period.
> >
> >
> >
> >
> >
> >
> >
> > 8.6.2.2 Issuing distribution point extension
> >
> > This CRL extension field identifies the CRL distribution point for this
> > particular CRL, and indicates if the CRL is limited to revocations for
> > end-entity certificates only, for authority certificates only, or for a
> > limited set of reasons only. The CRL is signed by the CRL issuer's key-
> > CRL distribution points do not have their own key pairs. However, for a
> > CRL distributed via the Directory, the CRL is stored in the entry of the
> > CRL distribution point, which may not be the directory entry of the CRL
> > issuer. If this field is absent, the CRL shall contain entries for all
> > revoked unexpired certificates issued by the CRL issuer.
> >
> >
> >
> > ....
> >
> >
> >
> > 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.
> >
> >
> >
> >
> >
> > Although section 8.6.2.2 is specifically in regards to CRLdps, any
> > difference between full CRLs and CRLdps in this case I feel would be an
> > arbitrary one.
> >
> >
> >
> > Now logically it makes sense to remove certificates that are expired
> > from CRLs to control size, yes this has a negative point specifically it
> > prevents CRLs from being used as a non-repudiation source; but this is
> > mute due to many other issues.
> >
> >
> >
> > That being the case I think; and I believe Peter would agree the correct
> > thing to do is to remove these expired/revoked entries from the CRL.
> >
> >
> >
> > The question now is what is the PKIX stance on this matter?
> >
> >
> >
> > Ryan M. Hurst
> >
> > ValiCert, Inc.
> >
> >
> >
> >      "It may roundly be asserted that human ingenuity cannot concoct a
> >      cipher which human ingenuity cannot resolve."
> >      -Edgar Allan Poe
> >
> >