Cryptography Reference
In-Depth Information
This covers RSA and DSA signature validation and RSA key exchange. What
about Diffi e-Hellman? X.509 does defi ne a certifi cate structure that includes
the Diffi e-Hellman parameters; however, this is even rarer in practice than the
nonexistent DSA certifi cate. You can't even use OpenSSL to generate such a
certifi cate. I won't cover it here; if you're so inclined, though, it wouldn't be hard
to add support for it.
There's one big, big problem with all of the X.509 parsing code presented in
this chapter. You probably noticed it while you were reading it: There's no error
checking. At each step, the code assumes that there is, for instance, a
children
.next.next.children.next
structure as required by the X.509 defi nition. The
code should include a lot more error checking to validate that the parsed ASN.1
structure correctly conforms to the expected X.509 structure. As is the technical
topic author's prerogative, though, I'll leave that as an exercise for the reader (or
you could just download the code from the companion website at
www.wiley.com/
go/ImplementingSSL
, which does include the aforementioned error checking).
Managing Certifi cates
The primary purpose of a certifi cate is to communicate a public key. The addi-
tional data — the subject name, the issuer name, the signature, the extensions,
and so on — are present to allow the receiver of the certifi cate to verify that the
bearer is legitimately in possession of the private key that corresponds with the
included public key. Overall, this is referred to as a
public key infrastructure
(PKI).
Public-key cryptography itself was originally developed to permit a secure key
exchange to occur over an insecure medium with no prior off-line communica-
tion; however, PKI requires that the identities — that is, the public keys — of
the trusted CAs be set up before secure communications can be established.
How this is done is outside the scope of SSL/TLS. Browsers come preconfi g-
ured with a list of trusted CAs, for instance, with an option to allow the user to
import new ones. It's up to the user to verify that new public keys are correct
and trustworthy, and to keep track of the trustworthiness of the top-level CAs.
Although this is not part of the SSL/TLS fl ow, there is a set of best practices that
has grown around PKI and certifi cate management.
How Authorities Handle Certifi cate Signing Requests
(CSRs)
The CA is vouching for the legitimacy of a certifi cate. In the context of the
world-wide web, CAs are typically for-profi t businesses; their reputation, and
business viability, depends on how accurately they vet certifi cates prior to
signing them and thus providing their seal of approval. However, it's perfectly
acceptable, in a corporate intranet environment, to establish a local CA and
Search WWH ::
Custom Search