21.03.2013 Views

Problem - Kevin Tafuro

Problem - Kevin Tafuro

Problem - Kevin Tafuro

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

they learn about key compromises. Included in the revocation list is the date and<br />

time that the next update will be published, so once an application has downloaded<br />

the list, it does not need to do so again until the one it has expires. Clients are<br />

encouraged to cache the information, but doing so may not be feasible if the client<br />

has limited storage space.<br />

This scheme could leave a window of vulnerability during which the CA knows<br />

about a revoked certificate, yet the client does not. If a CA publishes the list too frequently,<br />

it will require massive amounts of bandwidth to sustain the frequent<br />

demand for the list. On the other hand, if a CA publishes the list too infrequently,<br />

certificates that need to be revoked will still be considered valid until the next list is<br />

published. Each CA needs to strike a balance with the community it is serving to<br />

determine how frequently to publish its list.<br />

One solution to this problem is for the CA to break up its CRLs into segments. To<br />

do this, the CA specifies ranges of certificate serial numbers that each CRLwould<br />

contain. For example, the CA could create a different CRLfor each 1,000 serial numbers.<br />

Therefore, the first CRLwould be for serial numbers 1 through ,1000; the second<br />

would be for serial numbers 1,001 through 2,000; and so on. This solution does<br />

require forethought and planning on the part of the CA, but it reduces the size of the<br />

CRLs that the CA issues. Another solution is to use “delta CRLs,” where a CA periodically<br />

publishes incremental changes to its CRLlist. Delta CRLs still require the<br />

client to cache CRLinformation or to download everything anew each time a certificate<br />

needs to be validated.<br />

Another problem with CRLs is that while there is a standard means to publish them<br />

(formally specified in RFC 3280), that mechanism is optional, and many of the more<br />

common public CAs (e.g., VeriSign) do not distribute their CRLs this way. There are<br />

also other standard methods for distributing CRLs, but the overall problem is that<br />

there is no single method, so many software applications do not actually make use of<br />

CRLs at all. Of the various methods of distribution, LDAP is most commonly used as<br />

a repository for CRLs.<br />

Yet another problem is that multiple applications on the same machine or even the<br />

local network could be interested in the same data and require it to be queried from<br />

the CA multiple times within a short period.<br />

<strong>Problem</strong>s with the distribution of CRLs currently make them difficult to manage,<br />

and what is worse, few applications even make the attempt. This essentially makes<br />

CRLs useless and leaves no way for a CA to revoke a certificate effectively once it has<br />

been issued. Ideally, CAs need to standardize on a method for distribution, and both<br />

CAs and applications need to start making use of it.<br />

Another potentially serious problem that has not been addressed is what happens<br />

when a root CA’s certificate needs to be revoked. A CRLis not suited to handle this,<br />

and neither are applications. The reason is that a parent (a CA) issues CRLs for its<br />

children, but a root CA has no parent. It is possible for a CA to revoke its own certifi-<br />

508 | Chapter 10: Public Key Infrastructure<br />

This is the Title of the Book, eMatter Edition<br />

Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!