Creating a Network of Trust Using X.509 Certifi cates - Implementing SSL/TLS Using Cryptography and PKI - page 296

addition to some of the management/ambiguity problems, there's also the prob-
lem of freshness. If a private key has been compromised, the potential users of
that certifi cate probably want to know about it right away. To accomplish this,
the client has to download the entire CRL, or at least a delta (if the CA supports
them) every time a new certifi cate is encountered. The Online Certifi cate Status
Protocol (OCSP) was developed to enable the client to look up the status of a
certifi cate by serial ID.
The details can be found in RFC 2560 and aren't covered in depth here. The
user supplies the serial number of the certifi cate along with a hash of the issuer's
distinguished name as well as its public key. The issuer name and public key
are included so that a single OCSP can report on multiple CAs. The OCSP server
returns, at a minimum, a status of “good” or “revoked.”
Of course, this all works only if the OCSP server itself is online. If the server is
not available, the user has a decision to make: abandon the connection attempt,
or go ahead with a potentially revoked certifi cate? Ideally, the client should have
a CRL handy to verify in case the OCSP server is unavailable.
Other Problems with Certifi cates
Whenever a fl aw is found in SSL, it's almost always related to certifi cates.
Even when certifi cates are implemented “perfectly” human behavior often
renders them moot. All browsers, at the time of this writing, allow a user to
ignore a mismatched domain name or a certifi cate past its validity period. Users
are presented with cryptic warning messages and allowed to continue, which
most of them do — even the ones who ought to know better. Still, PKI is what
we have to guard against man-in-the-middle attacks. At a bare minimum, an
implementation of TLS must be prepared to parse certifi cates to extract the
server's public key.