21.03.2013 Views

Problem - Kevin Tafuro

Problem - Kevin Tafuro

Problem - Kevin Tafuro

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

There is no way to digitally verify the authenticity of a self-signed certificate because<br />

the issuer and the subject are the same, which is why it has become common practice<br />

to provide these certificates with the software that uses them. When self-signed<br />

certificates are included with an application, the software author generally obtains<br />

them by some physical means. For example, Thawte (now a part of VeriSign) provides<br />

its root certificates on its web site, free and clear, but strongly advises anyone<br />

making use of them to confirm the certificate fingerprints with Thawte via telephone<br />

before using or distributing them.<br />

To verify the authenticity and validity of a given certificate, each certificate in the<br />

chain must also be verified, from the issuer of the certificate all the way up to the<br />

root certificate. If any certificate in the chain is invalid, each certificate below it in the<br />

chain must also be considered invalid. Invalid certificates typically have either<br />

expired or been revoked (perhaps due to certificate theft). A certificate is also most<br />

certainly considered invalid if it has been tampered with or if the signatures on the<br />

certificate do not match the ones that should have been used to sign it, indicating<br />

that an attacker has tampered with the contents.<br />

The decision about whether to employ a certificate hierarchy more complex than a<br />

single root CA depends on many factors. These factors and their trade-offs are well<br />

beyond the scope of this book. Entire books have been devoted to PKI, and we<br />

strongly recommend that you consult one or more of them to assist you in making an<br />

informed decision. Again, we strongly recommend Planning for PKI, cited at the<br />

beginning of this recipe.<br />

X.509 certificates<br />

The most widely accepted format for certificates is the X.509 format, first introduced in<br />

1988. There are three versions of the format: X.509v1, X.509v2, and X.509v3. The<br />

most recent revision to the standard was introduced in 1996, and most, if not all, modern<br />

software now supports it. A large number of changes were made between X.509v1<br />

and X.509v3, but perhaps the most significant feature introduced in the X.509v3 standard<br />

is its support for extensions.<br />

Version 3 extensions allow a certificate to contain additional fields beyond those<br />

defined by previous versions of the X.509 standard. The additional fields may be<br />

standard in X.509v3, such as the basicConstraints or keyUsage extensions, or they<br />

may be completely nonstandard, perhaps recognized by only a single application.<br />

Each extension has a name for its field, a designation indicating whether the extension<br />

is critical or not, and a value to be associated with the extension field. When an<br />

extension is designated as being critical, software that does not recognize the extension<br />

must reject the certificate as being invalid. If the extension is noncritical and<br />

unknown to the certificate user, it may be ignored.<br />

The X.509v3 standard defines numerous extensions in an effort to consolidate the<br />

more frequently appearing extensions implemented by third parties. One such exam-<br />

512 | Chapter 10: Public Key Infrastructure<br />

This is the Title of the Book, eMatter Edition<br />

Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!