Problem - Kevin Tafuro

ights of the entity tied to that certificate. Finally, check to make sure the certificate
presented has not been compromised or otherwise revoked.
Discussion
The specifics of how to do certificate verification vary depending on the library you
are using. However, the methodology remains much the same no matter which
library you use. Most libraries perform basic certificate verification for you but leave
you to perform identity checks, such as ensuring that a certificate presented by a
server is actually appropriate for that server to be presenting.
First, note that public key infrastructures tend to support “hierarchies” of certificates,
although not all infrastructures do. That is, a root certificate from VeriSign
might be used to sign a “signing” certificate at AT&T, which might then be used to
sign individual certificates for AT&T employees. VeriSign may not sign the employee
certificates directly, but we can establish a chain of trust, because the personal certificates
are “trusted” by the AT&T signing certificate, and VeriSign trusts the AT&T
signing certificate. There can be arbitrary levels of depth in a certificate hierarchy.
For example, the AT&T company-wide signing certificate could be used to sign
department-wide certificates, which may then sign individual certificates.
Second, just because a CA signs a certificate does not necessarily mean that the certificate
should be trusted by the entity that is presenting it. For example, suppose
that you want to perform an electronic commerce transaction with Amazon. When
an SSLconnection to Amazon’s server is established, the server presents a certificate.
The first thing you do is check to see that there is a trusted path to a root CA that
you trust. Suppose that the certificate presented to you is signed by VeriSign and has
not expired. Does that mean the transaction should go forward? No! You have no
idea whether the certificate that has been presented to you was issued to Amazon or
not. For all you know, it could have been issued to Fred’s Mattress Warehouse or
any other entity. If you get a certificate that is not from Amazon or its representative,
it is probably an attacker’s certificate. Therefore, you need to verify the information
in the certificate to make sure that it really should be trusted. Remember that the signature
on the certificate proves that the data in the certificate has not been altered. A
certificate issued to attacker.org cannot be modified to look like a certificate issued
to Amazon because the signature verification would fail.
Third, what happens if Amazon’s private key is stolen? They will create a new private
key and get a new certificate issued that is bound to that new key, but what
about the old key? An attacker could present the old certificate, and you wouldn’t be
able to tell the difference between it and the new certificate until the old certificate
expires.
One solution to this problem is to use a certificate revocation list (CRL), a list of certificate
serial numbers signed by the CA that represent invalid certificates. These lists
Understanding X.509 Certificate Verification Methodology | 523
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.