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

serialNumber
serialNumber CertificateSerialNumber
As discussed in the section “Putting It Together: The Secure Channel Protocol”
earlier in this chapter, certifi cates are signed by CAs. The process of signing a
certifi cate is often referred to as issuing a certifi cate, and the signer is referred to
as the issuer , although this terminology is a bit misleading. Each signer is required
to assign a unique serial number to each certifi cate issued. The serial number
is not necessarily globally unique, but it can safely be assumed that VeriSign
(a popular CA), for example, never reuses a serial number. Two different CAs
may issue two certifi cates with identical serial numbers, but the same CA never
will. The CertificateSerialNumber is defi ned as an INTEGER .
signature
signature AlgorithmIdentifier,
An X.509 certifi cate must have been signed by a CA. Whether that CA is
trusted or not is a matter for the client to decide. In fact, for testing purposes,
it's often useful to create self-signed certifi cates, in which case the certifi cate
is digitally signed by the private key corresponding to the public key that it
contains.
Whoever signed the certifi cate, the signature algorithm used must be identi-
fi ed by this fi eld. The declaration for an algorithm identifi er is
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL }
Here you see a new type you haven't come across before: the object identifi er
(OID). OIDs are used quite a bit in the X.509 standard and anything else that's
based on ASN.1. OIDs are actually murderously complex and describe a hierar-
chy of just about anything you can think of. Fortunately, you don't really need
to fully understand OIDs. You can treat them simply as byte arrays and keep
track of the mappings of these byte arrays and their meanings.
Recall from the Chapter 4 that digitally signing a sequence of bytes involves
fi rst securely hashing those bytes using a secure hash algorithm such as MD5
or SHA and then encrypting the bytes using a private key. Thus, a digital sig-
nature algorithm identifi er must identify both the secure hashing algorithm
applied as well as the encrypting algorithm. Given MD5 and SHA for secure
hashing algorithms and RSA and DSS for private-key encryption algorithms,
you end up with four separate algorithm identifi ers. However, because MD5 is
not specifi ed for use with DSS, there are only three algorithm identifi ers, which
are shown in Table 5-1.