[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: CRLs versus short Validity periods
cme@cybercash.com (Carl Ellison) wrote:
>So, doing a performance comparison between (0) [no CRLs], (a) and (b):
>
>
> (0) (a) (b)
>Network traffic 2 certs 2 certs 1 small; 1 CRL (large)
>Issuer signatures 1 cert 1 response (fractional)
>Verifier sig checks 1 cert 1 cert; 1 resp 1 cert; 1 CRL
Carl, one point that seems to be missing from that analysis is that CRLs
are per-issuer, not per-cert. A significant saving is possible if a server
deals with 1000s of certs from one issuer. For example, getting VeriSign's
CRL brings you up-to-date for all of VeriSign's certs. The cost of getting,
processing and verifying that CRL is effectively shared among all the
certificate uses covered by it, which can be very many. In other words,
that cost can tend to zero.
Also, whereas you've set the cert validity and CRL issuing frequency
to be the same (2 days), in a CRL scenario typically the cert. would be
valid much longer (e.g. ~1 year) than the CRL (<2 days seems
reasonable) in order to achieve long validity in the normal case with
reasonably timely revocation in the exceptional case.
In other words, with CRLs you'd get the cert (say) once per year
(assuming you had the resources to cache it all year), and the CRL
every 2 days or whatever window of vulnerability you'd like. You'd verify
the CRL every 2 days (or every boot of the service), and thereafter you
could verify as many certs as you like (1 every few seconds, say) _without_
needing to fetch or verify a new CRL (assuming you can securely cache
the processed & verified CRL, e.g. in memory).
A comparable non-CRL situation could have you (and everyone else on
the Internet) fetching and verifying 1000s of certs every 2 days to get the
same level of risk management (think of a commerce website). This could
get quite scary in terms of bandwidth when scaled to the internet. So it's
not quite so obvious that the no-CRL solution is always better. It looks
more like a tradeoff depending on the application profile, where the various
parameters would need to be tuned depending on the actual frequency of
revocations, size of user population, and so on.
In passing, 'pushing' the crl out (e.g. by sending out on a mailing list or
newsgroup) seems like a cheaper way of doing things than having everyone
pull it. Similarly for certs in the no-CRL model, it would be better to send
them to people who express an interest than to have everyone fetch them
(the first fetch could be like joining a mailing list). It would also be useful to
have a compact CRL/cert type which essentially meant 'no CRL change
since last time', or 'that certified information is still OK' since that could
turn out to be common.
Cheers,
Frank O'Dwyer.
fod@brd.ie
>which tells me that (0) is strictly better than (a) and that
>the comparison between (0) and (b) depends on the relative costs of
>network traffic and Issuer digital signature generation. If the Issuer
>is really hobbled by doing new signatures and if new entries are
>added to the CRL only very rarely, then (b) might win over (0).
>Otherwise, the extra network load and Verifier CPU load suggests that (0)
>is better than (b).
> - Carl
>
>+--------------------------------------------------------------------------+
>|Carl M. Ellison cme@cybercash.com http://www.clark.net/pub/cme |
>|CyberCash, Inc., Suite 430 http://www.cybercash.com/ |
>|2100 Reston Parkway PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
>|Reston, VA 22091 Tel: (703) 620-4200 |
>+--------------------------------------------------------------------------+