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

From: [email-masked]
Date: Tue, 15 Dec 1998 09:10:31 -0500

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

---

From: Al Arsenault <[email-masked]>
Date: Wed, 16 Dec 1998 10:28:57 -0500

>read the LDAP schema doc; maybe that answers all my questions).

AWA: From the PKIX LDAP schema doc:

"The certificateRevocationList attribute, if present in a particular CA's
entry, contains CRL(s) as defined in draft-ietf-pkix-ipki- part1-08.txt."

 This attribute is multi-valued, which means it can hold more than one CRL
at a time.  (I trust that Sharon B.will correct me if I'm wrong, but I
believe that it's the end-entity's problem to figure out which is the right
one.)  You don't have to delete a regularly-scheduled CRL when you post a
new one; you can leave a CRL in the system for some period of time until
you're convinced it's not relevant except for historical purposes.  

The actual PKIX LDAP schema doc and PKIX LDAP doc are silent on how/when to
delete old CRLs.  I'm assuming that was intentional, to let individual
implementors decide on their own policies.

<snip>
>difference between different CRLs.

AWA:  The schema doc doesn't have any policy on this that I can find
(apologies if I've once again missed something obvious).  Yes, if you
automatically overwrite old CRLs with new ones, you're going to have a
problem, and you'll probably have to adjust your CRL strategy accordingly
(e.g., you might have to mandate that certs are not dropped from on-demand
CRLs).

There's also the problem of reality popping up.  There will be, in any
sufficiently large real network, relying parties that do not get CRLs in a
timely fashion for one reason or another.  That's part of the risk of using
CRLs - if the user hasn't gotten the new CRL, R1, and the cert in question
is on R1 but not on its predecessor R0, and R0 is still a valid CRL, then
the user will do something he/she shouldn't.  If that risk is unacceptable
in your situation, then you need to go to a more proactive revocation
system (e.g., force the user to explicitly check for a new CRL before
accepting each transaction; add OCDP or OCSP support; or whatever.)

				Al Arsenault

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

This stuff ain't so obvious. Most people would be surprised at the amount
of time and effort it takes to think through this stuff and get everything
(even sort-of) right.  The first PKI I worked on has been operational for
over 3 and a half years, and they're still learning new little things.  And
we spent a lot of time before going operational trying to figure out all of
the system design and operational procedures issues, too.

					Al Arsenault