[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CRLs versus short Validity periods
This may be obvious to some folks, but I finally worked out a potential
performance advantage to not having CRLs. I'm including the PKIX list
and coderpunks because I expect people there to have given this much thought.
For this purpose, I imagine the following two certs:
----- BEGIN CERT -----
[...]
Validity: 199602280000, 199603010000 // 2 day validity
New-certs: <some URL> // where to get updated certs
[...]
----- END CERT -----
versus
----- BEGIN CERT -----
[...]
Validity: 199601010000, 201001010000 // long validity
CRLs: <some URL> // where to get CRLs
CRL-lifetime: 000000020000 // CRL validity length = 2 days
// the CRL-lifetime might be in the CRL itself
// instead of in each certificate
// I list it here to emphasize that it's 2 days
// so that the comparison is fair.
[...]
----- END CERT -----
If I assume I'm continually validating this cert, then I'll be able to keep
a cert on my list without having to do a network operation for 2 days, in
either arrangement.
At the end of 2 days, I need either to go get a new cert from the issuer
or I need to check the issuer's DB for a revocation of this cert.
If I get a new cert, then I need to describe the cert [e.g., send the old
one] and get back the new cert. This involves network traffic of one small
cert in both directions. [I envision a swarm of small certs hovering around
any given key rather than one huge cert.] The Issuer does one public key
signature. The Verifier does one signature check.
If I go the CRL route, then I have two choices:
(a) ask for the status of the given cert
(b) ask for a whole CRL.
In case (a), I send a small message [e.g., the cert], asking the Issuer
if it's still valid. The Issuer sends me either a revocation certificate
or a message to the effect that the current cert is valid. Either of
those has to be digitally signed by the Issuer. If there's a revocation,
then the Issuer signs it when it's created. If there's no revocation, the
Issuer must sign it specifically at the time of the request. The Verifier
then has to check two digital signatures -- one on the cert and one on
the Issuer's message. The network traffic in this case is probably
identical to that of the non-CRL case.
In case (b), I send an even smaller message, asking for the whole CRL,
and get back a potentially large message [the CRL]. The CRL as a whole
has to be signed only when it's created or modified -- so this option might
let the Issuer do fewer digital signatures. The Verifier needs to check
signatures on both the certificate and the CRL.
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
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 |
+--------------------------------------------------------------------------+
Follow-Ups: