Subject: Complete CRLs with expired certs?

From: Michael Ströder <[email-masked]>
Date: Mon, 02 Oct 2006 11:49:08 +0200

HI!

Hope this hasn't discussed before:

Section 5 of RFC 3280 (and draft-ietf-pkix-rfc3280bis-04) states:

   A complete CRL lists all unexpired certificates, within its scope,
   that have been revoked for one of the revocation reasons covered by
   the CRL scope.  A full and complete CRL lists all unexpired
   certificates issued by a CA that have been revoked for any reason.

What I'm looking at is "lists all unexpired certificates". Is this a
MUST, SHOULD or a "MUST at least list all unexpired certificates"? Is it
compliant with PKIX to also list expired certificates in the complete CRL?

Would it be possible to generate two complete CRL lists,
1. one containing only unexpired and revoked certificates and
2. another containing expired and revoked certificates?

CRL 2. would preserve the time a particular cert was revoked even after
expiration of this cert.

Ciao, Michael.

---

From: "Peter Hesse" <[email-masked]>
Date: Mon, 2 Oct 2006 09:34:16 -0400

Michael,

My impression has always been that listing expired certificates on a CRL is
OK; in fact the section on Delta CRLs (5.2.4) makes this clear:

   If a certificate revocation notice first appears on a delta CRL, then
   it is possible for the certificate validity period to expire before
   the next complete CRL for the same scope is issued.  In this case,
   the revocation notice MUST be included in all subsequent delta CRLs
   until the revocation notice is included on at least one explicitly
   issued complete CRL for this scope.

The "at least one" at the end of that paragraph seems to make it
permissible.  If it read "exactly one" then I think having expired
certificates on your CRL would be against the standard.

The 2005 edition of X.509 includes an extension called expiredCertsOnCRL: 

	8.5.2.12 Expired certificates on CRL extension
	This CRL extension field indicates that the CRL includes revocation 
	notices for expired certificates.

		expiredCertsOnCRL EXTENSION ::= {
			SYNTAX ExpiredCertsOnCRL
			IDENTIFIED BY id-ce-expiredCertsOnCRL }

		ExpiredCertsOnCRL :: = GeneralizedTime

This all being said, including expired certificates on the CRL makes your
CRL larger.  A lot of organizations are doing everything they can to fight
this trend, including adopting OCSP.  Having two CRLs as you said -- perhaps
one with the above referenced extension -- would probably be your best bet.

--Peter

+----------------------------------------------------------------+
| Peter Hesse                     [email-masked]     |
| Phone: 703-378-5808 x105      Gemini Security Solutions, Inc.  |
| New! Visit our InfoSecurity industry blog: securitymusings.com |
+----------------------------------------------------------------+
"Security is mostly a superstition. It does not exist in nature...
 Life is either a daring adventure or nothing." --Helen Keller

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Michael Ströder
Sent: Monday, October 02, 2006 5:49 AM
To: [email-masked]
Subject: Complete CRLs with expired certs?

HI!

What I'm looking at is "lists all unexpired certificates". Is this a MUST,
SHOULD or a "MUST at least list all unexpired certificates"? Is it compliant
with PKIX to also list expired certificates in the complete CRL?

Would it be possible to generate two complete CRL lists, 1. one containing
only unexpired and revoked certificates and 2. another containing expired
and revoked certificates?

Ciao, Michael.

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 02 Oct 2006 11:26:46 -0400

Peter,

I agree that a compliant CRL issuer may include expired certificates on 
a CRL.  Expired certificates may be included in a CRL whether or not the 
expiredCertsOnCRL extension is included in the CRL. The 
expiredCertsOnCRL extension simply provides a way to inform relying 
parties that the scope of the CRL includes expired certificates.

I do not believe that there is currently a way to issue CRLs in the way 
that Michael suggested:  one that only covers unexpired certificates and 
one that only covers expired certificates.  A CRL MUST list "all 
unexpired certificates certificates, within its scope, that have been 
revoked for one of the revocation reasons covered by the CRL scope".  
So, the closest one could come would be to issue one CRL that only 
covers unexpired certificates and one that covers both expired and 
unexpired certificates.  While it would not be necessary to issue two 
CRLs, there is the risk that the CRL that covers expired certificates 
would grow very large and issuing two CRLs would ensure that most 
relying parties could use the smaller CRL that only covered unexpired 
certificates.  (Note that in order to be able to issue two CRLs where 
one CRL only covered expired certificates, it would be necessary to 
define a new CRL extension, and that extension would have to be marked 
as critical.)

There are a couple of ways that one could avoid the problem of CRLs 
becoming too large.  The first is to use CRL distribution points, with 
each distribution point covering a limited number of certificates.  The 
other option is to create a new CA every so often so that the number of 
certificates issued by any given CA is limited (one could continue to 
use the same hardware and software, but just issue under a different CA 
name and key pair).  In either case a CRL would initially cover only 
unexpired certificates, but over time all of the certificates covered by 
the CRL would expire at which point the CRL would only cover expired 
certificates.  Since these options would prevent CRLs from becoming too 
large, there would be no need to issue two CRLs during the transition 
period during which some certificates within the scope of a CRL are 
expired while others are still unexpired.

Dave

---

From: "Peter Hesse" <[email-masked]>
Date: Mon, 2 Oct 2006 11:30:10 -0400

You know, I mis-read what Michael had written. I agree that you would need
two CRLs: one with all revoked un-expired certificates, and the optional
second one with all revoked certificates including those that have expired.
And, as a general rule, I would point relying parties at the first one.

I did not mean to imply it was acceptable to issue a CRL containing only
expired certificates, I agree that there wouldn't be a safe way to
distinguish it from the "real" CRL.  

--Peter

-----Original Message-----
From: David A. Cooper [mailto:[email-masked]] 
Sent: Monday, October 02, 2006 11:27 AM
To: Peter Hesse
Cc: 'Michael Ströder'; pkix
Subject: Re: Complete CRLs with expired certs?

Peter,

I agree that a compliant CRL issuer may include expired certificates on a
CRL.  Expired certificates may be included in a CRL whether or not the
expiredCertsOnCRL extension is included in the CRL. The expiredCertsOnCRL
extension simply provides a way to inform relying parties that the scope of
the CRL includes expired certificates.

I do not believe that there is currently a way to issue CRLs in the way that
Michael suggested:  one that only covers unexpired certificates and one that
only covers expired certificates.  A CRL MUST list "all unexpired
certificates certificates, within its scope, that have been revoked for one
of the revocation reasons covered by the CRL scope".  
So, the closest one could come would be to issue one CRL that only covers
unexpired certificates and one that covers both expired and unexpired
certificates.  While it would not be necessary to issue two CRLs, there is
the risk that the CRL that covers expired certificates would grow very large
and issuing two CRLs would ensure that most relying parties could use the
smaller CRL that only covered unexpired certificates.  (Note that in order
to be able to issue two CRLs where one CRL only covered expired
certificates, it would be necessary to define a new CRL extension, and that
extension would have to be marked as critical.)

There are a couple of ways that one could avoid the problem of CRLs becoming
too large.  The first is to use CRL distribution points, with each
distribution point covering a limited number of certificates.  The other
option is to create a new CA every so often so that the number of
certificates issued by any given CA is limited (one could continue to use
the same hardware and software, but just issue under a different CA name and
key pair).  In either case a CRL would initially cover only unexpired
certificates, but over time all of the certificates covered by the CRL would
expire at which point the CRL would only cover expired certificates.  Since
these options would prevent CRLs from becoming too large, there would be no
need to issue two CRLs during the transition period during which some
certificates within the scope of a CRL are expired while others are still
unexpired.

Dave

Peter Hesse wrote:
> Michael,
>
> My impression has always been that listing expired certificates on a 
> CRL is OK; in fact the section on Delta CRLs (5.2.4) makes this clear:
>
> This all being said, including expired certificates on the CRL makes 
> your CRL larger.  A lot of organizations are doing everything they can 
> to fight this trend, including adopting OCSP.  Having two CRLs as you 
> said -- perhaps one with the above referenced extension -- would probably
be your best bet.
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Michael Ströder
> MUST, SHOULD or a "MUST at least list all unexpired certificates"? Is 
> it compliant with PKIX to also list expired certificates in the complete
CRL?
>
> Would it be possible to generate two complete CRL lists, 1. one 
> containing only unexpired and revoked certificates and 2. another 
> containing expired and revoked certificates?
>
> CRL 2. would preserve the time a particular cert was revoked even 
> after expiration of this cert.
>
> Ciao, Michael.

---

From: "Liaquat Khan" <[email-masked]>
Date: Mon, 2 Oct 2006 16:41:39 +0100

If a CA is continuing to list expired certificates this leads to some
ambiguity I think, i.e.:

- will it only continue to list those certificates which were revoked during
their lifetime and subsequently expired, or 
- will it also list those certificates which were only revoked subsequent to
their expiry? 

I would have thought generally CAs will want to avoid the second case above
(i.e. having to process revocation requests for certificates which have
expired)...I am not sure if there is a use case for wanting to revoke
already expired certificates? 

Regards,
LK

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Peter Hesse
Sent: 02 October 2006 14:34
To: 'Michael Ströder'; [email-masked]
Subject: RE: Complete CRLs with expired certs?

Michael,

--Peter

-----Original Message-----

HI!

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Mon, 09 Oct 2006 00:55:18 +0200

David,

David A. Cooper wrote:
> certificates.

This is exactly what I was planning to do. The large CRL would only be
used for validating archived digital signatures. But a product vendor
refused implementing that since he claimed it would not be compliant
with RFC 3280.

> (Note that in order to be able to issue two CRLs where

This is not what I was after.

> The first is to use CRL distribution points, with
> each distribution point covering a limited number of certificates.

But even in the ideal case this would divide the CRL by the reasons
flags. If the revocation reason is most times the same this does not
solve the problem. If you put different DistributionPointNames in there
client applications will likely retrieve and examine all CRLs => you win
nothing.

> The
> name and key pair).

Interesting point.

Ciao, Michael.