To understand X.509, we need to discuss something called X.500. Think of a telephone directory; X.500 is much like your local phone directory. You start with a person's name and, using that name, you can look up information about that person, such as his or her phone number and address. In the case of X.500, you can access many different items about that person, including his or her e-mail address. The concept of an X.500 directory is that the displays can represent any system entity, not just people but computers, businesses, and governments. The entry can also contain the certificate specifying the person's public key. Both X.509 and X.500 were designed in the mid-1980s, before the advent of the Internet.
The lookup method to X.500 is based on a property known as a DN. (Just what we need another acronym!) DN, which stands for "distinguished name," is a method to look up entries in a directory. The DN must be unique in the directory and will be arranged using a hierarchical methodology. This seems to be more confusing terminology. Actually, here is what all this means. A directory (of names) will be organized into a logical structure that someone who is looking for a name could follow. Using an X.500 directory structure, all information held in the directory would be known as the "directory information base," or DIB. The DIB contains entries that are related hierarchically to each other.
Now your next question would be, "What is an entry?" Every entity has attributes associated with it. An attribute comprises an attribute type and one or more associated values. One example of an attribute type would be "office phone number," and the attribute value might be "8-1234." The entries held in the DIB are formatted using a tree structure, which is similar to a structure chart used by most hierarchical organizations. The DIB would be similar to looking at a tree from the top down. In this example you may want to know Bill's office phone number. The problem is that there are 200 Bills in the Company. Looking at the tree from the top down, you can then follow the structure. You may know that Bill works for the Company. You may also know that Bill works in Dallas, Texas. With that information you can find Bill and then read his phone number. In Figure 7.1, Bill's DN is "Bill/Dallas/Texas/the Company." This name format is known as a "canonical" name. If there were a country identifier, then you would have an additional display shown, such as "C = US." These identifiers show each component of a name.
CN = Common Name
OU = Organization Unit
O = Organization
C = Country
Using the X.500 directory we can now find our way around and manage names within our organization. This is where X.509 arrives. As we said, each entry in an X.500 directory will have attributes and values. One of those attributes can and will be an e-mail address, and a place for a public key. Using these attributes, we can do several tasks: send e-mail; send encrypted e-mail; validate a signature; and authenticate against a directory.
This is very powerful, so place a mental bookmark here. We will be discussing directories more as we go on.
X.509 focuses on defining a mechanism by which information can be made available in a secure way to a third party and it supports the authentication of the entries in an X.500 directory. Every X.509 certificate will be "signed" by a certificate authority, or CA. The main purpose of a CA is to bind a public key to the name contained in the certificate, which will provide assurance to third parties that some measure of care was taken to ensure that this binding is valid. Figure 7.2 shows the features of an X.509v2 certificate.
This identifies which version of the X.509 standard applies to this certificate and impacts what information can be specified in it.
This number is unique and is assigned to the certificate by its issuing CA. This information can be used in several ways for example, when a certificate is revoked, its serial number is placed in a certificate revocation list, or CRL. We will describe the CRL later.
This identifies the algorithm used by the CA to sign the certificate.
This is the name of the entity that signed the certificate (typically the CA).
This is a pair of dates/times for which the certificate is considered valid. Each certificate is valid only for a limited amount of time. A start date and an end date define this time period.
The subject name sees the X.500 standard, so it is unique across the directory, or DIB. The entry will be in the format of a distinguished name (DN) of the entity for example, "CN = Bill/OU = Dallas/OU = Texas/OU = the Company/C = US." (Each of these refers to the subject's common name, organizational unit, organization, and country.)
This is the value of the public key, along with an algorithm identifier, which specifies the public key cryptography system to which this key belongs.
This is an optional bit that is used to make the issuing certification authority name unambiguous in the event that the same name has been reassigned to a different entity. This field is not widely used, since it has turned out to be difficult to manage and is ignored or omitted in most implementations.
This is an optional bit string used to make the X.500 name of the subject unambiguous.
The CA will 'stamp' the certificate with a signature. This signature binds of all the other fields (listed above) into the certificate. The certificate identifies the CA via a digital signature but also by the name of the certificate. Certificates are issued by a CA which, by design, is a trusted party that vouches for the identity of those to whom it issues certificates. In order to prevent faked certificates, the CA's public key must be trustworthy. The CA can publicize its public key or provide a certificate from a higher level CA which attests to the validity of its public key.
Now you have seen what an X.509v2 certificate looks like. More information can be gained at http://www.ietf.org/html.charters/pkix-charter.html.
Figure 7.3 shows an X.509v3 certificate. "Extensions" are new fields that have been added to X.509v3. These are significant changes to the X.509 standard. One of the fundamental changes was to make the certificate and CRL formats flexible. These extensions are fully described in RFC 2459.
We will review some of these new extensions: key usage; certificate policy; alternative names; and certification path constraints.
This field indicates the purpose for the key for example, digital signature, certificates signing, and CRL. This is becoming very important in the maintenance of keys, because keys that encrypt data may need to be recoverable and keys for nonrepudiation may be defined as "nonrecoverable."
X.509v3 gives the CA the function to include with the certificate a list of policies that were followed in creating the certificate. These policies are intended to help users decide if a certificate is usable for a particular application.
This field contains one or more alternative, unambiguous names.
These extensions help different organizations link their PKI infrastructures together. These fields include (1) basic constraints (2) name constraints, and (3) policy constraints. The basic constraints indicate whether the certificate may act as a certification authority or is an end-entity certificate. The name constraints can be used to restrict a name space that will be considered acceptable in subsequent certificates via this certificate. The policy constraints will specify a set of constraints with respect to explicit certificate policy identification and policy mapping.