X.509 v1 certificates and X.509 v2 certificates specify the public key algorithm and parameters, but they do not offer any other key attributes. Most CAs and end entities have more than one public/private key pair, and they use different key pairs to implement different security services. To differentiate the public keys in different certificates, CAs employ four standard certificate extensions: key usage, extended key usage, authority key identifier, and the subject key identifier:
Key Usage. The key usage extension identifies the security services that a public key might provide. This extension offers nine security services, with the CA selecting the appropriate combination.
Extended Key Usage. The extended key usage extension indicates spe- cific applications for public keys. The extended key usage extension is composed of a sequence of OIDs, where each OID identifies a particular application context in which the public key may be used. For example, the id-kp-serverAuth OID (1.3.6.1.5.5.7.3.1) indicates that the public key may be used by a TLS Web server.
Turner c05.tex V3 - 03/26/2008 5:28pm Page 71
Chapter 5 ■ Understanding Public Key Infrastructure 71
Authority Key Identifier. The authority key identifier extension provides a means for identifying certificates signed by a particular CA private key. This extension aids certification path construction. If the CA has several certificate signing keys, this extension identifies the correct one to verify a particular certificate signature. Without such a pointer, each public key must be tried in succession until the signature is verified or until all pos- sibilities are exhausted!
Subject Key Identifier. The subject key identifier extension provides a means for identifying certificates containing a particular public key. The subject key identifier contains a string that names the key. If the subject has multiple certificates — especially if multiple CAs issue them — the subject key identifier provides a means to quickly identify the certificates containing the public key of interest.
Policy
In early PKI implementations using X.509 v1 certificates and X.509 v2 certifi- cates, each CA issued certificates under one and only one policy. The policy was implicit. Implicit policy information proved unacceptable. No single pol- icy fit all needs. Further, it was, and still remains, inefficient to deploy a separate CA for each policy. It was difficult for certificate users to track which policy was used by each CA. Tracking issuer distinguished directory names to policies and policies to application requirements was too complicated; it was not implemented.
Two standard policy extensions fulfill these needs: the certificate policies extension and the policy mapping extension. The certificate policies extension indicates the policy or policies under which a certificate was issued. In a CA certificate, this indicates the policies under which the CA operates. In an end entity certificate, this indicates the policy (or policies) under which the certificate was issued. An object identifier, usually referred to as a policy OID, identifies the certificate policy. The policy mapping extension translates policy OIDs from one PKI to the equivalent policy OIDs in another PKI.
Certificate Policies. The certificate policies extension indicates the certifi- cate policies under which the certificate was issued. The CA asserts that the procedures used to issue the certificate satisfy the listed policies. Cer- tificate users must know which policy or policies are acceptable for their application. In end entity certificates, this extension describes the policies satisfied. In CA certificates, this extension defines the set of policies that can be included in subordinate certificates.
Policy Mapping. The policy mapping extension is used in CA certificates to translate policy information between two policy domains. Generally, certificate users recognize only a handful of policy OIDs. Normally, these
72 Part II ■ PKI Basics
are the policy OIDs that appear in certificates issued by their own CA. When two CAs operate under different policies, their users will not be able to use the policy information. A policy mapping extension provides the translation needed to make the remote policy information useful. Pol- icy mapping translates remote policy OIDs into local policy OIDs that the certificate user already knows.
Policy Constraints. The policy constraints extension is used to impose limitations on valid certification paths. This extension can constrain path validation in two ways. First, it can be used to prohibit policy mapping. Second, it can require that each certificate in a path contain an acceptable policy OID. Either restriction can be imposed immediately, or the restric- tion can begin after the certification path reaches a specified length.
Additional Information
Several standard extensions provide certificate users with pointers to addi- tional information, including issuer certificates, CRLs, delta CRLs, and online certificate status servers. Further, attributes associated with the certificate sub- ject may be included directly in the certificate. The CRL distribution points extension, freshest CRL extension, authority information access extension, sub- ject information access extension, and the subject directory attribute extension provide this additional information.
CRL Distribution Points. The CRL distribution points extension tells cer- tificate users where and how to obtain CRLs needed to determine if the certificate is revoked.
Freshest CRL. The freshest CRL extension could have been named the delta CRL distribution point extension. It identifies how delta CRL infor- mation is obtained. The same syntax is used for this extension and for the CRL distribution points’ extension described in the previous section. The same conventions apply to both extensions.
Authority Information Access. The authority information access exten- sion tells how to access CA information and services. This information and services may include CA policy data and online certificate status ser- vices. However, the location of CRLs is not specified in this extension; that information is provided by the CRL distribution points’ extension. Subject Information Access. The subject information access extension
tells more information about the subject. It has the same syntax as the authority information access extension.
S/MIME Capabilities. The S/MIME capabilities extension indicates the cryptographic capabilities of the sender of a signed S/MIME message. Recipients can use this information to select the appropriate crypto- graphic algorithms in future S/MIME secured exchanges.
Turner c05.tex V3 - 03/26/2008 5:28pm Page 73
Chapter 5 ■ Understanding Public Key Infrastructure 73
X.509 Certificate Revocation Lists
Figure 5-8 illustrates the structure of the X.509 v2 CRL. Thetbsprefix means to be signed. Therefore, the to-be-signed certificate list is the portion of the CRL that is ASN.1 DER encoded and digitally signed by the CRL issuer.
The top-level structure of the CRL parallels that described for certificates. The top-level structure of the CRL provides a tamper-evident envelope for the CRL content and is composed of three fields:tbsCertList,signatureAlgorithm, andsignatureValue. These fields perform the same function as the fields in the certificate.