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

[Al Arsenault <aarsenault@xxxxxxxxxx>]

At 09:10 AM 12/15/98 -0500, Mary_Ellen_Zurko@iris.com wrote:
>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).
>


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

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

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