Subject: RE: Complete CRLs with expired certs?

From: Carl Wallace <[email-masked]>
Date: Mon, 23 Oct 2006 07:22:30 -0400

FYI, the LTANS draft referenced earlier in this (or a related) thread
recently expired.  It defined a variation on the X.509 expiredCertsOnCRL
extension that preserves the thisUpdate < time of interest < nextUpdate
property for CRLs containing expired certs.  The mechanism is similar to
expiredCertsOnCRL but the time value in the extension represents the time
the CRL was generated instead of the low water mark for the inclusion of
expired certs.  The draft can be found here:
http://tools.ietf.org/wg/ltans/draft-ietf-ltans-pki-retention/draft-ietf-lta
ns-pki-retention-00.txt  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David A. Cooper
> Sent: Monday, October 02, 2006 5:08 PM
> To: Vittek Robert
> Cc: pkix
> Subject: Re: Complete CRLs with expired certs?
> 
> 
> 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.
> 
> Vittek Robert wrote:
> > 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?
> >
> >
> >
> > 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
> 
>