[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Light-weight certificate revocation lists ?
> From: "Brian M. Thomas" <bt0008@entropy.sbc.com>
> > 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.
Yes you can, you simply retrieve it from the source.
Surely different applications will have very different security and
communications requirements. It would be foolish to restrict these
unnecessarily when developing a generic infrastructure.
Applications with high security requirements (or perhaps ones in which
the effect of a transaction cannot be undone) may consider the overhead of
checking CRLs at source worthwhile. Others, where the effects of the
transaction can be undone, may not bother and are satisfied with either
the validity times in the certificate, or the last scheduled CRL.
Cheers,
Michael Warner
Telstra Research Labs
Melbourne, Australia
>
> 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
>