Network Working Group D. Cooper
Request for Comments: 5280 NIST
Obsoletes: 3280, 4325, 4630 S. Santesson
Category: Standards Track Microsoft
Trinity College Dublin
May 2008 Internet 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.
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
7.3. Internationalized Domain Names in Distinguished Names .....987.4. Internationalized Resource Identifiers ....................987.5. Internationalized Electronic Mail Addresses ..............1008. Security Considerations .......................................1009. IANA Considerations ...........................................10510. Acknowledgments ..............................................10511. References ...................................................10511.1. Normative References ....................................10511.2. Informative References ..................................107
Appendix A. Pseudo-ASN.1 Structures and OIDs ....................110A.1. Explicitly Tagged Module, 1988 Syntax ....................110A.2. Implicitly Tagged Module, 1988 Syntax ....................125
Appendix B. ASN.1 Notes ..........................................133
Appendix C. Examples .............................................136C.1. RSA Self-Signed Certificate ..............................137C.2. End Entity Certificate Using RSA .........................140C.3. End Entity Certificate Using DSA .........................143C.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.
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
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 184.108.40.206 and 220.127.116.11 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
* Section 18.104.22.168 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 22.214.171.124 recommends marking the policy mappings extension
as critical. RFC 3280 required that the policy mappings
extension be marked as non-critical.
* Section 126.96.36.199 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.
* 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
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
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
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
Note that an Attribute Authority (AA) might also choose to delegate
the publication of CRLs to a CRL issuer.
| 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
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
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
(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
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
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
(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
(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
(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
certificates, and self-signed certificates. Cross-certificates are
CA certificates in which the issuer and subject are different
entities. Cross-certificates describe a trust relationship between
the two CAs. Self-issued certificates are CA certificates in which
the issuer and subject are the same entity. Self-issued certificates
are generated to support changes in policy or operations. Self-
signed certificates are self-issued certificates where the digital
signature may be verified by the public key bound into the
certificate. Self-signed certificates are used to convey a public
key for use to begin certification paths. End entity certificates
are issued to subjects that are not authorized to issue certificates.
When a certificate is issued, it is expected to be in use for its
entire validity period. However, various circumstances may cause a
certificate to become invalid prior to the expiration of the validity
period. Such circumstances include change of name, change of
association between subject and CA (e.g., an employee terminates
employment with an organization), and compromise or suspected
compromise of the corresponding private key. Under such
circumstances, the CA needs to revoke the certificate.
X.509 defines one method of certificate revocation. This method
involves each CA periodically issuing a signed data structure called
a certificate revocation list (CRL). A CRL is a time-stamped list
identifying revoked certificates that is signed by a CA or CRL issuer
and made freely available in a public repository. Each revoked
certificate is identified in a CRL by its certificate serial number.
When a certificate-using system uses a certificate (e.g., for
verifying a remote user's digital signature), that system not only
checks the certificate signature and validity but also acquires a
suitably recent CRL and checks that the certificate serial number is
not on that CRL. The meaning of "suitably recent" may vary with
local policy, but it usually means the most recently issued CRL. A
new CRL is issued on a regular periodic basis (e.g., hourly, daily,
or weekly). An entry is added to the CRL as part of the next update
following notification of revocation. An entry MUST NOT be removed
from the CRL until it appears on one regularly scheduled CRL issued
beyond the revoked certificate's validity period.
An advantage of this revocation method is that CRLs may be
distributed by exactly the same means as certificates themselves,
namely, via untrusted servers and untrusted communications.
One limitation of the CRL revocation method, using untrusted
communications and servers, is that the time granularity of
revocation is limited to the CRL issue period. For example, if a
revocation is reported now, that revocation will not be reliably
notified to certificate-using systems until all currently issued CRLs
are scheduled to be updated -- this may be up to one hour, one day,
or one week depending on the frequency that CRLs are issued.
As with the X.509 v3 certificate format, in order to facilitate
interoperable implementations from multiple vendors, the X.509 v2 CRL
format needs to be profiled for Internet use. It is one goal of this
document to specify that profile. However, this profile does not
require the issuance of CRLs. Message formats and protocols
supporting on-line revocation notification are defined in other PKIX
specifications. On-line methods of revocation notification may be
applicable in some environments as an alternative to the X.509 CRL.
On-line revocation checking may significantly reduce the latency
between a revocation report and the distribution of the information
to relying parties. Once the CA accepts a revocation report as
authentic and valid, any query to the on-line service will correctly
reflect the certificate validation impacts of the revocation.
However, these methods impose new security requirements: the
certificate validator needs to trust the on-line validation service
while the repository does not need to be trusted.
3.4. Operational Protocols
Operational protocols are required to deliver certificates and CRLs
(or status information) to certificate-using client systems.
Provisions are needed for a variety of different means of certificate
and CRL delivery, including distribution procedures based on LDAP,
HTTP, FTP, and X.500. Operational protocols supporting these
functions are defined in other PKIX specifications. These
specifications may include definitions of message formats and
procedures for supporting all of the above operational environments,
including definitions of or references to appropriate MIME content
3.5. Management Protocols
Management protocols are required to support on-line interactions
between PKI user and management entities. For example, a management
protocol might be used between a CA and a client system with which a
key pair is associated, or between two CAs that cross-certify each
other. The set of functions that potentially need to be supported by
management protocols include:
(a) registration: This is the process whereby a user first makes
itself known to a CA (directly, or through an RA), prior to
that CA issuing a certificate or certificates for that user.
(b) initialization: Before a client system can operate securely,
it is necessary to install key materials that have the
appropriate relationship with keys stored elsewhere in the
infrastructure. For example, the client needs to be securely
initialized with the public key and other assured information
of the trusted CA(s), to be used in validating certificate
Furthermore, a client typically needs to be initialized with
its own key pair(s).
(c) certification: This is the process in which a CA issues a
certificate for a user's public key, and returns that
certificate to the user's client system and/or posts that
certificate in a repository.
(d) key pair recovery: As an option, user client key materials
(e.g., a user's private key used for encryption purposes) may
be backed up by a CA or a key backup system. If a user needs
to recover these backed-up key materials (e.g., as a result
of a forgotten password or a lost key chain file), an on-line
protocol exchange may be needed to support such recovery.
(e) key pair update: All key pairs need to be updated regularly,
i.e., replaced with a new key pair, and new certificates
(f) revocation request: An authorized person advises a CA of an
abnormal situation requiring certificate revocation.
(g) cross-certification: Two CAs exchange information used in
establishing a cross-certificate. A cross-certificate is a
certificate issued by one CA to another CA that contains a CA
signature key used for issuing certificates.
Note that on-line protocols are not the only way of implementing the
above functions. For all functions, there are off-line methods of
achieving the same result, and this specification does not mandate
use of on-line protocols. For example, when hardware tokens are
used, many of the functions may be achieved as part of the physical
token delivery. Furthermore, some of the above functions may be
combined into one protocol exchange. In particular, two or more of
the registration, initialization, and certification functions can be
combined into one protocol exchange.
The PKIX series of specifications defines a set of standard message
formats supporting the above functions. The protocols for conveying
these messages in different environments (e.g., email, file transfer,
and WWW) are described in those specifications.