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

From: Sharon Boeyen <[email-masked]>
Date: Thu, 6 Sep 2001 09:41:38 -0400

David I do remember some discussion of a new extension but don't recall the
reason why it wasn't pursued - do you remember? 
 
With the 509 meeting coming up in just a couple of weeks, if we reach
consensus that it would be useful to add either a new extension or a new
component to the IDP extension to indicate that a CRL includes revocation
notices for expired certs, we could probably add it to the 509 WD at that
meeting. 
 
I believe there is value in allowing expired certs to remain on CRLs, but
certainly it should be an optional feature as it is not needed in all
environments.
 
Cheers,
Sharon
-----Original Message-----
From: Ryan Hurst [mailto:[email-masked]]
Sent: Thursday, September 06, 2001 1:16 AM
To: 'David A. Cooper'; IETF-PKIX
Subject: RE: Removing expired certificates from CRLs.....

David -
 
            Although my confusion on this issue has been cleared up (note to
self; always verify your sources) now; this brings up a very interesting
point. I and others I have spoken with believe that the addition of such an
extension (one that states that the CRL contains ALL revocation entries both
current and expired) would be very valuable. 
 
Consider this problem, today I receive a digitally signed and time stamped
document (a contract possibly), this document was signed by a certificate
issued off of any number of commercial CA's that exist today. 10 years later
the document is in question and I need to establish that the certificate
associated with the signature on the document was valid at the time it was
signed; there are several significant possibilities here:
 
1.	CA in question has CRLNumber extension in all of their CRLs and they
are all available 

2.	CA in question does not have the CRLNumber in all CRLS or just a
subset 
 
Now in #1 the problem is relatively easy, I find all CRLs that were valid
during my window and of those I pick the one that has the highest CRLnumber.
An extension like this would be "use-full" in this case but not necessary.
 
In #2 the problem gets, well unsolvable; Since there are no ways to
determine if I have all of the CRLs that are within my window (remember
validity windows on CRLs can overlap so the ones within the overlapped
window that state the certificate is revoked could be "lost") I will never
now if the certificate was valid at the time in question. Now if the CRLs
that were generated contained all entries and were marked as such with an
extension I would have a mechanism to solve this problem; simply get the
most recent CRL.
 
Ryan

-----Original Message-----
From: David A. Cooper [mailto:[email-masked]] 
Sent: Wednesday, September 05, 2001 7:39 AM
To: IETF-PKIX
Subject: Re: Removing expired certificates from CRLs.....
 
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

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 06 Sep 2001 16:11:46 +0200

Hi Sharon,

Glad to see back on the PKIX mailing list for a short while. :-)

> David I do remember some discussion of a new extension but 
> don't recall the reason why it wasn't pursued - do you remember? 
 
> With the 509 meeting coming up in just a couple of weeks, 
> if we reach consensus that it would be useful to add either 
> a new extension or a new component to the IDP extension to indicate 
> that a CRL includes revocation notices for expired certs, 
> we could probably add it to the 509 WD at that meeting. 

At this time it is more an X.509 discussion, rather than a PKIX discussion.
Anyway, I would support in principle the idea for X.509. 

The information could be placed either in the certificate or in the CRL.
Placing it in the CRL has the advantage of not overloading the certificate,
so this solution should be better. So, if the information is placed in the
CRL, then the CRL should say something like: certificates which have the 
keyUsage bits set to XXXX are maintained on the CRL Y weeks after they
expire.

One of the main benefits is the following: you receive an e-mail while on
holidays. The signature was done just before the certificate expired, but
the e-amil was opened after it expired. With this additional feature it
would be possible to know by fetching the current CRL whether the e-mail was
signed legitimately.

> I believe there is value in allowing expired certs to remain 
> on CRLs, but certainly it should be an optional feature as 
> it is not needed in all environments.

True.

Regards,

Denis 
 
> Sharon

BTW: my Netscape 4.7 browser is unable to display your message correctly.
Next time, please use plaintext.

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 06 Sep 2001 10:51:57 -0400

At 04:11 PM 9/6/01 +0200, Denis Pinkas wrote:

>At 09:41 AM 9/6/01 -0400, Sharon Boeyen wrote:

I agree that the information should be placed in the CRL. This provides the CRL issuer with flexibility.

The idea of specifying keyUsage bits sounds interesting. This could be used to specify that only certificates used to verify signatures (i.e., keyUsage of digitalSignature and/or nonRepudiation) are listed after expiration. I can't think of any compelling reason to include key management certificates after they have expired. However, I'm not sure if the benefit is worth the increased complexity.

I would also suggest a slight re-wording of the meaning of the extension to "this CRL lists all revoked certificates that have expired within the last Y weeks (in addition to all unexpired revoked certificates).". The extension should only specify what is included in that particular CRL, it should not make any promises about what is included in other CRLs. The CRL issuer should always be free to expand or shrink the set of expired certificates covered by its CRLs.

Dave

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 06 Sep 2001 17:21:16 +0200

David,

 

> The idea of specifying keyUsage bits sounds interesting. This could be used 
> to specify that only certificates used to verify signatures 
> (i.e., keyUsage of digitalSignature and/or nonRepudiation) are listed after 
> expiration. I can't think of any compelling reason to include key management 
> certificates after they have expired. 

OK.

> However, I'm not sure if the benefit is worth the increased complexity.

Every time an new extension is added, an additional piece of software is
needed to handle it. Yes, this is debatable, but the problem we currently
have, is that the only current way to know that certificates are still
maintained in the CRL after they expire is by using the PDS, which is not
machine processable. When PDS are used, the time certificates are maintained
in the CRL after they expire cannot be changed very often.
 
> I would also suggest a slight re-wording of the meaning of the extension 
> to "this CRL lists all revoked certificates that have expired within the 
> last Y weeks (in addition to all unexpired revoked certificates)."
> The extension should only specify what is included in that particular CRL, 
> it should not make any promises about what is included in other CRLs. 
> The CRL issuer should always be free to expand or shrink the set of 
> expired certificates covered by its CRLs.

I agree. The time may vary from one CRL to the next, so it allows to change
the policy over time.

Denis