Re: when can an entry not appear on a CRL?

[Mary_Ellen_Zurko@xxxxxxxx]

Thanks Al.

>  You are correct, the purpose of the requirement as worded is to
> ensure
> that the revoked certificate appears on at least one
> regularly-scheduled
> CRL.  The additional thought is that even if there are on-demand CRLs,
> relying parties should still be getting regularly-scheduled CRLs as
> well as
> the on-demand ones.

So, if they're posted in LDAP, either on-demand ones are posted
somewhere different, or regularly scheduled ones are not
flushed when on-demand ones are posted, so that they are
still available, and someone the relying party can figure out
which is which (and I don't quite see how they would, as I haven't
read the LDAP schema doc; maybe that answers all my questions).

> Thus, all relying parties will see the revocation
> notice from the regularly-scheduled CRLs.  (You can do this by
> setting the
> next-issue date in the on-demand CRL to be the date of the next
> regularly-scheduled CRL.)

They'd see the next regularly scheduled CRL, but not the previous
one (if it had been overwritten), right? And it's the previous one
I'm worried about. Or did I miss something here? I certainly agree
that the next-issue date for any on-demand CRLs should be the
same as the next-issue date for the currently outstanding regularly
issued CRL.

>  That is:  suppose that regularly-scheduled CRL  R1 is issued on 15
> December; on-demand CRL O is issued on 17 December; and regularly
> scheduled
> CRL R2 is issued on 22 December.  If a revoked certificate with an
> expiration date of 14 December is on R1, it doesn't matter whether or
> not
> it's on O, as long as all relying parties will see R1.

But how can you be sure that all relying parties will see R1? Am I
missing something obvious? Say R1 is issued on December 15,
through LDAP. But because of concerns about latency and network
connectivity, CRL R0's NextUpdate date is December 18 (because
you have to absolutely get the next CRL out by the NextUpdate
date, otherwise you have no valid CRL and everything grinds to
a halt if it cares). So _if_ CRL 0 overwrites CRL R1, there's an
issue. Which maybe gets me back to reading the LDAP
schema, which may have some policy about what overwrites
what and what gets cleaned up when and how to tell the
difference between different CRLs.

> of certificate expiration.  For historical purposes, there will be a
> formal
> record of the certificate having been revoked, at a bare minimum on
> R1, so
> transactions dated between 15 December and 17 December but being
> processed
> after the fact can be rejected due to R1.

So, all the CRLs are always around and available, and there's some
way to tell the difference between regularly scheduled and on-demand
ones (which I don't quite get as both could be issued before the previous
NextUpdate date).

As always, I'm sorry if I'm taking up airspace with obvious stuff.

     Mez