| |
| |
| |
| |
| |
| |
| Network Working Group R. Housley |
| Request for Comments: 3280 RSA Laboratories |
| Obsoletes: 2459 W. Polk |
| Category: Standards Track NIST |
| W. Ford |
| VeriSign |
| D. Solo |
| Citigroup |
| April 2002 |
| |
| 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. |
| |
| Copyright Notice |
| |
| Copyright (C) The Internet Society (2002). All Rights Reserved. |
| |
| 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 are 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, and required extensions are defined. An |
| algorithm for X.509 certification path validation is described. An |
| ASN.1 module and examples are provided in the appendices. |
| |
| Table of Contents |
| |
| 1 Introduction . . . . . . . . . . . . . . . . . . . . . . 4 |
| 2 Requirements and Assumptions . . . . . . . . . . . . . . 5 |
| 2.1 Communication and Topology . . . . . . . . . . . . . . 6 |
| 2.2 Acceptability Criteria . . . . . . . . . . . . . . . . 6 |
| 2.3 User Expectations . . . . . . . . . . . . . . . . . . . 7 |
| 2.4 Administrator Expectations . . . . . . . . . . . . . . 7 |
| 3 Overview of Approach . . . . . . . . . . . . . . . . . . 7 |
| |
| |
| |
| Housley, et. al. Standards Track [Page 1] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 3.1 X.509 Version 3 Certificate . . . . . . . . . . . . . . 8 |
| 3.2 Certification Paths and Trust . . . . . . . . . . . . . 9 |
| 3.3 Revocation . . . . . . . . . . . . . . . . . . . . . . 11 |
| 3.4 Operational Protocols . . . . . . . . . . . . . . . . . 13 |
| 3.5 Management Protocols . . . . . . . . . . . . . . . . . 13 |
| 4 Certificate and Certificate Extensions Profile . . . . . 14 |
| 4.1 Basic Certificate Fields . . . . . . . . . . . . . . . 15 |
| 4.1.1 Certificate Fields . . . . . . . . . . . . . . . . . 16 |
| 4.1.1.1 tbsCertificate . . . . . . . . . . . . . . . . . . 16 |
| 4.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . 16 |
| 4.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . 16 |
| 4.1.2 TBSCertificate . . . . . . . . . . . . . . . . . . . 17 |
| 4.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . 17 |
| 4.1.2.2 Serial number . . . . . . . . . . . . . . . . . . . 17 |
| 4.1.2.3 Signature . . . . . . . . . . . . . . . . . . . . . 18 |
| 4.1.2.4 Issuer . . . . . . . . . . . . . . . . . . . . . . 18 |
| 4.1.2.5 Validity . . . . . . . . . . . . . . . . . . . . . 22 |
| 4.1.2.5.1 UTCTime . . . . . . . . . . . . . . . . . . . . . 22 |
| 4.1.2.5.2 GeneralizedTime . . . . . . . . . . . . . . . . . 22 |
| 4.1.2.6 Subject . . . . . . . . . . . . . . . . . . . . . . 23 |
| 4.1.2.7 Subject Public Key Info . . . . . . . . . . . . . . 24 |
| 4.1.2.8 Unique Identifiers . . . . . . . . . . . . . . . . 24 |
| 4.1.2.9 Extensions . . . . . . . . . . . . . . . . . . . . . 24 |
| 4.2 Certificate Extensions . . . . . . . . . . . . . . . . 24 |
| 4.2.1 Standard Extensions . . . . . . . . . . . . . . . . . 25 |
| 4.2.1.1 Authority Key Identifier . . . . . . . . . . . . . 26 |
| 4.2.1.2 Subject Key Identifier . . . . . . . . . . . . . . 27 |
| 4.2.1.3 Key Usage . . . . . . . . . . . . . . . . . . . . . 28 |
| 4.2.1.4 Private Key Usage Period . . . . . . . . . . . . . 29 |
| 4.2.1.5 Certificate Policies . . . . . . . . . . . . . . . 30 |
| 4.2.1.6 Policy Mappings . . . . . . . . . . . . . . . . . . 33 |
| 4.2.1.7 Subject Alternative Name . . . . . . . . . . . . . 33 |
| 4.2.1.8 Issuer Alternative Name . . . . . . . . . . . . . . 36 |
| 4.2.1.9 Subject Directory Attributes . . . . . . . . . . . 36 |
| 4.2.1.10 Basic Constraints . . . . . . . . . . . . . . . . 36 |
| 4.2.1.11 Name Constraints . . . . . . . . . . . . . . . . . 37 |
| 4.2.1.12 Policy Constraints . . . . . . . . . . . . . . . . 40 |
| 4.2.1.13 Extended Key Usage . . . . . . . . . . . . . . . . 40 |
| 4.2.1.14 CRL Distribution Points . . . . . . . . . . . . . 42 |
| 4.2.1.15 Inhibit Any-Policy . . . . . . . . . . . . . . . . 44 |
| 4.2.1.16 Freshest CRL . . . . . . . . . . . . . . . . . . . 44 |
| 4.2.2 Internet Certificate Extensions . . . . . . . . . . . 45 |
| 4.2.2.1 Authority Information Access . . . . . . . . . . . 45 |
| 4.2.2.2 Subject Information Access . . . . . . . . . . . . 46 |
| 5 CRL and CRL Extensions Profile . . . . . . . . . . . . . 48 |
| 5.1 CRL Fields . . . . . . . . . . . . . . . . . . . . . . 49 |
| 5.1.1 CertificateList Fields . . . . . . . . . . . . . . . 50 |
| 5.1.1.1 tbsCertList . . . . . . . . . . . . . . . . . . . . 50 |
| |
| |
| |
| Housley, et. al. Standards Track [Page 2] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 5.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . 50 |
| 5.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . 51 |
| 5.1.2 Certificate List "To Be Signed" . . . . . . . . . . . 51 |
| 5.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . 52 |
| 5.1.2.2 Signature . . . . . . . . . . . . . . . . . . . . . 52 |
| 5.1.2.3 Issuer Name . . . . . . . . . . . . . . . . . . . . 52 |
| 5.1.2.4 This Update . . . . . . . . . . . . . . . . . . . . 52 |
| 5.1.2.5 Next Update . . . . . . . . . . . . . . . . . . . . 53 |
| 5.1.2.6 Revoked Certificates . . . . . . . . . . . . . . . 53 |
| 5.1.2.7 Extensions . . . . . . . . . . . . . . . . . . . . 53 |
| 5.2 CRL Extensions . . . . . . . . . . . . . . . . . . . . 53 |
| 5.2.1 Authority Key Identifier . . . . . . . . . . . . . . 54 |
| 5.2.2 Issuer Alternative Name . . . . . . . . . . . . . . . 54 |
| 5.2.3 CRL Number . . . . . . . . . . . . . . . . . . . . . 55 |
| 5.2.4 Delta CRL Indicator . . . . . . . . . . . . . . . . . 55 |
| 5.2.5 Issuing Distribution Point . . . . . . . . . . . . . 58 |
| 5.2.6 Freshest CRL . . . . . . . . . . . . . . . . . . . . 59 |
| 5.3 CRL Entry Extensions . . . . . . . . . . . . . . . . . 60 |
| 5.3.1 Reason Code . . . . . . . . . . . . . . . . . . . . . 60 |
| 5.3.2 Hold Instruction Code . . . . . . . . . . . . . . . . 61 |
| 5.3.3 Invalidity Date . . . . . . . . . . . . . . . . . . . 62 |
| 5.3.4 Certificate Issuer . . . . . . . . . . . . . . . . . 62 |
| 6 Certificate Path Validation . . . . . . . . . . . . . . . 62 |
| 6.1 Basic Path Validation . . . . . . . . . . . . . . . . . 63 |
| 6.1.1 Inputs . . . . . . . . . . . . . . . . . . . . . . . 66 |
| 6.1.2 Initialization . . . . . . . . . . . . . . . . . . . 67 |
| 6.1.3 Basic Certificate Processing . . . . . . . . . . . . 70 |
| 6.1.4 Preparation for Certificate i+1 . . . . . . . . . . . 75 |
| 6.1.5 Wrap-up procedure . . . . . . . . . . . . . . . . . . 78 |
| 6.1.6 Outputs . . . . . . . . . . . . . . . . . . . . . . . 80 |
| 6.2 Extending Path Validation . . . . . . . . . . . . . . . 80 |
| 6.3 CRL Validation . . . . . . . . . . . . . . . . . . . . 81 |
| 6.3.1 Revocation Inputs . . . . . . . . . . . . . . . . . . 82 |
| 6.3.2 Initialization and Revocation State Variables . . . . 82 |
| 6.3.3 CRL Processing . . . . . . . . . . . . . . . . . . . 83 |
| 7 References . . . . . . . . . . . . . . . . . . . . . . . 86 |
| 8 Intellectual Property Rights . . . . . . . . . . . . . . 88 |
| 9 Security Considerations . . . . . . . . . . . . . . . . . 89 |
| Appendix A. ASN.1 Structures and OIDs . . . . . . . . . . . 92 |
| A.1 Explicitly Tagged Module, 1988 Syntax . . . . . . . . . 92 |
| A.2 Implicitly Tagged Module, 1988 Syntax . . . . . . . . . 105 |
| Appendix B. ASN.1 Notes . . . . . . . . . . . . . . . . . . 112 |
| Appendix C. Examples . . . . . . . . . . . . . . . . . . . 115 |
| C.1 DSA Self-Signed Certificate . . . . . . . . . . . . . . 115 |
| C.2 End Entity Certificate Using DSA . . . . . . . . . . . 119 |
| C.3 End Entity Certificate Using RSA . . . . . . . . . . . 122 |
| C.4 Certificate Revocation List . . . . . . . . . . . . . . 126 |
| Author Addresses . . . . . . . . . . . . . . . . . . . . . . 128 |
| |
| |
| |
| Housley, et. al. Standards Track [Page 3] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| Full Copyright Statement . . . . . . . . . . . . . . . . . . 129 |
| |
| 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 |
| which 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 are 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 which may be |
| useful in the Internet PKI. The profiles are presented in the 1988 |
| Abstract Syntax Notation One (ASN.1) rather than the 1997 ASN.1 |
| syntax used in the most recent ISO/IEC/ITU-T standards. |
| |
| Section 6 includes certification path validation procedures. These |
| procedures are based upon the ISO/IEC/ITU-T definition. |
| Implementations are REQUIRED to derive the same results but are not |
| required to use the specified procedures. |
| |
| Procedures for identification and encoding of public key materials |
| and digital signatures are defined in [PKIXALGS]. Implementations of |
| this specification are not required to use any particular |
| cryptographic algorithms. However, conforming implementations which |
| use the algorithms identified in [PKIXALGS] MUST identify and encode |
| the public key materials and digital signatures as described in that |
| specification. |
| |
| 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 a conforming certificate and a conforming CRL. |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 4] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| This specification obsoletes RFC 2459. This specification differs |
| from RFC 2459 in five basic areas: |
| |
| * To promote interoperable implementations, a detailed algorithm |
| for certification path validation is included in section 6.1 of |
| this specification; RFC 2459 provided only a high-level |
| description of path validation. |
| |
| * An algorithm for determining the status of a certificate using |
| CRLs is provided in section 6.3 of this specification. This |
| material was not present in RFC 2459. |
| |
| * To accommodate new usage models, detailed information describing |
| the use of delta CRLs is provided in Section 5 of this |
| specification. |
| |
| * Identification and encoding of public key materials and digital |
| signatures are not included in this specification, but are now |
| described in a companion specification [PKIXALGS]. |
| |
| * Four additional extensions are specified: three certificate |
| extensions and one CRL extension. The certificate extensions are |
| subject info access, inhibit any-policy, and freshest CRL. The |
| freshest CRL extension is also defined as a CRL extension. |
| |
| * Throughout the specification, clarifications have been |
| introduced to enhance consistency with the ITU-T X.509 |
| specification. X.509 defines the certificate and CRL format as |
| well as many of the extensions that appear in this specification. |
| These changes were introduced to improve the likelihood of |
| interoperability between implementations based on this |
| specification with implementations based on the ITU-T |
| specification. |
| |
| 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 RFC 2119. |
| |
| 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 |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 5] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| certificates, this document defines a profile to promote the |
| development of certificate management systems; development of |
| application tools; and interoperability determined by policy. |
| |
| Some communities will need to supplement, or possibly replace, this |
| profile in order to meet the requirements of specialized application |
| domains or environments with additional authorization, assurance, or |
| operational requirements. However, for basic applications, common |
| representations of frequently used attributes are defined so that |
| application developers can obtain necessary information without |
| regard to the issuer of a particular certificate or certificate |
| revocation list (CRL). |
| |
| A certificate user should review the certificate policy generated by |
| the certification authority (CA) before relying on the authentication |
| or non-repudiation services associated with the public key in a |
| particular certificate. To this end, this standard does not |
| prescribe legally binding rules or duties. |
| |
| As supplemental authorization and attribute management tools emerge, |
| such as attribute certificates, it may be appropriate to limit the |
| authenticated attributes that are included in a certificate. These |
| other management tools may provide more appropriate methods of |
| conveying many authenticated attributes. |
| |
| 2.1 Communication and Topology |
| |
| The users of certificates will operate in a wide range of |
| environments with respect to their communication topology, especially |
| users of secure electronic mail. This profile supports users without |
| high bandwidth, real-time IP connectivity, or high connection |
| availability. In addition, the profile allows for the presence of |
| firewall or other filtered communication. |
| |
| This profile does not assume the deployment of an X.500 Directory |
| system or a LDAP directory system. The profile does not prohibit the |
| use of an X.500 Directory or a 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. |
| |
| |
| |
| Housley, et. al. Standards Track [Page 6] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 2.3 User Expectations |
| |
| Users of the Internet PKI are people and processes who use client |
| software and are the subjects named in certificates. These uses |
| include readers and writers of electronic mail, the clients for WWW |
| browsers, WWW servers, and the key manager for IPsec within a router. |
| This profile recognizes the limitations of the platforms these users |
| employ and the limitations in sophistication and attentiveness of the |
| users themselves. This manifests itself in minimal user |
| configuration responsibility (e.g., trusted CA keys, rules), explicit |
| platform usage constraints within the certificate, certification path |
| constraints which shield the user from many malicious actions, and |
| applications which 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 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: an optional system to which a CA delegates the |
| publication of certificate revocation lists; |
| 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. |
| |
| Note that an Attribute Authority (AA) might also choose to delegate |
| the publication of CRLs to a CRL issuer. |
| |
| |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 7] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| +---+ |
| | 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 |
| |
| |
| |
| Housley, et. al. Standards Track [Page 8] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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 [RFC 1422]. The experience gained in attempts to |
| deploy RFC 1422 made it clear that the v1 and v2 certificate formats |
| are deficient in several respects. Most importantly, more fields |
| were needed to carry information which PEM design and implementation |
| experience had proven necessary. In response to these new |
| requirements, 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 |
| |
| |
| |
| Housley, et. al. Standards Track [Page 9] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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. |
| |
| The RFC 1422 uses the X.509 v1 certificate formats. 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: |
| |
| |
| |
| Housley, et. al. Standards Track [Page 10] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| (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. |
| |
| 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. |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 11] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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 which is signed by a CA or CRL |
| issuer and made freely available in a public repository. Each |
| revoked certificate is identified in a CRL by its certificate serial |
| number. When a certificate-using system uses a certificate (e.g., |
| for verifying a remote user's digital signature), that system not |
| only checks the certificate signature and validity but also acquires |
| a suitably-recent CRL and checks that the certificate serial number |
| is not on that CRL. The meaning of "suitably-recent" may vary with |
| local policy, but it usually means the most recently-issued CRL. A |
| new CRL is issued on a regular periodic basis (e.g., hourly, daily, |
| or weekly). An entry is added to the CRL as part of the next update |
| following notification of revocation. An entry MUST NOT be removed |
| from the CRL until it appears on one regularly scheduled CRL issued |
| beyond the revoked certificate's validity period. |
| |
| An advantage of this revocation method is that CRLs may be |
| distributed by exactly the same means as certificates themselves, |
| namely, via untrusted servers and untrusted communications. |
| |
| One limitation of the CRL revocation method, using untrusted |
| communications and servers, is that the time granularity of |
| revocation is limited to the CRL issue period. For example, if a |
| revocation is reported now, that revocation will not be reliably |
| notified to certificate-using systems until all currently issued CRLs |
| are 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. |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 12] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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 which cross-certify each |
| other. The set of functions which potentially need to be supported |
| by management protocols include: |
| |
| (a) registration: This is the process whereby a user first makes |
| itself known to a CA (directly, or through an RA), prior to that |
| CA issuing a certificate or certificates for that user. |
| |
| (b) initialization: Before a client system can operate securely |
| it is necessary to install key materials which 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. |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 13] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| (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 which contains a CA |
| signature key used for issuing certificates. |
| |
| Note that on-line protocols are not the only way of implementing the |
| above functions. For all functions there are off-line methods of |
| achieving the same result, and this specification does not mandate |
| use of on-line protocols. For example, when hardware tokens are |
| used, many of the functions may be achieved as part of the physical |
| token delivery. Furthermore, some of the above functions may be |
| combined into one protocol exchange. In particular, two or more of |
| the registration, initialization, and certification functions can be |
| combined into one protocol exchange. |
| |
| The PKIX series of specifications defines a set of standard message |
| formats supporting the above functions. The protocols for conveying |
| these messages in different environments (e.g., e-mail, 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. |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 14] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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 |
| 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 |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 15] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| Extension ::= SEQUENCE { |
| extnID OBJECT IDENTIFIER, |
| critical BOOLEAN DEFAULT FALSE, |
| extnValue OCTET STRING } |
| |
| 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. |
| |
| 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. |
| [PKIXALGS] lists 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 |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 16] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| signature value is encoded as a BIT STRING and included in the |
| signature field. The details of this process are specified for each |
| of algorithms listed in [PKIXALGS]. |
| |
| 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 who issued it. Every |
| TBSCertificate contains the names of the subject and issuer, a public |
| 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 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. |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 17] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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. Conformant 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 |
| 4.1.1.2). The contents of the optional parameters field will vary |
| according to the algorithm identified. [PKIXALGS] lists the |
| supported signature algorithms, but other signature algorithms MAY |
| also be supported. |
| |
| 4.1.2.4 Issuer |
| |
| The issuer field identifies the entity who 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 { |
| RDNSequence } |
| |
| RDNSequence ::= SEQUENCE OF RelativeDistinguishedName |
| |
| RelativeDistinguishedName ::= |
| SET OF AttributeTypeAndValue |
| |
| AttributeTypeAndValue ::= SEQUENCE { |
| type AttributeType, |
| value AttributeValue } |
| |
| AttributeType ::= OBJECT IDENTIFIER |
| |
| AttributeValue ::= ANY DEFINED BY AttributeType |
| |
| |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 18] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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. The |
| UTF8String encoding [RFC 2279] is the preferred encoding, and all |
| certificates issued after December 31, 2003 MUST use the UTF8String |
| encoding of DirectoryString (except as noted below). Until that |
| date, conforming CAs MUST choose from the following options when |
| creating a distinguished name, including their own: |
| |
| (a) if the character set is sufficient, the string MAY be |
| represented as a PrintableString; |
| |
| (b) failing (a), if the BMPString character set is sufficient the |
| string MAY be represented as a BMPString; and |
| |
| (c) failing (a) and (b), the string MUST be represented as a |
| UTF8String. If (a) or (b) is satisfied, the CA MAY still choose |
| to represent the string as a UTF8String. |
| |
| Exceptions to the December 31, 2003 UTF8 encoding requirements are as |
| follows: |
| |
| (a) CAs MAY issue "name rollover" certificates to support an |
| orderly migration to UTF8String encoding. Such certificates would |
| include the CA's UTF8String encoded name as issuer and and the old |
| name encoding as subject, or vice-versa. |
| |
| (b) As stated in section 4.1.2.6, the subject field MUST be |
| populated with a non-empty distinguished name matching the |
| contents of the issuer field in all certificates issued by the |
| subject CA regardless of encoding. |
| |
| The TeletexString 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. Certificate users SHOULD be |
| prepared to receive certificates with these types. |
| |
| |
| |
| Housley, et. al. Standards Track [Page 19] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| In addition, many legacy implementations support names encoded in the |
| ISO 8859-1 character set (Latin1String) [ISO 8859-1] but tag them as |
| TeletexString. TeletexString encodes a larger character set than ISO |
| 8859-1, but it encodes some characters differently. Implementations |
| SHOULD be prepared to handle both encodings. |
| |
| 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 [RFC 2247]. |
| 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 |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 20] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| alternative name field. Implementations are not required to convert |
| such names into DNS names. The syntax and associated OID for this |
| attribute type is provided in the ASN.1 modules in Appendix A. |
| |
| 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. |
| |
| This specification requires only a subset of the name comparison |
| functionality specified in the X.500 series of specifications. |
| Conforming implementations are REQUIRED to implement the following |
| name comparison rules: |
| |
| (a) attribute values encoded in different types (e.g., |
| PrintableString and BMPString) MAY be assumed to represent |
| different strings; |
| |
| (b) attribute values in types other than PrintableString are case |
| sensitive (this permits matching of attribute values as binary |
| objects); |
| |
| (c) attribute values in PrintableString are not case sensitive |
| (e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and |
| |
| (d) attribute values in PrintableString are compared after |
| removing leading and trailing white space and converting internal |
| substrings of one or more consecutive white space characters to a |
| single space. |
| |
| These name comparison rules permit a certificate user to validate |
| certificates issued using languages or encodings unfamiliar to the |
| certificate user. |
| |
| In addition, implementations of this specification MAY use these |
| comparison rules to process unfamiliar attribute types for name |
| chaining. This allows implementations to process certificates with |
| unfamiliar attributes in the issuer name. |
| |
| Note that the comparison rules defined in the X.500 series of |
| specifications indicate that the character sets used to encode data |
| in distinguished names are irrelevant. The characters themselves are |
| compared without regard to encoding. Implementations of this profile |
| are permitted to use the comparison algorithm defined in the X.500 |
| series. Such an implementation will recognize a superset of name |
| matches recognized by the algorithm specified above. |
| |
| |
| |
| Housley, et. al. Standards Track [Page 21] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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. |
| |
| The validity period for a certificate is the period of time from |
| notBefore through notAfter, inclusive. |
| |
| 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 |
| 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 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. |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 22] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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 4.2.1.10, 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 4.2.1.3, is |
| present and the value of cRLSign 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 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 name field. |
| A CA MAY issue more than one certificate with the same DN to the same |
| subject entity. |
| |
| The subject name 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). When encoding attribute values of |
| type DirectoryString, the encoding rules for the issuer field MUST be |
| implemented. 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 these comparison rules to process unfamiliar |
| attribute types (i.e., for name chaining). This allows |
| implementations to process certificates with unfamiliar attributes in |
| the subject name. |
| |
| In addition, legacy implementations exist where an RFC 822 name is |
| embedded in the subject distinguished name as an EmailAddress |
| attribute. 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., "fanfeedback@redsox.com" is the same as |
| "FANFEEDBACK@REDSOX.COM"). |
| |
| |
| |
| Housley, et. al. Standards Track [Page 23] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| Conforming implementations generating new certificates with |
| electronic mail addresses MUST use the rfc822Name in the subject |
| alternative name field (section 4.2.1.7) 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 [PKIXALGS]. |
| |
| 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 SHOULD NOT |
| generate certificates with unique identifiers. Applications |
| conforming to this profile SHOULD be capable of parsing 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 is 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 a certification hierarchy. 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; however, a non-critical |
| extension MAY be ignored if it is not recognized. The following |
| sections present recommended extensions used within Internet |
| |
| |
| |
| Housley, et. al. Standards Track [Page 24] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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 which |
| 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 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. |
| |
| Conforming CAs MUST support key identifiers (sections 4.2.1.1 and |
| 4.2.1.2), basic constraints (section 4.2.1.10), key usage (section |
| 4.2.1.3), and certificate policies (section 4.2.1.5) 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.7). Support for the remaining extensions is OPTIONAL. |
| Conforming CAs MAY support extensions that are not identified within |
| 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.5), the subject alternative name (section |
| 4.2.1.7), basic constraints (section 4.2.1.10), name constraints |
| (section 4.2.1.11), policy constraints (section 4.2.1.12), extended |
| key usage (section 4.2.1.13), and inhibit any-policy (section |
| 4.2.1.15). |
| |
| 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 mapping (section 4.2.1.6) 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 } |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 25] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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 on 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 |
| that generates unique values. Two common methods for generating key |
| identifiers from the public key, and one common method for generating |
| unique values, 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. |
| 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. |
| |
| This extension MUST NOT be marked 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 |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 26] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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.10) where |
| the value of cA is TRUE. 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. |
| |
| 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). |
| |
| (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 bit string bits). |
| |
| One common method for generating unique values is a monotonically |
| increasing sequence of integers. |
| |
| 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. Where a key identifier has been previously |
| established, the CA SHOULD use the previously established identifier. |
| |
| This extension MUST NOT be marked critical. |
| |
| |
| |
| Housley, et. al. Standards Track [Page 27] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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. |
| |
| This extension MUST appear in certificates that contain public keys |
| that are used to validate digital signatures on other public key |
| certificates or CRLs. When this extension appears, it SHOULD be |
| marked critical. |
| |
| id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } |
| |
| KeyUsage ::= BIT STRING { |
| digitalSignature (0), |
| nonRepudiation (1), |
| 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 with a digital signature mechanism to support security |
| services other than certificate signing (bit 5), or CRL signing |
| (bit 6). Digital signature mechanisms are often used for entity |
| authentication and data origin authentication with integrity. |
| |
| The nonRepudiation bit is asserted when the subject public key is |
| used to verify digital signatures used to provide a non- |
| repudiation service which protects against the signing entity |
| falsely denying some action, excluding certificate or CRL signing. |
| In the case of later conflict, a reliable third party may |
| determine the authenticity of the signed data. |
| |
| |
| |
| Housley, et. al. Standards Track [Page 28] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| Further distinctions between the digitalSignature and |
| nonRepudiation bits may be provided in specific certificate |
| policies. |
| |
| The keyEncipherment bit is asserted when the subject public key is |
| used for key transport. For example, when an RSA key is to be |
| used for key management, then this bit is set. |
| |
| The dataEncipherment bit is asserted when the subject public key |
| is used for enciphering user data, other than cryptographic keys. |
| |
| 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 a signature on public key certificates. If the |
| keyCertSign bit is asserted, then the cA bit in the basic |
| constraints extension (section 4.2.1.10) MUST also be asserted. |
| |
| The cRLSign bit is asserted when the subject public key is used |
| for verifying a signature on certificate revocation list (e.g., a |
| CRL, delta CRL, or an ARL). This bit MUST be asserted in |
| certificates that are used to verify signatures on CRLs. |
| |
| 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. |
| |
| 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 [PKIXALGS]. |
| |
| 4.2.1.4 Private Key Usage Period |
| |
| This extension SHOULD NOT be used within the Internet PKI. CAs |
| conforming to this profile MUST NOT generate certificates that |
| include a critical private key usage period extension. |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 29] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| The private key usage period extension allows the certificate issuer |
| to specify a different validity period for the private key than the |
| certificate. This extension is intended for use with digital |
| signature keys. This extension consists of two optional components, |
| notBefore and notAfter. The private key associated with the |
| certificate SHOULD NOT be used to sign objects before or after the |
| times specified by the two components, respectively. CAs conforming |
| to this profile MUST NOT generate certificates with private key usage |
| period extensions unless at least one of the two components is |
| present and the extension is non-critical. |
| |
| Where used, notBefore and notAfter are represented as GeneralizedTime |
| and MUST be specified and interpreted as defined in section |
| 4.1.2.5.2. |
| |
| id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } |
| |
| PrivateKeyUsagePeriod ::= SEQUENCE { |
| notBefore [0] GeneralizedTime OPTIONAL, |
| notAfter [1] GeneralizedTime OPTIONAL } |
| |
| 4.2.1.5 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. |
| |
| 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 which include this certificate. When a CA does |
| not wish to limit the set of policies for certification paths which |
| 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 which 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 use of qualifiers |
| |
| |
| |
| Housley, et. al. Standards Track [Page 30] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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. |
| |
| 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. The application software SHOULD display all |
| user notices in all certificates of the certification path used, |
| except that if a notice is 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. |
| |
| 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. |
| |
| 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. |
| |
| |
| |
| Housley, et. al. Standards Track [Page 31] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } |
| |
| anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificate-policies 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)) } |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 32] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 4.2.1.6 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 mapping extension SHOULD |
| also be asserted in a certificate policies extension in the same |
| certificate. Policies SHOULD NOT be mapped either to or from the |
| special value anyPolicy (section 4.2.1.5). |
| |
| This extension MAY be supported by CAs and/or applications, and it |
| MUST be non-critical. |
| |
| id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } |
| |
| PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { |
| issuerDomainPolicy CertPolicyId, |
| subjectDomainPolicy CertPolicyId } |
| |
| 4.2.1.7 Subject Alternative Name |
| |
| The subject alternative names extension allows additional identities |
| to be bound to the subject of the certificate. Defined options |
| include an Internet electronic mail 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 be represented in the subject field using the |
| domainComponent attribute as described in section 4.1.2.4. |
| |
| 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 |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 33] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| subjectAltName extension MUST be present. If the subject field |
| contains an empty sequence, the subjectAltName extension MUST be |
| marked critical. |
| |
| When the subjectAltName extension contains an Internet mail address, |
| the address MUST be included as an rfc822Name. The format of an |
| rfc822Name is an "addr-spec" as defined in RFC 822 [RFC 822]. An |
| addr-spec has the form "local-part@domain". Note that an addr-spec |
| 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 |
| ">". Note that while upper and lower case letters are allowed in an |
| RFC 822 addr-spec, no significance is attached to the case. |
| |
| When the subjectAltName extension contains a iPAddress, the address |
| MUST be stored in the octet string in "network byte order," as |
| specified in RFC 791 [RFC 791]. 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 RFC 791, the octet string |
| MUST contain exactly four octets. For IP Version 6, as specified in |
| RFC 1883, the octet string MUST contain exactly sixteen octets [RFC |
| 1883]. |
| |
| 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 RFC |
| 1034 [RFC 1034]. Note that while upper and lower case letters are |
| allowed in domain names, no signifigance is attached to the case. In |
| 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 (wpolk.nist.gov |
| instead of wpolk@nist.gov) MUST NOT be used; such identities are to |
| be encoded as rfc822Name. |
| |
| Note: work is currently underway to specify domain names in |
| international character sets. Such names will likely not be |
| accommodated by IA5String. Once this work is complete, this profile |
| will be revisited and the appropriate functionality will be added. |
| |
| When the subjectAltName extension contains a URI, the name MUST be |
| stored in the uniformResourceIdentifier (an IA5String). The name |
| MUST NOT be a relative URL, and it MUST follow the URL syntax and |
| encoding rules specified in [RFC 1738]. The name MUST include both a |
| scheme (e.g., "http" or "ftp") and a scheme-specific-part. The |
| scheme-specific-part MUST include a fully qualified domain name or IP |
| address as the host. |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 34] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| As specified in [RFC 1738], the scheme name is not case-sensitive |
| (e.g., "http" is equivalent to "HTTP"). The host part is also not |
| case-sensitive, but other components of the scheme-specific-part may |
| be case-sensitive. When comparing URIs, conforming implementations |
| MUST compare the scheme and host without regard to case, but assume |
| the remainder of the scheme-specific-part is case sensitive. |
| |
| When the subjectAltName extension contains a DN in the directoryName, |
| the DN MUST be unique for each subject entity certified by the one CA |
| as defined by the issuer name 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 [RFC 1510] format names can be encoded into the otherName, |
| using 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.11. |
| |
| 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 |
| that encounter such a certificate when processing a certificication |
| 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 |
| |
| |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 35] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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.8 Issuer Alternative Names |
| |
| As with 4.2.1.7, this extension is used to associate Internet style |
| identities with the certificate issuer. Issuer alternative names |
| MUST be encoded as in 4.2.1.7. |
| |
| Where present, this extension SHOULD NOT be marked critical. |
| |
| id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } |
| |
| IssuerAltName ::= GeneralNames |
| |
| 4.2.1.9 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. This |
| extension MUST be non-critical. |
| |
| id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } |
| |
| SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute |
| |
| 4.2.1.10 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. |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 36] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| The cA boolean indicates whether the certified public key belongs to |
| a CA. If the cA boolean is not asserted, then the keyCertSign bit in |
| the key usage extension MUST NOT be asserted. |
| |
| The pathLenConstraint field is meaningful only if the cA boolean is |
| asserted and the key usage extension 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. A certificate is self- |
| issued if the DNs that appear in the subject and issuer fields are |
| identical and are not empty. (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 only one more certificate |
| 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. |
| |
| This extension MUST appear as a critical extension in all CA |
| certificates that contain public keys used to validate digital |
| signatures on 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 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.11 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 |
| |
| |
| |
| Housley, et. al. Standards Track [Page 37] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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 certificates whose issuer and |
| subject are identical (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. This extension MUST be critical. |
| |
| Within this profile, the minimum and maximum fields are not used with |
| any name forms, thus minimum MUST be zero, and maximum MUST be |
| absent. |
| |
| For URIs, the constraint applies to the host part of the name. The |
| constraint MAY specify a host or a domain. Examples would be |
| "foo.bar.com"; and ".xyz.com". When the the constraint begins with |
| a period, it MAY be expanded with one or more subdomains. That is, |
| the constraint ".xyz.com" is satisfied by both abc.xyz.com and |
| abc.def.xyz.com. However, the constraint ".xyz.com" is not satisfied |
| by "xyz.com". When the constraint does not begin with a period, it |
| specifies a host. |
| |
| 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@xyz.com" |
| indicates the root mailbox on the host "xyz.com". To indicate all |
| Internet mail addresses on a particular host, the constraint is |
| specified as the host name. For example, the constraint "xyz.com" is |
| satisfied by any mail address at the host "xyz.com". To specify any |
| address within a domain, the constraint is specified with a leading |
| period (as with URIs). For example, ".xyz.com" indicates all the |
| Internet mail addresses in the domain "xyz.com", but not Internet |
| mail addresses on the host "xyz.com". |
| |
| DNS name restrictions are expressed as foo.bar.com. Any DNS name |
| that can be constructed by simply adding to the left hand side of the |
| name satisfies the name constraint. For example, www.foo.bar.com |
| would satisfy the constraint but foo1.bar.com would not. |
| |
| Legacy implementations exist where an RFC 822 name is embedded in the |
| subject distinguished name in an attribute of type EmailAddress |
| (section 4.1.2.6). When rfc822 names are constrained, but the |
| |
| |
| |
| Housley, et. al. Standards Track [Page 38] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| certificate does not include a subject alternative name, the rfc822 |
| name 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 and to the subjectAltName extensions of type |
| directoryName. Restrictions of the form x400Address MUST be applied |
| to subjectAltName extensions of type x400Address. |
| |
| 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 4.1.2.4. 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.7 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 1519 (CIDR) to represent an |
| address range [RFC 1519]. For IPv6 addresses, the ipAddress field |
| MUST contain 32 octets similarly encoded. For example, a name |
| constraint for "class C" subnet 10.9.8.0 is represented as the octets |
| 0A 09 08 00 FF FF FF 00, representing the CIDR notation |
| 10.9.8.0/255.255.255.0. |
| |
| The syntax and semantics for name constraints for otherName, |
| ediPartyName, and registeredID are not defined by this specification. |
| |
| 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) |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 39] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 4.2.1.12 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 |
| which has been declared equivalent through policy mapping. |
| |
| Conforming CAs MUST NOT issue certificates where policy constraints |
| is a empty sequence. That is, at least one of the |
| inhibitPolicyMapping field or the requireExplicitPolicy field MUST be |
| present. The behavior of clients that encounter a empty policy |
| constraints field is not addressed in this profile. |
| |
| This extension MAY be critical or non-critical. |
| |
| 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.13 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: |
| |
| |
| |
| Housley, et. al. Standards Track [Page 40] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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 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. If the |
| anyExtendedKeyUsage keyPurposeID is present, the extension SHOULD NOT |
| be critical. |
| |
| 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 |
| |
| |
| |
| Housley, et. al. Standards Track [Page 41] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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 } |
| -- E-mail 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.14 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. |
| |
| 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 the cRLIssuer field MUST be omitted and the distributionPoint |
| field MUST be present. If the distributionPoint field is omitted, |
| cRLIssuer MUST be present and include a Name corresponding to an |
| X.500 or LDAP directory entry where the CRL is located. |
| |
| When the distributionPoint field is present, it contains either a |
| SEQUENCE of general names or a single value, nameRelativeToCRLIssuer. |
| If the cRLDistributionPoints extension 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. The expected values for the URI |
| are those defined in 4.2.1.7. Processing rules for other values are |
| not defined by this specification. |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 42] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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 DistributionPointName contains the single value |
| nameRelativeToCRLIssuer, the value provides a distinguished name |
| 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. The DistributionPointName MUST NOT use the |
| nameRealtiveToCRLIssuer 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. |
| |
| The cRLIssuer identifies the entity who signs and issues the CRL. If |
| present, the cRLIssuer MUST contain at least one an X.500 |
| distinguished name (DN), and MAY also contain other name forms. |
| Since the cRLIssuer is compared to the CRL issuer name, the X.501 |
| type Name MUST follow the encoding rules for the issuer name field in |
| the certificate (section 4.1.2.4). |
| |
| 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 } |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 43] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| ReasonFlags ::= BIT STRING { |
| unused (0), |
| keyCompromise (1), |
| cACompromise (2), |
| affiliationChanged (3), |
| superseded (4), |
| cessationOfOperation (5), |
| certificateHold (6), |
| privilegeWithdrawn (7), |
| aACompromise (8) } |
| |
| 4.2.1.15 Inhibit Any-Policy |
| |
| The inhibit any-policy extension can be used in certificates issued |
| to CAs. The inhibit any-policy indicates that the special anyPolicy |
| OID, with the value { 2 5 29 32 0 }, is not considered an explicit |
| match for other certificate policies. The value indicates the number |
| of additional 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. |
| |
| This extension MUST be critical. |
| |
| id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 } |
| |
| InhibitAnyPolicy ::= SkipCerts |
| |
| SkipCerts ::= INTEGER (0..MAX) |
| |
| 4.2.1.16 Freshest CRL (a.k.a. Delta CRL Distribution Point) |
| |
| The freshest CRL extension identifies how delta CRL information is |
| obtained. The extension MUST be non-critical. 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.14. The same conventions apply to both extensions. |
| |
| id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } |
| |
| FreshestCRL ::= CRLDistributionPoints |
| |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 44] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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 issuing CA or the |
| subject. As the information may be available in multiple forms, each |
| extension is a sequence of IA5String values, each of which represents |
| a URI. The URI implicitly specifies the location and format of the |
| information and the method for obtaining the information. |
| |
| An object identifier is defined for the private extension. The |
| object identifier associated with the private extension is 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 CA |
| 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, and it MUST be 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 } |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 45] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| Each entry in the sequence AuthorityInfoAccessSyntax describes the |
| format and location of additional information provided by the CA that |
| issued the certificate in which this extension appears. The type and |
| format of the information is 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. |
| |
| The id-ad-caIssuers OID is used when the additional information lists |
| CAs that have issued certificates superior 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. |
| Where the information is available via http, ftp, or ldap, |
| accessLocation MUST be a uniformResourceIdentifier. Where the |
| information is available via the Directory Access Protocol (DAP), |
| accessLocation MUST be a directoryName. The entry for that |
| directoryName contains CA certificates in the crossCertificatePair |
| attribute. When the information is available via electronic mail, |
| accessLocation MUST be an rfc822Name. The semantics of other |
| id-ad-caIssuers accessLocation name forms are not defined. |
| |
| 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) [RFC 2560]. |
| |
| When id-ad-ocsp appears as accessMethod, the accessLocation field is |
| the location of the OCSP responder, using the conventions defined in |
| [RFC 2560]. |
| |
| 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 |
| |
| |
| |
| Housley, et. al. Standards Track [Page 46] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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 |
| specifications for the suported services. This extension may be |
| included in subject or CA certificates, and it MUST be 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 is 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, and |
| publishes its certificates and CRLs (if issued) in a repository. The |
| accessLocation field is defined as a GeneralName, which can take |
| several forms. Where the information is available via http, ftp, or |
| ldap, accessLocation MUST be a uniformResourceIdentifier. Where the |
| information is available via the directory access protocol (dap), |
| accessLocation MUST be a directoryName. When the information is |
| available via electronic mail, accessLocation MUST be an rfc822Name. |
| The semantics of other name forms of of accessLocation (when |
| accessMethod is id-ad-caRepository) are not defined by this |
| specification. |
| |
| The id-ad-timeStamping OID is used when the subject offers |
| timestamping services using the Time Stamp Protocol defined in |
| [PKIXTSA]. 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 |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 47] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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. |
| |
| 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. In general, the CRL issuer is the CA. CAs |
| publish CRLs to provide status information about the certificates |
| they issued. However, a CA may delegate this responsibility to |
| another trusted authority. Whenever the CRL issuer is not the CA |
| that issued the certificates, the CRL is referred to as an indirect |
| CRL. |
| |
| 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 could be a set of certificates based on arbitrary local |
| information, such as "all certificates issued to the NIST employees |
| located in Boulder". |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 48] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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. 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 does not define any private Internet CRL extensions or |
| 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. |
| |
| CertificateList ::= SEQUENCE { |
| tbsCertList TBSCertList, |
| signatureAlgorithm AlgorithmIdentifier, |
| signatureValue BIT STRING } |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 49] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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, MUST be v2 |
| } OPTIONAL, |
| crlExtensions [0] EXPLICIT Extensions OPTIONAL |
| -- if present, 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. |
| |
| 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. [PKIXALGS] lists the supported algorithms for this |
| specification, but other signature algorithms MAY also be supported. |
| |
| |
| |
| Housley, et. al. Standards Track [Page 50] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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 [PKIXALGS]. |
| |
| 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. |
| |
| 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, the date and time the CRL |
| was issued, and the date and time by which the CRL issuer will issue |
| the next CRL. |
| |
| Optional fields include 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 |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 51] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| has issued. The profile requires conforming CRL issuers to use 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. [PKIXALGS] lists 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 who has signed and issued the |
| CRL. The issuer identity is carried in the issuer name field. |
| Alternative name forms may also appear in the issuerAltName extension |
| (section 5.2.2). The issuer name field MUST contain an X.500 |
| distinguished name (DN). The issuer name 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 |
| this profile MUST encode thisUpdate as GeneralizedTime for dates in |
| the year 2050 or later. |
| |
| 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. |
| |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 52] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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. |
| |
| This profile requires inclusion of nextUpdate in all CRLs issued by |
| conforming CRL issuers. 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 which 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. |
| |
| 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. |
| |
| 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 |
| |
| |
| |
| Housley, et. al. Standards Track [Page 53] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| critical or non-critical. A CRL validation MUST fail if it |
| encounters a critical extension which it does not know how to |
| process. However, an unrecognized non-critical extension may be |
| ignored. The following subsections present those extensions used |
| within Internet CRLs. Communities may elect to include extensions in |
| CRLs which are not defined in this specification. However, caution |
| should be exercised in adopting any critical extensions in CRLs which |
| 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 on 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 names extension allows additional identities |
| to be associated with the issuer of the CRL. Defined options include |
| an rfc822 name (electronic mail address), a DNS name, an IP address, |
| and a URI. Multiple instances of a name and multiple name forms may |
| 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. |
| |
| The issuerAltName extension SHOULD NOT be marked critical. |
| |
| The OID and syntax for this CRL extension are defined in section |
| 4.2.1.8. |
| |
| |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 54] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 5.2.3 CRL Number |
| |
| The CRL number is a non-critical CRL extension which 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. |
| |
| 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. Conformant CRL issuers MUST NOT use CRLNumber |
| values longer than 20 octets. |
| |
| id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } |
| |
| CRLNumber ::= INTEGER (0..MAX) |
| |
| 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 which store revocation information in a format |
| other than the CRL structure can add new revocation information to |
| the local database without reprocessing information. |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 55] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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 |
| 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. |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 56] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| (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. |
| |
| (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, placed on hold, 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 |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 57] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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 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. |
| |
| 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. |
| |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 58] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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 |
| than 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 the distributionPoint field is present and contains a URI, the |
| following semantics MUST be assumed: the object is a pointer to the |
| most current CRL issued by this CRL issuer. The URI schemes ftp, |
| http, mailto [RFC1738] and ldap [RFC1778] are defined for this |
| purpose. The URI MUST be an absolute pathname, not a relative |
| pathname, and MUST specify the host. |
| |
| 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. |
| |
| The CRL issuer MUST assert the indirectCRL boolean, if the scope of |
| the CRL includes certificates issued by authorities other than the |
| CRL issuer. The authority responsible for each entry is indicated by |
| the certificate issuer CRL entry extension (section 5.3.4). |
| |
| 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 } |
| |
| 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. The extension MUST be non-critical. |
| This extension MUST NOT appear in delta CRLs. |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 59] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| The same syntax is used for this extension as the |
| cRLDistributionPoints certificate extension, and is described in |
| section 4.2.1.14. 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.14 apply to this extension. |
| |
| id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } |
| |
| FreshestCRL ::= CRLDistributionPoints |
| |
| 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. A CRL |
| validation MUST fail if it encounters a critical CRL entry extension |
| which it does not know how to process. However, an unrecognized non- |
| critical CRL entry extension may be ignored. 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 extensions in CRL entries which |
| might be used in a general context. |
| |
| All CRL entry extensions used in this specification are non-critical. |
| Support for these extensions 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.3) 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. |
| |
| |
| |
| Housley, et. al. Standards Track [Page 60] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 } |
| |
| -- reasonCode ::= { CRLReason } |
| |
| CRLReason ::= ENUMERATED { |
| unspecified (0), |
| keyCompromise (1), |
| cACompromise (2), |
| affiliationChanged (3), |
| superseded (4), |
| cessationOfOperation (5), |
| certificateHold (6), |
| removeFromCRL (8), |
| privilegeWithdrawn (9), |
| aACompromise (10) } |
| |
| 5.3.2 Hold Instruction Code |
| |
| The hold instruction code is a non-critical CRL entry extension that |
| provides a registered instruction identifier which indicates the |
| action to be taken after encountering a certificate that has been |
| placed on hold. |
| |
| id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } |
| |
| holdInstructionCode ::= OBJECT IDENTIFIER |
| |
| The following instruction codes have been defined. Conforming |
| applications that process this extension MUST recognize the following |
| instruction codes. |
| |
| holdInstruction OBJECT IDENTIFIER ::= |
| { iso(1) member-body(2) us(840) x9-57(10040) 2 } |
| |
| id-holdinstruction-none OBJECT IDENTIFIER ::= {holdInstruction 1} |
| id-holdinstruction-callissuer |
| OBJECT IDENTIFIER ::= {holdInstruction 2} |
| id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3} |
| |
| Conforming applications which encounter an id-holdinstruction- |
| callissuer MUST call the certificate issuer or reject the |
| certificate. Conforming applications which encounter an id- |
| holdinstruction-reject MUST reject the certificate. The hold |
| instruction id-holdinstruction-none is semantically equivalent to the |
| absence of a holdInstructionCode, and its use is strongly deprecated |
| for the Internet PKI. |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 61] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 5.3.3 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.4 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. If this extension is not present on the first entry in an |
| indirect CRL, the certificate issuer defaults to the CRL issuer. On |
| 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 |
| |
| If used by conforming CRL issuers, this extension MUST always be |
| critical. If an implementation ignored this extension it 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 which are specified in the |
| |
| |
| |
| Housley, et. al. Standards Track [Page 62] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| certificates which comprise the path and inputs which 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 which 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 |
| validation procedure is the same regardless of the choice of trust |
| anchor. In addition, different applications may rely on different |
| trust anchor, or may accept paths that begin with any of a set of |
| trust anchor. |
| |
| Section 6.2 describes methods for using the path validation algorithm |
| in specific implementations. Two specific cases are discussed: the |
| case where paths may begin with one of several trusted CAs; and where |
| compatibility with the PEM architecture is required. |
| |
| Section 6.3 describes the steps necessary to determine if a |
| certificate is revoked or on hold status 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 |
| conformant 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. |
| |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 63] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| For example, clients are NOT REQUIRED to support the policy mapping |
| 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. |
| |
| The algorithm presented in this section validates the certificate |
| with respect to the current date and time. A conformant |
| 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. |
| |
| 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 end entity certificate, |
| based on the public key of the trust anchor. This 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; and |
| |
| (d) for all x in {1, ..., n}, the certificate was valid at the |
| time in question. |
| |
| 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 |
| are provided as inputs to the certification path validation algorithm |
| (section 6.1.1). |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 64] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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 mapping extension, policy constraints extension, |
| and inhibit any-policy extension. To achieve this, the path |
| 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 DNs that appear in the subject |
| and issuer fields are identical and are not empty. 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. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 65] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| +-------+ |
| | 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 the following seven inputs are provided to the |
| path processing logic: |
| |
| (a) a prospective certification path of length n. |
| |
| (b) the current date/time. |
| |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 66] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| (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. |
| The trusted 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. |
| |
| 6.1.2 Initialization |
| |
| This initialization phase establishes eleven state variables based |
| upon the seven 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 |
| |
| |
| |
| Housley, et. al. Standards Track [Page 67] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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 four data objects: the |
| valid policy, a set of associated policy qualifiers, a set of one |
| or more expected policy values, and a criticality indicator. 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. |
| |
| (2) The qualifier_set is a set of policy qualifiers associated |
| with the valid policy in certificate x. |
| |
| (3) The criticality_indicator indicates whether the |
| certificate policy extension in certificate x was marked as |
| critical. |
| |
| (4) 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, an |
| expected_policy_set with the single value anyPolicy, and a |
| criticality_indicator of FALSE. 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 |
| +----------------+ |
| | FALSE | <---- criticality_indicator |
| +----------------+ |
| | {anyPolicy} | <---- expected_policy_set |
| +----------------+ |
| |
| Figure 3. Initial value of the valid_policy_tree state variable |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 68] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| (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: the |
| initial value for the set for Distinguished Names is the set of |
| all Distinguished names; the initial value for the set of RFC822 |
| names is the set of all RFC822 names, etc. |
| |
| (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 for each set is empty. |
| |
| (d) explicit_policy: an integer which 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 can not |
| remove this requirement. If initial-explicit-policy is set, then |
| the initial value is 0, otherwise the initial value is n+1. |
| |
| (e) inhibit_any-policy: an integer which 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, |
| 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 can not 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 which 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 policy |
| mapping is not permitted, it can not 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. |
| |
| |
| |
| Housley, et. al. Standards Track [Page 69] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| (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 provided in the trust anchor |
| information. |
| |
| (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 certificate was signed with the |
| working_public_key_algorithm using 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 and is |
| not on hold status. This may be determined by obtaining the |
| appropriate CRL (section 6.3), status information, or by out- |
| of-band mechanisms. |
| |
| (4) The certificate issuer name is the working_issuer_name. |
| |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 70] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| (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 one 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 one of the |
| excluded_subtrees for that name type. |
| |
| (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 in |
| policy P and P-Q denote the qualifier set for policy P. |
| Perform the following steps in order: |
| |
| (i) If the valid_policy_tree includes a node of depth i-1 |
| where P-OID is in the expected_policy_set, create a child |
| node as follows: set the valid_policy to OID-P; 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. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 71] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| +-----------------+ |
| | Red | |
| +-----------------+ |
| | {} | |
| +-----------------+ node of depth i-1 |
| | FALSE | |
| +-----------------+ |
| | {Gold, White} | |
| +-----------------+ |
| | |
| | |
| | |
| V |
| +-----------------+ |
| | Gold | |
| +-----------------+ |
| | {} | |
| +-----------------+ node of depth i |
| | uninitialized | |
| +-----------------+ |
| | {Gold} | |
| +-----------------+ |
| |
| Figure 4. Processing an exact match |
| |
| (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. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 72] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| +-----------------+ |
| | anyPolicy | |
| +-----------------+ |
| | {} | |
| +-----------------+ node of depth i-1 |
| | FALSE | |
| +-----------------+ |
| | {anyPolicy} | |
| +-----------------+ |
| / \ |
| / \ |
| / \ |
| / \ |
| +-----------------+ +-----------------+ |
| | Gold | | Silver | |
| +-----------------+ +-----------------+ |
| | {} | | {Q-Silver} | |
| +-----------------+ nodes of +-----------------+ |
| | uninitialized | depth i | uninitialized | |
| +-----------------+ +-----------------+ |
| | {Gold} | | {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_any-policy 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 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, but Gold and Silver do not. This rule will |
| generate two child nodes of depth i, one for each policy. The |
| result is shown below as Figure 6. |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 73] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| +-----------------+ |
| | Red | |
| +-----------------+ |
| | {} | |
| +-----------------+ node of depth i-1 |
| | FALSE | |
| +-----------------+ |
| | {Gold, Silver} | |
| +-----------------+ |
| / \ |
| / \ |
| / \ |
| / \ |
| +-----------------+ +-----------------+ |
| | Gold | | Silver | |
| +-----------------+ +-----------------+ |
| | {} | | {} | |
| +-----------------+ nodes of +-----------------+ |
| | uninitialized | depth i | uninitialized | |
| +-----------------+ +-----------------+ |
| | {Gold} | | {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 are deleted. Applying this rule to the |
| resulting tree will cause the node at depth i-2 that is marked |
| with an 'Y' to be deleted. The following application of the |
| rule does not cause any nodes to be deleted, and this step is |
| complete. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 74] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| +-----------+ |
| | | 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 |
| |
| (4) If the certificate policies extension was marked as |
| critical, set the criticality_indicator in all nodes of depth i |
| to TRUE. If the certificate policies extension was not marked |
| critical, set the criticality_indicator in all nodes of depth i |
| to FALSE. |
| |
| (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 6.1.4. If i is equal to n, perform the wrap-up steps |
| listed in 6.1.5. |
| |
| 6.1.4 Preparation for Certificate i+1 |
| |
| To prepare for processing of certificate i+1, perform the following |
| steps for certificate i: |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 75] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| (a) If a policy mapping extension is present, verify that the |
| special value anyPolicy does not appear as an issuerDomainPolicy |
| or a subjectDomainPolicy. |
| |
| (b) If a policy mapping extension is present, then for each |
| issuerDomainPolicy ID-P in the policy mapping extension: |
| |
| (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 mapping 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; |
| |
| (iii) set the criticality_indicator to the criticality of |
| the certificate policies extension of certificate i; |
| |
| (iv) and 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. |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 76] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| (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. |
| |
| (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 nist.gov and |
| csrc.nist.gov is csrc.nist.gov. And, the intersection of |
| nist.gov and rsasecurity.com 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 nist.gov and |
| csrc.nist.gov is nist.gov. And, the union of nist.gov and |
| rsasecurity.com is both name spaces. |
| |
| (h) If the issuer and subject names are not identical: |
| |
| (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_any-policy is not 0, decrement inhibit_any- |
| policy by 1. |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 77] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| (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. |
| |
| (j) If the inhibitAnyPolicy extension is included in the |
| certificate and is less than inhibit_any-policy, set inhibit_any- |
| policy to the value of inhibitAnyPolicy. |
| |
| (k) Verify that the certificate is a CA certificate (as specified |
| in a basicConstraints extension or as verified out-of-band). |
| |
| (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 pathLengthConstraint is present in the certificate and is |
| less than max_path_length, set max_path_length to the value of |
| pathLengthConstraint. |
| |
| (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. |
| |
| 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 6.1.3. |
| |
| 6.1.5 Wrap-up procedure |
| |
| To complete the processing of the end entity certificate, perform the |
| following steps for certificate n: |
| |
| (a) If certificate n was not self-issued and explicit_policy is |
| not 0, decrement explicit_policy by 1. |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 78] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| (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. |
| |
| (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. |
| |
| (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. |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 79] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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; copy |
| the criticality_indicator from the node of depth n with |
| the valid_policy anyPolicy; 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. An implementation that supports multiple trust anchors |
| MAY augment the algorithm presented in section 6.1 to further limit |
| the set of valid certification paths which begin with a particular |
| trust anchor. For example, an implementation MAY modify the |
| algorithm to apply name constraints to a specific trust anchor during |
| the initialization phase, or the application MAY require the presence |
| |
| |
| |
| Housley, et. al. Standards Track [Page 80] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| of a particular alternative name form in the end entity 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. |
| |
| 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 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. |
| |
| It is also possible to specify an extended version of the above |
| certification path processing procedure which results in default |
| behavior identical to the rules of PEM [RFC 1422]. In this extended |
| version, additional inputs to the procedure are a list of one or more |
| Policy Certification Authority (PCA) names and an indicator of the |
| position in the certification path where the PCA is expected. At the |
| nominated PCA position, the CA name is compared against this list. |
| If a recognized PCA name is found, then a constraint of |
| SubordinateToCA is implicitly assumed for the remainder of the |
| certification path and processing continues. If no valid PCA name is |
| found, and if the certification path cannot be validated on the basis |
| of identified policies, then the certification path is considered |
| invalid. |
| |
| 6.3 CRL Validation |
| |
| This section describes the steps necessary to determine if a |
| certificate is revoked or on hold status 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. 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. |
| |
| 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. |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 81] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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 |
| cRLDistributionsPoint and freshestCRL extensions to determine |
| revocation status. |
| |
| (b) use-deltas: This boolean input determines whether delta CRLs |
| are applied to CRLs. |
| |
| Note that implementations supporting legacy PKIs, such as RFC 1422 |
| and X.509 version 1, will need an additional input indicating |
| whether the supplied certificate is associated with a CA or an end |
| entity. |
| |
| 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: 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. |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 82] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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 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 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 the 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, 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 and use-deltas is set, then obtain the current delta CRL |
| that can be used to update the locally cached complete CRL as |
| specified in section 5.2.4. |
| |
| (b) Verify the issuer and scope of the complete CRL as follows: |
| |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 83] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| (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 indrectCRL 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 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. |
| |
| (3) Verify that the delta CRL authority key identifier |
| extension matches complete CRL authority key identifier |
| extension. |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 84] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| (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 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 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 is not included in the reasons_mask. |
| |
| (f) Obtain and validate the certification path for the complete CRL |
| issuer. 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.4, then set the |
| cert_status variable to the indicated reason as follows: |
| |
| (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. |
| |
| |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 85] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| (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.4, 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. |
| |
| 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. If the revocation status remains undetermined, then |
| return the cert_status UNDETERMINED. |
| |
| 7 References |
| |
| [ISO 10646] ISO/IEC 10646-1:1993. International Standard -- |
| Information technology -- Universal Multiple-Octet Coded |
| Character Set (UCS) -- Part 1: Architecture and Basic |
| Multilingual Plane. |
| |
| [RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791, |
| September 1981. |
| |
| [RFC 822] Crocker, D., "Standard for the format of ARPA Internet |
| text messages", STD 11, RFC 822, August 1982. |
| |
| [RFC 1034] Mockapetris, P., "Domain Names - Concepts and |
| Facilities", STD 13, RFC 1034, November 1987. |
| |
| [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic |
| Mail: Part II: Certificate-Based Key Management," RFC |
| 1422, February 1993. |
| |
| [RFC 1423] Balenson, D., "Privacy Enhancement for Internet |
| Electronic Mail: Part III: Algorithms, Modes, and |
| Identifiers," RFC 1423, February 1993. |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 86] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| [RFC 1510] Kohl, J. and C. Neuman, "The Kerberos Network |
| Authentication Service (V5)," RFC 1510, September 1993. |
| |
| [RFC 1519] Fuller, V., T. Li, J. Yu and K. Varadhan, "Classless |
| Inter-Domain Routing (CIDR): An Address Assignment and |
| Aggregation Strategy", RFC 1519, September 1993. |
| |
| [RFC 1738] Berners-Lee, T., L. Masinter and M. McCahill, "Uniform |
| Resource Locators (URL)", RFC 1738, December 1994. |
| |
| [RFC 1778] Howes, T., S. Kille, W. Yeong and C. Robbins, "The String |
| Representation of Standard Attribute Syntaxes," RFC 1778, |
| March 1995. |
| |
| [RFC 1883] Deering, S. and R. Hinden. "Internet Protocol, Version 6 |
| (IPv6) Specification", RFC 1883, December 1995. |
| |
| [RFC 2044] F. Yergeau, F., "UTF-8, a transformation format of |
| Unicode and ISO 10646", RFC 2044, October 1996. |
| |
| [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate |
| Requirement Levels", BCP 14, RFC 2119, March 1997. |
| |
| [RFC 2247] Kille, S., M. Wahl, A. Grimstad, R. Huber and S. |
| Sataluri, "Using Domains in LDAP/X.500 Distinguished |
| Names", RFC 2247, January 1998. |
| |
| [RFC 2252] Wahl, M., A. Coulbeck, T. Howes and S. Kille, |
| "Lightweight Directory Access Protocol (v3): Attribute |
| Syntax Definitions", RFC 2252, December 1997. |
| |
| [RFC 2277] Alvestrand, H., "IETF Policy on Character Sets and |
| Languages", BCP 18, RFC 2277, January 1998. |
| |
| [RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO |
| 10646", RFC 2279, January 1998. |
| |
| [RFC 2459] Housley, R., W. Ford, W. Polk and D. Solo, "Internet |
| X.509 Public Key Infrastructure: Certificate and CRL |
| Profile", RFC 2459, January 1999. |
| |
| [RFC 2560] Myers, M., R. Ankney, A. Malpani, S. Galperin and C. |
| Adams, "Online Certificate Status Protocal - OCSP", June |
| 1999. |
| |
| [SDN.701] SDN.701, "Message Security Protocol 4.0", Revision A, |
| 1997-02-06. |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 87] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| [X.501] ITU-T Recommendation X.501: Information Technology - Open |
| Systems Interconnection - The Directory: Models, 1993. |
| |
| [X.509] ITU-T Recommendation X.509 (1997 E): Information |
| Technology - Open Systems Interconnection - The |
| Directory: Authentication Framework, June 1997. |
| |
| [X.520] ITU-T Recommendation X.520: Information Technology - Open |
| Systems Interconnection - The Directory: Selected |
| Attribute Types, 1993. |
| |
| [X.660] ITU-T Recommendation X.660 Information Technology - ASN.1 |
| encoding rules: Specification of Basic Encoding Rules |
| (BER), Canonical Encoding Rules (CER) and Distinguished |
| Encoding Rules (DER), 1997. |
| |
| [X.690] ITU-T Recommendation X.690 Information Technology - Open |
| Systems Interconnection - Procedures for the operation of |
| OSI Registration Authorities: General procedures, 1992. |
| |
| [X9.55] ANSI X9.55-1995, Public Key Cryptography For The |
| Financial Services Industry: Extensions To Public Key |
| Certificates And Certificate Revocation Lists, 8 |
| December, 1995. |
| |
| [PKIXALGS] Bassham, L., Polk, W. and R. Housley, "Algorithms and |
| Identifiers for the Internet X.509 Public Key |
| Infrastructure Certificate and Certificate Revocation |
| Lists (CRL) Profile", RFC 3279, April 2002. |
| |
| [PKIXTSA] Adams, C., Cain, P., Pinkas, D. and R. Zuccherato, |
| "Internet X.509 Public Key Infrastructure Time-Stamp |
| Protocol (TSP)", RFC 3161, August 2001. |
| |
| 8 Intellectual Property Rights |
| |
| The IETF has been notified of intellectual property rights claimed in |
| regard to some or all of the specification contained in this |
| document. For more information consult the online list of claimed |
| rights (see http://www.ietf.org/ipr.html). |
| |
| The IETF takes no position regarding the validity or scope of any |
| intellectual property 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; neither does it represent that it |
| has made any effort to identify any such rights. Information on the |
| IETF's procedures with respect to rights in standards-track and |
| |
| |
| |
| Housley, et. al. Standards Track [Page 88] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| standards-related documentation can be found in BCP 11. Copies of |
| claims of rights made available for publication 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 implementors or users of this specification can |
| be obtained from the IETF Secretariat. |
| |
| 9 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 |
| parties might wish to review the CA's certificate 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., 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 |
| |
| |
| |
| Housley, et. al. Standards Track [Page 89] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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 which 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 |
| 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 |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 90] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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 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. |
| |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 91] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| Appendix A. Psuedo-ASN.1 Structures and OIDs |
| |
| This section 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/ITU 10646-1 |
| |
| UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING |
| -- The content of this type conforms to RFC 2279. |
| |
| -- PKIX specific OIDs |
| |
| id-pkix OBJECT IDENTIFIER ::= |
| { iso(1) identified-organization(3) dod(6) internet(1) |
| security(5) mechanisms(5) pkix(7) } |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 92] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| -- 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 |
| |
| 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 |
| --Arc for standard naming attributes |
| id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 } |
| |
| |
| |
| Housley, et. al. Standards Track [Page 93] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| -- 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 } |
| |
| 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 } |
| |
| 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)) } |
| |
| -- Naming attributes of type X520LocalityName |
| |
| id-at-localityName AttributeType ::= { id-at 7 } |
| |
| 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 } |
| |
| 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)) } |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 94] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| -- Naming attributes of type X520OrganizationName |
| |
| id-at-organizationName AttributeType ::= { id-at 10 } |
| |
| 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 } |
| |
| 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)) } |
| |
| -- Naming attributes of type X520Title |
| |
| id-at-title AttributeType ::= { id-at 12 } |
| |
| 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 |
| |
| |
| |
| Housley, et. al. Standards Track [Page 95] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| -- 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 } |
| |
| 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)) } |
| |
| -- Naming attributes of type DomainComponent (from RFC 2247) |
| |
| 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 |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 96] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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 } |
| |
| 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 |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 97] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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 } |
| |
| -- 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, MUST be v2 |
| } OPTIONAL, |
| crlExtensions [0] Extensions OPTIONAL } |
| -- if present, 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 |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 98] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| ORAddress ::= SEQUENCE { |
| built-in-standard-attributes BuiltInStandardAttributes, |
| built-in-domain-defined-attributes |
| BuiltInDomainDefinedAttributes OPTIONAL, |
| -- see also teletex-domain-defined-attributes |
| extension-attributes ExtensionAttributes OPTIONAL } |
| |
| -- 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)) } |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 99] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| OrganizationName ::= PrintableString |
| (SIZE (1..ub-organization-name-length)) |
| -- see also teletex-organization-name |
| |
| NumericUserIdentifier ::= NumericString |
| (SIZE (1..ub-numeric-user-id-length)) |
| |
| 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 } |
| |
| |
| |
| Housley, et. al. Standards Track [Page 100] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| -- Extension types and attribute values |
| |
| common-name INTEGER ::= 1 |
| |
| CommonName ::= PrintableString (SIZE (1..ub-common-name-length)) |
| |
| 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)) } |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 101] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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 |
| |
| 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 |
| |
| |
| |
| Housley, et. al. Standards Track [Page 102] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| PosteRestanteAddress ::= PDSParameter |
| |
| unique-postal-name INTEGER ::= 20 |
| |
| UniquePostalName ::= PDSParameter |
| |
| local-postal-attributes INTEGER ::= 21 |
| |
| 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 |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 103] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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)) } |
| |
| -- 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 ::= 128 |
| 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 |
| |
| |
| |
| Housley, et. al. Standards Track [Page 104] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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 |
| -- 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 } |
| |
| |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 105] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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 |
| |
| -- 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), |
| 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 { |
| |
| |
| |
| Housley, et. al. Standards Track [Page 106] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| policyIdentifier CertPolicyId, |
| policyQualifiers SEQUENCE SIZE (1..MAX) OF |
| PolicyQualifierInfo OPTIONAL } |
| |
| CertPolicyId ::= OBJECT IDENTIFIER |
| |
| 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 } |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 107] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| SubjectAltName ::= GeneralNames |
| |
| GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName |
| |
| 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 } |
| |
| -- name constraints extension OID and syntax |
| |
| id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 108] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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 } |
| |
| ReasonFlags ::= BIT STRING { |
| unused (0), |
| keyCompromise (1), |
| cACompromise (2), |
| affiliationChanged (3), |
| superseded (4), |
| cessationOfOperation (5), |
| certificateHold (6), |
| privilegeWithdrawn (7), |
| aACompromise (8) } |
| |
| |
| |
| Housley, et. al. Standards Track [Page 109] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| -- 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 |
| |
| -- 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 } |
| |
| |
| |
| Housley, et. al. Standards Track [Page 110] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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 } |
| |
| id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } |
| |
| BaseCRLNumber ::= CRLNumber |
| |
| -- CRL reasons 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 |
| |
| |
| |
| Housley, et. al. Standards Track [Page 111] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } |
| |
| HoldInstructionCode ::= OBJECT IDENTIFIER |
| |
| -- ANSI x9 holdinstructions |
| |
| -- ANSI x9 arc holdinstruction arc |
| |
| holdInstruction OBJECT IDENTIFIER ::= |
| {joint-iso-itu-t(2) member-body(2) us(840) x9cm(10040) 2} |
| |
| -- ANSI X9 holdinstructions referenced by this standard |
| |
| id-holdinstruction-none OBJECT IDENTIFIER ::= |
| {holdInstruction 1} -- deprecated |
| |
| id-holdinstruction-callissuer OBJECT IDENTIFIER ::= |
| {holdInstruction 2} |
| |
| id-holdinstruction-reject OBJECT IDENTIFIER ::= |
| {holdInstruction 3} |
| |
| -- 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. Conformant 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. Conformant CRL issuers MUST NOT |
| use cRLNumber values longer than 20 octets. |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 112] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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 the upper bound is unspecified. |
| Implementations are free to choose an upper bound that suits their |
| environment. |
| |
| The construct "positiveInt ::= INTEGER (0..MAX)" defines positiveInt |
| as a subtype of INTEGER containing integers greater than or equal to |
| zero. The upper bound is unspecified. Implementations are free to |
| select an upper bound that suits their environment. |
| |
| The character string type PrintableString supports a very basic Latin |
| character set: the lower case letters 'a' through 'z', upper case |
| 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 which include |
| either the at sign or underscore character as PrintableString. |
| |
| 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 zeroes 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 ISO 10646-1 [ISO 10646]. ISO 10646-1 is the |
| Universal multiple-octet coded Character Set (UCS). ISO 10646-1 |
| specifies the architecture and the "basic multilingual plane" -- a |
| large standard character set which includes all major world character |
| standards. |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 113] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 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 [X.520]. UTF8String is |
| a universal type and has been assigned tag number 12. The content of |
| UTF8String was defined by RFC 2044 [RFC 2044] and updated in RFC 2279 |
| [RFC 2279]. |
| |
| In anticipation of these changes, and in conformance with IETF Best |
| Practices codified in RFC 2277 [RFC 2277], IETF Policy on Character |
| Sets and Languages, this document includes UTF8String as a choice in |
| DirectoryString and the CPS qualifier extensions. |
| |
| 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 which 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 [RFC 2252], |
| section 4.1) 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 which |
| contain OIDs that exceed these requirements. Likewise, CRL issuers |
| SHOULD NOT issue CRLs which contain OIDs that exceed these |
| requirements. |
| |
| 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 RFC 2459 [RFC 2459], 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 critical, those |
| unknown elements ought to be ignored, as follows: |
| |
| (a) ignore all unknown bit name assignments within a bit string; |
| |
| |
| |
| Housley, et. al. Standards Track [Page 114] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| (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 critical, the |
| implementation MUST reject the certificate or CRL containing the |
| unrecognized extension. |
| |
| Appendix C. Examples |
| |
| This section contains four examples: three certificates and a CRL. |
| The first two certificates and the CRL comprise a minimal |
| certification path. |
| |
| Section C.1 contains an annotated hex dump of a "self-signed" |
| certificate issued by a CA whose distinguished name is |
| cn=us,o=gov,ou=nist. The certificate contains a DSA public key with |
| parameters, and is signed by the corresponding DSA private key. |
| |
| Section C.2 contains an annotated hex dump of an end entity |
| certificate. The end entity certificate contains a DSA public key, |
| and is signed by the private key corresponding to the "self-signed" |
| certificate in section C.1. |
| |
| Section C.3 contains a dump of an end entity certificate which |
| contains an RSA public key and is signed with RSA and MD5. This |
| certificate is not part of the minimal certification path. |
| |
| Section C.4 contains an annotated hex dump of a CRL. The CRL is |
| issued by the CA whose distinguished name is cn=us,o=gov,ou=nist and |
| the list of revoked certificates includes the end entity certificate |
| presented in C.2. |
| |
| The certificates were processed using Peter Gutman'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/pki/pkixtools>. |
| |
| C.1 Certificate |
| |
| This section contains an annotated hex dump of a 699 byte version 3 |
| certificate. The certificate contains the following information: |
| (a) the serial number is 23 (17 hex); |
| |
| |
| |
| Housley, et. al. Standards Track [Page 115] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| (b) the certificate is signed with DSA and the SHA-1 hash algorithm; |
| (c) the issuer's distinguished name is OU=NIST; O=gov; C=US |
| (d) and the subject's distinguished name is OU=NIST; O=gov; C=US |
| (e) the certificate was issued on June 30, 1997 and will expire on |
| December 31, 1997; |
| (f) the certificate contains a 1024 bit DSA public key with |
| parameters; |
| (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 30 699: SEQUENCE { |
| 4 30 635: SEQUENCE { |
| 8 A0 3: [0] { |
| 10 02 1: INTEGER 2 |
| : } |
| 13 02 1: INTEGER 17 |
| 16 30 9: SEQUENCE { |
| 18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) |
| : } |
| 27 30 42: SEQUENCE { |
| 29 31 11: SET { |
| 31 30 9: SEQUENCE { |
| 33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) |
| 38 13 2: PrintableString 'US' |
| : } |
| : } |
| 42 31 12: SET { |
| 44 30 10: SEQUENCE { |
| 46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) |
| 51 13 3: PrintableString 'gov' |
| : } |
| : } |
| 56 31 13: SET { |
| 58 30 11: SEQUENCE { |
| 60 06 3: OBJECT IDENTIFIER |
| : organizationalUnitName (2 5 4 11) |
| 65 13 4: PrintableString 'NIST' |
| : } |
| : } |
| : } |
| 71 30 30: SEQUENCE { |
| 73 17 13: UTCTime '970630000000Z' |
| 88 17 13: UTCTime '971231000000Z' |
| : } |
| 103 30 42: SEQUENCE { |
| 105 31 11: SET { |
| |
| |
| |
| Housley, et. al. Standards Track [Page 116] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 107 30 9: SEQUENCE { |
| 109 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) |
| 114 13 2: PrintableString 'US' |
| : } |
| : } |
| 118 31 12: SET { |
| 120 30 10: SEQUENCE { |
| 122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) |
| 127 13 3: PrintableString 'gov' |
| : } |
| : } |
| 132 31 13: SET { |
| 134 30 11: SEQUENCE { |
| 136 06 3: OBJECT IDENTIFIER |
| : organizationalUnitName (2 5 4 11) |
| 141 13 4: PrintableString 'NIST' |
| : } |
| : } |
| : } |
| 147 30 440: SEQUENCE { |
| 151 30 300: SEQUENCE { |
| 155 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) |
| 164 30 287: SEQUENCE { |
| 168 02 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 |
| 300 02 21: INTEGER |
| : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA |
| : 55 F7 7D 57 74 81 E5 |
| 323 02 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 |
| |
| |
| |
| Housley, et. al. Standards Track [Page 117] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| : } |
| : } |
| 455 03 133: BIT STRING 0 unused bits, encapsulates { |
| 459 02 129: INTEGER |
| : 00 B5 9E 1F 49 04 47 D1 DB F5 3A DD CA 04 |
| : 75 E8 DD 75 F6 9B 8A B1 97 D6 59 69 82 D3 |
| : 03 4D FD 3B 36 5F 4A F2 D1 4E C1 07 F5 D1 |
| : 2A D3 78 77 63 56 EA 96 61 4D 42 0B 7A 1D |
| : FB AB 91 A4 CE DE EF 77 C8 E5 EF 20 AE A6 |
| : 28 48 AF BE 69 C3 6A A5 30 F2 C2 B9 D9 82 |
| : 2B 7D D9 C4 84 1F DE 0D E8 54 D7 1B 99 2E |
| : B3 D0 88 F6 D6 63 9B A7 E2 0E 82 D4 3B 8A |
| : 68 1B 06 56 31 59 0B 49 EB 99 A5 D5 81 41 |
| : 7B C9 55 |
| : } |
| : } |
| 591 A3 50: [3] { |
| 593 30 48: SEQUENCE { |
| 595 30 29: SEQUENCE { |
| 597 06 3: OBJECT IDENTIFIER |
| : subjectKeyIdentifier (2 5 29 14) |
| 602 04 22: OCTET STRING, encapsulates { |
| 604 04 20: OCTET STRING |
| : 86 CA A5 22 81 62 EF AD 0A 89 BC AD 72 41 |
| : 2C 29 49 F4 86 56 |
| : } |
| : } |
| 626 30 15: SEQUENCE { |
| 628 06 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19) |
| 633 01 1: BOOLEAN TRUE |
| 636 04 5: OCTET STRING, encapsulates { |
| 638 30 3: SEQUENCE { |
| 640 01 1: BOOLEAN TRUE |
| : } |
| : } |
| : } |
| : } |
| : } |
| : } |
| 643 30 9: SEQUENCE { |
| 645 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) |
| : } |
| 654 03 47: BIT STRING 0 unused bits, encapsulates { |
| 657 30 44: SEQUENCE { |
| 659 02 20: INTEGER |
| : 43 1B CF 29 25 45 C0 4E 52 E7 7D D6 FC B1 |
| : 66 4C 83 CF 2D 77 |
| 681 02 20: INTEGER |
| |
| |
| |
| Housley, et. al. Standards Track [Page 118] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| : 0B 5B 9A 24 11 98 E8 F3 86 90 04 F6 08 A9 |
| : E1 8D A5 CC 3A D4 |
| : } |
| : } |
| : } |
| |
| C.2 Certificate |
| |
| This section contains an annotated hex dump of a 730 byte version 3 |
| certificate. The certificate contains the following information: |
| (a) the serial number is 18 (12 hex); |
| (b) the certificate is signed with DSA and the SHA-1 hash algorithm; |
| (c) the issuer's distinguished name is OU=nist; O=gov; C=US |
| (d) and the subject's distinguished name is CN=Tim Polk; OU=nist; |
| O=gov; C=US |
| (e) the certificate was valid from July 30, 1997 through December 1, |
| 1997; |
| (f) the certificate contains a 1024 bit DSA 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 RFC 822 |
| address of "wpolk@nist.gov". |
| |
| 0 30 730: SEQUENCE { |
| 4 30 665: SEQUENCE { |
| 8 A0 3: [0] { |
| 10 02 1: INTEGER 2 |
| : } |
| 13 02 1: INTEGER 18 |
| 16 30 9: SEQUENCE { |
| 18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) |
| : } |
| 27 30 42: SEQUENCE { |
| 29 31 11: SET { |
| 31 30 9: SEQUENCE { |
| 33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) |
| 38 13 2: PrintableString 'US' |
| : } |
| : } |
| 42 31 12: SET { |
| 44 30 10: SEQUENCE { |
| 46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) |
| 51 13 3: PrintableString 'gov' |
| : } |
| : } |
| |
| |
| |
| Housley, et. al. Standards Track [Page 119] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 56 31 13: SET { |
| 58 30 11: SEQUENCE { |
| 60 06 3: OBJECT IDENTIFIER |
| : organizationalUnitName (2 5 4 11) |
| 65 13 4: PrintableString 'NIST' |
| : } |
| : } |
| : } |
| 71 30 30: SEQUENCE { |
| 73 17 13: UTCTime '970730000000Z' |
| 88 17 13: UTCTime '971201000000Z' |
| : } |
| 103 30 61: SEQUENCE { |
| 105 31 11: SET { |
| 107 30 9: SEQUENCE { |
| 109 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) |
| 114 13 2: PrintableString 'US' |
| : } |
| : } |
| 118 31 12: SET { |
| 120 30 10: SEQUENCE { |
| 122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) |
| 127 13 3: PrintableString 'gov' |
| : } |
| : } |
| 132 31 13: SET { |
| 134 30 11: SEQUENCE { |
| 136 06 3: OBJECT IDENTIFIER |
| : organizationalUnitName (2 5 4 11) |
| 141 13 4: PrintableString 'NIST' |
| : } |
| : } |
| 147 31 17: SET { |
| 149 30 15: SEQUENCE { |
| 151 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) |
| 156 13 8: PrintableString 'Tim Polk' |
| : } |
| : } |
| : } |
| 166 30 439: SEQUENCE { |
| 170 30 300: SEQUENCE { |
| 174 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) |
| 183 30 287: SEQUENCE { |
| 187 02 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 |
| |
| |
| |
| Housley, et. al. Standards Track [Page 120] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| : 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 |
| 319 02 21: INTEGER |
| : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA |
| : 55 F7 7D 57 74 81 E5 |
| 342 02 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 |
| : } |
| : } |
| 474 03 132: BIT STRING 0 unused bits, encapsulates { |
| 478 02 128: INTEGER |
| : 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 |
| : } |
| : } |
| 609 A3 62: [3] { |
| 611 30 60: SEQUENCE { |
| 613 30 25: SEQUENCE { |
| 615 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) |
| 620 04 18: OCTET STRING, encapsulates { |
| 622 30 16: SEQUENCE { |
| 624 81 14: [1] 'wpolk@nist.gov' |
| : } |
| : } |
| : } |
| 640 30 31: SEQUENCE { |
| 642 06 3: OBJECT IDENTIFIER |
| |
| |
| |
| Housley, et. al. Standards Track [Page 121] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| : authorityKeyIdentifier (2 5 29 35) |
| 647 04 24: OCTET STRING, encapsulates { |
| 649 30 22: SEQUENCE { |
| 651 80 20: [0] |
| : 86 CA A5 22 81 62 EF AD 0A 89 BC AD 72 |
| : 41 2C 29 49 F4 86 56 |
| : } |
| : } |
| : } |
| : } |
| : } |
| : } |
| 673 30 9: SEQUENCE { |
| 675 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) |
| : } |
| 684 03 48: BIT STRING 0 unused bits, encapsulates { |
| 687 30 45: SEQUENCE { |
| 689 02 20: INTEGER |
| : 36 97 CB E3 B4 2C E1 BB 61 A9 D3 CC 24 CC |
| : 22 92 9F F4 F5 87 |
| 711 02 21: INTEGER |
| : 00 AB C9 79 AF D2 16 1C A9 E3 68 A9 14 10 |
| : B4 A0 2E FF 22 5A 73 |
| : } |
| : } |
| : } |
| |
| C.3 End Entity Certificate Using RSA |
| |
| This section contains an annotated hex dump of a 654 byte version 3 |
| certificate. The certificate contains the following information: |
| (a) the serial number is 256; |
| (b) the certificate is signed with RSA and the SHA-1 hash algorithm; |
| (c) the issuer's distinguished name is OU=NIST; O=gov; C=US |
| (d) and the subject's distinguished name is CN=Tim Polk; OU=NIST; |
| O=gov; C=US |
| (e) the certificate was issued on May 21, 1996 at 09:58:26 and |
| expired on May 21, 1997 at 09:58:26; |
| (f) the certificate contains a 1024 bit RSA public key; |
| (g) the certificate is an end entity certificate (not a CA |
| certificate); |
| (h) the certificate includes an alternative subject name of |
| "<http://www.itl.nist.gov/div893/staff/polk/index.html>" and an |
| alternative issuer name of "<http://www.nist.gov/>" - both are URLs; |
| (i) the certificate include 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 |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 122] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| (j) the certificate includes a critical key usage extension |
| specifying that the public key is intended for verification of |
| digital signatures. |
| |
| 0 30 654: SEQUENCE { |
| 4 30 503: SEQUENCE { |
| 8 A0 3: [0] { |
| 10 02 1: INTEGER 2 |
| : } |
| 13 02 2: INTEGER 256 |
| 17 30 13: SEQUENCE { |
| 19 06 9: OBJECT IDENTIFIER |
| : sha1withRSAEncryption (1 2 840 113549 1 1 5) |
| 30 05 0: NULL |
| : } |
| 32 30 42: SEQUENCE { |
| 34 31 11: SET { |
| 36 30 9: SEQUENCE { |
| 38 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) |
| 43 13 2: PrintableString 'US' |
| : } |
| : } |
| 47 31 12: SET { |
| 49 30 10: SEQUENCE { |
| 51 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) |
| 56 13 3: PrintableString 'gov' |
| : } |
| : } |
| 61 31 13: SET { |
| 63 30 11: SEQUENCE { |
| 65 06 3: OBJECT IDENTIFIER |
| : organizationalUnitName (2 5 4 11) |
| 70 13 4: PrintableString 'NIST' |
| : } |
| : } |
| : } |
| 76 30 30: SEQUENCE { |
| 78 17 13: UTCTime '960521095826Z' |
| 93 17 13: UTCTime '970521095826Z' |
| : } |
| 108 30 61: SEQUENCE { |
| 110 31 11: SET { |
| 112 30 9: SEQUENCE { |
| 114 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) |
| 119 13 2: PrintableString 'US' |
| : } |
| : } |
| 123 31 12: SET { |
| |
| |
| |
| Housley, et. al. Standards Track [Page 123] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 125 30 10: SEQUENCE { |
| 127 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) |
| 132 13 3: PrintableString 'gov' |
| : } |
| : } |
| 137 31 13: SET { |
| 139 30 11: SEQUENCE { |
| 141 06 3: OBJECT IDENTIFIER |
| : organizationalUnitName (2 5 4 11) |
| 146 13 4: PrintableString 'NIST' |
| : } |
| : } |
| 152 31 17: SET { |
| 154 30 15: SEQUENCE { |
| 156 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) |
| 161 13 8: PrintableString 'Tim Polk' |
| : } |
| : } |
| : } |
| 171 30 159: SEQUENCE { |
| 174 30 13: SEQUENCE { |
| 176 06 9: OBJECT IDENTIFIER |
| : rsaEncryption (1 2 840 113549 1 1 1) |
| 187 05 0: NULL |
| : } |
| 189 03 141: BIT STRING 0 unused bits, encapsulates { |
| 193 30 137: SEQUENCE { |
| 196 02 129: INTEGER |
| : 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 |
| 328 02 3: INTEGER 65537 |
| : } |
| : } |
| : } |
| 333 A3 175: [3] { |
| 336 30 172: SEQUENCE { |
| 339 30 63: SEQUENCE { |
| 341 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) |
| 346 04 56: OCTET STRING, encapsulates { |
| 348 30 54: SEQUENCE { |
| |
| |
| |
| Housley, et. al. Standards Track [Page 124] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 350 86 52: [6] |
| : 'http://www.itl.nist.gov/div893/staff/' |
| : 'polk/index.html' |
| : } |
| : } |
| : } |
| 404 30 31: SEQUENCE { |
| 406 06 3: OBJECT IDENTIFIER issuerAltName (2 5 29 18) |
| 411 04 24: OCTET STRING, encapsulates { |
| 413 30 22: SEQUENCE { |
| 415 86 20: [6] 'http://www.nist.gov/' |
| : } |
| : } |
| : } |
| 437 30 31: SEQUENCE { |
| 439 06 3: OBJECT IDENTIFIER |
| : authorityKeyIdentifier (2 5 29 35) |
| 444 04 24: OCTET STRING, encapsulates { |
| 446 30 22: SEQUENCE { |
| 448 80 20: [0] |
| : 08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E |
| : 70 6A 4A 20 84 2C 32 |
| : } |
| : } |
| : } |
| 470 30 23: SEQUENCE { |
| 472 06 3: OBJECT IDENTIFIER |
| : certificatePolicies (2 5 29 32) |
| 477 04 16: OCTET STRING, encapsulates { |
| 479 30 14: SEQUENCE { |
| 481 30 12: SEQUENCE { |
| 483 06 10: OBJECT IDENTIFIER |
| : '2 16 840 1 101 3 2 1 48 9' |
| : } |
| : } |
| : } |
| : } |
| 495 30 14: SEQUENCE { |
| 497 06 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) |
| 502 01 1: BOOLEAN TRUE |
| 505 04 4: OCTET STRING, encapsulates { |
| 507 03 2: BIT STRING 7 unused bits |
| : '1'B (bit 0) |
| : } |
| : } |
| : } |
| : } |
| : } |
| |
| |
| |
| Housley, et. al. Standards Track [Page 125] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 511 30 13: SEQUENCE { |
| 513 06 9: OBJECT IDENTIFIER |
| : sha1withRSAEncryption (1 2 840 113549 1 1 5) |
| 524 05 0: NULL |
| : } |
| 526 03 129: BIT STRING 0 unused bits |
| : 1E 07 77 6E 66 B5 B6 B8 57 F0 03 DC 6F 77 |
| : 6D AF 55 1D 74 E5 CE 36 81 FC 4B C5 F4 47 |
| : 82 C4 0A 25 AA 8D D6 7D 3A 89 AB 44 34 39 |
| : F6 BD 61 1A 78 85 7A B8 1E 92 A2 22 2F CE |
| : 07 1A 08 8E F1 46 03 59 36 4A CB 60 E6 03 |
| : 40 01 5B 2A 44 D6 E4 7F EB 43 5E 74 0A E6 |
| : E4 F9 3E E1 44 BE 1F E7 5F 5B 2C 41 8D 08 |
| : BD 26 FE 6A A6 C3 2F B2 3B 41 12 6B C1 06 |
| : 8A B8 4C 91 59 EB 2F 38 20 2A 67 74 20 0B |
| : 77 F3 |
| : } |
| |
| C.4 Certificate Revocation List |
| |
| This section contains an annotated hex dump of a version 2 CRL with |
| one extension (cRLNumber). The CRL was issued by OU=NIST; O=gov; |
| C=US on August 7, 1997; the next scheduled issuance was September 7, |
| 1997. The CRL includes one revoked certificates: serial number 18 |
| (12 hex), which was revoked on July 31, 1997 due to keyCompromise. |
| The CRL itself is number 18, and it was signed with DSA and SHA-1. |
| |
| 0 30 203: SEQUENCE { |
| 3 30 140: SEQUENCE { |
| 6 02 1: INTEGER 1 |
| 9 30 9: SEQUENCE { |
| 11 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) |
| : } |
| 20 30 42: SEQUENCE { |
| 22 31 11: SET { |
| 24 30 9: SEQUENCE { |
| 26 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) |
| 31 13 2: PrintableString 'US' |
| : } |
| : } |
| 35 31 12: SET { |
| 37 30 10: SEQUENCE { |
| 39 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) |
| 44 13 3: PrintableString 'gov' |
| : } |
| : } |
| 49 31 13: SET { |
| 51 30 11: SEQUENCE { |
| |
| |
| |
| Housley, et. al. Standards Track [Page 126] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| 53 06 3: OBJECT IDENTIFIER |
| : organizationalUnitName (2 5 4 11) |
| 58 13 4: PrintableString 'NIST' |
| : } |
| : } |
| : } |
| 64 17 13: UTCTime '970807000000Z' |
| 79 17 13: UTCTime '970907000000Z' |
| 94 30 34: SEQUENCE { |
| 96 30 32: SEQUENCE { |
| 98 02 1: INTEGER 18 |
| 101 17 13: UTCTime '970731000000Z' |
| 116 30 12: SEQUENCE { |
| 118 30 10: SEQUENCE { |
| 120 06 3: OBJECT IDENTIFIER cRLReason (2 5 29 21) |
| 125 04 3: OCTET STRING, encapsulates { |
| 127 0A 1: ENUMERATED 1 |
| : } |
| : } |
| : } |
| : } |
| : } |
| 130 A0 14: [0] { |
| 132 30 12: SEQUENCE { |
| 134 30 10: SEQUENCE { |
| 136 06 3: OBJECT IDENTIFIER cRLNumber (2 5 29 20) |
| 141 04 3: OCTET STRING, encapsulates { |
| 143 02 1: INTEGER 12 |
| : } |
| : } |
| : } |
| : } |
| : } |
| 146 30 9: SEQUENCE { |
| 148 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) |
| : } |
| 157 03 47: BIT STRING 0 unused bits, encapsulates { |
| 160 30 44: SEQUENCE { |
| 162 02 20: INTEGER |
| : 22 4E 9F 43 BA 95 06 34 F2 BB 5E 65 DB A6 |
| : 80 05 C0 3A 29 47 |
| 184 02 20: INTEGER |
| : 59 1A 57 C9 82 D7 02 21 14 C3 D4 0B 32 1B |
| : 96 16 B1 1F 46 5A |
| : } |
| : } |
| : } |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 127] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| Author Addresses |
| |
| Russell Housley |
| RSA Laboratories |
| 918 Spring Knoll Drive |
| Herndon, VA 20170 |
| USA |
| |
| EMail: rhousley@rsasecurity.com |
| |
| Warwick Ford |
| VeriSign, Inc. |
| 401 Edgewater Place |
| Wakefield, MA 01880 |
| USA |
| |
| EMail: wford@verisign.com |
| |
| Tim Polk |
| NIST |
| Building 820, Room 426 |
| Gaithersburg, MD 20899 |
| USA |
| |
| EMail: wpolk@nist.gov |
| |
| David Solo |
| Citigroup |
| 909 Third Ave, 16th Floor |
| New York, NY 10043 |
| USA |
| |
| EMail: dsolo@alum.mit.edu |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 128] |
| |
| RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| |
| |
| Full Copyright Statement |
| |
| Copyright (C) The Internet Society (2002). All Rights Reserved. |
| |
| This document and translations of it may be copied and furnished to |
| others, and derivative works that comment on or otherwise explain it |
| or assist in its implementation may be prepared, copied, published |
| and distributed, in whole or in part, without restriction of any |
| kind, provided that the above copyright notice and this paragraph are |
| included on all such copies and derivative works. However, this |
| document itself may not be modified in any way, such as by removing |
| the copyright notice or references to the Internet Society or other |
| Internet organizations, except as needed for the purpose of |
| developing Internet standards in which case the procedures for |
| copyrights defined in the Internet Standards process must be |
| followed, or as required to translate it into languages other than |
| English. |
| |
| The limited permissions granted above are perpetual and will not be |
| revoked by the Internet Society or its successors or assigns. |
| |
| This document and the information contained herein is provided on an |
| "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING |
| TASK FORCE DISCLAIMS 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. |
| |
| Acknowledgement |
| |
| Funding for the RFC Editor function is currently provided by the |
| Internet Society. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Housley, et. al. Standards Track [Page 129] |
| |