The to-be-signed certificate is the real meat of the X.509 certificate; it contains all the basic certificate information. At a minimum, it contains six fields: the serial number, the certificate signature algorithm identifier, the certificate issuer name, the certificate validity period, the public key, and the subject name. The subject is the party that controls the corresponding private key. There are four optional fields: the version number, two unique identifiers, and the extensions. These optional fields appear only in version 2 and version 3 certificates. The fields are described next:
version.The optionalversionfield describes the syntax of the certificate. When theversionfield is omitted, the certificate is encoded in the orig- inal, version 1 syntax. Version 1 certificates do not include the unique identifiers or extensions. When the certificate includes unique identifiers but not extensions, the version field indicates version 2. When the certifi- cate includes extensions, as almost all modern certificates do, the version field indicates version 3.
serialNumber.The serial number is an integer assigned by the certifi- cate issuer to each certificate. The serial number must be unique for each certificate generated by a particular issuer. The combination of the issuer name and serial number uniquely identifies any certificate. signature.Thesignaturefield is an algorithm identifier. It is a copy of the
signature algorithm contained in the signature algorithm field; however, the digital signature protects this value.
issuer.Theissuerfield contains the X.500 distinguished name of the cer- tificate issuer. The Internet Certificate and CRL profile [RFC3280] requires the issuer field to contain a nonempty name. The distinguished name can include any attributes; however, for interoperability, the issuer should be limited to the naming attributes described previously.
validity.Thevalidityfield has two components, indicating the dates on which the certificate becomes valid (notBefore) and the date on which
68 Part II ■ PKI Basics
the certificate expires (notAfter). CAs must encode these fields as UTC time for dates through the year 2049, and generalized time for dates in the year 2050 and beyond.
subject.Thesubjectfield contains the distinguished name of the holder of the private key corresponding to the public key in this certificate. The subject may be a CA or an end entity. End entities can be human users, hardware devices, or anything else that might make use of the pri- vate key. The distinguished name can include any attributes; however, for interoperability, the subject name should be limited to the naming attributes described earlier. In the development of a certification path, the subject names in CA certificates must match the issuer name in the certifi- cate that follows.
subjectPublicKeyInfo.ThesubjectPublicKeyInfofield contains the sub- ject’s public key and algorithm identifier. Unlike the signature or sig- nature algorithm fields, which also make use of algorithm identifiers, the parameters within this field convey important information about the public key. For example, the parameters field will contain the domain parameters (p, q, and g) associated with DSA or Diffie-Hellman public keys. If the parameters are omitted, then the subject and issuer have the same public key parameters. Parameter inheritance simply reduces the size of certificates by not repeating the same values over and over again. issuerUniqueIdentifierand subjectUniqueIdentifier. These fields contain
identifiers, and they only appear in version 2 or version 3 certificates. The subject and issuer unique identifiers are intended to handle the reuse of subject names or issuer names over time. However, this mechanism has proven to be an unsatisfactory solution. The Internet Certificate and CRL profile [RFC3280] recommends omission of these fields. Even so, imple- mentations must parse these fields or reject certificates containing them. extensions.This optional field only appears in version 3 certificates. If
present, this field contains one or more certificate extensions. Each exten- sion includes an extension identifier, a criticality flag, and an extension value. Common certificate extensions are described in the next section.
Certificate Extensions
Early PKI deployments clearly demonstrate that the basic certificate content described earlier is insufficient. Certificate users are unable to determine important information about the issuer, the subject, or the public key itself. The missing information can be divided into five groups. Each group is characterized by the questions that it answers:
Turner c05.tex V3 - 03/26/2008 5:28pm Page 69
Chapter 5 ■ Understanding Public Key Infrastructure 69
Names and identity information. Are [email protected] and c=US; o=Fox Consulting; cn=Alice Adams the same person?
Key attributes. Can this public key be used for key transport? Can it also be used to verify a digital signature?
Policy information. Can I trust Alice’s certificate? Is it appropriate for large value transactions?
Additional information. Where can I find certificates issued to the Fox Consulting CA? Where can I get CRLs issued by the Fox Consulting CA? Certificate extensions allow the CA to include information not supported by the basic certificate content. Any organization may define a private extension to meet its particular business requirements. However, most requirements can be satisfied using standard extensions. Standard extensions are widely supported by commercial products. Standard extensions offer improved interoperability, and they are more cost-effective than private extensions.
Extensions have three components: extension identifier, a criticality flag, and extension value. The extension identifier is an OID, and it indicates the format and semantics of the extension value. The criticality flag indicates the importance of the extension. When the criticality flag is set, the information is essential to certificate use. Therefore, if an unrecognized critical extension is encountered, the certificate must not be used. Alternatively, unrecognized noncritical extensions may be ignored.
ITU-T and IETF have defined several extensions for X.509 v3 certificates. They are specified in [X50997], [X50900], [RFC3280], and [RFC3851].