Subject: RE: Removing expired certificates from CRLs.....

From: Sharon Boeyen <[email-masked]>
Date: Mon, 10 Sep 2001 10:09:57 -0400

Tim, I like this proposal because of its simplicity and given all the other
variable ways we have to set up CRLs, I suspect this, combined with them,
gives more than enough flexibility. Does this need to be a new extension on
its own? It could be, or it could be added as an additional parameter to the
IDP extension. That might be even simpler - thoughts?

As for the different groups, if there is going to be a new extension of this
sort, I'd like it to be added to 509 and profiled by PKIX, if possible. If
the PKIX groups reaches consensus on what they want quickly enough, that
input can be submitted on behalf of PKIX to the 509 meeting later this
month. The timing is very good this time.

Cheers,
Sharon

> -----Original Message-----
> From: Tim Polk [mailto:[email-masked]]
> Sent: Friday, September 07, 2001 5:20 PM
> To: Denis Pinkas; Tom Gindin
> Cc: IETF-PKIX
> Subject: Re: Removing expired certificates from CRLs.....
> 
> 
> 
> Denis, Tom, et al.
> 
> As one of several independent originators of the idea, 
> (Ambarish Malpani is 
> another), I thought I ought to weigh in as well.  I had something 
> *considerably* simpler in mind.  If a CRL includes revocation 
> information 
> for certificates that have expired, a relying party should be able to 
> determine that automatically.
> 
> I would suggest a noncritical CRL extension with a single 
> value of type 
> GeneralizedTime.   The ASN.1 syntax would be
> 
> 	ExpiredCertsOnCRL ::= GeneralizedTime
> 
> As usual with PKIX times, we would require time Zulu with 
> seconds (even if 
> zero).
> 
> The semantics for the extension would be as follows:
> 
> 	The scope of a CRL containing this extension is 
> extended to include 
> certificates that expired  at the exact time specified in the 
> extension or 
> after that time.  If limitations in the CRL's scope are specified (by 
> either reason codes or by distribution points), that applies 
> to expired 
> certificates as well.
> 
> IMHO, we shouldn't make the scope of a CRL different for expired and 
> unexpired certificates.  This is a simple idea - let's keep 
> it that way!
> 
> BTW, folks were wondering why this hasn't been pursued in 
> PKIX.  This idea 
> has been floated a couple of times, but no one was really ready to 
> implement it.  We needed to concentrate on the core functionality.  I 
> floated the idea again at one of the meetings (in San Diego?) 
> and Ambarish 
> said he'd had the same idea and wanted to pursue it.  I asked 
> him to delay 
> any new work in this area until the son-of-2459 is approved by the 
> IESG.  (Neither of us realized what a long delay we'd agreed to...)
> 
> Thanks,
> 
> Tim Polk
>

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 10 Sep 2001 16:19:23 +0200

Sharon,

> Tim, I like this proposal because of its simplicity and given all the
> other variable ways we have to set up CRLs, I suspect this, combined with
> them, gives more than enough flexibility. Does this need to be a new
> extension on its own? It could be, or it could be added as an additional
> parameter to the IDP extension. That might be even simpler - thoughts?

As implictly said in my e-mail from this morning, I am in favour of an
independant extension, so that we do not mandate the use of IDP to have that
additional feature. In other words, if the extension were part of IDP, a
single big CRL could not benefit of that advantage.

Denis

> As for the different groups, if there is going to be a new extension of
> this sort, I'd like it to be added to 509 and profiled by PKIX, if
> possible. If the PKIX groups reaches consensus on what they want quickly
> enough, that input can be submitted on behalf of PKIX to the 509 meeting
> later this month. The timing is very good this time.
> 
> Cheers,
> Sharon
>