RE: Complete CRLs with expired certs?

["Vittek Robert" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Denis Pinkas
Sent: Monday, October 02, 2006 4:44 PM
To: [e-mail]
Subject: Re: Complete CRLs with expired certs?



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

Regards,

Denis Pinkas