[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Light-weight certificate revocation lists ?

> I don't mind making provisions for CRLs, but they are an
> extraordinarily limited tool unless you impose very tight constraints
> on the ways that certificates are used, and even then, an adversary
> can probably prevent you from getting a CRL far more easily than they
> could otherwise interfere with you.


My biggest objection - and this pretty much accords with Carl's point
of view, I think, but I like to state it differently - is that I *never
know* whether the CRL I have is the latest one.  I can know if it's
expired (meaning due to be superceded), but I *cannot* know whether
there is another.  This puts a lower bound on the effective validity
interval.   I can have, as we do, a policy that says I don't accept a
chain if I don't have CRLs from all issuers, but that puts a real-time
load on the network that I'd like to avoid or can't afford, as in
Perry's examples, and I still can't know if what I get is really the
latest.  Far better to use short expiry.

This, unfortunately, brings up the problem of recertification, which is
where I think SPKI, especially coupled with PolicyMaker, really shines.
If the recertification question can be answered by an automated process,
as PolicyMaker facilitates, it becomes a much smaller problem.


Brian Thomas, CISSP - Distributed Systems Architect  bt0008@entropy.sbc.com
Southwestern Bell                                    bthomas@primary.net
One Bell Center,  Room 34G3                          Tel: 314 235 3141
St. Louis, MO 63101                                  Fax: 314 235 0162