Network Working Group D. Cooper Request for Comments: 5280 NIST Obsoletes: 3280, 4325, 4630 S. Santesson Category: Standards Track Microsoft S. Farrell Trinity College Dublin S. Boeyen Entrust R. Housley Vigil Security W. Polk NIST May 2008Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile
Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. Cooper, et al. Standards Track [Page 1]
RFC 5280 PKIX Certificate and CRL Profile May 2008 Table of Contents 1. Introduction ....................................................4 2. Requirements and Assumptions ....................................6 2.1. Communication and Topology .................................7 2.2. Acceptability Criteria .....................................7 2.3. User Expectations ..........................................7 2.4. Administrator Expectations .................................8 3. Overview of Approach ............................................8 3.1. X.509 Version 3 Certificate ................................9 3.2. Certification Paths and Trust .............................10 3.3. Revocation ................................................13 3.4. Operational Protocols .....................................14 3.5. Management Protocols ......................................14 4. Certificate and Certificate Extensions Profile .................16 4.1. Basic Certificate Fields ..................................16 4.1.1. Certificate Fields .................................17 4.1.1.1. tbsCertificate ............................18 4.1.1.2. signatureAlgorithm ........................18 4.1.1.3. signatureValue ............................18 4.1.2. TBSCertificate .....................................18 4.1.2.1. Version ...................................19 4.1.2.2. Serial Number .............................19 4.1.2.3. Signature .................................19 4.1.2.4. Issuer ....................................20 4.1.2.5. Validity ..................................22 4.1.2.5.1. UTCTime ........................23 4.1.2.5.2. GeneralizedTime ................23 4.1.2.6. Subject ...................................23 4.1.2.7. Subject Public Key Info ...................25 4.1.2.8. Unique Identifiers ........................25 4.1.2.9. Extensions ................................26 4.2. Certificate Extensions ....................................26 4.2.1. Standard Extensions ................................27 4.2.1.1. Authority Key Identifier ..................27 4.2.1.2. Subject Key Identifier ....................28 4.2.1.3. Key Usage .................................29 4.2.1.4. Certificate Policies ......................32 4.2.1.5. Policy Mappings ...........................35 4.2.1.6. Subject Alternative Name ..................35 4.2.1.7. Issuer Alternative Name ...................38 4.2.1.8. Subject Directory Attributes ..............39 4.2.1.9. Basic Constraints .........................39 4.2.1.10. Name Constraints .........................40 4.2.1.11. Policy Constraints .......................43 4.2.1.12. Extended Key Usage .......................44 4.2.1.13. CRL Distribution Points ..................45 4.2.1.14. Inhibit anyPolicy ........................48 Cooper, et al. Standards Track [Page 2]
RFC 5280 PKIX Certificate and CRL Profile May 2008 4.2.1.15. Freshest CRL (a.k.a. Delta CRL Distribution Point) ......................48 4.2.2. Private Internet Extensions ........................49 4.2.2.1. Authority Information Access ..............49 4.2.2.2. Subject Information Access ................51 5. CRL and CRL Extensions Profile .................................54 5.1. CRL Fields ................................................55 5.1.1. CertificateList Fields .............................56 5.1.1.1. tbsCertList ...............................56 5.1.1.2. signatureAlgorithm ........................57 5.1.1.3. signatureValue ............................57 5.1.2. Certificate List "To Be Signed" ....................58 5.1.2.1. Version ...................................58 5.1.2.2. Signature .................................58 5.1.2.3. Issuer Name ...............................58 5.1.2.4. This Update ...............................58 5.1.2.5. Next Update ...............................59 5.1.2.6. Revoked Certificates ......................59 5.1.2.7. Extensions ................................60 5.2. CRL Extensions ............................................60 5.2.1. Authority Key Identifier ...........................60 5.2.2. Issuer Alternative Name ............................60 5.2.3. CRL Number .........................................61 5.2.4. Delta CRL Indicator ................................62 5.2.5. Issuing Distribution Point .........................65 5.2.6. Freshest CRL (a.k.a. Delta CRL Distribution Point) .............................................67 5.2.7. Authority Information Access .......................67 5.3. CRL Entry Extensions ......................................69 5.3.1. Reason Code ........................................69 5.3.2. Invalidity Date ....................................70 5.3.3. Certificate Issuer .................................70 6. Certification Path Validation ..................................71 6.1. Basic Path Validation .....................................72 6.1.1. Inputs .............................................75 6.1.2. Initialization .....................................77 6.1.3. Basic Certificate Processing .......................80 6.1.4. Preparation for Certificate i+1 ....................84 6.1.5. Wrap-Up Procedure ..................................87 6.1.6. Outputs ............................................89 6.2. Using the Path Validation Algorithm .......................89 6.3. CRL Validation ............................................90 6.3.1. Revocation Inputs ..................................91 6.3.2. Initialization and Revocation State Variables ......91 6.3.3. CRL Processing .....................................92 7. Processing Rules for Internationalized Names ...................95 7.1. Internationalized Names in Distinguished Names ............96 7.2. Internationalized Domain Names in GeneralName .............97 Cooper, et al. Standards Track [Page 3]
RFC 5280 PKIX Certificate and CRL Profile May 2008 7.3. Internationalized Domain Names in Distinguished Names .....98 7.4. Internationalized Resource Identifiers ....................98 7.5. Internationalized Electronic Mail Addresses ..............100 8. Security Considerations .......................................100 9. IANA Considerations ...........................................105 10. Acknowledgments ..............................................105 11. References ...................................................105 11.1. Normative References ....................................105 11.2. Informative References ..................................107 Appendix A. Pseudo-ASN.1 Structures and OIDs ....................110 A.1. Explicitly Tagged Module, 1988 Syntax ....................110 A.2. Implicitly Tagged Module, 1988 Syntax ....................125 Appendix B. ASN.1 Notes ..........................................133 Appendix C. Examples .............................................136 C.1. RSA Self-Signed Certificate ..............................137 C.2. End Entity Certificate Using RSA .........................140 C.3. End Entity Certificate Using DSA .........................143 C.4. Certificate Revocation List ..............................1471. Introduction
This specification is one part of a family of standards for the X.509 Public Key Infrastructure (PKI) for the Internet. This specification profiles the format and semantics of certificates and certificate revocation lists (CRLs) for the Internet PKI. Procedures are described for processing of certification paths in the Internet environment. Finally, ASN.1 modules are provided in the appendices for all data structures defined or referenced. Section 2 describes Internet PKI requirements and the assumptions that affect the scope of this document. Section 3 presents an architectural model and describes its relationship to previous IETF and ISO/IEC/ITU-T standards. In particular, this document's relationship with the IETF PEM specifications and the ISO/IEC/ITU-T X.509 documents is described. Section 4 profiles the X.509 version 3 certificate, and Section 5 profiles the X.509 version 2 CRL. The profiles include the identification of ISO/IEC/ITU-T and ANSI extensions that may be useful in the Internet PKI. The profiles are presented in the 1988 Abstract Syntax Notation One (ASN.1) rather than the 1997 ASN.1 syntax used in the most recent ISO/IEC/ITU-T standards. Section 6 includes certification path validation procedures. These procedures are based upon the ISO/IEC/ITU-T definition. Implementations are REQUIRED to derive the same results but are not required to use the specified procedures. Cooper, et al. Standards Track [Page 4]
RFC 5280 PKIX Certificate and CRL Profile May 2008 Procedures for identification and encoding of public key materials and digital signatures are defined in [RFC3279], [RFC4055], and [RFC4491]. Implementations of this specification are not required to use any particular cryptographic algorithms. However, conforming implementations that use the algorithms identified in [RFC3279], [RFC4055], and [RFC4491] MUST identify and encode the public key materials and digital signatures as described in those specifications. Finally, three appendices are provided to aid implementers. Appendix A contains all ASN.1 structures defined or referenced within this specification. As above, the material is presented in the 1988 ASN.1. Appendix B contains notes on less familiar features of the ASN.1 notation used within this specification. Appendix C contains examples of conforming certificates and a conforming CRL. This specification obsoletes [RFC3280]. Differences from RFC 3280 are summarized below: * Enhanced support for internationalized names is specified in Section 7, with rules for encoding and comparing Internationalized Domain Names, Internationalized Resource Identifiers (IRIs), and distinguished names. These rules are aligned with comparison rules established in current RFCs, including [RFC3490], [RFC3987], and [RFC4518]. * Sections 4.1.2.4 and 4.1.2.6 incorporate the conditions for continued use of legacy text encoding schemes that were specified in [RFC4630]. Where in use by an established PKI, transition to UTF8String could cause denial of service based on name chaining failures or incorrect processing of name constraints. * Section 4.2.1.4 in RFC 3280, which specified the privateKeyUsagePeriod certificate extension but deprecated its use, was removed. Use of this ISO standard extension is neither deprecated nor recommended for use in the Internet PKI. * Section 4.2.1.5 recommends marking the policy mappings extension as critical. RFC 3280 required that the policy mappings extension be marked as non-critical. * Section 4.2.1.11 requires marking the policy constraints extension as critical. RFC 3280 permitted the policy constraints extension to be marked as critical or non-critical. * The Authority Information Access (AIA) CRL extension, as specified in [RFC4325], was added as Section 5.2.7. Cooper, et al. Standards Track [Page 5]
RFC 5280 PKIX Certificate and CRL Profile May 2008 * Sections 5.2 and 5.3 clarify the rules for handling unrecognized CRL extensions and CRL entry extensions, respectively. * Section 5.3.2 in RFC 3280, which specified the holdInstructionCode CRL entry extension, was removed. * The path validation algorithm specified in Section 6 no longer tracks the criticality of the certificate policies extensions in a chain of certificates. In RFC 3280, this information was returned to a relying party. * The Security Considerations section addresses the risk of circular dependencies arising from the use of https or similar schemes in the CRL distribution points, authority information access, or subject information access extensions. * The Security Considerations section addresses risks associated with name ambiguity. * The Security Considerations section references RFC 4210 for procedures to signal changes in CA operations. The ASN.1 modules in Appendix A are unchanged from RFC 3280, except that ub-emailaddress-length was changed from 128 to 255 in order to align with PKCS #9 [RFC2985]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].2. Requirements and Assumptions
The goal of this specification is to develop a profile to facilitate the use of X.509 certificates within Internet applications for those communities wishing to make use of X.509 technology. Such applications may include WWW, electronic mail, user authentication, and IPsec. In order to relieve some of the obstacles to using X.509 certificates, this document defines a profile to promote the development of certificate management systems, development of application tools, and interoperability determined by policy. Some communities will need to supplement, or possibly replace, this profile in order to meet the requirements of specialized application domains or environments with additional authorization, assurance, or operational requirements. However, for basic applications, common representations of frequently used attributes are defined so that Cooper, et al. Standards Track [Page 6]
RFC 5280 PKIX Certificate and CRL Profile May 2008 application developers can obtain necessary information without regard to the issuer of a particular certificate or certificate revocation list (CRL). A certificate user should review the certificate policy generated by the certification authority (CA) before relying on the authentication or non-repudiation services associated with the public key in a particular certificate. To this end, this standard does not prescribe legally binding rules or duties. As supplemental authorization and attribute management tools emerge, such as attribute certificates, it may be appropriate to limit the authenticated attributes that are included in a certificate. These other management tools may provide more appropriate methods of conveying many authenticated attributes.2.1. Communication and Topology
The users of certificates will operate in a wide range of environments with respect to their communication topology, especially users of secure electronic mail. This profile supports users without high bandwidth, real-time IP connectivity, or high connection availability. In addition, the profile allows for the presence of firewall or other filtered communication. This profile does not assume the deployment of an X.500 directory system [X.500] or a Lightweight Directory Access Protocol (LDAP) directory system [RFC4510]. The profile does not prohibit the use of an X.500 directory or an LDAP directory; however, any means of distributing certificates and certificate revocation lists (CRLs) may be used.2.2. Acceptability Criteria
The goal of the Internet Public Key Infrastructure (PKI) is to meet the needs of deterministic, automated identification, authentication, access control, and authorization functions. Support for these services determines the attributes contained in the certificate as well as the ancillary control information in the certificate such as policy data and certification path constraints.2.3. User Expectations
Users of the Internet PKI are people and processes who use client software and are the subjects named in certificates. These uses include readers and writers of electronic mail, the clients for WWW browsers, WWW servers, and the key manager for IPsec within a router. This profile recognizes the limitations of the platforms these users Cooper, et al. Standards Track [Page 7]
RFC 5280 PKIX Certificate and CRL Profile May 2008 employ and the limitations in sophistication and attentiveness of the users themselves. This manifests itself in minimal user configuration responsibility (e.g., trusted CA keys, rules), explicit platform usage constraints within the certificate, certification path constraints that shield the user from many malicious actions, and applications that sensibly automate validation functions.2.4. Administrator Expectations
As with user expectations, the Internet PKI profile is structured to support the individuals who generally operate CAs. Providing administrators with unbounded choices increases the chances that a subtle CA administrator mistake will result in broad compromise. Also, unbounded choices greatly complicate the software that process and validate the certificates created by the CA.3. Overview of Approach
Following is a simplified view of the architectural model assumed by the Public-Key Infrastructure using X.509 (PKIX) specifications. The components in this model are: end entity: user of PKI certificates and/or end user system that is the subject of a certificate; CA: certification authority; RA: registration authority, i.e., an optional system to which a CA delegates certain management functions; CRL issuer: a system that generates and signs CRLs; and repository: a system or collection of distributed systems that stores certificates and CRLs and serves as a means of distributing these certificates and CRLs to end entities. CAs are responsible for indicating the revocation status of the certificates that they issue. Revocation status information may be provided using the Online Certificate Status Protocol (OCSP) [RFC2560], certificate revocation lists (CRLs), or some other mechanism. In general, when revocation status information is provided using CRLs, the CA is also the CRL issuer. However, a CA may delegate the responsibility for issuing CRLs to a different entity. Note that an Attribute Authority (AA) might also choose to delegate the publication of CRLs to a CRL issuer. Cooper, et al. Standards Track [Page 8]
RFC 5280 PKIX Certificate and CRL Profile May 2008 +---+ | C | +------------+ | e | <-------------------->| End entity | | r | Operational +------------+ | t | transactions ^ | i | and management | Management | f | transactions | transactions PKI | i | | users | c | v | a | ======================= +--+------------+ ============== | t | ^ ^ | e | | | PKI | | v | management | & | +------+ | entities | | <---------------------| RA |<----+ | | C | Publish certificate +------+ | | | R | | | | L | | | | | v v | R | +------------+ | e | <------------------------------| CA | | p | Publish certificate +------------+ | o | Publish CRL ^ ^ | s | | | Management | i | +------------+ | | transactions | t | <--------------| CRL Issuer |<----+ | | o | Publish CRL +------------+ v | r | +------+ | y | | CA | +---+ +------+ Figure 1. PKI Entities3.1. X.509 Version 3 Certificate
Users of a public key require confidence that the associated private key is owned by the correct remote subject (person or system) with which an encryption or digital signature mechanism will be used. This confidence is obtained through the use of public key certificates, which are data structures that bind public key values to subjects. The binding is asserted by having a trusted CA digitally sign each certificate. The CA may base this assertion upon technical means (a.k.a., proof of possession through a challenge- response protocol), presentation of the private key, or on an assertion by the subject. A certificate has a limited valid lifetime, which is indicated in its signed contents. Because a certificate's signature and timeliness can be independently checked by a certificate-using client, certificates can be distributed via Cooper, et al. Standards Track [Page 9]
RFC 5280 PKIX Certificate and CRL Profile May 2008 untrusted communications and server systems, and can be cached in unsecured storage in certificate-using systems. ITU-T X.509 (formerly CCITT X.509) or ISO/IEC 9594-8, which was first published in 1988 as part of the X.500 directory recommendations, defines a standard certificate format [X.509]. The certificate format in the 1988 standard is called the version 1 (v1) format. When X.500 was revised in 1993, two more fields were added, resulting in the version 2 (v2) format. The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993, include specifications for a public key infrastructure based on X.509 v1 certificates [RFC1422]. The experience gained in attempts to deploy RFC 1422 made it clear that the v1 and v2 certificate formats were deficient in several respects. Most importantly, more fields were needed to carry information that PEM design and implementation experience had proven necessary. In response to these new requirements, the ISO/IEC, ITU-T, and ANSI X9 developed the X.509 version 3 (v3) certificate format. The v3 format extends the v2 format by adding provision for additional extension fields. Particular extension field types may be specified in standards or may be defined and registered by any organization or community. In June 1996, standardization of the basic v3 format was completed [X.509]. ISO/IEC, ITU-T, and ANSI X9 have also developed standard extensions for use in the v3 extensions field [X.509][X9.55]. These extensions can convey such data as additional subject identification information, key attribute information, policy information, and certification path constraints. However, the ISO/IEC, ITU-T, and ANSI X9 standard extensions are very broad in their applicability. In order to develop interoperable implementations of X.509 v3 systems for Internet use, it is necessary to specify a profile for use of the X.509 v3 extensions tailored for the Internet. It is one goal of this document to specify a profile for Internet WWW, electronic mail, and IPsec applications. Environments with additional requirements may build on this profile or may replace it.3.2. Certification Paths and Trust
A user of a security service requiring knowledge of a public key generally needs to obtain and validate a certificate containing the required public key. If the public key user does not already hold an assured copy of the public key of the CA that signed the certificate, the CA's name, and related information (such as the validity period or name constraints), then it might need an additional certificate to obtain that public key. In general, a chain of multiple certificates Cooper, et al. Standards Track [Page 10]
RFC 5280 PKIX Certificate and CRL Profile May 2008 may be needed, comprising a certificate of the public key owner (the end entity) signed by one CA, and zero or more additional certificates of CAs signed by other CAs. Such chains, called certification paths, are required because a public key user is only initialized with a limited number of assured CA public keys. There are different ways in which CAs might be configured in order for public key users to be able to find certification paths. For PEM, RFC 1422 defined a rigid hierarchical structure of CAs. There are three types of PEM certification authority: (a) Internet Policy Registration Authority (IPRA): This authority, operated under the auspices of the Internet Society, acts as the root of the PEM certification hierarchy at level 1. It issues certificates only for the next level of authorities, PCAs. All certification paths start with the IPRA. (b) Policy Certification Authorities (PCAs): PCAs are at level 2 of the hierarchy, each PCA being certified by the IPRA. A PCA shall establish and publish a statement of its policy with respect to certifying users or subordinate certification authorities. Distinct PCAs aim to satisfy different user needs. For example, one PCA (an organizational PCA) might support the general electronic mail needs of commercial organizations, and another PCA (a high-assurance PCA) might have a more stringent policy designed for satisfying legally binding digital signature requirements. (c) Certification Authorities (CAs): CAs are at level 3 of the hierarchy and can also be at lower levels. Those at level 3 are certified by PCAs. CAs represent, for example, particular organizations, particular organizational units (e.g., departments, groups, sections), or particular geographical areas. RFC 1422 furthermore has a name subordination rule, which requires that a CA can only issue certificates for entities whose names are subordinate (in the X.500 naming tree) to the name of the CA itself. The trust associated with a PEM certification path is implied by the PCA name. The name subordination rule ensures that CAs below the PCA are sensibly constrained as to the set of subordinate entities they can certify (e.g., a CA for an organization can only certify entities in that organization's name tree). Certificate user systems are able to mechanically check that the name subordination rule has been followed. Cooper, et al. Standards Track [Page 11]
RFC 5280 PKIX Certificate and CRL Profile May 2008 RFC 1422 uses the X.509 v1 certificate format. The limitations of X.509 v1 required imposition of several structural restrictions to clearly associate policy information or restrict the utility of certificates. These restrictions included: (a) a pure top-down hierarchy, with all certification paths starting from IPRA; (b) a naming subordination rule restricting the names of a CA's subjects; and (c) use of the PCA concept, which requires knowledge of individual PCAs to be built into certificate chain verification logic. Knowledge of individual PCAs was required to determine if a chain could be accepted. With X.509 v3, most of the requirements addressed by RFC 1422 can be addressed using certificate extensions, without a need to restrict the CA structures used. In particular, the certificate extensions relating to certificate policies obviate the need for PCAs and the constraint extensions obviate the need for the name subordination rule. As a result, this document supports a more flexible architecture, including: (a) Certification paths start with a public key of a CA in a user's own domain, or with the public key of the top of a hierarchy. Starting with the public key of a CA in a user's own domain has certain advantages. In some environments, the local domain is the most trusted. (b) Name constraints may be imposed through explicit inclusion of a name constraints extension in a certificate, but are not required. (c) Policy extensions and policy mappings replace the PCA concept, which permits a greater degree of automation. The application can determine if the certification path is acceptable based on the contents of the certificates instead of a priori knowledge of PCAs. This permits automation of certification path processing. X.509 v3 also includes an extension that identifies the subject of a certificate as being either a CA or an end entity, reducing the reliance on out-of-band information demanded in PEM. This specification covers two classes of certificates: CA certificates and end entity certificates. CA certificates may be further divided into three classes: cross-certificates, self-issued Cooper, et al. Standards Track [Page 12]