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

let it sign certifi cates that are only trusted within the local network. An entity
wishing to act as a CA must simply create a new key pair, generate a certifi cate
that contains the public key, sign the certifi cate with the private key, and publish
the self-signed certifi cate.
How the receivers decide which authorities to trust is not part of the PKI
specifi cation, but how a would-be certifi cate holder gets a signature is. First,
of course, the hopeful certifi cate holder must generate his own keypair. The
public key and the subject's name are wrapped up into a PKCS #10 certifi cate
signing request ( CSR ). The whole certifi cate signing request itself is signed with
the private key, but the private key isn't shared with the CA. Signing the request
with the private key prevents a malicious man in the middle from intercepting
the CSR, substituting his own public key in the request itself, and obtaining a
signed certifi cate in somebody else's name. In essence, the signature proves that
whoever generated the request has access to the private key that corresponds
with the public key, without ever revealing the actual private key.
The CA should, of course, verify the signature with the public key, but should
also verify, in some unspecifi ed offl ine manner, that the requester is actually
the correct holder of the name in the CN fi eld of the subject name. If the certifi -
cate identifi es an individual, perhaps the CA would request that the individual
appear in person and present a driver's license with a name that matches the
CN fi eld and a state that matches the ST fi eld. If the certifi cate identifi es a web
site, the CA might perform a WHOIS query against the ARIN database for the
domain in question to determine who the registered owner is and demand a
driver's license in that name.
After the identity of the requester has been verifi ed, the CA creates an X.509
certifi cate that includes the public key and subject name, as well as the serial
number, validity period, issuer's name as well as any extra attributes that may
be appropriate, such as key usage, and, of course, the signature using the CA's
private key. The fi nal certifi cate can safely be returned over a cleartext channel
with no further authentication. This certifi cate is now public data and by design
contains no sensitive information.
The PKCS #10 format won't be examined in detail here. The offi cial specifi ca-
tion can be downloaded from http://www.rsa.com/rsalabs/node.asp?id=2132 ,
and the OpenSSL req command can be used to generate a new CSR.
Correlating Public and Private Keys Using PKCS #12
Formatting
Notice that the private key itself doesn't appear anywhere in the certifi cate
format, nor the CSR format. (This a good thing!) As you can imagine, when
dealing with several certifi cates, it can become diffi cult to keep track of which
private keys correspond to which public keys; some certifi cates expire, some
need to be revoked due to a key compromise, some domains have their own