summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5280.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5280.txt')
-rw-r--r--doc/rfc/rfc5280.txt8459
1 files changed, 8459 insertions, 0 deletions
diff --git a/doc/rfc/rfc5280.txt b/doc/rfc/rfc5280.txt
new file mode 100644
index 0000000..34d5699
--- /dev/null
+++ b/doc/rfc/rfc5280.txt
@@ -0,0 +1,8459 @@
+
+
+
+
+
+
+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 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.
+
+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 ..............................147
+
+1. 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 Entities
+
+3.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]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ 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.
+
+3.3. Revocation
+
+ 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
+
+
+
+Cooper, et al. Standards Track [Page 13]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ 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
+ types.
+
+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.
+
+
+
+
+Cooper, et al. Standards Track [Page 14]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ (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
+ paths.
+
+ 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
+ issued.
+
+ (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.
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 15]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ 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.
+
+4. Certificate and Certificate Extensions Profile
+
+ This section presents a profile for public key certificates that will
+ foster interoperability and a reusable PKI. This section is based
+ upon the X.509 v3 certificate format and the standard certificate
+ extensions defined in [X.509]. The ISO/IEC and ITU-T documents use
+ the 1997 version of ASN.1; while this document uses the 1988 ASN.1
+ syntax, the encoded certificate and standard extensions are
+ equivalent. This section also defines private extensions required to
+ support a PKI for the Internet community.
+
+ Certificates may be used in a wide range of applications and
+ environments covering a broad spectrum of interoperability goals and
+ a broader spectrum of operational and assurance requirements. The
+ goal of this document is to establish a common baseline for generic
+ applications requiring broad interoperability and limited special
+ purpose requirements. In particular, the emphasis will be on
+ supporting the use of X.509 v3 certificates for informal Internet
+ electronic mail, IPsec, and WWW applications.
+
+4.1. Basic Certificate Fields
+
+ The X.509 v3 certificate basic syntax is as follows. For signature
+ calculation, the data that is to be signed is encoded using the ASN.1
+ distinguished encoding rules (DER) [X.690]. ASN.1 DER encoding is a
+ tag, length, value encoding system for each element.
+
+ Certificate ::= SEQUENCE {
+ tbsCertificate TBSCertificate,
+ signatureAlgorithm AlgorithmIdentifier,
+ signatureValue BIT STRING }
+
+ TBSCertificate ::= SEQUENCE {
+ version [0] EXPLICIT Version DEFAULT v1,
+ serialNumber CertificateSerialNumber,
+ signature AlgorithmIdentifier,
+ issuer Name,
+ validity Validity,
+ subject Name,
+ subjectPublicKeyInfo SubjectPublicKeyInfo,
+ issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
+ -- If present, version MUST be v2 or v3
+
+
+
+
+Cooper, et al. Standards Track [Page 16]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
+ -- If present, version MUST be v2 or v3
+ extensions [3] EXPLICIT Extensions OPTIONAL
+ -- If present, version MUST be v3
+ }
+
+ Version ::= INTEGER { v1(0), v2(1), v3(2) }
+
+ CertificateSerialNumber ::= INTEGER
+
+ Validity ::= SEQUENCE {
+ notBefore Time,
+ notAfter Time }
+
+ Time ::= CHOICE {
+ utcTime UTCTime,
+ generalTime GeneralizedTime }
+
+ UniqueIdentifier ::= BIT STRING
+
+ SubjectPublicKeyInfo ::= SEQUENCE {
+ algorithm AlgorithmIdentifier,
+ subjectPublicKey BIT STRING }
+
+ Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
+
+ Extension ::= SEQUENCE {
+ extnID OBJECT IDENTIFIER,
+ critical BOOLEAN DEFAULT FALSE,
+ extnValue OCTET STRING
+ -- contains the DER encoding of an ASN.1 value
+ -- corresponding to the extension type identified
+ -- by extnID
+ }
+
+ The following items describe the X.509 v3 certificate for use in the
+ Internet.
+
+4.1.1. Certificate Fields
+
+ The Certificate is a SEQUENCE of three required fields. The fields
+ are described in detail in the following subsections.
+
+
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 17]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+4.1.1.1. tbsCertificate
+
+ The field contains the names of the subject and issuer, a public key
+ associated with the subject, a validity period, and other associated
+ information. The fields are described in detail in Section 4.1.2;
+ the tbsCertificate usually includes extensions, which are described
+ in Section 4.2.
+
+4.1.1.2. signatureAlgorithm
+
+ The signatureAlgorithm field contains the identifier for the
+ cryptographic algorithm used by the CA to sign this certificate.
+ [RFC3279], [RFC4055], and [RFC4491] list supported signature
+ algorithms, but other signature algorithms MAY also be supported.
+
+ An algorithm identifier is defined by the following ASN.1 structure:
+
+ AlgorithmIdentifier ::= SEQUENCE {
+ algorithm OBJECT IDENTIFIER,
+ parameters ANY DEFINED BY algorithm OPTIONAL }
+
+ The algorithm identifier is used to identify a cryptographic
+ algorithm. The OBJECT IDENTIFIER component identifies the algorithm
+ (such as DSA with SHA-1). The contents of the optional parameters
+ field will vary according to the algorithm identified.
+
+ This field MUST contain the same algorithm identifier as the
+ signature field in the sequence tbsCertificate (Section 4.1.2.3).
+
+4.1.1.3. signatureValue
+
+ The signatureValue field contains a digital signature computed upon
+ the ASN.1 DER encoded tbsCertificate. The ASN.1 DER encoded
+ tbsCertificate is used as the input to the signature function. This
+ signature value is encoded as a BIT STRING and included in the
+ signature field. The details of this process are specified for each
+ of the algorithms listed in [RFC3279], [RFC4055], and [RFC4491].
+
+ By generating this signature, a CA certifies the validity of the
+ information in the tbsCertificate field. In particular, the CA
+ certifies the binding between the public key material and the subject
+ of the certificate.
+
+4.1.2. TBSCertificate
+
+ The sequence TBSCertificate contains information associated with the
+ subject of the certificate and the CA that issued it. Every
+ TBSCertificate contains the names of the subject and issuer, a public
+
+
+
+Cooper, et al. Standards Track [Page 18]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ key associated with the subject, a validity period, a version number,
+ and a serial number; some MAY contain optional unique identifier
+ fields. The remainder of this section describes the syntax and
+ semantics of these fields. A TBSCertificate usually includes
+ extensions. Extensions for the Internet PKI are described in Section
+ 4.2.
+
+4.1.2.1. Version
+
+ This field describes the version of the encoded certificate. When
+ extensions are used, as expected in this profile, version MUST be 3
+ (value is 2). If no extensions are present, but a UniqueIdentifier
+ is present, the version SHOULD be 2 (value is 1); however, the
+ version MAY be 3. If only basic fields are present, the version
+ SHOULD be 1 (the value is omitted from the certificate as the default
+ value); however, the version MAY be 2 or 3.
+
+ Implementations SHOULD be prepared to accept any version certificate.
+ At a minimum, conforming implementations MUST recognize version 3
+ certificates.
+
+ Generation of version 2 certificates is not expected by
+ implementations based on this profile.
+
+4.1.2.2. Serial Number
+
+ The serial number MUST be a positive integer assigned by the CA to
+ each certificate. It MUST be unique for each certificate issued by a
+ given CA (i.e., the issuer name and serial number identify a unique
+ certificate). CAs MUST force the serialNumber to be a non-negative
+ integer.
+
+ Given the uniqueness requirements above, serial numbers can be
+ expected to contain long integers. Certificate users MUST be able to
+ handle serialNumber values up to 20 octets. Conforming CAs MUST NOT
+ use serialNumber values longer than 20 octets.
+
+ Note: Non-conforming CAs may issue certificates with serial numbers
+ that are negative or zero. Certificate users SHOULD be prepared to
+ gracefully handle such certificates.
+
+4.1.2.3. Signature
+
+ This field contains the algorithm identifier for the algorithm used
+ by the CA to sign the certificate.
+
+ This field MUST contain the same algorithm identifier as the
+ signatureAlgorithm field in the sequence Certificate (Section
+
+
+
+Cooper, et al. Standards Track [Page 19]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ 4.1.1.2). The contents of the optional parameters field will vary
+ according to the algorithm identified. [RFC3279], [RFC4055], and
+ [RFC4491] list supported signature algorithms, but other signature
+ algorithms MAY also be supported.
+
+4.1.2.4. Issuer
+
+ The issuer field identifies the entity that has signed and issued the
+ certificate. The issuer field MUST contain a non-empty distinguished
+ name (DN). The issuer field is defined as the X.501 type Name
+ [X.501]. Name is defined by the following ASN.1 structures:
+
+ Name ::= CHOICE { -- only one possibility for now --
+ rdnSequence RDNSequence }
+
+ RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
+
+ RelativeDistinguishedName ::=
+ SET SIZE (1..MAX) OF AttributeTypeAndValue
+
+ AttributeTypeAndValue ::= SEQUENCE {
+ type AttributeType,
+ value AttributeValue }
+
+ AttributeType ::= OBJECT IDENTIFIER
+
+ AttributeValue ::= ANY -- DEFINED BY AttributeType
+
+ DirectoryString ::= CHOICE {
+ teletexString TeletexString (SIZE (1..MAX)),
+ printableString PrintableString (SIZE (1..MAX)),
+ universalString UniversalString (SIZE (1..MAX)),
+ utf8String UTF8String (SIZE (1..MAX)),
+ bmpString BMPString (SIZE (1..MAX)) }
+
+ The Name describes a hierarchical name composed of attributes, such
+ as country name, and corresponding values, such as US. The type of
+ the component AttributeValue is determined by the AttributeType; in
+ general it will be a DirectoryString.
+
+ The DirectoryString type is defined as a choice of PrintableString,
+ TeletexString, BMPString, UTF8String, and UniversalString. CAs
+ conforming to this profile MUST use either the PrintableString or
+ UTF8String encoding of DirectoryString, with two exceptions. When
+ CAs have previously issued certificates with issuer fields with
+ attributes encoded using TeletexString, BMPString, or
+ UniversalString, then the CA MAY continue to use these encodings of
+ the DirectoryString to preserve backward compatibility. Also, new
+
+
+
+Cooper, et al. Standards Track [Page 20]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ CAs that are added to a domain where existing CAs issue certificates
+ with issuer fields with attributes encoded using TeletexString,
+ BMPString, or UniversalString MAY encode attributes that they share
+ with the existing CAs using the same encodings as the existing CAs
+ use.
+
+ As noted above, distinguished names are composed of attributes. This
+ specification does not restrict the set of attribute types that may
+ appear in names. However, conforming implementations MUST be
+ prepared to receive certificates with issuer names containing the set
+ of attribute types defined below. This specification RECOMMENDS
+ support for additional attribute types.
+
+ Standard sets of attributes have been defined in the X.500 series of
+ specifications [X.520]. Implementations of this specification MUST
+ be prepared to receive the following standard attribute types in
+ issuer and subject (Section 4.1.2.6) names:
+
+ * country,
+ * organization,
+ * organizational unit,
+ * distinguished name qualifier,
+ * state or province name,
+ * common name (e.g., "Susan Housley"), and
+ * serial number.
+
+ In addition, implementations of this specification SHOULD be prepared
+ to receive the following standard attribute types in issuer and
+ subject names:
+
+ * locality,
+ * title,
+ * surname,
+ * given name,
+ * initials,
+ * pseudonym, and
+ * generation qualifier (e.g., "Jr.", "3rd", or "IV").
+
+ The syntax and associated object identifiers (OIDs) for these
+ attribute types are provided in the ASN.1 modules in Appendix A.
+
+ In addition, implementations of this specification MUST be prepared
+ to receive the domainComponent attribute, as defined in [RFC4519].
+ The Domain Name System (DNS) provides a hierarchical resource
+ labeling system. This attribute provides a convenient mechanism for
+ organizations that wish to use DNs that parallel their DNS names.
+ This is not a replacement for the dNSName component of the
+ alternative name extensions. Implementations are not required to
+
+
+
+Cooper, et al. Standards Track [Page 21]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ convert such names into DNS names. The syntax and associated OID for
+ this attribute type are provided in the ASN.1 modules in Appendix A.
+ Rules for encoding internationalized domain names for use with the
+ domainComponent attribute type are specified in Section 7.3.
+
+ Certificate users MUST be prepared to process the issuer
+ distinguished name and subject distinguished name (Section 4.1.2.6)
+ fields to perform name chaining for certification path validation
+ (Section 6). Name chaining is performed by matching the issuer
+ distinguished name in one certificate with the subject name in a CA
+ certificate. Rules for comparing distinguished names are specified
+ in Section 7.1. If the names in the issuer and subject field in a
+ certificate match according to the rules specified in Section 7.1,
+ then the certificate is self-issued.
+
+4.1.2.5. Validity
+
+ The certificate validity period is the time interval during which the
+ CA warrants that it will maintain information about the status of the
+ certificate. The field is represented as a SEQUENCE of two dates:
+ the date on which the certificate validity period begins (notBefore)
+ and the date on which the certificate validity period ends
+ (notAfter). Both notBefore and notAfter may be encoded as UTCTime or
+ GeneralizedTime.
+
+ CAs conforming to this profile MUST always encode certificate
+ validity dates through the year 2049 as UTCTime; certificate validity
+ dates in 2050 or later MUST be encoded as GeneralizedTime.
+ Conforming applications MUST be able to process validity dates that
+ are encoded in either UTCTime or GeneralizedTime.
+
+ The validity period for a certificate is the period of time from
+ notBefore through notAfter, inclusive.
+
+ In some situations, devices are given certificates for which no good
+ expiration date can be assigned. For example, a device could be
+ issued a certificate that binds its model and serial number to its
+ public key; such a certificate is intended to be used for the entire
+ lifetime of the device.
+
+ To indicate that a certificate has no well-defined expiration date,
+ the notAfter SHOULD be assigned the GeneralizedTime value of
+ 99991231235959Z.
+
+ When the issuer will not be able to maintain status information until
+ the notAfter date (including when the notAfter date is
+ 99991231235959Z), the issuer MUST ensure that no valid certification
+ path exists for the certificate after maintenance of status
+
+
+
+Cooper, et al. Standards Track [Page 22]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ information is terminated. This may be accomplished by expiration or
+ revocation of all CA certificates containing the public key used to
+ verify the signature on the certificate and discontinuing use of the
+ public key used to verify the signature on the certificate as a trust
+ anchor.
+
+4.1.2.5.1. UTCTime
+
+ The universal time type, UTCTime, is a standard ASN.1 type intended
+ for representation of dates and time. UTCTime specifies the year
+ through the two low-order digits and time is specified to the
+ precision of one minute or one second. UTCTime includes either Z
+ (for Zulu, or Greenwich Mean Time) or a time differential.
+
+ For the purposes of this profile, UTCTime values MUST be expressed in
+ Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are
+ YYMMDDHHMMSSZ), even where the number of seconds is zero. Conforming
+ systems MUST interpret the year field (YY) as follows:
+
+ Where YY is greater than or equal to 50, the year SHALL be
+ interpreted as 19YY; and
+
+ Where YY is less than 50, the year SHALL be interpreted as 20YY.
+
+4.1.2.5.2. GeneralizedTime
+
+ The generalized time type, GeneralizedTime, is a standard ASN.1 type
+ for variable precision representation of time. Optionally, the
+ GeneralizedTime field can include a representation of the time
+ differential between local and Greenwich Mean Time.
+
+ For the purposes of this profile, GeneralizedTime values MUST be
+ expressed in Greenwich Mean Time (Zulu) and MUST include seconds
+ (i.e., times are YYYYMMDDHHMMSSZ), even where the number of seconds
+ is zero. GeneralizedTime values MUST NOT include fractional seconds.
+
+4.1.2.6. Subject
+
+ The subject field identifies the entity associated with the public
+ key stored in the subject public key field. The subject name MAY be
+ carried in the subject field and/or the subjectAltName extension. If
+ the subject is a CA (e.g., the basic constraints extension, as
+ discussed in Section 4.2.1.9, is present and the value of cA is
+ TRUE), then the subject field MUST be populated with a non-empty
+ distinguished name matching the contents of the issuer field (Section
+ 4.1.2.4) in all certificates issued by the subject CA. If the
+ subject is a CRL issuer (e.g., the key usage extension, as discussed
+ in Section 4.2.1.3, is present and the value of cRLSign is TRUE),
+
+
+
+Cooper, et al. Standards Track [Page 23]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ then the subject field MUST be populated with a non-empty
+ distinguished name matching the contents of the issuer field (Section
+ 5.1.2.3) in all CRLs issued by the subject CRL issuer. If subject
+ naming information is present only in the subjectAltName extension
+ (e.g., a key bound only to an email address or URI), then the subject
+ name MUST be an empty sequence and the subjectAltName extension MUST
+ be critical.
+
+ Where it is non-empty, the subject field MUST contain an X.500
+ distinguished name (DN). The DN MUST be unique for each subject
+ entity certified by the one CA as defined by the issuer field. A CA
+ MAY issue more than one certificate with the same DN to the same
+ subject entity.
+
+ The subject field is defined as the X.501 type Name. Implementation
+ requirements for this field are those defined for the issuer field
+ (Section 4.1.2.4). Implementations of this specification MUST be
+ prepared to receive subject names containing the attribute types
+ required for the issuer field. Implementations of this specification
+ SHOULD be prepared to receive subject names containing the
+ recommended attribute types for the issuer field. The syntax and
+ associated object identifiers (OIDs) for these attribute types are
+ provided in the ASN.1 modules in Appendix A. Implementations of this
+ specification MAY use the comparison rules in Section 7.1 to process
+ unfamiliar attribute types (i.e., for name chaining) whose attribute
+ values use one of the encoding options from DirectoryString. Binary
+ comparison should be used when unfamiliar attribute types include
+ attribute values with encoding options other than those found in
+ DirectoryString. This allows implementations to process certificates
+ with unfamiliar attributes in the subject name.
+
+ When encoding attribute values of type DirectoryString, conforming
+ CAs MUST use PrintableString or UTF8String encoding, with the
+ following exceptions:
+
+ (a) When the subject of the certificate is a CA, the subject
+ field MUST be encoded in the same way as it is encoded in the
+ issuer field (Section 4.1.2.4) in all certificates issued by
+ the subject CA. Thus, if the subject CA encodes attributes
+ in the issuer fields of certificates that it issues using the
+ TeletexString, BMPString, or UniversalString encodings, then
+ the subject field of certificates issued to that CA MUST use
+ the same encoding.
+
+ (b) When the subject of the certificate is a CRL issuer, the
+ subject field MUST be encoded in the same way as it is
+ encoded in the issuer field (Section 5.1.2.3) in all CRLs
+ issued by the subject CRL issuer.
+
+
+
+Cooper, et al. Standards Track [Page 24]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ (c) TeletexString, BMPString, and UniversalString are included
+ for backward compatibility, and SHOULD NOT be used for
+ certificates for new subjects. However, these types MAY be
+ used in certificates where the name was previously
+ established, including cases in which a new certificate is
+ being issued to an existing subject or a certificate is being
+ issued to a new subject where the attributes being encoded
+ have been previously established in certificates issued to
+ other subjects. Certificate users SHOULD be prepared to
+ receive certificates with these types.
+
+ Legacy implementations exist where an electronic mail address is
+ embedded in the subject distinguished name as an emailAddress
+ attribute [RFC2985]. The attribute value for emailAddress is of type
+ IA5String to permit inclusion of the character '@', which is not part
+ of the PrintableString character set. emailAddress attribute values
+ are not case-sensitive (e.g., "subscriber@example.com" is the same as
+ "SUBSCRIBER@EXAMPLE.COM").
+
+ Conforming implementations generating new certificates with
+ electronic mail addresses MUST use the rfc822Name in the subject
+ alternative name extension (Section 4.2.1.6) to describe such
+ identities. Simultaneous inclusion of the emailAddress attribute in
+ the subject distinguished name to support legacy implementations is
+ deprecated but permitted.
+
+4.1.2.7. Subject Public Key Info
+
+ This field is used to carry the public key and identify the algorithm
+ with which the key is used (e.g., RSA, DSA, or Diffie-Hellman). The
+ algorithm is identified using the AlgorithmIdentifier structure
+ specified in Section 4.1.1.2. The object identifiers for the
+ supported algorithms and the methods for encoding the public key
+ materials (public key and parameters) are specified in [RFC3279],
+ [RFC4055], and [RFC4491].
+
+4.1.2.8. Unique Identifiers
+
+ These fields MUST only appear if the version is 2 or 3 (Section
+ 4.1.2.1). These fields MUST NOT appear if the version is 1. The
+ subject and issuer unique identifiers are present in the certificate
+ to handle the possibility of reuse of subject and/or issuer names
+ over time. This profile RECOMMENDS that names not be reused for
+ different entities and that Internet certificates not make use of
+ unique identifiers. CAs conforming to this profile MUST NOT generate
+ certificates with unique identifiers. Applications conforming to
+
+
+
+
+
+Cooper, et al. Standards Track [Page 25]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ this profile SHOULD be capable of parsing certificates that include
+ unique identifiers, but there are no processing requirements
+ associated with the unique identifiers.
+
+4.1.2.9. Extensions
+
+ This field MUST only appear if the version is 3 (Section 4.1.2.1).
+ If present, this field is a SEQUENCE of one or more certificate
+ extensions. The format and content of certificate extensions in the
+ Internet PKI are defined in Section 4.2.
+
+4.2. Certificate Extensions
+
+ The extensions defined for X.509 v3 certificates provide methods for
+ associating additional attributes with users or public keys and for
+ managing relationships between CAs. The X.509 v3 certificate format
+ also allows communities to define private extensions to carry
+ information unique to those communities. Each extension in a
+ certificate is designated as either critical or non-critical. A
+ certificate-using system MUST reject the certificate if it encounters
+ a critical extension it does not recognize or a critical extension
+ that contains information that it cannot process. A non-critical
+ extension MAY be ignored if it is not recognized, but MUST be
+ processed if it is recognized. The following sections present
+ recommended extensions used within Internet certificates and standard
+ locations for information. Communities may elect to use additional
+ extensions; however, caution ought to be exercised in adopting any
+ critical extensions in certificates that might prevent use in a
+ general context.
+
+ Each extension includes an OID and an ASN.1 structure. When an
+ extension appears in a certificate, the OID appears as the field
+ extnID and the corresponding ASN.1 DER encoded structure is the value
+ of the octet string extnValue. A certificate MUST NOT include more
+ than one instance of a particular extension. For example, a
+ certificate may contain only one authority key identifier extension
+ (Section 4.2.1.1). An extension includes the boolean critical, with
+ a default value of FALSE. The text for each extension specifies the
+ acceptable values for the critical field for CAs conforming to this
+ profile.
+
+ Conforming CAs MUST support key identifiers (Sections 4.2.1.1 and
+ 4.2.1.2), basic constraints (Section 4.2.1.9), key usage (Section
+ 4.2.1.3), and certificate policies (Section 4.2.1.4) extensions. If
+ the CA issues certificates with an empty sequence for the subject
+ field, the CA MUST support the subject alternative name extension
+ (Section 4.2.1.6). Support for the remaining extensions is OPTIONAL.
+ Conforming CAs MAY support extensions that are not identified within
+
+
+
+Cooper, et al. Standards Track [Page 26]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ this specification; certificate issuers are cautioned that marking
+ such extensions as critical may inhibit interoperability.
+
+ At a minimum, applications conforming to this profile MUST recognize
+ the following extensions: key usage (Section 4.2.1.3), certificate
+ policies (Section 4.2.1.4), subject alternative name (Section
+ 4.2.1.6), basic constraints (Section 4.2.1.9), name constraints
+ (Section 4.2.1.10), policy constraints (Section 4.2.1.11), extended
+ key usage (Section 4.2.1.12), and inhibit anyPolicy (Section
+ 4.2.1.14).
+
+ In addition, applications conforming to this profile SHOULD recognize
+ the authority and subject key identifier (Sections 4.2.1.1 and
+ 4.2.1.2) and policy mappings (Section 4.2.1.5) extensions.
+
+4.2.1. Standard Extensions
+
+ This section identifies standard certificate extensions defined in
+ [X.509] for use in the Internet PKI. Each extension is associated
+ with an OID defined in [X.509]. These OIDs are members of the id-ce
+ arc, which is defined by the following:
+
+ id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 }
+
+4.2.1.1. Authority Key Identifier
+
+ The authority key identifier extension provides a means of
+ identifying the public key corresponding to the private key used to
+ sign a certificate. This extension is used where an issuer has
+ multiple signing keys (either due to multiple concurrent key pairs or
+ due to changeover). The identification MAY be based on either the
+ key identifier (the subject key identifier in the issuer's
+ certificate) or the issuer name and serial number.
+
+ The keyIdentifier field of the authorityKeyIdentifier extension MUST
+ be included in all certificates generated by conforming CAs to
+ facilitate certification path construction. There is one exception;
+ where a CA distributes its public key in the form of a "self-signed"
+ certificate, the authority key identifier MAY be omitted. The
+ signature on a self-signed certificate is generated with the private
+ key associated with the certificate's subject public key. (This
+ proves that the issuer possesses both the public and private keys.)
+ In this case, the subject and authority key identifiers would be
+ identical, but only the subject key identifier is needed for
+ certification path building.
+
+ The value of the keyIdentifier field SHOULD be derived from the
+ public key used to verify the certificate's signature or a method
+
+
+
+Cooper, et al. Standards Track [Page 27]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ that generates unique values. Two common methods for generating key
+ identifiers from the public key are described in Section 4.2.1.2.
+ Where a key identifier has not been previously established, this
+ specification RECOMMENDS use of one of these methods for generating
+ keyIdentifiers or use of a similar method that uses a different hash
+ algorithm. Where a key identifier has been previously established,
+ the CA SHOULD use the previously established identifier.
+
+ This profile RECOMMENDS support for the key identifier method by all
+ certificate users.
+
+ Conforming CAs MUST mark this extension as non-critical.
+
+ id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 }
+
+ AuthorityKeyIdentifier ::= SEQUENCE {
+ keyIdentifier [0] KeyIdentifier OPTIONAL,
+ authorityCertIssuer [1] GeneralNames OPTIONAL,
+ authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }
+
+ KeyIdentifier ::= OCTET STRING
+
+4.2.1.2. Subject Key Identifier
+
+ The subject key identifier extension provides a means of identifying
+ certificates that contain a particular public key.
+
+ To facilitate certification path construction, this extension MUST
+ appear in all conforming CA certificates, that is, all certificates
+ including the basic constraints extension (Section 4.2.1.9) where the
+ value of cA is TRUE. In conforming CA certificates, the value of the
+ subject key identifier MUST be the value placed in the key identifier
+ field of the authority key identifier extension (Section 4.2.1.1) of
+ certificates issued by the subject of this certificate. Applications
+ are not required to verify that key identifiers match when performing
+ certification path validation.
+
+ For CA certificates, subject key identifiers SHOULD be derived from
+ the public key or a method that generates unique values. Two common
+ methods for generating key identifiers from the public key are:
+
+ (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
+ value of the BIT STRING subjectPublicKey (excluding the tag,
+ length, and number of unused bits).
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 28]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ (2) The keyIdentifier is composed of a four-bit type field with
+ the value 0100 followed by the least significant 60 bits of
+ the SHA-1 hash of the value of the BIT STRING
+ subjectPublicKey (excluding the tag, length, and number of
+ unused bits).
+
+ Other methods of generating unique numbers are also acceptable.
+
+ For end entity certificates, the subject key identifier extension
+ provides a means for identifying certificates containing the
+ particular public key used in an application. Where an end entity
+ has obtained multiple certificates, especially from multiple CAs, the
+ subject key identifier provides a means to quickly identify the set
+ of certificates containing a particular public key. To assist
+ applications in identifying the appropriate end entity certificate,
+ this extension SHOULD be included in all end entity certificates.
+
+ For end entity certificates, subject key identifiers SHOULD be
+ derived from the public key. Two common methods for generating key
+ identifiers from the public key are identified above.
+
+ Where a key identifier has not been previously established, this
+ specification RECOMMENDS use of one of these methods for generating
+ keyIdentifiers or use of a similar method that uses a different hash
+ algorithm. Where a key identifier has been previously established,
+ the CA SHOULD use the previously established identifier.
+
+ Conforming CAs MUST mark this extension as non-critical.
+
+ id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 }
+
+ SubjectKeyIdentifier ::= KeyIdentifier
+
+4.2.1.3. Key Usage
+
+ The key usage extension defines the purpose (e.g., encipherment,
+ signature, certificate signing) of the key contained in the
+ certificate. The usage restriction might be employed when a key that
+ could be used for more than one operation is to be restricted. For
+ example, when an RSA key should be used only to verify signatures on
+ objects other than public key certificates and CRLs, the
+ digitalSignature and/or nonRepudiation bits would be asserted.
+ Likewise, when an RSA key should be used only for key management, the
+ keyEncipherment bit would be asserted.
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 29]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ Conforming CAs MUST include this extension in certificates that
+ contain public keys that are used to validate digital signatures on
+ other public key certificates or CRLs. When present, conforming CAs
+ SHOULD mark this extension as critical.
+
+ id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 }
+
+ KeyUsage ::= BIT STRING {
+ digitalSignature (0),
+ nonRepudiation (1), -- recent editions of X.509 have
+ -- renamed this bit to contentCommitment
+ keyEncipherment (2),
+ dataEncipherment (3),
+ keyAgreement (4),
+ keyCertSign (5),
+ cRLSign (6),
+ encipherOnly (7),
+ decipherOnly (8) }
+
+ Bits in the KeyUsage type are used as follows:
+
+ The digitalSignature bit is asserted when the subject public key
+ is used for verifying digital signatures, other than signatures on
+ certificates (bit 5) and CRLs (bit 6), such as those used in an
+ entity authentication service, a data origin authentication
+ service, and/or an integrity service.
+
+ The nonRepudiation bit is asserted when the subject public key is
+ used to verify digital signatures, other than signatures on
+ certificates (bit 5) and CRLs (bit 6), used to provide a non-
+ repudiation service that protects against the signing entity
+ falsely denying some action. In the case of later conflict, a
+ reliable third party may determine the authenticity of the signed
+ data. (Note that recent editions of X.509 have renamed the
+ nonRepudiation bit to contentCommitment.)
+
+ The keyEncipherment bit is asserted when the subject public key is
+ used for enciphering private or secret keys, i.e., for key
+ transport. For example, this bit shall be set when an RSA public
+ key is to be used for encrypting a symmetric content-decryption
+ key or an asymmetric private key.
+
+ The dataEncipherment bit is asserted when the subject public key
+ is used for directly enciphering raw user data without the use of
+ an intermediate symmetric cipher. Note that the use of this bit
+ is extremely uncommon; almost all applications use key transport
+ or key agreement to establish a symmetric key.
+
+
+
+
+Cooper, et al. Standards Track [Page 30]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ The keyAgreement bit is asserted when the subject public key is
+ used for key agreement. For example, when a Diffie-Hellman key is
+ to be used for key management, then this bit is set.
+
+ The keyCertSign bit is asserted when the subject public key is
+ used for verifying signatures on public key certificates. If the
+ keyCertSign bit is asserted, then the cA bit in the basic
+ constraints extension (Section 4.2.1.9) MUST also be asserted.
+
+ The cRLSign bit is asserted when the subject public key is used
+ for verifying signatures on certificate revocation lists (e.g.,
+ CRLs, delta CRLs, or ARLs).
+
+ The meaning of the encipherOnly bit is undefined in the absence of
+ the keyAgreement bit. When the encipherOnly bit is asserted and
+ the keyAgreement bit is also set, the subject public key may be
+ used only for enciphering data while performing key agreement.
+
+ The meaning of the decipherOnly bit is undefined in the absence of
+ the keyAgreement bit. When the decipherOnly bit is asserted and
+ the keyAgreement bit is also set, the subject public key may be
+ used only for deciphering data while performing key agreement.
+
+ If the keyUsage extension is present, then the subject public key
+ MUST NOT be used to verify signatures on certificates or CRLs unless
+ the corresponding keyCertSign or cRLSign bit is set. If the subject
+ public key is only to be used for verifying signatures on
+ certificates and/or CRLs, then the digitalSignature and
+ nonRepudiation bits SHOULD NOT be set. However, the digitalSignature
+ and/or nonRepudiation bits MAY be set in addition to the keyCertSign
+ and/or cRLSign bits if the subject public key is to be used to verify
+ signatures on certificates and/or CRLs as well as other objects.
+
+ Combining the nonRepudiation bit in the keyUsage certificate
+ extension with other keyUsage bits may have security implications
+ depending on the context in which the certificate is to be used.
+ Further distinctions between the digitalSignature and nonRepudiation
+ bits may be provided in specific certificate policies.
+
+ This profile does not restrict the combinations of bits that may be
+ set in an instantiation of the keyUsage extension. However,
+ appropriate values for keyUsage extensions for particular algorithms
+ are specified in [RFC3279], [RFC4055], and [RFC4491]. When the
+ keyUsage extension appears in a certificate, at least one of the bits
+ MUST be set to 1.
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 31]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+4.2.1.4. Certificate Policies
+
+ The certificate policies extension contains a sequence of one or more
+ policy information terms, each of which consists of an object
+ identifier (OID) and optional qualifiers. Optional qualifiers, which
+ MAY be present, are not expected to change the definition of the
+ policy. A certificate policy OID MUST NOT appear more than once in a
+ certificate policies extension.
+
+ In an end entity certificate, these policy information terms indicate
+ the policy under which the certificate has been issued and the
+ purposes for which the certificate may be used. In a CA certificate,
+ these policy information terms limit the set of policies for
+ certification paths that include this certificate. When a CA does
+ not wish to limit the set of policies for certification paths that
+ include this certificate, it MAY assert the special policy anyPolicy,
+ with a value of { 2 5 29 32 0 }.
+
+ Applications with specific policy requirements are expected to have a
+ list of those policies that they will accept and to compare the
+ policy OIDs in the certificate to that list. If this extension is
+ critical, the path validation software MUST be able to interpret this
+ extension (including the optional qualifier), or MUST reject the
+ certificate.
+
+ To promote interoperability, this profile RECOMMENDS that policy
+ information terms consist of only an OID. Where an OID alone is
+ insufficient, this profile strongly recommends that the use of
+ qualifiers be limited to those identified in this section. When
+ qualifiers are used with the special policy anyPolicy, they MUST be
+ limited to the qualifiers identified in this section. Only those
+ qualifiers returned as a result of path validation are considered.
+
+ This specification defines two policy qualifier types for use by
+ certificate policy writers and certificate issuers. The qualifier
+ types are the CPS Pointer and User Notice qualifiers.
+
+ The CPS Pointer qualifier contains a pointer to a Certification
+ Practice Statement (CPS) published by the CA. The pointer is in the
+ form of a URI. Processing requirements for this qualifier are a
+ local matter. No action is mandated by this specification regardless
+ of the criticality value asserted for the extension.
+
+ User notice is intended for display to a relying party when a
+ certificate is used. Only user notices returned as a result of path
+ validation are intended for display to the user. If a notice is
+
+
+
+
+
+Cooper, et al. Standards Track [Page 32]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ duplicated, only one copy need be displayed. To prevent such
+ duplication, this qualifier SHOULD only be present in end entity
+ certificates and CA certificates issued to other organizations.
+
+ The user notice has two optional fields: the noticeRef field and the
+ explicitText field. Conforming CAs SHOULD NOT use the noticeRef
+ option.
+
+ The noticeRef field, if used, names an organization and
+ identifies, by number, a particular textual statement prepared by
+ that organization. For example, it might identify the
+ organization "CertsRUs" and notice number 1. In a typical
+ implementation, the application software will have a notice file
+ containing the current set of notices for CertsRUs; the
+ application will extract the notice text from the file and display
+ it. Messages MAY be multilingual, allowing the software to select
+ the particular language message for its own environment.
+
+ An explicitText field includes the textual statement directly in
+ the certificate. The explicitText field is a string with a
+ maximum size of 200 characters. Conforming CAs SHOULD use the
+ UTF8String encoding for explicitText, but MAY use IA5String.
+ Conforming CAs MUST NOT encode explicitText as VisibleString or
+ BMPString. The explicitText string SHOULD NOT include any control
+ characters (e.g., U+0000 to U+001F and U+007F to U+009F). When
+ the UTF8String encoding is used, all character sequences SHOULD be
+ normalized according to Unicode normalization form C (NFC) [NFC].
+
+ If both the noticeRef and explicitText options are included in the
+ one qualifier and if the application software can locate the notice
+ text indicated by the noticeRef option, then that text SHOULD be
+ displayed; otherwise, the explicitText string SHOULD be displayed.
+
+ Note: While the explicitText has a maximum size of 200 characters,
+ some non-conforming CAs exceed this limit. Therefore, certificate
+ users SHOULD gracefully handle explicitText with more than 200
+ characters.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 33]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 }
+
+ anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 }
+
+ certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
+
+ PolicyInformation ::= SEQUENCE {
+ policyIdentifier CertPolicyId,
+ policyQualifiers SEQUENCE SIZE (1..MAX) OF
+ PolicyQualifierInfo OPTIONAL }
+
+ CertPolicyId ::= OBJECT IDENTIFIER
+
+ PolicyQualifierInfo ::= SEQUENCE {
+ policyQualifierId PolicyQualifierId,
+ qualifier ANY DEFINED BY policyQualifierId }
+
+ -- policyQualifierIds for Internet policy qualifiers
+
+ id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
+ id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 }
+ id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 }
+
+ PolicyQualifierId ::= OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )
+
+ Qualifier ::= CHOICE {
+ cPSuri CPSuri,
+ userNotice UserNotice }
+
+ CPSuri ::= IA5String
+
+ UserNotice ::= SEQUENCE {
+ noticeRef NoticeReference OPTIONAL,
+ explicitText DisplayText OPTIONAL }
+
+ NoticeReference ::= SEQUENCE {
+ organization DisplayText,
+ noticeNumbers SEQUENCE OF INTEGER }
+
+ DisplayText ::= CHOICE {
+ ia5String IA5String (SIZE (1..200)),
+ visibleString VisibleString (SIZE (1..200)),
+ bmpString BMPString (SIZE (1..200)),
+ utf8String UTF8String (SIZE (1..200)) }
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 34]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+4.2.1.5. Policy Mappings
+
+ This extension is used in CA certificates. It lists one or more
+ pairs of OIDs; each pair includes an issuerDomainPolicy and a
+ subjectDomainPolicy. The pairing indicates the issuing CA considers
+ its issuerDomainPolicy equivalent to the subject CA's
+ subjectDomainPolicy.
+
+ The issuing CA's users might accept an issuerDomainPolicy for certain
+ applications. The policy mapping defines the list of policies
+ associated with the subject CA that may be accepted as comparable to
+ the issuerDomainPolicy.
+
+ Each issuerDomainPolicy named in the policy mappings extension SHOULD
+ also be asserted in a certificate policies extension in the same
+ certificate. Policies MUST NOT be mapped either to or from the
+ special value anyPolicy (Section 4.2.1.4).
+
+ In general, certificate policies that appear in the
+ issuerDomainPolicy field of the policy mappings extension are not
+ considered acceptable policies for inclusion in subsequent
+ certificates in the certification path. In some circumstances, a CA
+ may wish to map from one policy (p1) to another (p2), but still wants
+ the issuerDomainPolicy (p1) to be considered acceptable for inclusion
+ in subsequent certificates. This may occur, for example, if the CA
+ is in the process of transitioning from the use of policy p1 to the
+ use of policy p2 and has valid certificates that were issued under
+ each of the policies. A CA may indicate this by including two policy
+ mappings in the CA certificates that it issues. Each policy mapping
+ would have an issuerDomainPolicy of p1; one policy mapping would have
+ a subjectDomainPolicy of p1 and the other would have a
+ subjectDomainPolicy of p2.
+
+ This extension MAY be supported by CAs and/or applications.
+ Conforming CAs SHOULD mark this extension as critical.
+
+ id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 }
+
+ PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
+ issuerDomainPolicy CertPolicyId,
+ subjectDomainPolicy CertPolicyId }
+
+4.2.1.6. Subject Alternative Name
+
+ The subject alternative name extension allows identities to be bound
+ to the subject of the certificate. These identities may be included
+ in addition to or in place of the identity in the subject field of
+ the certificate. Defined options include an Internet electronic mail
+
+
+
+Cooper, et al. Standards Track [Page 35]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ address, a DNS name, an IP address, and a Uniform Resource Identifier
+ (URI). Other options exist, including completely local definitions.
+ Multiple name forms, and multiple instances of each name form, MAY be
+ included. Whenever such identities are to be bound into a
+ certificate, the subject alternative name (or issuer alternative
+ name) extension MUST be used; however, a DNS name MAY also be
+ represented in the subject field using the domainComponent attribute
+ as described in Section 4.1.2.4. Note that where such names are
+ represented in the subject field implementations are not required to
+ convert them into DNS names.
+
+ Because the subject alternative name is considered to be definitively
+ bound to the public key, all parts of the subject alternative name
+ MUST be verified by the CA.
+
+ Further, if the only subject identity included in the certificate is
+ an alternative name form (e.g., an electronic mail address), then the
+ subject distinguished name MUST be empty (an empty sequence), and the
+ subjectAltName extension MUST be present. If the subject field
+ contains an empty sequence, then the issuing CA MUST include a
+ subjectAltName extension that is marked as critical. When including
+ the subjectAltName extension in a certificate that has a non-empty
+ subject distinguished name, conforming CAs SHOULD mark the
+ subjectAltName extension as non-critical.
+
+ When the subjectAltName extension contains an Internet mail address,
+ the address MUST be stored in the rfc822Name. The format of an
+ rfc822Name is a "Mailbox" as defined in Section 4.1.2 of [RFC2821].
+ A Mailbox has the form "Local-part@Domain". Note that a Mailbox has
+ no phrase (such as a common name) before it, has no comment (text
+ surrounded in parentheses) after it, and is not surrounded by "<" and
+ ">". Rules for encoding Internet mail addresses that include
+ internationalized domain names are specified in Section 7.5.
+
+ When the subjectAltName extension contains an iPAddress, the address
+ MUST be stored in the octet string in "network byte order", as
+ specified in [RFC791]. The least significant bit (LSB) of each octet
+ is the LSB of the corresponding byte in the network address. For IP
+ version 4, as specified in [RFC791], the octet string MUST contain
+ exactly four octets. For IP version 6, as specified in
+ [RFC2460], the octet string MUST contain exactly sixteen octets.
+
+ When the subjectAltName extension contains a domain name system
+ label, the domain name MUST be stored in the dNSName (an IA5String).
+ The name MUST be in the "preferred name syntax", as specified by
+ Section 3.5 of [RFC1034] and as modified by Section 2.1 of
+ [RFC1123]. Note that while uppercase and lowercase letters are
+ allowed in domain names, no significance is attached to the case. In
+
+
+
+Cooper, et al. Standards Track [Page 36]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ addition, while the string " " is a legal domain name, subjectAltName
+ extensions with a dNSName of " " MUST NOT be used. Finally, the use
+ of the DNS representation for Internet mail addresses
+ (subscriber.example.com instead of subscriber@example.com) MUST NOT
+ be used; such identities are to be encoded as rfc822Name. Rules for
+ encoding internationalized domain names are specified in Section 7.2.
+
+ When the subjectAltName extension contains a URI, the name MUST be
+ stored in the uniformResourceIdentifier (an IA5String). The name
+ MUST NOT be a relative URI, and it MUST follow the URI syntax and
+ encoding rules specified in [RFC3986]. The name MUST include both a
+ scheme (e.g., "http" or "ftp") and a scheme-specific-part. URIs that
+ include an authority ([RFC3986], Section 3.2) MUST include a fully
+ qualified domain name or IP address as the host. Rules for encoding
+ Internationalized Resource Identifiers (IRIs) are specified in
+ Section 7.4.
+
+ As specified in [RFC3986], the scheme name is not case-sensitive
+ (e.g., "http" is equivalent to "HTTP"). The host part, if present,
+ is also not case-sensitive, but other components of the scheme-
+ specific-part may be case-sensitive. Rules for comparing URIs are
+ specified in Section 7.4.
+
+ When the subjectAltName extension contains a DN in the directoryName,
+ the encoding rules are the same as those specified for the issuer
+ field in Section 4.1.2.4. The DN MUST be unique for each subject
+ entity certified by the one CA as defined by the issuer field. A CA
+ MAY issue more than one certificate with the same DN to the same
+ subject entity.
+
+ The subjectAltName MAY carry additional name types through the use of
+ the otherName field. The format and semantics of the name are
+ indicated through the OBJECT IDENTIFIER in the type-id field. The
+ name itself is conveyed as value field in otherName. For example,
+ Kerberos [RFC4120] format names can be encoded into the otherName,
+ using a Kerberos 5 principal name OID and a SEQUENCE of the Realm and
+ the PrincipalName.
+
+ Subject alternative names MAY be constrained in the same manner as
+ subject distinguished names using the name constraints extension as
+ described in Section 4.2.1.10.
+
+ If the subjectAltName extension is present, the sequence MUST contain
+ at least one entry. Unlike the subject field, conforming CAs MUST
+ NOT issue certificates with subjectAltNames containing empty
+ GeneralName fields. For example, an rfc822Name is represented as an
+ IA5String. While an empty string is a valid IA5String, such an
+ rfc822Name is not permitted by this profile. The behavior of clients
+
+
+
+Cooper, et al. Standards Track [Page 37]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ that encounter such a certificate when processing a certification
+ path is not defined by this profile.
+
+ Finally, the semantics of subject alternative names that include
+ wildcard characters (e.g., as a placeholder for a set of names) are
+ not addressed by this specification. Applications with specific
+ requirements MAY use such names, but they must define the semantics.
+
+ id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 }
+
+ SubjectAltName ::= GeneralNames
+
+ GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
+
+ GeneralName ::= CHOICE {
+ otherName [0] OtherName,
+ rfc822Name [1] IA5String,
+ dNSName [2] IA5String,
+ x400Address [3] ORAddress,
+ directoryName [4] Name,
+ ediPartyName [5] EDIPartyName,
+ uniformResourceIdentifier [6] IA5String,
+ iPAddress [7] OCTET STRING,
+ registeredID [8] OBJECT IDENTIFIER }
+
+ OtherName ::= SEQUENCE {
+ type-id OBJECT IDENTIFIER,
+ value [0] EXPLICIT ANY DEFINED BY type-id }
+
+ EDIPartyName ::= SEQUENCE {
+ nameAssigner [0] DirectoryString OPTIONAL,
+ partyName [1] DirectoryString }
+
+4.2.1.7. Issuer Alternative Name
+
+ As with Section 4.2.1.6, this extension is used to associate Internet
+ style identities with the certificate issuer. Issuer alternative
+ name MUST be encoded as in 4.2.1.6. Issuer alternative names are not
+ processed as part of the certification path validation algorithm in
+ Section 6. (That is, issuer alternative names are not used in name
+ chaining and name constraints are not enforced.)
+
+ Where present, conforming CAs SHOULD mark this extension as non-
+ critical.
+
+ id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 }
+
+ IssuerAltName ::= GeneralNames
+
+
+
+Cooper, et al. Standards Track [Page 38]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+4.2.1.8. Subject Directory Attributes
+
+ The subject directory attributes extension is used to convey
+ identification attributes (e.g., nationality) of the subject. The
+ extension is defined as a sequence of one or more attributes.
+ Conforming CAs MUST mark this extension as non-critical.
+
+ id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 }
+
+ SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute
+
+4.2.1.9. Basic Constraints
+
+ The basic constraints extension identifies whether the subject of the
+ certificate is a CA and the maximum depth of valid certification
+ paths that include this certificate.
+
+ The cA boolean indicates whether the certified public key may be used
+ to verify certificate signatures. If the cA boolean is not asserted,
+ then the keyCertSign bit in the key usage extension MUST NOT be
+ asserted. If the basic constraints extension is not present in a
+ version 3 certificate, or the extension is present but the cA boolean
+ is not asserted, then the certified public key MUST NOT be used to
+ verify certificate signatures.
+
+ The pathLenConstraint field is meaningful only if the cA boolean is
+ asserted and the key usage extension, if present, asserts the
+ keyCertSign bit (Section 4.2.1.3). In this case, it gives the
+ maximum number of non-self-issued intermediate certificates that may
+ follow this certificate in a valid certification path. (Note: The
+ last certificate in the certification path is not an intermediate
+ certificate, and is not included in this limit. Usually, the last
+ certificate is an end entity certificate, but it can be a CA
+ certificate.) A pathLenConstraint of zero indicates that no non-
+ self-issued intermediate CA certificates may follow in a valid
+ certification path. Where it appears, the pathLenConstraint field
+ MUST be greater than or equal to zero. Where pathLenConstraint does
+ not appear, no limit is imposed.
+
+ Conforming CAs MUST include this extension in all CA certificates
+ that contain public keys used to validate digital signatures on
+ certificates and MUST mark the extension as critical in such
+ certificates. This extension MAY appear as a critical or non-
+ critical extension in CA certificates that contain public keys used
+ exclusively for purposes other than validating digital signatures on
+ certificates. Such CA certificates include ones that contain public
+ keys used exclusively for validating digital signatures on CRLs and
+ ones that contain key management public keys used with certificate
+
+
+
+Cooper, et al. Standards Track [Page 39]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ enrollment protocols. This extension MAY appear as a critical or
+ non-critical extension in end entity certificates.
+
+ CAs MUST NOT include the pathLenConstraint field unless the cA
+ boolean is asserted and the key usage extension asserts the
+ keyCertSign bit.
+
+ id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 }
+
+ BasicConstraints ::= SEQUENCE {
+ cA BOOLEAN DEFAULT FALSE,
+ pathLenConstraint INTEGER (0..MAX) OPTIONAL }
+
+4.2.1.10. Name Constraints
+
+ The name constraints extension, which MUST be used only in a CA
+ certificate, indicates a name space within which all subject names in
+ subsequent certificates in a certification path MUST be located.
+ Restrictions apply to the subject distinguished name and apply to
+ subject alternative names. Restrictions apply only when the
+ specified name form is present. If no name of the type is in the
+ certificate, the certificate is acceptable.
+
+ Name constraints are not applied to self-issued certificates (unless
+ the certificate is the final certificate in the path). (This could
+ prevent CAs that use name constraints from employing self-issued
+ certificates to implement key rollover.)
+
+ Restrictions are defined in terms of permitted or excluded name
+ subtrees. Any name matching a restriction in the excludedSubtrees
+ field is invalid regardless of information appearing in the
+ permittedSubtrees. Conforming CAs MUST mark this extension as
+ critical and SHOULD NOT impose name constraints on the x400Address,
+ ediPartyName, or registeredID name forms. Conforming CAs MUST NOT
+ issue certificates where name constraints is an empty sequence. That
+ is, either the permittedSubtrees field or the excludedSubtrees MUST
+ be present.
+
+ Applications conforming to this profile MUST be able to process name
+ constraints that are imposed on the directoryName name form and
+ SHOULD be able to process name constraints that are imposed on the
+ rfc822Name, uniformResourceIdentifier, dNSName, and iPAddress name
+ forms. If a name constraints extension that is marked as critical
+ imposes constraints on a particular name form, and an instance of
+ that name form appears in the subject field or subjectAltName
+ extension of a subsequent certificate, then the application MUST
+ either process the constraint or reject the certificate.
+
+
+
+
+Cooper, et al. Standards Track [Page 40]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ Within this profile, the minimum and maximum fields are not used with
+ any name forms, thus, the minimum MUST be zero, and maximum MUST be
+ absent. However, if an application encounters a critical name
+ constraints extension that specifies other values for minimum or
+ maximum for a name form that appears in a subsequent certificate, the
+ application MUST either process these fields or reject the
+ certificate.
+
+ For URIs, the constraint applies to the host part of the name. The
+ constraint MUST be specified as a fully qualified domain name and MAY
+ specify a host or a domain. Examples would be "host.example.com" and
+ ".example.com". When the constraint begins with a period, it MAY be
+ expanded with one or more labels. That is, the constraint
+ ".example.com" is satisfied by both host.example.com and
+ my.host.example.com. However, the constraint ".example.com" is not
+ satisfied by "example.com". When the constraint does not begin with
+ a period, it specifies a host. If a constraint is applied to the
+ uniformResourceIdentifier name form and a subsequent certificate
+ includes a subjectAltName extension with a uniformResourceIdentifier
+ that does not include an authority component with a host name
+ specified as a fully qualified domain name (e.g., if the URI either
+ does not include an authority component or includes an authority
+ component in which the host name is specified as an IP address), then
+ the application MUST reject the certificate.
+
+ A name constraint for Internet mail addresses MAY specify a
+ particular mailbox, all addresses at a particular host, or all
+ mailboxes in a domain. To indicate a particular mailbox, the
+ constraint is the complete mail address. For example,
+ "root@example.com" indicates the root mailbox on the host
+ "example.com". To indicate all Internet mail addresses on a
+ particular host, the constraint is specified as the host name. For
+ example, the constraint "example.com" is satisfied by any mail
+ address at the host "example.com". To specify any address within a
+ domain, the constraint is specified with a leading period (as with
+ URIs). For example, ".example.com" indicates all the Internet mail
+ addresses in the domain "example.com", but not Internet mail
+ addresses on the host "example.com".
+
+ DNS name restrictions are expressed as host.example.com. Any DNS
+ name that can be constructed by simply adding zero or more labels to
+ the left-hand side of the name satisfies the name constraint. For
+ example, www.host.example.com would satisfy the constraint but
+ host1.example.com would not.
+
+ Legacy implementations exist where an electronic mail address is
+ embedded in the subject distinguished name in an attribute of type
+ emailAddress (Section 4.1.2.6). When constraints are imposed on the
+
+
+
+Cooper, et al. Standards Track [Page 41]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ rfc822Name name form, but the certificate does not include a subject
+ alternative name, the rfc822Name constraint MUST be applied to the
+ attribute of type emailAddress in the subject distinguished name.
+ The ASN.1 syntax for emailAddress and the corresponding OID are
+ supplied in Appendix A.
+
+ Restrictions of the form directoryName MUST be applied to the subject
+ field in the certificate (when the certificate includes a non-empty
+ subject field) and to any names of type directoryName in the
+ subjectAltName extension. Restrictions of the form x400Address MUST
+ be applied to any names of type x400Address in the subjectAltName
+ extension.
+
+ When applying restrictions of the form directoryName, an
+ implementation MUST compare DN attributes. At a minimum,
+ implementations MUST perform the DN comparison rules specified in
+ Section 7.1. CAs issuing certificates with a restriction of the form
+ directoryName SHOULD NOT rely on implementation of the full ISO DN
+ name comparison algorithm. This implies name restrictions MUST be
+ stated identically to the encoding used in the subject field or
+ subjectAltName extension.
+
+ The syntax of iPAddress MUST be as described in Section 4.2.1.6 with
+ the following additions specifically for name constraints. For IPv4
+ addresses, the iPAddress field of GeneralName MUST contain eight (8)
+ octets, encoded in the style of RFC 4632 (CIDR) to represent an
+ address range [RFC4632]. For IPv6 addresses, the iPAddress field
+ MUST contain 32 octets similarly encoded. For example, a name
+ constraint for "class C" subnet 192.0.2.0 is represented as the
+ octets C0 00 02 00 FF FF FF 00, representing the CIDR notation
+ 192.0.2.0/24 (mask 255.255.255.0).
+
+ Additional rules for encoding and processing name constraints are
+ specified in Section 7.
+
+ The syntax and semantics for name constraints for otherName,
+ ediPartyName, and registeredID are not defined by this specification,
+ however, syntax and semantics for name constraints for other name
+ forms may be specified in other documents.
+
+ id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 }
+
+ NameConstraints ::= SEQUENCE {
+ permittedSubtrees [0] GeneralSubtrees OPTIONAL,
+ excludedSubtrees [1] GeneralSubtrees OPTIONAL }
+
+ GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
+
+
+
+
+Cooper, et al. Standards Track [Page 42]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ GeneralSubtree ::= SEQUENCE {
+ base GeneralName,
+ minimum [0] BaseDistance DEFAULT 0,
+ maximum [1] BaseDistance OPTIONAL }
+
+ BaseDistance ::= INTEGER (0..MAX)
+
+4.2.1.11. Policy Constraints
+
+ The policy constraints extension can be used in certificates issued
+ to CAs. The policy constraints extension constrains path validation
+ in two ways. It can be used to prohibit policy mapping or require
+ that each certificate in a path contain an acceptable policy
+ identifier.
+
+ If the inhibitPolicyMapping field is present, the value indicates the
+ number of additional certificates that may appear in the path before
+ policy mapping is no longer permitted. For example, a value of one
+ indicates that policy mapping may be processed in certificates issued
+ by the subject of this certificate, but not in additional
+ certificates in the path.
+
+ If the requireExplicitPolicy field is present, the value of
+ requireExplicitPolicy indicates the number of additional certificates
+ that may appear in the path before an explicit policy is required for
+ the entire path. When an explicit policy is required, it is
+ necessary for all certificates in the path to contain an acceptable
+ policy identifier in the certificate policies extension. An
+ acceptable policy identifier is the identifier of a policy required
+ by the user of the certification path or the identifier of a policy
+ that has been declared equivalent through policy mapping.
+
+ Conforming applications MUST be able to process the
+ requireExplicitPolicy field and SHOULD be able to process the
+ inhibitPolicyMapping field. Applications that support the
+ inhibitPolicyMapping field MUST also implement support for the
+ policyMappings extension. If the policyConstraints extension is
+ marked as critical and the inhibitPolicyMapping field is present,
+ applications that do not implement support for the
+ inhibitPolicyMapping field MUST reject the certificate.
+
+ Conforming CAs MUST NOT issue certificates where policy constraints
+ is an empty sequence. That is, either the inhibitPolicyMapping field
+ or the requireExplicitPolicy field MUST be present. The behavior of
+ clients that encounter an empty policy constraints field is not
+ addressed in this profile.
+
+ Conforming CAs MUST mark this extension as critical.
+
+
+
+Cooper, et al. Standards Track [Page 43]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 }
+
+ PolicyConstraints ::= SEQUENCE {
+ requireExplicitPolicy [0] SkipCerts OPTIONAL,
+ inhibitPolicyMapping [1] SkipCerts OPTIONAL }
+
+ SkipCerts ::= INTEGER (0..MAX)
+
+4.2.1.12. Extended Key Usage
+
+ This extension indicates one or more purposes for which the certified
+ public key may be used, in addition to or in place of the basic
+ purposes indicated in the key usage extension. In general, this
+ extension will appear only in end entity certificates. This
+ extension is defined as follows:
+
+ id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 }
+
+ ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
+
+ KeyPurposeId ::= OBJECT IDENTIFIER
+
+ Key purposes may be defined by any organization with a need. Object
+ identifiers used to identify key purposes MUST be assigned in
+ accordance with IANA or ITU-T Recommendation X.660 [X.660].
+
+ This extension MAY, at the option of the certificate issuer, be
+ either critical or non-critical.
+
+ If the extension is present, then the certificate MUST only be used
+ for one of the purposes indicated. If multiple purposes are
+ indicated the application need not recognize all purposes indicated,
+ as long as the intended purpose is present. Certificate using
+ applications MAY require that the extended key usage extension be
+ present and that a particular purpose be indicated in order for the
+ certificate to be acceptable to that application.
+
+ If a CA includes extended key usages to satisfy such applications,
+ but does not wish to restrict usages of the key, the CA can include
+ the special KeyPurposeId anyExtendedKeyUsage in addition to the
+ particular key purposes required by the applications. Conforming CAs
+ SHOULD NOT mark this extension as critical if the anyExtendedKeyUsage
+ KeyPurposeId is present. Applications that require the presence of a
+ particular purpose MAY reject certificates that include the
+ anyExtendedKeyUsage OID but not the particular OID expected for the
+ application.
+
+
+
+
+
+Cooper, et al. Standards Track [Page 44]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ If a certificate contains both a key usage extension and an extended
+ key usage extension, then both extensions MUST be processed
+ independently and the certificate MUST only be used for a purpose
+ consistent with both extensions. If there is no purpose consistent
+ with both extensions, then the certificate MUST NOT be used for any
+ purpose.
+
+ The following key usage purposes are defined:
+
+ anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 }
+
+ id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
+
+ id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
+ -- TLS WWW server authentication
+ -- Key usage bits that may be consistent: digitalSignature,
+ -- keyEncipherment or keyAgreement
+
+ id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }
+ -- TLS WWW client authentication
+ -- Key usage bits that may be consistent: digitalSignature
+ -- and/or keyAgreement
+
+ id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 }
+ -- Signing of downloadable executable code
+ -- Key usage bits that may be consistent: digitalSignature
+
+ id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 }
+ -- Email protection
+ -- Key usage bits that may be consistent: digitalSignature,
+ -- nonRepudiation, and/or (keyEncipherment or keyAgreement)
+
+ id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
+ -- Binding the hash of an object to a time
+ -- Key usage bits that may be consistent: digitalSignature
+ -- and/or nonRepudiation
+
+ id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
+ -- Signing OCSP responses
+ -- Key usage bits that may be consistent: digitalSignature
+ -- and/or nonRepudiation
+
+4.2.1.13. CRL Distribution Points
+
+ The CRL distribution points extension identifies how CRL information
+ is obtained. The extension SHOULD be non-critical, but this profile
+ RECOMMENDS support for this extension by CAs and applications.
+ Further discussion of CRL management is contained in Section 5.
+
+
+
+Cooper, et al. Standards Track [Page 45]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ The cRLDistributionPoints extension is a SEQUENCE of
+ DistributionPoint. A DistributionPoint consists of three fields,
+ each of which is optional: distributionPoint, reasons, and cRLIssuer.
+ While each of these fields is optional, a DistributionPoint MUST NOT
+ consist of only the reasons field; either distributionPoint or
+ cRLIssuer MUST be present. If the certificate issuer is not the CRL
+ issuer, then the cRLIssuer field MUST be present and contain the Name
+ of the CRL issuer. If the certificate issuer is also the CRL issuer,
+ then conforming CAs MUST omit the cRLIssuer field and MUST include
+ the distributionPoint field.
+
+ When the distributionPoint field is present, it contains either a
+ SEQUENCE of general names or a single value, nameRelativeToCRLIssuer.
+ If the DistributionPointName contains multiple values, each name
+ describes a different mechanism to obtain the same CRL. For example,
+ the same CRL could be available for retrieval through both LDAP and
+ HTTP.
+
+ If the distributionPoint field contains a directoryName, the entry
+ for that directoryName contains the current CRL for the associated
+ reasons and the CRL is issued by the associated cRLIssuer. The CRL
+ may be stored in either the certificateRevocationList or
+ authorityRevocationList attribute. The CRL is to be obtained by the
+ application from whatever directory server is locally configured.
+ The protocol the application uses to access the directory (e.g., DAP
+ or LDAP) is a local matter.
+
+ If the DistributionPointName contains a general name of type URI, the
+ following semantics MUST be assumed: the URI is a pointer to the
+ current CRL for the associated reasons and will be issued by the
+ associated cRLIssuer. When the HTTP or FTP URI scheme is used, the
+ URI MUST point to a single DER encoded CRL as specified in
+ [RFC2585]. HTTP server implementations accessed via the URI SHOULD
+ specify the media type application/pkix-crl in the content-type
+ header field of the response. When the LDAP URI scheme [RFC4516] is
+ used, the URI MUST include a <dn> field containing the distinguished
+ name of the entry holding the CRL, MUST include a single <attrdesc>
+ that contains an appropriate attribute description for the attribute
+ that holds the CRL [RFC4523], and SHOULD include a <host>
+ (e.g., <ldap://ldap.example.com/cn=example%20CA,dc=example,dc=com?
+ certificateRevocationList;binary>). Omitting the <host> (e.g.,
+ <ldap:///cn=CA,dc=example,dc=com?authorityRevocationList;binary>) has
+ the effect of relying on whatever a priori knowledge the client might
+ have to contact an appropriate server. When present,
+ DistributionPointName SHOULD include at least one LDAP or HTTP URI.
+
+ If the DistributionPointName contains the single value
+ nameRelativeToCRLIssuer, the value provides a distinguished name
+
+
+
+Cooper, et al. Standards Track [Page 46]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ fragment. The fragment is appended to the X.500 distinguished name
+ of the CRL issuer to obtain the distribution point name. If the
+ cRLIssuer field in the DistributionPoint is present, then the name
+ fragment is appended to the distinguished name that it contains;
+ otherwise, the name fragment is appended to the certificate issuer
+ distinguished name. Conforming CAs SHOULD NOT use
+ nameRelativeToCRLIssuer to specify distribution point names. The
+ DistributionPointName MUST NOT use the nameRelativeToCRLIssuer
+ alternative when cRLIssuer contains more than one distinguished name.
+
+ If the DistributionPoint omits the reasons field, the CRL MUST
+ include revocation information for all reasons. This profile
+ RECOMMENDS against segmenting CRLs by reason code. When a conforming
+ CA includes a cRLDistributionPoints extension in a certificate, it
+ MUST include at least one DistributionPoint that points to a CRL that
+ covers the certificate for all reasons.
+
+ The cRLIssuer identifies the entity that signs and issues the CRL.
+ If present, the cRLIssuer MUST only contain the distinguished name
+ (DN) from the issuer field of the CRL to which the DistributionPoint
+ is pointing. The encoding of the name in the cRLIssuer field MUST be
+ exactly the same as the encoding in issuer field of the CRL. If the
+ cRLIssuer field is included and the DN in that field does not
+ correspond to an X.500 or LDAP directory entry where CRL is located,
+ then conforming CAs MUST include the distributionPoint field.
+
+ id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 }
+
+ CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
+
+ DistributionPoint ::= SEQUENCE {
+ distributionPoint [0] DistributionPointName OPTIONAL,
+ reasons [1] ReasonFlags OPTIONAL,
+ cRLIssuer [2] GeneralNames OPTIONAL }
+
+ DistributionPointName ::= CHOICE {
+ fullName [0] GeneralNames,
+ nameRelativeToCRLIssuer [1] RelativeDistinguishedName }
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 47]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ ReasonFlags ::= BIT STRING {
+ unused (0),
+ keyCompromise (1),
+ cACompromise (2),
+ affiliationChanged (3),
+ superseded (4),
+ cessationOfOperation (5),
+ certificateHold (6),
+ privilegeWithdrawn (7),
+ aACompromise (8) }
+
+4.2.1.14. Inhibit anyPolicy
+
+ The inhibit anyPolicy extension can be used in certificates issued to
+ CAs. The inhibit anyPolicy extension indicates that the special
+ anyPolicy OID, with the value { 2 5 29 32 0 }, is not considered an
+ explicit match for other certificate policies except when it appears
+ in an intermediate self-issued CA certificate. The value indicates
+ the number of additional non-self-issued certificates that may appear
+ in the path before anyPolicy is no longer permitted. For example, a
+ value of one indicates that anyPolicy may be processed in
+ certificates issued by the subject of this certificate, but not in
+ additional certificates in the path.
+
+ Conforming CAs MUST mark this extension as critical.
+
+ id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 }
+
+ InhibitAnyPolicy ::= SkipCerts
+
+ SkipCerts ::= INTEGER (0..MAX)
+
+4.2.1.15. Freshest CRL (a.k.a. Delta CRL Distribution Point)
+
+ The freshest CRL extension identifies how delta CRL information is
+ obtained. The extension MUST be marked as non-critical by conforming
+ CAs. Further discussion of CRL management is contained in Section 5.
+
+ The same syntax is used for this extension and the
+ cRLDistributionPoints extension, and is described in Section
+ 4.2.1.13. The same conventions apply to both extensions.
+
+ id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 }
+
+ FreshestCRL ::= CRLDistributionPoints
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 48]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+4.2.2. Private Internet Extensions
+
+ This section defines two extensions for use in the Internet Public
+ Key Infrastructure. These extensions may be used to direct
+ applications to on-line information about the issuer or the subject.
+ Each extension contains a sequence of access methods and access
+ locations. The access method is an object identifier that indicates
+ the type of information that is available. The access location is a
+ GeneralName that implicitly specifies the location and format of the
+ information and the method for obtaining the information.
+
+ Object identifiers are defined for the private extensions. The
+ object identifiers associated with the private extensions are defined
+ under the arc id-pe within the arc id-pkix. Any future extensions
+ defined for the Internet PKI are also expected to be defined under
+ the arc id-pe.
+
+ id-pkix OBJECT IDENTIFIER ::=
+ { iso(1) identified-organization(3) dod(6) internet(1)
+ security(5) mechanisms(5) pkix(7) }
+
+ id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
+
+4.2.2.1. Authority Information Access
+
+ The authority information access extension indicates how to access
+ information and services for the issuer of the certificate in which
+ the extension appears. Information and services may include on-line
+ validation services and CA policy data. (The location of CRLs is not
+ specified in this extension; that information is provided by the
+ cRLDistributionPoints extension.) This extension may be included in
+ end entity or CA certificates. Conforming CAs MUST mark this
+ extension as non-critical.
+
+ id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }
+
+ AuthorityInfoAccessSyntax ::=
+ SEQUENCE SIZE (1..MAX) OF AccessDescription
+
+ AccessDescription ::= SEQUENCE {
+ accessMethod OBJECT IDENTIFIER,
+ accessLocation GeneralName }
+
+ id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
+
+ id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }
+
+ id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }
+
+
+
+Cooper, et al. Standards Track [Page 49]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ Each entry in the sequence AuthorityInfoAccessSyntax describes the
+ format and location of additional information provided by the issuer
+ of the certificate in which this extension appears. The type and
+ format of the information are specified by the accessMethod field;
+ the accessLocation field specifies the location of the information.
+ The retrieval mechanism may be implied by the accessMethod or
+ specified by accessLocation.
+
+ This profile defines two accessMethod OIDs: id-ad-caIssuers and
+ id-ad-ocsp.
+
+ In a public key certificate, the id-ad-caIssuers OID is used when the
+ additional information lists certificates that were issued to the CA
+ that issued the certificate containing this extension. The
+ referenced CA issuers description is intended to aid certificate
+ users in the selection of a certification path that terminates at a
+ point trusted by the certificate user.
+
+ When id-ad-caIssuers appears as accessMethod, the accessLocation
+ field describes the referenced description server and the access
+ protocol to obtain the referenced description. The accessLocation
+ field is defined as a GeneralName, which can take several forms.
+
+ When the accessLocation is a directoryName, the information is to be
+ obtained by the application from whatever directory server is locally
+ configured. The entry for the directoryName contains CA certificates
+ in the crossCertificatePair and/or cACertificate attributes as
+ specified in [RFC4523]. The protocol that application uses to access
+ the directory (e.g., DAP or LDAP) is a local matter.
+
+ Where the information is available via LDAP, the accessLocation
+ SHOULD be a uniformResourceIdentifier. The LDAP URI [RFC4516] MUST
+ include a <dn> field containing the distinguished name of the entry
+ holding the certificates, MUST include an <attributes> field that
+ lists appropriate attribute descriptions for the attributes that hold
+ the DER encoded certificates or cross-certificate pairs [RFC4523],
+ and SHOULD include a <host> (e.g., <ldap://ldap.example.com/cn=CA,
+ dc=example,dc=com?cACertificate;binary,crossCertificatePair;binary>).
+ Omitting the <host> (e.g., <ldap:///cn=exampleCA,dc=example,dc=com?
+ cACertificate;binary>) has the effect of relying on whatever a priori
+ knowledge the client might have to contact an appropriate server.
+
+ Where the information is available via HTTP or FTP, accessLocation
+ MUST be a uniformResourceIdentifier and the URI MUST point to either
+ a single DER encoded certificate as specified in [RFC2585] or a
+ collection of certificates in a BER or DER encoded "certs-only" CMS
+ message as specified in [RFC2797].
+
+
+
+
+Cooper, et al. Standards Track [Page 50]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ Conforming applications that support HTTP or FTP for accessing
+ certificates MUST be able to accept individual DER encoded
+ certificates and SHOULD be able to accept "certs-only" CMS messages.
+
+ HTTP server implementations accessed via the URI SHOULD specify the
+ media type application/pkix-cert [RFC2585] in the content-type header
+ field of the response for a single DER encoded certificate and SHOULD
+ specify the media type application/pkcs7-mime [RFC2797] in the
+ content-type header field of the response for "certs-only" CMS
+ messages. For FTP, the name of a file that contains a single DER
+ encoded certificate SHOULD have a suffix of ".cer" [RFC2585] and the
+ name of a file that contains a "certs-only" CMS message SHOULD have a
+ suffix of ".p7c" [RFC2797]. Consuming clients may use the media type
+ or file extension as a hint to the content, but should not depend
+ solely on the presence of the correct media type or file extension in
+ the server response.
+
+ The semantics of other id-ad-caIssuers accessLocation name forms are
+ not defined.
+
+ An authorityInfoAccess extension may include multiple instances of
+ the id-ad-caIssuers accessMethod. The different instances may
+ specify different methods for accessing the same information or may
+ point to different information. When the id-ad-caIssuers
+ accessMethod is used, at least one instance SHOULD specify an
+ accessLocation that is an HTTP [RFC2616] or LDAP [RFC4516] URI.
+
+ The id-ad-ocsp OID is used when revocation information for the
+ certificate containing this extension is available using the Online
+ Certificate Status Protocol (OCSP) [RFC2560].
+
+ When id-ad-ocsp appears as accessMethod, the accessLocation field is
+ the location of the OCSP responder, using the conventions defined in
+ [RFC2560].
+
+ Additional access descriptors may be defined in other PKIX
+ specifications.
+
+4.2.2.2. Subject Information Access
+
+ The subject information access extension indicates how to access
+ information and services for the subject of the certificate in which
+ the extension appears. When the subject is a CA, information and
+ services may include certificate validation services and CA policy
+ data. When the subject is an end entity, the information describes
+ the type of services offered and how to access them. In this case,
+ the contents of this extension are defined in the protocol
+
+
+
+
+Cooper, et al. Standards Track [Page 51]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ specifications for the supported services. This extension may be
+ included in end entity or CA certificates. Conforming CAs MUST mark
+ this extension as non-critical.
+
+ id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 }
+
+ SubjectInfoAccessSyntax ::=
+ SEQUENCE SIZE (1..MAX) OF AccessDescription
+
+ AccessDescription ::= SEQUENCE {
+ accessMethod OBJECT IDENTIFIER,
+ accessLocation GeneralName }
+
+ Each entry in the sequence SubjectInfoAccessSyntax describes the
+ format and location of additional information provided by the subject
+ of the certificate in which this extension appears. The type and
+ format of the information are specified by the accessMethod field;
+ the accessLocation field specifies the location of the information.
+ The retrieval mechanism may be implied by the accessMethod or
+ specified by accessLocation.
+
+ This profile defines one access method to be used when the subject is
+ a CA and one access method to be used when the subject is an end
+ entity. Additional access methods may be defined in the future in
+ the protocol specifications for other services.
+
+ The id-ad-caRepository OID is used when the subject is a CA that
+ publishes certificates it issues in a repository. The accessLocation
+ field is defined as a GeneralName, which can take several forms.
+
+ When the accessLocation is a directoryName, the information is to be
+ obtained by the application from whatever directory server is locally
+ configured. When the extension is used to point to CA certificates,
+ the entry for the directoryName contains CA certificates in the
+ crossCertificatePair and/or cACertificate attributes as specified in
+ [RFC4523]. The protocol the application uses to access the directory
+ (e.g., DAP or LDAP) is a local matter.
+
+ Where the information is available via LDAP, the accessLocation
+ SHOULD be a uniformResourceIdentifier. The LDAP URI [RFC4516] MUST
+ include a <dn> field containing the distinguished name of the entry
+ holding the certificates, MUST include an <attributes> field that
+ lists appropriate attribute descriptions for the attributes that hold
+ the DER encoded certificates or cross-certificate pairs [RFC4523],
+ and SHOULD include a <host> (e.g., <ldap://ldap.example.com/cn=CA,
+ dc=example,dc=com?cACertificate;binary,crossCertificatePair;binary>).
+
+
+
+
+
+Cooper, et al. Standards Track [Page 52]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ Omitting the <host> (e.g., <ldap:///cn=exampleCA,dc=example,dc=com?
+ cACertificate;binary>) has the effect of relying on whatever a priori
+ knowledge the client might have to contact an appropriate server.
+
+ Where the information is available via HTTP or FTP, accessLocation
+ MUST be a uniformResourceIdentifier and the URI MUST point to either
+ a single DER encoded certificate as specified in [RFC2585] or a
+ collection of certificates in a BER or DER encoded "certs-only" CMS
+ message as specified in [RFC2797].
+
+ Conforming applications that support HTTP or FTP for accessing
+ certificates MUST be able to accept individual DER encoded
+ certificates and SHOULD be able to accept "certs-only" CMS messages.
+
+ HTTP server implementations accessed via the URI SHOULD specify the
+ media type application/pkix-cert [RFC2585] in the content-type header
+ field of the response for a single DER encoded certificate and SHOULD
+ specify the media type application/pkcs7-mime [RFC2797] in the
+ content-type header field of the response for "certs-only" CMS
+ messages. For FTP, the name of a file that contains a single DER
+ encoded certificate SHOULD have a suffix of ".cer" [RFC2585] and the
+ name of a file that contains a "certs-only" CMS message SHOULD have a
+ suffix of ".p7c" [RFC2797]. Consuming clients may use the media type
+ or file extension as a hint to the content, but should not depend
+ solely on the presence of the correct media type or file extension in
+ the server response.
+
+ The semantics of other id-ad-caRepository accessLocation name forms
+ are not defined.
+
+ A subjectInfoAccess extension may include multiple instances of the
+ id-ad-caRepository accessMethod. The different instances may specify
+ different methods for accessing the same information or may point to
+ different information. When the id-ad-caRepository accessMethod is
+ used, at least one instance SHOULD specify an accessLocation that is
+ an HTTP [RFC2616] or LDAP [RFC4516] URI.
+
+ The id-ad-timeStamping OID is used when the subject offers
+ timestamping services using the Time Stamp Protocol defined in
+ [RFC3161]. Where the timestamping services are available via HTTP or
+ FTP, accessLocation MUST be a uniformResourceIdentifier. Where the
+ timestamping services are available via electronic mail,
+ accessLocation MUST be an rfc822Name. Where timestamping services
+ are available using TCP/IP, the dNSName or iPAddress name forms may
+ be used. The semantics of other name forms of accessLocation (when
+ accessMethod is id-ad-timeStamping) are not defined by this
+ specification.
+
+
+
+
+Cooper, et al. Standards Track [Page 53]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ Additional access descriptors may be defined in other PKIX
+ specifications.
+
+ id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
+
+ id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 }
+
+ id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 }
+
+5. CRL and CRL Extensions Profile
+
+ As discussed above, one goal of this X.509 v2 CRL profile is to
+ foster the creation of an interoperable and reusable Internet PKI.
+ To achieve this goal, guidelines for the use of extensions are
+ specified, and some assumptions are made about the nature of
+ information included in the CRL.
+
+ CRLs may be used in a wide range of applications and environments
+ covering a broad spectrum of interoperability goals and an even
+ broader spectrum of operational and assurance requirements. This
+ profile establishes a common baseline for generic applications
+ requiring broad interoperability. The profile defines a set of
+ information that can be expected in every CRL. Also, the profile
+ defines common locations within the CRL for frequently used
+ attributes as well as common representations for these attributes.
+
+ CRL issuers issue CRLs. The CRL issuer is either the CA or an entity
+ that has been authorized by the CA to issue CRLs. CAs publish CRLs
+ to provide status information about the certificates they issued.
+ However, a CA may delegate this responsibility to another trusted
+ authority.
+
+ Each CRL has a particular scope. The CRL scope is the set of
+ certificates that could appear on a given CRL. For example, the
+ scope could be "all certificates issued by CA X", "all CA
+ certificates issued by CA X", "all certificates issued by CA X that
+ have been revoked for reasons of key compromise and CA compromise",
+ or a set of certificates based on arbitrary local information, such
+ as "all certificates issued to the NIST employees located in
+ Boulder".
+
+ A complete CRL lists all unexpired certificates, within its scope,
+ that have been revoked for one of the revocation reasons covered by
+ the CRL scope. A full and complete CRL lists all unexpired
+ certificates issued by a CA that have been revoked for any reason.
+ (Note that since CAs and CRL issuers are identified by name, the
+ scope of a CRL is not affected by the key used to sign the CRL or the
+ key(s) used to sign certificates.)
+
+
+
+Cooper, et al. Standards Track [Page 54]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ If the scope of the CRL includes one or more certificates issued by
+ an entity other than the CRL issuer, then it is an indirect CRL. The
+ scope of an indirect CRL may be limited to certificates issued by a
+ single CA or may include certificates issued by multiple CAs. If the
+ issuer of the indirect CRL is a CA, then the scope of the indirect
+ CRL MAY also include certificates issued by the issuer of the CRL.
+
+ The CRL issuer MAY also generate delta CRLs. A delta CRL only lists
+ those certificates, within its scope, whose revocation status has
+ changed since the issuance of a referenced complete CRL. The
+ referenced complete CRL is referred to as a base CRL. The scope of a
+ delta CRL MUST be the same as the base CRL that it references.
+
+ This profile defines one private Internet CRL extension but does not
+ define any private CRL entry extensions.
+
+ Environments with additional or special purpose requirements may
+ build on this profile or may replace it.
+
+ Conforming CAs are not required to issue CRLs if other revocation or
+ certificate status mechanisms are provided. When CRLs are issued,
+ the CRLs MUST be version 2 CRLs, include the date by which the next
+ CRL will be issued in the nextUpdate field (Section 5.1.2.5), include
+ the CRL number extension (Section 5.2.3), and include the authority
+ key identifier extension (Section 5.2.1). Conforming applications
+ that support CRLs are REQUIRED to process both version 1 and version
+ 2 complete CRLs that provide revocation information for all
+ certificates issued by one CA. Conforming applications are not
+ required to support processing of delta CRLs, indirect CRLs, or CRLs
+ with a scope other than all certificates issued by one CA.
+
+5.1. CRL Fields
+
+ The X.509 v2 CRL syntax is as follows. For signature calculation,
+ the data that is to be signed is ASN.1 DER encoded. ASN.1 DER
+ encoding is a tag, length, value encoding system for each element.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 55]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ CertificateList ::= SEQUENCE {
+ tbsCertList TBSCertList,
+ signatureAlgorithm AlgorithmIdentifier,
+ signatureValue BIT STRING }
+
+ TBSCertList ::= SEQUENCE {
+ version Version OPTIONAL,
+ -- if present, MUST be v2
+ signature AlgorithmIdentifier,
+ issuer Name,
+ thisUpdate Time,
+ nextUpdate Time OPTIONAL,
+ revokedCertificates SEQUENCE OF SEQUENCE {
+ userCertificate CertificateSerialNumber,
+ revocationDate Time,
+ crlEntryExtensions Extensions OPTIONAL
+ -- if present, version MUST be v2
+ } OPTIONAL,
+ crlExtensions [0] EXPLICIT Extensions OPTIONAL
+ -- if present, version MUST be v2
+ }
+
+ -- Version, Time, CertificateSerialNumber, and Extensions
+ -- are all defined in the ASN.1 in Section 4.1
+
+ -- AlgorithmIdentifier is defined in Section 4.1.1.2
+
+ The following items describe the use of the X.509 v2 CRL in the
+ Internet PKI.
+
+5.1.1. CertificateList Fields
+
+ The CertificateList is a SEQUENCE of three required fields. The
+ fields are described in detail in the following subsections.
+
+5.1.1.1. tbsCertList
+
+ The first field in the sequence is the tbsCertList. This field is
+ itself a sequence containing the name of the issuer, issue date,
+ issue date of the next list, the optional list of revoked
+ certificates, and optional CRL extensions. When there are no revoked
+ certificates, the revoked certificates list is absent. When one or
+ more certificates are revoked, each entry on the revoked certificate
+ list is defined by a sequence of user certificate serial number,
+ revocation date, and optional CRL entry extensions.
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 56]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+5.1.1.2. signatureAlgorithm
+
+ The signatureAlgorithm field contains the algorithm identifier for
+ the algorithm used by the CRL issuer to sign the CertificateList.
+ The field is of type AlgorithmIdentifier, which is defined in Section
+ 4.1.1.2. [RFC3279], [RFC4055], and [RFC4491] list supported
+ algorithms for this specification, but other signature algorithms MAY
+ also be supported.
+
+ This field MUST contain the same algorithm identifier as the
+ signature field in the sequence tbsCertList (Section 5.1.2.2).
+
+5.1.1.3. signatureValue
+
+ The signatureValue field contains a digital signature computed upon
+ the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded tbsCertList
+ is used as the input to the signature function. This signature value
+ is encoded as a BIT STRING and included in the CRL signatureValue
+ field. The details of this process are specified for each of the
+ supported algorithms in [RFC3279], [RFC4055], and [RFC4491].
+
+ CAs that are also CRL issuers MAY use one private key to digitally
+ sign certificates and CRLs, or MAY use separate private keys to
+ digitally sign certificates and CRLs. When separate private keys are
+ employed, each of the public keys associated with these private keys
+ is placed in a separate certificate, one with the keyCertSign bit set
+ in the key usage extension, and one with the cRLSign bit set in the
+ key usage extension (Section 4.2.1.3). When separate private keys
+ are employed, certificates issued by the CA contain one authority key
+ identifier, and the corresponding CRLs contain a different authority
+ key identifier. The use of separate CA certificates for validation
+ of certificate signatures and CRL signatures can offer improved
+ security characteristics; however, it imposes a burden on
+ applications, and it might limit interoperability. Many applications
+ construct a certification path, and then validate the certification
+ path (Section 6). CRL checking in turn requires a separate
+ certification path to be constructed and validated for the CA's CRL
+ signature validation certificate. Applications that perform CRL
+ checking MUST support certification path validation when certificates
+ and CRLs are digitally signed with the same CA private key. These
+ applications SHOULD support certification path validation when
+ certificates and CRLs are digitally signed with different CA private
+ keys.
+
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 57]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+5.1.2. Certificate List "To Be Signed"
+
+ The certificate list to be signed, or TBSCertList, is a sequence of
+ required and optional fields. The required fields identify the CRL
+ issuer, the algorithm used to sign the CRL, and the date and time the
+ CRL was issued.
+
+ Optional fields include the date and time by which the CRL issuer
+ will issue the next CRL, lists of revoked certificates, and CRL
+ extensions. The revoked certificate list is optional to support the
+ case where a CA has not revoked any unexpired certificates that it
+ has issued. This profile requires conforming CRL issuers to include
+ the nextUpdate field and the CRL number and authority key identifier
+ CRL extensions in all CRLs issued.
+
+5.1.2.1. Version
+
+ This optional field describes the version of the encoded CRL. When
+ extensions are used, as required by this profile, this field MUST be
+ present and MUST specify version 2 (the integer value is 1).
+
+5.1.2.2. Signature
+
+ This field contains the algorithm identifier for the algorithm used
+ to sign the CRL. [RFC3279], [RFC4055], and [RFC4491] list OIDs for
+ the most popular signature algorithms used in the Internet PKI.
+
+ This field MUST contain the same algorithm identifier as the
+ signatureAlgorithm field in the sequence CertificateList (Section
+ 5.1.1.2).
+
+5.1.2.3. Issuer Name
+
+ The issuer name identifies the entity that has signed and issued the
+ CRL. The issuer identity is carried in the issuer field.
+ Alternative name forms may also appear in the issuerAltName extension
+ (Section 5.2.2). The issuer field MUST contain a non-empty X.500
+ distinguished name (DN). The issuer field is defined as the X.501
+ type Name, and MUST follow the encoding rules for the issuer name
+ field in the certificate (Section 4.1.2.4).
+
+5.1.2.4. This Update
+
+ This field indicates the issue date of this CRL. thisUpdate may be
+ encoded as UTCTime or GeneralizedTime.
+
+ CRL issuers conforming to this profile MUST encode thisUpdate as
+ UTCTime for dates through the year 2049. CRL issuers conforming to
+
+
+
+Cooper, et al. Standards Track [Page 58]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ this profile MUST encode thisUpdate as GeneralizedTime for dates in
+ the year 2050 or later. Conforming applications MUST be able to
+ process dates that are encoded in either UTCTime or GeneralizedTime.
+
+ Where encoded as UTCTime, thisUpdate MUST be specified and
+ interpreted as defined in Section 4.1.2.5.1. Where encoded as
+ GeneralizedTime, thisUpdate MUST be specified and interpreted as
+ defined in Section 4.1.2.5.2.
+
+5.1.2.5. Next Update
+
+ This field indicates the date by which the next CRL will be issued.
+ The next CRL could be issued before the indicated date, but it will
+ not be issued any later than the indicated date. CRL issuers SHOULD
+ issue CRLs with a nextUpdate time equal to or later than all previous
+ CRLs. nextUpdate may be encoded as UTCTime or GeneralizedTime.
+
+ Conforming CRL issuers MUST include the nextUpdate field in all CRLs.
+ Note that the ASN.1 syntax of TBSCertList describes this field as
+ OPTIONAL, which is consistent with the ASN.1 structure defined in
+ [X.509]. The behavior of clients processing CRLs that omit
+ nextUpdate is not specified by this profile.
+
+ CRL issuers conforming to this profile MUST encode nextUpdate as
+ UTCTime for dates through the year 2049. CRL issuers conforming to
+ this profile MUST encode nextUpdate as GeneralizedTime for dates in
+ the year 2050 or later. Conforming applications MUST be able to
+ process dates that are encoded in either UTCTime or GeneralizedTime.
+
+ Where encoded as UTCTime, nextUpdate MUST be specified and
+ interpreted as defined in Section 4.1.2.5.1. Where encoded as
+ GeneralizedTime, nextUpdate MUST be specified and interpreted as
+ defined in Section 4.1.2.5.2.
+
+5.1.2.6. Revoked Certificates
+
+ When there are no revoked certificates, the revoked certificates list
+ MUST be absent. Otherwise, revoked certificates are listed by their
+ serial numbers. Certificates revoked by the CA are uniquely
+ identified by the certificate serial number. The date on which the
+ revocation occurred is specified. The time for revocationDate MUST
+ be expressed as described in Section 5.1.2.4. Additional information
+ may be supplied in CRL entry extensions; CRL entry extensions are
+ discussed in Section 5.3.
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 59]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+5.1.2.7. Extensions
+
+ This field may only appear if the version is 2 (Section 5.1.2.1). If
+ present, this field is a sequence of one or more CRL extensions. CRL
+ extensions are discussed in Section 5.2.
+
+5.2. CRL Extensions
+
+ The extensions defined by ANSI X9, ISO/IEC, and ITU-T for X.509 v2
+ CRLs [X.509] [X9.55] provide methods for associating additional
+ attributes with CRLs. The X.509 v2 CRL format also allows
+ communities to define private extensions to carry information unique
+ to those communities. Each extension in a CRL may be designated as
+ critical or non-critical. If a CRL contains a critical extension
+ that the application cannot process, then the application MUST NOT
+ use that CRL to determine the status of certificates. However,
+ applications may ignore unrecognized non-critical extensions. The
+ following subsections present those extensions used within Internet
+ CRLs. Communities may elect to include extensions in CRLs that are
+ not defined in this specification. However, caution should be
+ exercised in adopting any critical extensions in CRLs that might be
+ used in a general context.
+
+ Conforming CRL issuers are REQUIRED to include the authority key
+ identifier (Section 5.2.1) and the CRL number (Section 5.2.3)
+ extensions in all CRLs issued.
+
+5.2.1. Authority Key Identifier
+
+ The authority key identifier extension provides a means of
+ identifying the public key corresponding to the private key used to
+ sign a CRL. The identification can be based on either the key
+ identifier (the subject key identifier in the CRL signer's
+ certificate) or the issuer name and serial number. This extension is
+ especially useful where an issuer has more than one signing key,
+ either due to multiple concurrent key pairs or due to changeover.
+
+ Conforming CRL issuers MUST use the key identifier method, and MUST
+ include this extension in all CRLs issued.
+
+ The syntax for this CRL extension is defined in Section 4.2.1.1.
+
+5.2.2. Issuer Alternative Name
+
+ The issuer alternative name extension allows additional identities to
+ be associated with the issuer of the CRL. Defined options include an
+ electronic mail address (rfc822Name), a DNS name, an IP address, and
+ a URI. Multiple instances of a name form and multiple name forms may
+
+
+
+Cooper, et al. Standards Track [Page 60]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ be included. Whenever such identities are used, the issuer
+ alternative name extension MUST be used; however, a DNS name MAY be
+ represented in the issuer field using the domainComponent attribute
+ as described in Section 4.1.2.4.
+
+ Conforming CRL issuers SHOULD mark the issuerAltName extension as
+ non-critical.
+
+ The OID and syntax for this CRL extension are defined in Section
+ 4.2.1.7.
+
+5.2.3. CRL Number
+
+ The CRL number is a non-critical CRL extension that conveys a
+ monotonically increasing sequence number for a given CRL scope and
+ CRL issuer. This extension allows users to easily determine when a
+ particular CRL supersedes another CRL. CRL numbers also support the
+ identification of complementary complete CRLs and delta CRLs. CRL
+ issuers conforming to this profile MUST include this extension in all
+ CRLs and MUST mark this extension as non-critical.
+
+ If a CRL issuer generates delta CRLs in addition to complete CRLs for
+ a given scope, the complete CRLs and delta CRLs MUST share one
+ numbering sequence. If a delta CRL and a complete CRL that cover the
+ same scope are issued at the same time, they MUST have the same CRL
+ number and provide the same revocation information. That is, the
+ combination of the delta CRL and an acceptable complete CRL MUST
+ provide the same revocation information as the simultaneously issued
+ complete CRL.
+
+ If a CRL issuer generates two CRLs (two complete CRLs, two delta
+ CRLs, or a complete CRL and a delta CRL) for the same scope at
+ different times, the two CRLs MUST NOT have the same CRL number.
+ That is, if the this update field (Section 5.1.2.4) in the two CRLs
+ are not identical, the CRL numbers MUST be different.
+
+ Given the requirements above, CRL numbers can be expected to contain
+ long integers. CRL verifiers MUST be able to handle CRLNumber values
+ up to 20 octets. Conforming CRL issuers MUST NOT use CRLNumber
+ values longer than 20 octets.
+
+ id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
+
+ CRLNumber ::= INTEGER (0..MAX)
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 61]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+5.2.4. Delta CRL Indicator
+
+ The delta CRL indicator is a critical CRL extension that identifies a
+ CRL as being a delta CRL. Delta CRLs contain updates to revocation
+ information previously distributed, rather than all the information
+ that would appear in a complete CRL. The use of delta CRLs can
+ significantly reduce network load and processing time in some
+ environments. Delta CRLs are generally smaller than the CRLs they
+ update, so applications that obtain delta CRLs consume less network
+ bandwidth than applications that obtain the corresponding complete
+ CRLs. Applications that store revocation information in a format
+ other than the CRL structure can add new revocation information to
+ the local database without reprocessing information.
+
+ The delta CRL indicator extension contains the single value of type
+ BaseCRLNumber. The CRL number identifies the CRL, complete for a
+ given scope, that was used as the starting point in the generation of
+ this delta CRL. A conforming CRL issuer MUST publish the referenced
+ base CRL as a complete CRL. The delta CRL contains all updates to
+ the revocation status for that same scope. The combination of a
+ delta CRL plus the referenced base CRL is equivalent to a complete
+ CRL, for the applicable scope, at the time of publication of the
+ delta CRL.
+
+ When a conforming CRL issuer generates a delta CRL, the delta CRL
+ MUST include a critical delta CRL indicator extension.
+
+ When a delta CRL is issued, it MUST cover the same set of reasons and
+ the same set of certificates that were covered by the base CRL it
+ references. That is, the scope of the delta CRL MUST be the same as
+ the scope of the complete CRL referenced as the base. The referenced
+ base CRL and the delta CRL MUST omit the issuing distribution point
+ extension or contain identical issuing distribution point extensions.
+ Further, the CRL issuer MUST use the same private key to sign the
+ delta CRL and any complete CRL that it can be used to update.
+
+ An application that supports delta CRLs can construct a CRL that is
+ complete for a given scope by combining a delta CRL for that scope
+ with either an issued CRL that is complete for that scope or a
+ locally constructed CRL that is complete for that scope.
+
+ When a delta CRL is combined with a complete CRL or a locally
+ constructed CRL, the resulting locally constructed CRL has the CRL
+ number specified in the CRL number extension found in the delta CRL
+ used in its construction. In addition, the resulting locally
+ constructed CRL has the thisUpdate and nextUpdate times specified in
+
+
+
+
+
+Cooper, et al. Standards Track [Page 62]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ the corresponding fields of the delta CRL used in its construction.
+ In addition, the locally constructed CRL inherits the issuing
+ distribution point from the delta CRL.
+
+ A complete CRL and a delta CRL MAY be combined if the following four
+ conditions are satisfied:
+
+ (a) The complete CRL and delta CRL have the same issuer.
+
+ (b) The complete CRL and delta CRL have the same scope. The two
+ CRLs have the same scope if either of the following
+ conditions are met:
+
+ (1) The issuingDistributionPoint extension is omitted from
+ both the complete CRL and the delta CRL.
+
+ (2) The issuingDistributionPoint extension is present in both
+ the complete CRL and the delta CRL, and the values for
+ each of the fields in the extensions are the same in both
+ CRLs.
+
+ (c) The CRL number of the complete CRL is equal to or greater
+ than the BaseCRLNumber specified in the delta CRL. That is,
+ the complete CRL contains (at a minimum) all the revocation
+ information held by the referenced base CRL.
+
+ (d) The CRL number of the complete CRL is less than the CRL
+ number of the delta CRL. That is, the delta CRL follows the
+ complete CRL in the numbering sequence.
+
+ CRL issuers MUST ensure that the combination of a delta CRL and any
+ appropriate complete CRL accurately reflects the current revocation
+ status. The CRL issuer MUST include an entry in the delta CRL for
+ each certificate within the scope of the delta CRL whose status has
+ changed since the generation of the referenced base CRL:
+
+ (a) If the certificate is revoked for a reason included in the
+ scope of the CRL, list the certificate as revoked.
+
+ (b) If the certificate is valid and was listed on the referenced
+ base CRL or any subsequent CRL with reason code
+ certificateHold, and the reason code certificateHold is
+ included in the scope of the CRL, list the certificate with
+ the reason code removeFromCRL.
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 63]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ (c) If the certificate is revoked for a reason outside the scope
+ of the CRL, but the certificate was listed on the referenced
+ base CRL or any subsequent CRL with a reason code included in
+ the scope of this CRL, list the certificate as revoked but
+ omit the reason code.
+
+ (d) If the certificate is revoked for a reason outside the scope
+ of the CRL and the certificate was neither listed on the
+ referenced base CRL nor any subsequent CRL with a reason code
+ included in the scope of this CRL, do not list the
+ certificate on this CRL.
+
+ The status of a certificate is considered to have changed if it is
+ revoked (for any revocation reason, including certificateHold), if it
+ is released from hold, or if its revocation reason changes.
+
+ It is appropriate to list a certificate with reason code
+ removeFromCRL on a delta CRL even if the certificate was not on hold
+ in the referenced base CRL. If the certificate was placed on hold in
+ any CRL issued after the base but before this delta CRL and then
+ released from hold, it MUST be listed on the delta CRL with
+ revocation reason removeFromCRL.
+
+ A CRL issuer MAY optionally list a certificate on a delta CRL with
+ reason code removeFromCRL if the notAfter time specified in the
+ certificate precedes the thisUpdate time specified in the delta CRL
+ and the certificate was listed on the referenced base CRL or in any
+ CRL issued after the base but before this delta CRL.
+
+ If a certificate revocation notice first appears on a delta CRL, then
+ it is possible for the certificate validity period to expire before
+ the next complete CRL for the same scope is issued. In this case,
+ the revocation notice MUST be included in all subsequent delta CRLs
+ until the revocation notice is included on at least one explicitly
+ issued complete CRL for this scope.
+
+ An application that supports delta CRLs MUST be able to construct a
+ current complete CRL by combining a previously issued complete CRL
+ and the most current delta CRL. An application that supports delta
+ CRLs MAY also be able to construct a current complete CRL by
+ combining a previously locally constructed complete CRL and the
+ current delta CRL. A delta CRL is considered to be the current one
+ if the current time is between the times contained in the thisUpdate
+ and nextUpdate fields. Under some circumstances, the CRL issuer may
+ publish one or more delta CRLs before the time indicated by the
+ nextUpdate field. If more than one current delta CRL for a given
+ scope is encountered, the application SHOULD consider the one with
+ the latest value in thisUpdate to be the most current one.
+
+
+
+Cooper, et al. Standards Track [Page 64]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
+
+ BaseCRLNumber ::= CRLNumber
+
+5.2.5. Issuing Distribution Point
+
+ The issuing distribution point is a critical CRL extension that
+ identifies the CRL distribution point and scope for a particular CRL,
+ and it indicates whether the CRL covers revocation for end entity
+ certificates only, CA certificates only, attribute certificates only,
+ or a limited set of reason codes. Although the extension is
+ critical, conforming implementations are not required to support this
+ extension. However, implementations that do not support this
+ extension MUST either treat the status of any certificate not listed
+ on this CRL as unknown or locate another CRL that does not contain
+ any unrecognized critical extensions.
+
+ The CRL is signed using the CRL issuer's private key. CRL
+ distribution points do not have their own key pairs. If the CRL is
+ stored in the X.500 directory, it is stored in the directory entry
+ corresponding to the CRL distribution point, which may be different
+ from the directory entry of the CRL issuer.
+
+ The reason codes associated with a distribution point MUST be
+ specified in onlySomeReasons. If onlySomeReasons does not appear,
+ the distribution point MUST contain revocations for all reason codes.
+ CAs may use CRL distribution points to partition the CRL on the basis
+ of compromise and routine revocation. In this case, the revocations
+ with reason code keyCompromise (1), cACompromise (2), and
+ aACompromise (8) appear in one distribution point, and the
+ revocations with other reason codes appear in another distribution
+ point.
+
+ If a CRL includes an issuingDistributionPoint extension with
+ onlySomeReasons present, then every certificate in the scope of the
+ CRL that is revoked MUST be assigned a revocation reason other than
+ unspecified. The assigned revocation reason is used to determine on
+ which CRL(s) to list the revoked certificate, however, there is no
+ requirement to include the reasonCode CRL entry extension in the
+ corresponding CRL entry.
+
+ The syntax and semantics for the distributionPoint field are the same
+ as for the distributionPoint field in the cRLDistributionPoints
+ extension (Section 4.2.1.13). If the distributionPoint field is
+ present, then it MUST include at least one of names from the
+ corresponding distributionPoint field of the cRLDistributionPoints
+
+
+
+
+
+Cooper, et al. Standards Track [Page 65]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ extension of every certificate that is within the scope of this CRL.
+ The identical encoding MUST be used in the distributionPoint fields
+ of the certificate and the CRL.
+
+ If the distributionPoint field is absent, the CRL MUST contain
+ entries for all revoked unexpired certificates issued by the CRL
+ issuer, if any, within the scope of the CRL.
+
+ If the scope of the CRL only includes certificates issued by the CRL
+ issuer, then the indirectCRL boolean MUST be set to FALSE.
+ Otherwise, if the scope of the CRL includes certificates issued by
+ one or more authorities other than the CRL issuer, the indirectCRL
+ boolean MUST be set to TRUE. The authority responsible for each
+ entry is indicated by the certificate issuer CRL entry extension
+ (Section 5.3.3).
+
+ If the scope of the CRL only includes end entity public key
+ certificates, then onlyContainsUserCerts MUST be set to TRUE. If the
+ scope of the CRL only includes CA certificates, then
+ onlyContainsCACerts MUST be set to TRUE. If either
+ onlyContainsUserCerts or onlyContainsCACerts is set to TRUE, then the
+ scope of the CRL MUST NOT include any version 1 or version 2
+ certificates. Conforming CRLs issuers MUST set the
+ onlyContainsAttributeCerts boolean to FALSE.
+
+ Conforming CRLs issuers MUST NOT issue CRLs where the DER encoding of
+ the issuing distribution point extension is an empty sequence. That
+ is, if onlyContainsUserCerts, onlyContainsCACerts, indirectCRL, and
+ onlyContainsAttributeCerts are all FALSE, then either the
+ distributionPoint field or the onlySomeReasons field MUST be present.
+
+ id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }
+
+ IssuingDistributionPoint ::= SEQUENCE {
+ distributionPoint [0] DistributionPointName OPTIONAL,
+ onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE,
+ onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE,
+ onlySomeReasons [3] ReasonFlags OPTIONAL,
+ indirectCRL [4] BOOLEAN DEFAULT FALSE,
+ onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
+
+ -- at most one of onlyContainsUserCerts, onlyContainsCACerts,
+ -- and onlyContainsAttributeCerts may be set to TRUE.
+
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 66]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+5.2.6. Freshest CRL (a.k.a. Delta CRL Distribution Point)
+
+ The freshest CRL extension identifies how delta CRL information for
+ this complete CRL is obtained. Conforming CRL issuers MUST mark this
+ extension as non-critical. This extension MUST NOT appear in delta
+ CRLs.
+
+ The same syntax is used for this extension as the
+ cRLDistributionPoints certificate extension, and is described in
+ Section 4.2.1.13. However, only the distribution point field is
+ meaningful in this context. The reasons and cRLIssuer fields MUST be
+ omitted from this CRL extension.
+
+ Each distribution point name provides the location at which a delta
+ CRL for this complete CRL can be found. The scope of these delta
+ CRLs MUST be the same as the scope of this complete CRL. The
+ contents of this CRL extension are only used to locate delta CRLs;
+ the contents are not used to validate the CRL or the referenced delta
+ CRLs. The encoding conventions defined for distribution points in
+ Section 4.2.1.13 apply to this extension.
+
+ id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 }
+
+ FreshestCRL ::= CRLDistributionPoints
+
+5.2.7. Authority Information Access
+
+ This section defines the use of the Authority Information Access
+ extension in a CRL. The syntax and semantics defined in Section
+ 4.2.2.1 for the certificate extension are also used for the CRL
+ extension.
+
+ This CRL extension MUST be marked as non-critical.
+
+ When present in a CRL, this extension MUST include at least one
+ AccessDescription specifying id-ad-caIssuers as the accessMethod.
+ The id-ad-caIssuers OID is used when the information available lists
+ certificates that can be used to verify the signature on the CRL
+ (i.e., certificates that have a subject name that matches the issuer
+ name on the CRL and that have a subject public key that corresponds
+ to the private key used to sign the CRL). Access method types other
+ than id-ad-caIssuers MUST NOT be included. At least one instance of
+ AccessDescription SHOULD specify an accessLocation that is an HTTP
+ [RFC2616] or LDAP [RFC4516] URI.
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 67]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ Where the information is available via HTTP or FTP, accessLocation
+ MUST be a uniformResourceIdentifier and the URI MUST point to either
+ a single DER encoded certificate as specified in [RFC2585] or a
+ collection of certificates in a BER or DER encoded "certs-only" CMS
+ message as specified in [RFC2797].
+
+ Conforming applications that support HTTP or FTP for accessing
+ certificates MUST be able to accept individual DER encoded
+ certificates and SHOULD be able to accept "certs-only" CMS messages.
+
+ HTTP server implementations accessed via the URI SHOULD specify the
+ media type application/pkix-cert [RFC2585] in the content-type header
+ field of the response for a single DER encoded certificate and SHOULD
+ specify the media type application/pkcs7-mime [RFC2797] in the
+ content-type header field of the response for "certs-only" CMS
+ messages. For FTP, the name of a file that contains a single DER
+ encoded certificate SHOULD have a suffix of ".cer" [RFC2585] and the
+ name of a file that contains a "certs-only" CMS message SHOULD have a
+ suffix of ".p7c" [RFC2797]. Consuming clients may use the media type
+ or file extension as a hint to the content, but should not depend
+ solely on the presence of the correct media type or file extension in
+ the server response.
+
+ When the accessLocation is a directoryName, the information is to be
+ obtained by the application from whatever directory server is locally
+ configured. When one CA public key is used to validate signatures on
+ certificates and CRLs, the desired CA certificate is stored in the
+ crossCertificatePair and/or cACertificate attributes as specified in
+ [RFC4523]. When different public keys are used to validate
+ signatures on certificates and CRLs, the desired certificate is
+ stored in the userCertificate attribute as specified in [RFC4523].
+ Thus, implementations that support the directoryName form of
+ accessLocation MUST be prepared to find the needed certificate in any
+ of these three attributes. The protocol that an application uses to
+ access the directory (e.g., DAP or LDAP) is a local matter.
+
+ Where the information is available via LDAP, the accessLocation
+ SHOULD be a uniformResourceIdentifier. The LDAP URI [RFC4516] MUST
+ include a <dn> field containing the distinguished name of the entry
+ holding the certificates, MUST include an <attributes> field that
+ lists appropriate attribute descriptions for the attributes that hold
+ the DER encoded certificates or cross-certificate pairs [RFC4523],
+ and SHOULD include a <host> (e.g., <ldap://ldap.example.com/cn=CA,
+ dc=example,dc=com?cACertificate;binary,crossCertificatePair;binary>).
+ Omitting the <host> (e.g., <ldap:///cn=exampleCA,dc=example,dc=com?
+ cACertificate;binary>) has the effect of relying on whatever a priori
+ knowledge the client might have to contact an appropriate server.
+
+
+
+
+Cooper, et al. Standards Track [Page 68]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+5.3. CRL Entry Extensions
+
+ The CRL entry extensions defined by ISO/IEC, ITU-T, and ANSI X9 for
+ X.509 v2 CRLs provide methods for associating additional attributes
+ with CRL entries [X.509] [X9.55]. The X.509 v2 CRL format also
+ allows communities to define private CRL entry extensions to carry
+ information unique to those communities. Each extension in a CRL
+ entry may be designated as critical or non-critical. If a CRL
+ contains a critical CRL entry extension that the application cannot
+ process, then the application MUST NOT use that CRL to determine the
+ status of any certificates. However, applications may ignore
+ unrecognized non-critical CRL entry extensions.
+
+ The following subsections present recommended extensions used within
+ Internet CRL entries and standard locations for information.
+ Communities may elect to use additional CRL entry extensions;
+ however, caution should be exercised in adopting any critical CRL
+ entry extensions in CRLs that might be used in a general context.
+
+ Support for the CRL entry extensions defined in this specification is
+ optional for conforming CRL issuers and applications. However, CRL
+ issuers SHOULD include reason codes (Section 5.3.1) and invalidity
+ dates (Section 5.3.2) whenever this information is available.
+
+5.3.1. Reason Code
+
+ The reasonCode is a non-critical CRL entry extension that identifies
+ the reason for the certificate revocation. CRL issuers are strongly
+ encouraged to include meaningful reason codes in CRL entries;
+ however, the reason code CRL entry extension SHOULD be absent instead
+ of using the unspecified (0) reasonCode value.
+
+ The removeFromCRL (8) reasonCode value may only appear in delta CRLs
+ and indicates that a certificate is to be removed from a CRL because
+ either the certificate expired or was removed from hold. All other
+ reason codes may appear in any CRL and indicate that the specified
+ certificate should be considered revoked.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 69]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 }
+
+ -- reasonCode ::= { CRLReason }
+
+ CRLReason ::= ENUMERATED {
+ unspecified (0),
+ keyCompromise (1),
+ cACompromise (2),
+ affiliationChanged (3),
+ superseded (4),
+ cessationOfOperation (5),
+ certificateHold (6),
+ -- value 7 is not used
+ removeFromCRL (8),
+ privilegeWithdrawn (9),
+ aACompromise (10) }
+
+5.3.2. Invalidity Date
+
+ The invalidity date is a non-critical CRL entry extension that
+ provides the date on which it is known or suspected that the private
+ key was compromised or that the certificate otherwise became invalid.
+ This date may be earlier than the revocation date in the CRL entry,
+ which is the date at which the CA processed the revocation. When a
+ revocation is first posted by a CRL issuer in a CRL, the invalidity
+ date may precede the date of issue of earlier CRLs, but the
+ revocation date SHOULD NOT precede the date of issue of earlier CRLs.
+ Whenever this information is available, CRL issuers are strongly
+ encouraged to share it with CRL users.
+
+ The GeneralizedTime values included in this field MUST be expressed
+ in Greenwich Mean Time (Zulu), and MUST be specified and interpreted
+ as defined in Section 4.1.2.5.2.
+
+ id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 }
+
+ InvalidityDate ::= GeneralizedTime
+
+5.3.3. Certificate Issuer
+
+ This CRL entry extension identifies the certificate issuer associated
+ with an entry in an indirect CRL, that is, a CRL that has the
+ indirectCRL indicator set in its issuing distribution point
+ extension. When present, the certificate issuer CRL entry extension
+ includes one or more names from the issuer field and/or issuer
+ alternative name extension of the certificate that corresponds to the
+ CRL entry. If this extension is not present on the first entry in an
+ indirect CRL, the certificate issuer defaults to the CRL issuer. On
+
+
+
+Cooper, et al. Standards Track [Page 70]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ subsequent entries in an indirect CRL, if this extension is not
+ present, the certificate issuer for the entry is the same as that for
+ the preceding entry. This field is defined as follows:
+
+ id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 }
+
+ CertificateIssuer ::= GeneralNames
+
+ Conforming CRL issuers MUST include in this extension the
+ distinguished name (DN) from the issuer field of the certificate that
+ corresponds to this CRL entry. The encoding of the DN MUST be
+ identical to the encoding used in the certificate.
+
+ CRL issuers MUST mark this extension as critical since an
+ implementation that ignored this extension could not correctly
+ attribute CRL entries to certificates. This specification RECOMMENDS
+ that implementations recognize this extension.
+
+6. Certification Path Validation
+
+ Certification path validation procedures for the Internet PKI are
+ based on the algorithm supplied in [X.509]. Certification path
+ processing verifies the binding between the subject distinguished
+ name and/or subject alternative name and subject public key. The
+ binding is limited by constraints that are specified in the
+ certificates that comprise the path and inputs that are specified by
+ the relying party. The basic constraints and policy constraints
+ extensions allow the certification path processing logic to automate
+ the decision making process.
+
+ This section describes an algorithm for validating certification
+ paths. Conforming implementations of this specification are not
+ required to implement this algorithm, but MUST provide functionality
+ equivalent to the external behavior resulting from this procedure.
+ Any algorithm may be used by a particular implementation so long as
+ it derives the correct result.
+
+ In Section 6.1, the text describes basic path validation. Valid
+ paths begin with certificates issued by a trust anchor. The
+ algorithm requires the public key of the CA, the CA's name, and any
+ constraints upon the set of paths that may be validated using this
+ key.
+
+ The selection of a trust anchor is a matter of policy: it could be
+ the top CA in a hierarchical PKI, the CA that issued the verifier's
+ own certificate(s), or any other CA in a network PKI. The path
+
+
+
+
+
+Cooper, et al. Standards Track [Page 71]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ validation procedure is the same regardless of the choice of trust
+ anchor. In addition, different applications may rely on different
+ trust anchors, or may accept paths that begin with any of a set of
+ trust anchors.
+
+ Section 6.2 describes methods for using the path validation algorithm
+ in specific implementations.
+
+ Section 6.3 describes the steps necessary to determine if a
+ certificate is revoked when CRLs are the revocation mechanism used by
+ the certificate issuer.
+
+6.1. Basic Path Validation
+
+ This text describes an algorithm for X.509 path processing. A
+ conforming implementation MUST include an X.509 path processing
+ procedure that is functionally equivalent to the external behavior of
+ this algorithm. However, support for some of the certificate
+ extensions processed in this algorithm are OPTIONAL for compliant
+ implementations. Clients that do not support these extensions MAY
+ omit the corresponding steps in the path validation algorithm.
+
+ For example, clients are not required to support the policy mappings
+ extension. Clients that do not support this extension MAY omit the
+ path validation steps where policy mappings are processed. Note that
+ clients MUST reject the certificate if it contains an unsupported
+ critical extension.
+
+ While the certificate and CRL profiles specified in Sections 4 and 5
+ of this document specify values for certificate and CRL fields and
+ extensions that are considered to be appropriate for the Internet
+ PKI, the algorithm presented in this section is not limited to
+ accepting certificates and CRLs that conform to these profiles.
+ Therefore, the algorithm only includes checks to verify that the
+ certification path is valid according to X.509 and does not include
+ checks to verify that the certificates and CRLs conform to this
+ profile. While the algorithm could be extended to include checks for
+ conformance to the profiles in Sections 4 and 5, this profile
+ RECOMMENDS against including such checks.
+
+ The algorithm presented in this section validates the certificate
+ with respect to the current date and time. A conforming
+ implementation MAY also support validation with respect to some point
+ in the past. Note that mechanisms are not available for validating a
+ certificate with respect to a time outside the certificate validity
+ period.
+
+
+
+
+
+Cooper, et al. Standards Track [Page 72]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ The trust anchor is an input to the algorithm. There is no
+ requirement that the same trust anchor be used to validate all
+ certification paths. Different trust anchors MAY be used to validate
+ different paths, as discussed further in Section 6.2.
+
+ The primary goal of path validation is to verify the binding between
+ a subject distinguished name or a subject alternative name and
+ subject public key, as represented in the target certificate, based
+ on the public key of the trust anchor. In most cases, the target
+ certificate will be an end entity certificate, but the target
+ certificate may be a CA certificate as long as the subject public key
+ is to be used for a purpose other than verifying the signature on a
+ public key certificate. Verifying the binding between the name and
+ subject public key requires obtaining a sequence of certificates that
+ support that binding. The procedure performed to obtain this
+ sequence of certificates is outside the scope of this specification.
+
+ To meet this goal, the path validation process verifies, among other
+ things, that a prospective certification path (a sequence of n
+ certificates) satisfies the following conditions:
+
+ (a) for all x in {1, ..., n-1}, the subject of certificate x is
+ the issuer of certificate x+1;
+
+ (b) certificate 1 is issued by the trust anchor;
+
+ (c) certificate n is the certificate to be validated (i.e., the
+ target certificate); and
+
+ (d) for all x in {1, ..., n}, the certificate was valid at the
+ time in question.
+
+ A certificate MUST NOT appear more than once in a prospective
+ certification path.
+
+ When the trust anchor is provided in the form of a self-signed
+ certificate, this self-signed certificate is not included as part of
+ the prospective certification path. Information about trust anchors
+ is provided as inputs to the certification path validation algorithm
+ (Section 6.1.1).
+
+ A particular certification path may not, however, be appropriate for
+ all applications. Therefore, an application MAY augment this
+ algorithm to further limit the set of valid paths. The path
+ validation process also determines the set of certificate policies
+ that are valid for this path, based on the certificate policies
+ extension, policy mappings extension, policy constraints extension,
+ and inhibit anyPolicy extension. To achieve this, the path
+
+
+
+Cooper, et al. Standards Track [Page 73]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ validation algorithm constructs a valid policy tree. If the set of
+ certificate policies that are valid for this path is not empty, then
+ the result will be a valid policy tree of depth n, otherwise the
+ result will be a null valid policy tree.
+
+ A certificate is self-issued if the same DN appears in the subject
+ and issuer fields (the two DNs are the same if they match according
+ to the rules specified in Section 7.1). In general, the issuer and
+ subject of the certificates that make up a path are different for
+ each certificate. However, a CA may issue a certificate to itself to
+ support key rollover or changes in certificate policies. These
+ self-issued certificates are not counted when evaluating path length
+ or name constraints.
+
+ This section presents the algorithm in four basic steps: (1)
+ initialization, (2) basic certificate processing, (3) preparation for
+ the next certificate, and (4) wrap-up. Steps (1) and (4) are
+ performed exactly once. Step (2) is performed for all certificates
+ in the path. Step (3) is performed for all certificates in the path
+ except the final certificate. Figure 2 provides a high-level
+ flowchart of this algorithm.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 74]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ +-------+
+ | START |
+ +-------+
+ |
+ V
+ +----------------+
+ | Initialization |
+ +----------------+
+ |
+ +<--------------------+
+ | |
+ V |
+ +----------------+ |
+ | Process Cert | |
+ +----------------+ |
+ | |
+ V |
+ +================+ |
+ | IF Last Cert | |
+ | in Path | |
+ +================+ |
+ | | |
+ THEN | | ELSE |
+ V V |
+ +----------------+ +----------------+ |
+ | Wrap up | | Prepare for | |
+ +----------------+ | Next Cert | |
+ | +----------------+ |
+ V | |
+ +-------+ +--------------+
+ | STOP |
+ +-------+
+
+ Figure 2. Certification Path Processing Flowchart
+
+6.1.1. Inputs
+
+ This algorithm assumes that the following nine inputs are provided to
+ the path processing logic:
+
+ (a) a prospective certification path of length n.
+
+ (b) the current date/time.
+
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 75]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ (c) user-initial-policy-set: A set of certificate policy
+ identifiers naming the policies that are acceptable to the
+ certificate user. The user-initial-policy-set contains the
+ special value any-policy if the user is not concerned about
+ certificate policy.
+
+ (d) trust anchor information, describing a CA that serves as a
+ trust anchor for the certification path. The trust anchor
+ information includes:
+
+ (1) the trusted issuer name,
+
+ (2) the trusted public key algorithm,
+
+ (3) the trusted public key, and
+
+ (4) optionally, the trusted public key parameters associated
+ with the public key.
+
+ The trust anchor information may be provided to the path
+ processing procedure in the form of a self-signed certificate.
+ When the trust anchor information is provided in the form of a
+ certificate, the name in the subject field is used as the trusted
+ issuer name and the contents of the subjectPublicKeyInfo field is
+ used as the source of the trusted public key algorithm and the
+ trusted public key. The trust anchor information is trusted
+ because it was delivered to the path processing procedure by some
+ trustworthy out-of-band procedure. If the trusted public key
+ algorithm requires parameters, then the parameters are provided
+ along with the trusted public key.
+
+ (e) initial-policy-mapping-inhibit, which indicates if policy
+ mapping is allowed in the certification path.
+
+ (f) initial-explicit-policy, which indicates if the path must be
+ valid for at least one of the certificate policies in the
+ user-initial-policy-set.
+
+ (g) initial-any-policy-inhibit, which indicates whether the
+ anyPolicy OID should be processed if it is included in a
+ certificate.
+
+ (h) initial-permitted-subtrees, which indicates for each name
+ type (e.g., X.500 distinguished names, email addresses, or IP
+ addresses) a set of subtrees within which all subject names
+ in every certificate in the certification path MUST fall.
+ The initial-permitted-subtrees input includes a set for each
+ name type. For each name type, the set may consist of a
+
+
+
+Cooper, et al. Standards Track [Page 76]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ single subtree that includes all names of that name type or
+ one or more subtrees that each specifies a subset of the
+ names of that name type, or the set may be empty. If the set
+ for a name type is empty, then the certification path will be
+ considered invalid if any certificate in the certification
+ path includes a name of that name type.
+
+ (i) initial-excluded-subtrees, which indicates for each name type
+ (e.g., X.500 distinguished names, email addresses, or IP
+ addresses) a set of subtrees within which no subject name in
+ any certificate in the certification path may fall. The
+ initial-excluded-subtrees input includes a set for each name
+ type. For each name type, the set may be empty or may
+ consist of one or more subtrees that each specifies a subset
+ of the names of that name type. If the set for a name type
+ is empty, then no names of that name type are excluded.
+
+ Conforming implementations are not required to support the setting of
+ all of these inputs. For example, a conforming implementation may be
+ designed to validate all certification paths using a value of FALSE
+ for initial-any-policy-inhibit.
+
+6.1.2. Initialization
+
+ This initialization phase establishes eleven state variables based
+ upon the nine inputs:
+
+ (a) valid_policy_tree: A tree of certificate policies with their
+ optional qualifiers; each of the leaves of the tree
+ represents a valid policy at this stage in the certification
+ path validation. If valid policies exist at this stage in
+ the certification path validation, the depth of the tree is
+ equal to the number of certificates in the chain that have
+ been processed. If valid policies do not exist at this stage
+ in the certification path validation, the tree is set to
+ NULL. Once the tree is set to NULL, policy processing
+ ceases.
+
+ Each node in the valid_policy_tree includes three data
+ objects: the valid policy, a set of associated policy
+ qualifiers, and a set of one or more expected policy values.
+ If the node is at depth x, the components of the node have
+ the following semantics:
+
+ (1) The valid_policy is a single policy OID representing a
+ valid policy for the path of length x.
+
+
+
+
+
+Cooper, et al. Standards Track [Page 77]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ (2) The qualifier_set is a set of policy qualifiers associated
+ with the valid policy in certificate x.
+
+ (3) The expected_policy_set contains one or more policy OIDs
+ that would satisfy this policy in the certificate x+1.
+
+ The initial value of the valid_policy_tree is a single node with
+ valid_policy anyPolicy, an empty qualifier_set, and an
+ expected_policy_set with the single value anyPolicy. This node is
+ considered to be at depth zero.
+
+ Figure 3 is a graphic representation of the initial state of the
+ valid_policy_tree. Additional figures will use this format to
+ describe changes in the valid_policy_tree during path processing.
+
+ +----------------+
+ | anyPolicy | <---- valid_policy
+ +----------------+
+ | {} | <---- qualifier_set
+ +----------------+
+ | {anyPolicy} | <---- expected_policy_set
+ +----------------+
+
+ Figure 3. Initial Value of the valid_policy_tree State Variable
+
+ (b) permitted_subtrees: a set of root names for each name type
+ (e.g., X.500 distinguished names, email addresses, or IP
+ addresses) defining a set of subtrees within which all
+ subject names in subsequent certificates in the certification
+ path MUST fall. This variable includes a set for each name
+ type, and the initial value is initial-permitted-subtrees.
+
+ (c) excluded_subtrees: a set of root names for each name type
+ (e.g., X.500 distinguished names, email addresses, or IP
+ addresses) defining a set of subtrees within which no subject
+ name in subsequent certificates in the certification path may
+ fall. This variable includes a set for each name type, and
+ the initial value is initial-excluded-subtrees.
+
+ (d) explicit_policy: an integer that indicates if a non-NULL
+ valid_policy_tree is required. The integer indicates the
+ number of non-self-issued certificates to be processed before
+ this requirement is imposed. Once set, this variable may be
+ decreased, but may not be increased. That is, if a
+ certificate in the path requires a non-NULL
+ valid_policy_tree, a later certificate cannot remove this
+ requirement. If initial-explicit-policy is set, then the
+ initial value is 0, otherwise the initial value is n+1.
+
+
+
+Cooper, et al. Standards Track [Page 78]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ (e) inhibit_anyPolicy: an integer that indicates whether the
+ anyPolicy policy identifier is considered a match. The
+ integer indicates the number of non-self-issued certificates
+ to be processed before the anyPolicy OID, if asserted in a
+ certificate other than an intermediate self-issued
+ certificate, is ignored. Once set, this variable may be
+ decreased, but may not be increased. That is, if a
+ certificate in the path inhibits processing of anyPolicy, a
+ later certificate cannot permit it. If initial-any-policy-
+ inhibit is set, then the initial value is 0, otherwise the
+ initial value is n+1.
+
+ (f) policy_mapping: an integer that indicates if policy mapping
+ is permitted. The integer indicates the number of non-self-
+ issued certificates to be processed before policy mapping is
+ inhibited. Once set, this variable may be decreased, but may
+ not be increased. That is, if a certificate in the path
+ specifies that policy mapping is not permitted, it cannot be
+ overridden by a later certificate. If initial-policy-
+ mapping-inhibit is set, then the initial value is 0,
+ otherwise the initial value is n+1.
+
+ (g) working_public_key_algorithm: the digital signature
+ algorithm used to verify the signature of a certificate. The
+ working_public_key_algorithm is initialized from the trusted
+ public key algorithm provided in the trust anchor
+ information.
+
+ (h) working_public_key: the public key used to verify the
+ signature of a certificate. The working_public_key is
+ initialized from the trusted public key provided in the trust
+ anchor information.
+
+ (i) working_public_key_parameters: parameters associated with
+ the current public key that may be required to verify a
+ signature (depending upon the algorithm). The
+ working_public_key_parameters variable is initialized from
+ the trusted public key parameters provided in the trust
+ anchor information.
+
+ (j) working_issuer_name: the issuer distinguished name expected
+ in the next certificate in the chain. The
+ working_issuer_name is initialized to the trusted issuer name
+ provided in the trust anchor information.
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 79]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ (k) max_path_length: this integer is initialized to n, is
+ decremented for each non-self-issued certificate in the path,
+ and may be reduced to the value in the path length constraint
+ field within the basic constraints extension of a CA
+ certificate.
+
+ Upon completion of the initialization steps, perform the basic
+ certificate processing steps specified in 6.1.3.
+
+6.1.3. Basic Certificate Processing
+
+ The basic path processing actions to be performed for certificate i
+ (for all i in [1..n]) are listed below.
+
+ (a) Verify the basic certificate information. The certificate
+ MUST satisfy each of the following:
+
+ (1) The signature on the certificate can be verified using
+ working_public_key_algorithm, the working_public_key, and
+ the working_public_key_parameters.
+
+ (2) The certificate validity period includes the current time.
+
+ (3) At the current time, the certificate is not revoked. This
+ may be determined by obtaining the appropriate CRL
+ (Section 6.3), by status information, or by out-of-band
+ mechanisms.
+
+ (4) The certificate issuer name is the working_issuer_name.
+
+ (b) If certificate i is self-issued and it is not the final
+ certificate in the path, skip this step for certificate i.
+ Otherwise, verify that the subject name is within one of the
+ permitted_subtrees for X.500 distinguished names, and verify
+ that each of the alternative names in the subjectAltName
+ extension (critical or non-critical) is within one of the
+ permitted_subtrees for that name type.
+
+ (c) If certificate i is self-issued and it is not the final
+ certificate in the path, skip this step for certificate i.
+ Otherwise, verify that the subject name is not within any of
+ the excluded_subtrees for X.500 distinguished names, and
+ verify that each of the alternative names in the
+ subjectAltName extension (critical or non-critical) is not
+ within any of the excluded_subtrees for that name type.
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 80]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ (d) If the certificate policies extension is present in the
+ certificate and the valid_policy_tree is not NULL, process
+ the policy information by performing the following steps in
+ order:
+
+ (1) For each policy P not equal to anyPolicy in the
+ certificate policies extension, let P-OID denote the OID
+ for policy P and P-Q denote the qualifier set for policy
+ P. Perform the following steps in order:
+
+ (i) For each node of depth i-1 in the valid_policy_tree
+ where P-OID is in the expected_policy_set, create a
+ child node as follows: set the valid_policy to P-OID,
+ set the qualifier_set to P-Q, and set the
+ expected_policy_set to
+ {P-OID}.
+
+ For example, consider a valid_policy_tree with a node
+ of depth i-1 where the expected_policy_set is {Gold,
+ White}. Assume the certificate policies Gold and
+ Silver appear in the certificate policies extension of
+ certificate i. The Gold policy is matched, but the
+ Silver policy is not. This rule will generate a child
+ node of depth i for the Gold policy. The result is
+ shown as Figure 4.
+
+ +-----------------+
+ | Red |
+ +-----------------+
+ | {} |
+ +-----------------+ node of depth i-1
+ | {Gold, White} |
+ +-----------------+
+ |
+ |
+ |
+ V
+ +-----------------+
+ | Gold |
+ +-----------------+
+ | {} |
+ +-----------------+ node of depth i
+ | {Gold} |
+ +-----------------+
+
+ Figure 4. Processing an Exact Match
+
+
+
+
+
+Cooper, et al. Standards Track [Page 81]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ (ii) If there was no match in step (i) and the
+ valid_policy_tree includes a node of depth i-1 with
+ the valid_policy anyPolicy, generate a child node with
+ the following values: set the valid_policy to P-OID,
+ set the qualifier_set to P-Q, and set the
+ expected_policy_set to {P-OID}.
+
+ For example, consider a valid_policy_tree with a node
+ of depth i-1 where the valid_policy is anyPolicy.
+ Assume the certificate policies Gold and Silver appear
+ in the certificate policies extension of certificate
+ i. The Gold policy does not have a qualifier, but the
+ Silver policy has the qualifier Q-Silver. If Gold and
+ Silver were not matched in (i) above, this rule will
+ generate two child nodes of depth i, one for each
+ policy. The result is shown as Figure 5.
+
+ +-----------------+
+ | anyPolicy |
+ +-----------------+
+ | {} |
+ +-----------------+ node of depth i-1
+ | {anyPolicy} |
+ +-----------------+
+ / \
+ / \
+ / \
+ / \
+ +-----------------+ +-----------------+
+ | Gold | | Silver |
+ +-----------------+ +-----------------+
+ | {} | | {Q-Silver} |
+ +-----------------+ nodes of +-----------------+
+ | {Gold} | depth i | {Silver} |
+ +-----------------+ +-----------------+
+
+ Figure 5. Processing Unmatched Policies when a
+ Leaf Node Specifies anyPolicy
+
+ (2) If the certificate policies extension includes the policy
+ anyPolicy with the qualifier set AP-Q and either (a)
+ inhibit_anyPolicy is greater than 0 or (b) i<n and the
+ certificate is self-issued, then:
+
+ For each node in the valid_policy_tree of depth i-1, for
+ each value in the expected_policy_set (including
+ anyPolicy) that does not appear in a child node, create a
+ child node with the following values: set the valid_policy
+
+
+
+Cooper, et al. Standards Track [Page 82]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ to the value from the expected_policy_set in the parent
+ node, set the qualifier_set to AP-Q, and set the
+ expected_policy_set to the value in the valid_policy from
+ this node.
+
+ For example, consider a valid_policy_tree with a node of
+ depth i-1 where the expected_policy_set is {Gold, Silver}.
+ Assume anyPolicy appears in the certificate policies
+ extension of certificate i with no policy qualifiers, but
+ Gold and Silver do not appear. This rule will generate
+ two child nodes of depth i, one for each policy. The
+ result is shown below as Figure 6.
+
+ +-----------------+
+ | Red |
+ +-----------------+
+ | {} |
+ +-----------------+ node of depth i-1
+ | {Gold, Silver} |
+ +-----------------+
+ / \
+ / \
+ / \
+ / \
+ +-----------------+ +-----------------+
+ | Gold | | Silver |
+ +-----------------+ +-----------------+
+ | {} | | {} |
+ +-----------------+ nodes of +-----------------+
+ | {Gold} | depth i | {Silver} |
+ +-----------------+ +-----------------+
+
+ Figure 6. Processing Unmatched Policies When the
+ Certificate Policies Extension Specifies anyPolicy
+
+ (3) If there is a node in the valid_policy_tree of depth i-1
+ or less without any child nodes, delete that node. Repeat
+ this step until there are no nodes of depth i-1 or less
+ without children.
+
+ For example, consider the valid_policy_tree shown in
+ Figure 7 below. The two nodes at depth i-1 that are
+ marked with an 'X' have no children, and they are deleted.
+ Applying this rule to the resulting tree will cause the
+ node at depth i-2 that is marked with a 'Y' to be deleted.
+ In the resulting tree, there are no nodes of depth i-1 or
+ less without children, and this step is complete.
+
+
+
+
+Cooper, et al. Standards Track [Page 83]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ (e) If the certificate policies extension is not present, set the
+ valid_policy_tree to NULL.
+
+ (f) Verify that either explicit_policy is greater than 0 or the
+ valid_policy_tree is not equal to NULL;
+
+ If any of steps (a), (b), (c), or (f) fails, the procedure
+ terminates, returning a failure indication and an appropriate reason.
+
+ If i is not equal to n, continue by performing the preparatory steps
+ listed in Section 6.1.4. If i is equal to n, perform the wrap-up
+ steps listed in Section 6.1.5.
+
+ +-----------+
+ | | node of depth i-3
+ +-----------+
+ / | \
+ / | \
+ / | \
+ +-----------+ +-----------+ +-----------+
+ | | | | | Y | nodes of
+ +-----------+ +-----------+ +-----------+ depth i-2
+ / \ | |
+ / \ | |
+ / \ | |
+ +-----------+ +-----------+ +-----------+ +-----------+ nodes of
+ | | | X | | | | X | depth
+ +-----------+ +-----------+ +-----------+ +-----------+ i-1
+ | / | \
+ | / | \
+ | / | \
+ +-----------+ +-----------+ +-----------+ +-----------+ nodes of
+ | | | | | | | | depth
+ +-----------+ +-----------+ +-----------+ +-----------+ i
+
+ Figure 7. Pruning the valid_policy_tree
+
+6.1.4. Preparation for Certificate i+1
+
+ To prepare for processing of certificate i+1, perform the
+ following steps for certificate i:
+
+ (a) If a policy mappings extension is present, verify that the
+ special value anyPolicy does not appear as an
+ issuerDomainPolicy or a subjectDomainPolicy.
+
+ (b) If a policy mappings extension is present, then for each
+ issuerDomainPolicy ID-P in the policy mappings extension:
+
+
+
+Cooper, et al. Standards Track [Page 84]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ (1) If the policy_mapping variable is greater than 0, for each
+ node in the valid_policy_tree of depth i where ID-P is the
+ valid_policy, set expected_policy_set to the set of
+ subjectDomainPolicy values that are specified as
+ equivalent to ID-P by the policy mappings extension.
+
+ If no node of depth i in the valid_policy_tree has a
+ valid_policy of ID-P but there is a node of depth i with a
+ valid_policy of anyPolicy, then generate a child node of
+ the node of depth i-1 that has a valid_policy of anyPolicy
+ as follows:
+
+ (i) set the valid_policy to ID-P;
+
+ (ii) set the qualifier_set to the qualifier set of the
+ policy anyPolicy in the certificate policies
+ extension of certificate i; and
+
+ (iii) set the expected_policy_set to the set of
+ subjectDomainPolicy values that are specified as
+ equivalent to ID-P by the policy mappings extension.
+
+ (2) If the policy_mapping variable is equal to 0:
+
+ (i) delete each node of depth i in the valid_policy_tree
+ where ID-P is the valid_policy.
+
+ (ii) If there is a node in the valid_policy_tree of depth
+ i-1 or less without any child nodes, delete that
+ node. Repeat this step until there are no nodes of
+ depth i-1 or less without children.
+
+ (c) Assign the certificate subject name to working_issuer_name.
+
+ (d) Assign the certificate subjectPublicKey to
+ working_public_key.
+
+ (e) If the subjectPublicKeyInfo field of the certificate contains
+ an algorithm field with non-null parameters, assign the
+ parameters to the working_public_key_parameters variable.
+
+ If the subjectPublicKeyInfo field of the certificate contains
+ an algorithm field with null parameters or parameters are
+ omitted, compare the certificate subjectPublicKey algorithm
+ to the working_public_key_algorithm. If the certificate
+ subjectPublicKey algorithm and the
+ working_public_key_algorithm are different, set the
+ working_public_key_parameters to null.
+
+
+
+Cooper, et al. Standards Track [Page 85]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ (f) Assign the certificate subjectPublicKey algorithm to the
+ working_public_key_algorithm variable.
+
+ (g) If a name constraints extension is included in the
+ certificate, modify the permitted_subtrees and
+ excluded_subtrees state variables as follows:
+
+ (1) If permittedSubtrees is present in the certificate, set
+ the permitted_subtrees state variable to the intersection
+ of its previous value and the value indicated in the
+ extension field. If permittedSubtrees does not include a
+ particular name type, the permitted_subtrees state
+ variable is unchanged for that name type. For example,
+ the intersection of example.com and foo.example.com is
+ foo.example.com. And the intersection of example.com and
+ example.net is the empty set.
+
+ (2) If excludedSubtrees is present in the certificate, set the
+ excluded_subtrees state variable to the union of its
+ previous value and the value indicated in the extension
+ field. If excludedSubtrees does not include a particular
+ name type, the excluded_subtrees state variable is
+ unchanged for that name type. For example, the union of
+ the name spaces example.com and foo.example.com is
+ example.com. And the union of example.com and example.net
+ is both name spaces.
+
+ (h) If certificate i is not self-issued:
+
+ (1) If explicit_policy is not 0, decrement explicit_policy by
+ 1.
+
+ (2) If policy_mapping is not 0, decrement policy_mapping by 1.
+
+ (3) If inhibit_anyPolicy is not 0, decrement inhibit_anyPolicy
+ by 1.
+
+ (i) If a policy constraints extension is included in the
+ certificate, modify the explicit_policy and policy_mapping
+ state variables as follows:
+
+ (1) If requireExplicitPolicy is present and is less than
+ explicit_policy, set explicit_policy to the value of
+ requireExplicitPolicy.
+
+ (2) If inhibitPolicyMapping is present and is less than
+ policy_mapping, set policy_mapping to the value of
+ inhibitPolicyMapping.
+
+
+
+Cooper, et al. Standards Track [Page 86]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ (j) If the inhibitAnyPolicy extension is included in the
+ certificate and is less than inhibit_anyPolicy, set
+ inhibit_anyPolicy to the value of inhibitAnyPolicy.
+
+ (k) If certificate i is a version 3 certificate, verify that the
+ basicConstraints extension is present and that cA is set to
+ TRUE. (If certificate i is a version 1 or version 2
+ certificate, then the application MUST either verify that
+ certificate i is a CA certificate through out-of-band means
+ or reject the certificate. Conforming implementations may
+ choose to reject all version 1 and version 2 intermediate
+ certificates.)
+
+ (l) If the certificate was not self-issued, verify that
+ max_path_length is greater than zero and decrement
+ max_path_length by 1.
+
+ (m) If pathLenConstraint is present in the certificate and is
+ less than max_path_length, set max_path_length to the value
+ of pathLenConstraint.
+
+ (n) If a key usage extension is present, verify that the
+ keyCertSign bit is set.
+
+ (o) Recognize and process any other critical extension present in
+ the certificate. Process any other recognized non-critical
+ extension present in the certificate that is relevant to path
+ processing.
+
+ If check (a), (k), (l), (n), or (o) fails, the procedure terminates,
+ returning a failure indication and an appropriate reason.
+
+ If (a), (k), (l), (n), and (o) have completed successfully, increment
+ i and perform the basic certificate processing specified in Section
+ 6.1.3.
+
+6.1.5. Wrap-Up Procedure
+
+ To complete the processing of the target certificate, perform the
+ following steps for certificate n:
+
+ (a) If explicit_policy is not 0, decrement explicit_policy by 1.
+
+ (b) If a policy constraints extension is included in the
+ certificate and requireExplicitPolicy is present and has a
+ value of 0, set the explicit_policy state variable to 0.
+
+
+
+
+
+Cooper, et al. Standards Track [Page 87]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ (c) Assign the certificate subjectPublicKey to
+ working_public_key.
+
+ (d) If the subjectPublicKeyInfo field of the certificate contains
+ an algorithm field with non-null parameters, assign the
+ parameters to the working_public_key_parameters variable.
+
+ If the subjectPublicKeyInfo field of the certificate contains
+ an algorithm field with null parameters or parameters are
+ omitted, compare the certificate subjectPublicKey algorithm
+ to the working_public_key_algorithm. If the certificate
+ subjectPublicKey algorithm and the
+ working_public_key_algorithm are different, set the
+ working_public_key_parameters to null.
+
+ (e) Assign the certificate subjectPublicKey algorithm to the
+ working_public_key_algorithm variable.
+
+ (f) Recognize and process any other critical extension present in
+ the certificate n. Process any other recognized non-critical
+ extension present in certificate n that is relevant to path
+ processing.
+
+ (g) Calculate the intersection of the valid_policy_tree and the
+ user-initial-policy-set, as follows:
+
+ (i) If the valid_policy_tree is NULL, the intersection is
+ NULL.
+
+ (ii) If the valid_policy_tree is not NULL and the user-
+ initial-policy-set is any-policy, the intersection is
+ the entire valid_policy_tree.
+
+ (iii) If the valid_policy_tree is not NULL and the user-
+ initial-policy-set is not any-policy, calculate the
+ intersection of the valid_policy_tree and the user-
+ initial-policy-set as follows:
+
+ 1. Determine the set of policy nodes whose parent nodes
+ have a valid_policy of anyPolicy. This is the
+ valid_policy_node_set.
+
+ 2. If the valid_policy of any node in the
+ valid_policy_node_set is not in the user-initial-
+ policy-set and is not anyPolicy, delete this node and
+ all its children.
+
+
+
+
+
+Cooper, et al. Standards Track [Page 88]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ 3. If the valid_policy_tree includes a node of depth n
+ with the valid_policy anyPolicy and the user-initial-
+ policy-set is not any-policy, perform the following
+ steps:
+
+ a. Set P-Q to the qualifier_set in the node of depth n
+ with valid_policy anyPolicy.
+
+ b. For each P-OID in the user-initial-policy-set that is
+ not the valid_policy of a node in the
+ valid_policy_node_set, create a child node whose
+ parent is the node of depth n-1 with the valid_policy
+ anyPolicy. Set the values in the child node as
+ follows: set the valid_policy to P-OID, set the
+ qualifier_set to P-Q, and set the expected_policy_set
+ to {P-OID}.
+
+ c. Delete the node of depth n with the valid_policy
+ anyPolicy.
+
+ 4. If there is a node in the valid_policy_tree of depth
+ n-1 or less without any child nodes, delete that node.
+ Repeat this step until there are no nodes of depth n-1
+ or less without children.
+
+ If either (1) the value of explicit_policy variable is greater than
+ zero or (2) the valid_policy_tree is not NULL, then path processing
+ has succeeded.
+
+6.1.6. Outputs
+
+ If path processing succeeds, the procedure terminates, returning a
+ success indication together with final value of the
+ valid_policy_tree, the working_public_key, the
+ working_public_key_algorithm, and the working_public_key_parameters.
+
+6.2. Using the Path Validation Algorithm
+
+ The path validation algorithm describes the process of validating a
+ single certification path. While each certification path begins with
+ a specific trust anchor, there is no requirement that all
+ certification paths validated by a particular system share a single
+ trust anchor. The selection of one or more trusted CAs is a local
+ decision. A system may provide any one of its trusted CAs as the
+ trust anchor for a particular path. The inputs to the path
+ validation algorithm may be different for each path. The inputs used
+ to process a path may reflect application-specific requirements or
+ limitations in the trust accorded a particular trust anchor. For
+
+
+
+Cooper, et al. Standards Track [Page 89]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ example, a trusted CA may only be trusted for a particular
+ certificate policy. This restriction can be expressed through the
+ inputs to the path validation procedure.
+
+ An implementation MAY augment the algorithm presented in Section 6.1
+ to further limit the set of valid certification paths that begin with
+ a particular trust anchor. For example, an implementation MAY modify
+ the algorithm to apply a path length constraint to a specific trust
+ anchor during the initialization phase, or the application MAY
+ require the presence of a particular alternative name form in the
+ target certificate, or the application MAY impose requirements on
+ application-specific extensions. Thus, the path validation algorithm
+ presented in Section 6.1 defines the minimum conditions for a path to
+ be considered valid.
+
+ Where a CA distributes self-signed certificates to specify trust
+ anchor information, certificate extensions can be used to specify
+ recommended inputs to path validation. For example, a policy
+ constraints extension could be included in the self-signed
+ certificate to indicate that paths beginning with this trust anchor
+ should be trusted only for the specified policies. Similarly, a name
+ constraints extension could be included to indicate that paths
+ beginning with this trust anchor should be trusted only for the
+ specified name spaces. The path validation algorithm presented in
+ Section 6.1 does not assume that trust anchor information is provided
+ in self-signed certificates and does not specify processing rules for
+ additional information included in such certificates.
+ Implementations that use self-signed certificates to specify trust
+ anchor information are free to process or ignore such information.
+
+6.3. CRL Validation
+
+ This section describes the steps necessary to determine if a
+ certificate is revoked when CRLs are the revocation mechanism used by
+ the certificate issuer. Conforming implementations that support CRLs
+ are not required to implement this algorithm, but they MUST be
+ functionally equivalent to the external behavior resulting from this
+ procedure when processing CRLs that are issued in conformance with
+ this profile. Any algorithm may be used by a particular
+ implementation so long as it derives the correct result.
+
+ This algorithm assumes that all of the needed CRLs are available in a
+ local cache. Further, if the next update time of a CRL has passed,
+ the algorithm assumes a mechanism to fetch a current CRL and place it
+ in the local CRL cache.
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 90]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ This algorithm defines a set of inputs, a set of state variables, and
+ processing steps that are performed for each certificate in the path.
+ The algorithm output is the revocation status of the certificate.
+
+6.3.1. Revocation Inputs
+
+ To support revocation processing, the algorithm requires two inputs:
+
+ (a) certificate: The algorithm requires the certificate serial
+ number and issuer name to determine whether a certificate is
+ on a particular CRL. The basicConstraints extension is used
+ to determine whether the supplied certificate is associated
+ with a CA or an end entity. If present, the algorithm uses
+ the cRLDistributionPoints and freshestCRL extensions to
+ determine revocation status.
+
+ (b) use-deltas: This boolean input determines whether delta CRLs
+ are applied to CRLs.
+
+6.3.2. Initialization and Revocation State Variables
+
+ To support CRL processing, the algorithm requires the following state
+ variables:
+
+ (a) reasons_mask: This variable contains the set of revocation
+ reasons supported by the CRLs and delta CRLs processed so
+ far. The legal members of the set are the possible
+ revocation reason values minus unspecified: keyCompromise,
+ cACompromise, affiliationChanged, superseded,
+ cessationOfOperation, certificateHold, privilegeWithdrawn,
+ and aACompromise. The special value all-reasons is used to
+ denote the set of all legal members. This variable is
+ initialized to the empty set.
+
+ (b) cert_status: This variable contains the status of the
+ certificate. This variable may be assigned one of the
+ following values: unspecified, keyCompromise, cACompromise,
+ affiliationChanged, superseded, cessationOfOperation,
+ certificateHold, removeFromCRL, privilegeWithdrawn,
+ aACompromise, the special value UNREVOKED, or the special
+ value UNDETERMINED. This variable is initialized to the
+ special value UNREVOKED.
+
+ (c) interim_reasons_mask: This contains the set of revocation
+ reasons supported by the CRL or delta CRL currently being
+ processed.
+
+
+
+
+
+Cooper, et al. Standards Track [Page 91]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ Note: In some environments, it is not necessary to check all reason
+ codes. For example, some environments are only concerned with
+ cACompromise and keyCompromise for CA certificates. This algorithm
+ checks all reason codes. Additional processing and state variables
+ may be necessary to limit the checking to a subset of the reason
+ codes.
+
+6.3.3. CRL Processing
+
+ This algorithm begins by assuming that the certificate is not
+ revoked. The algorithm checks one or more CRLs until either the
+ certificate status is determined to be revoked or sufficient CRLs
+ have been checked to cover all reason codes.
+
+ For each distribution point (DP) in the certificate's CRL
+ distribution points extension, for each corresponding CRL in the
+ local CRL cache, while ((reasons_mask is not all-reasons) and
+ (cert_status is UNREVOKED)) perform the following:
+
+ (a) Update the local CRL cache by obtaining a complete CRL, a
+ delta CRL, or both, as required:
+
+ (1) If the current time is after the value of the CRL next
+ update field, then do one of the following:
+
+ (i) If use-deltas is set and either the certificate or the
+ CRL contains the freshest CRL extension, obtain a
+ delta CRL with a next update value that is after the
+ current time and can be used to update the locally
+ cached CRL as specified in Section 5.2.4.
+
+ (ii) Update the local CRL cache with a current complete
+ CRL, verify that the current time is before the next
+ update value in the new CRL, and continue processing
+ with the new CRL. If use-deltas is set and either the
+ certificate or the CRL contains the freshest CRL
+ extension, then obtain the current delta CRL that can
+ be used to update the new locally cached complete CRL
+ as specified in Section 5.2.4.
+
+ (2) If the current time is before the value of the next update
+ field, use-deltas is set, and either the certificate or
+ the CRL contains the freshest CRL extension, then obtain
+ the current delta CRL that can be used to update the
+ locally cached complete CRL as specified in Section 5.2.4.
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 92]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ (b) Verify the issuer and scope of the complete CRL as follows:
+
+ (1) If the DP includes cRLIssuer, then verify that the issuer
+ field in the complete CRL matches cRLIssuer in the DP and
+ that the complete CRL contains an issuing distribution
+ point extension with the indirectCRL boolean asserted.
+ Otherwise, verify that the CRL issuer matches the
+ certificate issuer.
+
+ (2) If the complete CRL includes an issuing distribution point
+ (IDP) CRL extension, check the following:
+
+ (i) If the distribution point name is present in the IDP
+ CRL extension and the distribution field is present in
+ the DP, then verify that one of the names in the IDP
+ matches one of the names in the DP. If the
+ distribution point name is present in the IDP CRL
+ extension and the distribution field is omitted from
+ the DP, then verify that one of the names in the IDP
+ matches one of the names in the cRLIssuer field of the
+ DP.
+
+ (ii) If the onlyContainsUserCerts boolean is asserted in
+ the IDP CRL extension, verify that the certificate
+ does not include the basic constraints extension with
+ the cA boolean asserted.
+
+ (iii) If the onlyContainsCACerts boolean is asserted in the
+ IDP CRL extension, verify that the certificate
+ includes the basic constraints extension with the cA
+ boolean asserted.
+
+ (iv) Verify that the onlyContainsAttributeCerts boolean is
+ not asserted.
+
+ (c) If use-deltas is set, verify the issuer and scope of the
+ delta CRL as follows:
+
+ (1) Verify that the delta CRL issuer matches the complete CRL
+ issuer.
+
+ (2) If the complete CRL includes an issuing distribution point
+ (IDP) CRL extension, verify that the delta CRL contains a
+ matching IDP CRL extension. If the complete CRL omits an
+ IDP CRL extension, verify that the delta CRL also omits an
+ IDP CRL extension.
+
+
+
+
+
+Cooper, et al. Standards Track [Page 93]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ (3) Verify that the delta CRL authority key identifier
+ extension matches the complete CRL authority key
+ identifier extension.
+
+ (d) Compute the interim_reasons_mask for this CRL as follows:
+
+ (1) If the issuing distribution point (IDP) CRL extension is
+ present and includes onlySomeReasons and the DP includes
+ reasons, then set interim_reasons_mask to the intersection
+ of reasons in the DP and onlySomeReasons in the IDP CRL
+ extension.
+
+ (2) If the IDP CRL extension includes onlySomeReasons but the
+ DP omits reasons, then set interim_reasons_mask to the
+ value of onlySomeReasons in the IDP CRL extension.
+
+ (3) If the IDP CRL extension is not present or omits
+ onlySomeReasons but the DP includes reasons, then set
+ interim_reasons_mask to the value of DP reasons.
+
+ (4) If the IDP CRL extension is not present or omits
+ onlySomeReasons and the DP omits reasons, then set
+ interim_reasons_mask to the special value all-reasons.
+
+ (e) Verify that interim_reasons_mask includes one or more reasons
+ that are not included in the reasons_mask.
+
+ (f) Obtain and validate the certification path for the issuer of
+ the complete CRL. The trust anchor for the certification
+ path MUST be the same as the trust anchor used to validate
+ the target certificate. If a key usage extension is present
+ in the CRL issuer's certificate, verify that the cRLSign bit
+ is set.
+
+ (g) Validate the signature on the complete CRL using the public
+ key validated in step (f).
+
+ (h) If use-deltas is set, then validate the signature on the
+ delta CRL using the public key validated in step (f).
+
+ (i) If use-deltas is set, then search for the certificate on the
+ delta CRL. If an entry is found that matches the certificate
+ issuer and serial number as described in Section 5.3.3, then
+ set the cert_status variable to the indicated reason as
+ follows:
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 94]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ (1) If the reason code CRL entry extension is present, set the
+ cert_status variable to the value of the reason code CRL
+ entry extension.
+
+ (2) If the reason code CRL entry extension is not present, set
+ the cert_status variable to the value unspecified.
+
+ (j) If (cert_status is UNREVOKED), then search for the
+ certificate on the complete CRL. If an entry is found that
+ matches the certificate issuer and serial number as described
+ in Section 5.3.3, then set the cert_status variable to the
+ indicated reason as described in step (i).
+
+ (k) If (cert_status is removeFromCRL), then set cert_status to
+ UNREVOKED.
+
+ (l) Set the reasons_mask state variable to the union of its
+ previous value and the value of the interim_reasons_mask
+ state variable.
+
+ If ((reasons_mask is all-reasons) OR (cert_status is not UNREVOKED)),
+ then the revocation status has been determined, so return
+ cert_status.
+
+ If the revocation status has not been determined, repeat the process
+ above with any available CRLs not specified in a distribution point
+ but issued by the certificate issuer. For the processing of such a
+ CRL, assume a DP with both the reasons and the cRLIssuer fields
+ omitted and a distribution point name of the certificate issuer.
+ That is, the sequence of names in fullName is generated from the
+ certificate issuer field as well as the certificate issuerAltName
+ extension. After processing such CRLs, if the revocation status has
+ still not been determined, then return the cert_status UNDETERMINED.
+
+7. Processing Rules for Internationalized Names
+
+ Internationalized names may be encountered in numerous certificate
+ and CRL fields and extensions, including distinguished names,
+ internationalized domain names, electronic mail addresses, and
+ Internationalized Resource Identifiers (IRIs). Storage, comparison,
+ and presentation of such names require special care. Some characters
+ may be encoded in multiple ways. The same names could be represented
+ in multiple encodings (e.g., ASCII or UTF8). This section
+ establishes conformance requirements for storage or comparison of
+ each of these name forms. Informative guidance on presentation is
+ provided for some of these name forms.
+
+
+
+
+
+Cooper, et al. Standards Track [Page 95]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+7.1. Internationalized Names in Distinguished Names
+
+ Representation of internationalized names in distinguished names is
+ covered in Sections 4.1.2.4, Issuer Name, and 4.1.2.6, Subject Name.
+ Standard naming attributes, such as common name, employ the
+ DirectoryString type, which supports internationalized names through
+ a variety of language encodings. Conforming implementations MUST
+ support UTF8String and PrintableString. RFC 3280 required only
+ binary comparison of attribute values encoded in UTF8String, however,
+ this specification requires a more comprehensive handling of
+ comparison. Implementations may encounter certificates and CRLs with
+ names encoded using TeletexString, BMPString, or UniversalString, but
+ support for these is OPTIONAL.
+
+ Conforming implementations MUST use the LDAP StringPrep profile
+ (including insignificant space handling), as specified in [RFC4518],
+ as the basis for comparison of distinguished name attributes encoded
+ in either PrintableString or UTF8String. Conforming implementations
+ MUST support name comparisons using caseIgnoreMatch. Support for
+ attribute types that use other equality matching rules is optional.
+
+ Before comparing names using the caseIgnoreMatch matching rule,
+ conforming implementations MUST perform the six-step string
+ preparation algorithm described in [RFC4518] for each attribute of
+ type DirectoryString, with the following clarifications:
+
+ * In step 2, Map, the mapping shall include case folding as
+ specified in Appendix B.2 of [RFC3454].
+
+ * In step 6, Insignificant Character Removal, perform white space
+ compression as specified in Section 2.6.1, Insignificant Space
+ Handling, of [RFC4518].
+
+ When performing the string preparation algorithm, attributes MUST be
+ treated as stored values.
+
+ Comparisons of domainComponent attributes MUST be performed as
+ specified in Section 7.3.
+
+ Two naming attributes match if the attribute types are the same and
+ the values of the attributes are an exact match after processing with
+ the string preparation algorithm. Two relative distinguished names
+ RDN1 and RDN2 match if they have the same number of naming attributes
+ and for each naming attribute in RDN1 there is a matching naming
+ attribute in RDN2. Two distinguished names DN1 and DN2 match if they
+ have the same number of RDNs, for each RDN in DN1 there is a matching
+ RDN in DN2, and the matching RDNs appear in the same order in both
+ DNs. A distinguished name DN1 is within the subtree defined by the
+
+
+
+Cooper, et al. Standards Track [Page 96]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ distinguished name DN2 if DN1 contains at least as many RDNs as DN2,
+ and DN1 and DN2 are a match when trailing RDNs in DN1 are ignored.
+
+7.2. Internationalized Domain Names in GeneralName
+
+ Internationalized Domain Names (IDNs) may be included in certificates
+ and CRLs in the subjectAltName and issuerAltName extensions, name
+ constraints extension, authority information access extension,
+ subject information access extension, CRL distribution points
+ extension, and issuing distribution point extension. Each of these
+ extensions uses the GeneralName type; one choice in GeneralName is
+ the dNSName field, which is defined as type IA5String.
+
+ IA5String is limited to the set of ASCII characters. To accommodate
+ internationalized domain names in the current structure, conforming
+ implementations MUST convert internationalized domain names to the
+ ASCII Compatible Encoding (ACE) format as specified in Section 4 of
+ RFC 3490 before storage in the dNSName field. Specifically,
+ conforming implementations MUST perform the conversion operation
+ specified in Section 4 of RFC 3490, with the following
+ clarifications:
+
+ * in step 1, the domain name SHALL be considered a "stored
+ string". That is, the AllowUnassigned flag SHALL NOT be set;
+
+ * in step 3, set the flag called "UseSTD3ASCIIRules";
+
+ * in step 4, process each label with the "ToASCII" operation; and
+
+ * in step 5, change all label separators to U+002E (full stop).
+
+ When comparing DNS names for equality, conforming implementations
+ MUST perform a case-insensitive exact match on the entire DNS name.
+ When evaluating name constraints, conforming implementations MUST
+ perform a case-insensitive exact match on a label-by-label basis. As
+ noted in Section 4.2.1.10, any DNS name that may be constructed by
+ adding labels to the left-hand side of the domain name given as the
+ constraint is considered to fall within the indicated subtree.
+
+ Implementations should convert IDNs to Unicode before display.
+ Specifically, conforming implementations should perform the
+ conversion operation specified in Section 4 of RFC 3490, with the
+ following clarifications:
+
+ * in step 1, the domain name SHALL be considered a "stored
+ string". That is, the AllowUnassigned flag SHALL NOT be set;
+
+ * in step 3, set the flag called "UseSTD3ASCIIRules";
+
+
+
+Cooper, et al. Standards Track [Page 97]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ * in step 4, process each label with the "ToUnicode" operation;
+ and
+
+ * skip step 5.
+
+ Note: Implementations MUST allow for increased space requirements
+ for IDNs. An IDN ACE label will begin with the four additional
+ characters "xn--" and may require as many as five ASCII characters to
+ specify a single international character.
+
+7.3. Internationalized Domain Names in Distinguished Names
+
+ Domain Names may also be represented as distinguished names using
+ domain components in the subject field, the issuer field, the
+ subjectAltName extension, or the issuerAltName extension. As with
+ the dNSName in the GeneralName type, the value of this attribute is
+ defined as an IA5String. Each domainComponent attribute represents a
+ single label. To represent a label from an IDN in the distinguished
+ name, the implementation MUST perform the "ToASCII" label conversion
+ specified in Section 4.1 of RFC 3490. The label SHALL be considered
+ a "stored string". That is, the AllowUnassigned flag SHALL NOT be
+ set.
+
+ Conforming implementations shall perform a case-insensitive exact
+ match when comparing domainComponent attributes in distinguished
+ names, as described in Section 7.2.
+
+ Implementations should convert ACE labels to Unicode before display.
+ Specifically, conforming implementations should perform the
+ "ToUnicode" conversion operation specified, as described in Section
+ 7.2, on each ACE label before displaying the name.
+
+7.4. Internationalized Resource Identifiers
+
+ Internationalized Resource Identifiers (IRIs) are the
+ internationalized complement to the Uniform Resource Identifier
+ (URI). IRIs are sequences of characters from Unicode, while URIs are
+ sequences of characters from the ASCII character set. [RFC3987]
+ defines a mapping from IRIs to URIs. While IRIs are not encoded
+ directly in any certificate fields or extensions, their mapped URIs
+ may be included in certificates and CRLs. URIs may appear in the
+ subjectAltName and issuerAltName extensions, name constraints
+ extension, authority information access extension, subject
+ information access extension, issuing distribution point extension,
+ and CRL distribution points extension. Each of these extensions uses
+ the GeneralName type; URIs are encoded in the
+ uniformResourceIdentifier field in GeneralName, which is defined as
+ type IA5String.
+
+
+
+Cooper, et al. Standards Track [Page 98]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ To accommodate IRIs in the current structure, conforming
+ implementations MUST map IRIs to URIs as specified in Section 3.1 of
+ [RFC3987], with the following clarifications:
+
+ * in step 1, generate a UCS character sequence from the original
+ IRI format normalizing according to the NFC as specified in
+ Variant b (normalization according to NFC);
+
+ * perform step 2 using the output from step 1.
+
+ Implementations MUST NOT convert the ireg-name component before
+ performing step 2.
+
+ Before URIs may be compared, conforming implementations MUST perform
+ a combination of the syntax-based and scheme-based normalization
+ techniques described in [RFC3987]. Specifically, conforming
+ implementations MUST prepare URIs for comparison as follows:
+
+ * Step 1: Where IRIs allow the usage of IDNs, those names MUST be
+ converted to ASCII Compatible Encoding as specified in Section
+ 7.2 above.
+
+ * Step 2: The scheme and host are normalized to lowercase, as
+ described in Section 5.3.2.1 of [RFC3987].
+
+ * Step 3: Perform percent-encoding normalization, as specified in
+ Section 5.3.2.3 of [RFC3987].
+
+ * Step 4: Perform path segment normalization, as specified in
+ Section 5.3.2.4 of [RFC3987].
+
+ * Step 5: If recognized, the implementation MUST perform scheme-
+ based normalization as specified in Section 5.3.3 of [RFC3987].
+
+ Conforming implementations MUST recognize and perform scheme-based
+ normalization for the following schemes: ldap, http, https, and ftp.
+ If the scheme is not recognized, step 5 is omitted.
+
+ When comparing URIs for equivalence, conforming implementations shall
+ perform a case-sensitive exact match.
+
+ Implementations should convert URIs to Unicode before display.
+ Specifically, conforming implementations should perform the
+ conversion operation specified in Section 3.2 of [RFC3987].
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 99]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+7.5. Internationalized Electronic Mail Addresses
+
+ Electronic Mail addresses may be included in certificates and CRLs in
+ the subjectAltName and issuerAltName extensions, name constraints
+ extension, authority information access extension, subject
+ information access extension, issuing distribution point extension,
+ or CRL distribution points extension. Each of these extensions uses
+ the GeneralName construct; GeneralName includes the rfc822Name
+ choice, which is defined as type IA5String. To accommodate email
+ addresses with internationalized domain names using the current
+ structure, conforming implementations MUST convert the addresses into
+ an ASCII representation.
+
+ Where the host-part (the Domain of the Mailbox) contains an
+ internationalized name, the domain name MUST be converted from an IDN
+ to the ASCII Compatible Encoding (ACE) format as specified in Section
+ 7.2.
+
+ Two email addresses are considered to match if:
+
+ 1) the local-part of each name is an exact match, AND
+
+ 2) the host-part of each name matches using a case-insensitive
+ ASCII comparison.
+
+ Implementations should convert the host-part of internationalized
+ email addresses specified in these extensions to Unicode before
+ display. Specifically, conforming implementations should perform the
+ conversion of the host-part of the Mailbox as described in Section
+ 7.2.
+
+8. Security Considerations
+
+ The majority of this specification is devoted to the format and
+ content of certificates and CRLs. Since certificates and CRLs are
+ digitally signed, no additional integrity service is necessary.
+ Neither certificates nor CRLs need be kept secret, and unrestricted
+ and anonymous access to certificates and CRLs has no security
+ implications.
+
+ However, security factors outside the scope of this specification
+ will affect the assurance provided to certificate users. This
+ section highlights critical issues to be considered by implementers,
+ administrators, and users.
+
+ The procedures performed by CAs and RAs to validate the binding of
+ the subject's identity to their public key greatly affect the
+ assurance that ought to be placed in the certificate. Relying
+
+
+
+Cooper, et al. Standards Track [Page 100]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ parties might wish to review the CA's certification practice
+ statement. This is particularly important when issuing certificates
+ to other CAs.
+
+ The use of a single key pair for both signature and other purposes is
+ strongly discouraged. Use of separate key pairs for signature and
+ key management provides several benefits to the users. The
+ ramifications associated with loss or disclosure of a signature key
+ are different from loss or disclosure of a key management key. Using
+ separate key pairs permits a balanced and flexible response.
+ Similarly, different validity periods or key lengths for each key
+ pair may be appropriate in some application environments.
+ Unfortunately, some legacy applications (e.g., Secure Sockets Layer
+ (SSL)) use a single key pair for signature and key management.
+
+ The protection afforded private keys is a critical security factor.
+ On a small scale, failure of users to protect their private keys will
+ permit an attacker to masquerade as them or decrypt their personal
+ information. On a larger scale, compromise of a CA's private signing
+ key may have a catastrophic effect. If an attacker obtains the
+ private key unnoticed, the attacker may issue bogus certificates and
+ CRLs. Existence of bogus certificates and CRLs will undermine
+ confidence in the system. If such a compromise is detected, all
+ certificates issued to the compromised CA MUST be revoked, preventing
+ services between its users and users of other CAs. Rebuilding after
+ such a compromise will be problematic, so CAs are advised to
+ implement a combination of strong technical measures (e.g., tamper-
+ resistant cryptographic modules) and appropriate management
+ procedures (e.g., separation of duties) to avoid such an incident.
+
+ Loss of a CA's private signing key may also be problematic. The CA
+ would not be able to produce CRLs or perform normal key rollover.
+ CAs SHOULD maintain secure backup for signing keys. The security of
+ the key backup procedures is a critical factor in avoiding key
+ compromise.
+
+ The availability and freshness of revocation information affects the
+ degree of assurance that ought to be placed in a certificate. While
+ certificates expire naturally, events may occur during its natural
+ lifetime that negate the binding between the subject and public key.
+ If revocation information is untimely or unavailable, the assurance
+ associated with the binding is clearly reduced. Relying parties
+ might not be able to process every critical extension that can appear
+ in a CRL. CAs SHOULD take extra care when making revocation
+ information available only through CRLs that contain critical
+ extensions, particularly if support for those extensions is not
+ mandated by this profile. For example, if revocation information is
+ supplied using a combination of delta CRLs and full CRLs, and the
+
+
+
+Cooper, et al. Standards Track [Page 101]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ delta CRLs are issued more frequently than the full CRLs, then
+ relying parties that cannot handle the critical extensions related to
+ delta CRL processing will not be able to obtain the most recent
+ revocation information. Alternatively, if a full CRL is issued
+ whenever a delta CRL is issued, then timely revocation information
+ will be available to all relying parties. Similarly, implementations
+ of the certification path validation mechanism described in Section 6
+ that omit revocation checking provide less assurance than those that
+ support it.
+
+ The certification path validation algorithm depends on the certain
+ knowledge of the public keys (and other information) about one or
+ more trusted CAs. The decision to trust a CA is an important
+ decision as it ultimately determines the trust afforded a
+ certificate. The authenticated distribution of trusted CA public
+ keys (usually in the form of a "self-signed" certificate) is a
+ security critical out-of-band process that is beyond the scope of
+ this specification.
+
+ In addition, where a key compromise or CA failure occurs for a
+ trusted CA, the user will need to modify the information provided to
+ the path validation routine. Selection of too many trusted CAs makes
+ the trusted CA information difficult to maintain. On the other hand,
+ selection of only one trusted CA could limit users to a closed
+ community of users.
+
+ The quality of implementations that process certificates also affects
+ the degree of assurance provided. The path validation algorithm
+ described in Section 6 relies upon the integrity of the trusted CA
+ information, and especially the integrity of the public keys
+ associated with the trusted CAs. By substituting public keys for
+ which an attacker has the private key, an attacker could trick the
+ user into accepting false certificates.
+
+ The binding between a key and certificate subject cannot be stronger
+ than the cryptographic module implementation and algorithms used to
+ generate the signature. Short key lengths or weak hash algorithms
+ will limit the utility of a certificate. CAs are encouraged to note
+ advances in cryptology so they can employ strong cryptographic
+ techniques. In addition, CAs SHOULD decline to issue certificates to
+ CAs or end entities that generate weak signatures.
+
+ Inconsistent application of name comparison rules can result in
+ acceptance of invalid X.509 certification paths or rejection of valid
+ ones. The X.500 series of specifications defines rules for comparing
+ distinguished names that require comparison of strings without regard
+
+
+
+
+
+Cooper, et al. Standards Track [Page 102]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ to case, character set, multi-character white space substring, or
+ leading and trailing white space. This specification relaxes these
+ requirements, requiring support for binary comparison at a minimum.
+
+ CAs MUST encode the distinguished name in the subject field of a CA
+ certificate identically to the distinguished name in the issuer field
+ in certificates issued by that CA. If CAs use different encodings,
+ implementations might fail to recognize name chains for paths that
+ include this certificate. As a consequence, valid paths could be
+ rejected.
+
+ In addition, name constraints for distinguished names MUST be stated
+ identically to the encoding used in the subject field or
+ subjectAltName extension. If not, then name constraints stated as
+ excludedSubtrees will not match and invalid paths will be accepted
+ and name constraints expressed as permittedSubtrees will not match
+ and valid paths will be rejected. To avoid acceptance of invalid
+ paths, CAs SHOULD state name constraints for distinguished names as
+ permittedSubtrees wherever possible.
+
+ In general, using the nameConstraints extension to constrain one name
+ form (e.g., DNS names) offers no protection against use of other name
+ forms (e.g., electronic mail addresses).
+
+ While X.509 mandates that names be unambiguous, there is a risk that
+ two unrelated authorities will issue certificates and/or CRLs under
+ the same issuer name. As a means of reducing problems and security
+ issues related to issuer name collisions, CA and CRL issuer names
+ SHOULD be formed in a way that reduces the likelihood of name
+ collisions. Implementers should take into account the possible
+ existence of multiple unrelated CAs and CRL issuers with the same
+ name. At a minimum, implementations validating CRLs MUST ensure that
+ the certification path of a certificate and the CRL issuer
+ certification path used to validate the certificate terminate at the
+ same trust anchor.
+
+ While the local-part of an electronic mail address is case sensitive
+ [RFC2821], emailAddress attribute values are not case sensitive
+ [RFC2985]. As a result, there is a risk that two different email
+ addresses will be treated as the same address when the matching rule
+ for the emailAddress attribute is used, if the email server exploits
+ the case sensitivity of mailbox local-parts. Implementers should not
+ include an email address in the emailAddress attribute if the email
+ server that hosts the email address treats the local-part of email
+ addresses as case sensitive.
+
+ Implementers should be aware of risks involved if the CRL
+ distribution points or authority information access extensions of
+
+
+
+Cooper, et al. Standards Track [Page 103]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ corrupted certificates or CRLs contain links to malicious code.
+ Implementers should always take the steps of validating the retrieved
+ data to ensure that the data is properly formed.
+
+ When certificates include a cRLDistributionPoints extension with an
+ https URI or similar scheme, circular dependencies can be introduced.
+ The relying party is forced to perform an additional path validation
+ in order to obtain the CRL required to complete the initial path
+ validation! Circular conditions can also be created with an https
+ URI (or similar scheme) in the authorityInfoAccess or
+ subjectInfoAccess extensions. At worst, this situation can create
+ unresolvable dependencies.
+
+ CAs SHOULD NOT include URIs that specify https, ldaps, or similar
+ schemes in extensions. CAs that include an https URI in one of these
+ extensions MUST ensure that the server's certificate can be validated
+ without using the information that is pointed to by the URI. Relying
+ parties that choose to validate the server's certificate when
+ obtaining information pointed to by an https URI in the
+ cRLDistributionPoints, authorityInfoAccess, or subjectInfoAccess
+ extensions MUST be prepared for the possibility that this will result
+ in unbounded recursion.
+
+ Self-issued certificates provide CAs with one automated mechanism to
+ indicate changes in the CA's operations. In particular, self-issued
+ certificates may be used to implement a graceful change-over from one
+ non-compromised CA key pair to the next. Detailed procedures for "CA
+ key update" are specified in [RFC4210], where the CA protects its new
+ public key using its previous private key and vice versa using two
+ self-issued certificates. Conforming client implementations will
+ process the self-issued certificate and determine whether
+ certificates issued under the new key may be trusted. Self-issued
+ certificates MAY be used to support other changes in CA operations,
+ such as additions to the CA's policy set, using similar procedures.
+
+ Some legacy implementations support names encoded in the ISO 8859-1
+ character set (Latin1String) [ISO8859] but tag them as TeletexString.
+ TeletexString encodes a larger character set than ISO 8859-1, but it
+ encodes some characters differently. The name comparison rules
+ specified in Section 7.1 assume that TeletexStrings are encoded as
+ described in the ASN.1 standard. When comparing names encoded using
+ the Latin1String character set, false positives and negatives are
+ possible.
+
+ When strings are mapped from internal representations to visual
+ representations, sometimes two different strings will have the same
+ or similar visual representations. This can happen for many
+ different reasons, including use of similar glyphs and use of
+
+
+
+Cooper, et al. Standards Track [Page 104]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ composed characters (such as e + ' equaling U+00E9, the Korean
+ composed characters, and vowels above consonant clusters in certain
+ languages). As a result of this situation, people doing visual
+ comparisons between two different names may think they are the same
+ when in fact they are not. Also, people may mistake one string for
+ another. Issuers of certificates and relying parties both need to be
+ aware of this situation.
+
+9. IANA Considerations
+
+ Extensions in certificates and CRLs are identified using object
+ identifiers. The objects are defined in an arc delegated by IANA to
+ the PKIX Working Group. No further action by IANA is necessary for
+ this document or any anticipated updates.
+
+10. Acknowledgments
+
+ Warwick Ford participated with the authors in some of the design team
+ meetings that directed development of this document. The design
+ team's efforts were guided by contributions from Matt Crawford, Tom
+ Gindin, Steve Hanna, Stephen Henson, Paul Hoffman, Takashi Ito, Denis
+ Pinkas, and Wen-Cheng Wang.
+
+11. References
+
+11.1. Normative References
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
+ 1981.
+
+ [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
+ STD 13, RFC 1034, November 1987.
+
+ [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts --
+ Application and Support", STD 3, RFC 1123, October 1989.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+ [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
+ Infrastructure: Operational Protocols: FTP and HTTP", RFC
+ 2585, May 1999.
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 105]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+ Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+ Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+ [RFC2797] Myers, M., Liu, X., Schaad, J., and J. Weinstein,
+ "Certificate Management Messages over CMS", RFC 2797,
+ April 2000.
+
+ [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC
+ 2821, April 2001.
+
+ [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
+ Internationalized Strings ("stringprep")", RFC 3454,
+ December 2002.
+
+ [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
+ "Internationalizing Domain Names in Applications (IDNA)",
+ RFC 3490, March 2003.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifier (URI): Generic Syntax", STD 66, RFC
+ 3986, January 2005.
+
+ [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
+ Identifiers (IRIs)", RFC 3987, January 2005.
+
+ [RFC4516] Smith, M., Ed., and T. Howes, "Lightweight Directory
+ Access Protocol (LDAP): Uniform Resource Locator", RFC
+ 4516, June 2006.
+
+ [RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Internationalized String Preparation", RFC 4518,
+ June 2006.
+
+ [RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP) Schema Definitions for X.509 Certificates", RFC
+ 4523, June 2006.
+
+ [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
+ (CIDR): The Internet Address Assignment and Aggregation
+ Plan", BCP 122, RFC 4632, August 2006.
+
+ [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
+ Information technology - Abstract Syntax Notation One
+ (ASN.1): Specification of basic notation.
+
+
+
+Cooper, et al. Standards Track [Page 106]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
+ Information technology - ASN.1 encoding rules:
+ Specification of Basic Encoding Rules (BER), Canonical
+ Encoding Rules (CER) and Distinguished Encoding Rules
+ (DER).
+
+11.2. Informative References
+
+ [ISO8859] ISO/IEC 8859-1:1998. Information technology -- 8-bit
+ single-byte coded graphic character sets -- Part 1: Latin
+ alphabet No. 1.
+
+ [ISO10646] ISO/IEC 10646:2003. Information technology -- Universal
+ Multiple-Octet Coded Character Set (UCS).
+
+ [NFC] Davis, M. and M. Duerst, "Unicode Standard Annex #15:
+ Unicode Normalization Forms", October 2006,
+ <http://www.unicode.org/reports/tr15/>.
+
+ [RFC1422] Kent, S., "Privacy Enhancement for Internet Electronic
+ Mail: Part II: Certificate-Based Key Management", RFC
+ 1422, February 1993.
+
+ [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
+ Languages", BCP 18, RFC 2277, January 1998.
+
+ [RFC2459] Housley, R., Ford, W., Polk, W., and D. Solo, "Internet
+ X.509 Public Key Infrastructure Certificate and CRL
+ Profile", RFC 2459, January 1999.
+
+ [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
+ Adams, "X.509 Internet Public Key Infrastructure Online
+ Certificate Status Protocol - OCSP", RFC 2560, June 1999.
+
+ [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
+ Classes and Attribute Types Version 2.0", RFC 2985,
+ November 2000.
+
+ [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
+ "Internet X.509 Public Key Infrastructure Time-Stamp
+ Protocol (TSP)", RFC 3161, August 2001.
+
+ [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
+ Identifiers for the Internet X.509 Public Key
+ Infrastructure Certificate and Certificate Revocation List
+ (CRL) Profile", RFC 3279, April 2002.
+
+
+
+
+
+Cooper, et al. Standards Track [Page 107]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+ X.509 Public Key Infrastructure Certificate and
+ Certificate Revocation List (CRL) Profile", RFC 3280,
+ April 2002.
+
+ [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
+ Algorithms and Identifiers for RSA Cryptography for use in
+ the Internet X.509 Public Key Infrastructure Certificate
+ and Certificate Revocation List (CRL) Profile", RFC 4055,
+ June 2005.
+
+ [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+ Kerberos Network Authentication Service (V5)", RFC 4120,
+ July 2005.
+
+ [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,
+ "Internet X.509 Public Key Infrastructure Certificate
+ Management Protocol (CMP)", RFC 4210, September 2005.
+
+ [RFC4325] Santesson, S. and R. Housley, "Internet X.509 Public Key
+ Infrastructure Authority Information Access Certificate
+ Revocation List (CRL) Extension", RFC 4325, December 2005.
+
+ [RFC4491] Leontiev, S., Ed., and D. Shefanovski, Ed., "Using the
+ GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
+ Algorithms with the Internet X.509 Public Key
+ Infrastructure Certificate and CRL Profile", RFC 4491, May
+ 2006.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map", RFC 4510, June
+ 2006.
+
+ [RFC4512] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): String Representation of Distinguished Names", RFC
+ 4514, June 2006.
+
+ [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Schema for User Applications", RFC 4519, June
+ 2006.
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 108]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ [RFC4630] Housley, R. and S. Santesson, "Update to DirectoryString
+ Processing in the Internet X.509 Public Key Infrastructure
+ Certificate and Certificate Revocation List (CRL)
+ Profile", RFC 4630, August 2006.
+
+ [X.500] ITU-T Recommendation X.500 (2005) | ISO/IEC 9594-1:2005,
+ Information technology - Open Systems Interconnection -
+ The Directory: Overview of concepts, models and services.
+
+ [X.501] ITU-T Recommendation X.501 (2005) | ISO/IEC 9594-2:2005,
+ Information technology - Open Systems Interconnection -
+ The Directory: Models.
+
+ [X.509] ITU-T Recommendation X.509 (2005) | ISO/IEC 9594-8:2005,
+ Information technology - Open Systems Interconnection -
+ The Directory: Public-key and attribute certificate
+ frameworks.
+
+ [X.520] ITU-T Recommendation X.520 (2005) | ISO/IEC 9594-6:2005,
+ Information technology - Open Systems Interconnection -
+ The Directory: Selected attribute types.
+
+ [X.660] ITU-T Recommendation X.660 (2004) | ISO/IEC 9834-1:2005,
+ Information technology - Open Systems Interconnection -
+ Procedures for the operation of OSI Registration
+ Authorities: General procedures, and top arcs of the ASN.1
+ Object Identifier tree.
+
+ [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002,
+ Information technology - Abstract Syntax Notation One
+ (ASN.1): Parameterization of ASN.1 specifications.
+
+ [X9.55] ANSI X9.55-1997, Public Key Cryptography for the Financial
+ Services Industry: Extensions to Public Key Certificates
+ and Certificate Revocation Lists, January 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 109]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+Appendix A. Pseudo-ASN.1 Structures and OIDs
+
+ This appendix describes data objects used by conforming PKI
+ components in an "ASN.1-like" syntax. This syntax is a hybrid of the
+ 1988 and 1993 ASN.1 syntaxes. The 1988 ASN.1 syntax is augmented
+ with 1993 UNIVERSAL Types UniversalString, BMPString, and UTF8String.
+
+ The ASN.1 syntax does not permit the inclusion of type statements in
+ the ASN.1 module, and the 1993 ASN.1 standard does not permit use of
+ the new UNIVERSAL types in modules using the 1988 syntax. As a
+ result, this module does not conform to either version of the ASN.1
+ standard.
+
+ This appendix may be converted into 1988 ASN.1 by replacing the
+ definitions for the UNIVERSAL Types with the 1988 catch-all "ANY".
+
+A.1. Explicitly Tagged Module, 1988 Syntax
+
+PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1)
+ security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) }
+
+DEFINITIONS EXPLICIT TAGS ::=
+
+BEGIN
+
+-- EXPORTS ALL --
+
+-- IMPORTS NONE --
+
+-- UNIVERSAL Types defined in 1993 and 1998 ASN.1
+-- and required by this specification
+
+UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING
+ -- UniversalString is defined in ASN.1:1993
+
+BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING
+ -- BMPString is the subtype of UniversalString and models
+ -- the Basic Multilingual Plane of ISO/IEC 10646
+
+UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
+ -- The content of this type conforms to RFC 3629.
+
+-- PKIX specific OIDs
+
+id-pkix OBJECT IDENTIFIER ::=
+ { iso(1) identified-organization(3) dod(6) internet(1)
+ security(5) mechanisms(5) pkix(7) }
+
+
+
+
+Cooper, et al. Standards Track [Page 110]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+-- PKIX arcs
+
+id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
+ -- arc for private certificate extensions
+id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
+ -- arc for policy qualifier types
+id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
+ -- arc for extended key purpose OIDS
+id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
+ -- arc for access descriptors
+
+-- policyQualifierIds for Internet policy qualifiers
+
+id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 }
+ -- OID for CPS qualifier
+id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 }
+ -- OID for user notice qualifier
+
+-- access descriptor definitions
+
+id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }
+id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }
+id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 }
+id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 }
+
+-- attribute data types
+
+Attribute ::= SEQUENCE {
+ type AttributeType,
+ values SET OF AttributeValue }
+ -- at least one value is required
+
+AttributeType ::= OBJECT IDENTIFIER
+
+AttributeValue ::= ANY -- DEFINED BY AttributeType
+
+AttributeTypeAndValue ::= SEQUENCE {
+ type AttributeType,
+ value AttributeValue }
+
+-- suggested naming attributes: Definition of the following
+-- information object set may be augmented to meet local
+-- requirements. Note that deleting members of the set may
+-- prevent interoperability with conforming implementations.
+-- presented in pairs: the AttributeType followed by the
+-- type definition for the corresponding AttributeValue
+
+
+
+
+
+Cooper, et al. Standards Track [Page 111]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+-- Arc for standard naming attributes
+
+id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 }
+
+-- Naming attributes of type X520name
+
+id-at-name AttributeType ::= { id-at 41 }
+id-at-surname AttributeType ::= { id-at 4 }
+id-at-givenName AttributeType ::= { id-at 42 }
+id-at-initials AttributeType ::= { id-at 43 }
+id-at-generationQualifier AttributeType ::= { id-at 44 }
+
+-- Naming attributes of type X520Name:
+-- X520name ::= DirectoryString (SIZE (1..ub-name))
+--
+-- Expanded to avoid parameterized type:
+X520name ::= CHOICE {
+ teletexString TeletexString (SIZE (1..ub-name)),
+ printableString PrintableString (SIZE (1..ub-name)),
+ universalString UniversalString (SIZE (1..ub-name)),
+ utf8String UTF8String (SIZE (1..ub-name)),
+ bmpString BMPString (SIZE (1..ub-name)) }
+
+-- Naming attributes of type X520CommonName
+
+id-at-commonName AttributeType ::= { id-at 3 }
+
+-- Naming attributes of type X520CommonName:
+-- X520CommonName ::= DirectoryName (SIZE (1..ub-common-name))
+--
+-- Expanded to avoid parameterized type:
+X520CommonName ::= CHOICE {
+ teletexString TeletexString (SIZE (1..ub-common-name)),
+ printableString PrintableString (SIZE (1..ub-common-name)),
+ universalString UniversalString (SIZE (1..ub-common-name)),
+ utf8String UTF8String (SIZE (1..ub-common-name)),
+ bmpString BMPString (SIZE (1..ub-common-name)) }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 112]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+-- Naming attributes of type X520LocalityName
+
+id-at-localityName AttributeType ::= { id-at 7 }
+
+-- Naming attributes of type X520LocalityName:
+-- X520LocalityName ::= DirectoryName (SIZE (1..ub-locality-name))
+--
+-- Expanded to avoid parameterized type:
+X520LocalityName ::= CHOICE {
+ teletexString TeletexString (SIZE (1..ub-locality-name)),
+ printableString PrintableString (SIZE (1..ub-locality-name)),
+ universalString UniversalString (SIZE (1..ub-locality-name)),
+ utf8String UTF8String (SIZE (1..ub-locality-name)),
+ bmpString BMPString (SIZE (1..ub-locality-name)) }
+
+-- Naming attributes of type X520StateOrProvinceName
+
+id-at-stateOrProvinceName AttributeType ::= { id-at 8 }
+
+-- Naming attributes of type X520StateOrProvinceName:
+-- X520StateOrProvinceName ::= DirectoryName (SIZE (1..ub-state-name))
+--
+-- Expanded to avoid parameterized type:
+X520StateOrProvinceName ::= CHOICE {
+ teletexString TeletexString (SIZE (1..ub-state-name)),
+ printableString PrintableString (SIZE (1..ub-state-name)),
+ universalString UniversalString (SIZE (1..ub-state-name)),
+ utf8String UTF8String (SIZE (1..ub-state-name)),
+ bmpString BMPString (SIZE (1..ub-state-name)) }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 113]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+-- Naming attributes of type X520OrganizationName
+
+id-at-organizationName AttributeType ::= { id-at 10 }
+
+-- Naming attributes of type X520OrganizationName:
+-- X520OrganizationName ::=
+-- DirectoryName (SIZE (1..ub-organization-name))
+--
+-- Expanded to avoid parameterized type:
+X520OrganizationName ::= CHOICE {
+ teletexString TeletexString
+ (SIZE (1..ub-organization-name)),
+ printableString PrintableString
+ (SIZE (1..ub-organization-name)),
+ universalString UniversalString
+ (SIZE (1..ub-organization-name)),
+ utf8String UTF8String
+ (SIZE (1..ub-organization-name)),
+ bmpString BMPString
+ (SIZE (1..ub-organization-name)) }
+
+-- Naming attributes of type X520OrganizationalUnitName
+
+id-at-organizationalUnitName AttributeType ::= { id-at 11 }
+
+-- Naming attributes of type X520OrganizationalUnitName:
+-- X520OrganizationalUnitName ::=
+-- DirectoryName (SIZE (1..ub-organizational-unit-name))
+--
+-- Expanded to avoid parameterized type:
+X520OrganizationalUnitName ::= CHOICE {
+ teletexString TeletexString
+ (SIZE (1..ub-organizational-unit-name)),
+ printableString PrintableString
+ (SIZE (1..ub-organizational-unit-name)),
+ universalString UniversalString
+ (SIZE (1..ub-organizational-unit-name)),
+ utf8String UTF8String
+ (SIZE (1..ub-organizational-unit-name)),
+ bmpString BMPString
+ (SIZE (1..ub-organizational-unit-name)) }
+
+
+
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 114]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+-- Naming attributes of type X520Title
+
+id-at-title AttributeType ::= { id-at 12 }
+
+-- Naming attributes of type X520Title:
+-- X520Title ::= DirectoryName (SIZE (1..ub-title))
+--
+-- Expanded to avoid parameterized type:
+X520Title ::= CHOICE {
+ teletexString TeletexString (SIZE (1..ub-title)),
+ printableString PrintableString (SIZE (1..ub-title)),
+ universalString UniversalString (SIZE (1..ub-title)),
+ utf8String UTF8String (SIZE (1..ub-title)),
+ bmpString BMPString (SIZE (1..ub-title)) }
+
+-- Naming attributes of type X520dnQualifier
+
+id-at-dnQualifier AttributeType ::= { id-at 46 }
+
+X520dnQualifier ::= PrintableString
+
+-- Naming attributes of type X520countryName (digraph from IS 3166)
+
+id-at-countryName AttributeType ::= { id-at 6 }
+
+X520countryName ::= PrintableString (SIZE (2))
+
+-- Naming attributes of type X520SerialNumber
+
+id-at-serialNumber AttributeType ::= { id-at 5 }
+
+X520SerialNumber ::= PrintableString (SIZE (1..ub-serial-number))
+
+-- Naming attributes of type X520Pseudonym
+
+id-at-pseudonym AttributeType ::= { id-at 65 }
+
+-- Naming attributes of type X520Pseudonym:
+-- X520Pseudonym ::= DirectoryName (SIZE (1..ub-pseudonym))
+--
+-- Expanded to avoid parameterized type:
+X520Pseudonym ::= CHOICE {
+ teletexString TeletexString (SIZE (1..ub-pseudonym)),
+ printableString PrintableString (SIZE (1..ub-pseudonym)),
+ universalString UniversalString (SIZE (1..ub-pseudonym)),
+ utf8String UTF8String (SIZE (1..ub-pseudonym)),
+ bmpString BMPString (SIZE (1..ub-pseudonym)) }
+
+
+
+
+Cooper, et al. Standards Track [Page 115]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+-- Naming attributes of type DomainComponent (from RFC 4519)
+
+id-domainComponent AttributeType ::= { 0 9 2342 19200300 100 1 25 }
+
+DomainComponent ::= IA5String
+
+-- Legacy attributes
+
+pkcs-9 OBJECT IDENTIFIER ::=
+ { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 }
+
+id-emailAddress AttributeType ::= { pkcs-9 1 }
+
+EmailAddress ::= IA5String (SIZE (1..ub-emailaddress-length))
+
+-- naming data types --
+
+Name ::= CHOICE { -- only one possibility for now --
+ rdnSequence RDNSequence }
+
+RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
+
+DistinguishedName ::= RDNSequence
+
+RelativeDistinguishedName ::= SET SIZE (1..MAX) OF AttributeTypeAndValue
+
+-- Directory string type --
+
+DirectoryString ::= CHOICE {
+ teletexString TeletexString (SIZE (1..MAX)),
+ printableString PrintableString (SIZE (1..MAX)),
+ universalString UniversalString (SIZE (1..MAX)),
+ utf8String UTF8String (SIZE (1..MAX)),
+ bmpString BMPString (SIZE (1..MAX)) }
+
+-- certificate and CRL specific structures begin here
+
+Certificate ::= SEQUENCE {
+ tbsCertificate TBSCertificate,
+ signatureAlgorithm AlgorithmIdentifier,
+ signature BIT STRING }
+
+
+
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 116]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+TBSCertificate ::= SEQUENCE {
+ version [0] Version DEFAULT v1,
+ serialNumber CertificateSerialNumber,
+ signature AlgorithmIdentifier,
+ issuer Name,
+ validity Validity,
+ subject Name,
+ subjectPublicKeyInfo SubjectPublicKeyInfo,
+ issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
+ -- If present, version MUST be v2 or v3
+ subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
+ -- If present, version MUST be v2 or v3
+ extensions [3] Extensions OPTIONAL
+ -- If present, version MUST be v3 -- }
+
+Version ::= INTEGER { v1(0), v2(1), v3(2) }
+
+CertificateSerialNumber ::= INTEGER
+
+Validity ::= SEQUENCE {
+ notBefore Time,
+ notAfter Time }
+
+Time ::= CHOICE {
+ utcTime UTCTime,
+ generalTime GeneralizedTime }
+
+UniqueIdentifier ::= BIT STRING
+
+SubjectPublicKeyInfo ::= SEQUENCE {
+ algorithm AlgorithmIdentifier,
+ subjectPublicKey BIT STRING }
+
+Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
+
+Extension ::= SEQUENCE {
+ extnID OBJECT IDENTIFIER,
+ critical BOOLEAN DEFAULT FALSE,
+ extnValue OCTET STRING
+ -- contains the DER encoding of an ASN.1 value
+ -- corresponding to the extension type identified
+ -- by extnID
+ }
+
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 117]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+-- CRL structures
+
+CertificateList ::= SEQUENCE {
+ tbsCertList TBSCertList,
+ signatureAlgorithm AlgorithmIdentifier,
+ signature BIT STRING }
+
+TBSCertList ::= SEQUENCE {
+ version Version OPTIONAL,
+ -- if present, MUST be v2
+ signature AlgorithmIdentifier,
+ issuer Name,
+ thisUpdate Time,
+ nextUpdate Time OPTIONAL,
+ revokedCertificates SEQUENCE OF SEQUENCE {
+ userCertificate CertificateSerialNumber,
+ revocationDate Time,
+ crlEntryExtensions Extensions OPTIONAL
+ -- if present, version MUST be v2
+ } OPTIONAL,
+ crlExtensions [0] Extensions OPTIONAL }
+ -- if present, version MUST be v2
+
+-- Version, Time, CertificateSerialNumber, and Extensions were
+-- defined earlier for use in the certificate structure
+
+AlgorithmIdentifier ::= SEQUENCE {
+ algorithm OBJECT IDENTIFIER,
+ parameters ANY DEFINED BY algorithm OPTIONAL }
+ -- contains a value of the type
+ -- registered for use with the
+ -- algorithm object identifier value
+
+-- X.400 address syntax starts here
+
+ORAddress ::= SEQUENCE {
+ built-in-standard-attributes BuiltInStandardAttributes,
+ built-in-domain-defined-attributes
+ BuiltInDomainDefinedAttributes OPTIONAL,
+ -- see also teletex-domain-defined-attributes
+ extension-attributes ExtensionAttributes OPTIONAL }
+
+
+
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 118]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+-- Built-in Standard Attributes
+
+BuiltInStandardAttributes ::= SEQUENCE {
+ country-name CountryName OPTIONAL,
+ administration-domain-name AdministrationDomainName OPTIONAL,
+ network-address [0] IMPLICIT NetworkAddress OPTIONAL,
+ -- see also extended-network-address
+ terminal-identifier [1] IMPLICIT TerminalIdentifier OPTIONAL,
+ private-domain-name [2] PrivateDomainName OPTIONAL,
+ organization-name [3] IMPLICIT OrganizationName OPTIONAL,
+ -- see also teletex-organization-name
+ numeric-user-identifier [4] IMPLICIT NumericUserIdentifier
+ OPTIONAL,
+ personal-name [5] IMPLICIT PersonalName OPTIONAL,
+ -- see also teletex-personal-name
+ organizational-unit-names [6] IMPLICIT OrganizationalUnitNames
+ OPTIONAL }
+ -- see also teletex-organizational-unit-names
+
+CountryName ::= [APPLICATION 1] CHOICE {
+ x121-dcc-code NumericString
+ (SIZE (ub-country-name-numeric-length)),
+ iso-3166-alpha2-code PrintableString
+ (SIZE (ub-country-name-alpha-length)) }
+
+AdministrationDomainName ::= [APPLICATION 2] CHOICE {
+ numeric NumericString (SIZE (0..ub-domain-name-length)),
+ printable PrintableString (SIZE (0..ub-domain-name-length)) }
+
+NetworkAddress ::= X121Address -- see also extended-network-address
+
+X121Address ::= NumericString (SIZE (1..ub-x121-address-length))
+
+TerminalIdentifier ::= PrintableString (SIZE (1..ub-terminal-id-length))
+
+PrivateDomainName ::= CHOICE {
+ numeric NumericString (SIZE (1..ub-domain-name-length)),
+ printable PrintableString (SIZE (1..ub-domain-name-length)) }
+
+OrganizationName ::= PrintableString
+ (SIZE (1..ub-organization-name-length))
+ -- see also teletex-organization-name
+
+NumericUserIdentifier ::= NumericString
+ (SIZE (1..ub-numeric-user-id-length))
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 119]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+PersonalName ::= SET {
+ surname [0] IMPLICIT PrintableString
+ (SIZE (1..ub-surname-length)),
+ given-name [1] IMPLICIT PrintableString
+ (SIZE (1..ub-given-name-length)) OPTIONAL,
+ initials [2] IMPLICIT PrintableString
+ (SIZE (1..ub-initials-length)) OPTIONAL,
+ generation-qualifier [3] IMPLICIT PrintableString
+ (SIZE (1..ub-generation-qualifier-length))
+ OPTIONAL }
+ -- see also teletex-personal-name
+
+OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units)
+ OF OrganizationalUnitName
+ -- see also teletex-organizational-unit-names
+
+OrganizationalUnitName ::= PrintableString (SIZE
+ (1..ub-organizational-unit-name-length))
+
+-- Built-in Domain-defined Attributes
+
+BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE
+ (1..ub-domain-defined-attributes) OF
+ BuiltInDomainDefinedAttribute
+
+BuiltInDomainDefinedAttribute ::= SEQUENCE {
+ type PrintableString (SIZE
+ (1..ub-domain-defined-attribute-type-length)),
+ value PrintableString (SIZE
+ (1..ub-domain-defined-attribute-value-length)) }
+
+-- Extension Attributes
+
+ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF
+ ExtensionAttribute
+
+ExtensionAttribute ::= SEQUENCE {
+ extension-attribute-type [0] IMPLICIT INTEGER
+ (0..ub-extension-attributes),
+ extension-attribute-value [1]
+ ANY DEFINED BY extension-attribute-type }
+
+-- Extension types and attribute values
+
+common-name INTEGER ::= 1
+
+CommonName ::= PrintableString (SIZE (1..ub-common-name-length))
+
+
+
+
+Cooper, et al. Standards Track [Page 120]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+teletex-common-name INTEGER ::= 2
+
+TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length))
+
+teletex-organization-name INTEGER ::= 3
+
+TeletexOrganizationName ::=
+ TeletexString (SIZE (1..ub-organization-name-length))
+
+teletex-personal-name INTEGER ::= 4
+
+TeletexPersonalName ::= SET {
+ surname [0] IMPLICIT TeletexString
+ (SIZE (1..ub-surname-length)),
+ given-name [1] IMPLICIT TeletexString
+ (SIZE (1..ub-given-name-length)) OPTIONAL,
+ initials [2] IMPLICIT TeletexString
+ (SIZE (1..ub-initials-length)) OPTIONAL,
+ generation-qualifier [3] IMPLICIT TeletexString
+ (SIZE (1..ub-generation-qualifier-length))
+ OPTIONAL }
+
+teletex-organizational-unit-names INTEGER ::= 5
+
+TeletexOrganizationalUnitNames ::= SEQUENCE SIZE
+ (1..ub-organizational-units) OF TeletexOrganizationalUnitName
+
+TeletexOrganizationalUnitName ::= TeletexString
+ (SIZE (1..ub-organizational-unit-name-length))
+
+pds-name INTEGER ::= 7
+
+PDSName ::= PrintableString (SIZE (1..ub-pds-name-length))
+
+physical-delivery-country-name INTEGER ::= 8
+
+PhysicalDeliveryCountryName ::= CHOICE {
+ x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)),
+ iso-3166-alpha2-code PrintableString
+ (SIZE (ub-country-name-alpha-length)) }
+
+postal-code INTEGER ::= 9
+
+PostalCode ::= CHOICE {
+ numeric-code NumericString (SIZE (1..ub-postal-code-length)),
+ printable-code PrintableString (SIZE (1..ub-postal-code-length)) }
+
+physical-delivery-office-name INTEGER ::= 10
+
+
+
+Cooper, et al. Standards Track [Page 121]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+PhysicalDeliveryOfficeName ::= PDSParameter
+
+physical-delivery-office-number INTEGER ::= 11
+
+PhysicalDeliveryOfficeNumber ::= PDSParameter
+
+extension-OR-address-components INTEGER ::= 12
+
+ExtensionORAddressComponents ::= PDSParameter
+
+physical-delivery-personal-name INTEGER ::= 13
+
+PhysicalDeliveryPersonalName ::= PDSParameter
+
+physical-delivery-organization-name INTEGER ::= 14
+
+PhysicalDeliveryOrganizationName ::= PDSParameter
+
+extension-physical-delivery-address-components INTEGER ::= 15
+
+ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter
+
+unformatted-postal-address INTEGER ::= 16
+
+UnformattedPostalAddress ::= SET {
+ printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines)
+ OF PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL,
+ teletex-string TeletexString
+ (SIZE (1..ub-unformatted-address-length)) OPTIONAL }
+
+street-address INTEGER ::= 17
+
+StreetAddress ::= PDSParameter
+
+post-office-box-address INTEGER ::= 18
+
+PostOfficeBoxAddress ::= PDSParameter
+
+poste-restante-address INTEGER ::= 19
+
+PosteRestanteAddress ::= PDSParameter
+
+unique-postal-name INTEGER ::= 20
+
+UniquePostalName ::= PDSParameter
+
+local-postal-attributes INTEGER ::= 21
+
+
+
+
+Cooper, et al. Standards Track [Page 122]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+LocalPostalAttributes ::= PDSParameter
+
+PDSParameter ::= SET {
+ printable-string PrintableString
+ (SIZE(1..ub-pds-parameter-length)) OPTIONAL,
+ teletex-string TeletexString
+ (SIZE(1..ub-pds-parameter-length)) OPTIONAL }
+
+extended-network-address INTEGER ::= 22
+
+ExtendedNetworkAddress ::= CHOICE {
+ e163-4-address SEQUENCE {
+ number [0] IMPLICIT NumericString
+ (SIZE (1..ub-e163-4-number-length)),
+ sub-address [1] IMPLICIT NumericString
+ (SIZE (1..ub-e163-4-sub-address-length))
+ OPTIONAL },
+ psap-address [0] IMPLICIT PresentationAddress }
+
+PresentationAddress ::= SEQUENCE {
+ pSelector [0] EXPLICIT OCTET STRING OPTIONAL,
+ sSelector [1] EXPLICIT OCTET STRING OPTIONAL,
+ tSelector [2] EXPLICIT OCTET STRING OPTIONAL,
+ nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING }
+
+terminal-type INTEGER ::= 23
+
+TerminalType ::= INTEGER {
+ telex (3),
+ teletex (4),
+ g3-facsimile (5),
+ g4-facsimile (6),
+ ia5-terminal (7),
+ videotex (8) } (0..ub-integer-options)
+
+-- Extension Domain-defined Attributes
+
+teletex-domain-defined-attributes INTEGER ::= 6
+
+TeletexDomainDefinedAttributes ::= SEQUENCE SIZE
+ (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute
+
+TeletexDomainDefinedAttribute ::= SEQUENCE {
+ type TeletexString
+ (SIZE (1..ub-domain-defined-attribute-type-length)),
+ value TeletexString
+ (SIZE (1..ub-domain-defined-attribute-value-length)) }
+
+
+
+
+Cooper, et al. Standards Track [Page 123]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+-- specifications of Upper Bounds MUST be regarded as mandatory
+-- from Annex B of ITU-T X.411 Reference Definition of MTS Parameter
+-- Upper Bounds
+
+-- Upper Bounds
+ub-name INTEGER ::= 32768
+ub-common-name INTEGER ::= 64
+ub-locality-name INTEGER ::= 128
+ub-state-name INTEGER ::= 128
+ub-organization-name INTEGER ::= 64
+ub-organizational-unit-name INTEGER ::= 64
+ub-title INTEGER ::= 64
+ub-serial-number INTEGER ::= 64
+ub-match INTEGER ::= 128
+ub-emailaddress-length INTEGER ::= 255
+ub-common-name-length INTEGER ::= 64
+ub-country-name-alpha-length INTEGER ::= 2
+ub-country-name-numeric-length INTEGER ::= 3
+ub-domain-defined-attributes INTEGER ::= 4
+ub-domain-defined-attribute-type-length INTEGER ::= 8
+ub-domain-defined-attribute-value-length INTEGER ::= 128
+ub-domain-name-length INTEGER ::= 16
+ub-extension-attributes INTEGER ::= 256
+ub-e163-4-number-length INTEGER ::= 15
+ub-e163-4-sub-address-length INTEGER ::= 40
+ub-generation-qualifier-length INTEGER ::= 3
+ub-given-name-length INTEGER ::= 16
+ub-initials-length INTEGER ::= 5
+ub-integer-options INTEGER ::= 256
+ub-numeric-user-id-length INTEGER ::= 32
+ub-organization-name-length INTEGER ::= 64
+ub-organizational-unit-name-length INTEGER ::= 32
+ub-organizational-units INTEGER ::= 4
+ub-pds-name-length INTEGER ::= 16
+ub-pds-parameter-length INTEGER ::= 30
+ub-pds-physical-address-lines INTEGER ::= 6
+ub-postal-code-length INTEGER ::= 16
+ub-pseudonym INTEGER ::= 128
+ub-surname-length INTEGER ::= 40
+ub-terminal-id-length INTEGER ::= 24
+ub-unformatted-address-length INTEGER ::= 180
+ub-x121-address-length INTEGER ::= 16
+
+-- Note - upper bounds on string types, such as TeletexString, are
+-- measured in characters. Excepting PrintableString or IA5String, a
+-- significantly greater number of octets will be required to hold
+-- such a value. As a minimum, 16 octets, or twice the specified
+-- upper bound, whichever is the larger, should be allowed for
+
+
+
+Cooper, et al. Standards Track [Page 124]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+-- TeletexString. For UTF8String or UniversalString at least four
+-- times the upper bound should be allowed.
+
+END
+
+A.2. Implicitly Tagged Module, 1988 Syntax
+
+PKIX1Implicit88 { iso(1) identified-organization(3) dod(6) internet(1)
+ security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19) }
+
+DEFINITIONS IMPLICIT TAGS ::=
+
+BEGIN
+
+-- EXPORTS ALL --
+
+IMPORTS
+ id-pe, id-kp, id-qt-unotice, id-qt-cps,
+ -- delete following line if "new" types are supported --
+ BMPString, UTF8String, -- end "new" types --
+ ORAddress, Name, RelativeDistinguishedName,
+ CertificateSerialNumber, Attribute, DirectoryString
+ FROM PKIX1Explicit88 { iso(1) identified-organization(3)
+ dod(6) internet(1) security(5) mechanisms(5) pkix(7)
+ id-mod(0) id-pkix1-explicit(18) };
+
+-- ISO arc for standard certificate and CRL extensions
+
+id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29}
+
+-- authority key identifier OID and syntax
+
+id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 }
+
+AuthorityKeyIdentifier ::= SEQUENCE {
+ keyIdentifier [0] KeyIdentifier OPTIONAL,
+ authorityCertIssuer [1] GeneralNames OPTIONAL,
+ authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }
+ -- authorityCertIssuer and authorityCertSerialNumber MUST both
+ -- be present or both be absent
+
+KeyIdentifier ::= OCTET STRING
+
+
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 125]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+-- subject key identifier OID and syntax
+
+id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 }
+
+SubjectKeyIdentifier ::= KeyIdentifier
+
+-- key usage extension OID and syntax
+
+id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 }
+
+KeyUsage ::= BIT STRING {
+ digitalSignature (0),
+ nonRepudiation (1), -- recent editions of X.509 have
+ -- renamed this bit to contentCommitment
+ keyEncipherment (2),
+ dataEncipherment (3),
+ keyAgreement (4),
+ keyCertSign (5),
+ cRLSign (6),
+ encipherOnly (7),
+ decipherOnly (8) }
+
+-- private key usage period extension OID and syntax
+
+id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 }
+
+PrivateKeyUsagePeriod ::= SEQUENCE {
+ notBefore [0] GeneralizedTime OPTIONAL,
+ notAfter [1] GeneralizedTime OPTIONAL }
+ -- either notBefore or notAfter MUST be present
+
+-- certificate policies extension OID and syntax
+
+id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 }
+
+anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 }
+
+CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
+
+PolicyInformation ::= SEQUENCE {
+ policyIdentifier CertPolicyId,
+ policyQualifiers SEQUENCE SIZE (1..MAX) OF
+ PolicyQualifierInfo OPTIONAL }
+
+CertPolicyId ::= OBJECT IDENTIFIER
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 126]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+PolicyQualifierInfo ::= SEQUENCE {
+ policyQualifierId PolicyQualifierId,
+ qualifier ANY DEFINED BY policyQualifierId }
+
+-- Implementations that recognize additional policy qualifiers MUST
+-- augment the following definition for PolicyQualifierId
+
+PolicyQualifierId ::= OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )
+
+-- CPS pointer qualifier
+
+CPSuri ::= IA5String
+
+-- user notice qualifier
+
+UserNotice ::= SEQUENCE {
+ noticeRef NoticeReference OPTIONAL,
+ explicitText DisplayText OPTIONAL }
+
+NoticeReference ::= SEQUENCE {
+ organization DisplayText,
+ noticeNumbers SEQUENCE OF INTEGER }
+
+DisplayText ::= CHOICE {
+ ia5String IA5String (SIZE (1..200)),
+ visibleString VisibleString (SIZE (1..200)),
+ bmpString BMPString (SIZE (1..200)),
+ utf8String UTF8String (SIZE (1..200)) }
+
+-- policy mapping extension OID and syntax
+
+id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 }
+
+PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
+ issuerDomainPolicy CertPolicyId,
+ subjectDomainPolicy CertPolicyId }
+
+-- subject alternative name extension OID and syntax
+
+id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 }
+
+SubjectAltName ::= GeneralNames
+
+GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 127]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+GeneralName ::= CHOICE {
+ otherName [0] AnotherName,
+ rfc822Name [1] IA5String,
+ dNSName [2] IA5String,
+ x400Address [3] ORAddress,
+ directoryName [4] Name,
+ ediPartyName [5] EDIPartyName,
+ uniformResourceIdentifier [6] IA5String,
+ iPAddress [7] OCTET STRING,
+ registeredID [8] OBJECT IDENTIFIER }
+
+-- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as
+-- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax
+
+AnotherName ::= SEQUENCE {
+ type-id OBJECT IDENTIFIER,
+ value [0] EXPLICIT ANY DEFINED BY type-id }
+
+EDIPartyName ::= SEQUENCE {
+ nameAssigner [0] DirectoryString OPTIONAL,
+ partyName [1] DirectoryString }
+
+-- issuer alternative name extension OID and syntax
+
+id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 }
+
+IssuerAltName ::= GeneralNames
+
+id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 }
+
+SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute
+
+-- basic constraints extension OID and syntax
+
+id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 }
+
+BasicConstraints ::= SEQUENCE {
+ cA BOOLEAN DEFAULT FALSE,
+ pathLenConstraint INTEGER (0..MAX) OPTIONAL }
+
+
+
+
+
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 128]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+-- name constraints extension OID and syntax
+
+id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 }
+
+NameConstraints ::= SEQUENCE {
+ permittedSubtrees [0] GeneralSubtrees OPTIONAL,
+ excludedSubtrees [1] GeneralSubtrees OPTIONAL }
+
+GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
+
+GeneralSubtree ::= SEQUENCE {
+ base GeneralName,
+ minimum [0] BaseDistance DEFAULT 0,
+ maximum [1] BaseDistance OPTIONAL }
+
+BaseDistance ::= INTEGER (0..MAX)
+
+-- policy constraints extension OID and syntax
+
+id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 }
+
+PolicyConstraints ::= SEQUENCE {
+ requireExplicitPolicy [0] SkipCerts OPTIONAL,
+ inhibitPolicyMapping [1] SkipCerts OPTIONAL }
+
+SkipCerts ::= INTEGER (0..MAX)
+
+-- CRL distribution points extension OID and syntax
+
+id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31}
+
+CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
+
+DistributionPoint ::= SEQUENCE {
+ distributionPoint [0] DistributionPointName OPTIONAL,
+ reasons [1] ReasonFlags OPTIONAL,
+ cRLIssuer [2] GeneralNames OPTIONAL }
+
+DistributionPointName ::= CHOICE {
+ fullName [0] GeneralNames,
+ nameRelativeToCRLIssuer [1] RelativeDistinguishedName }
+
+
+
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 129]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ReasonFlags ::= BIT STRING {
+ unused (0),
+ keyCompromise (1),
+ cACompromise (2),
+ affiliationChanged (3),
+ superseded (4),
+ cessationOfOperation (5),
+ certificateHold (6),
+ privilegeWithdrawn (7),
+ aACompromise (8) }
+
+-- extended key usage extension OID and syntax
+
+id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37}
+
+ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
+
+KeyPurposeId ::= OBJECT IDENTIFIER
+
+-- permit unspecified key uses
+
+anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 }
+
+-- extended key purpose OIDs
+
+id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
+id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }
+id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 }
+id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 }
+id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
+id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
+
+-- inhibit any policy OID and syntax
+
+id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 }
+
+InhibitAnyPolicy ::= SkipCerts
+
+-- freshest (delta)CRL extension OID and syntax
+
+id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 }
+
+FreshestCRL ::= CRLDistributionPoints
+
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 130]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+-- authority info access
+
+id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }
+
+AuthorityInfoAccessSyntax ::=
+ SEQUENCE SIZE (1..MAX) OF AccessDescription
+
+AccessDescription ::= SEQUENCE {
+ accessMethod OBJECT IDENTIFIER,
+ accessLocation GeneralName }
+
+-- subject info access
+
+id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 }
+
+SubjectInfoAccessSyntax ::=
+ SEQUENCE SIZE (1..MAX) OF AccessDescription
+
+-- CRL number extension OID and syntax
+
+id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
+
+CRLNumber ::= INTEGER (0..MAX)
+
+-- issuing distribution point extension OID and syntax
+
+id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }
+
+IssuingDistributionPoint ::= SEQUENCE {
+ distributionPoint [0] DistributionPointName OPTIONAL,
+ onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE,
+ onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE,
+ onlySomeReasons [3] ReasonFlags OPTIONAL,
+ indirectCRL [4] BOOLEAN DEFAULT FALSE,
+ onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
+ -- at most one of onlyContainsUserCerts, onlyContainsCACerts,
+ -- and onlyContainsAttributeCerts may be set to TRUE.
+
+id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
+
+BaseCRLNumber ::= CRLNumber
+
+
+
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 131]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+-- reason code extension OID and syntax
+
+id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 }
+
+CRLReason ::= ENUMERATED {
+ unspecified (0),
+ keyCompromise (1),
+ cACompromise (2),
+ affiliationChanged (3),
+ superseded (4),
+ cessationOfOperation (5),
+ certificateHold (6),
+ removeFromCRL (8),
+ privilegeWithdrawn (9),
+ aACompromise (10) }
+
+-- certificate issuer CRL entry extension OID and syntax
+
+id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 }
+
+CertificateIssuer ::= GeneralNames
+
+-- hold instruction extension OID and syntax
+
+id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 }
+
+HoldInstructionCode ::= OBJECT IDENTIFIER
+
+-- ANSI x9 arc holdinstruction arc
+
+holdInstruction OBJECT IDENTIFIER ::=
+ {joint-iso-itu-t(2) member-body(2) us(840) x9cm(10040) 2}
+
+-- ANSI X9 holdinstructions
+
+id-holdinstruction-none OBJECT IDENTIFIER ::=
+ {holdInstruction 1} -- deprecated
+
+id-holdinstruction-callissuer OBJECT IDENTIFIER ::= {holdInstruction 2}
+
+id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3}
+
+
+
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 132]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+-- invalidity date CRL entry extension OID and syntax
+
+id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 }
+
+InvalidityDate ::= GeneralizedTime
+
+END
+
+Appendix B. ASN.1 Notes
+
+ CAs MUST force the serialNumber to be a non-negative integer, that
+ is, the sign bit in the DER encoding of the INTEGER value MUST be
+ zero. This can be done by adding a leading (leftmost) `00'H octet if
+ necessary. This removes a potential ambiguity in mapping between a
+ string of octets and an integer value.
+
+ As noted in Section 4.1.2.2, serial numbers can be expected to
+ contain long integers. Certificate users MUST be able to handle
+ serialNumber values up to 20 octets in length. Conforming CAs MUST
+ NOT use serialNumber values longer than 20 octets.
+
+ As noted in Section 5.2.3, CRL numbers can be expected to contain
+ long integers. CRL validators MUST be able to handle cRLNumber
+ values up to 20 octets in length. Conforming CRL issuers MUST NOT
+ use cRLNumber values longer than 20 octets.
+
+ The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1
+ constructs. A valid ASN.1 sequence will have zero or more entries.
+ The SIZE (1..MAX) construct constrains the sequence to have at least
+ one entry. MAX indicates that the upper bound is unspecified.
+ Implementations are free to choose an upper bound that suits their
+ environment.
+
+ The character string type PrintableString supports a very basic Latin
+ character set: the lowercase letters 'a' through 'z', uppercase
+ letters 'A' through 'Z', the digits '0' through '9', eleven special
+ characters ' = ( ) + , - . / : ? and space.
+
+ Implementers should note that the at sign ('@') and underscore ('_')
+ characters are not supported by the ASN.1 type PrintableString.
+ These characters often appear in Internet addresses. Such addresses
+ MUST be encoded using an ASN.1 type that supports them. They are
+ usually encoded as IA5String in either the emailAddress attribute
+ within a distinguished name or the rfc822Name field of GeneralName.
+ Conforming implementations MUST NOT encode strings that include
+ either the at sign or underscore character as PrintableString.
+
+
+
+
+
+Cooper, et al. Standards Track [Page 133]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ The character string type TeletexString is a superset of
+ PrintableString. TeletexString supports a fairly standard (ASCII-
+ like) Latin character set: Latin characters with non-spacing accents
+ and Japanese characters.
+
+ Named bit lists are BIT STRINGs where the values have been assigned
+ names. This specification makes use of named bit lists in the
+ definitions for the key usage, CRL distribution points, and freshest
+ CRL certificate extensions, as well as the freshest CRL and issuing
+ distribution point CRL extensions. When DER encoding a named bit
+ list, trailing zeros MUST be omitted. That is, the encoded value
+ ends with the last named bit that is set to one.
+
+ The character string type UniversalString supports any of the
+ characters allowed by [ISO10646]. ISO 10646 is the Universal
+ multiple-octet coded Character Set (UCS).
+
+ The character string type UTF8String was introduced in the 1997
+ version of ASN.1, and UTF8String was added to the list of choices for
+ DirectoryString in the 2001 version of [X.520]. UTF8String is a
+ universal type and has been assigned tag number 12. The content of
+ UTF8String was defined by RFC 2044 and updated in RFC 2279, which was
+ updated in [RFC3629].
+
+ In anticipation of these changes, and in conformance with IETF Best
+ Practices codified in [RFC2277], IETF Policy on Character Sets and
+ Languages, this document includes UTF8String as a choice in
+ DirectoryString and in the userNotice certificate policy qualifier.
+
+ For many of the attribute types defined in [X.520], the
+ AttributeValue uses the DirectoryString type. Of the attributes
+ specified in Appendix A, the name, surname, givenName, initials,
+ generationQualifier, commonName, localityName, stateOrProvinceName,
+ organizationName, organizationalUnitName, title, and pseudonym
+ attributes all use the DirectoryString type. X.520 uses a
+ parameterized type definition [X.683] of DirectoryString to specify
+ the syntax for each of these attributes. The parameter is used to
+ indicate the maximum string length allowed for the attribute. In
+ Appendix A, in order to avoid the use of parameterized type
+ definitions, the DirectoryString type is written in its expanded form
+ for the definition of each of these attribute types. So, the ASN.1
+ in Appendix A describes the syntax for each of these attributes as
+ being a CHOICE of TeletexString, PrintableString, UniversalString,
+ UTF8String, and BMPString, with the appropriate constraints on the
+ string length applied to each of the types in the CHOICE, rather than
+ using the ASN.1 type DirectoryString to describe the syntax.
+
+
+
+
+
+Cooper, et al. Standards Track [Page 134]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ Implementers should note that the DER encoding of the SET OF values
+ requires ordering of the encodings of the values. In particular,
+ this issue arises with respect to distinguished names.
+
+ Implementers should note that the DER encoding of SET or SEQUENCE
+ components whose value is the DEFAULT omit the component from the
+ encoded certificate or CRL. For example, a BasicConstraints
+ extension whose cA value is FALSE would omit the cA boolean from the
+ encoded certificate.
+
+ Object Identifiers (OIDs) are used throughout this specification to
+ identify certificate policies, public key and signature algorithms,
+ certificate extensions, etc. There is no maximum size for OIDs.
+ This specification mandates support for OIDs that have arc elements
+ with values that are less than 2^28, that is, they MUST be between 0
+ and 268,435,455, inclusive. This allows each arc element to be
+ represented within a single 32-bit word. Implementations MUST also
+ support OIDs where the length of the dotted decimal (see Section 1.4
+ of [RFC4512]) string representation can be up to 100 bytes
+ (inclusive). Implementations MUST be able to handle OIDs with up to
+ 20 elements (inclusive). CAs SHOULD NOT issue certificates that
+ contain OIDs that exceed these requirements. Likewise, CRL issuers
+ SHOULD NOT issue CRLs that contain OIDs that exceed these
+ requirements.
+
+ The content-specific rules for encoding GeneralName field values in
+ the nameConstraints extension differ from rules that apply in other
+ extensions. In all other certificate, CRL, and CRL entry extensions
+ specified in this document the encoding rules conform to the rules
+ for the underlying type. For example, values in the
+ uniformResourceIdentifier field must contain a valid URI as specified
+ in [RFC3986]. The content-specific rules for encoding values in the
+ nameConstraints extension are specified in Section 4.2.1.10, and
+ these rules may not conform to the rules for the underlying type.
+ For example, when the uniformResourceIdentifier field appears in a
+ nameConstraints extension, it must hold a DNS name (e.g.,
+ "host.example.com" or ".example.com") rather than a URI.
+
+ Implementors are warned that the X.500 standards community has
+ developed a series of extensibility rules. These rules determine
+ when an ASN.1 definition can be changed without assigning a new
+ Object Identifier (OID). For example, at least two extension
+ definitions included in [RFC2459], the predecessor to this profile
+ document, have different ASN.1 definitions in this specification, but
+ the same OID is used. If unknown elements appear within an
+ extension, and the extension is not marked as critical, those unknown
+ elements ought to be ignored, as follows:
+
+
+
+
+Cooper, et al. Standards Track [Page 135]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ (a) ignore all unknown bit name assignments within a bit string;
+
+ (b) ignore all unknown named numbers in an ENUMERATED type or
+ INTEGER type that is being used in the enumerated style,
+ provided the number occurs as an optional element of a SET or
+ SEQUENCE; and
+
+ (c) ignore all unknown elements in SETs, at the end of SEQUENCEs,
+ or in CHOICEs where the CHOICE is itself an optional element
+ of a SET or SEQUENCE.
+
+ If an extension containing unexpected values is marked as critical,
+ the implementation MUST reject the certificate or CRL containing the
+ unrecognized extension.
+
+Appendix C. Examples
+
+ This appendix contains four examples: three certificates and a CRL.
+ The first two certificates and the CRL comprise a minimal
+ certification path.
+
+ Appendix C.1 contains an annotated hex dump of a "self-signed"
+ certificate issued by a CA whose distinguished name is
+ cn=Example CA,dc=example,dc=com. The certificate contains an RSA
+ public key, and is signed by the corresponding RSA private key.
+
+ Appendix C.2 contains an annotated hex dump of an end entity
+ certificate. The end entity certificate contains an RSA public key,
+ and is signed by the private key corresponding to the "self-signed"
+ certificate in Appendix C.1.
+
+ Appendix C.3 contains an annotated hex dump of an end entity
+ certificate that contains a DSA public key with parameters, and is
+ signed with DSA and SHA-1. This certificate is not part of the
+ minimal certification path.
+
+ Appendix C.4 contains an annotated hex dump of a CRL. The CRL is
+ issued by the CA whose distinguished name is
+ cn=Example CA,dc=example,dc=com and the list of revoked certificates
+ includes the end entity certificate presented in Appendix C.2.
+
+ The certificates were processed using Peter Gutmann's dumpasn1
+ utility to generate the output. The source for the dumpasn1 utility
+ is available at <http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c>.
+ The binaries for the certificates and CRLs are available at
+ http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/pkixtools.
+
+
+
+
+
+Cooper, et al. Standards Track [Page 136]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ In places in this appendix where a distinguished name is specified
+ using a string representation, the strings are formatted using the
+ rules specified in [RFC4514].
+
+C.1. RSA Self-Signed Certificate
+
+ This appendix contains an annotated hex dump of a 578 byte version 3
+ certificate. The certificate contains the following information:
+
+ (a) the serial number is 17;
+ (b) the certificate is signed with RSA and the SHA-1 hash algorithm;
+ (c) the issuer's distinguished name is
+ cn=Example CA,dc=example,dc=com;
+ (d) the subject's distinguished name is
+ cn=Example CA,dc=example,dc=com;
+ (e) the certificate was issued on April 30, 2004 and expired on
+ April 30, 2005;
+ (f) the certificate contains a 1024-bit RSA public key;
+ (g) the certificate contains a subject key identifier extension
+ generated using method (1) of Section 4.2.1.2; and
+ (h) the certificate is a CA certificate (as indicated through the
+ basic constraints extension).
+
+ 0 574: SEQUENCE {
+ 4 423: SEQUENCE {
+ 8 3: [0] {
+ 10 1: INTEGER 2
+ : }
+ 13 1: INTEGER 17
+ 16 13: SEQUENCE {
+ 18 9: OBJECT IDENTIFIER
+ : sha1withRSAEncryption (1 2 840 113549 1 1 5)
+ 29 0: NULL
+ : }
+ 31 67: SEQUENCE {
+ 33 19: SET {
+ 35 17: SEQUENCE {
+ 37 10: OBJECT IDENTIFIER
+ : domainComponent (0 9 2342 19200300 100 1 25)
+ 49 3: IA5String 'com'
+ : }
+ : }
+ 54 23: SET {
+ 56 21: SEQUENCE {
+ 58 10: OBJECT IDENTIFIER
+ : domainComponent (0 9 2342 19200300 100 1 25)
+ 70 7: IA5String 'example'
+ : }
+
+
+
+Cooper, et al. Standards Track [Page 137]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ : }
+ 79 19: SET {
+ 81 17: SEQUENCE {
+ 83 3: OBJECT IDENTIFIER commonName (2 5 4 3)
+ 88 10: PrintableString 'Example CA'
+ : }
+ : }
+ : }
+ 100 30: SEQUENCE {
+ 102 13: UTCTime 30/04/2004 14:25:34 GMT
+ 117 13: UTCTime 30/04/2005 14:25:34 GMT
+ : }
+ 132 67: SEQUENCE {
+ 134 19: SET {
+ 136 17: SEQUENCE {
+ 138 10: OBJECT IDENTIFIER
+ : domainComponent (0 9 2342 19200300 100 1 25)
+ 150 3: IA5String 'com'
+ : }
+ : }
+ 155 23: SET {
+ 157 21: SEQUENCE {
+ 159 10: OBJECT IDENTIFIER
+ : domainComponent (0 9 2342 19200300 100 1 25)
+ 171 7: IA5String 'example'
+ : }
+ : }
+ 180 19: SET {
+ 182 17: SEQUENCE {
+ 184 3: OBJECT IDENTIFIER commonName (2 5 4 3)
+ 189 10: PrintableString 'Example CA'
+ : }
+ : }
+ : }
+ 201 159: SEQUENCE {
+ 204 13: SEQUENCE {
+ 206 9: OBJECT IDENTIFIER
+ : rsaEncryption (1 2 840 113549 1 1 1)
+ 217 0: NULL
+ : }
+ 219 141: BIT STRING, encapsulates {
+ 223 137: SEQUENCE {
+ 226 129: INTEGER
+ : 00 C2 D7 97 6D 28 70 AA 5B CF 23 2E 80 70 39 EE
+ : DB 6F D5 2D D5 6A 4F 7A 34 2D F9 22 72 47 70 1D
+ : EF 80 E9 CA 30 8C 00 C4 9A 6E 5B 45 B4 6E A5 E6
+ : 6C 94 0D FA 91 E9 40 FC 25 9D C7 B7 68 19 56 8F
+ : 11 70 6A D7 F1 C9 11 4F 3A 7E 3F 99 8D 6E 76 A5
+
+
+
+Cooper, et al. Standards Track [Page 138]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ : 74 5F 5E A4 55 53 E5 C7 68 36 53 C7 1D 3B 12 A6
+ : 85 FE BD 6E A1 CA DF 35 50 AC 08 D7 B9 B4 7E 5C
+ : FE E2 A3 2C D1 23 84 AA 98 C0 9B 66 18 9A 68 47
+ : E9
+ 358 3: INTEGER 65537
+ : }
+ : }
+ : }
+ 363 66: [3] {
+ 365 64: SEQUENCE {
+ 367 29: SEQUENCE {
+ 369 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14)
+ 374 22: OCTET STRING, encapsulates {
+ 376 20: OCTET STRING
+ : 08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E 70 6A 4A
+ : 20 84 2C 32
+ : }
+ : }
+ 398 14: SEQUENCE {
+ 400 3: OBJECT IDENTIFIER keyUsage (2 5 29 15)
+ 405 1: BOOLEAN TRUE
+ 408 4: OCTET STRING, encapsulates {
+ 410 2: BIT STRING 1 unused bits
+ : '0000011'B
+ : }
+ : }
+ 414 15: SEQUENCE {
+ 416 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19)
+ 421 1: BOOLEAN TRUE
+ 424 5: OCTET STRING, encapsulates {
+ 426 3: SEQUENCE {
+ 428 1: BOOLEAN TRUE
+ : }
+ : }
+ : }
+ : }
+ : }
+ : }
+ 431 13: SEQUENCE {
+ 433 9: OBJECT IDENTIFIER
+ : sha1withRSAEncryption (1 2 840 113549 1 1 5)
+ 444 0: NULL
+ : }
+ 446 129: BIT STRING
+ : 6C F8 02 74 A6 61 E2 64 04 A6 54 0C 6C 72 13 AD
+ : 3C 47 FB F6 65 13 A9 85 90 33 EA 76 A3 26 D9 FC
+ : D1 0E 15 5F 28 B7 EF 93 BF 3C F3 E2 3E 7C B9 52
+ : FC 16 6E 29 AA E1 F4 7A 6F D5 7F EF B3 95 CA F3
+
+
+
+Cooper, et al. Standards Track [Page 139]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ : 66 88 83 4E A1 35 45 84 CB BC 9B B8 C8 AD C5 5E
+ : 46 D9 0B 0E 8D 80 E1 33 2B DC BE 2B 92 7E 4A 43
+ : A9 6A EF 8A 63 61 B3 6E 47 38 BE E8 0D A3 67 5D
+ : F3 FA 91 81 3C 92 BB C5 5F 25 25 EB 7C E7 D8 A1
+ : }
+
+C.2. End Entity Certificate Using RSA
+
+ This appendix contains an annotated hex dump of a 629-byte version 3
+ certificate. The certificate contains the following information:
+
+ (a) the serial number is 18;
+ (b) the certificate is signed with RSA and the SHA-1 hash algorithm;
+ (c) the issuer's distinguished name is
+ cn=Example CA,dc=example,dc=com;
+ (d) the subject's distinguished name is
+ cn=End Entity,dc=example,dc=com;
+ (e) the certificate was valid from September 15, 2004 through March
+ 15, 2005;
+ (f) the certificate contains a 1024-bit RSA public key;
+ (g) the certificate is an end entity certificate, as the basic
+ constraints extension is not present;
+ (h) the certificate contains an authority key identifier extension
+ matching the subject key identifier of the certificate in
+ appendix C.1; and
+ (i) the certificate includes one alternative name -- an electronic
+ mail address (rfc822Name) of "end.entity@example.com".
+
+ 0 625: SEQUENCE {
+ 4 474: SEQUENCE {
+ 8 3: [0] {
+ 10 1: INTEGER 2
+ : }
+ 13 1: INTEGER 18
+ 16 13: SEQUENCE {
+ 18 9: OBJECT IDENTIFIER
+ : sha1withRSAEncryption (1 2 840 113549 1 1 5)
+ 29 0: NULL
+ : }
+ 31 67: SEQUENCE {
+ 33 19: SET {
+ 35 17: SEQUENCE {
+ 37 10: OBJECT IDENTIFIER
+ : domainComponent (0 9 2342 19200300 100 1 25)
+ 49 3: IA5String 'com'
+ : }
+ : }
+ 54 23: SET {
+
+
+
+Cooper, et al. Standards Track [Page 140]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ 56 21: SEQUENCE {
+ 58 10: OBJECT IDENTIFIER
+ : domainComponent (0 9 2342 19200300 100 1 25)
+ 70 7: IA5String 'example'
+ : }
+ : }
+ 79 19: SET {
+ 81 17: SEQUENCE {
+ 83 3: OBJECT IDENTIFIER commonName (2 5 4 3)
+ 88 10: PrintableString 'Example CA'
+ : }
+ : }
+ : }
+ 100 30: SEQUENCE {
+ 102 13: UTCTime 15/09/2004 11:48:21 GMT
+ 117 13: UTCTime 15/03/2005 11:48:21 GMT
+ : }
+ 132 67: SEQUENCE {
+ 134 19: SET {
+ 136 17: SEQUENCE {
+ 138 10: OBJECT IDENTIFIER
+ : domainComponent (0 9 2342 19200300 100 1 25)
+ 150 3: IA5String 'com'
+ : }
+ : }
+ 155 23: SET {
+ 157 21: SEQUENCE {
+ 159 10: OBJECT IDENTIFIER
+ : domainComponent (0 9 2342 19200300 100 1 25)
+ 171 7: IA5String 'example'
+ : }
+ : }
+ 180 19: SET {
+ 182 17: SEQUENCE {
+ 184 3: OBJECT IDENTIFIER commonName (2 5 4 3)
+ 189 10: PrintableString 'End Entity'
+ : }
+ : }
+ : }
+ 201 159: SEQUENCE {
+ 204 13: SEQUENCE {
+ 206 9: OBJECT IDENTIFIER
+ : rsaEncryption (1 2 840 113549 1 1 1)
+ 217 0: NULL
+ : }
+ 219 141: BIT STRING, encapsulates {
+ 223 137: SEQUENCE {
+ 226 129: INTEGER
+
+
+
+Cooper, et al. Standards Track [Page 141]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ : 00 E1 6A E4 03 30 97 02 3C F4 10 F3 B5 1E 4D 7F
+ : 14 7B F6 F5 D0 78 E9 A4 8A F0 A3 75 EC ED B6 56
+ : 96 7F 88 99 85 9A F2 3E 68 77 87 EB 9E D1 9F C0
+ : B4 17 DC AB 89 23 A4 1D 7E 16 23 4C 4F A8 4D F5
+ : 31 B8 7C AA E3 1A 49 09 F4 4B 26 DB 27 67 30 82
+ : 12 01 4A E9 1A B6 C1 0C 53 8B 6C FC 2F 7A 43 EC
+ : 33 36 7E 32 B2 7B D5 AA CF 01 14 C6 12 EC 13 F2
+ : 2D 14 7A 8B 21 58 14 13 4C 46 A3 9A F2 16 95 FF
+ : 23
+ 358 3: INTEGER 65537
+ : }
+ : }
+ : }
+ 363 117: [3] {
+ 365 115: SEQUENCE {
+ 367 33: SEQUENCE {
+ 369 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17)
+ 374 26: OCTET STRING, encapsulates {
+ 376 24: SEQUENCE {
+ 378 22: [1] 'end.entity@example.com'
+ : }
+ : }
+ : }
+ 402 29: SEQUENCE {
+ 404 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14)
+ 409 22: OCTET STRING, encapsulates {
+ 411 20: OCTET STRING
+ : 17 7B 92 30 FF 44 D6 66 E1 90 10 22 6C 16 4F C0
+ : 8E 41 DD 6D
+ : }
+ : }
+ 433 31: SEQUENCE {
+ 435 3: OBJECT IDENTIFIER
+ : authorityKeyIdentifier (2 5 29 35)
+ 440 24: OCTET STRING, encapsulates {
+ 442 22: SEQUENCE {
+ 444 20: [0]
+ : 08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E 70 6A
+ : 4A 20 84 2C 32
+ : }
+ : }
+ : }
+ 466 14: SEQUENCE {
+ 468 3: OBJECT IDENTIFIER keyUsage (2 5 29 15)
+ 473 1: BOOLEAN TRUE
+ 476 4: OCTET STRING, encapsulates {
+ 478 2: BIT STRING 6 unused bits
+ : '11'B
+
+
+
+Cooper, et al. Standards Track [Page 142]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ : }
+ : }
+ : }
+ : }
+ : }
+ 482 13: SEQUENCE {
+ 484 9: OBJECT IDENTIFIER
+ : sha1withRSAEncryption (1 2 840 113549 1 1 5)
+ 495 0: NULL
+ : }
+ 497 129: BIT STRING
+ : 00 20 28 34 5B 68 32 01 BB 0A 36 0E AD 71 C5 95
+ : 1A E1 04 CF AE AD C7 62 14 A4 1B 36 31 C0 E2 0C
+ : 3D D9 1E C0 00 DC 10 A0 BA 85 6F 41 CB 62 7A B7
+ : 4C 63 81 26 5E D2 80 45 5E 33 E7 70 45 3B 39 3B
+ : 26 4A 9C 3B F2 26 36 69 08 79 BB FB 96 43 77 4B
+ : 61 8B A1 AB 91 64 E0 F3 37 61 3C 1A A3 A4 C9 8A
+ : B2 BF 73 D4 4D E4 58 E4 62 EA BC 20 74 92 86 0E
+ : CE 84 60 76 E9 73 BB C7 85 D3 91 45 EA 62 5D CD
+ : }
+
+C.3. End Entity Certificate Using DSA
+
+ This appendix contains an annotated hex dump of a 914-byte version 3
+ certificate. The certificate contains the following information:
+
+ (a) the serial number is 256;
+
+ (b) the certificate is signed with DSA and the SHA-1 hash algorithm;
+
+ (c) the issuer's distinguished name is cn=Example DSA
+ CA,dc=example,dc=com;
+
+ (d) the subject's distinguished name is cn=DSA End
+ Entity,dc=example,dc=com;
+
+ (e) the certificate was issued on May 2, 2004 and expired on May 2,
+ 2005;
+
+ (f) the certificate contains a 1024-bit DSA public key with
+ parameters;
+
+ (g) the certificate is an end entity certificate (not a CA
+ certificate);
+
+ (h) the certificate includes a subject alternative name of
+ "<http://www.example.com/users/DSAendentity.html>" and an issuer
+ alternative name of "<http://www.example.com>" -- both are URLs;
+
+
+
+Cooper, et al. Standards Track [Page 143]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ (i) the certificate includes an authority key identifier extension
+ and a certificate policies extension specifying the policy OID
+ 2.16.840.1.101.3.2.1.48.9; and
+
+ (j) the certificate includes a critical key usage extension
+ specifying that the public key is intended for verification of
+ digital signatures.
+
+ 0 910: SEQUENCE {
+ 4 846: SEQUENCE {
+ 8 3: [0] {
+ 10 1: INTEGER 2
+ : }
+ 13 2: INTEGER 256
+ 17 9: SEQUENCE {
+ 19 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
+ : }
+ 28 71: SEQUENCE {
+ 30 19: SET {
+ 32 17: SEQUENCE {
+ 34 10: OBJECT IDENTIFIER
+ : domainComponent (0 9 2342 19200300 100 1 25)
+ 46 3: IA5String 'com'
+ : }
+ : }
+ 51 23: SET {
+ 53 21: SEQUENCE {
+ 55 10: OBJECT IDENTIFIER
+ : domainComponent (0 9 2342 19200300 100 1 25)
+ 67 7: IA5String 'example'
+ : }
+ : }
+ 76 23: SET {
+ 78 21: SEQUENCE {
+ 80 3: OBJECT IDENTIFIER commonName (2 5 4 3)
+ 85 14: PrintableString 'Example DSA CA'
+ : }
+ : }
+ : }
+ 101 30: SEQUENCE {
+ 103 13: UTCTime 02/05/2004 16:47:38 GMT
+ 118 13: UTCTime 02/05/2005 16:47:38 GMT
+ : }
+ 133 71: SEQUENCE {
+ 135 19: SET {
+ 137 17: SEQUENCE {
+ 139 10: OBJECT IDENTIFIER
+ : domainComponent (0 9 2342 19200300 100 1 25)
+
+
+
+Cooper, et al. Standards Track [Page 144]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ 151 3: IA5String 'com'
+ : }
+ : }
+ 156 23: SET {
+ 158 21: SEQUENCE {
+ 160 10: OBJECT IDENTIFIER
+ : domainComponent (0 9 2342 19200300 100 1 25)
+ 172 7: IA5String 'example'
+ : }
+ : }
+ 181 23: SET {
+ 183 21: SEQUENCE {
+ 185 3: OBJECT IDENTIFIER commonName (2 5 4 3)
+ 190 14: PrintableString 'DSA End Entity'
+ : }
+ : }
+ : }
+ 206 439: SEQUENCE {
+ 210 300: SEQUENCE {
+ 214 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1)
+ 223 287: SEQUENCE {
+ 227 129: INTEGER
+ : 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC FB 95
+ : 32 AC 01 12 33 B9 E0 1C AD 90 9B BC 48 54 9E F3
+ : 94 77 3C 2C 71 35 55 E6 FE 4F 22 CB D5 D8 3E 89
+ : 93 33 4D FC BD 4F 41 64 3E A2 98 70 EC 31 B4 50
+ : DE EB F1 98 28 0A C9 3E 44 B3 FD 22 97 96 83 D0
+ : 18 A3 E3 BD 35 5B FF EE A3 21 72 6A 7B 96 DA B9
+ : 3F 1E 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A
+ : FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48 63 FE
+ : 43
+ 359 21: INTEGER
+ : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA 55 F7
+ : 7D 57 74 81 E5
+ 382 129: INTEGER
+ : 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91 C0 8E
+ : 47 F1 0A C3 01 47 C2 44 42 36 A9 92 81 DE 57 C5
+ : E0 68 86 58 00 7B 1F F9 9B 77 A1 C5 10 A5 80 91
+ : 78 51 51 3C F6 FC FC CC 46 C6 81 78 92 84 3D F4
+ : 93 3D 0C 38 7E 1A 5B 99 4E AB 14 64 F6 0C 21 22
+ : 4E 28 08 9C 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF
+ : 39 A2 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF
+ : F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE 1E 57
+ : 18
+ : }
+ : }
+ 514 132: BIT STRING, encapsulates {
+ 518 128: INTEGER
+
+
+
+Cooper, et al. Standards Track [Page 145]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ : 30 B6 75 F7 7C 20 31 AE 38 BB 7E 0D 2B AB A0 9C
+ : 4B DF 20 D5 24 13 3C CD 98 E5 5F 6C B7 C1 BA 4A
+ : BA A9 95 80 53 F0 0D 72 DC 33 37 F4 01 0B F5 04
+ : 1F 9D 2E 1F 62 D8 84 3A 9B 25 09 5A 2D C8 46 8E
+ : 2B D4 F5 0D 3B C7 2D C6 6C B9 98 C1 25 3A 44 4E
+ : 8E CA 95 61 35 7C CE 15 31 5C 23 13 1E A2 05 D1
+ : 7A 24 1C CB D3 72 09 90 FF 9B 9D 28 C0 A1 0A EC
+ : 46 9F 0D B8 D0 DC D0 18 A6 2B 5E F9 8F B5 95 BE
+ : }
+ : }
+ 649 202: [3] {
+ 652 199: SEQUENCE {
+ 655 57: SEQUENCE {
+ 657 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17)
+ 662 50: OCTET STRING, encapsulates {
+ 664 48: SEQUENCE {
+ 666 46: [6]
+ : 'http://www.example.com/users/DSAendentity.'
+ : 'html'
+ : }
+ : }
+ : }
+ 714 33: SEQUENCE {
+ 716 3: OBJECT IDENTIFIER issuerAltName (2 5 29 18)
+ 721 26: OCTET STRING, encapsulates {
+ 723 24: SEQUENCE {
+ 725 22: [6] 'http://www.example.com'
+ : }
+ : }
+ : }
+ 749 29: SEQUENCE {
+ 751 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14)
+ 756 22: OCTET STRING, encapsulates {
+ 758 20: OCTET STRING
+ : DD 25 66 96 43 AB 78 11 43 44 FE 95 16 F9 D9 B6
+ : B7 02 66 8D
+ : }
+ : }
+ 780 31: SEQUENCE {
+ 782 3: OBJECT IDENTIFIER
+ : authorityKeyIdentifier (2 5 29 35)
+ 787 24: OCTET STRING, encapsulates {
+ 789 22: SEQUENCE {
+ 791 20: [0]
+ : 86 CA A5 22 81 62 EF AD 0A 89 BC AD 72 41 2C
+ : 29 49 F4 86 56
+ : }
+ : }
+
+
+
+Cooper, et al. Standards Track [Page 146]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ : }
+ 813 23: SEQUENCE {
+ 815 3: OBJECT IDENTIFIER certificatePolicies (2 5 29 32)
+ 820 16: OCTET STRING, encapsulates {
+ 822 14: SEQUENCE {
+ 824 12: SEQUENCE {
+ 826 10: OBJECT IDENTIFIER '2 16 840 1 101 3 2 1 48 9'
+ : }
+ : }
+ : }
+ : }
+ 838 14: SEQUENCE {
+ 840 3: OBJECT IDENTIFIER keyUsage (2 5 29 15)
+ 845 1: BOOLEAN TRUE
+ 848 4: OCTET STRING, encapsulates {
+ 850 2: BIT STRING 7 unused bits
+ : '1'B (bit 0)
+ : }
+ : }
+ : }
+ : }
+ : }
+ 854 9: SEQUENCE {
+ 856 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
+ : }
+ 865 47: BIT STRING, encapsulates {
+ 868 44: SEQUENCE {
+ 870 20: INTEGER
+ : 65 57 07 34 DD DC CA CC 5E F4 02 F4 56 42 2C 5E
+ : E1 B3 3B 80
+ 892 20: INTEGER
+ : 60 F4 31 17 CA F4 CF FF EE F4 08 A7 D9 B2 61 BE
+ : B1 C3 DA BF
+ : }
+ : }
+ : }
+
+C.4. Certificate Revocation List
+
+ This appendix contains an annotated hex dump of a version 2 CRL with
+ two extensions (cRLNumber and authorityKeyIdentifier). The CRL was
+ issued by cn=Example CA,dc=example,dc=com on February 5, 2005; the
+ next scheduled issuance was February 6, 2005. The CRL includes one
+ revoked certificate: serial number 18, which was revoked on November
+ 19, 2004 due to keyCompromise. The CRL itself is number 12, and it
+ was signed with RSA and SHA-1.
+
+
+
+
+
+Cooper, et al. Standards Track [Page 147]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ 0 352: SEQUENCE {
+ 4 202: SEQUENCE {
+ 7 1: INTEGER 1
+ 10 13: SEQUENCE {
+ 12 9: OBJECT IDENTIFIER
+ : sha1withRSAEncryption (1 2 840 113549 1 1 5)
+ 23 0: NULL
+ : }
+ 25 67: SEQUENCE {
+ 27 19: SET {
+ 29 17: SEQUENCE {
+ 31 10: OBJECT IDENTIFIER
+ : domainComponent (0 9 2342 19200300 100 1 25)
+ 43 3: IA5String 'com'
+ : }
+ : }
+ 48 23: SET {
+ 50 21: SEQUENCE {
+ 52 10: OBJECT IDENTIFIER
+ : domainComponent (0 9 2342 19200300 100 1 25)
+ 64 7: IA5String 'example'
+ : }
+ : }
+ 73 19: SET {
+ 75 17: SEQUENCE {
+ 77 3: OBJECT IDENTIFIER commonName (2 5 4 3)
+ 82 10: PrintableString 'Example CA'
+ : }
+ : }
+ : }
+ 94 13: UTCTime 05/02/2005 12:00:00 GMT
+ 109 13: UTCTime 06/02/2005 12:00:00 GMT
+ 124 34: SEQUENCE {
+ 126 32: SEQUENCE {
+ 128 1: INTEGER 18
+ 131 13: UTCTime 19/11/2004 15:57:03 GMT
+ 146 12: SEQUENCE {
+ 148 10: SEQUENCE {
+ 150 3: OBJECT IDENTIFIER cRLReason (2 5 29 21)
+ 155 3: OCTET STRING, encapsulates {
+ 157 1: ENUMERATED 1
+ : }
+ : }
+ : }
+ : }
+ : }
+ 160 47: [0] {
+ 162 45: SEQUENCE {
+
+
+
+Cooper, et al. Standards Track [Page 148]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+ 164 31: SEQUENCE {
+ 166 3: OBJECT IDENTIFIER
+ : authorityKeyIdentifier (2 5 29 35)
+ 171 24: OCTET STRING, encapsulates {
+ 173 22: SEQUENCE {
+ 175 20: [0]
+ : 08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E 70 6A
+ : 4A 20 84 2C 32
+ : }
+ : }
+ : }
+ 197 10: SEQUENCE {
+ 199 3: OBJECT IDENTIFIER cRLNumber (2 5 29 20)
+ 204 3: OCTET STRING, encapsulates {
+ 206 1: INTEGER 12
+ : }
+ : }
+ : }
+ : }
+ : }
+ 209 13: SEQUENCE {
+ 211 9: OBJECT IDENTIFIER
+ : sha1withRSAEncryption (1 2 840 113549 1 1 5)
+ 222 0: NULL
+ : }
+ 224 129: BIT STRING
+ : 22 DC 18 7D F7 08 CE CC 75 D0 D0 6A 9B AD 10 F4
+ : 76 23 B4 81 6E B5 6D BE 0E FB 15 14 6C C8 17 6D
+ : 1F EE 90 17 A2 6F 60 E4 BD AA 8C 55 DE 8E 84 6F
+ : 92 F8 9F 10 12 27 AF 4A D4 2F 85 E2 36 44 7D AA
+ : A3 4C 25 38 15 FF 00 FD 3E 7E EE 3D 26 12 EB D8
+ : E7 2B 62 E2 2B C3 46 80 EF 78 82 D1 15 C6 D0 9C
+ : 72 6A CB CE 7A ED 67 99 8B 6E 70 81 7D 43 42 74
+ : C1 A6 AF C1 55 17 A2 33 4C D6 06 98 2B A4 FC 2E
+ : }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 149]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+Authors' Addresses
+
+ David Cooper
+ National Institute of Standards and Technology
+ 100 Bureau Drive, Mail Stop 8930
+ Gaithersburg, MD 20899-8930
+ USA
+ EMail: david.cooper@nist.gov
+
+ Stefan Santesson
+ Microsoft
+ One Microsoft Way
+ Redmond, WA 98052
+ USA
+ EMail: stefans@microsoft.com
+
+ Stephen Farrell
+ Distributed Systems Group
+ Computer Science Department
+ Trinity College Dublin
+ Ireland
+ EMail: stephen.farrell@cs.tcd.ie
+
+ Sharon Boeyen
+ Entrust
+ 1000 Innovation Drive
+ Ottawa, Ontario
+ Canada K2K 3E7
+ EMail: sharon.boeyen@entrust.com
+
+ Russell Housley
+ Vigil Security, LLC
+ 918 Spring Knoll Drive
+ Herndon, VA 20170
+ USA
+ EMail: housley@vigilsec.com
+
+ Tim Polk
+ National Institute of Standards and Technology
+ 100 Bureau Drive, Mail Stop 8930
+ Gaithersburg, MD 20899-8930
+ USA
+ EMail: wpolk@nist.gov
+
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 150]
+
+RFC 5280 PKIX Certificate and CRL Profile May 2008
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2008).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Cooper, et al. Standards Track [Page 151]
+