43
was that Microsoft never requested these certificates—someone claiming to represent Microsoft did. VeriSign handled the situation in the appropriate manner and published the serial numbers of
the certificates in a new CRL. What really demonstrated the flaws with CRLs was how Microsoft handled the situation. It quickly became clear that Microsofts software, while distributing
VeriSigns root certificates and using their services, did not check VeriSigns 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. Had Microsofts 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 VeriSigns publication of its CRL minus the inherent window of vulnerability.
It could be argued that if a major software company like Microsoft cant handle CRLs properly, how can smaller software companies and individual software developers be expected to handle
them properly? While the argument may very well be faulty in a number of respects, it is still a question worth asking, and in truth, the answer, at least for right 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 weve discussed here, but others that we leave as an exercise for the reader to
explore as well. While CRLs may not be the ultimate answer to revoking a certificate, for the time being, they are the most widely implemented means by which to do so. Its 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 CRL specification has changed over time, and both the old format Version 1 and the new format Version 2 are actively used. OpenSSL supports 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 offers is extensions. The standard defines four extensions that are used primarily to indicate when
a certificate was revoked, why a certificate was revoked, and how to handle a certificate that has been revoked.
The fourth standard extension is used in indirect CRLs. An indirect CRL is one that is not necessarily issued by a CA, but instead by a third party. Such a CRL can contain certificates from
multiple CAs. The extension, then, is used to indicate which CA issued the certificate that has been revoked. Currently, indirect CRLs are not very common, because CRLs in Version 2 format
are not widely supported.
3.1.5 Online Certificate Status Protocol
The Online Certificate Status Protocol OCSP, formally specified in RFC 2560, is a relatively new addition to PKI. Its primary aim is to address some of the distribution problems that have
traditionally plagued CRLs.
Using OCSP, an application makes a connection to an OCSP responder and requests the status of a certificate by passing the certificates serial number. The responder replies good, revoked, or
unknown. A good response indicates that the certificate is valid, so far as the responder knows. This does not necessarily mean that the certificate was ever issued, just that is hasnt been revoked.
A revoked response indicates that the certificate has been issued and that it has indeed been revoked. An unknown response indicates that the responder doesnt know anything about the
certificate. A typical reason for this response could be that the certificate was issued by a CA that is unknown to the responder.
An OCSP responder is typically operated by a CA or by a trusted third party that is authorized by the CAs for which it provides information. The client must trust the OCSP responder in a manner
similar to a root CA. More importantly, there is only one way to revoke an OCSPs trusted status, and its not pretty. If an OCSP responder is compromised, every client that makes use of that
44
responder must be reconfigured manually either not to trust it or to use a new certificate that can be trusted.
A clients request includes information about the issuer of the certificate it is requesting status information for, so it is possible for a single OCSP responder to provide certificate revocation
information for more than a single CA. Unfortunately, one of the problems of OCSP responders when run by a third party is that the information theyre serving can become stale. At the very least,
a delay often occurs between the time when a CA revokes a certificate and when the responder receives the information from the CA, particularly if the responder is relying on CRLs published
by its serviceable CAs to supply its information.
Currently, OCSP is not nearly as widely recognized or implemented as CRLs are, so unless you know that all your users will have an OCSP server available, it is generally best to use the
technology to supplement CRLs rather than replace them completely.
Three of the more significant problems that OCSP introduces are the potential for denial of service, replay, and man-in-the-middle attacks. Most servers are vulnerable to denial of service attacks to
some extent, but the nature of the service, the amount of information transferred, and the way requests are handled help determine just how vulnerable a given server is to such an attack. The
details of denial of service attacks are beyond the scope of this book; however, OCSP responders are typically more susceptible to them than other common services such as HTTP.
The OCSP Version 1 specification allows responders to pre-produce signed responses in an effort to reduce the load on the responder required by signing definitive responses. Allowing for pre-
produced signed responses opens the door for replay attacks. Man-in-the-middle attacks are possible because error responses are not signed, although this type of attack could more accurately
be considered a denial of service attack. Perhaps whats most disturbing about the aforementioned vulnerabilities is the fact that each one is noted in the RFC, yet nothing was done when
formalizing the standard to prevent them.
There are only a handful of public OCSP responders available at the time of this writing, as listed by
www.OpenValidation.org . The small number of responders is a clear indication that OCSP is
not widely deployed. While OCSP is an attempt at resolving the problems of CRLs, we feel that the additional problems it creates, at least in its current state, outweigh the problems that it solves.
Certainly, it cannot be reasonably considered as a replacement for CRLs. In its defense, there was an IETF draft submitted in March of 2001 for Version 2 of the protocol, which addresses some of
the issues, but this has not yet completed the standards process.
3.2 Obtaining a Certificate
Before obtaining a certificate, you first need to determine what purpose the certificate will serve. There are many different types of certificates offered by a variety of CAs, both public and private.
For the purposes of this discussion, we will investigate what is necessary to obtain three different types of certificates from a public CA. While it is certainly not the only public CA, weve chosen
VeriSign as the CA that well obtain a certificate from because it is perhaps the most established public CA and offers the widest variety of certificates for a variety of uses.
As we mentioned, there are many different types of certificates, each used for different purposes. VeriSigns offerings range from personal certificates for use with SMIME to enterprise solutions
that are more sophisticated. Well find out how to get a personal certificate for SMIME, a code- signing certificate for signing your software so that users can verify that it came from you, and a
certificate for securing your web site for applications such as e-commerce.
