Re: Removing expired certificates from CRLs.....

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Tim,

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

We strongly agree on that statement.

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

As Tom said, in practice we would expect certificates with the DS bit set
with a retention period of two or three days, while certificates with the NR
bit set with a retention period of about one month. For other certificates,
it would be the next *scheduled* CRL after revocation.

An option is to say that all certificates from a CRL are maintained for a
fixed time, e.g. one month more. This does not increase the size of CRLs
indefinitively and, as Tim says, is simple enough. 

If different retention periods are needed, there is still a solution, but
there is a price to pay: use CRL Distribution Points with different reason
codes. This means that certificates must originally be produced with this
feature. If there aren't ... then this is not possible.
 
I can buy that simplicity, as long as we include such explanations in the
text.

Denis

> 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