Subject: Re: Complete CRLs with expired certs?

From: "Denis Pinkas" <[email-masked]>
Date: Mon, 2 Oct 2006 16:44:04 +0200

In order to complement, but correct the sentence : "listing expired certificates on a CRL is OK".

PKIX does not currently support the new X.509 extension mentionned hereafter.

PKIX compliant CRLs shall include the serial number of expired certificates 
one time more after the expiration date of the certificate (placing delta CRL 
aside for simplicity).

They might last it longer, but then there is no garantee that the revoked certificates 
serial numbers are present, (unless the new X.509 extension is being used), 
so if maintained longer, PKIX compliant CRLs cannot be used to know whether 
a given certificate was revoked or not, once that certificate has expired.

As a conclusion:  "listing expired certificates on a PKIX compliant CRL is useless".

Denis

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

Regards,

Denis Pinkas

---

From: "Vittek Robert" <[email-masked]>
Date: Mon, 2 Oct 2006 20:53:23 +0200

I do not think that "listing expired certificates on a PKIX compliant CRL is useless".

rfc 3280 states in chapter 3.3: An entry MUST NOT be removed
   from the CRL until it appears on one regularly scheduled CRL issued
   beyond the revoked certificate's validity period.

on the contrary to obsoleted rfc 2459 which stated just: An entry may be removed from
   the CRL after appearing on one regularly scheduled CRL issued beyond
   the revoked certificate's validity period.

and thus allowing CAs to remove revoked certificates entries from CRLs sooner.

Assume a signature made at time T (as claimed by an attached time stamp). Assume the signing certificate was revoked at time T-X (this value should appear in revocationDate on next CRL), e.g. for key compromise reason. And assume the certificate expired soon after the time T, let's say T+M. At time T+M+N new regular CRL_n is issued. CRL_n conformant with rfc 3280 allows to correctly reject such a signature, while CRL_n conformant with (obsoleted) rfc 2459 might not even list such cerificate.

IMHO, there is still a problem if a signature validation application is temporarily unable to fetch CRL_n (e.g. for troubles with connectivity) and fetches only the next CRL_n+1 which though not issued on a regular basis was still issued before the nextUpdate of the last CRL in application's CRL cache. If CRL_n+1 does not list the certificate in question any more then the application is not able to say if the certificate was valid at time T or not. Unfortunately, the same is applicable to CRL_n, if n > the number of last cached CRL (CRL numbers do not have to be increased by 1).

I think that incorporating ArchiveCutOff extension from OCSP protocol (rfc 2560) to CRL profile could help solve this issue. This still gives CAs possibility to decide on the length of the retention period.

Robert Vittek

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Denis Pinkas
Sent: Monday, October 02, 2006 4:44 PM
To: [email-masked]
Subject: Re: Complete CRLs with expired certs?

PKIX compliant CRLs shall include the serial number of expired certificates one time more after the expiration date of the certificate (placing delta CRL aside for simplicity).

They might last it longer, but then there is no garantee that the revoked certificates serial numbers are present, (unless the new X.509 extension is being used), so if maintained longer, PKIX compliant CRLs cannot be used to know whether a given certificate was revoked or not, once that certificate has expired.

Denis

>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.
>
>--Peter
>
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Michael Ströder
>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?
>

Regards,

Denis Pinkas

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 02 Oct 2006 17:07:34 -0400

There is no need to incorporate the ArchiveCutOff extension in the CRL 
profile.  The expiredCertsOnCRL extension has already been defined in 
X.509 achieves the same goal.

As Peter Hesse noted, the expiredCertsOnCRL extension is a non-critical 
CRL extension that consists of a GeneralizedTime value.  The semantics 
are that the CRL lists all revoked certificates within the scope of the 
CRL that are either unexpired or that expired at the time specified in 
the extension or later.  So, if CRLs cover all expired certificates, 
each CRL can specify the same time (any time that is earlier than when 
the first certificate expired).  If the retention period is limited, 
each CRL can specify a different time (e.g., expiredCertsOnCRL = 
thisUpdate - 1 year if CRLs continue to cover certificates for one year 
after they expire).

I would also like to see this extension profiled within the IETF.  In 
fact, there are other extensions that I would like to see either defined 
or profiled within the IETF.  However, it has generally been agreed that 
it would not be appropriate to include new extensions in 3280bis.  Any 
new extensions would have to appear in a new I-D. While I would be 
willing to participate in the development of such an I-D, I would not be 
able to do so until after 3280bis is complete.

Dave

P.S.  I would technically disagree with the statements about "PKIX 
compliant CRLs".  RFC 3280 (section 5.2) says:

     The following subsections present those extensions used within Internet
     CRLs.  Communities may elect to include extensions in CRLs which
     are not defined in this specification.  However, caution should be
     exercised in adopting any critical extensions in CRLs which might be
    used in a general context.

So, while it is true that no IETF document mentions the 
expiredCertsOnCRL extension, RFC 3280 does not prevent a conforming CRL 
issuer from including this extension in CRLs nor does it prevent 
conforming clients from processing the extension.  But, I would agree 
that without the expiredCertsOnCRLs extension there is very little 
benefit to including expired certificates on CRLs except in environments 
where clients can rely on out of band knowledge that CRLs cover expired 
certificates.