[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: CRLs versus short Validity periods
At 05:10 3/1/96, Frank O'Dwyer wrote:
>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.
I took that into account, as I mentioned to one previous person with the
same comment and discuss below. It shows up in the notation (fractional)
in my table.
>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.
I set the cert validity to be 2 days only in my case (0). In (a) and (b),
the cert was valid for 20 years and the CRL was valid for 2 days. In all 3
cases, of course, each user of each cert has to fetch something [ a cert,
a CR query or a CRL ] over the net every 2 days.
>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).
As I said, you're fetching *something* every 2 days. With the exception of
the example you gave above, this means the same level of net traffic no
matter which model you use. [could even be worse in case (b) with CRLs
being transmitted]
>This could
>get quite scary in terms of bandwidth when scaled to the internet.
As I said, TANSTAAFL. You get this number of fetches over the net
no matter which model you use.
-------------------------
The one departure from my model is the one you cited above -- with
VeriSign issuing a CRL covering its thousands of certificates and every
consumer of certificates caching VeriSign's CRL. In this case, the
verification of the CRL's signature and its receipt might be amortized
in the verifier over a number of different certificates.
This assumes one thing I don't necessarily agree with: that there will be
only a few CAs [few enough that any cert user is likely to have many hits
on each CA's CRL during the CRL validity period].
In my model of the future world, there will be a vanishingly small percentage
of certificates which are identity-based. The vast majority will be
attribute-based (Rivest's "type II") and those will be issued by owners
of the attribute being allocated. Every public key will become its own issuer
and each such issuer will generate only a few certificates. Therefore,
unless the CRL validity period is very long, the probability of a second hit
on a validated CRL is very small. Meanwhile, there will be as many issuers
(or more) as any cert verifier is likely to have certificates to verify
-- so it is not practical to cache the CRLs of each one. In fact, some
verifiers will be stateless code, in which case CRL's can not be cached
at all.
----------------------
However, your point is valuable. Much of this analysis depends on
the probability of multiple hit on the CRL. If that probability is high
for each verifier, then (b) could show a performance advantage over (0)
even for the Verifier and the net.
Thanks for pointing this out.
- 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 |
+--------------------------------------------------------------------------+
Follow-Ups: