Problem - Kevin Tafuro

they learn about key compromises. Included in the revocation list is the date and
time that the next update will be published, so once an application has downloaded
the list, it does not need to do so again until the one it has expires. Clients are
encouraged to cache the information, but doing so may not be feasible if the client
has limited storage space.
This scheme could leave a window of vulnerability during which the CA knows
about a revoked certificate, yet the client does not. If a CA publishes the list too frequently,
it will require massive amounts of bandwidth to sustain the frequent
demand for the list. On the other hand, if a CA publishes the list too infrequently,
certificates that need to be revoked will still be considered valid until the next list is
published. Each CA needs to strike a balance with the community it is serving to
determine how frequently to publish its list.
One solution to this problem is for the CA to break up its CRLs into segments. To
do this, the CA specifies ranges of certificate serial numbers that each CRLwould
contain. For example, the CA could create a different CRLfor each 1,000 serial numbers.
Therefore, the first CRLwould be for serial numbers 1 through ,1000; the second
would be for serial numbers 1,001 through 2,000; and so on. This solution does
require forethought and planning on the part of the CA, but it reduces the size of the
CRLs that the CA issues. Another solution is to use “delta CRLs,” where a CA periodically
publishes incremental changes to its CRLlist. Delta CRLs still require the
client to cache CRLinformation or to download everything anew each time a certificate
needs to be validated.
Another problem with CRLs is that while there is a standard means to publish them
(formally specified in RFC 3280), that mechanism is optional, and many of the more
common public CAs (e.g., VeriSign) do not distribute their CRLs this way. There are
also other standard methods for distributing CRLs, but the overall problem is that
there is no single method, so many software applications do not actually make use of
CRLs at all. Of the various methods of distribution, LDAP is most commonly used as
a repository for CRLs.
Yet another problem is that multiple applications on the same machine or even the
local network could be interested in the same data and require it to be queried from
the CA multiple times within a short period.
Problems with the distribution of CRLs currently make them difficult to manage,
and what is worse, few applications even make the attempt. This essentially makes
CRLs useless and leaves no way for a CA to revoke a certificate effectively once it has
been issued. Ideally, CAs need to standardize on a method for distribution, and both
CAs and applications need to start making use of it.
Another potentially serious problem that has not been addressed is what happens
when a root CA’s certificate needs to be revoked. A CRLis not suited to handle this,
and neither are applications. The reason is that a parent (a CA) issues CRLs for its
children, but a root CA has no parent. It is possible for a CA to revoke its own certifi-
508 | Chapter 10: Public Key Infrastructure
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.