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

From: "Tom Gindin" <[email-masked]>
Date: Fri, 7 Sep 2001 07:56:41 -0400

I would argue for SHOULD for that extension rather than MUST, but its
presence can hardly hurt if it is non-critical.  BTW, I hadn't read your
note when I composed mine.  Now, what is the proper syntax for this
extension, which could be named "RevokeRetention"?  Here are some
possibilities:
1    Assume that all usage types have either no retention or the same one.
A simple syntax for this would be:
     RevokeRetention ::= SEQUENCE  {
          basicUsages    KeyUsage OPTIONAL,
          extUsages SEQUENCE OF OBJECT IDENTIFIER OPTIONAL,
          incExpsAfter   GeneralizedTime
     }
2    Assume that usage types may have different non-null retentions.  A
slightly less simple syntax for  this would be:
     RevokeRetention ::= SEQUENCE OF UsageRevokeRetention
     UsageRevokeRetention ::= SEQUENCE   {
        CHOICE {
          basicUsage     INTEGER, -- 0-based bit offset from KeyUsage
definition
          extUsage  OBJECT IDENTIFIER,
        }
        incExpsAfter     GeneralizedTime
     }

     Naturally, any revocation matching a specified usage would be expected
to be retained on the CRL if the certificate expiration time is after
"incExpsAfter", but not otherwise.  Furthermore, do you think
extendedKeyUsage should be omitted?

          Tom Gindin

Denis Pinkas <[email-masked]> on 09/07/2001 07:34:12 AM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   IETF-PKIX <[email-masked]>
Subject:  Re: Removing expired certificates from CRLs.....

Hello Tom !

>      Because of unscheduled CRL publication, would it not make sense to
> recommend a minimum period of time after expiration before revoked NR
> certificates get removed from CRL's?  In practice, specifying that they
> should be kept for a week or so beyond expiration would not cause CRL
> bloat, which can admittedly become a serious problem if all CRL entries
are
> kept forever.

Such recommendation would be nice, but only usable in "closed environments"
where it can be known that this policy is enforced. In "open environments"
in order to allow the use of CRLs which include certificates even after
they
expire, some indication SHALL be present in the CRL to know whether or not
it includes such certificates.

Denis

>           Tom Gindin
>
> "Flynn, Michael" <[email-masked]>@mail.imc.org on 09/05/2001
01:02:33
> PM
>
> Sent by:  [email-masked]
>
> To:   "'Ryan Hurst'" <[email-masked]>, IETF-PKIX <[email-masked]>
> cc:
> Subject:  RE: Removing expired certificates from CRLs.....
>
> Ryan,
>
> Ryan wrote::
>
> 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.
>
> At least regarding removing expired certs from CRLs, I would think that
> non-repudiation can be satisfied by keeping the old CRLs in back up
storage
> for some length of time.  That time being how far back in time a contract
> dispute might go; ten years, twenty?   So long as you could get them off
> tape for the lawyers to look at the legal process would be satisfied,
they
> don't need to be online forever.
>
> Michael
>
>  -----Original Message-----
>  From: Ryan Hurst [mailto:[email-masked]]
>  Sent: Tuesday, September 04, 2001 8:50 PM
>  To: IETF-PKIX
>  Subject: Removing expired certificates from CRLs.....
>
>  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

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 07 Sep 2001 14:32:14 +0200

Tom,

I still believe that this discussion is more appropriate, at this time, to
X.509 currently rather than PKIX. So I have bindly copied the X.509
discussion list. Having said that, making sure that PKIX members agree with
the proposal cannot hurt.

> presence can hardly hurt if it is non-critical.  

I believe that we basically agree. When this extension is present, then it
is non critical.

> BTW, I hadn't read your note when I composed mine.  
> Now, what is the proper syntax for this extension, which could be named 
> "RevokeRetention"?  Here are some possibilities:

>           incExpsAfter   GeneralizedTime

Since in practice, I would expect a policy where all certicates having DS or
NR set are kept one month longer, this seems sufficient.

> 2    Assume that usage types may have different non-null retentions.
    A slightly less simple syntax for  this would be:
>        basicUsage     INTEGER, 
                        -- 0-based bit offset from KeyUsage definition
>      incExpsAfter     GeneralizedTime

I would prefer:
 
        basicUsage     BIT STRING  rather than
        basicUsage     INTEGER

We could also have a simpler syntax:

    UsageRevokeRetention ::= SEQUENCE  {
        incExpsAfter     GeneralizedTime,
        basicUsage       BIT STRING                      OPTIONAL, 
        extUsages        SEQUENCE OF OBJECT IDENTIFIER   OPTIONAL
    }

If some dates are different but some dates are common to various types of
certificates, this can save some entries. 

> extendedKeyUsage should be omitted?

For completness, since X.509 is a framework, extendedKeyUsage should be
there. PKIX can then decide to keep it or leave it in its profile.

Now, suppose we do this, this is fine for CRLs. How should an OCSP server
behave whether or not expired certificates are kept longer than strictly
mandatory ? RFC 2560 is rather vague on that topic.

Denis

---

From: Tim Polk <[email-masked]>
Date: Fri, 07 Sep 2001 17:19:37 -0400

Denis, Tom, et al.

As one of several independent originators of the idea, (Ambarish Malpani is 
another), I thought I ought to weigh in as well.  I had something 
*considerably* simpler in mind.  If a CRL includes revocation information 
for certificates that have expired, a relying party should be able to 
determine that automatically.

I would suggest a noncritical CRL extension with a single value of type 
GeneralizedTime.   The ASN.1 syntax would be

	ExpiredCertsOnCRL ::= GeneralizedTime

As usual with PKIX times, we would require time Zulu with seconds (even if 
zero).

The semantics for the extension would be as follows:

	The scope of a CRL containing this extension is extended to include 
certificates that expired  at the exact time specified in the extension or 
after that time.  If limitations in the CRL's scope are specified (by 
either reason codes or by distribution points), that applies to expired 
certificates as well.

IMHO, we shouldn't make the scope of a CRL different for expired and 
unexpired certificates.  This is a simple idea - let's keep it that way!

BTW, folks were wondering why this hasn't been pursued in PKIX.  This idea 
has been floated a couple of times, but no one was really ready to 
implement it.  We needed to concentrate on the core functionality.  I 
floated the idea again at one of the meetings (in San Diego?) and Ambarish 
said he'd had the same idea and wanted to pursue it.  I asked him to delay 
any new work in this area until the son-of-2459 is approved by the 
IESG.  (Neither of us realized what a long delay we'd agreed to...)

Thanks,

Tim Polk

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 10 Sep 2001 09:51:04 +0200

Tim,

> determine that automatically.

We strongly agree on that statement.

> either reason codes or by distribution points), that applies to expired

As Tom said, in practice we would expect certificates with the DS bit set
with a retention period of two or three days, while certificates with the NR
bit set with a retention period of about one month. For other certificates,
it would be the next *scheduled* CRL after revocation.

An option is to say that all certificates from a CRL are maintained for a
fixed time, e.g. one month more. This does not increase the size of CRLs
indefinitively and, as Tim says, is simple enough. 

If different retention periods are needed, there is still a solution, but
there is a price to pay: use CRL Distribution Points with different reason
codes. This means that certificates must originally be produced with this
feature. If there aren't ... then this is not possible.
 
I can buy that simplicity, as long as we include such explanations in the
text.

Denis