Problem - Kevin Tafuro

cate as long as it still has its private key. For purposes of signing a CRLcontaining its
own certificate, the CA’s compromised key can still be trusted. Unfortunately, given
the poor state of CRLhandling in existing software in general, it is not too likely that
this situation will be handled very well, if it is handled at all.
A classic example of how poorly CRLs are supported is what happened in early 2001
when VeriSign issued two class 3 code-signing certificates to Microsoft Corporation.
The problem was that Microsoft never requested the certificates—someone claiming
to represent Microsoft did. Given the process failure, VeriSign handled the situation
in the appropriate manner and published the serial numbers of the certificates in a
new CRL. Microsoft’s handling of the situation really demonstrated the flaws with
CRLs. It quickly became clear that Microsoft’s software, while distributing Veri-
Sign’s root certificates and using their services, did not check VeriSign’s CRLs.
Microsoft issued a patch to deal with the problem of the revoked certificates, but the
patch did nothing to fix the problem of their software not utilizing the CRLs at all; it
simply special-cased the bad certificates. Had Microsoft’s software made proper use
(or, arguably, any use at all) of CRLs, no patch would have been necessary and the
problem would have ended with VeriSign’s publication of its CRL(minus the inherent
window of vulnerability).
It could be argued that if a major software company like Microsoft can’t handle
CRLs properly, how can smaller software companies and individual software developers
be expected to do so? While this argument may be faulty in a number of
respects, it is still a question worth asking; the answer, at least for now, is not one
that we would all like to hear. PKI is still relatively immature, and much work needs
to be done to remedy not only the issues that we have discussed here, but also others
that we leave as an exercise for the reader to explore. While CRLs may not be the
ultimate answer to revoking a certificate, they are, for the time being, the most
widely implemented means by which to do so. It is worth taking the time to ensure
that your software is capable of dealing with the technology and provides for a reasonably
safe and pleasant experience for your users.
To complicate matters more, the standard CRLspecification has changed over time,
and both the old format (Version 1) and the new format (Version 2) are still actively
used. OpenSSLsupports both Version 1 and Version 2 CRLs, but there is much software
still in common use that does not yet support Version 2, and certainly old legacy
applications that are no longer being developed or supported never will, even
though they continue to be used. The major addition that Version 2 brings to the
table is extensions. The standard defines four extensions that are used primarily to
indicate the following:
• When a certificate was revoked
• Why a certificate was revoked
• How to handle a certificate that has been revoked
• How to deal with indirect CRLs
Understanding Public Key Infrastructure (PKI) | 509
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.