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

Frank O'Dwyer.

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