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

[Nada Kapidzic Cicovic <nada@xxxxxxxxxxxxx>]

At 03:22 PM 9/5/01 +0200, Denis Pinkas wrote:
> Nada,
>
> Which text are using using ? In son-of-RC2459 there is no section
> 8.6.2.2.
> as you indicate.

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). 

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



> 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
> > > > >
> > > > >