Public-Key Certificates and Certification
This chapter is from the book
This chapter is from the book
This chapter is from the book
As we discussed in Chapter 2, public-key cryptography involves the use of public/private-key pairs to facilitate digital signature and key management services. The fundamental principle that enables public-key technology to scale is the fact that the public component of the public/private-key pair may be distributed freely among the entities that need the public component to use the underlying security services. (See Chapters 4 and 5 for more information regarding security services enabled through the use of a PKI.)
However, distribution of the public component without some form of integrity protection would defeat the very foundation for these security services. Thus, the public-key component must be protected in such a way that it will not impact the overall scalability that public-key cryptography techniques offer. Further, we need to bind certain attributes with the public key.
Thus, a data integrity mechanism is required to ensure that the public key (and any other information associated with that public key) is not modified without detection. However, a data integrity mechanism alone is not sufficient to guarantee that the public key belongs to the claimed owner. A mechanism that binds the public key to the claimed owner in a trustworthy manner is also required. In the end, the goal is to provide a single mechanism by which a relying party (that is, the "user" of the key and associated data, as defined in [RFC2527]) is assured that
The integrity of the public key (and any other associated information) is sound.
The public key (and any other associated information) has been bound to the claimed owner in a trusted manner.
Our purpose in this chapter is to explain how the use of public-key certificates accomplishes these goals. In particular, we will focus on the syntax and semantics of the X.509 Version 3 public-key certificate, and we will explain how the integrity of these certificates is established and maintained.
Certificates
Kohnfelder first introduced the concept of using a signed data structure or certificate to convey the public key to a relying party in his 1978 bachelor's thesis entitled "Towards a Practical Public-Key Cryptosystem" [Kohn78]. Thus, over two decades ago, it was recognized that a scalable and secure method (from an integrity perspective) would be required to convey the public keys to the parties that needed them. Simply stated, public-key certificates are used to bind an entity's name (and possibly additional attributes associated with that entity) with the corresponding public key.
When discussing the concept of a "certificate," it is important to recognize that a number of different types of certificates exist, including
X.509 public-key certificates
Simple Public Key Infrastructure (SPKI) certificates
Pretty Good Privacy (PGP) certificates
Attribute certificates
The certificate types listed here have separate and distinct formats. In some cases, one type of certificate may be defined in several different versions, and a single version may be instantiated in a number of different ways. For example, there are three versions of an X.509 public-key certificate. Version 1 is a subset of Version 2, and Version 2 is a subset of Version 3. Because a Version 3 public- key certificate includes numerous optional extensions (as discussed later), it can be instantiated in a number of application-specific ways; for example, Secure Electronic Transaction (SET) certificates are X.509 Version 3 public-key certificates with specific extensions defined solely for SET exchanges.
To complicate matters further, multiple terms commonly denote the same thing. For example, in many environments the terms certificate and digital certificate are synonymous with an X.509 public-key certificate.
For the purposes of this book, a certificate is synonymous only with a Version 3 public-key certificate as defined in the X.509 Recommendation [X509–00]. (See Box 6.1.) Any other type of certificate will be further qualified to avoid any confusion with this usage. In this chapter, we discuss the structure and content of a certificate. As we describe the structure of a certificate in the next section, you will notice that certificates can be issued to Certification Authorities (CAs) and to end entities (for example, end users or devices). These are referred to as CA certificates and end-entity certificates, respectively.
Box 6.1 Versions 1–3 of X.509Three versions of an X.509 public-key certificate are defined. The original Version 1 public-key certificate, defined in the 1988 X.509 Recommendation, suffers from inherent inflexibility because this version cannot be extended to support additional attributes. The Version 2 public-key certificate did little to correct this shortcoming because it simply augments Version 1 with the addition of two optional fields. Because the demand for these fields was (and continues to be) negligible and the same inability to support extensions also applies, the Version 2 public-key certificate has failed to gain widespread acceptance. Not surprisingly, Version 3 public-key certificates, as specified in the 1997 X.509 Recommendation [X509–97], were introduced to correct the deficiencies associated with the Version 1 and Version 2 definitions. Specifically, Version 3 offers significant improvements over Version 1 and Version 2 through the addition of optional extensions. More recently (circa June 2000), the 2000 X.509 Recommendation [X509–00] was completed. The 2000 version includes numerous changes from the previous version, including the definition of two additional extensions to the Version 3 public-key certificate. In the enterprise domain, it is fair to say that Version 3 public-key certificates are the preferred choice as they are the most flexible, and many of the extensions are required to fully support the requirements of the enterprise. |
Digital Certificate
The term digital certificate is sometimes used to denote a certificate in electronic form. However, this term can be somewhat confusing in some circumstances because a number of quite different certificates (for example, an X.509 public-key certificate, an attribute certificate, a PGP certificate, and so on) are "digital." For that matter, a digitized birth certificate might be considered to be a "digital certificate." Thus, unless the term is either explicitly defined or further qualified, it is not precise enough to convey any intended meaning.
The use of this term has also introduced confusion when describing the relationship between digital certificates and digital signatures. In particular, a common mistake is to assume that Alice can authenticate herself by simply supplying a "digital certificate" without the corresponding "digital signature." Further, although a digital signature is meaningful in itself (that is, a digital signature is distinguished from a handwritten or a generic electronic signature), digital certificate does not offer the same connotation—especially when referring solely to a public-key certificate.
To be perfectly precise, any reference to a certificate should be fully qualified to avoid unnecessary confusion. However, in accordance with common practice in the PKI industry, we will simply use the term certificate as a shorthand notation for an X.509 Version 3 public-key certificate. We will explicitly identify all other types of certificates where appropriate—even the generic use of certificate will be qualified wherever any doubt may arise.
Certificate Structure and Semantics
Although X.509 defines certain requirements associated with the standard fields and extensions of a certificate, other issues still must be further refined in specific profiles to fully address interoperability considerations. The Internet Engineering Task Force (IETF) Public Key Infrastructure X.509 (PKIX) Working Group introduced such a profile in January 1999 with the publication of RFC2459. In April 2002, RFC2459 was replaced with RFC3280. Although RFC3280 is targeted for the Internet community, a number of its recommendations could equally apply in the enterprise environment, and consistency should be maintained wherever possible. Therefore, we will provide references to some of the recommendations made in RFC3280 where appropriate.
Figure 6.1 shows the generic structure of a Version 3 certificate. The following list defines the fields represented in Figure 6.1:
)
Figure 6.1 Version 3 certificate structure.
Version indicates the version of the certificate (either 1, 2, or 3).
Serial Number is the unique identifier for this certificate relative to the certificate issuer.
Signature indicates the algorithm identifier (that is, the Object Identifier, or OID, plus any associated parameters) of the algorithm used to calculate the digital signature on the certificate.1
For example, the OID for SHA-1 with RSA might be present, indicating that the digital signature is an SHA-1 hash encrypted using RSA.
Issuer is the Distinguished Name (DN) of the CA that issued the certificate and must always be present.2
Validity indicates the window of time that this certificate should be considered valid unless otherwise revoked (refer to Chapter 8 for more information on revocation). This field is composed of Not Valid Before and Not Valid After dates/times that may be represented in UTC Time or in Generalized Time (however, RFC3280 has specific rules associated with the use of these time representations).
Subject indicates the DN of the certificate owner and must be non-null unless an alternate name form is used (refer to the Extensions field later).
Subject Public Key Info is the public key (and algorithm identifier) associated with the subject and must always be present.
Issuer Unique ID is an optional unique identifier of the certificate issuer present in Version 2 and Version 3 only; this field is rarely used in implementation practice, and it is not recommended for use by RFC3280.
Subject Unique ID is an optional unique identifier of the certificate owner present in Version 2 and Version 3 only; this field is rarely used in implementation practice, and it is not recommended for use by RFC3280.
Each certificate extension described next is associated with a criticality flag. In general, extensions can be marked critical or noncritical, although the standards often recommend or even mandate the criticality associated with certain extensions.
An extension that has been marked critical must be processed and understood, or the certificate is not to be used. A noncritical extension is to be processed if possible, but it may be gracefully ignored if it is not recognized.
Extensions are optional standard and private extensions (present in Version 3 only) and include the following:
Authority Key Identifier is a unique identifier of the key that should be used to verify the digital signature calculated over the certificate; it distinguishes between multiple keys that apply to the same certificate issuer. RFC3280 mandates the inclusion of this field for all but self-signed certificates. (Chapter 9 discusses self-signed certificates.)
Subject Key Identifier is a unique identifier associated with the public key contained in this certificate; it distinguishes between multiple keys that apply to the same certificate owner. RFC3280 mandates this field for CA certificates, and it is recommended for end-entity certificates.
Key Usage is a bit string used to identify (or restrict) the functions or services that can be supported by using the public key in this certificate; it can be used to indicate support for digital signature, non-repudiation, key encipherment, data encipherment, key agreement, certificate signature, Certification Revocation List (CRL) signature, encipher only, and decipher only. A profile typically specifies allowable combinations (for example, the U.S. Federal PKI (FPKI) profile [FPKIpro] explicitly identifies permitted key usage combinations).
Extended Key Usage is a sequence of one or more OIDs that identify specific usage of the public key in the certificate. Although X.509 does not explicitly define identifiers for this purpose, RFC3280 identifies several OIDs associated with this extension, including Transport Layer Security (TLS) server authentication, TLS client authentication, code signing, e-mail protection, time stamping, and Online Certificate Status Protocol (OCSP) signing. (OCSP is discussed in more detail in Chapter 8.) The list of OIDs will likely be augmented over time as needs dictate, so this should not be considered an exhaustive list. RFC3280 also points out that this extension is typically used with end-entity certificates.
CRL Distribution Point indicates the location of the CRL partition where revocation information associated with this certificate resides. (Refer to Chapter 8 for more information regarding revocation techniques and CRL Distribution Points.) RFC3280 provides additional guidance with respect to which attributes within the CRL Distribution Point extension should be populated and what it means when multiple distribution points are present.
Private Key Usage Period indicates the time window that the private key associated with the public key in this certificate can be used; it is intended for use with digital signature keys/certificates. Like the certificate validity period, this window is specified in terms of Not Valid Before and Not Valid After dates/times (although only Generalized Time is permitted here). Judicious use of this extension can establish a buffer between the time the signing private key expires and the time the corresponding public key used to verify the digital signatures created with that private key expires. This should help eliminate many instances where perfectly valid digital signatures needlessly come into question because the key lifetimes of both the private and public key were too close together (or even identical).
Note that when this extension is absent, the validity periods of the public key and the private key are identical. As Chapter 7 discusses, a new key pair should be issued before the private key expires in order to avoid any unnecessary downtime. It is interesting to note that RFC3280 recommends against the use of this extension. One reason for this is that the interpretation of this field is not universally agreed upon, which could give rise to inconsistent implementations.
Certificate Policies indicates a sequence of one or more policy OIDs and optional qualifiers associated with the issuance and subsequent use of the certificate. If this extension is marked critical, the processing application must adhere to at least one of the policies indicated, or the certificate is not to be used. Although RFC3280 recommends that policy qualifiers should not be used (in order to promote interoperability), it does define two possible qualifiers: the Certification Practice Statement (CPS) qualifier and the User Notice qualifier. The CPS qualifier is a Uniform Resource Identifier (URI) at which one can find the CPS that applies to this certificate. A notice reference, an explicit notice (up to 200 characters), or both, can comprise the User Notice qualifier.
Policy Mappings indicates one or more policy OID equivalencies between two CA domains and are present only in CA certificates. The Certificate Policies section in this chapter provides additional information related to policy mappings.
Subject Alternative Name indicates alternative name forms associated with the owner of the certificate (for example, e-mail address, IP address, URI, and so on). Alternative name forms are to be considered just as binding as the subject DN, if present. RFC3280 further specifies that if the subject DN is null, one or more alternative name forms must be present, and this extension must be marked critical.
Issuer Alternative Name indicates alternative name forms associated with the issuer of the certificate (for example, e-mail address, IP address, URI, and so on). RFC3280 specifies the same processing rules as specified under the Subject Alternate Name extension with the exception that the issuer's DN must always be present in the Issuer field. One reason for this requirement is to maintain compatibility with the S/MIME specification.
Subject Directory Attributes indicates a sequence of attributes associated with the owner of the certificate. Although this extension is not currently in widespread use, several known applications exist where this extension conveys access control information. However, we recommend exercising caution when using a certificate to convey privilege-related information, because any change in those privileges would force the revocation of the existing certificate and a new certificate would have to be issued. (See Box 6.2.)
Box 6.2 Certificate Perishability
Any change to the information contained within a given certificate before it naturally expires necessarily means that the existing certificate must be revoked and a new certificate must be issued. Therefore, exercise care to ensure that the attributes placed within the certificate are fairly static in order to avoid wasteful certificate revocation and (re)issuance. Attributes associated with an end entity that will tend to be fairly dynamic in nature should be conveyed through some other means (for example, via attribute certificates, which are briefly discussed later in this chapter and in Chapter 5).
Basic Constraints indicates whether this is a CA certificate. Typically, this field is absent in end-entity certificates. If it is present in an end-entity certificate, the value of the CA attribute in the Basic Constraints field must be false. For CA certificates, the Basic Constraints field should always be present, and the CA attribute in the Basic Constraints field must be set to a value of true. Note that X.509 [X509–00] recommends (but doesn't mandate) that this extension be marked critical. RFC3280 mandates that this extension be present and marked critical if the associated public key is to be used to verify digital signatures on certificates. However, RFC3280 makes a distinction between public keys used to verify digital signatures on certificates and those that might be used to verify digital signatures on CRLs only or those that are used in conjunction with certificate management protocols. In these cases, the extension may be marked critical or noncritical.
For CA certificates, the Basic Constraints extension can also include a Path Length Constraint. In accordance with X.509 [X509–00], the Path Length Constraint indicates "the maximum number of CA certificates that may follow this certificate in a certification path." (Chapter 9 describes certification paths and certification path processing.) A value of zero indicates that the CA can issue only end-entity certificates. The absence of the Path Length Constraint in a CA certificate indicates that no restriction is placed on the length of the certification path (that is, the length of the certification path is unbounded). Note that the Path Length Constraint should not be present in an end-entity certificate and is meaningless therein; it should be ignored if it is present.
Name Constraints, an extension present only in CA certificates, indicates required and/or excluded subtree names through the use of the Permitted Subtrees and/or Excluded Subtrees attributes, respectively. The specified names can take the form of a DN, a URI, an e-mail address, or any other name form that lends itself to a hierarchical structure. The idea is to qualify the name space that applies to the subject names that follow the CA certificate in which the restrictions took effect. If present, this extension should be marked critical [X509–00]. RFC3280 mandates that this extension be marked critical and points out that Name Constraints should not be applied to certificates where the Issuer and Subject fields are the same unless the certificate is the last one in the certification path. (Chapter 9 provides additional information regarding Name Constraints in relation to certification path validation.)
Policy Constraints, an extension present only in CA certificates, indicates required policy identifiers and/or prohibited policy mappings through the use of the Require Explicit Policy and/or Inhibit Policy Mapping attributes, respectively. It is important to note that if the Require Explicit Policy comes into effect anywhere in a given certification path, it applies to the entire certification path. This is not the case with the Inhibit Policy Mapping attribute that applies only to subsequent certificates in the certification path. A value of zero for either attribute indicates that the restrictions apply immediately. A nonzero value for either attribute indicates where the restrictions might apply; that is, the value is an offset in the certification path, and the nominated CA certificate may or may not be encountered. If present, this extension should be marked critical [X509–00]. RFC3280 states that this extension may be critical or noncritical.
Inhibit Any Policy, an extension present only in CA certificates, indicates that the any-policy identifier (OID value 2.5.29.32.0) should not be considered a legitimate match for other policy identifiers. A value of zero indicates that this restriction applies from this point forward. A nonzero value indicates where the restriction might apply; that is, the value is an offset in the certification path, and the nominated CA certificate may or may not be encountered. This extension was first standardized in the 2000 version of X.509 [X509–00]. In accordance with X.509, this extension may be marked critical or noncritical, but it is recommended that it be marked critical. RFC3280 states that this extension must be marked critical.
Freshest CRL Pointer, an extension present in end-entity and CA certificates, provides a pointer to the "freshest" CRL information. In practice, this is likely to be a pointer to a Delta CRL. (Refer to Chapter 8 for more information on Delta CRLs.) The syntax is the same as is used with CRL Distribution Points. This extension was first standardized in the 2000 version of X.509 [X509–00]. The extension may be marked critical or noncritical, but if it is marked critical, the relying party must retrieve and use this information. RFC3280 states that this extension should be marked noncritical.
Private extensions can also be defined in accordance with X.509. Private extensions are typically defined for domain-specific use. For example, RFC3280 defines two private extensions for Internet use as follows:
Authority Information Access, a private extension present in end-entity and CA certificates, indicates how information or services offered by the issuer of the certificate can be obtained. The type of information and services include on-line validation services and policy information but do not include CRL location information. (The CRL Distribution Point discussed earlier is used for that purpose.) The extension syntax is composed of a sequence of an access method OID that describes the type and format of the service/information and the associated location of the service/information in the form of a General Name (for example, a URI, Directory Name, or RFC822 Name). Two access method OIDs have been defined. One access method, referred to as "CA Issuers," retrieves information about CAs that are superior to the issuer of the certificate. This information can be used to help build certification paths. The other defined access method is for on-line validation services based on OCSP. (Refer to Chapter 8 for more information on OCSP.) Other access methods may be defined in the future. RFC3280 states that this extension must be marked noncritical.
Subject Information Access, a private extension present in end-entity and CA certificates, indicates how information and services offered by the subject in the certificate can be obtained. Like the Authority Information Access private extension, the extension syntax is composed of a sequence of an access method OID and the associated location of the service/information in the form of a General Name. One access method OID has been defined for CAs (CA Repository), and one access method OID has been defined for end entities (time stamping). The CA Repository access method identifies the location of the repository where the CA publishes certificate and CRL information. The Time-Stamping access method indicates that the subject identified in the certificate offers a time stamping service. Other access methods may be defined in the future. RFC3280 states that this extension must be marked noncritical.
Alternative Certificate Formats
As discussed previously in this chapter, certificate types other than the X.509 Version 3 public-key certificate are available. We discuss these further in the next few pages.
SPKI
In contrast to the IETF PKIX Working Group that focused on X.509 issues for the Internet (see Chapter 18), a separate IETF working group was formed to address a (potentially) simpler public- key infrastructure, referred to as the Simple Public Key Infrastructure (SPKI), for the Internet. Specifically, the charter of the IETF SPKI Working Group3 was to develop Internet standards for an IETF sponsored public-key certificate format, associated signature and other formats, and key acquisition protocols. The key certificate format and associated protocols are to be simple to understand, implement, and use.
The IETF SPKI Working Group produced a number of technical and informational documents, including
- SPKI certificate format
- SPKI certificate theory
- SPKI requirements
- SPKI examples
You can retrieve the relevant SPKI documents from http://www.ietf.org/html.charters/spki-charter.html. Because the focus of the SPKI work was on authorization rather than on identity, the SPKI certificate is referred to as an authorization certificate. The primary purpose of the SPKI authorization certificate is to convey permissions. It also includes the ability to delegate permissions to others.
Although the SPKI authorization certificate has some things in common with an X.509 public-key certificate (for example, Issuer and Validity), the syntax and, in many cases, the semantics of these fields are not the same. Further, a number of fields are defined for one type of certificate that does not correspond to an equivalent mapping in the other. In addition, the naming conventions (and assumptions) are completely different because the SPKI work adopted the naming conventions as defined in SDSI.
The IETF work on SPKI has concluded. However, the extent to which this work will be used in practice still remains to be seen. There is currently very little demand for SPKI-based certificates, and in the absence of market demand, CA and PKI vendors are not likely to implement a completely different certificate syntax in addition to X.509 Version 3 public-key certificates.
Chapter 18 provides additional information regarding the role and status of the SPKI work.
PGP
Essentially, Pretty Good Privacy (PGP) is a method for encrypting and digitally signing e-mail messages and files. Phil Zimmermann introduced the first version of PGP in the early 1990s [Zimm95]. Version 2.x of PGP was published a number of years later as an IETF standards-track specification entitled PGP Message Exchange Formats [RFC1991]. The latest version of PGP, referred to as OpenPGP, has been published as an IETF standards-track specification entitled OpenPGP Message Format [RFC2440]. A document on the Internet standards track also incorporates MIME with PGP and is entitled MIME Security with Pretty Good Privacy [RFC2015].
PGP specifies packet formats that convey messages and files from one entity to another. PGP also includes packet formats that convey PGP keys (sometimes referred to as PGP certificates) from one entity to another.
Significant differences exist between PGP keys (or certificates) and X.509 Version 3 public-key certificates, and the trust models they embody are also completely different. (Chapter 9 discusses the PGP trust model further.) The significant differences between PGP keys and the X.509 Version 3 public-key certificate have created interoperability barriers between the PGP-user community and other communities that base their certificate formats on X.509 (for example, the S/MIME-user community). This is much more than a protocol incompatibility issue because the very foundation for the underlying public-key-enabled security services is different and incompatible. One possible solution is for PGP (or OpenPGP) to adopt X.509 Version 3 public-key certificates in addition to (or perhaps in lieu of) the PGP certificate. In fact, Version 6.5 of OpenPGP has pursued this direction and is now capable of supporting X.509 certificates. Although allowing OpenPGP users to tap into X.509-based PKIs, this still does not solve the basic protocol incompatibilities between OpenPGP and S/MIME. Another possibility might be for PKI vendors to offer products that support both PGP and X.509 Version 3 public-key certificates, but this can lead to other difficulties due to the significant differences in the trust models. (For example, it would introduce significant administrative and control issues.)
Although PGP enjoys a significant amount of use over the Internet, it does not make a good candidate for the corporate intranet (that is, the enterprise domain) because all trust decisions rest with individuals rather than with the enterprise. Because many CA and PKI vendors seem to have concentrated their product development efforts on the enterprise domain, it is unclear that they have any motivation to offer PGP-compatible (or OpenPGP-compatible) products.
Chapter 18 provides additional information regarding the role and status of the PGP/OpenPGP work.
SET
The Secure Electronic Transaction (SET) specifications [SET1; SET2; SET3] define a standard to support credit card payment transactions over distributed communications networks such as the Internet. Essentially, SET defines a standard payment protocol and specifies requirements that the supporting PKI is expected to meet.
SET adopts the X.509 Version 3 public-key certificate format, and it defines specific private extensions that have meaning only in a SET context. SET also levies certain profile requirements on the standard extensions. Figure 6.2 illustrates a SET certificate. Note that Figure 6.2 does not represent all the possible extensions. (For example, it does not represent the Hashed Root Key extension present in a SET root CA certificate.)
)
Figure 6.2 SET certificate structure.
Because non-SET applications will not understand the private extensions SET defines, one cannot expect a non-SET application (for example, S/MIME-based e-mail) to accept a SET certificate for use. This is true even though the SET certificate format is compliant with an X.509 Version 3 public-key certificate. Although one might suggest that a non-SET application could ignore the SET extensions, the Certificate Type extension is critical; therefore, by definition a non-SET application must reject a SET certificate. Note that it is accepted practice to intentionally mark certain extensions critical so that a particular type of certificate can be used only in the context of a specific application to minimize liability concerns.
Although it is not necessarily the case that end users will require a separate certificate for each application, this example helps illustrate that multiple certificates per end entity will be required. (Chapter 10 provides additional discussion regarding the requirements for multiple certificates.)
Attribute Certificates
Attribute certificates were first standardized in the 1997 version of X.509 when the basic ASN.1 constructs for an attribute certificate were defined. The 2000 version of X.509 expands on the definition and use of attribute certificates significantly and even describes an attribute certificate framework that can be used as a foundation for building Privilege Management Infrastructures (PMIs). The subject of PMI is rather extensive and could very well be the topic of another book. For the purpose of this book, it is sufficient to say that—although attribute certificates are defined in the X.509 Recommendation—attribute certificates are not public-key certificates. Attribute certificates are designed to convey (potentially short-lived) attributes about a given subject to facilitate flexible and scalable privilege management. The attribute certificate may point to a public-key certificate that can be used to authenticate the identity of the attribute certificate holder. (Chapter 5 provides additional information regarding privilege management.)