Cryptography Reference
In-Depth Information
VeriSign's current CRL, as an example, is 125K and includes more than 3600
certifi cates, some of which were revoked more than two years ago. The idea
behind CRLs is that a user downloads each trusted CA's CRL on a periodic
basis. However, there's no real upper bound on how large a CRL may grow. It
might be reasonable to try to keep a handle on the size of the fi le by removing
a certifi cate from the CRL after its validity period had passed, but an actual
compromised certifi cate is a far greater security risk than one that is simply
expired. A compromised certifi cate should never be used, under any circum-
stances; an expired certifi cate may be used, if the receiver trusts the certifi cate
holder. As a result, it's necessary for the CA to keep a certifi cate on its CRL list
for a fairly long period of time. To keep the size of the download somewhat
manageable, the specifi cation allows the CA to distribute “delta” CRL's that only
include newly revoked certifi cates. This is still problematic, as the user of the
CRL has no way of knowing when it's safe to stop keeping track of an expired
certifi cate, whereas the CA knows, for instance, that a certifi cate expired six years
ago and can probably be safely removed from the list. The downloader only
knows the serial number of the certifi cate; he has no way of knowing whether
it was revoked 10 years ago or last Tuesday.
You may be wondering where to go to fi nd the CRL associated with a CA.
It would seem reasonable that the location of the CRL would be set up when
the CA itself was listed as trusted, but this doesn't allow a CA to move its CRL
location, ever. The X.509 certifi cate form has an extension that allows the CA to
indicate where the CRL ought to be downloaded from. This does introduce one
potential confusion, though: The extension doesn't permit the CA to indicate
the date that the CRL distribution point changed. Remember that the CRL is
associated with the CA that signed the certifi cate. If the client downloads two
certifi cates signed by the same CA, but with two different CRL URLs, which one
should be used? There are no clear guidelines in the specifi cations. This isn't a
problem if you don't mind downloading the entire CRL each time you want to
validate a certifi cate, but it can be a problem if you're trying to use deltas or if
the CRL distribution point is temporarily unreachable.
How does the legitimate holder of a certifi cate inform a CA that a certifi cate
is compromised and should be revoked? The CSR format described earlier
includes an optional attributes section in which the requester can provide a
challenge password
that must be supplied at any later time in order to perform
subsequent certifi cate management, including revocation.
Keeping Certifi cate Blacklists Up-to-Date with the
Online Certifi cate Status Protocol (OCSP)
As detailed in the previous section, there are quite a few problems with using
CRLs as a means of notifying consumers of the revocation of certifi cates. In
Search WWH ::
Custom Search