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