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

above, and is identifi ed uniquely by an OID. Incidentally, all of the extension
OIDs start with 55 1D.
Signed Certifi cates
Now, as you browse over the list of fi elds described in the certifi cate structure
from Listing 5-1, you may have noticed that although a signing algorithm is
included, a signature isn't. As you recall from Chapter 4, a signature is generated
when a byte sequence is hashed and the hash is encrypted using a private key.
So, one thing that must be agreed upon before a signature can be generated is
exactly which bytes are hashed. In this case, it's the bytes of the certifi cate struc-
ture — technically, the certifi cate's DER encoding (described later). So, there's
another outer structure defi ned, which includes the certifi cate, the signature
algorithm (again), and the signature value itself, as shown in Listing 5-2.
Listing 5-2: X.509 signed certifi cate declaration
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }
The certifi cate structure defi ned here is properly referred to as the TBSCertificate .
TBS stands for To B e Sig n e d , although the ones examined here have already been
signed. If you think about the overall lifecycle of a certifi cate, this nomenclature
makes sense. First, the certifi cate requester (e.g. the website owner) generates a
public/private keypair and wraps up that information in a To-be-signed certifi cate
structure. This is sent off to the CA, which signs it (after verifying it) and returns
the whole certifi cate back, complete with its digital signature.
The signature algorithm is — in fact, must be — the exact same as the OID
given in the TBSCertificate itself. The signature, of course, is a bit string .
The use of a bit string — the ASN.1 equivalent of a void pointer — runs into the
same defi nitional problem with subjectPublicKeyInfo ; the precise contents vary
depending on the signature algorithm itself. Therefore, again, the BIT STRING
itself is another ASN.1-defi ned structure, depending on the algorithm identifi er.
NOTE A certifi cate can legally be signed by the private key corresponding
to the public key contained within it. This sort of certifi cate is called a self-
signed certifi cate. After all, my certifi cate is signed by a CA, but who signs
their certifi cates? As a result, all top-level certifi cates are self-signed this way.
How the client decides which self-signed top-level certifi cates to trust is not
defi ned by the SSL specifi cation. In the context of a web browser, for example,
there's always a list of trusted CAs that can be updated by the user.
You can see which CAs your browser trusts. If you're using Internet Explorer 8,
for instance, go to Tools Internet Options Publishers, and click the Trusted
Root Certifi cation Authorities tab, as shown in Figure 5-4: