RE: Complete CRLs with expired certs?

["Peter Hesse" <[e-mail]>]

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:[e-mail]] 
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:
>
>    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                     [e-mail]     |
> | Phone: [phone] 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: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Michael Ströder
> Sent: Monday, October 02, 2006 5:49 AM
> To: [e-mail]
> Subject: Complete CRLs with expired certs?
>
>
> 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.