Problem - Kevin Tafuro

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 responder available, it is generally
best to use the technology to supplement CRLs rather than to replace them
completely.
OCSP introduces a significant potential for three types of attacks:
Denial of service 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; note, however, that OCSP responders are typically more susceptible to
these attacks than are other common services such as HTTP, for example.
Replay attacks
The OCSP Version 1 specification allows responders to preproduce signed
responses in an effort to reduce the load on the responder required by signing
definitive responses. Allowing for preproduced signed responses opens the door
for replay attacks.
Man-in-the-middle attacks
Man-in-the-middle attacks are possible because error responses are not signed.
Note that it is possible to consider this type of attack a denial of service attack.
Perhaps what is most disturbing about these vulnerabilities is the fact that although
the RFC notes each one nothing was done to prevent them when formalizing the
standard.
There are only a handful of public OCSP responders available at the time of this writing,
as listed by OpenValidation.org. The small number of responders is a clear indication
that OCSP is not widely deployed. While it 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 a replacement for CRLs. In its defense, an IETF draft was submitted in
March 2001 for Version 2 of the protocol, which addresses some of the issues, but
this has not yet completed the standards process, and is far from being deployed.
We cover use of OCSP using OpenSSL in Recipe 10.12.
Certificate hierarchies
A certificate that is issued by a CA can be used to issue and sign another certificate, if
the issued certificate is created with the appropriate permissions to do so. In this
way, certificates can be chained. At the root of the chain is the root CA’s certificate.
Because it is at the root of the chain and there is no other authority to sign its certificate,
the root CA signs its own certificate. Such a certificate is known as a self-signed
certificate.
Understanding Public Key Infrastructure (PKI) | 511
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.