[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Removing expired certificates from CRLs.....
Nada,
Which text are using using ? In son-of-RC2459 there is no section 8.6.2.2.
as you indicate.
Please be more specific on the exact sentence that you think is not
appropriate in son-of-RC2459 and which exact change you would like to be
done.
Denis
> >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
>
> The text in 8.6.2.2 does not mention the possibility of leaving the expired
> certificates identifiers in CRL. The last extracted sentence is very
> explicit in requiring removal of revocation info for expired certificates.
>
> >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.
>
> I could not agree more. Perhaps DPV/DPD work could include such guidelines.
>
> >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 ...
>
> You are right. Since the document has already progressed this far, it may
> not be worth making additional modifications.
>
> Nada
>
> >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
> > > >
> > > >