idnits 2.17.00 (12 Aug 2021) /tmp/idnits32535/draft-ietf-pkix-new-part1-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 63 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 7 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 8 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 588 has weird spacing: '...issuing a cer...' == Line 600 has weird spacing: '...: This is th...' -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2001) is 7522 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 5846 -- Looks like a reference, but probably isn't: '1' on line 5579 -- Looks like a reference, but probably isn't: '2' on line 5084 -- Looks like a reference, but probably isn't: '3' on line 5722 == Missing Reference: 'ISO 8859-1' is mentioned on line 897, but not defined -- Looks like a reference, but probably isn't: '4' on line 5086 -- Looks like a reference, but probably isn't: '5' on line 5087 -- Looks like a reference, but probably isn't: '6' on line 5738 -- Looks like a reference, but probably isn't: '7' on line 4948 -- Looks like a reference, but probably isn't: '8' on line 4949 == Missing Reference: 'RFC1738' is mentioned on line 2718, but not defined ** Obsolete undefined reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) == Missing Reference: 'RFC1778' is mentioned on line 2718, but not defined ** Obsolete undefined reference: RFC 1778 (Obsoleted by RFC 3494) == Missing Reference: 'UNIVERSAL 28' is mentioned on line 4219, but not defined == Missing Reference: 'UNIVERSAL 30' is mentioned on line 4222, but not defined == Missing Reference: 'UNIVERSAL 12' is mentioned on line 4226, but not defined == Missing Reference: 'APPLICATION 1' is mentioned on line 4552, but not defined == Missing Reference: 'APPLICATION 2' is mentioned on line 4558, but not defined == Unused Reference: 'RFC 1423' is defined on line 3946, but no explicit reference was found in the text == Unused Reference: 'RFC 1778' is defined on line 3961, but no explicit reference was found in the text == Unused Reference: 'RFC 1883' is defined on line 3965, but no explicit reference was found in the text == Unused Reference: 'RFC 2119' is defined on line 3972, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO 10646' ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Downref: Normative reference to an Historic RFC: RFC 1422 ** Downref: Normative reference to an Historic RFC: RFC 1423 ** Obsolete normative reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) ** Obsolete normative reference: RFC 1519 (Obsoleted by RFC 4632) ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 1778 (Obsoleted by RFC 3494) ** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 2044 (Obsoleted by RFC 2279) ** Obsolete normative reference: RFC 2252 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2459 (Obsoleted by RFC 3280) ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) == Outdated reference: draft-ietf-pkix-ipki-pkalgs has been published as RFC 3279 == Outdated reference: draft-ietf-pkix-time-stamp has been published as RFC 3161 Summary: 21 errors (**), 0 flaws (~~), 22 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group R. Housley (RSA Laboratories) 3 Internet Draft W. Ford (VeriSign) 4 W. Polk (NIST) 5 D. Solo (Citigroup) 6 expires in six months October 2001 8 Internet X.509 Public Key Infrastructure 10 Certificate and CRL Profile 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 To view the entire list of current Internet-Drafts, please check the 34 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 35 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 36 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 37 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 39 Copyright (C) The Internet Society (2001). All Rights Reserved. 41 Abstract 43 This is the tenth draft of a specification based upon RFC 2459. When 44 complete, this specification will obsolete RFC 2459. 46 Please send comments on this document to the ietf-pkix@imc.org mail 47 list. 49 This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use 50 in the Internet. An overview of the approach and model are provided 51 as an introduction. The X.509 v3 certificate format is described in 52 detail, with additional information regarding the format and 53 semantics of Internet name forms (e.g., IP addresses). Standard 54 certificate extensions are described and one new Internet-specific 55 extension is defined. A required set of certificate extensions is 56 specified. The X.509 v2 CRL format is described and a required 57 extension set is defined as well. An algorithm for X.509 certificate 58 path validation is described. Supplemental information is provided 59 describing the format of public keys and digital signatures in X.509 60 certificates for common Internet public key encryption algorithms 61 (i.e., RSA, DSA, and Diffie-Hellman). ASN.1 modules and examples are 62 provided in the appendices. 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in RFC 2119. 68 Table of Contents 70 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 2 Requirements and Assumptions . . . . . . . . . . . . . . . . . . 7 72 2.1 Communication and Topology . . . . . . . . . . . . . . . . . . 7 73 2.2 Acceptability Criteria . . . . . . . . . . . . . . . . . . . . 8 74 2.3 User Expectations . . . . . . . . . . . . . . . . . . . . . . . 8 75 2.4 Administrator Expectations . . . . . . . . . . . . . . . . . . 8 76 3 Overview of Approach . . . . . . . . . . . . . . . . . . . . . . 8 77 3.1 X.509 Version 3 Certificate . . . . . . . . . . . . . . . . . . 10 78 3.2 Certification Paths and Trust . . . . . . . . . . . . . . . . . 11 79 3.3 Revocation . . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 3.4 Operational Protocols . . . . . . . . . . . . . . . . . . . . . 14 81 3.5 Management Protocols . . . . . . . . . . . . . . . . . . . . . 14 82 4 Certificate and Certificate Extensions Profile . . . . . . . . . 15 83 4.1 Basic Certificate Fields . . . . . . . . . . . . . . . . . . . 16 84 4.1.1 Certificate Fields . . . . . . . . . . . . . . . . . . . . . 17 85 4.1.1.1 tbsCertificate . . . . . . . . . . . . . . . . . . . . . . 17 86 4.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . . . . . 17 87 4.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . . . . . 18 88 4.1.2 TBSCertificate . . . . . . . . . . . . . . . . . . . . . . . 18 89 4.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 4.1.2.2 Serial number . . . . . . . . . . . . . . . . . . . . . . . 19 91 4.1.2.3 Signature . . . . . . . . . . . . . . . . . . . . . . . . . 19 92 4.1.2.4 Issuer . . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 4.1.2.5 Validity . . . . . . . . . . . . . . . . . . . . . . . . . 23 94 4.1.2.5.1 UTCTime . . . . . . . . . . . . . . . . . . . . . . . . . 23 95 4.1.2.5.2 GeneralizedTime . . . . . . . . . . . . . . . . . . . . . 23 96 4.1.2.6 Subject . . . . . . . . . . . . . . . . . . . . . . . . . . 24 97 4.1.2.7 Subject Public Key Info . . . . . . . . . . . . . . . . . . 25 98 4.1.2.8 Unique Identifiers . . . . . . . . . . . . . . . . . . . . 25 99 4.1.2.9 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 25 100 4.2 Certificate Extensions . . . . . . . . . . . . . . . . . . . . 25 101 4.2.1 Standard Extensions . . . . . . . . . . . . . . . . . . . . . 26 102 4.2.1.1 Authority Key Identifier . . . . . . . . . . . . . . . . . 27 103 4.2.1.2 Subject Key Identifier . . . . . . . . . . . . . . . . . . 28 104 4.2.1.3 Key Usage . . . . . . . . . . . . . . . . . . . . . . . . . 29 105 4.2.1.4 Private Key Usage Period . . . . . . . . . . . . . . . . . 30 106 4.2.1.5 Certificate Policies . . . . . . . . . . . . . . . . . . . 31 107 4.2.1.6 Policy Mappings . . . . . . . . . . . . . . . . . . . . . . 33 108 4.2.1.7 Subject Alternative Name . . . . . . . . . . . . . . . . . 34 109 4.2.1.8 Issuer Alternative Name . . . . . . . . . . . . . . . . . . 37 110 4.2.1.9 Subject Directory Attributes . . . . . . . . . . . . . . . 37 111 4.2.1.10 Basic Constraints . . . . . . . . . . . . . . . . . . . . 37 112 4.2.1.11 Name Constraints . . . . . . . . . . . . . . . . . . . . . 38 113 4.2.1.12 Policy Constraints . . . . . . . . . . . . . . . . . . . . 40 114 4.2.1.13 Extended key usage field . . . . . . . . . . . . . . . . . 41 115 4.2.1.14 CRL Distribution Points . . . . . . . . . . . . . . . . . 43 116 4.2.1.15 Inhibit Any-Policy . . . . . . . . . . . . . . . . . . . . 44 117 4.2.1.16 Freshest CRL . . . . . . . . . . . . . . . . . . . . . . . 45 118 4.2.2 Internet Certificate Extensions . . . . . . . . . . . . . . . 45 119 4.2.2.1 Authority Information Access . . . . . . . . . . . . . . . 45 120 4.2.2.2 Subject Information Access . . . . . . . . . . . . . . . . 47 121 5 CRL and CRL Extensions Profile . . . . . . . . . . . . . . . . . 48 122 5.1 CRL Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 49 123 5.1.1 CertificateList Fields . . . . . . . . . . . . . . . . . . . 50 124 5.1.1.1 tbsCertList . . . . . . . . . . . . . . . . . . . . . . . . 50 125 5.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . . . . . 51 126 5.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . . . . . 51 127 5.1.2 Certificate List "To Be Signed" . . . . . . . . . . . . . . . 52 128 5.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . . . . . 52 129 5.1.2.2 Signature . . . . . . . . . . . . . . . . . . . . . . . . . 52 130 5.1.2.3 Issuer Name . . . . . . . . . . . . . . . . . . . . . . . . 52 131 5.1.2.4 This Update . . . . . . . . . . . . . . . . . . . . . . . . 52 132 5.1.2.5 Next Update . . . . . . . . . . . . . . . . . . . . . . . . 53 133 5.1.2.6 Revoked Certificates . . . . . . . . . . . . . . . . . . . 53 134 5.1.2.7 Extensions . . . . . . . . . . . . . . . . . . . . . . . . 53 135 5.2 CRL Extensions . . . . . . . . . . . . . . . . . . . . . . . . 54 136 5.2.1 Authority Key Identifier . . . . . . . . . . . . . . . . . . 54 137 5.2.2 Issuer Alternative Name . . . . . . . . . . . . . . . . . . . 54 138 5.2.3 CRL Number . . . . . . . . . . . . . . . . . . . . . . . . . 55 139 5.2.4 Delta CRL Indicator . . . . . . . . . . . . . . . . . . . . . 55 140 5.2.5 Issuing Distribution Point . . . . . . . . . . . . . . . . . 58 141 5.2.6 Freshest CRL . . . . . . . . . . . . . . . . . . . . . . . . 59 142 5.3 CRL Entry Extensions . . . . . . . . . . . . . . . . . . . . . 60 143 5.3.1 Reason Code . . . . . . . . . . . . . . . . . . . . . . . . . 60 144 5.3.2 Hold Instruction Code . . . . . . . . . . . . . . . . . . . . 61 145 5.3.3 Invalidity Date . . . . . . . . . . . . . . . . . . . . . . . 61 146 5.3.4 Certificate Issuer . . . . . . . . . . . . . . . . . . . . . 62 147 6 Certificate Path Validation . . . . . . . . . . . . . . . . . . . 62 148 6.1 Basic Path Validation . . . . . . . . . . . . . . . . . . . . . 63 149 6.1.1 Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 150 6.1.2 Initialization . . . . . . . . . . . . . . . . . . . . . . . 67 151 6.1.3 Basic Certificate Processing . . . . . . . . . . . . . . . . 69 152 6.1.4 Preparation for Certificate i+1 . . . . . . . . . . . . . . . 74 153 6.1.5 Wrap-up procedure . . . . . . . . . . . . . . . . . . . . . . 77 154 6.1.6 Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 155 6.2 Extending Path Validation . . . . . . . . . . . . . . . . . . . 79 156 6.3 CRL Validation . . . . . . . . . . . . . . . . . . . . . . . . 80 157 6.3.1 Revocation Inputs . . . . . . . . . . . . . . . . . . . . . . 80 158 6.3.2 Initialization and Revocation State Variables . . . . . . . . 81 159 6.3.3 CRL Processing . . . . . . . . . . . . . . . . . . . . . . . 81 160 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 161 8 Intellectual Property Rights . . . . . . . . . . . . . . . . . . 87 162 9 Security Considerations . . . . . . . . . . . . . . . . . . . . . 87 163 Appendix A. ASN.1 Structures and OIDs . . . . . . . . . . . . . . . 91 164 A.1 Explicitly Tagged Module, 1988 Syntax . . . . . . . . . . . . . 91 165 A.2 Implicitly Tagged Module, 1988 Syntax . . . . . . . . . . . . . 105 166 Appendix B. ASN.1 Notes . . . . . . . . . . . . . . . . . . . . . . 112 167 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . . 114 168 C.1 DSA Self-Signed Certificate . . . . . . . . . . . . . . . . . . 115 169 C.2 End Entity Certificate Using DSA . . . . . . . . . . . . . . . 118 170 C.3 End Entity Certificate Using RSA . . . . . . . . . . . . . . . 121 171 C.4 Certificate Revocation List . . . . . . . . . . . . . . . . . . 125 172 Appendix D. Author Addresses . . . . . . . . . . . . . . . . . . . 128 173 Appendix E. Full Copyright Statement . . . . . . . . . . . . . . . 128 174 1 Introduction 176 This specification is one part of a family of standards for the X.509 177 Public Key Infrastructure (PKI) for the Internet. This specification 178 is a standalone document; implementations of this standard may 179 proceed independent from the other parts. 181 This specification profiles the format and semantics of certificates 182 and certificate revocation lists for the Internet PKI. Procedures 183 are described for processing of certification paths in the Internet 184 environment. Encoding rules are provided for popular cryptographic 185 algorithms. Finally, ASN.1 modules are provided in the appendices 186 for all data structures defined or referenced. 188 The specification describes the requirements which inspire the 189 creation of this document and the assumptions which affect its scope 190 in Section 2. Section 3 presents an architectural model and 191 describes its relationship to previous IETF and ISO/IEC/ITU 192 standards. In particular, this document's relationship with the IETF 193 PEM specifications and the ISO/IEC/ITU X.509 documents are described. 195 The specification profiles the X.509 version 3 certificate in Section 196 4, and the X.509 version 2 certificate revocation list (CRL) in 197 Section 5. The profiles include the identification of ISO/IEC/ITU 198 and ANSI extensions which may be useful in the Internet PKI. The 199 profiles are presented in the 1988 Abstract Syntax Notation One 200 (ASN.1) rather than the 1997 ASN.1 syntax used in the ISO/IEC/ITU 201 standards. 203 This specification also includes path validation procedures in 204 Section 6. These procedures are based upon the ISO/IEC/ITU 205 definition, but the presentation assumes one or more self-signed 206 trusted CA certificates. Implementations are required to derive the 207 same results but are not required to use the specified procedures. 209 Procedures for identification and encoding of public key materials 210 and digital signatures are defined in [PKIXALGS]. Implementations of 211 this specification are not required to use any particular 212 cryptographic algorithms. However, conforming implementations which 213 use the algorithms identified in [PKIXALGS] MUST identify and encode 214 the public key materials and digital signatures as described in that 215 specification. 217 Finally, three appendices are provided to aid implementers. Appendix 218 A contains all ASN.1 structures defined or referenced within this 219 specification. As above, the material is presented in the 1988 220 ASN.1. Appendix B contains notes on less familiar features of the 221 ASN.1 notation used within this specification. Appendix C contains 222 examples of a conforming certificate and a conforming CRL. 224 2 Requirements and Assumptions 226 The goal of this specification is to develop a profile to facilitate 227 the use of X.509 certificates within Internet applications for those 228 communities wishing to make use of X.509 technology. Such 229 applications may include WWW, electronic mail, user authentication, 230 and IPsec. In order to relieve some of the obstacles to using X.509 231 certificates, this document defines a profile to promote the 232 development of certificate management systems; development of 233 application tools; and interoperability determined by policy. 235 Some communities will need to supplement, or possibly replace, this 236 profile in order to meet the requirements of specialized application 237 domains or environments with additional authorization, assurance, or 238 operational requirements. However, for basic applications, common 239 representations of frequently used attributes are defined so that 240 application developers can obtain necessary information without 241 regard to the issuer of a particular certificate or certificate 242 revocation list (CRL). 244 A certificate user should review the certificate policy generated by 245 the certification authority (CA) before relying on the authentication 246 or non-repudiation services associated with the public key in a 247 particular certificate. To this end, this standard does not 248 prescribe legally binding rules or duties. 250 As supplemental authorization and attribute management tools emerge, 251 such as attribute certificates, it may be appropriate to limit the 252 authenticated attributes that are included in a certificate. These 253 other management tools may provide more appropriate methods of 254 conveying many authenticated attributes. 256 2.1 Communication and Topology 258 The users of certificates will operate in a wide range of 259 environments with respect to their communication topology, especially 260 users of secure electronic mail. This profile supports users without 261 high bandwidth, real-time IP connectivity, or high connection 262 availability. In addition, the profile allows for the presence of 263 firewall or other filtered communication. 265 This profile does not assume the deployment of an X.500 Directory 266 system or a LDAP directory system. The profile does not prohibit the 267 use of an X.500 Directory or a LDAP directory; however, any means of 268 distributing certificates and certificate revocation lists (CRLs) may 269 be used. 271 2.2 Acceptability Criteria 273 The goal of the Internet Public Key Infrastructure (PKI) is to meet 274 the needs of deterministic, automated identification, authentication, 275 access control, and authorization functions. Support for these 276 services determines the attributes contained in the certificate as 277 well as the ancillary control information in the certificate such as 278 policy data and certification path constraints. 280 2.3 User Expectations 282 Users of the Internet PKI are people and processes who use client 283 software and are the subjects named in certificates. These uses 284 include readers and writers of electronic mail, the clients for WWW 285 browsers, WWW servers, and the key manager for IPsec within a router. 286 This profile recognizes the limitations of the platforms these users 287 employ and the limitations in sophistication and attentiveness of the 288 users themselves. This manifests itself in minimal user 289 configuration responsibility (e.g., trusted CA keys, rules), explicit 290 platform usage constraints within the certificate, certification path 291 constraints which shield the user from many malicious actions, and 292 applications which sensibly automate validation functions. 294 2.4 Administrator Expectations 296 As with user expectations, the Internet PKI profile is structured to 297 support the individuals who generally operate CAs. Providing 298 administrators with unbounded choices increases the chances that a 299 subtle CA administrator mistake will result in broad compromise. 300 Also, unbounded choices greatly complicate the software that process 301 and validate the certificates created by the CA. 303 3 Overview of Approach 305 Following is a simplified view of the architectural model assumed by 306 the PKIX specifications. 308 +---+ 309 | C | +------------+ 310 | e | <-------------------->| End entity | 311 | r | Operational +------------+ 312 | t | transactions ^ 313 | i | and management | Management 314 | f | transactions | transactions PKI 315 | i | | users 316 | c | v 317 | a | ======================= +--+------------+ ============== 318 | t | ^ ^ 319 | e | | | PKI 320 | | v | management 321 | & | +------+ | entities 322 | | <---------------------| RA |<----+ | 323 | C | Publish certificate +------+ | | 324 | R | | | 325 | L | | | 326 | | v v 327 | R | +------------+ 328 | e | <------------------------------| CA | 329 | p | Publish certificate +------------+ 330 | o | Publish CRL ^ ^ 331 | s | | | Management 332 | i | +------------+ | | transactions 333 | t | <--------------| CRL Issuer |<----+ | 334 | o | Publish CRL +------------+ v 335 | r | +------+ 336 | y | | CA | 337 +---+ +------+ 339 Figure 1 - PKI Entities 341 The components in this model are: 343 end entity: user of PKI certificates and/or end user system that 344 is the subject of a certificate; 345 CA: certification authority; 346 RA: registration authority, i.e., an optional system to 347 which a CA delegates certain management functions; 348 CRL issuer: an optional system to which a CA delegates the 349 publication of certificate revocation lists; 350 repository: a system or collection of distributed systems that 351 store certificates and CRLs and serves as a means of 352 distributing these certificates and CRLs to end 353 entities. 355 Note that an Attribute Authority (AA) might also choose to delegate 356 the publication of CRLs to a CRL issuer. 358 3.1 X.509 Version 3 Certificate 360 Users of a public key require confidence that the associated private 361 key is owned by the correct remote subject (person or system) with 362 which an encryption or digital signature mechanism will be used. 363 This confidence is obtained through the use of public key 364 certificates, which are data structures that bind public key values 365 to subjects. The binding is asserted by having a trusted CA 366 digitally sign each certificate. The CA may base this assertion upon 367 technical means (a.k.a., proof of possession through a challenge- 368 response protocol), presentation of the private key, or on an 369 assertion by the subject. A certificate has a limited valid lifetime 370 which is indicated in its signed contents. Because a certificate's 371 signature and timeliness can be independently checked by a 372 certificate-using client, certificates can be distributed via 373 untrusted communications and server systems, and can be cached in 374 unsecured storage in certificate-using systems. 376 ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8, which was 377 first published in 1988 as part of the X.500 Directory 378 recommendations, defines a standard certificate format [X.509]. The 379 certificate format in the 1988 standard is called the version 1 (v1) 380 format. When X.500 was revised in 1993, two more fields were added, 381 resulting in the version 2 (v2) format. 383 The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993, 384 include specifications for a public key infrastructure based on X.509 385 v1 certificates [RFC 1422]. The experience gained in attempts to 386 deploy RFC 1422 made it clear that the v1 and v2 certificate formats 387 are deficient in several respects. Most importantly, more fields 388 were needed to carry information which PEM design and implementation 389 experience has proven necessary. In response to these new 390 requirements, ISO/IEC/ITU and ANSI X9 developed the X.509 version 3 391 (v3) certificate format. The v3 format extends the v2 format by 392 adding provision for additional extension fields. Particular 393 extension field types may be specified in standards or may be defined 394 and registered by any organization or community. In June 1996, 395 standardization of the basic v3 format was completed [X.509]. 397 ISO/IEC/ITU and ANSI X9 have also developed standard extensions for 398 use in the v3 extensions field [X.509][X9.55]. These extensions can 399 convey such data as additional subject identification information, 400 key attribute information, policy information, and certification path 401 constraints. 403 However, the ISO/IEC/ITU and ANSI X9 standard extensions are very 404 broad in their applicability. In order to develop interoperable 405 implementations of X.509 v3 systems for Internet use, it is necessary 406 to specify a profile for use of the X.509 v3 extensions tailored for 407 the Internet. It is one goal of this document to specify a profile 408 for Internet WWW, electronic mail, and IPsec applications. 409 Environments with additional requirements may build on this profile 410 or may replace it. 412 3.2 Certification Paths and Trust 414 A user of a security service requiring knowledge of a public key 415 generally needs to obtain and validate a certificate containing the 416 required public key. If the public-key user does not already hold an 417 assured copy of the public key of the CA that signed the certificate, 418 the CA's name, and related information (such as the validity period 419 or name constraints), then it might need an additional certificate to 420 obtain that public key. In general, a chain of multiple certificates 421 may be needed, comprising a certificate of the public key owner (the 422 end entity) signed by one CA, and zero or more additional 423 certificates of CAs signed by other CAs. Such chains, called 424 certification paths, are required because a public key user is only 425 initialized with a limited number of assured CA public keys. 427 There are different ways in which CAs might be configured in order 428 for public key users to be able to find certification paths. For 429 PEM, RFC 1422 defined a rigid hierarchical structure of CAs. There 430 are three types of PEM certification authority: 432 (a) Internet Policy Registration Authority (IPRA): This 433 authority, operated under the auspices of the Internet Society, 434 acts as the root of the PEM certification hierarchy at level 1. 435 It issues certificates only for the next level of authorities, 436 PCAs. All certification paths start with the IPRA. 438 (b) Policy Certification Authorities (PCAs): PCAs are at level 2 439 of the hierarchy, each PCA being certified by the IPRA. A PCA 440 shall establish and publish a statement of its policy with respect 441 to certifying users or subordinate certification authorities. 442 Distinct PCAs aim to satisfy different user needs. For example, 443 one PCA (an organizational PCA) might support the general 444 electronic mail needs of commercial organizations, and another PCA 445 (a high-assurance PCA) might have a more stringent policy designed 446 for satisfying legally binding digital signature requirements. 448 (c) Certification Authorities (CAs): CAs are at level 3 of the 449 hierarchy and can also be at lower levels. Those at level 3 are 450 certified by PCAs. CAs represent, for example, particular 451 organizations, particular organizational units (e.g., departments, 452 groups, sections), or particular geographical areas. 454 RFC 1422 furthermore has a name subordination rule which requires 455 that a CA can only issue certificates for entities whose names are 456 subordinate (in the X.500 naming tree) to the name of the CA itself. 457 The trust associated with a PEM certification path is implied by the 458 PCA name. The name subordination rule ensures that CAs below the PCA 459 are sensibly constrained as to the set of subordinate entities they 460 can certify (e.g., a CA for an organization can only certify entities 461 in that organization's name tree). Certificate user systems are able 462 to mechanically check that the name subordination rule has been 463 followed. 465 The RFC 1422 uses the X.509 v1 certificate formats. The limitations 466 of X.509 v1 required imposition of several structural restrictions to 467 clearly associate policy information or restrict the utility of 468 certificates. These restrictions included: 470 (a) a pure top-down hierarchy, with all certification paths 471 starting from IPRA; 473 (b) a naming subordination rule restricting the names of a CA's 474 subjects; and 476 (c) use of the PCA concept, which requires knowledge of 477 individual PCAs to be built into certificate chain verification 478 logic. Knowledge of individual PCAs was required to determine if 479 a chain could be accepted. 481 With X.509 v3, most of the requirements addressed by RFC 1422 can be 482 addressed using certificate extensions, without a need to restrict 483 the CA structures used. In particular, the certificate extensions 484 relating to certificate policies obviate the need for PCAs and the 485 constraint extensions obviate the need for the name subordination 486 rule. As a result, this document supports a more flexible 487 architecture, including: 489 (a) Certification paths start with a public key of a CA in a 490 user's own domain, or with the public key of the top of a 491 hierarchy. Starting with the public key of a CA in a user's own 492 domain has certain advantages. In some environments, the local 493 domain is the most trusted. 495 (b) Name constraints may be imposed through explicit inclusion of 496 a name constraints extension in a certificate, but are not 497 required. 499 (c) Policy extensions and policy mappings replace the PCA 500 concept, which permits a greater degree of automation. The 501 application can determine if the certification path is acceptable 502 based on the contents of the certificates instead of a priori 503 knowledge of PCAs. This permits automation of certificate chain 504 processing. 506 3.3 Revocation 508 When a certificate is issued, it is expected to be in use for its 509 entire validity period. However, various circumstances may cause a 510 certificate to become invalid prior to the expiration of the validity 511 period. Such circumstances include change of name, change of 512 association between subject and CA (e.g., an employee terminates 513 employment with an organization), and compromise or suspected 514 compromise of the corresponding private key. Under such 515 circumstances, the CA needs to revoke the certificate. 517 X.509 defines one method of certificate revocation. This method 518 involves each CA periodically issuing a signed data structure called 519 a certificate revocation list (CRL). A CRL is a time stamped list 520 identifying revoked certificates which is signed by a CA and made 521 freely available in a public repository. Each revoked certificate is 522 identified in a CRL by its certificate serial number. When a 523 certificate-using system uses a certificate (e.g., for verifying a 524 remote user's digital signature), that system not only checks the 525 certificate signature and validity but also acquires a suitably- 526 recent CRL and checks that the certificate serial number is not on 527 that CRL. The meaning of "suitably-recent" may vary with local 528 policy, but it usually means the most recently-issued CRL. A CA 529 issues a new CRL on a regular periodic basis (e.g., hourly, daily, or 530 weekly). An entry is added to the CRL as part of the next update 531 following notification of revocation. An entry MUST NOT be removed 532 from the CRL until it appears on one regularly scheduled CRL issued 533 beyond the revoked certificate's validity period. 535 An advantage of this revocation method is that CRLs may be 536 distributed by exactly the same means as certificates themselves, 537 namely, via untrusted servers and untrusted communications. 539 One limitation of the CRL revocation method, using untrusted 540 communications and servers, is that the time granularity of 541 revocation is limited to the CRL issue period. For example, if a 542 revocation is reported now, that revocation will not be reliably 543 notified to certificate-using systems until all currently issued CRLs 544 are updated -- this may be up to one hour, one day, or one week 545 depending on the frequency that CRLs are issued. 547 As with the X.509 v3 certificate format, in order to facilitate 548 interoperable implementations from multiple vendors, the X.509 v2 CRL 549 format needs to be profiled for Internet use. It is one goal of this 550 document to specify that profile. However, this profile does not 551 require CAs to issue CRLs. Message formats and protocols supporting 552 on-line revocation notification are defined in other PKIX 553 specifications. On-line methods of revocation notification may be 554 applicable in some environments as an alternative to the X.509 CRL. 555 On-line revocation checking may significantly reduce the latency 556 between a revocation report and the distribution of the information 557 to relying parties. Once the CA accepts the report as authentic and 558 valid, any query to the on-line service will correctly reflect the 559 certificate validation impacts of the revocation. However, these 560 methods impose new security requirements: the certificate validator 561 needs to trust the on-line validation service while the repository 562 does not need to be trusted. 564 3.4 Operational Protocols 566 Operational protocols are required to deliver certificates and CRLs 567 (or status information) to certificate using client systems. 568 Provision is needed for a variety of different means of certificate 569 and CRL delivery, including distribution procedures based on LDAP, 570 HTTP, FTP, and X.500. Operational protocols supporting these 571 functions are defined in other PKIX specifications. These 572 specifications may include definitions of message formats and 573 procedures for supporting all of the above operational environments, 574 including definitions of or references to appropriate MIME content 575 types. 577 3.5 Management Protocols 579 Management protocols are required to support on-line interactions 580 between PKI user and management entities. For example, a management 581 protocol might be used between a CA and a client system with which a 582 key pair is associated, or between two CAs which cross-certify each 583 other. The set of functions which potentially need to be supported 584 by management protocols include: 586 (a) registration: This is the process whereby a user first makes 587 itself known to a CA (directly, or through an RA), prior to that 588 CA issuing a certificate or certificates for that user. 590 (b) initialization: Before a client system can operate securely 591 it is necessary to install key materials which have the 592 appropriate relationship with keys stored elsewhere in the 593 infrastructure. For example, the client needs to be securely 594 initialized with the public key and other assured information of 595 the trusted CA(s), to be used in validating certificate paths. 597 Furthermore, a client typically needs to be initialized with its 598 own key pair(s). 600 (c) certification: This is the process in which a CA issues a 601 certificate for a user's public key, and returns that certificate 602 to the user's client system and/or posts that certificate in a 603 repository. 605 (d) key pair recovery: As an option, user client key materials 606 (e.g., a user's private key used for encryption purposes) may be 607 backed up by a CA or a key backup system. If a user needs to 608 recover these backed up key materials (e.g., as a result of a 609 forgotten password or a lost key chain file), an on-line protocol 610 exchange may be needed to support such recovery. 612 (e) key pair update: All key pairs need to be updated regularly, 613 i.e., replaced with a new key pair, and new certificates issued. 615 (f) revocation request: An authorized person advises a CA of an 616 abnormal situation requiring certificate revocation. 618 (g) cross-certification: Two CAs exchange information used in 619 establishing a cross-certificate. A cross-certificate is a 620 certificate issued by one CA to another CA which contains a CA 621 signature key used for issuing certificates. 623 Note that on-line protocols are not the only way of implementing the 624 above functions. For all functions there are off-line methods of 625 achieving the same result, and this specification does not mandate 626 use of on-line protocols. For example, when hardware tokens are 627 used, many of the functions may be achieved as part of the physical 628 token delivery. Furthermore, some of the above functions may be 629 combined into one protocol exchange. In particular, two or more of 630 the registration, initialization, and certification functions can be 631 combined into one protocol exchange. 633 The PKIX series of specifications defines a set of standard message 634 formats supporting the above functions. The protocols for conveying 635 these messages in different environments (e.g., e-mail, file 636 transfer, and WWW) are described in those specifications. 638 4 Certificate and Certificate Extensions Profile 640 This section presents a profile for public key certificates that will 641 foster interoperability and a reusable PKI. This section is based 642 upon the X.509 v3 certificate format and the standard certificate 643 extensions defined in [X.509]. The ISO/IEC/ITU documents use the 644 1997 version of ASN.1; while this document uses the 1988 ASN.1 645 syntax, the encoded certificate and standard extensions are 646 equivalent. This section also defines private extensions required to 647 support a PKI for the Internet community. 649 Certificates may be used in a wide range of applications and 650 environments covering a broad spectrum of interoperability goals and 651 a broader spectrum of operational and assurance requirements. The 652 goal of this document is to establish a common baseline for generic 653 applications requiring broad interoperability and limited special 654 purpose requirements. In particular, the emphasis will be on 655 supporting the use of X.509 v3 certificates for informal Internet 656 electronic mail, IPsec, and WWW applications. 658 4.1 Basic Certificate Fields 660 The X.509 v3 certificate basic syntax is as follows. For signature 661 calculation, the certificate is encoded using the ASN.1 distinguished 662 encoding rules (DER) [X.208]. ASN.1 DER encoding is a tag, length, 663 value encoding system for each element. 665 Certificate ::= SEQUENCE { 666 tbsCertificate TBSCertificate, 667 signatureAlgorithm AlgorithmIdentifier, 668 signatureValue BIT STRING } 670 TBSCertificate ::= SEQUENCE { 671 version [0] EXPLICIT Version DEFAULT v1, 672 serialNumber CertificateSerialNumber, 673 signature AlgorithmIdentifier, 674 issuer Name, 675 validity Validity, 676 subject Name, 677 subjectPublicKeyInfo SubjectPublicKeyInfo, 678 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 679 -- If present, version MUST be v2 or v3 680 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 681 -- If present, version MUST be v2 or v3 682 extensions [3] EXPLICIT Extensions OPTIONAL 683 -- If present, version MUST be v3 684 } 686 Version ::= INTEGER { v1(0), v2(1), v3(2) } 688 CertificateSerialNumber ::= INTEGER 690 Validity ::= SEQUENCE { 691 notBefore Time, 692 notAfter Time } 694 Time ::= CHOICE { 695 utcTime UTCTime, 696 generalTime GeneralizedTime } 698 UniqueIdentifier ::= BIT STRING 700 SubjectPublicKeyInfo ::= SEQUENCE { 701 algorithm AlgorithmIdentifier, 702 subjectPublicKey BIT STRING } 704 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 706 Extension ::= SEQUENCE { 707 extnID OBJECT IDENTIFIER, 708 critical BOOLEAN DEFAULT FALSE, 709 extnValue OCTET STRING } 711 The following items describe the X.509 v3 certificate for use in the 712 Internet. 714 4.1.1 Certificate Fields 716 The Certificate is a SEQUENCE of three required fields. The fields 717 are described in detail in the following subsections. 719 4.1.1.1 tbsCertificate 721 The field contains the names of the subject and issuer, a public key 722 associated with the subject, a validity period, and other associated 723 information. The fields are described in detail in section 4.1.2; 724 the tbsCertificate MAY also include extensions which are described in 725 section 4.2. 727 4.1.1.2 signatureAlgorithm 729 The signatureAlgorithm field contains the identifier for the 730 cryptographic algorithm used by the CA to sign this certificate. 731 [PKIXALGS] lists supported signature algorithms, but other signature 732 algorithms MAY also be supported. 734 An algorithm identifier is defined by the following ASN.1 structure: 736 AlgorithmIdentifier ::= SEQUENCE { 737 algorithm OBJECT IDENTIFIER, 738 parameters ANY DEFINED BY algorithm OPTIONAL } 740 The algorithm identifier is used to identify a cryptographic 741 algorithm. The OBJECT IDENTIFIER component identifies the algorithm 742 (such as DSA with SHA-1). The contents of the optional parameters 743 field will vary according to the algorithm identified. [PKIXALGS] 744 lists supported algorithms, but other algorithms MAY also be 745 implemented. 747 This field MUST contain the same algorithm identifier as the 748 signature field in the sequence tbsCertificate (section 4.1.2.3). 750 4.1.1.3 signatureValue 752 The signatureValue field contains a digital signature computed upon 753 the ASN.1 DER encoded tbsCertificate. The ASN.1 DER encoded 754 tbsCertificate is used as the input to the signature function. This 755 signature value is then ASN.1 encoded as a BIT STRING and included in 756 the signature field. The details of this process are specified for 757 each of algorithms listed in [PKIXALGS]. 759 By generating this signature, a CA certifies the validity of the 760 information in the tbsCertificate field. In particular, the CA 761 certifies the binding between the public key material and the subject 762 of the certificate. 764 4.1.2 TBSCertificate 766 The sequence TBSCertificate contains information associated with the 767 subject of the certificate and the CA who issued it. Every 768 TBSCertificate contains the names of the subject and issuer, a public 769 key associated with the subject, a validity period, a version number, 770 and a serial number; some MAY contain optional unique identifier 771 fields. The remainder of this section describes the syntax and 772 semantics of these fields. A TBSCertificate MAY also include 773 extensions. Extensions for the Internet PKI are described in Section 774 4.2. 776 4.1.2.1 Version 778 This field describes the version of the encoded certificate. When 779 extensions are used, as expected in this profile, use X.509 version 3 780 (value is 2). If no extensions are present, but a UniqueIdentifier 781 is present, use version 2 (value is 1). If only basic fields are 782 present, use version 1 (the value is omitted from the certificate as 783 the default value). 785 Implementations SHOULD be prepared to accept any version certificate. 786 At a minimum, conforming implementations MUST recognize version 3 787 certificates. 789 Generation of version 2 certificates is not expected by 790 implementations based on this profile. 792 4.1.2.2 Serial number 794 The serial number MUST be a positive integer assigned by the CA to 795 each certificate. It MUST be unique for each certificate issued by a 796 given CA (i.e., the issuer name and serial number identify a unique 797 certificate). CAs MUST force the serialNumber to be a non-negative 798 integer. 800 Given the uniqueness requirements above, serial numbers can be 801 expected to contain long integers. Certificate users MUST be able to 802 handle serialNumber values up to 20 octets. Conformant CAs MUST NOT 803 use serialNumber values longer than 20 octets. 805 Note: Non-conforming CAs MAY issue certificates with serial numbers 806 that are negative, or zero. Certificate users SHOULD be prepared to 807 handle such certificates. 809 4.1.2.3 Signature 811 This field contains the algorithm identifier for the algorithm used 812 by the CA to sign the certificate. 814 This field MUST contain the same algorithm identifier as the 815 signatureAlgorithm field in the sequence Certificate (section 816 4.1.1.2). The contents of the optional parameters field will vary 817 according to the algorithm identified. [PKIXALGS] lists the 818 supported signature algorithms. 820 4.1.2.4 Issuer 822 The issuer field identifies the entity who has signed and issued the 823 certificate. The issuer field MUST contain a non-empty distinguished 824 name (DN). The issuer field is defined as the X.501 type Name 825 [X.501]. Name is defined by the following ASN.1 structures: 827 Name ::= CHOICE { 828 RDNSequence } 830 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 832 RelativeDistinguishedName ::= 833 SET OF AttributeTypeAndValue 835 AttributeTypeAndValue ::= SEQUENCE { 836 type AttributeType, 837 value AttributeValue } 839 AttributeType ::= OBJECT IDENTIFIER 841 AttributeValue ::= ANY DEFINED BY AttributeType 843 DirectoryString ::= CHOICE { 844 teletexString TeletexString (SIZE (1..MAX)), 845 printableString PrintableString (SIZE (1..MAX)), 846 universalString UniversalString (SIZE (1..MAX)), 847 utf8String UTF8String (SIZE (1..MAX)), 848 bmpString BMPString (SIZE (1..MAX)) } 850 The Name describes a hierarchical name composed of attributes, such 851 as country name, and corresponding values, such as US. The type of 852 the component AttributeValue is determined by the AttributeType; in 853 general it will be a DirectoryString. 855 The DirectoryString type is defined as a choice of PrintableString, 856 TeletexString, BMPString, UTF8String, and UniversalString. The 857 UTF8String encoding [RFC 2279] is the preferred encoding, and all 858 certificates issued after December 31, 2003 MUST use the UTF8String 859 encoding of DirectoryString (except as noted below). Until that 860 date, conforming CAs MUST choose from the following options when 861 creating a distinguished name, including their own: 863 (a) if the character set is sufficient, the string MAY be 864 represented as a PrintableString; 866 (b) failing (a), if the BMPString character set is sufficient the 867 string MAY be represented as a BMPString; and 869 (c) failing (a) and (b), the string MUST be represented as a 870 UTF8String. If (a) or (b) is satisfied, the CA MAY still choose 871 to represent the string as a UTF8String. 873 Exceptions to the December 31, 2003 UTF8 encoding requirements are as 874 follows: 876 (a) CAs MAY issue "name rollover" certificates to support an 877 orderly migration to UTF8String encoding. Such certificates would 878 include the CA's UTF8String encoded name as issuer and and the old 879 name encoding as subject, or vice-versa. 881 (b) As stated in section 4.1.2.6, the subject field MUST be 882 populated with a non-empty distinguished name matching the 883 contents of the issuer field in all certificates issued by the 884 subject CA regardless of encoding. 886 The TeletexString and UniversalString are included for backward 887 compatibility, and SHOULD NOT be used for certificates for new 888 subjects. However, these types MAY be used in certificates where the 889 name was previously established. Certificate users SHOULD be 890 prepared to receive certificates with these types. 892 In addition, many legacy implementations support names encoded in the 893 ISO 8859-1 character set (Latin1String) but tag them as 894 TeletexString. The Latin1String includes characters used in Western 895 European countries which are not part of the TeletexString charcter 896 set. Implementations that process TeletexString SHOULD be prepared 897 to handle the entire ISO 8859-1 character set.[ISO 8859-1] 899 As noted above, distinguished names are composed of attributes. This 900 specification does not restrict the set of attribute types that may 901 appear in names. However, conforming implementations MUST be 902 prepared to receive certificates with issuer names containing the set 903 of attribute types defined below. This specification RECOMMENDS 904 support for additional attribute types. 906 Standard sets of attributes have been defined in the X.500 series of 907 specifications.[X.520] Implementations of this specification MUST be 908 prepared to receive the following standard attribute types in issuer 909 and subject (section 4.1.2.6) names: 911 * country, 912 * organization, 913 * organizational-unit, 914 * distinguished name qualifier, 915 * state or province name, 916 * common name (e.g., "Susan Housley"), and 917 * serial number. 919 In addition, implementations of this specification SHOULD be prepared 920 to receive the following standard attribute types in issuer and 921 subject names: 923 * locality, 924 * title, 925 * surname, 926 * given name, 927 * initials, 928 * pseudonym, and 929 * generation qualifier (e.g., "Jr.", "3rd", or "IV"). 931 The syntax and associated object identifiers (OIDs) for these 932 attribute types are provided in the ASN.1 modules in Appendix A. 934 In addition, implementations of this specification MUST be prepared 935 to receive the domainComponent attribute, as defined in [RFC 2247]. 936 The Domain (Nameserver) System (DNS) provides a hierarchical resource 937 labeling system. This attribute provides a convenient mechanism for 938 organizations that wish to use DNs that parallel their DNS names. 939 This is not a replacement for the dNSName component of the 940 alternative name field. Implementations are not required to convert 941 such names into DNS names. The syntax and associated OID for this 942 attribute type is provided in the ASN.1 modules in Appendix A. 944 Certificate users MUST be prepared to process the issuer 945 distinguished name and subject distinguished name (section 4.1.2.6) 946 fields to perform name chaining for certification path validation 947 (section 6). Name chaining is performed by matching the issuer 948 distinguished name in one certificate with the subject name in a CA 949 certificate. 951 This specification requires only a subset of the name comparison 952 functionality specified in the X.500 series of specifications. The 953 requirements for conforming implementations are as follows: 955 (a) attribute values encoded in different types (e.g., 956 PrintableString and BMPString) MAY be assumed to represent 957 different strings; 959 (b) attribute values in types other than PrintableString are case 960 sensitive (this permits matching of attribute values as binary 961 objects); 963 (c) attribute values in PrintableString are not case sensitive 964 (e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and 966 (d) attribute values in PrintableString are compared after 967 removing leading and trailing white space and converting internal 968 substrings of one or more consecutive white space characters to a 969 single space. 971 These name comparison rules permit a certificate user to validate 972 certificates issued using languages or encodings unfamiliar to the 973 certificate user. 975 In addition, implementations of this specification MAY use these 976 comparison rules to process unfamiliar attribute types for name 977 chaining. This allows implementations to process certificates with 978 unfamiliar attributes in the issuer name. 980 Note that the comparison rules defined in the X.500 series of 981 specifications indicate that the character sets used to encode data 982 in distinguished names are irrelevant. The characters themselves are 983 compared without regard to encoding. Implementations of the profile 984 are permitted to use the comparison algorithm defined in the X.500 985 series. Such an implementation will recognize a superset of name 986 matches recognized by the algorithm specified above. 988 4.1.2.5 Validity 990 The certificate validity period is the time interval during which the 991 CA warrants that it will maintain information about the status of the 992 certificate. The field is represented as a SEQUENCE of two dates: 993 the date on which the certificate validity period begins (notBefore) 994 and the date on which the certificate validity period ends 995 (notAfter). Both notBefore and notAfter may be encoded as UTCTime or 996 GeneralizedTime. 998 CAs conforming to this profile MUST always encode certificate 999 validity dates through the year 2049 as UTCTime; certificate validity 1000 dates in 2050 or later MUST be encoded as GeneralizedTime. 1002 The validity period for a certificate is the period of time from 1003 notBefore through notAfter, inclusive. 1005 4.1.2.5.1 UTCTime 1007 The universal time type, UTCTime, is a standard ASN.1 type intended 1008 for representation of dates and time. UTCTime specifies the year 1009 through the two low order digits and time is specified to the 1010 precision of one minute or one second. UTCTime includes either Z 1011 (for Zulu, or Greenwich Mean Time) or a time differential. 1013 For the purposes of this profile, UTCTime values MUST be expressed 1014 Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are 1015 YYMMDDHHMMSSZ), even where the number of seconds is zero. Conforming 1016 systems MUST interpret the year field (YY) as follows: 1018 Where YY is greater than or equal to 50, the year SHALL be 1019 interpreted as 19YY; and 1021 Where YY is less than 50, the year SHALL be interpreted as 20YY. 1023 4.1.2.5.2 GeneralizedTime 1025 The generalized time type, GeneralizedTime, is a standard ASN.1 type 1026 for variable precision representation of time. Optionally, the 1027 GeneralizedTime field can include a representation of the time 1028 differential between local and Greenwich Mean Time. 1030 For the purposes of this profile, GeneralizedTime values MUST be 1031 expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e., 1032 times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. 1033 GeneralizedTime values MUST NOT include fractional seconds. 1035 4.1.2.6 Subject 1037 The subject field identifies the entity associated with the public 1038 key stored in the subject public key field. The subject name MAY be 1039 carried in the subject field and/or the subjectAltName extension. If 1040 the subject is a CA (e.g., the basic constraints extension, as 1041 discussed in 4.2.1.10, is present and the value of cA is TRUE,) then 1042 the subject field MUST be populated with a non-empty distinguished 1043 name matching the contents of the issuer field (section 4.1.2.4) in 1044 all certificates issued by the subject CA. If subject naming 1045 information is present only in the subjectAltName extension (e.g., a 1046 key bound only to an email address or URI), then the subject name 1047 MUST be an empty sequence and the subjectAltName extension MUST be 1048 critical. 1050 Where it is non-empty, the subject field MUST contain an X.500 1051 distinguished name (DN). The DN MUST be unique for each subject 1052 entity certified by the one CA as defined by the issuer name field. 1053 A CA MAY issue more than one certificate with the same DN to the same 1054 subject entity. 1056 The subject name field is defined as the X.501 type Name. 1057 Implementation requirements for this field are those defined for the 1058 issuer field (section 4.1.2.4). When encoding attribute values of 1059 type DirectoryString, the encoding rules for the issuer field MUST be 1060 implemented. Implementations of this specification MUST be prepared 1061 to receive subject names containing the attribute types required for 1062 the issuer field. Implementations of this specification SHOULD be 1063 prepared to receive subject names containing the recommended 1064 attribute types for the issuer field. The syntax and associated 1065 object identifiers (OIDs) for these attribute types are provided in 1066 the ASN.1 modules in Appendix A. Implementations of this 1067 specification MAY use these comparison rules to process unfamiliar 1068 attribute types (i.e., for name chaining). This allows 1069 implementations to process certificates with unfamiliar attributes in 1070 the subject name. 1072 In addition, legacy implementations exist where an RFC 822 name is 1073 embedded in the subject distinguished name as an EmailAddress 1074 attribute. The attribute value for EmailAddress is of type IA5String 1075 to permit inclusion of the character '@', which is not part of the 1076 PrintableString character set. EmailAddress attribute values are not 1077 case sensitive (e.g., "fanfeedback@redsox.com" is the same as 1078 "FANFEEDBACK@REDSOX.COM"). 1080 Conforming implementations generating new certificates with 1081 electronic mail addresses MUST use the rfc822Name in the subject 1082 alternative name field (section 4.2.1.7) to describe such identities. 1083 Simultaneous inclusion of the EmailAddress attribute in the subject 1084 distinguished name to support legacy implementations is deprecated 1085 but permitted. 1087 4.1.2.7 Subject Public Key Info 1089 This field is used to carry the public key and identify the algorithm 1090 with which the key is used (e.g., RSA, DSA, or Diffie-Hellman). The 1091 algorithm is identified using the AlgorithmIdentifier structure 1092 specified in section 4.1.1.2. The object identifiers for the 1093 supported algorithms and the methods for encoding the public key 1094 materials (public key and parameters) are specified in [PKIXALGS]. 1096 4.1.2.8 Unique Identifiers 1098 These fields MUST only appear if the version is 2 or 3 (section 1099 4.1.2.1). These fields MUST NOT appear if the version is 1. The 1100 subject and issuer unique identifiers are present in the certificate 1101 to handle the possibility of reuse of subject and/or issuer names 1102 over time. This profile RECOMMENDS that names not be reused for 1103 different entities and that Internet certificates not make use of 1104 unique identifiers. CAs conforming to this profile SHOULD NOT 1105 generate certificates with unique identifiers. Applications 1106 conforming to this profile SHOULD be capable of parsing unique 1107 identifiers and making comparisons. 1109 4.1.2.9 Extensions 1111 This field MUST only appear if the version is 3 (section 4.1.2.1). 1112 If present, this field is a SEQUENCE of one or more certificate 1113 extensions. The format and content of certificate extensions in the 1114 Internet PKI is defined in section 4.2. 1116 4.2 Certificate Extensions 1118 The extensions defined for X.509 v3 certificates provide methods for 1119 associating additional attributes with users or public keys and for 1120 managing the certification hierarchy. The X.509 v3 certificate 1121 format also allows communities to define private extensions to carry 1122 information unique to those communities. Each extension in a 1123 certificate is designated as either critical or non-critical. A 1124 certificate using system MUST reject the certificate if it encounters 1125 a critical extension it does not recognize; however, a non-critical 1126 extension MAY be ignored if it is not recognized. The following 1127 sections present recommended extensions used within Internet 1128 certificates and standard locations for information. Communities MAY 1129 elect to use additional extensions; however, caution SHOULD be 1130 exercised in adopting any critical extensions in certificates which 1131 might prevent use in a general context. 1133 Each extension includes an OID and an ASN.1 structure. When an 1134 extension appears in a certificate, the OID appears as the field 1135 extnID and the corresponding ASN.1 encoded structure is the value of 1136 the octet string extnValue. Only one instance of a particular 1137 extension MUST appear in a particular certificate. For example, a 1138 certificate may contain only one authority key identifier extension 1139 (section 4.2.1.1). An extension includes the boolean critical, with 1140 a default value of FALSE. The text for each extension specifies the 1141 acceptable values for the critical field. 1143 Conforming CAs MUST support key identifiers (sections 4.2.1.1 and 1144 4.2.1.2), basic constraints (section 4.2.1.10), key usage (section 1145 4.2.1.3), and certificate policies (section 4.2.1.5) extensions. If 1146 the CA issues certificates with an empty sequence for the subject 1147 field, the CA MUST support the subject alternative name extension 1148 (section 4.2.1.7). Support for the remaining extensions is OPTIONAL. 1149 Conforming CAs MAY support extensions that are not identified within 1150 this specification; certificate issuers are cautioned that marking 1151 such extensions as critical may inhibit interoperability. 1153 At a minimum, applications conforming to this profile MUST recognize 1154 the following extensions: key usage (section 4.2.1.3), certificate 1155 policies (section 4.2.1.5), the subject alternative name (section 1156 4.2.1.7), basic constraints (section 4.2.1.10), name constraints 1157 (section 4.2.1.11), policy constraints (section 4.2.1.12), extended 1158 key usage (section 4.2.1.13), and inhibit any-policy (section 1159 4.2.1.15). 1161 In addition, applications conforming to this profile SHOULD recognize 1162 the authority and subject key identifier (sections 4.2.1.1 and 1163 4.2.1.2), and policy mapping (section 4.2.1.6) extensions. 1165 4.2.1 Standard Extensions 1167 This section identifies standard certificate extensions defined in 1168 [X.509] for use in the Internet PKI. Each extension is associated 1169 with an OID defined in [X.509]. These OIDs are members of the id-ce 1170 arc, which is defined by the following: 1172 id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 1174 4.2.1.1 Authority Key Identifier 1176 The authority key identifier extension provides a means of 1177 identifying the public key corresponding to the private key used to 1178 sign a certificate. This extension is used where an issuer has 1179 multiple signing keys (either due to multiple concurrent key pairs or 1180 due to changeover). The identification MAY be based on either the 1181 key identifier (the subject key identifier in the issuer's 1182 certificate) or on the issuer name and serial number. 1184 The keyIdentifier field of the authorityKeyIdentifier extension MUST 1185 be included in all certificates generated by conforming CAs to 1186 facilitate chain building. There is one exception; where a CA 1187 distributes its public key in the form of a "self-signed" 1188 certificate, the authority key identifier MAY be omitted. The 1189 signature on a self-signed certificate is generated with the private 1190 key associated with the certificate's subject public key. (This 1191 proves that the issuer possesses both the public and private keys.) 1192 In this case, the subject and authority key identifiers would be 1193 identical, but only the subject key identifier is needed for 1194 certification path building. 1196 The value of the keyIdentifier field SHOULD be derived from the 1197 public key used to verify the certificate's signature or a method 1198 that generates unique values. Two common methods for generating key 1199 identifiers from the public key are described in (sec. 4.2.1.2). One 1200 common method for generating unique values is described in (sec. 1201 4.2.1.2). Where a key identifier has not been previously 1202 established, this specification recommends use of one of these 1203 methods for generating keyIdentifiers. 1205 This profile recommends support for the key identifier method by all 1206 certificate users. 1208 This extension MUST NOT be marked critical. 1210 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 1212 AuthorityKeyIdentifier ::= SEQUENCE { 1213 keyIdentifier [0] KeyIdentifier OPTIONAL, 1214 authorityCertIssuer [1] GeneralNames OPTIONAL, 1215 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 1217 KeyIdentifier ::= OCTET STRING 1219 4.2.1.2 Subject Key Identifier 1221 The subject key identifier extension provides a means of identifying 1222 certificates that contain a particular public key. 1224 To facilitate chain building, this extension MUST appear in all 1225 conforming CA certificates, that is, all certificates including the 1226 basic constraints extension (section 4.2.1.10) where the value of cA 1227 is TRUE. The value of the subject key identifier MUST be the value 1228 placed in the key identifier field of the Authority Key Identifier 1229 extension (section 4.2.1.1) of certificates issued by the subject of 1230 this certificate. 1232 For CA certificates, subject key identifiers SHOULD be derived from 1233 the public key or a method that generates unique values. The key 1234 identifier is an explicit value placed in the certificate by the 1235 issuer, not a value generated by a certificate user. Two common 1236 methods for generating key identifiers from the public key are: 1238 (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the 1239 value of the BIT STRING subjectPublicKey (excluding the tag, 1240 length, and number of unused bits). 1242 (2) The keyIdentifier is composed of a four bit type field with 1243 the value 0100 followed by the least significant 60 bits of the 1244 SHA-1 hash of the value of the BIT STRING subjectPublicKey 1245 (excluding the tag, length, and number of unused bit string bits). 1247 One common method for generating unique values is a monotonically 1248 increasing sequence of integers. 1250 For end entity certificates, the subject key identifier extension 1251 provides a means for identifying certificates containing the 1252 particular public key used in an application. Where an end entity 1253 has obtained multiple certificates, especially from multiple CAs, the 1254 subject key identifier provides a means to quickly identify the set 1255 of certificates containing a particular public key. To assist 1256 applications in identifying the appropriate end entity certificate, 1257 this extension SHOULD be included in all end entity certificates. 1259 For end entity certificates, subject key identifiers SHOULD be 1260 derived from the public key. Two common methods for generating key 1261 identifiers from the public key are identified above. 1263 Where a key identifier has not been previously established, this 1264 specification recommends use of one of these methods for generating 1265 keyIdentifiers. 1267 This extension MUST NOT be marked critical. 1269 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 1271 SubjectKeyIdentifier ::= KeyIdentifier 1273 4.2.1.3 Key Usage 1275 The key usage extension defines the purpose (e.g., encipherment, 1276 signature, certificate signing) of the key contained in the 1277 certificate. The usage restriction might be employed when a key that 1278 could be used for more than one operation is to be restricted. For 1279 example, when an RSA key should be used only to verify signatures on 1280 objects other than public key certificates and CRLs, the 1281 digitalSignature and/or nonRepudiation bits would be asserted. 1282 Likewise, when an RSA key should be used only for key management, the 1283 keyEncipherment bit would be asserted. 1285 This extension MUST appear in certificates that contain public keys 1286 that are used to validate digital signatures on other public key 1287 certificates or CRLs. When this extension appears, it SHOULD be 1288 marked critical. 1290 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 1292 KeyUsage ::= BIT STRING { 1293 digitalSignature (0), 1294 nonRepudiation (1), 1295 keyEncipherment (2), 1296 dataEncipherment (3), 1297 keyAgreement (4), 1298 keyCertSign (5), 1299 cRLSign (6), 1300 encipherOnly (7), 1301 decipherOnly (8) } 1303 Bits in the KeyUsage type are used as follows: 1305 The digitalSignature bit is asserted when the subject public key 1306 is used with a digital signature mechanism to support security 1307 services other than non-repudiation (bit 1), certificate signing 1308 (bit 5), or CRL signing (bit 6). Digital signature mechanisms are 1309 often used for entity authentication and data origin 1310 authentication with integrity. 1312 The nonRepudiation bit is asserted when the subject public key is 1313 used to verify digital signatures used to provide a non- 1314 repudiation service which protects against the signing entity 1315 falsely denying some action, excluding certificate or CRL signing. 1316 In the case of later conflict, a reliable third party may 1317 determine the authenticity of the signed data. 1319 Further distinctions between the digitalSignature and 1320 nonRepudiation bits may be provided in specific certificate 1321 policies. 1323 The keyEncipherment bit is asserted when the subject public key is 1324 used for key transport. For example, when an RSA key is to be 1325 used for key management, then this bit is set. 1327 The dataEncipherment bit is asserted when the subject public key 1328 is used for enciphering user data, other than cryptographic keys. 1330 The keyAgreement bit is asserted when the subject public key is 1331 used for key agreement. For example, when a Diffie-Hellman key is 1332 to be used for key management, then this bit is set. 1334 The keyCertSign bit is asserted when the subject public key is 1335 used for verifying a signature on public key certificates. If the 1336 keyCertSign bit is asserted, then the cA bit in the basic 1337 constraints extension (section 4.2.1.10) MUST also be asserted. 1339 The cRLSign bit is asserted when the subject public key is used 1340 for verifying a signature on certificate revocation list (e.g., a 1341 CRL, delta CRL, or an ARL). This bit MUST be asserted in 1342 certificates that are used to verify signatures on CRLs. 1344 The meaning of the encipherOnly bit is undefined in the absence of 1345 the keyAgreement bit. When the encipherOnly bit is asserted and 1346 the keyAgreement bit is also set, the subject public key may be 1347 used only for enciphering data while performing key agreement. 1349 The meaning of the decipherOnly bit is undefined in the absence of 1350 the keyAgreement bit. When the decipherOnly bit is asserted and 1351 the keyAgreement bit is also set, the subject public key may be 1352 used only for deciphering data while performing key agreement. 1354 This profile does not restrict the combinations of bits that may be 1355 set in an instantiation of the keyUsage extension. However, 1356 appropriate values for keyUsage extensions for particular algorithms 1357 are specified in [PKIXALGS]. 1359 4.2.1.4 Private Key Usage Period 1361 This profile RECOMMENDS against the use of this extension. CAs 1362 conforming to this profile MUST NOT generate certificates that 1363 include a critical private key usage period extension. 1365 The private key usage period extension allows the certificate issuer 1366 to specify a different validity period for the private key than the 1367 certificate. This extension is intended for use with digital 1368 signature keys. This extension consists of two optional components, 1369 notBefore and notAfter. The private key associated with the 1370 certificate SHOULD NOT be used to sign objects before or after the 1371 times specified by the two components, respectively. CAs conforming 1372 to this profile MUST NOT generate certificates with private key usage 1373 period extensions unless at least one of the two components is 1374 present. 1376 Where used, notBefore and notAfter are represented as GeneralizedTime 1377 and MUST be specified and interpreted as defined in section 1378 4.1.2.5.2. 1380 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 1382 PrivateKeyUsagePeriod ::= SEQUENCE { 1383 notBefore [0] GeneralizedTime OPTIONAL, 1384 notAfter [1] GeneralizedTime OPTIONAL } 1386 4.2.1.5 Certificate Policies 1388 The certificate policies extension contains a sequence of one or more 1389 policy information terms, each of which consists of an object 1390 identifier (OID) and optional qualifiers. Optional qualifiers, which 1391 MAY be present, are not expected to change the definition of the 1392 policy. 1394 In an end entity certificate, these policy information terms indicate 1395 the policy under which the certificate has been issued and the 1396 purposes for which the certificate may be used. In a CA certificate, 1397 these policy information terms limit the set of policies for 1398 certification paths which include this certificate. When a CA does 1399 not wish to limit the set of policies for certification paths which 1400 include this certificate, they MAY assert the special policy 1401 anyPolicy, with a value of { 2 5 29 32 0 }. 1403 Applications with specific policy requirements are expected to have a 1404 list of those policies which they will accept and to compare the 1405 policy OIDs in the certificate to that list. If this extension is 1406 critical, the path validation software MUST be able to interpret this 1407 extension (including the optional qualifier), or MUST reject the 1408 certificate. 1410 To promote interoperability, this profile RECOMMENDS that policy 1411 information terms consist of only an OID. Where an OID alone is 1412 insufficient, this profile strongly recommends that use of qualifiers 1413 be limited to those identified in this section. When qualifiers are 1414 used with the special policy anyPolicy, they MUST be limited to the 1415 qualifiers identified in this section. 1417 This specification defines two policy qualifier types for use by 1418 certificate policy writers and certificate issuers. The qualifier 1419 types are the CPS Pointer and User Notice qualifiers. 1421 The CPS Pointer qualifier contains a pointer to a Certification 1422 Practice Statement (CPS) published by the CA. The pointer is in the 1423 form of a URI. Processing requirements for this qualifier are a 1424 local matter. No action is mandated by this specification regardless 1425 of the criticality value asserted for the extension. 1427 User notice is intended for display to a relying party when a 1428 certificate is used. The application software SHOULD display all 1429 user notices in all certificates of the certification path used, 1430 except that if a notice is duplicated only one copy need be 1431 displayed. To prevent such duplication, this qualifier SHOULD only 1432 be present in end entity certificates and CA certificates issued to 1433 other organizations. 1435 The user notice has two optional fields: the noticeRef field and the 1436 explicitText field. 1438 The noticeRef field, if used, names an organization and 1439 identifies, by number, a particular textual statement prepared by 1440 that organization. For example, it might identify the 1441 organization "CertsRUs" and notice number 1. In a typical 1442 implementation, the application software will have a notice file 1443 containing the current set of notices for CertsRUs; the 1444 application will extract the notice text from the file and display 1445 it. Messages MAY be multilingual, allowing the software to select 1446 the particular language message for its own environment. 1448 An explicitText field includes the textual statement directly in 1449 the certificate. The explicitText field is a string with a 1450 maximum size of 200 characters. 1452 If both the noticeRef and explicitText options are included in the 1453 one qualifier and if the application software can locate the notice 1454 text indicated by the noticeRef option then that text SHOULD be 1455 displayed; otherwise, the explicitText string SHOULD be displayed. 1457 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 1458 anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificate-policies 0 } 1460 certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 1462 PolicyInformation ::= SEQUENCE { 1463 policyIdentifier CertPolicyId, 1464 policyQualifiers SEQUENCE SIZE (1..MAX) OF 1465 PolicyQualifierInfo OPTIONAL } 1467 CertPolicyId ::= OBJECT IDENTIFIER 1469 PolicyQualifierInfo ::= SEQUENCE { 1470 policyQualifierId PolicyQualifierId, 1471 qualifier ANY DEFINED BY policyQualifierId } 1473 -- policyQualifierIds for Internet policy qualifiers 1475 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 1476 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 1477 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 1479 PolicyQualifierId ::= 1480 OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) 1482 Qualifier ::= CHOICE { 1483 cPSuri CPSuri, 1484 userNotice UserNotice } 1486 CPSuri ::= IA5String 1488 UserNotice ::= SEQUENCE { 1489 noticeRef NoticeReference OPTIONAL, 1490 explicitText DisplayText OPTIONAL} 1492 NoticeReference ::= SEQUENCE { 1493 organization DisplayText, 1494 noticeNumbers SEQUENCE OF INTEGER } 1496 DisplayText ::= CHOICE { 1497 ia5String IA5String (SIZE (1..200)), 1498 visibleString VisibleString (SIZE (1..200)), 1499 bmpString BMPString (SIZE (1..200)), 1500 utf8String UTF8String (SIZE (1..200)) } 1502 4.2.1.6 Policy Mappings 1504 This extension is used in CA certificates. It lists one or more 1505 pairs of OIDs; each pair includes an issuerDomainPolicy and a 1506 subjectDomainPolicy. The pairing indicates the issuing CA considers 1507 its issuerDomainPolicy equivalent to the subject CA's 1508 subjectDomainPolicy. 1510 The issuing CA's users might accept an issuerDomainPolicy for certain 1511 applications. The policy mapping defines the list of policies 1512 associated with the subject CA that may be accepted as comparable to 1513 the issuerDomainPolicy. 1515 Each issuerDomainPolicy named in the policy mapping extension SHOULD 1516 also be asserted in a certificate policies extension in the same 1517 certificate. Policies SHOULD NOT be mapped either to or from the 1518 special value anyPolicy (section 4.2.1.5). 1520 This extension MAY be supported by CAs and/or applications, and it 1521 MUST be non-critical. 1523 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 1525 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 1526 issuerDomainPolicy CertPolicyId, 1527 subjectDomainPolicy CertPolicyId } 1529 4.2.1.7 Subject Alternative Name 1531 The subject alternative names extension allows additional identities 1532 to be bound to the subject of the certificate. Defined options 1533 include an Internet electronic mail address, a DNS name, an IP 1534 address, and a uniform resource identifier (URI). Other options 1535 exist, including completely local definitions. Multiple name forms, 1536 and multiple instances of each name form, MAY be included. Whenever 1537 such identities are to be bound into a certificate, the subject 1538 alternative name (or issuer alternative name) extension MUST be used; 1539 however, a DNS name MAY be represented in the subject field using the 1540 domainComponent attribute as described in section 4.1.2.4. 1542 Because the subject alternative name is considered to be definitively 1543 bound to the public key, all parts of the subject alternative name 1544 MUST be verified by the CA. 1546 Further, if the only subject identity included in the certificate is 1547 an alternative name form (e.g., an electronic mail address), then the 1548 subject distinguished name MUST be empty (an empty sequence), and the 1549 subjectAltName extension MUST be present. If the subject field 1550 contains an empty sequence, the subjectAltName extension MUST be 1551 marked critical. 1553 When the subjectAltName extension contains an Internet mail address, 1554 the address MUST be included as an rfc822Name. The format of an 1555 rfc822Name is an "addr-spec" as defined in RFC 822 [RFC 822]. An 1556 addr-spec has the form "local-part@domain". Note that an addr-spec 1557 has no phrase (such as a common name) before it, has no comment (text 1558 surrounded in parentheses) after it, and is not surrounded by "<" and 1559 ">". Note that while upper and lower case letters are allowed in an 1560 RFC 822 addr-spec, no significance is attached to the case. 1562 When the subjectAltName extension contains a iPAddress, the address 1563 MUST be stored in the octet string in "network byte order," as 1564 specified in RFC 791 [RFC 791]. The least significant bit (LSB) of 1565 each octet is the LSB of the corresponding byte in the network 1566 address. For IP Version 4, as specified in RFC 791, the octet string 1567 MUST contain exactly four octets. For IP Version 6, as specified in 1568 RFC 1883, the octet string MUST contain exactly sixteen octets [RFC 1569 1883]. 1571 When the subjectAltName extension contains a domain name service 1572 label, the domain name MUST be stored in the dNSName (an IA5String). 1573 The name MUST be in the "preferred name syntax," as specified by RFC 1574 1034 [RFC 1034]. Note that while upper and lower case letters are 1575 allowed in domain names, no signifigance is attached to the case. In 1576 addition, while the string " " is a legal domain name, subjectAltName 1577 extensions with a dNSName " " are not permitted. Finally, the use of 1578 the DNS representation for Internet mail addresses (wpolk.nist.gov 1579 instead of wpolk@nist.gov) MUST NOT be used; such identities are to 1580 be encoded as rfc822Name. 1582 Note: work is currently underway to specify domain names in 1583 international character sets. This names will likely not be 1584 accomodated by IA5String. Once this work is complete, this profile 1585 will be revisited and the appropriate functionality will be added. 1587 When the subjectAltName extension contains a URI, the name MUST be 1588 stored in the uniformResourceIdentifier (an IA5String). The name 1589 MUST NOT be a relative URL, and it MUST follow the URL syntax and 1590 encoding rules specified in [RFC 1738]. The name MUST include both a 1591 scheme (e.g., "http" or "ftp") and a scheme-specific-part. The 1592 scheme-specific-part MUST include a fully qualified domain name or IP 1593 address as the host. 1595 As specified in [RFC 1738], the scheme name is not case-sensitive 1596 (e.g., "http" is equivalent to "HTTP"). The host part is also not 1597 case-sensitive, but other components of the scheme-specific-part may 1598 be case-sensitive. When comparing URIs, conforming implementations 1599 MUST compare the scheme and host without regard to case, but assume 1600 the remainder of the scheme-specific-part is case sensitive. 1602 When the subjectAltName extension contains a DN in the directoryName, 1603 the DN MUST be unique for each subject entity certified by the one CA 1604 as defined by the issuer name field. A CA MAY issue more than one 1605 certificate with the same DN to the same subject entity. 1607 The subjectAltName MAY carry additional name types through the use of 1608 the otherName field. The format and semantics of the name are 1609 indicated through the OBJECT IDENTIFIER in the type-id field. The 1610 name itself is conveyed as value field in otherName. For example, 1611 Kerberos [RFC 1510] format names can be encoded into the otherName, 1612 using using a Kerberos 5 principal name OID and a SEQUENCE of the 1613 Realm and the PrincipalName. 1615 Subject alternative names MAY be constrained in the same manner as 1616 subject distinguished names using the name constraints extension as 1617 described in section 4.2.1.11. 1619 If the subjectAltName extension is present, the sequence MUST contain 1620 at least one entry. Unlike the subject field, conforming CAs MUST 1621 NOT issue certificates with subjectAltNames containing empty 1622 GeneralName fields. For example, an rfc822Name is represented as an 1623 IA5String. While an empty string is a valid IA5String, such an 1624 rfc822Name is not permitted by this profile. The behavior of clients 1625 that encounter such a certificate when processing a certificication 1626 path is not defined by this profile. 1628 Finally, the semantics of subject alternative names that include 1629 wildcard characters (e.g., as a placeholder for a set of names) are 1630 not addressed by this specification. Applications with specific 1631 requirements MAY use such names, but they MUST define the semantics. 1633 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 1635 SubjectAltName ::= GeneralNames 1637 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 1639 GeneralName ::= CHOICE { 1640 otherName [0] OtherName, 1641 rfc822Name [1] IA5String, 1642 dNSName [2] IA5String, 1643 x400Address [3] ORAddress, 1644 directoryName [4] Name, 1645 ediPartyName [5] EDIPartyName, 1646 uniformResourceIdentifier [6] IA5String, 1647 iPAddress [7] OCTET STRING, 1648 registeredID [8] OBJECT IDENTIFIER} 1650 OtherName ::= SEQUENCE { 1651 type-id OBJECT IDENTIFIER, 1652 value [0] EXPLICIT ANY DEFINED BY type-id } 1654 EDIPartyName ::= SEQUENCE { 1655 nameAssigner [0] DirectoryString OPTIONAL, 1656 partyName [1] DirectoryString } 1658 4.2.1.8 Issuer Alternative Names 1660 As with 4.2.1.7, this extension is used to associate Internet style 1661 identities with the certificate issuer. Issuer alternative names MUST 1662 be encoded as in 4.2.1.7. 1664 Where present, this extension SHOULD NOT be marked critical. 1666 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 1668 IssuerAltName ::= GeneralNames 1670 4.2.1.9 Subject Directory Attributes 1672 The subject directory attributes extension is used to convey 1673 identification attributes (e.g., nationality) of the subject. The 1674 extension is defined as a sequence of one or more attributes. This 1675 extension MUST be non-critical. 1677 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 1679 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 1681 4.2.1.10 Basic Constraints 1683 The basic constraints extension identifies whether the subject of the 1684 certificate is a CA and the maximum depth of valid certification 1685 paths that include this certificate. 1687 The cA boolean indicates whether the certified public key belongs to 1688 a CA. If the cA boolean is not asserted, then the keyCertSign bit in 1689 the key usage extension MUST NOT be asserted. 1691 The pathLenConstraint field is meaningful only if the cA boolean is 1692 asserted and the key usage extension asserts the keyCertSign bit 1693 (section 4.2.1.3). In this case, it gives the maximum number of non- 1694 self-issued intermediate certificates that may follow this 1695 certificate in a valid certification path. A certificate is self- 1696 issued if the DNs that appear in the subject and issuer fields are 1697 identical and are not empty. (Note: The last certificate in the 1698 certification path is not an intermediate certificate, and is not 1699 included in this limit. Usually, the last certificate is an end 1700 entity certificate, but it can be a CA certificate.) A 1701 pathLenConstraint of zero indicates that only one more certificate 1702 may follow in a valid certification path. Where it appears, the 1703 pathLenConstraint field MUST be greater than or equal to zero. Where 1704 pathLenConstraint does not appear, no limit is imposed. 1706 This extension MUST appear as a critical extension in all CA 1707 certificates that contain public keys used to validate digital 1708 signatures on certificates. This extension MAY appear as a critical 1709 or non-critical extension in CA certificates that contain public keys 1710 used exclusively for purposes other than validating digital 1711 signatures on certificates. Such CA certificates include ones that 1712 contain public keys used exclusively for validating digital 1713 signatures on CRLs and ones that contain key management public keys 1714 used with certificate enrollment protocols. This extension MAY 1715 appear as a critical or non-critical extension in end entity 1716 certificates. 1718 CAs MUST NOT include the pathLenConstraint field unless the cA 1719 boolean is asserted and the key usage extension asserts the 1720 keyCertSign bit. 1722 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 1724 BasicConstraints ::= SEQUENCE { 1725 cA BOOLEAN DEFAULT FALSE, 1726 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 1728 4.2.1.11 Name Constraints 1730 The name constraints extension, which MUST be used only in a CA 1731 certificate, indicates a name space within which all subject names in 1732 subsequent certificates in a certification path MUST be located. 1733 Restrictions apply to the subject distinguished name and apply to 1734 subject alternative names. Restrictions apply only when the 1735 specified name form is present. If no name of the type is in the 1736 certificate, the certificate is acceptable. 1738 Name constraints are not applied to certificates whose issuer and 1739 subject are identical (unless the certificate is the final 1740 certificate in the path). (This could prevent CAs that use name 1741 constraints from employing self-issued certificates to implement key 1742 rollover.) 1744 Restrictions are defined in terms of permitted or excluded name 1745 subtrees. Any name matching a restriction in the excludedSubtrees 1746 field is invalid regardless of information appearing in the 1747 permittedSubtrees. This extension MUST be critical. 1749 Within this profile, the minimum and maximum fields are not used with 1750 any name forms, thus minimum is always zero, and maximum is always 1751 absent. 1753 For URIs, the constraint applies to the host part of the name. The 1754 constraint MAY specify a host or a domain. Examples would be 1755 "foo.bar.com"; and ".xyz.com". When the the constraint begins with 1756 a period, it MAY be expanded with one or more subdomains. That is, 1757 the constraint ".xyz.com" is satisfied by both abc.xyz.com and 1758 abc.def.xyz.com. However, the constraint ".xyz.com" is not satisfied 1759 by "xyz.com". When the constraint does not begin with a period, it 1760 specifies a host. 1762 A name constraint for Internet mail addresses MAY specify a 1763 particular mailbox, all addresses at a particular host, or all 1764 mailboxes in a domain. To indicate a particular mailbox, the 1765 constraint is the complete mail address. For example, "root@xyz.com" 1766 indicates the root mailbox on the host "xyz.com". To indicate all 1767 Internet mail addresses on a particular host, the constraint is 1768 specified as the host name. For example, the constraint "xyz.com" is 1769 satisfied by any mail address at the host "xyz.com". To specify any 1770 address within a domain, the constraint is specified with a leading 1771 period (as with URIs). For example, ".xyz.com" indicates all the 1772 Internet mail addresses in the domain "xyz.com", but not Internet 1773 mail addresses on the host "xyz.com". 1775 DNS name restrictions are expressed as foo.bar.com. Any DNS name that 1776 can be constructed by simply adding to the left hand side of the name 1777 satisfies the name constraint. For example, www.foo.bar.com would 1778 satisfy the constraint but foo1.bar.com would not. 1780 Legacy implementations exist where an RFC 822 name is embedded in the 1781 subject distinguished name in an attribute of type EmailAddress 1782 (section 4.1.2.6). When rfc822 names are constrained, but the 1783 certificate does not include a subject alternative name, the rfc822 1784 name constraint MUST be applied to the attribute of type EmailAddress 1785 in the subject distinguished name. The ASN.1 syntax for EmailAddress 1786 and the corresponding OID are supplied in Appendix A. 1788 Restrictions of the form directoryName MUST be applied to the subject 1789 field in the certificate and to the subjectAltName extensions of type 1790 directoryName. Restrictions of the form x400Address MUST be applied 1791 to subjectAltName extensions of type x400Address. 1793 When applying restrictions of the form directoryName, an 1794 implementation MUST compare DN attributes. At a minimum, 1795 implementations MUST perform the DN comparison rules specified in 1796 Section 4.1.2.4. CAs issuing certificates with a restriction of the 1797 form directoryName SHOULD NOT rely on implementation of the full ISO 1798 DN name comparison algorithm. This implies name restrictions MUST be 1799 stated identically to the encoding used in the subject field or 1800 subjectAltName extension. 1802 The syntax of iPAddress MUST be as described in section 4.2.1.7 with 1803 the following additions specifically for Name Constraints. For IPv4 1804 addresses, the ipAddress field of generalName MUST contain eight (8) 1805 octets, encoded in the style of RFC 1519 (CIDR) to represent an 1806 address range.[RFC 1519] For IPv6 addresses, the ipAddress field 1807 MUST contain 32 octets similarly encoded. For example, a name 1808 constraint for "class C" subnet 10.9.8.0 is represented as the octets 1809 0A 09 08 00 FF FF FF 00, representing the CIDR notation 1810 10.9.8.0/255.255.255.0. 1812 The syntax and semantics for name constraints for otherName, 1813 ediPartyName, and registeredID are not defined by this specification. 1815 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 1817 NameConstraints ::= SEQUENCE { 1818 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 1819 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 1821 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 1823 GeneralSubtree ::= SEQUENCE { 1824 base GeneralName, 1825 minimum [0] BaseDistance DEFAULT 0, 1826 maximum [1] BaseDistance OPTIONAL } 1828 BaseDistance ::= INTEGER (0..MAX) 1830 4.2.1.12 Policy Constraints 1832 The policy constraints extension can be used in certificates issued 1833 to CAs. The policy constraints extension constrains path validation 1834 in two ways. It can be used to prohibit policy mapping or require 1835 that each certificate in a path contain an acceptable policy 1836 identifier. 1838 If the inhibitPolicyMapping field is present, the value indicates the 1839 number of additional certificates that may appear in the path before 1840 policy mapping is no longer permitted. For example, a value of one 1841 indicates that policy mapping may be processed in certificates issued 1842 by the subject of this certificate, but not in additional 1843 certificates in the path. 1845 If the requireExplicitPolicy field is present, subsequent 1846 certificates MUST include an acceptable policy identifier. The value 1847 of requireExplicitPolicy indicates the number of additional 1848 certificates that may appear in the path before an explicit policy is 1849 required. An acceptable policy identifier is the identifier of a 1850 policy required by the user of the certification path or the 1851 identifier of a policy which has been declared equivalent through 1852 policy mapping. 1854 Conforming CAs MUST NOT issue certificates where policy constraints 1855 is a empty sequence. That is, at least one of the 1856 inhibitPolicyMapping field or the requireExplicitPolicy field MUST be 1857 present. The behavior of clients that encounter a empty policy 1858 constraints field is not addressed in this profile. 1860 This extension MAY be critical or non-critical. 1862 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } 1864 PolicyConstraints ::= SEQUENCE { 1865 requireExplicitPolicy [0] SkipCerts OPTIONAL, 1866 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 1868 SkipCerts ::= INTEGER (0..MAX) 1870 4.2.1.13 Extended key usage field 1872 This field indicates one or more purposes for which the certified 1873 public key may be used, in addition to or in place of the basic 1874 purposes indicated in the key usage extension field. In general, 1875 this extension will appear only in end entity certificates. This 1876 field is defined as follows: 1878 id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 } 1880 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 1882 KeyPurposeId ::= OBJECT IDENTIFIER 1884 Key purposes may be defined by any organization with a need. Object 1885 identifiers used to identify key purposes MUST be assigned in 1886 accordance with IANA or ITU-T Recommendation X.660. [X.660] 1888 This extension MAY, at the option of the certificate issuer, be 1889 either critical or non-critical. 1891 If the extension is flagged critical, then the certificate MUST only 1892 be used for one of the purposes indicated. If multiple purposes are 1893 indicated the application need not recognize all purposes indicated, 1894 as long as the intended purpose is present and recognized. 1896 If the extension is flagged non-critical, then it indicates the 1897 intended purpose or purposes of the key, and MAY be used in finding 1898 the correct key/certificate of an entity that has multiple 1899 keys/certificates. It is an advisory field and does not imply that 1900 usage of the key is restricted by the certification authority to the 1901 purpose indicated. Certificate using applications MAY nevertheless 1902 require that a particular purpose be indicated in order for the 1903 certificate to be acceptable to that application. 1905 If a certificate contains both a critical key usage field and a 1906 critical extended key usage field, then both fields MUST be processed 1907 independently and the certificate MUST only be used for a purpose 1908 consistent with both fields. If there is no purpose consistent with 1909 both fields, then the certificate MUST NOT be used for any purpose. 1911 The following key usage purposes are defined by this profile: 1913 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 1915 id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } 1916 -- TLS WWW server authentication 1917 -- Key usage bits that may be consistent: digitalSignature, 1918 -- keyEncipherment or keyAgreement 1920 id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } 1921 -- TLS WWW client authentication 1922 -- Key usage bits that may be consistent: digitalSignature 1923 -- and/or keyAgreement 1925 id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } 1926 -- Signing of downloadable executable code 1927 -- Key usage bits that may be consistent: digitalSignature 1929 id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } 1930 -- E-mail protection 1931 -- Key usage bits that may be consistent: digitalSignature, 1932 -- nonRepudiation, and/or (keyEncipherment or keyAgreement) 1934 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 1935 -- Binding the hash of an object to a time 1936 -- Key usage bits that may be consistent: digitalSignature 1937 -- and/or nonRepudiation 1938 id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 } 1939 -- Signing OCSP responses 1940 -- Key usage bits that may be consistent: digitalSignature 1941 -- and/or nonRepudiation 1943 4.2.1.14 CRL Distribution Points 1945 The CRL distribution points extension identifies how CRL information 1946 is obtained. The extension SHOULD be non-critical, but this profile 1947 RECOMMENDS support for this extension by CAs and applications. 1948 Further discussion of CRL management is contained in section 5. 1950 The cRLDistributionPoints extension is a SEQUENCE of 1951 DistributionPoint. A DistributionPoint consists of three fields, 1952 each of which is optional: distributionPoint, reasons, and cRLIssuer. 1953 While each of these fields is optional, a DistributionPoint MUST NOT 1954 consist of only the reasons field; either distributionPoint or 1955 cRLIssuer MUST be present. If the certificate issuer is not the CRL 1956 issuer, then the cRLIssuer field MUST be present and contain the Name 1957 of the CRL issuer. If the certificate issuer is also the CRL issuer, 1958 then the cRLIssuer field MUST be omitted and the distributionPoint 1959 field MUST be present. If the the distributionPoint field is 1960 omitted, cRLIssuer MUST be present and include a Name corresponding 1961 to an X.500 or LDAP directory entry where the CRL is located. 1963 When the distributionPoint field is present, it contains either a 1964 SEQUENCE of general names or a single value, nameRelativeToCRLIssuer. 1965 If the cRLDistributionPoints extension contains a general name of 1966 type URI, the following semantics MUST be assumed: the URI is a 1967 pointer to the current CRL for the associated reasons and will be 1968 issued by the associated cRLIssuer. The expected values for the URI 1969 are those defined in 4.2.1.7. Processing rules for other values are 1970 not defined by this specification. 1972 If the DistributionPointName contains multiple values, each name 1973 describes a different mechanism to obtain the same CRL. For example, 1974 the same CRL could be available for retrieval through both LDAP and 1975 HTTP. 1977 If the DistributionPointName contains the single value 1978 nameRelativeToCRLIssuer, the value provides a distinguished name 1979 fragment. The fragment is appended to the X.500 distinguished name 1980 of the CRL issuer to obtain the distribution point name. If the 1981 cRLIssuer field in the DistributionPoint is present, then the name 1982 fragment is appended to the distinguished name that it contains; 1983 otherwise, the name fragment is appended to the certificate issuer 1984 distinguished name. The DistributionPointName MUST NOT use the 1985 nameRealtiveToCRLIssuer alternative when cRLIssuer contains more than 1986 one distinguished name. 1988 If the DistributionPoint omits the reasons field, the CRL MUST 1989 include revocation information for all reasons. 1991 The cRLIssuer identifies the entity who signs and issues the CRL. If 1992 present, the cRLIssuer MUST contain at least one an X.500 1993 distinguished name (DN), and MAY also contain other name forms. 1994 Since the cRLIssuer is compared to the CRL issuer name, the X.501 1995 type Name MUST follow the encoding rules for the issuer name field in 1996 the certificate (section 4.1.2.4). 1998 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 } 2000 CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 2002 DistributionPoint ::= SEQUENCE { 2003 distributionPoint [0] DistributionPointName OPTIONAL, 2004 reasons [1] ReasonFlags OPTIONAL, 2005 cRLIssuer [2] GeneralNames OPTIONAL } 2007 DistributionPointName ::= CHOICE { 2008 fullName [0] GeneralNames, 2009 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 2011 ReasonFlags ::= BIT STRING { 2012 unused (0), 2013 keyCompromise (1), 2014 cACompromise (2), 2015 affiliationChanged (3), 2016 superseded (4), 2017 cessationOfOperation (5), 2018 certificateHold (6), 2019 privilegeWithdrawn (7), 2020 aACompromise (8) } 2022 4.2.1.15 Inhibit Any-Policy 2024 The inhibit any-policy extension can be used in certificates issued 2025 to CAs. The inhibit any-policy indicates that the special any-policy 2026 OID, with the value { 2 5 29 32 0 }, is not considered an explicit 2027 match for other certificate policies. The value indicates the number 2028 of additional certificates that may appear in the path before any- 2029 policy is no longer permitted. For example, a value of one indicates 2030 that any-policy may be processed in certificates issued by the 2031 subject of this certificate, but not in additional certificates in 2032 the path. 2034 This extension MUST be critical. 2036 id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 } 2038 InhibitAnyPolicy ::= SkipCerts 2040 SkipCerts ::= INTEGER (0..MAX) 2042 4.2.1.16 Freshest CRL (a.k.a. Delta CRL Distribution Point) 2044 The freshest CRL extension identifies how delta CRL information is 2045 obtained. The extension MUST be non-critical. Further discussion of 2046 CRL management is contained in section 5. 2048 The same syntax is used for this extension and the 2049 cRLDistributionPoints extension, and is described in section 2050 4.2.1.14. The same conventions apply to both extensions. 2052 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } 2054 FreshestCRL ::= CRLDistributionPoints 2056 4.2.2 Private Internet Extensions 2058 This section defines two extensions for use in the Internet Public 2059 Key Infrastructure. These extensions may be used to direct 2060 applications to on-line information about the issuing CA or the 2061 subject. As the information may be available in multiple forms, each 2062 extension is a sequence of IA5String values, each of which represents 2063 a URI. The URI implicitly specifies the location and format of the 2064 information and the method for obtaining the information. 2066 An object identifier is defined for the private extension. The 2067 object identifier associated with the private extension is defined 2068 under the arc id-pe within the arc id-pkix. Any future extensions 2069 defined for the Internet PKI are also expected to be defined under 2070 the arc id-pe. 2072 id-pkix OBJECT IDENTIFIER ::= 2073 { iso(1) identified-organization(3) dod(6) internet(1) 2074 security(5) mechanisms(5) pkix(7) } 2076 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 2078 4.2.2.1 Authority Information Access 2080 The authority information access extension indicates how to access CA 2081 information and services for the issuer of the certificate in which 2082 the extension appears. Information and services may include on-line 2083 validation services and CA policy data. (The location of CRLs is not 2084 specified in this extension; that information is provided by the 2085 cRLDistributionPoints extension.) This extension may be included in 2086 subject or CA certificates, and it MUST be non-critical. 2088 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 2090 AuthorityInfoAccessSyntax ::= 2091 SEQUENCE SIZE (1..MAX) OF AccessDescription 2093 AccessDescription ::= SEQUENCE { 2094 accessMethod OBJECT IDENTIFIER, 2095 accessLocation GeneralName } 2097 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 2099 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 2101 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 2103 Each entry in the sequence AuthorityInfoAccessSyntax describes the 2104 format and location of additional information provided by the CA who 2105 issued the certificate in which this extension appears. The type and 2106 format of the information is specified by the accessMethod field; the 2107 accessLocation field specifies the location of the information. The 2108 retrieval mechanism may be implied by the accessMethod or specified 2109 by accessLocation. 2111 This profile defines two accessMethod OIDs: id-ad-caIssuers and id- 2112 ad-ocsp. 2114 The id-ad-caIssuers OID is used when the additional information lists 2115 CAs that have issued certificates superior to the CA that issued the 2116 certificate containing this extension. The referenced CA Issuers 2117 description is intended to aid certificate users in the selection of 2118 a certification path that terminates at a point trusted by the 2119 certificate user. 2121 When id-ad-caIssuers appears as accessMethod, the accessLocation 2122 field describes the referenced description server and the access 2123 protocol to obtain the referenced description. The accessLocation 2124 field is defined as a GeneralName, which can take several forms. 2125 Where the information is available via http, ftp, or ldap, 2126 accessLocation MUST be a uniformResourceIdentifier. Where the 2127 information is available via the Directory Access Protocol (DAP), 2128 accessLocation MUST be a directoryName. When the information is 2129 available via electronic mail, accessLocation MUST be an rfc822Name. 2131 The semantics of other id-ad-caIssuers accessLocation name forms are 2132 not defined. 2134 The id-ad-ocsp OID is used when revocation information for the 2135 certificate containing this extension is available using the Online 2136 Certificate Status Protocol (OCSP) [RFC 2560]. 2138 When id-ad-ocsp appears as accessMethod, the accessLocation field is 2139 the location of the OCSP responder, using the conventions defined in 2140 [RFC 2560]. 2142 [RFC 2560] defines the access descriptor for the Online Certificate 2143 Status Protocol. When this access descriptor appears in the 2144 authority information access extension, this indicates the issuer 2145 provides revocation information for this certificate through the 2146 named OCSP service. Additional access descriptors may be defined in 2147 other PKIX specifications. 2149 4.2.2.2 Subject Information Access 2151 The subject information access extension indicates how to access 2152 information and services for the subject of the certificate in which 2153 the extension appears. When the subject is a CA, information and 2154 services may include certificate validation services and CA policy 2155 data. When the subject is an end entity, the information describes 2156 the type of services offered and how to access them. In this case, 2157 the contents of this extension are defined in the protocol 2158 specifications for the suported services. This extension may be 2159 included in subject or CA certificates, and it MUST be non-critical. 2161 id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 } 2163 SubjectInfoAccessSyntax ::= 2164 SEQUENCE SIZE (1..MAX) OF AccessDescription 2166 AccessDescription ::= SEQUENCE { 2167 accessMethod OBJECT IDENTIFIER, 2168 accessLocation GeneralName } 2170 Each entry in the sequence SubjectInfoAccessSyntax describes the 2171 format and location of additional information provided by the subject 2172 of the certificate in which this extension appears. The type and 2173 format of the information is specified by the accessMethod field; the 2174 accessLocation field specifies the location of the information. The 2175 retrieval mechanism may be implied by the accessMethod or specified 2176 by accessLocation. 2178 This profile defines one access method to be used when the subject is 2179 a CA, and one access method to be used when the subject is an end 2180 entity. Additional access methods may be defined in the future in 2181 the protocol specifications for other services. 2183 The id-ad-caRepository OID is used when the subject is a CA, and 2184 publishes its certificates and CRLs (if issued) in a repository. The 2185 accessLocation field is defined as a GeneralName, which can take 2186 several forms. Where the information is available via http, ftp, or 2187 ldap, accessLocation MUST be a uniformResourceIdentifier. Where the 2188 information is available via the directory access protocol (dap), 2189 accessLocation MUST be a directoryName. When the information is 2190 available via electronic mail, accessLocation MUST be an rfc822Name. 2191 The semantics of other name forms of of accessLocation (when 2192 accessMethod is id-ad-caRepository) are not defined by this 2193 specification. 2195 The id-ad-timeStamping OID is used when the subject offers 2196 timestamping services using the Time Stamp Protocol defined in 2197 [PKIXTSA]. Where the timestamping services are available via http or 2198 ftp, accessLocation MUST be a uniformResourceIdentifier. Where the 2199 timestamping services are available via electronic mail, 2200 accessLocation MUST be an rfc822Name. Where timestamping services 2201 are available using TCP/IP, the dNSName or ipAddress name forms may 2202 be used. The semantics of other name forms of accessLocation (when 2203 accessMethod is id-ad-timeStamping) are not defined by this 2204 specification. 2206 Additional access descriptors may be defined in other PKIX 2207 specifications. 2209 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 2211 id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 } 2213 id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 } 2215 5 CRL and CRL Extensions Profile 2217 As discussed above, one goal of this X.509 v2 CRL profile is to 2218 foster the creation of an interoperable and reusable Internet PKI. 2219 To achieve this goal, guidelines for the use of extensions are 2220 specified, and some assumptions are made about the nature of 2221 information included in the CRL. 2223 CRLs may be used in a wide range of applications and environments 2224 covering a broad spectrum of interoperability goals and an even 2225 broader spectrum of operational and assurance requirements. This 2226 profile establishes a common baseline for generic applications 2227 requiring broad interoperability. The profile defines a set of 2228 information that can be expected in every CRL. Also, the profile 2229 defines common locations within the CRL for frequently used 2230 attributes as well as common representations for these attributes. 2232 CRL issuers issue CRLs. In general, the CRL issuer is the CA. CAs 2233 publish CRLs to provide status information about the certificates 2234 they issued. However, a CA may delegate this responsibility to 2235 another trusted authority. Whenever the CRL issuer is not the CA 2236 that issued the certificates, the CRL is referred to as an indirect 2237 CRL. 2239 Each CRL has a particular scope. The CRL scope is the set of 2240 certificates that could appear on a given CRL. For example, the 2241 scope could be "all certificates issued by CA X", "all CA 2242 certificates issued by CA X", "all certificates issued by CA X that 2243 have been revoked for reasons of key compromise and CA compromise", 2244 or could be a set of certificates based on arbitrary local 2245 information, such as "all certificates issued to the NIST employees 2246 located in Boulder". 2248 A complete CRL lists all unexpired certificates, within its scope, 2249 that have been revoked for one of the revocation reasons covered by 2250 the CRL scope. The CRL issuer MAY also generate delta CRLs. A delta 2251 CRL only lists those certificates, within its scope, whose revocation 2252 status has changed since the issuance of a referenced complete CRL. 2253 The referenced complete CRL is referred to as a base CRL. The scope 2254 of a delta CRL MUST be the same as the base CRL that it references. 2256 This profile does not define any private Internet CRL extensions or 2257 CRL entry extensions. 2259 Environments with additional or special purpose requirements may 2260 build on this profile or may replace it. 2262 Conforming CAs are not required to issue CRLs if other revocation or 2263 certificate status mechanisms are provided. Conforming CAs that 2264 issue CRLs MUST issue version 2 CRLs, include the date by which the 2265 next CRL will be issued in the nextUpdate field (section 5.1.2.5), 2266 include the CRL number extension (section 5.2.3), and include the 2267 authority key identifier extension (section 5.2.1). Conforming 2268 applications that support CRLs are required to process both version 1 2269 and version 2 complete CRLs that provide revocation information for 2270 all certificates issued by one CA. Conforming applications are not 2271 required to support processing of delta CRLs, indirect CRLs, or CRLs 2272 with a scope other than all certificates issued by the CA. 2274 5.1 CRL Fields 2276 The X.509 v2 CRL syntax is as follows. For signature calculation, 2277 the data that is to be signed is ASN.1 DER encoded. ASN.1 DER 2278 encoding is a tag, length, value encoding system for each element. 2280 CertificateList ::= SEQUENCE { 2281 tbsCertList TBSCertList, 2282 signatureAlgorithm AlgorithmIdentifier, 2283 signatureValue BIT STRING } 2285 TBSCertList ::= SEQUENCE { 2286 version Version OPTIONAL, 2287 -- if present, MUST be v2 2288 signature AlgorithmIdentifier, 2289 issuer Name, 2290 thisUpdate Time, 2291 nextUpdate Time OPTIONAL, 2292 revokedCertificates SEQUENCE OF SEQUENCE { 2293 userCertificate CertificateSerialNumber, 2294 revocationDate Time, 2295 crlEntryExtensions Extensions OPTIONAL 2296 -- if present, MUST be v2 2297 } OPTIONAL, 2298 crlExtensions [0] EXPLICIT Extensions OPTIONAL 2299 -- if present, MUST be v2 2300 } 2302 -- Version, Time, CertificateSerialNumber, and Extensions 2303 -- are all defined in the ASN.1 in section 4.1 2305 -- AlgorithmIdentifier is defined in section 4.1.1.2 2307 The following items describe the use of the X.509 v2 CRL in the 2308 Internet PKI. 2310 5.1.1 CertificateList Fields 2312 The CertificateList is a SEQUENCE of three required fields. The 2313 fields are described in detail in the following subsections. 2315 5.1.1.1 tbsCertList 2317 The first field in the sequence is the tbsCertList. This field is 2318 itself a sequence containing the name of the issuer, issue date, 2319 issue date of the next list, the optional list of revoked 2320 certificates, and optional CRL extensions. When there are no revoked 2321 certificates, the revoked certificates list is absent. When one or 2322 more certificates are revoked, each entry on the revoked certificate 2323 list is defined by a sequence of user certificate serial number, 2324 revocation date, and optional CRL entry extensions. 2326 5.1.1.2 signatureAlgorithm 2328 The signatureAlgorithm field contains the algorithm identifier for 2329 the algorithm used by the CRL issuer to sign the CertificateList. 2330 The field is of type AlgorithmIdentifier, which is defined in section 2331 4.1.1.2. [PKIXALGS] lists the supported algorithms for this 2332 specification. Conforming CAs MUST use the algorithm identifiers 2333 presented in [PKIXALGS] when signing with a supported signature 2334 algorithm. 2336 This field MUST contain the same algorithm identifier as the 2337 signature field in the sequence tbsCertList (section 5.1.2.2). 2339 5.1.1.3 signatureValue 2341 The signatureValue field contains a digital signature computed upon 2342 the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded tbsCertList 2343 is used as the input to the signature function. This signature value 2344 is then ASN.1 encoded as a BIT STRING and included in the CRL's 2345 signatureValue field. The details of this process are specified for 2346 each of the supported algorithms in [PKIXALGS]. 2348 CAs that are also CRL issuers MAY use one private key to digitally 2349 sign certificates and CRLs, or MAY use separate private keys to 2350 digitally sign certificates and CRLs. When separate private keys are 2351 employed, each of the public keys associated with these private keys 2352 is placed in a separate certificate, one with the keyCertSign bit set 2353 in the key usage extension, and one with the cRLSign bit set in the 2354 key usage extension (section 4.2.1.3). When separate private keys 2355 are employed, certificates issued by the CA contain one authority key 2356 identifier, and the corresponding CRLs contain a different authority 2357 key identifier. The use of separate CA certificates for validation 2358 of certificate signatures and CRL signatures can offer improved 2359 security characteristics; however, it imposes a burden on 2360 applications, and it might limit interoperability. Many applications 2361 construct a certification path, and then validate the certification 2362 path (section 6). CRL checking in turn requires a separate 2363 certification path to be constructed and validated for the CA's CRL 2364 signature validation certificate. Applications that perform CRL 2365 checking MUST support certification path validation when certificates 2366 and CRLs are digitally signed with the same CA private key. These 2367 applications SHOULD support certification path validation when 2368 certificates and CRLs are digitally signed with different CA private 2369 keys. 2371 5.1.2 Certificate List "To Be Signed" 2373 The certificate list to be signed, or TBSCertList, is a SEQUENCE of 2374 required and optional fields. The required fields identify the CRL 2375 issuer, the algorithm used to sign the CRL, the date and time the CRL 2376 was issued, and the date and time by which the CRL issuer will issue 2377 the next CRL. 2379 Optional fields include lists of revoked certificates and CRL 2380 extensions. The revoked certificate list is optional to support the 2381 case where a CA has not revoked any unexpired certificates that it 2382 has issued. The profile requires conforming CRL issuers to use the 2383 CRL Number CRL extension in all CRLs issued. 2385 5.1.2.1 Version 2387 This optional field describes the version of the encoded CRL. When 2388 extensions are used, as required by this profile, this field MUST be 2389 present and MUST specify version 2 (the integer value is 1). 2391 5.1.2.2 Signature 2393 This field contains the algorithm identifier for the algorithm used 2394 to sign the CRL. [PKIXALGS] lists OIDs for the most popular 2395 signature algorithms used in the Internet PKI. 2397 This field MUST contain the same algorithm identifier as the 2398 signatureAlgorithm field in the sequence CertificateList (section 2399 5.1.1.2). 2401 5.1.2.3 Issuer Name 2403 The issuer name identifies the entity who has signed and issued the 2404 CRL. The issuer identity is carried in the issuer name field. 2405 Alternative name forms may also appear in the issuerAltName extension 2406 (section 5.2.2). The issuer name field MUST contain an X.500 2407 distinguished name (DN). The issuer name field is defined as the 2408 X.501 type Name, and MUST follow the encoding rules for the issuer 2409 name field in the certificate (section 4.1.2.4). 2411 5.1.2.4 This Update 2413 This field indicates the issue date of this CRL. ThisUpdate may be 2414 encoded as UTCTime or GeneralizedTime. 2416 CRL issuers conforming to this profile MUST encode thisUpdate as 2417 UTCTime for dates through the year 2049. CRL issuers conforming to 2418 this profile MUST encode thisUpdate as GeneralizedTime for dates in 2419 the year 2050 or later. 2421 Where encoded as UTCTime, thisUpdate MUST be specified and 2422 interpreted as defined in section 4.1.2.5.1. Where encoded as 2423 GeneralizedTime, thisUpdate MUST be specified and interpreted as 2424 defined in section 4.1.2.5.2. 2426 5.1.2.5 Next Update 2428 This field indicates the date by which the next CRL will be issued. 2429 The next CRL could be issued before the indicated date, but it will 2430 not be issued any later than the indicated date. CRL issuers SHOULD 2431 issue CRLs with a nextUpdate time equal to or later than all previous 2432 CRLs. nextUpdate may be encoded as UTCTime or GeneralizedTime. 2434 This profile requires inclusion of nextUpdate in all CRLs issued by 2435 conforming CRL issuers. Note that the ASN.1 syntax of TBSCertList 2436 describes this field as OPTIONAL, which is consistent with the ASN.1 2437 structure defined in [X.509]. The behavior of clients processing CRLs 2438 which omit nextUpdate is not specified by this profile. 2440 CRL issuers conforming to this profile MUST encode nextUpdate as 2441 UTCTime for dates through the year 2049. CRL issuers conforming to 2442 this profile MUST encode nextUpdate as GeneralizedTime for dates in 2443 the year 2050 or later. 2445 Where encoded as UTCTime, nextUpdate MUST be specified and 2446 interpreted as defined in section 4.1.2.5.1. Where encoded as 2447 GeneralizedTime, nextUpdate MUST be specified and interpreted as 2448 defined in section 4.1.2.5.2. 2450 5.1.2.6 Revoked Certificates 2452 When there are no revoked certificates, the revoked certificates list 2453 is absent. Otherwise, revoked certificates are listed by their 2454 serial numbers. Certificates revoked by the CA are uniquely 2455 identified by the certificate serial number. The date on which the 2456 revocation occurred is specified. The time for revocationDate MUST 2457 be expressed as described in section 5.1.2.4. Additional information 2458 may be supplied in CRL entry extensions; CRL entry extensions are 2459 discussed in section 5.3. 2461 5.1.2.7 Extensions 2463 This field may only appear if the version is 2 (section 5.1.2.1). If 2464 present, this field is a SEQUENCE of one or more CRL extensions. CRL 2465 extensions are discussed in section 5.2. 2467 5.2 CRL Extensions 2469 The extensions defined by ANSI X9 and ISO/IEC/ITU for X.509 v2 CRLs 2470 [X.509] [X9.55] provide methods for associating additional attributes 2471 with CRLs. The X.509 v2 CRL format also allows communities to define 2472 private extensions to carry information unique to those communities. 2473 Each extension in a CRL may be designated as critical or non- 2474 critical. A CRL validation MUST fail if it encounters a critical 2475 extension which it does not know how to process. However, an 2476 unrecognized non-critical extension may be ignored. The following 2477 subsections present those extensions used within Internet CRLs. 2478 Communities MAY elect to include extensions in CRLs which are not 2479 defined in this specification. However, caution SHOULD be exercised 2480 in adopting any critical extensions in CRLs which might be used in a 2481 general context. 2483 Conforming CRL issuers are required to include the authority key 2484 identifier (section 5.2.1) and the CRL number (section 5.2.3) 2485 extensions in all CRLs issued. 2487 5.2.1 Authority Key Identifier 2489 The authority key identifier extension provides a means of 2490 identifying the public key corresponding to the private key used to 2491 sign a CRL. The identification can be based on either the key 2492 identifier (the subject key identifier in the CRL signer's 2493 certificate) or on the issuer name and serial number. This extension 2494 is especially useful where an issuer has more than one signing key, 2495 either due to multiple concurrent key pairs or due to changeover. 2497 Conforming CRL issuers MUST use the key identifier method, and MUST 2498 include this extension in all CRLs issued. 2500 The syntax for this CRL extension is defined in section 4.2.1.1. 2502 5.2.2 Issuer Alternative Name 2504 The issuer alternative names extension allows additional identities 2505 to be associated with the issuer of the CRL. Defined options include 2506 an rfc822 name (electronic mail address), a DNS name, an IP address, 2507 and a URI. Multiple instances of a name and multiple name forms may 2508 be included. Whenever such identities are used, the issuer 2509 alternative name extension MUST be used; however, a DNS name MAY be 2510 represented in the issuer field using the domainComponent attribute 2511 as described in section 4.1.2.4. 2513 The issuerAltName extension SHOULD NOT be marked critical. 2515 The OID and syntax for this CRL extension are defined in section 2516 4.2.1.8. 2518 5.2.3 CRL Number 2520 The CRL number is a non-critical CRL extension which conveys a 2521 monotonically increasing sequence number for a given CRL scope and 2522 CRL issuer. This extension allows users to easily determine when a 2523 particular CRL supersedes another CRL. CRL numbers also support the 2524 identification of complementary complete CRLs and delta CRLs. CRL 2525 issuers conforming to this profile MUST include this extension in all 2526 CRLs. 2528 If a CRL issuer generates delta CRLs in addition to complete CRLs for 2529 a given scope, the complete CRLs and delta CRLs MUST share one 2530 numbering sequence. If a delta CRL and a complete CRL that cover the 2531 same scope are issued at the same time, they MUST have the same CRL 2532 number and provide the same revocation information. That is, the 2533 combination of the delta CRL and an acceptable complete CRL MUST 2534 provide the same revocation information as the simultaneously issued 2535 complete CRL. 2537 If a CRL issuer generates two CRLs (two complete CRLs, two delta 2538 CRLs, or a complete CRL and a delta CRL) for the same scope at 2539 different times, the two CRLs MUST NOT have the same CRL number. 2540 That is, if the this update field (section 5.1.2.4) in the two CRLs 2541 are not identical, the CRL numbers MUST be different. 2543 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 2545 CRLNumber ::= INTEGER (0..MAX) 2547 5.2.4 Delta CRL Indicator 2549 The delta CRL indicator is a critical CRL extension that identifies a 2550 CRL as being a delta CRL. Delta CRLs contain updates to revocation 2551 information previously distributed, rather than all the information 2552 that would appear in a complete CRL. The use of delta CRLs can 2553 significantly reduce network load and processing time in some 2554 environments. Delta CRLs are generally smaller than the CRLs they 2555 update, so applications that obtain delta CRLs consume less network 2556 bandwidth than applications that obtain the corresponding complete 2557 CRLs. Applications which store revocation information in a format 2558 other than the CRL structure can add new revocation information to 2559 the local database without reprocessing information. 2561 The delta CRL indicator extension contains the single value of type 2562 BaseCRLNumber. The CRL number identifies the CRL, complete for a 2563 given scope, that was used as the starting point in the generation of 2564 this delta CRL. A conforming CRL issuer MUST publish the referenced 2565 base CRL as a complete CRL. The delta CRL contains all updates to 2566 the revocation status for that same scope. The combination of a 2567 delta CRL plus the referenced base CRL is equivalent to a complete 2568 CRL, for the applicable scope, at the time of publication of the 2569 delta CRL. 2571 When a conforming CRL issuer generates a delta CRL, the delta CRL 2572 MUST include a critical delta CRL indicator extension. 2574 When a delta CRL is issued, it MUST cover the same set of reasons and 2575 the same set of certificates that were covered by the base CRL it 2576 references. That is, the scope of the delta CRL MUST be the same as 2577 the scope of the complete CRL referenced as the base. The referenced 2578 base CRL and the delta CRL MUST omit the issuing distribution point 2579 extension or contain identical issuing distribution point extensions. 2580 Further, the CRL issuer MUST use the same private key to sign the 2581 delta CRL and any complete CRL that it can be used to update. 2583 An application that supports delta CRLs can construct a CRL that is 2584 complete for a given scope by combining a delta CRL for that scope 2585 with either an issued CRL that is complete for that scope or a 2586 locally constructed CRL that is complete for that scope. 2588 When a delta CRL is combined with a complete CRL or a locally 2589 constructed CRL, the resulting locally constructed CRL has the CRL 2590 number specified in the CRL number extension found in the delta CRL 2591 used in its construction. In addition, the resulting locally 2592 constructed CRL has the thisUpdate and nextUpdate times specified in 2593 the corresponding fields of the delta CRL used in its construction. 2594 In addition, the locally constructed CRL inherits the issuing 2595 distribution point from the delta CRL. 2597 A complete CRL and a delta CRL MAY be combined if the following four 2598 conditions are satisfied: 2600 (a) The complete CRL and delta CRL have the same issuer. 2602 (b) The complete CRL and delta CRL have the same scope. The two 2603 CRLs have the same scope if either of the following conditions are 2604 met: 2606 (1) The issuingDistributionPoint extension is omitted from 2607 both the complete CRL and the delta CRL. 2609 (2) The issuingDistributionPoint extension is present in both 2610 the complete CRL and the delta CRL, and the values for each of 2611 the fields in the extensions are the same in both CRLs. 2613 (c) The CRL number of the complete CRL is equal to or greater 2614 than the BaseCRLNumber specified in the delta CRL. That is, the 2615 complete CRL contains (at a minimum) all the revocation 2616 information held by the referenced base CRL. 2618 (d) The CRL number of the complete CRL is less than the CRL 2619 number of the delta CRL. That is, the delta CRL follows the 2620 complete CRL in the numbering sequence. 2622 CRL issuers MUST ensure that the combination of a delta CRL and any 2623 appropriate complete CRL accurately reflects the current revocation 2624 status. The CRL issuer MUST include an entry in the delta CRL for 2625 each certificate within the scope of the delta CRL whose status has 2626 changed since the generation of the referenced base CRL: 2628 (a) If the certificate is revoked for a reason included in the 2629 scope of the CRL, list the certificate as revoked. 2631 (b) If the certificate is valid and was listed on the referenced 2632 base CRL or any subsequent CRL with reason code certificateHold, 2633 and the reason code certificateHold is included in the scope of 2634 the CRL, list the certificate with the reason code removeFromCRL. 2636 (c) If the certificate is revoked for a reason outside the scope 2637 of the CRL, but the certificate was listed on the referenced base 2638 CRL or any subsequent CRL with a reason code included in the scope 2639 of this CRL, list the certificate as revoked but omit the reason 2640 code. 2642 (d) If the certificate is revoked for a reason outside the scope 2643 of the CRL and the certificate was neither listed on the 2644 referenced base CRL nor any subsequent CRL with a reason code 2645 included in the scope of this CRL, do not list the certificate on 2646 this CRL. 2648 The status of a certificate is considered to have changed if it is 2649 revoked, placed on hold, released from hold, or if its revocation 2650 reason changes. 2652 It is appropriate to list a certificate with reason code 2653 removeFromCRL on a delta CRL even if the certificate was not on hold 2654 in the referenced base CRL. If the certificate was placed on hold in 2655 any CRL issued after the base but before this delta CRL and then 2656 released from hold, it MUST be listed on the delta CRL with 2657 revocation reason removeFromCRL. 2659 A CRL issuer MAY optionally list a certificate on a delta CRL with 2660 reason code removeFromCRL if the notAfter time specified in the 2661 certificate precedes the thisUpdate time specified in the delta CRL 2662 and the certificate was listed on the referenced base CRL or in any 2663 CRL issued after the base but before this delta CRL. 2665 If a certificate revocation notice first appears on a delta CRL, then 2666 it is possible for the certificate validity period to expire before 2667 the next complete CRL for the same scope is issued. In this case, 2668 the revocation notice MUST be included in all subsequent delta CRLs 2669 until the revocation notice is included on at least one explicitly 2670 issued complete CRL for this scope. 2672 An application that supports delta CRLs MUST be able to construct a 2673 current complete CRL by combining a previously issued complete CRL 2674 and the most current delta CRL. An application that supports delta 2675 CRLs MAY also be able to construct a current complete CRL by 2676 combining a previously locally constructed complete CRL and the 2677 current delta CRL. A delta CRL is considered to be the current one 2678 if the current time is between the times contained in the thisUpdate 2679 and nextUpdate fields. Under some circumstances, the CRL issuer may 2680 publish one or more delta CRLs before indicated by the nextUpdate 2681 field. If more than one current delta CRL for a given scope is 2682 encountered, the application SHOULD consider the one with the latest 2683 value in thisUpdate to be the most current one. 2685 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 2687 BaseCRLNumber ::= CRLNumber 2689 5.2.5 Issuing Distribution Point 2691 The issuing distribution point is a critical CRL extension that 2692 identifies the CRL distribution point and scope for a particular CRL, 2693 and it indicates whether the CRL covers revocation for end entity 2694 certificates only, CA certificates only, attribute certificates 2695 only, or a limited set of reason codes. Although the extension is 2696 critical, conforming implementations are not required to support this 2697 extension. 2699 The CRL is signed using the CRL issuer's private key. CRL 2700 Distribution Points do not have their own key pairs. If the CRL is 2701 stored in the X.500 Directory, it is stored in the Directory entry 2702 corresponding to the CRL distribution point, which may be different 2703 than the Directory entry of the CRL issuer. 2705 The reason codes associated with a distribution point MUST be 2706 specified in onlySomeReasons. If onlySomeReasons does not appear, 2707 the distribution point MUST contain revocations for all reason codes. 2708 CAs may use CRL distribution points to partition the CRL on the basis 2709 of compromise and routine revocation. In this case, the revocations 2710 with reason code keyCompromise (1), cACompromise (2), and 2711 aACompromise (8) appear in one distribution point, and the 2712 revocations with other reason codes appear in another distribution 2713 point. 2715 If the distributionPoint field is present and contains a URI, the 2716 following semantics MUST be assumed: the object is a pointer to the 2717 most current CRL issued by this CRL issuer. The URI schemes ftp, 2718 http, mailto [RFC1738] and ldap [RFC1778] are defined for this 2719 purpose. The URI MUST be an absolute pathname, not a relative 2720 pathname, and MUST specify the host. 2722 If the distributionPoint field is absent, the CRL MUST contain 2723 entries for all revoked unexpired certificates issued by the CRL 2724 issuer, if any, within the scope of the CRL. 2726 The CRL issuer MUST assert the indirectCRL boolean, if the scope of 2727 the CRL includes certificates issued by authorities other than the 2728 CRL issuer. The authority responsible for each entry is indicated by 2729 the certificate issuer CRL entry extension (section 5.3.4). 2731 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 2733 issuingDistributionPoint ::= SEQUENCE { 2734 distributionPoint [0] DistributionPointName OPTIONAL, 2735 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 2736 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 2737 onlySomeReasons [3] ReasonFlags OPTIONAL, 2738 indirectCRL [4] BOOLEAN DEFAULT FALSE, 2739 onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE } 2741 5.2.6 Freshest CRL (a.k.a. Delta CRL Distribution Point) 2743 The freshest CRL extension identifies how delta CRL information for 2744 this complete CRL is obtained. The extension MUST be non-critical. 2745 This extension MUST NOT appear in delta CRLs. 2747 The same syntax is used for this extension as the 2748 cRLDistributionPoints certificate extension, and is described in 2749 section 4.2.1.14. However, only the distribution point field is 2750 meaningful in this context. The reasons and CRLIssuer fields MUST be 2751 omitted from this CRL extension. 2753 Each distribution point name provides the location at which a delta 2754 CRL for this complete CRL can be found. The scope of these delta 2755 CRLs MUST be the same as the scope of this complete CRL. The 2756 contents of this CRL extension are only used to locate delta CRLs; 2757 the contents are not used to validate the CRL or the referenced delta 2758 CRLs. The encoding conventions defined for distribution points in 2759 section 4.2.1.14 apply to this extension. 2761 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } 2763 FreshestCRL ::= CRLDistributionPoints 2765 5.3 CRL Entry Extensions 2767 The CRL entry extensions already defined by ANSI X9 and ISO/IEC/ITU 2768 for X.509 v2 CRLs provide methods for associating additional 2769 attributes with CRL entries [X.509] [X9.55]. The X.509 v2 CRL format 2770 also allows communities to define private CRL entry extensions to 2771 carry information unique to those communities. Each extension in a 2772 CRL entry may be designated as critical or non-critical. A CRL 2773 validation MUST fail if it encounters a critical CRL entry extension 2774 which it does not know how to process. However, an unrecognized non- 2775 critical CRL entry extension may be ignored. The following 2776 subsections present recommended extensions used within Internet CRL 2777 entries and standard locations for information. Communities MAY 2778 elect to use additional CRL entry extensions; however, caution SHOULD 2779 be exercised in adopting any critical extensions in CRL entries which 2780 might be used in a general context. 2782 All CRL entry extensions used in this specification are non-critical. 2783 Support for these extensions is optional for conforming CRL issuers 2784 and applications. However, CRL issuers SHOULD include reason codes 2785 (section 5.3.1) and invalidity dates (section 5.3.3) whenever this 2786 information is available. 2788 5.3.1 Reason Code 2790 The reasonCode is a non-critical CRL entry extension that identifies 2791 the reason for the certificate revocation. CRL issuers are strongly 2792 encouraged to include meaningful reason codes in CRL entries; 2793 however, the reason code CRL entry extension SHOULD be absent instead 2794 of using the unspecified (0) reasonCode value. 2796 id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 } 2798 -- reasonCode ::= { CRLReason } 2800 CRLReason ::= ENUMERATED { 2801 unspecified (0), 2802 keyCompromise (1), 2803 cACompromise (2), 2804 affiliationChanged (3), 2805 superseded (4), 2806 cessationOfOperation (5), 2807 certificateHold (6), 2808 removeFromCRL (8), 2809 privilegeWithdrawn (9), 2810 aACompromise (10) } 2812 5.3.2 Hold Instruction Code 2814 The hold instruction code is a non-critical CRL entry extension that 2815 provides a registered instruction identifier which indicates the 2816 action to be taken after encountering a certificate that has been 2817 placed on hold. 2819 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 2821 holdInstructionCode ::= OBJECT IDENTIFIER 2823 The following instruction codes have been defined. Conforming 2824 applications that process this extension MUST recognize the following 2825 instruction codes. 2827 holdInstruction OBJECT IDENTIFIER ::= 2828 { iso(1) member-body(2) us(840) x9-57(10040) 2 } 2830 id-holdinstruction-none OBJECT IDENTIFIER ::= {holdInstruction 1} 2831 id-holdinstruction-callissuer 2832 OBJECT IDENTIFIER ::= {holdInstruction 2} 2833 id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3} 2835 Conforming applications which encounter an id-holdinstruction- 2836 callissuer MUST call the certificate issuer or reject the 2837 certificate. Conforming applications which encounter an id- 2838 holdinstruction-reject MUST reject the certificate. The hold 2839 instruction id-holdinstruction-none is semantically equivalent to the 2840 absence of a holdInstructionCode, and its use is strongly deprecated 2841 for the Internet PKI. 2843 5.3.3 Invalidity Date 2845 The invalidity date is a non-critical CRL entry extension that 2846 provides the date on which it is known or suspected that the private 2847 key was compromised or that the certificate otherwise became invalid. 2848 This date may be earlier than the revocation date in the CRL entry, 2849 which is the date at which the CA processed the revocation. When a 2850 revocation is first posted by a CRL issuer in a CRL, the invalidity 2851 date may precede the date of issue of earlier CRLs, but the 2852 revocation date SHOULD NOT precede the date of issue of earlier CRLs. 2853 Whenever this information is available, CRL issuers are strongly 2854 encouraged to share it with CRL users. 2856 The GeneralizedTime values included in this field MUST be expressed 2857 in Greenwich Mean Time (Zulu), and MUST be specified and interpreted 2858 as defined in section 4.1.2.5.2. 2860 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 2862 invalidityDate ::= GeneralizedTime 2864 5.3.4 Certificate Issuer 2866 This CRL entry extension identifies the certificate issuer associated 2867 with an entry in an indirect CRL, that is, a CRL that has the 2868 indirectCRL indicator set in its issuing distribution point 2869 extension. If this extension is not present on the first entry in an 2870 indirect CRL, the certificate issuer defaults to the CRL issuer. On 2871 subsequent entries in an indirect CRL, if this extension is not 2872 present, the certificate issuer for the entry is the same as that for 2873 the preceding entry. This field is defined as follows: 2875 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } 2877 certificateIssuer ::= GeneralNames 2879 If used by conforming CRL issuers, this extension MUST always be 2880 critical. If an implementation ignored this extension it could not 2881 correctly attribute CRL entries to certificates. This specification 2882 RECOMMENDS that implementations recognize this extension. 2884 6 Certification Path Validation 2886 Certification path validation procedures for the Internet PKI are 2887 based on the algorithm supplied in [X.509]. Certification path 2888 processing verifies the binding between the subject distinguished 2889 name and/or subject alternative name and subject public key. The 2890 binding is limited by constraints which are specified in the 2891 certificates which comprise the path and inputs which are specified 2892 by the relying party. The basic constraints and policy constraints 2893 extensions allow the certification path processing logic to automate 2894 the decision making process. 2896 This section describes an algorithm for validating certification 2897 paths. Conforming implementations of this specification are not 2898 required to implement this algorithm, but MUST provide functionality 2899 equivalent to the external behavior resulting from this procedure. 2900 Any algorithm may be used by a particular implementation so long as 2901 it derives the correct result. 2903 In section 6.1, the text describes basic path validation. Valid 2904 paths begin with certificates issued by a "most-trusted CA". The 2905 algorithm requires the public key of the CA, the CA's name, and any 2906 constraints upon the set of paths which may be validated using this 2907 key. 2909 The selection of a "most-trusted CA" is a matter of policy: it could 2910 be the top CA in a hierarchical PKI; the CA that issued the 2911 verifier's own certificate(s); or any other CA in a network PKI. The 2912 path validation procedure is the same regardless of the choice of 2913 "most-trusted CA." In addition, different applications may rely on 2914 different "most-trusted CA", or may accept paths that begin with any 2915 of a set of "most-trusted CAs." 2917 Section 6.2 describes methods for using the path validation algorithm 2918 in specific implementations. Two specific cases are discussed: the 2919 case where paths may begin with one of several trusted CAs; and where 2920 compatibility with the PEM architecture is required. 2922 Section 6.3 describes the steps necessary to determine if a 2923 certificate is revoked or on hold status when CRLs are the revocation 2924 mechanism used by the certificate issuer. 2926 6.1 Basic Path Validation 2928 This text describes an algorithm for X.509 path processing. A 2929 conformant implementation MUST include an X.509 path processing 2930 procedure that is functionally equivalent to the external behavior of 2931 this algorithm. However, support for some of the certificate 2932 extensions processed in this algorithm are OPTIONAL for compliant 2933 implementations. Clients that do not support these extensions MAY 2934 omit the corresponding steps in the path validation algorithm. 2936 For example, clients are NOT REQUIRED to support the policy mapping 2937 extension. Clients that do not support this extension MAY omit the 2938 path validation steps where policy mappings are processed. Note that 2939 clients MUST reject the certificate if it contains an unsupported 2940 critical extension. 2942 The algorithm presented in this section validates the certificate 2943 with respect to the current date and time. A conformant 2944 implementation MAY also support validation with respect to some point 2945 in the past. Note that mechanisms are not available for validating a 2946 certificate with respect to a time outside the certificate validity 2947 period. 2949 The trust anchor is an input to the algorithm. There is no 2950 requirement that the same trust anchor be used to validate all 2951 certification paths. Different trust anchors MAY be used to validate 2952 different paths, as discussed further in Section 6.2. 2954 The primary goal of path validation is to verify the binding between 2955 a subject distinguished name or a subject alternative name and 2956 subject public key, as represented in the end entity certificate, 2957 based on the public key of the trust anchor. This requires obtaining 2958 a sequence of certificates that support that binding. The procedure 2959 performed to obtain this sequence of certificates is outside the 2960 scope of this specification. 2962 To meet this goal, the path validation process verifies, among other 2963 things, that a prospective certification path (a sequence of n 2964 certificates) satisfies the following conditions: 2966 (a) for all x in {1, ..., n-1}, the subject of certificate x is 2967 the issuer of certificate x+1; 2969 (b) certificate 1 is issued by the trust anchor; 2971 (c) certificate n is the certificate to be validated; and 2973 (d) for all x in {1, ..., n}, the certificate was valid at the 2974 time in question. 2976 When the trust anchor is provided in the form of a self-signed 2977 certificate, this self-signed certificate is not included as part of 2978 the prospective certification path. Information about trust anchors 2979 are provided as inputs to the certification path validation algorithm 2980 (section 6.1.1). 2982 A particular certification path may not, however, be appropriate for 2983 all applications. Therefore, an application MAY augment this 2984 algorithm to further limit the set of valid paths. The path 2985 validation process also determines the set of certificate policies 2986 that are valid for this path, based on the certificate policies 2987 extension, policy mapping extension, policy constraints extension, 2988 and inhibit any-policy extension. To achieve this, the path 2989 validation algorithm constructs a valid policy tree. If the set of 2990 certificate policies that are valid for this path is not empty, then 2991 the result will be a valid policy tree of depth n, otherwise the 2992 result will be a null valid policy tree. 2994 A certificate is self-issued if the DNs that appear in the subject 2995 and issuer fields are identical and are not empty. In general, the 2996 issuer and subject of the certificates that make up a path are 2997 different for each certificate. However, a CA may issue a 2998 certificate to itself to support key rollover or changes in 2999 certificate policies. These self-issued certificates are not counted 3000 when evaluating path length or name constraints. 3002 This section presents the algorithm in four basic steps: (1) 3003 initialization, (2) basic certificate processing, (3) preparation for 3004 the next certificate, and (4) wrap-up. Steps (1) and (4) are 3005 performed exactly once. Step (2) is performed for all certificates 3006 in the path. Step (3) is performed for all certificates in the path 3007 except the final certificate. Figure 2 provides a high-level 3008 flowchart of this algorithm. 3010 +-------+ 3011 | START | 3012 +-------+ 3013 | 3014 V 3015 +----------------+ 3016 | Initialization | 3017 +----------------+ 3018 | 3019 +<--------------------+ 3020 | | 3021 V | 3022 +----------------+ | 3023 | Process Cert | | 3024 +----------------+ | 3025 | | 3026 V | 3027 +================+ | 3028 | IF Last Cert | | 3029 | in Path | | 3030 +================+ | 3031 | | | 3032 THEN | | ELSE | 3033 V V | 3034 +----------------+ +----------------+ | 3035 | Wrap up | | Prepare for | | 3036 +----------------+ | Next Cert | | 3037 | +----------------+ | 3038 V | | 3039 +-------+ +--------------+ 3040 | STOP | 3041 +-------+ 3043 Figure 2. Certification Path Processing Flowchart 3045 6.1.1 Inputs 3047 This algorithm assumes the following seven inputs are provided to the 3048 path processing logic: 3050 (a) a prospective certification path of length n. 3052 (b) the current date/time. 3054 (c) user-initial-policy-set: A set of certificate policy 3055 identifiers naming the policies that are acceptable to the 3056 certificate user. The user-initial-policy-set contains the special 3057 value any-policy if the user is not concerned about certificate 3058 policy. 3060 (d) trust anchor information, describing a CA that serves as a 3061 trust anchor for the certification path. The trust anchor 3062 information includes: 3064 (1) the trusted issuer name, 3066 (2) the trusted public key algorithm, 3068 (3) the trusted public key, and 3070 (4) optionally, the trusted public key parameters associated 3071 with the public key. 3073 The trust anchor information may be provided to the path 3074 processing procedure in the form of a self-signed certificate. 3075 The trusted anchor information is trusted because it was delivered 3076 to the path processing procedure by some trustworthy out-of-band 3077 procedure. If the trusted public key algorithm requires 3078 parameters, then the parameters are provided along with the 3079 trusted public key. 3081 (e) initial-policy-mapping-inhibit, which indicates if policy 3082 mapping is allowed in the certification path. 3084 (f) initial-explicit-policy, which indicates if the path must be 3085 valid for at least one of the certificate policies in the user- 3086 initial-policy-set. 3088 (g) initial-any-policy-inhibit, which indicates whether the 3089 anyPolicy OID should be processed if it is included in a 3090 certificate. 3092 6.1.2 Initialization 3094 The initialization phase establishes eleven state variables based 3095 upon the seven inputs: 3097 (a) valid_policy_tree: A tree of certificate policies with their 3098 optional qualifiers; each of the leaves of the tree represents a 3099 valid policy at this stage in the certification path validation. 3100 If valid policies exist at this stage in the certification path 3101 validation, the depth of the tree is equal to the number of 3102 certificates in the chain that have been processed. If valid 3103 policies do not exist at this stage in the certification path 3104 validation, the tree is set to NULL. Once the tree is set to NULL, 3105 policy processing ceases. 3107 Each node in the valid_policy_tree includes four data objects: the 3108 valid policy, a set of associated policy qualifiers, a set of one 3109 or more expected policy values, and a criticality indicator. If 3110 the node is at depth x, the components of the node have the 3111 following semantics: 3113 (1) The valid_policy is a single policy OID representing a 3114 valid policy for the path of length x. 3116 (2) The qualifier_set is a set of policy qualifiers associated 3117 with the valid policy in certificate x. 3119 (3) The criticality_indicator indicates whether the 3120 certificate policy extension in certificate x was marked as 3121 critical. 3123 (4) The expected_policy_set contains one or more policy OIDs 3124 that would satisfy this policy in the certificate x+1. 3126 The initial value of the valid_policy_tree is a single node with 3127 valid_policy any-policy, an empty qualifier_set, an 3128 expected_policy_set with the single value any-policy, and a 3129 criticality_indicator of FALSE. This node is considered to be at 3130 depth zero. 3132 Figure 3 is a graphic representation of the initial state of the 3133 valid_policy_tree. Additional figures will use this format to 3134 describe changes in the valid_policy_tree during path processing. 3136 +----------------+ 3137 | any-policy | <---- valid_policy 3138 +----------------+ 3139 | {} | <---- qualifier_set 3140 +----------------+ 3141 | FALSE | <---- criticality_indicator 3142 +----------------+ 3143 | {any-policy} | <---- expected_policy_set 3144 +----------------+ 3146 Figure 3. Initial value of the valid_policy_tree state variable 3148 (b) permitted_subtrees: A set of root names for each name type 3149 (e.g., X.500 distinguished names, email addresses, or ip 3150 addresses) defining a set of subtrees within which all subject 3151 names in subsequent certificates in the certification path MUST 3152 fall. This variable includes a set for each name type: the 3153 initial value for the set for Distinguished Names is the set of 3154 all Distinguished names; the initial value for the set of RFC822 3155 names is the set of all RFC822 names, etc. 3157 (c) excluded_subtrees: A set of root names for each name type 3158 (e.g., X.500 distinguished names, email addresses, or ip 3159 addresses) defining a set of subtrees within which no subject name 3160 in subsequent certificates in the certification path may fall. 3161 This variable includes a set for each name type, and the initial 3162 value for each set is empty. 3164 (d) explicit_policy: an integer which indicates if a non-NULL 3165 valid_policy_tree is required. The integer indicates the number of 3166 non-self-issued certificates to be processed before this 3167 requirement is imposed. Once set, this variable may be decreased, 3168 but may not be increased. That is, if a certificate in the path 3169 requires a non-NULL valid_policy_tree, a later certificate can not 3170 remove this requirement. If initial-explicit-policy is set, then 3171 the initial value is 0, otherwise the initial value is n+1. 3173 (e) inhibit_any-policy: an integer which indicates whether the 3174 any-policy policy identifier is considered a match. The integer 3175 indicates the number of non-self-issued certificates to be 3176 processed before the any-policy OID, if asserted in a certificate, 3177 is ignored. Once set, this variable may be decreased, but may not 3178 be increased. That is, if a certificate in the path inhibits 3179 processing of any-policy, a later certificate can not permit it. 3180 If initial-any-policy-inhibit is set, then the initial value is 0, 3181 otherwise the initial value is n+1. 3183 (f) policy_mapping: an integer which indicates if policy mapping 3184 is permitted. The integer indicates the number of non-self-issued 3185 certificates to be processed before policy mapping is inhibited. 3187 Once set, this variable may be decreased, but may not be 3188 increased. That is, if a certificate in the path specifies policy 3189 mapping is not permitted, it can not be overridden by a later 3190 certificate. If initial-policy-mapping-inhibit is set, then the 3191 initial value is 0, otherwise the initial value is n+1. 3193 (g) working_public_key_algorithm: the digital signature algorithm 3194 used to verify the signature of a certificate. The 3195 working_public_key_algorithm is initialized from the trusted 3196 public key algorithm provided in the trust anchor information. 3198 (h) working_public_key: the public key used to verify the 3199 signature of a certificate. The working_public_key is initialized 3200 from the trusted public key provided in the trust anchor 3201 information. 3203 (i) working_public_key_parameters: parameters associated with the 3204 current public key, that may be required to verify a signature 3205 (depending upon the algorithm). The working_public_key_parameters 3206 variable is initialized from the trusted public key parameters 3207 provided in the trust anchor information. 3209 (j) working_issuer_name: the issuer distinguished name expected 3210 in the next certificate in the chain. The working_issuer_name is 3211 initialized to the trusted issuer provided in the trust anchor 3212 information. 3214 (k) max_path_length: this integer is initialized to n, is 3215 decremented for each non-self-issued certificate in the path, and 3216 may be reduced to the value in the path length constraint field 3217 within the basic constraints extension of a CA certificate. 3219 Upon completion of the initialization steps, perform the basic 3220 certificate processing steps specified in 6.1.3. 3222 6.1.3 Basic Certificate Processing 3224 The basic path processing actions to be performed for certificate i 3225 (for all i in [1..n]) are listed below. 3227 (a) Verify the basic certificate information. The certificate 3228 MUST satisfy each of the following: 3230 (1) The certificate was signed with the 3231 working_public_key_algorithm using the working_public_key and 3232 the working_public_key_parameters. 3234 (2) The certificate validity period includes the current time. 3236 (3) At the current time, the certificate is not revoked and is 3237 not on hold status. This may be determined by obtaining the 3238 appropriate CRL (section 6.3), status information, or by out- 3239 of-band mechanisms. 3241 (4) The certificate issuer name is the working_issuer_name. 3243 (b) If certificate i is self-issued and it is not the final 3244 certificate in the path, skip this step for certificate i. 3245 Otherwise, verify that the subject name is within one of the 3246 permitted_subtrees for X.500 distinguished names, and verify that 3247 each of the alternative names in the subjectAltName extension 3248 (critical or non-critical) is within one of the permitted_subtrees 3249 for that name type. 3251 (c) If certificate i is self-issued and it is not the final 3252 certificate in the path, skip this step for certificate i. 3253 Otherwise, verify that the subject name is not within one of the 3254 excluded_subtrees for X.500 distinguished names, and verify that 3255 each of the alternative names in the subjectAltName extension 3256 (critical or non-critical) is not within one of the 3257 excluded_subtrees for that name type. 3259 (d) If the certificate policies extension is present in the 3260 certificiate and the valid_policy_tree is not NULL, process the 3261 policy information by performing the following steps in order: 3263 (1) For each policy P not equal to any-policy in the 3264 certificate policies extension, let P-OID denote the OID in 3265 policy P and P-Q denote the qualifier set for policy P. 3266 Perform the following steps in order: 3268 (i) If the valid_policy_tree includes a node of depth i-1 3269 where P-OID is in the expected_policy_set, create a child 3270 node as follows: set the valid_policy to OID-P; set the 3271 qualifier_set to P-Q, and set the expected_policy_set to {P- 3272 OID}. 3274 For example, consider a valid_policy_tree with a node of 3275 depth i-1 where the expected_policy_set is {Gold, White}. 3276 Assume the certificate policies Gold and Silver appear in 3277 the certificate policies extension of certificate i. The 3278 Gold policy is matched but the Silver policy is not. This 3279 rule will generate a child node of depth i for the Gold 3280 policy. The result is shown as Figure 4. 3282 |-----------------| 3283 | Red | 3284 |-----------------| 3285 | {} | 3286 |-----------------| node of depth i-1 3287 | FALSE | 3288 |-----------------| 3289 | {Gold, White} | 3290 |-----------------| 3291 | 3292 | 3293 | 3294 V 3295 |-----------------| 3296 | Gold | 3297 |-----------------| 3298 | {} | 3299 |-----------------| node of depth i 3300 | uninitialized | 3301 |-----------------| 3302 | {Gold} | 3303 |-----------------| 3305 Figure 4. Processing an exact match 3307 (ii) If there was no match in step (i) and the 3308 valid_policy_tree includes a node of depth i-1 with the 3309 valid policy any-policy, generate a child node with the 3310 following values: set the valid_policy to P-OID; set the 3311 qualifier_set to P-Q, and set the expected_policy_set to {P- 3312 OID}. 3314 For example, consider a valid_policy_tree with a node of 3315 depth i-1 where the valid_policy is any-policy. Assume the 3316 certificate policies Gold and Silver appear in the 3317 certificate policies extension of certificate i. The Gold 3318 policy does not have a qualifier, but the Silver policy has 3319 the qualifier Q-Silver. If Gold and Silver were not matched 3320 in (i) above, this rule will generate two child nodes of 3321 depth i, one for each policy. The result is shown as Figure 3322 5. 3324 |-----------------| 3325 | any-policy | 3326 |-----------------| 3327 | {} | 3328 |-----------------| node of depth i-1 3329 | FALSE | 3330 |-----------------| 3331 | {any-policy} | 3332 |-----------------| 3333 / \ 3334 / \ 3335 / \ 3336 / \ 3337 |-----------------| |-----------------| 3338 | Gold | | Silver | 3339 |-----------------| |-----------------| 3340 | {} | | {Q-Silver} | 3341 |-----------------| nodes of |-----------------| 3342 | uninitialized | depth i | uninitialized | 3343 |-----------------| |-----------------| 3344 | {Gold} | | {Silver} | 3345 |-----------------| |-----------------| 3347 Figure 5. Processing unmatched policies when a leaf node 3348 specifies any-policy 3350 (2) If the certificate policies extension includes the policy 3351 anyPolicy with the qualifier set AP-Q and inhibit_any-policy is 3352 greater than 0, then: 3354 For each node in the valid_policy_tree of depth i-1, for each 3355 value in the expected_policy_set (including any-policy) that 3356 does not appear in a child node, create a child node with the 3357 following values: set the valid_policy to the value from the 3358 expected_policy_set in the parent node; set the qualifier_set 3359 to AP-Q, and set the expected_policy_set to the value in the 3360 valid_policy from this node. 3362 For example, consider a valid_policy_tree with a node of depth 3363 i-1 where the expected_policy_set = {Gold, Silver}. Assume 3364 any-policy appears in the certificate policies extension of 3365 certificate i, but Gold and Silver do not. This rule will 3366 generate two child nodes of depth i, one for each policy. The 3367 result is shown below as Figure 6. 3369 |-----------------| 3370 | Red | 3371 |-----------------| 3372 | {} | 3373 |-----------------| node of depth i-1 3374 | FALSE | 3375 |-----------------| 3376 | {Gold, Silver} | 3377 |-----------------| 3378 / \ 3379 / \ 3380 / \ 3381 / \ 3382 |-----------------| |-----------------| 3383 | Gold | | Silver | 3384 |-----------------| |-----------------| 3385 | {} | | {} | 3386 |-----------------| nodes of |-----------------| 3387 | uninitialized | depth i | uninitialized | 3388 |-----------------| |-----------------| 3389 | {Gold} | | {Silver} | 3390 |-----------------| |-----------------| 3392 Figure 6. Processing unmatched policies when the certificate 3393 policies extension specifies any-policy 3395 (3) If there is a node in the valid_policy_tree of depth i-1 3396 or less without any child nodes, delete that node. Repeat this 3397 step until there are no nodes of depth i-1 or less without 3398 children. 3400 For example, consider the valid_policy_tree shown in Figure 7 3401 below. The two nodes at depth i-1 that are marked with an 'X' 3402 have no children, and are deleted. Applying this rule to the 3403 resulting tree will cause the node at depth i-2 that is marked 3404 with an 'Y' to be deleted. The following application of the 3405 rule does not cause any nodes to be deleted, and this step is 3406 complete. 3408 +-----------+ 3409 | | node of depth i-3 3410 +-----------+ 3411 / | \ 3412 / | \ 3413 / | \ 3414 +-----------+ +-----------+ +-----------+ 3415 | | | | | Y | nodes of 3416 +-----------+ +-----------+ +-----------+ depth i-2 3417 / \ | | 3418 / \ | | 3419 / \ | | 3420 +-----------+ +-----------+ +-----------+ +-----------+ nodes of 3421 | | | X | | | | X | depth 3422 +-----------+ +-----------+ +-----------+ +-----------+ i-1 3423 | / | \ 3424 | / | \ 3425 | / | \ 3426 +-----------+ +-----------+ +-----------+ +-----------+ nodes of 3427 | | | | | | | | depth 3428 +-----------+ +-----------+ +-----------+ +-----------+ i 3430 Figure 7. Pruning the valid_policy_tree 3432 (4) If the certificate policies extension was marked as 3433 critical, set the criticality_indicator in all nodes of depth i 3434 to TRUE. If the certificate policies extension was not marked 3435 critical, set the criticality_indicator in all nodes of depth i 3436 to FALSE. 3438 (e) If the certificate policies extension is not present, set the 3439 valid_policy_tree to NULL. 3441 (f) Verify that either explicit_policy is greater than 0 or the 3442 valid_policy_tree is not equal to NULL; 3444 If any of steps (a), (b), (c), or (f) fails, the procedure 3445 terminates, returning a failure indication and an appropriate reason. 3447 If i is not equal to n, continue by performing the preparatory steps 3448 listed in 6.1.4. If i is equal to n, perform the wrap-up steps 3449 listed in 6.1.5. 3451 6.1.4 Preparation for Certificate i+1 3453 To prepare for processing of certificate i+1, perform the following 3454 steps for certificate i: 3456 (a) If a policy mapping extension is present, verify that the 3457 special value any-policy does not appear as an issuerDomainPolicy 3458 or a subjectDomainPolicy. 3460 (b) If a policy mapping extension is present, then for each 3461 issuerDomainPolicy ID-P in the policy mapping extension: 3463 (1) If the policy_mapping variable is greater than 0, for each 3464 node in the valid_policy_tree of depth i where ID-P is the 3465 valid_policy, set expected_policy_set to the set of 3466 subjectDomainPolicy values that are specified as equivalent to 3467 ID-P by the policy mapping extension. 3469 If no node of depth i in the valid_policy_tree has a 3470 valid_policy of ID-P but there is a node of depth i with a 3471 valid_policy of any-policy, then generate a child node of the 3472 node of depth i-1 that has a valid_policy of any-policy as 3473 follows: 3475 (i) set the valid_policy to ID-P; 3477 (ii) set the qualifier_set to the qualifier set of the 3478 policy any-policy in the certificate policies extension of 3479 certificate i; 3481 (iii) set the criticality_indicator to the criticality of 3482 the certificate policies extension of certificate i; 3484 (iv) and set the expected_policy_set to the set of 3485 subjectDomainPolicy values that are specified as equivalent 3486 to ID-P by the policy mappings extension. 3488 (2) If the policy_mapping variable is equal to 0: 3490 (i) delete each node of depth i in the valid_policy_tree 3491 where ID-P is the valid_policy. 3493 (ii) If there is a node in the valid_policy_tree of depth 3494 i-1 or less without any child nodes, delete that node. 3495 Repeat this step until there are no nodes of depth i-1 or 3496 less without children. 3498 (c) Assign the certificate subject name to working_issuer_name. 3500 (d) Assign the certificate subjectPublicKey to 3501 working_public_key. 3503 (e) If the subjectPublicKeyInfo field of the certificate contains 3504 an algorithm field with non-null parameters, assign the parameters 3505 to the working_public_key_parameters variable. 3507 If the subjectPublicKeyInfo field of the certificate contains an 3508 algorithm field with null parameters or parameters are omitted, 3509 compare the certificate subjectPublicKey algorithm to the 3510 working_public_key_algorithm. If the certificate subjectPublicKey 3511 algorithm and the working_public_key_algorithm are different, set 3512 the working_public_key_parameters to null. 3514 (f) Assign the certificate subjectPublicKey algorithm to the 3515 working_public_key_algorithm variable. 3517 (g) If a name constraints extension is included in the 3518 certificate, modify the permitted_subtrees and excluded_subtrees 3519 state variables as follows: 3521 (1) If permittedSubtrees is present in the certificate, set 3522 the permitted_subtrees state variable to the intersection of 3523 its previous value and the value indicated in the extension 3524 field. If permittedSubtrees does not include a particular name 3525 type, the permitted_subtrees state variable is unchanged for 3526 that name type. For example, the intersection of the name 3527 spaces nist.gov and csrc.nist.gov is csrc.nist.gov. And, the 3528 intersection of nist.gov and rsasecurity.com is the empty set. 3530 (2) If excludedSubtrees is present in the certificate, set the 3531 excluded_subtrees state variable to the union of its previous 3532 value and the value indicated in the extension field. If 3533 excludedSubtrees does not include a particular name type, the 3534 excluded_subtrees state variable is unchanged for that name 3535 type. For example, the union of the name spaces nist.gov and 3536 csrc.nist.gov is nist.gov. And, the union of nist.gov and 3537 rsasecurity.com is both name spaces. 3539 (h) If the issuer and subject names are not identical: 3541 (1) If explicit_policy is not 0, decrement explicit_policy by 3542 1. 3544 (2) If policy_mapping is not 0, decrement policy_mapping by 1. 3546 (3) If inhibit_any-policy is not 0, decrement inhibit_any- 3547 policy by 1. 3549 (i) If a policy constraints extension is included in the 3550 certificate, modify the explicit_policy and policy_mapping state 3551 variables as follows: 3553 (1) If requireExplicitPolicy is present and is less than 3554 explicit_policy, set explicit_policy to the value of 3555 requireExplicitPolicy. 3557 (2) If inhibitPolicyMapping is present and is less than 3558 policy_mapping, set policy_mapping to the value of 3559 inhibitPolicyMapping. 3561 (j) If the inhibitAnyPolicy extension is included in the 3562 certificate and is less than inhibit_any-policy, set inhibit_any- 3563 policy to the value of inhibitAnyPolicy. 3565 (k) Verify that the certificate is a CA certificate (as specified 3566 in a basicConstraints extension or as verified out-of-band). 3568 (l) If the certificate was not self-issued, verify that 3569 max_path_length is greater than zero and decrement max_path_length 3570 by 1. 3572 (m) If pathLengthConstraint is present in the certificate and is 3573 less than max_path_length, set max_path_length to the value of 3574 pathLengthConstraint. 3576 (n) If a key usage extension is present, verify that the 3577 keyCertSign bit is set. 3579 (o) Recognize and process any other critical extension present in 3580 the certificate. Process any other recognized non-critical 3581 extension present in the certificate. 3583 If check (a), (k), (l), (n) or (o) fails, the procedure terminates, 3584 returning a failure indication and an appropriate reason. 3586 If (a), (k), (l), (n) and (o) have completed successfully, increment 3587 i and perform the basic certificate processing specified in 6.1.3. 3589 6.1.5 Wrap-up procedure 3591 To complete the processing of the end entity certificate, perform the 3592 following steps for certificate n: 3594 (a) If certificate n was not self-issued and explicit_policy is 3595 not 0, decrement explicit_policy by 1. 3597 (b) If a policy constraints extension is included in the 3598 certificate and requireExplicitPolicy is present and has a value 3599 of 0, set the explicit_policy state variable to 0. 3601 (c) Assign the certificate subjectPublicKey to 3602 working_public_key. 3604 (d) If the subjectPublicKeyInfo field of the certificate contains 3605 an algorithm field with non-null parameters, assign the parameters 3606 to the working_public_key_parameters variable. 3608 If the subjectPublicKeyInfo field of the certificate contains an 3609 algorithm field with null parameters or parameters are omitted, 3610 compare the certificate subjectPublicKey algorithm to the 3611 working_public_key_algorithm. If the certificate subjectPublicKey 3612 algorithm and the working_public_key_algorithm are different, set 3613 the working_public_key_parameters to null. 3615 (e) Assign the certificate subjectPublicKey algorithm to the 3616 working_public_key_algorithm variable. 3618 (f) Recognize and process any other critical extension present in 3619 the certificate n. Process any other recognized non-critical 3620 extension present in certificate n. 3622 (g) Calculate the intersection of the valid_policy_tree and the 3623 user-initial-policy-set, as follows: 3625 (i) If the valid_policy_tree is NULL, the intersection is 3626 NULL. 3628 (ii) If the valid_policy_tree is not NULL and the user- 3629 initial-policy-set is any-policy, the intersection is the 3630 entire valid_policy_tree. 3632 (iii) If the valid_policy_tree is not NULL and the user- 3633 initial-policy-set is not any-policy, calculate the 3634 intersection of the valid_policy_tree and the user-initial- 3635 policy-set as follows: 3637 1. Determine the set of policy nodes whose parent nodes 3638 have a valid_policy of any-policy. This is the 3639 valid_policy_node_set. 3641 2. If the valid_policy of any node in the 3642 valid_policy_node_set is not in the user-initial-policy-set 3643 and is not any-policy, delete this node and all its 3644 children. 3646 3. If there is a node in the valid_policy_tree of depth n-1 3647 or less without any child nodes, delete that node. Repeat 3648 this step until there are no nodes of depth n-1 or less 3649 without children. 3651 If either (1) the value of explicit_policy variable is greater than 3652 zero, or (2) the valid_policy_tree is not NULL, then path processing 3653 has succeeded. 3655 6.1.6 Outputs 3657 If path processing succeeds, the procedure terminates, returning a 3658 success indication together with final value of the 3659 valid_policy_tree, the working_public_key, the 3660 working_public_key_algorithm, and the working_public_key_parameters. 3662 6.2 Using the Path Validation Algorithm 3664 The path validation algorithm describes the process of validating a 3665 single certification path. While each certification path begins with 3666 a specific trust anchor, there is no requirement that all 3667 certification paths validated by a particular system share a single 3668 trust anchor. An implementation that supports multiple trust anchors 3669 MAY augment the algorithm presented in section 6.1 to further limit 3670 the set of valid certification paths which begin with a particular 3671 trust anchor. For example, an implementation MAY modify the 3672 algorithm to apply name constraints to a specific trust anchor during 3673 the initialization phase, or the application MAY require the presence 3674 of a particular alternative name form in the end entity certificate, 3675 or the application MAY impose requirements on application-specific 3676 extensions. Thus, the path validation algorithm presented in section 3677 6.1 defines the minimum conditions for a path to be considered valid. 3679 The selection of one or more trusted CAs is a local decision. A 3680 system may provide any one of its trusted CAs as the trust anchor for 3681 a particular path. The inputs to the path validation algorithm may 3682 be different for each path. The inputs used to process a path may 3683 reflect application-specific requirements or limitations in the trust 3684 accorded a particular trust anchor. For example, a trusted CA may 3685 only be trusted for a particular certificate policy. This 3686 restriction can be expressed through the inputs to the path 3687 validation procedure. 3689 It is also possible to specify an extended version of the above 3690 certification path processing procedure which results in default 3691 behavior identical to the rules of PEM [RFC 1422]. In this extended 3692 version, additional inputs to the procedure are a list of one or more 3693 Policy Certification Authority (PCA) names and an indicator of the 3694 position in the certification path where the PCA is expected. At the 3695 nominated PCA position, the CA name is compared against this list. 3697 If a recognized PCA name is found, then a constraint of 3698 SubordinateToCA is implicitly assumed for the remainder of the 3699 certification path and processing continues. If no valid PCA name is 3700 found, and if the certification path cannot be validated on the basis 3701 of identified policies, then the certification path is considered 3702 invalid. 3704 6.3 CRL Validation 3706 This section describes the steps necessary to determine if a 3707 certificate is revoked or on hold status when CRLs are the revocation 3708 mechanism used by the certificate issuer. Conforming implementations 3709 that support CRLs are not required to implement this algorithm, but 3710 they MUST be functionally equivalent to the external behavior 3711 resulting from this procedure. Any algorithm may be used by a 3712 particular implementation so long as it derives the correct result. 3714 This algorithm assumes that all of the needed CRLs are available in a 3715 local cache. Further, if the next update time of a CRL has passed, 3716 the algorithm assumes a mechanism to fetch a current CRL and place it 3717 in the local CRL cache. 3719 This algorithm defines a set of inputs, a set of state variables, and 3720 processing steps that are performed for each certificate in the path. 3721 The algorithm output is the revocation status of the certificate. 3723 6.3.1 Revocation Inputs 3725 To support revocation processing, the algorithm requires two inputs: 3727 (a) certificate: The algorithm requires the certificate serial 3728 number and issuer name to determine whether a certificate is on a 3729 particular CRL. The basicConstraints extension is used to 3730 determine whether the supplied certificate is associated with a CA 3731 or an end entity. If present, the algorithm uses the 3732 cRLDistributionsPoint and freshestCRL extensions to determine 3733 revocation status. 3735 (b) use-deltas: This boolean input determines whether delta CRLs 3736 are applied to CRLs. 3738 Note that implementations supporting legacy PKIs, such as RFC 1422 3739 and X.509 version 1, will need an additional input indicating 3740 whether the supplied certificate is associated with a CA or an end 3741 entity. 3743 6.3.2 Initialization and Revocation State Variables 3745 To support CRL processing, the algorithm requires the following state 3746 variables: 3748 (a) reasons_mask: This variable contains the set of revocation 3749 reasons supported by the CRLs and delta CRLs processed so far. 3750 The legal members of the set are the possible revocation reason 3751 values: unspecified, keyCompromise, caCompromise, 3752 affiliationChanged, superseded, cessationOfOperation, 3753 certificateHold, privilegeWithdrawn, and aACompromise. The 3754 special value all-reasons is used to denote the set of all legal 3755 members. This variable is initialized to the empty set. 3757 (b) cert_status: This variable contains the status of the 3758 certificate. This variable may be assigned one of the following 3759 values: unspecified, keyCompromise, caCompromise, 3760 affiliationChanged, superseded, cessationOfOperation, 3761 certificateHold, removeFromCRL, privilegeWithdrawn, aACompromise, 3762 the special value UNREVOKED, or the special value UNDETERMINED. 3763 This variable is initialized to the special value UNREVOKED. 3765 (c) interim_reasons_mask: This contains the set of revocation 3766 reasons supported by the CRL or delta CRL currently being 3767 processed. 3769 Note: In some environments, it is not necessary to check all reason 3770 codes. For example, some environments are only concerned with 3771 caCompromise and keyCompromise for CA certificates. This algorithm 3772 checks all reason codes. Additional processing and state variables 3773 may be necessary to limit the checking to a subset of the reason 3774 codes. 3776 6.3.3 CRL Processing 3778 This algorithm begins by assuming the certificate is not revoked. 3779 The algorithm checks one or more CRLs until either the certificate 3780 status is determined to be revoked or sufficient CRLs have been 3781 checked to cover all reason codes. 3783 For each distribution point (DP) in the certificate CRL distribution 3784 points extension, for each corresponding CRL in the local CRL cache, 3785 while ((reasons_mask is not all-reasons) and 3786 (cert_status is UNREVOKED)) perform the following: 3788 (a) Update the local CRL cache by obtaining a complete CRL, a 3789 delta CRL, or both, as required: 3791 (1) If the current time is after the value of the CRL next 3792 update field, then do one of the following: 3794 (i) If use-deltas is set and either the certificate or the 3795 CRL contains the freshest CRL extension, obtain a delta CRL 3796 with the a next update value that is after the current time 3797 and can be used to update the locally cached CRL as 3798 specified in section 5.2.4. 3800 (ii) Update the local CRL cache with a current complete 3801 CRL, verify that the current time is before the next update 3802 value in the new CRL, and continue processing with the new 3803 CRL. If use-deltas is set, then obtain the current delta 3804 CRL that can be used to update the new locally cached 3805 complete CRL as specified in section 5.2.4. 3807 (2) If the current time is before the value of the next update 3808 field and use-deltas is set, then obtain the current delta CRL 3809 that can be used to update the locally cached complete CRL as 3810 specified in section 5.2.4. 3812 (b) Verify the issuer and scope of the complete CRL as follows: 3814 (1) If the DP includes cRLIssuer, then verify that the issuer 3815 field in the complete CRL matches cRLIssuer in the DP and that 3816 the complete CRL contains an issuing distribution point 3817 extension with the indrectCRL boolean asserted. Otherwise, 3818 verify that the CRL issuer matches the certificate issuer. 3820 (2) If the complete CRL includes an issuing distribution point 3821 (IDP) CRL extension check the following: 3823 (i) If the distribution point name is present in the IDP 3824 CRL extension and the distribution field is present in the 3825 DP, then verify that one of the names in the IDP matches one 3826 of the names in the DP. If the distribution point name is 3827 present in the IDP CRL extension and the distribution field 3828 is omitted from the DP, then verify that one of the names in 3829 the IDP matches one of the names in the cRLIssuer field of 3830 the DP. 3832 (ii) If the onlyContainsUserCerts boolean is asserted in 3833 the IDP CRL extension, verify that the certificate does not 3834 include the basic constraints extension with the cA boolean 3835 asserted. 3837 (iii) If the onlyContainsCACerts boolean is asserted in the 3838 IDP CRL extension, verify that the certificate includes the 3839 basic constraints extension with the cA boolean asserted. 3841 (iv) Verify that the onlyContainsAttributeCerts boolean is 3842 not asserted. 3844 (c) If use-deltas is set, verify the issuer and scope of the 3845 delta CRL as follows: 3847 (1) Verify that the delta CRL issuer matches complete CRL 3848 issuer. 3850 (2) If the complete CRL includes an issuing distribution point 3851 (IDP) CRL extension, verify that the delta CRL contains a 3852 matching IDP CRL extension. If the complete CRL omits an IDP 3853 CRL extension, verify that the delta CRL also omits an IDP CRL 3854 extension. 3856 (3) Verify that the delta CRL authority key identifier 3857 extension matches complete CRL authority key identifier 3858 extension. 3860 (d) Compute the interim_reasons_mask for this CRL as follows: 3862 (1) If the issuing distribution point (IDP) CRL extension is 3863 present and includes onlySomeReasons and the DP includes 3864 reasons, then set interim_reasons_mask to the intersection of 3865 reasons in the DP and onlySomeReasons in IDP CRL extension. 3867 (2) If the IDP CRL extension includes onlySomeReasons but the 3868 DP omits reasons, then set interim_reasons_mask to the value of 3869 onlySomeReasons in IDP CRL extension. 3871 (3) If the IDP CRL extension is not present or omits 3872 onlySomeReasons but the DP includes reasons, then set 3873 interim_reasons_mask to the value of DP reasons. 3875 (4) If the IDP CRL extension is not present or omits 3876 onlySomeReasons and the DP omits reasons, then set 3877 interim_reasons_mask to the special value all-reasons. 3879 (e) Verify that interim_reasons_mask includes one or more reasons 3880 that is not included in the reasons_mask. 3882 (f) Obtain and validate the certification path for the complete 3883 CRL issuer. 3885 (g) Validate the signature on the complete CRL using the public 3886 key validated in step (f). 3888 (h) If use-deltas is set, then validate the signature on the 3889 delta CRL using the public key validated in step (f). 3891 (i) If use-deltas is set, then search for the certificate on the 3892 delta CRL. If an entry is found that matches the certificate 3893 issuer and serial number as described in section 5.3.4, then set 3894 the cert_status variable to the indicated reason as follows: 3896 (1) If the reason code CRL entry extension is present, set the 3897 cert_status variable to the value of the reason code CRL entry 3898 extension. 3900 (2) If the reason code CRL entry extension is not present, set 3901 the cert_status variable to the value unspecified. 3903 (j) If (cert_status is UNREVOKED), then search for the 3904 certificate on the complete CRL. If an entry is found that 3905 matches the certificate issuer and serial number as described in 3906 section 5.3.4, then set the cert_status variable to the indicated 3907 reason as described in step (i). 3909 (k) If (cert_status is removeFromCRL), then set cert_status to 3910 UNREVOKED. 3912 If ((reasons_mask is all-reasons) OR (cert_status is not UNREVOKED)), 3913 then the revocation status has been determined, so return 3914 cert_status. 3916 If the revocation status has not been determined, repeat the process 3917 above with any available CRLs not specified in a distribution point 3918 but issued by the certificate issuer. For the processing of such a 3919 CRL, assume a DP with both the reasons and the cRLIssuer fields 3920 omitted and a distribution point name of the certificate issuer. 3921 That is, the sequence of names in fullName is generated from the 3922 certificate issuer field as well as the certificate issuerAltName 3923 extension. If the revocation status remains undetermined, then 3924 return the cert_status UNDETERMINED. 3926 7 References 3928 [ISO 10646] ISO/IEC 10646-1:1993. International Standard -- 3929 Information technology -- Universal Multiple-Octet Coded 3930 Character Set (UCS) -- Part 1: Architecture and Basic 3931 Multilingual Plane. 3933 [RFC 791] Postel, J., "Internet Protocol", RFC 791, 3934 September 1981. 3936 [RFC 822] Crocker, D., "Standard for the format of ARPA Internet 3937 text messages", RFC 822, August 1982. 3939 [RFC 1034] Mockapetris, P.V., "Domain names - concepts and 3940 facilities", RFC 1034, November 1987. 3942 [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic 3943 Mail: Part II: Certificate-Based Key Management," 3944 RFC 1422, February 1993. 3946 [RFC 1423] Balenson, D., "Privacy Enhancement for Internet 3947 Electronic Mail: Part III: Algorithms, Modes, and 3948 Identifiers," RFC 1423, February 1993. 3950 [RFC 1510] Kohl, J., and C. Neuman, "The Kerberos Network 3951 Authentication Service (V5)," RFC 1510, September 1993. 3953 [RFC 1519] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless 3954 Inter-Domain Routing (CIDR): An Address Assignment and 3955 Aggregation Strategy", RFC 1519, September 1993. 3957 [RFC 1738] Berners-Lee, T., L. Masinter, and M. McCahill, 3958 "Uniform Resource Locators (URL)", RFC 1738, 3959 December 1994. 3961 [RFC 1778] Howes, T., S. Kille, W. Yeong, and C. Robbins, "The 3962 String Representation of Standard Attribute Syntaxes," 3963 RFC 1778, March 1995. 3965 [RFC 1883] Deering, S., and R. Hinden. "Internet Protocol, 3966 Version 6 (IPv6) Specification", RFC 1883, December 3967 1995. 3969 [RFC 2044] F. Yergeau, F., "UTF-8, a transformation format of 3970 Unicode and ISO 10646", RFC 2044, October 1996. 3972 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 3973 Requirement Levels", RFC 2119, March 1997. 3975 [RFC 2247] Kille, S., M. Wahl, A. Grimstad, R. Huber, and 3976 S. Sataluri, "Using Domains in LDAP/X.500 3977 Distinguished Names", RFC 2247, January 1998. 3979 [RFC 2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille, 3980 "Lightweight Directory Access Protocol (v3): 3981 Attribute Syntax Definitions", RFC 2252, 3982 December 1997. 3984 [RFC 2277] Alvestrand, H., "IETF Policy on Character Sets and 3985 Languages", January 1998. 3987 [RFC 2279] Yergeau, F., "UTF-8, a transformation format of 3988 ISO 10646", RFC 2279, January 1998. 3990 [RFC 2459] Housley, R., W. Ford, W. Polk, and D. Solo, "Internet 3991 X.509 Public Key Infrastructure: Certificate and CRL 3992 Profile", RFC 2459, January 1999. 3994 [RFC 2560] Myers, M., R. Ankney, A. Malpani, S. Galperin, and 3995 C. Adams, "Online Certificate Status Protocal - OCSP", 3996 June 1999. 3998 [SDN.701] SDN.701, "Message Security Protocol 4.0", Revision A, 3999 1997-02-06. 4001 [X.208] CCITT Recommendation X.208: Specification of Abstract 4002 Syntax Notation One (ASN.1), 1988. 4004 [X.501] ITU-T Recommendation X.501: Information 4005 Technology - Open Systems Interconnection - The 4006 Directory: Models, 1993. 4008 [X.509] ITU-T Recommendation X.509 (1997 E): Information 4009 Technology - Open Systems Interconnection - The 4010 Directory: Authentication Framework, June 1997. 4012 [X.520] ITU-T Recommendation X.520: Information 4013 Technology - Open Systems Interconnection - The 4014 Directory: Selected Attribute Types, 1993. 4016 [X.660] ITU-T Recommendation X.660 Information 4017 Technology - Open Systems Interconnection - 4018 Procedures for the operation of OSI 4019 Registration Authorities: General procedures, 1992. 4021 [X9.55] ANSI X9.55-1995, Public Key Cryptography For The 4022 Financial Services Industry: Extensions To Public 4023 Key Certificates And Certificate Revocation Lists, 4024 8 December, 1995. 4026 [PKIXALGS] Bassham, L., R. Housley, and W. Polk, "Internet X.509 4027 Public Key Infrastructure Representation of Public Keys 4028 and Digital Signatures," 4029 draft-ietf-pkix-ipki-pkalgs-02.txt, March 2001. 4031 [PKIXTSA] Cain, P., D. Pinkas, and R. Zuccherato, "Internet 4032 X.509 Public Key Infrastructure Time Stamp Protocol," 4033 draft-ietf-pkix-time-stamp-13.txt, January 2001. 4035 8 Intellectual Property Rights 4037 The IETF has been notified of intellectual property rights claimed in 4038 regard to some or all of the specification contained in this 4039 document. For more information consult the online list of claimed 4040 rights (see http://www.ietf.org/ipr.html). 4042 The IETF takes no position regarding the validity or scope of any 4043 intellectual property or other rights that might be claimed to 4044 pertain to the implementation or use of the technology described in 4045 this document or the extent to which any license under such rights 4046 might or might not be available; neither does it represent that it 4047 has made any effort to identify any such rights. Information on the 4048 IETF's procedures with respect to rights in standards-track and 4049 standards-related documentation can be found in BCP-11. Copies of 4050 claims of rights made available for publication and any assurances of 4051 licenses to be made available, or the result of an attempt made to 4052 obtain a general license or permission for the use of such 4053 proprietary rights by implementors or users of this specification can 4054 be obtained from the IETF Secretariat. 4056 9 Security Considerations 4058 The majority of this specification is devoted to the format and 4059 content of certificates and CRLs. Since certificates and CRLs are 4060 digitally signed, no additional integrity service is necessary. 4061 Neither certificates nor CRLs need be kept secret, and unrestricted 4062 and anonymous access to certificates and CRLs has no security 4063 implications. 4065 However, security factors outside the scope of this specification 4066 will affect the assurance provided to certificate users. This 4067 section highlights critical issues to be considered by implementers, 4068 administrators, and users. 4070 The procedures performed by CAs and RAs to validate the binding of 4071 the subject's identity to their public key greatly affect the 4072 assurance that ought to be placed in the certificate. Relying 4073 parties might wish to review the CA's certificate practice statement. 4074 This is particularly important when issuing certificates to other 4075 CAs. 4077 The use of a single key pair for both signature and other purposes is 4078 strongly discouraged. Use of separate key pairs for signature and 4079 key management provides several benefits to the users. The 4080 ramifications associated with loss or disclosure of a signature key 4081 are different from loss or disclosure of a key management key. Using 4082 separate key pairs permits a balanced and flexible response. 4083 Similarly, different validity periods or key lengths for each key 4084 pair may be appropriate in some application environments. 4085 Unfortunately, some legacy applications (e.g., SSL) use a single key 4086 pair for signature and key management. 4088 The protection afforded private keys is a critical security factor. 4089 On a small scale, failure of users to protect their private keys will 4090 permit an attacker to masquerade as them, or decrypt their personal 4091 information. On a larger scale, compromise of a CA's private signing 4092 key may have a catastrophic effect. If an attacker obtains the 4093 private key unnoticed, the attacker may issue bogus certificates and 4094 CRLs. Existence of bogus certificates and CRLs will undermine 4095 confidence in the system. If such a compromise is detected, all 4096 certificates issued to the compromised CA MUST be revoked, preventing 4097 services between its users and users of other CAs. Rebuilding after 4098 such a compromise will be problematic, so CAs are advised to 4099 implement a combination of strong technical measures (e.g., tamper- 4100 resistant cryptographic modules) and appropriate management 4101 procedures (e.g., separation of duties) to avoid such an incident. 4103 Loss of a CA's private signing key may also be problematic. The CA 4104 would not be able to produce CRLs or perform normal key rollover. 4105 CAs SHOULD maintain secure backup for signing keys. The security of 4106 the key backup procedures is a critical factor in avoiding key 4107 compromise. 4109 The availability and freshness of revocation information affects the 4110 degree of assurance that ought to be placed in a certificate. While 4111 certificates expire naturally, events may occur during its natural 4112 lifetime which negate the binding between the subject and public key. 4113 If revocation information is untimely or unavailable, the assurance 4114 associated with the binding is clearly reduced. Relying parties 4115 might not be able to process every critical extension that can appear 4116 in a CRL. CAs SHOULD take extra care when making revocation 4117 information available only through CRLs that contain critical 4118 extensions, particularly if support for those extensions is not 4119 mandated by this profile. For example, if revocation information is 4120 supplied using a combination of delta CRLs and full CRLs, and the 4121 delta CRLs are issued more frequently than the full CRLs, then 4122 relying parties that cannot handle the critical extensions related to 4123 delta CRL processing will not be able to obtain the most recent 4124 revocation information. Alternatively, if a full CRL is issued 4125 whenever a delta CRL is issued, then timely revocation information 4126 will be available to all relying parties. Similarly, implementations 4127 of the certification path validation mechanism described in section 6 4128 that omit revocation checking provide less assurance than those that 4129 support it. 4131 The path validation algorithm depends on the certain knowledge of the 4132 public keys (and other information) about one or more trusted CAs. 4133 The decision to trust a CA is an important decision as it ultimately 4134 determines the trust afforded a certificate. The authenticated 4135 distribution of trusted CA public keys (usually in the form of a 4136 "self-signed" certificate) is a security critical out-of-band process 4137 that is beyond the scope of this specification. 4139 In addition, where a key compromise or CA failure occurs for a 4140 trusted CA, the user will need to modify the information provided to 4141 the path validation routine. Selection of too many trusted CAs makes 4142 the trusted CA information difficult to maintain. On the other hand, 4143 selection of only one trusted CA could limit users to a closed 4144 community of users. 4146 The quality of implementations that process certificates also affects 4147 the degree of assurance provided. The path validation algorithm 4148 described in section 6 relies upon the integrity of the trusted CA 4149 information, and especially the integrity of the public keys 4150 associated with the trusted CAs. By substituting public keys for 4151 which an attacker has the private key, an attacker could trick the 4152 user into accepting false certificates. 4154 The binding between a key and certificate subject cannot be stronger 4155 than the cryptographic module implementation and algorithms used to 4156 generate the signature. Short key lengths or weak hash algorithms 4157 will limit the utility of a certificate. CAs are encouraged to note 4158 advances in cryptology so they can employ strong cryptographic 4159 techniques. In addition, CAs SHOULD decline to issue certificates to 4160 CAs or end entities that generate weak signatures. 4162 Inconsistent application of name comparison rules can result in 4163 acceptance of invalid X.509 certification paths, or rejection of 4164 valid ones. The X.500 series of specifications defines rules for 4165 comparing distinguished names that require comparison of strings 4166 without regard to case, character set, multi-character white space 4167 substring, or leading and trailing white space. This specification 4168 relaxes these requirements, requiring support for binary comparison 4169 at a minimum. 4171 CAs MUST encode the distinguished name in the subject field of a CA 4172 certificate identically to the distinguished name in the issuer field 4173 in certificates issued by that CA. If CAs use different encodings, 4174 implementations might fail to recognize name chains for paths that 4175 include this certificate. As a consequence, valid paths could be 4176 rejected. 4178 In addition, name constraints for distinguished names MUST be stated 4179 identically to the encoding used in the subject field or 4180 subjectAltName extension. If not, then name constraints stated as 4181 excludedSubTrees will not match and invalid paths will be accepted 4182 and name constraints expressed as permittedSubtrees will not match 4183 and valid paths will be rejected. To avoid acceptance of invalid 4184 paths, CAs SHOULD state name constraints for distinguished names as 4185 permittedSubtrees wherever possible. 4187 Appendix A. Psuedo-ASN.1 Structures and OIDs 4189 This section describes data objects used by conforming PKI components 4190 in an "ASN.1-like" syntax. This syntax is a hybrid of the 1988 and 4191 1993 ASN.1 syntaxes. The 1988 ASN.1 syntax is augmented with 1993 4192 UNIVERSAL Types UniversalString, BMPString and UTF8String. 4194 The ASN.1 syntax does not permit the inclusion of type statements in 4195 the ASN.1 module, and the 1993 ASN.1 standard does not permit use of 4196 the new UNIVERSAL types in modules using the 1988 syntax. As a 4197 result, this module does not conform to either version of the ASN.1 4198 standard. 4200 This appendix may be converted into 1988 ASN.1 by replacing the 4201 defintions for the UNIVERSAL Types with the 1988 catch-all "ANY". 4203 A.1 Explicitly Tagged Module, 1988 Syntax 4205 PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) 4206 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) } 4208 DEFINITIONS EXPLICIT TAGS ::= 4210 BEGIN 4212 -- EXPORTS ALL -- 4214 -- IMPORTS NONE -- 4216 -- UNIVERSAL Types defined in 1993 and 1998 ASN.1 4217 -- and required by this specification 4219 UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING 4220 -- UniversalString is defined in ASN.1:1993 4222 BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING 4223 -- BMPString is the subtype of UniversalString and models 4224 -- the Basic Multilingual Plane of ISO/IEC/ITU 10646-1 4226 UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 4227 -- The content of this type conforms to RFC 2279. 4229 -- PKIX specific OIDs 4231 id-pkix OBJECT IDENTIFIER ::= 4232 { iso(1) identified-organization(3) dod(6) internet(1) 4233 security(5) mechanisms(5) pkix(7) } 4235 -- PKIX arcs 4237 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 4238 -- arc for private certificate extensions 4239 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 4240 -- arc for policy qualifier types 4241 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 4242 -- arc for extended key purpose OIDS 4243 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 4244 -- arc for access descriptors 4246 -- policyQualifierIds for Internet policy qualifiers 4248 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 4249 -- OID for CPS qualifier 4250 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 4251 -- OID for user notice qualifier 4253 -- access descriptor definitions 4255 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 4256 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 4257 id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 } 4258 id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 } 4260 -- attribute data types 4262 Attribute ::= SEQUENCE { 4263 type AttributeType, 4264 values SET OF AttributeValue } 4265 -- at least one value is required 4267 AttributeType ::= OBJECT IDENTIFIER 4269 AttributeValue ::= ANY 4271 AttributeTypeAndValue ::= SEQUENCE { 4272 type AttributeType, 4273 value AttributeValue } 4275 -- suggested naming attributes: Definition of the following 4276 -- information object set may be augmented to meet local 4277 -- requirements. Note that deleting members of the set may 4278 -- prevent interoperability with conforming implementations. 4279 -- presented in pairs: the AttributeType followed by the 4280 -- type definition for the corresponding AttributeValue 4282 --Arc for standard naming attributes 4283 id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 } 4285 -- Naming attributes of type X520name 4287 id-at-name AttributeType ::= { id-at 41 } 4288 id-at-surname AttributeType ::= { id-at 4 } 4289 id-at-givenName AttributeType ::= { id-at 42 } 4290 id-at-initials AttributeType ::= { id-at 43 } 4291 id-at-generationQualifier AttributeType ::= { id-at 44 } 4293 X520name ::= CHOICE { 4294 teletexString TeletexString (SIZE (1..ub-name)), 4295 printableString PrintableString (SIZE (1..ub-name)), 4296 universalString UniversalString (SIZE (1..ub-name)), 4297 utf8String UTF8String (SIZE (1..ub-name)), 4298 bmpString BMPString (SIZE (1..ub-name)) } 4300 -- Naming attributes of type X520CommonName 4302 id-at-commonName AttributeType ::= { id-at 3 } 4304 X520CommonName ::= CHOICE { 4305 teletexString TeletexString (SIZE (1..ub-common-name)), 4306 printableString PrintableString (SIZE (1..ub-common-name)), 4307 universalString UniversalString (SIZE (1..ub-common-name)), 4308 utf8String UTF8String (SIZE (1..ub-common-name)), 4309 bmpString BMPString (SIZE (1..ub-common-name)) } 4311 -- Naming attributes of type X520LocalityName 4313 id-at-localityName AttributeType ::= { id-at 7 } 4315 X520LocalityName ::= CHOICE { 4316 teletexString TeletexString (SIZE (1..ub-locality-name)), 4317 printableString PrintableString (SIZE (1..ub-locality-name)), 4318 universalString UniversalString (SIZE (1..ub-locality-name)), 4319 utf8String UTF8String (SIZE (1..ub-locality-name)), 4320 bmpString BMPString (SIZE (1..ub-locality-name)) } 4322 -- Naming attributes of type X520StateOrProvinceName 4324 id-at-stateOrProvinceName AttributeType ::= { id-at 8 } 4326 X520StateOrProvinceName ::= CHOICE { 4327 teletexString TeletexString (SIZE (1..ub-state-name)), 4328 printableString PrintableString (SIZE (1..ub-state-name)), 4329 universalString UniversalString (SIZE (1..ub-state-name)), 4330 utf8String UTF8String (SIZE (1..ub-state-name)), 4331 bmpString BMPString (SIZE(1..ub-state-name)) } 4333 -- Naming attributes of type X520OrganizationName 4335 id-at-organizationName AttributeType ::= { id-at 10 } 4337 X520OrganizationName ::= CHOICE { 4338 teletexString TeletexString 4339 (SIZE (1..ub-organization-name)), 4340 printableString PrintableString 4341 (SIZE (1..ub-organization-name)), 4342 universalString UniversalString 4343 (SIZE (1..ub-organization-name)), 4344 utf8String UTF8String 4345 (SIZE (1..ub-organization-name)), 4346 bmpString BMPString 4347 (SIZE (1..ub-organization-name)) } 4349 -- Naming attributes of type X520OrganizationalUnitName 4351 id-at-organizationalUnitName AttributeType ::= { id-at 11 } 4353 X520OrganizationalUnitName ::= CHOICE { 4354 teletexString TeletexString 4355 (SIZE (1..ub-organizational-unit-name)), 4356 printableString PrintableString 4357 (SIZE (1..ub-organizational-unit-name)), 4358 universalString UniversalString 4359 (SIZE (1..ub-organizational-unit-name)), 4360 utf8String UTF8String 4361 (SIZE (1..ub-organizational-unit-name)), 4362 bmpString BMPString 4363 (SIZE (1..ub-organizational-unit-name)) } 4365 -- Naming attributes of type X520Title 4367 id-at-title AttributeType ::= { id-at 12 } 4369 X520Title ::= CHOICE { 4370 teletexString TeletexString (SIZE (1..ub-title)), 4371 printableString PrintableString (SIZE (1..ub-title)), 4372 universalString UniversalString (SIZE (1..ub-title)), 4373 utf8String UTF8String (SIZE (1..ub-title)), 4374 bmpString BMPString (SIZE (1..ub-title)) } 4376 -- Naming attributes of type X520dnQualifier 4377 id-at-dnQualifier AttributeType ::= { id-at 46 } 4379 X520dnQualifier ::= PrintableString 4381 -- Naming attributes of type X520countryName (digraph from IS 3166) 4383 id-at-countryName AttributeType ::= { id-at 6 } 4385 X520countryName ::= PrintableString (SIZE (2)) 4387 -- Naming attributes of type X520SerialNumber 4389 id-at-serialNumber AttributeType ::= { id-at 5 } 4391 X520SerialNumber ::= PrintableString (SIZE (1..ub-serial-number)) 4393 -- Naming attributes of type X520Pseudonym 4395 id-at-localityName AttributeType ::= { id-at 65 } 4397 X520Pseudonym ::= CHOICE { 4398 teletexString TeletexString (SIZE (1..ub-pseudonym)), 4399 printableString PrintableString (SIZE (1..ub-pseudonym)), 4400 universalString UniversalString (SIZE (1..ub-pseudonym)), 4401 utf8String UTF8String (SIZE (1..ub-pseudonym)), 4402 bmpString BMPString (SIZE (1..ub-pseudonym)) } 4404 -- Naming attributes of type DomainComponent (from RFC 2247) 4406 id-domainComponent AttributeType ::= 4407 { 0 9 2342 19200300 100 1 25 } 4409 DomainComponent ::= IA5String 4411 -- Legacy attributes 4413 pkcs-9 OBJECT IDENTIFIER ::= 4414 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 } 4416 id-emailAddress AttributeType ::= { pkcs-9 1 } 4418 EmailAddress ::= IA5String (SIZE (1..ub-emailaddress-length)) 4420 -- naming data types -- 4422 Name ::= CHOICE { -- only one possibility for now -- 4423 rdnSequence RDNSequence } 4425 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 4427 DistinguishedName ::= RDNSequence 4429 RelativeDistinguishedName ::= 4430 SET SIZE (1 .. MAX) OF AttributeTypeAndValue 4432 -- Directory string type -- 4434 DirectoryString ::= CHOICE { 4435 teletexString TeletexString (SIZE (1..MAX)), 4436 printableString PrintableString (SIZE (1..MAX)), 4437 universalString UniversalString (SIZE (1..MAX)), 4438 utf8String UTF8String (SIZE (1..MAX)), 4439 bmpString BMPString (SIZE (1..MAX)) } 4441 -- certificate and CRL specific structures begin here 4443 Certificate ::= SEQUENCE { 4444 tbsCertificate TBSCertificate, 4445 signatureAlgorithm AlgorithmIdentifier, 4446 signature BIT STRING } 4448 TBSCertificate ::= SEQUENCE { 4449 version [0] Version DEFAULT v1, 4450 serialNumber CertificateSerialNumber, 4451 signature AlgorithmIdentifier, 4452 issuer Name, 4453 validity Validity, 4454 subject Name, 4455 subjectPublicKeyInfo SubjectPublicKeyInfo, 4456 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 4457 -- If present, version MUST be v2 or v3 4458 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 4459 -- If present, version MUST be v2 or v3 4460 extensions [3] Extensions OPTIONAL 4461 -- If present, version MUST be v3 -- } 4463 Version ::= INTEGER { v1(0), v2(1), v3(2) } 4465 CertificateSerialNumber ::= INTEGER 4467 Validity ::= SEQUENCE { 4468 notBefore Time, 4469 notAfter Time } 4471 Time ::= CHOICE { 4472 utcTime UTCTime, 4473 generalTime GeneralizedTime } 4475 UniqueIdentifier ::= BIT STRING 4477 SubjectPublicKeyInfo ::= SEQUENCE { 4478 algorithm AlgorithmIdentifier, 4479 subjectPublicKey BIT STRING } 4481 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 4483 Extension ::= SEQUENCE { 4484 extnID OBJECT IDENTIFIER, 4485 critical BOOLEAN DEFAULT FALSE, 4486 extnValue OCTET STRING } 4488 -- CRL structures 4490 CertificateList ::= SEQUENCE { 4491 tbsCertList TBSCertList, 4492 signatureAlgorithm AlgorithmIdentifier, 4493 signature BIT STRING } 4495 TBSCertList ::= SEQUENCE { 4496 version Version OPTIONAL, 4497 -- if present, MUST be v2 4498 signature AlgorithmIdentifier, 4499 issuer Name, 4500 thisUpdate Time, 4501 nextUpdate Time OPTIONAL, 4502 revokedCertificates SEQUENCE OF SEQUENCE { 4503 userCertificate CertificateSerialNumber, 4504 revocationDate Time, 4505 crlEntryExtensions Extensions OPTIONAL 4506 -- if present, MUST be v2 4507 } OPTIONAL, 4508 crlExtensions [0] Extensions OPTIONAL 4509 -- if present, MUST be v2 -- } 4511 -- Version, Time, CertificateSerialNumber, and Extensions were 4512 -- defined earlier for use in the certificate structure 4514 AlgorithmIdentifier ::= SEQUENCE { 4515 algorithm OBJECT IDENTIFIER, 4516 parameters ANY DEFINED BY algorithm OPTIONAL } 4517 -- contains a value of the type 4518 -- registered for use with the 4519 -- algorithm object identifier value 4521 -- X.400 address syntax starts here 4523 ORAddress ::= SEQUENCE { 4524 built-in-standard-attributes BuiltInStandardAttributes, 4525 built-in-domain-defined-attributes 4526 BuiltInDomainDefinedAttributes OPTIONAL, 4527 -- see also teletex-domain-defined-attributes 4528 extension-attributes ExtensionAttributes OPTIONAL } 4529 -- [[[*** What is this comment about? OR-Name is not defined ***]]] 4530 -- The OR-address is semantically absent from the OR-name if the 4531 -- built-in-standard-attribute sequence is empty and the 4532 -- built-in-domain-defined-attributes and extension-attributes are 4533 -- both omitted. 4535 -- Built-in Standard Attributes 4537 BuiltInStandardAttributes ::= SEQUENCE { 4538 country-name CountryName OPTIONAL, 4539 administration-domain-name AdministrationDomainName OPTIONAL, 4540 network-address [0] NetworkAddress OPTIONAL, 4541 -- see also extended-network-address 4542 terminal-identifier [1] TerminalIdentifier OPTIONAL, 4543 private-domain-name [2] PrivateDomainName OPTIONAL, 4544 organization-name [3] OrganizationName OPTIONAL, 4545 -- see also teletex-organization-name 4546 numeric-user-identifier [4] NumericUserIdentifier OPTIONAL, 4547 personal-name [5] PersonalName OPTIONAL, 4548 -- see also teletex-personal-name 4549 organizational-unit-names [6] OrganizationalUnitNames OPTIONAL 4550 -- see also teletex-organizational-unit-names -- } 4552 CountryName ::= [APPLICATION 1] CHOICE { 4553 x121-dcc-code NumericString 4554 (SIZE (ub-country-name-numeric-length)), 4555 iso-3166-alpha2-code PrintableString 4556 (SIZE (ub-country-name-alpha-length)) } 4558 AdministrationDomainName ::= [APPLICATION 2] CHOICE { 4559 numeric NumericString (SIZE (0..ub-domain-name-length)), 4560 printable PrintableString (SIZE (0..ub-domain-name-length)) } 4562 NetworkAddress ::= X121Address -- see also extended-network-address 4564 X121Address ::= NumericString (SIZE (1..ub-x121-address-length)) 4566 TerminalIdentifier ::= PrintableString (SIZE (1..ub-terminal-id-length)) 4567 PrivateDomainName ::= CHOICE { 4568 numeric NumericString (SIZE (1..ub-domain-name-length)), 4569 printable PrintableString (SIZE (1..ub-domain-name-length)) } 4571 OrganizationName ::= PrintableString 4572 (SIZE (1..ub-organization-name-length)) 4573 -- see also teletex-organization-name 4575 NumericUserIdentifier ::= NumericString 4576 (SIZE (1..ub-numeric-user-id-length)) 4578 PersonalName ::= SET { 4579 surname [0] PrintableString (SIZE (1..ub-surname-length)), 4580 given-name [1] PrintableString 4581 (SIZE (1..ub-given-name-length)) OPTIONAL, 4582 initials [2] PrintableString (SIZE (1..ub-initials-length)) OPTIONAL, 4583 generation-qualifier [3] PrintableString 4584 (SIZE (1..ub-generation-qualifier-length)) OPTIONAL } 4585 -- see also teletex-personal-name 4587 OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units) 4588 OF OrganizationalUnitName 4589 -- see also teletex-organizational-unit-names 4591 OrganizationalUnitName ::= PrintableString (SIZE 4592 (1..ub-organizational-unit-name-length)) 4594 -- Built-in Domain-defined Attributes 4596 BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE 4597 (1..ub-domain-defined-attributes) OF 4598 BuiltInDomainDefinedAttribute 4600 BuiltInDomainDefinedAttribute ::= SEQUENCE { 4601 type PrintableString (SIZE 4602 (1..ub-domain-defined-attribute-type-length)), 4603 value PrintableString (SIZE 4604 (1..ub-domain-defined-attribute-value-length)) } 4606 -- Extension Attributes 4608 ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF 4609 ExtensionAttribute 4611 ExtensionAttribute ::= SEQUENCE { 4612 extension-attribute-type [0] INTEGER (0..ub-extension-attributes), 4613 extension-attribute-value [1] 4614 ANY DEFINED BY extension-attribute-type } 4616 -- Extension types and attribute values 4618 common-name INTEGER ::= 1 4620 CommonName ::= PrintableString (SIZE (1..ub-common-name-length)) 4622 teletex-common-name INTEGER ::= 2 4624 TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length)) 4626 teletex-organization-name INTEGER ::= 3 4628 TeletexOrganizationName ::= 4629 TeletexString (SIZE (1..ub-organization-name-length)) 4631 teletex-personal-name INTEGER ::= 4 4633 TeletexPersonalName ::= SET { 4634 surname [0] TeletexString (SIZE (1..ub-surname-length)), 4635 given-name [1] TeletexString 4636 (SIZE (1..ub-given-name-length)) OPTIONAL, 4637 initials [2] TeletexString (SIZE (1..ub-initials-length)) OPTIONAL, 4638 generation-qualifier [3] TeletexString (SIZE 4639 (1..ub-generation-qualifier-length)) OPTIONAL } 4641 teletex-organizational-unit-names INTEGER ::= 5 4643 TeletexOrganizationalUnitNames ::= SEQUENCE SIZE 4644 (1..ub-organizational-units) OF TeletexOrganizationalUnitName 4646 TeletexOrganizationalUnitName ::= TeletexString 4647 (SIZE (1..ub-organizational-unit-name-length)) 4649 pds-name INTEGER ::= 7 4651 PDSName ::= PrintableString (SIZE (1..ub-pds-name-length)) 4653 physical-delivery-country-name INTEGER ::= 8 4655 PhysicalDeliveryCountryName ::= CHOICE { 4656 x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)), 4657 iso-3166-alpha2-code PrintableString 4658 (SIZE (ub-country-name-alpha-length)) } 4660 postal-code INTEGER ::= 9 4662 PostalCode ::= CHOICE { 4663 numeric-code NumericString (SIZE (1..ub-postal-code-length)), 4664 printable-code PrintableString (SIZE (1..ub-postal-code-length)) } 4666 physical-delivery-office-name INTEGER ::= 10 4668 PhysicalDeliveryOfficeName ::= PDSParameter 4670 physical-delivery-office-number INTEGER ::= 11 4672 PhysicalDeliveryOfficeNumber ::= PDSParameter 4674 extension-OR-address-components INTEGER ::= 12 4676 ExtensionORAddressComponents ::= PDSParameter 4678 physical-delivery-personal-name INTEGER ::= 13 4680 PhysicalDeliveryPersonalName ::= PDSParameter 4682 physical-delivery-organization-name INTEGER ::= 14 4684 PhysicalDeliveryOrganizationName ::= PDSParameter 4686 extension-physical-delivery-address-components INTEGER ::= 15 4688 ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter 4690 unformatted-postal-address INTEGER ::= 16 4692 UnformattedPostalAddress ::= SET { 4693 printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) OF 4694 PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL, 4695 teletex-string TeletexString 4696 (SIZE (1..ub-unformatted-address-length)) OPTIONAL } 4698 street-address INTEGER ::= 17 4700 StreetAddress ::= PDSParameter 4702 post-office-box-address INTEGER ::= 18 4704 PostOfficeBoxAddress ::= PDSParameter 4706 poste-restante-address INTEGER ::= 19 4708 PosteRestanteAddress ::= PDSParameter 4710 unique-postal-name INTEGER ::= 20 4711 UniquePostalName ::= PDSParameter 4713 local-postal-attributes INTEGER ::= 21 4715 LocalPostalAttributes ::= PDSParameter 4717 PDSParameter ::= SET { 4718 printable-string PrintableString 4719 (SIZE(1..ub-pds-parameter-length)) OPTIONAL, 4720 teletex-string TeletexString 4721 (SIZE(1..ub-pds-parameter-length)) OPTIONAL } 4723 extended-network-address INTEGER ::= 22 4725 ExtendedNetworkAddress ::= CHOICE { 4726 e163-4-address SEQUENCE { 4727 number [0] NumericString (SIZE (1..ub-e163-4-number-length)), 4728 sub-address [1] NumericString 4729 (SIZE (1..ub-e163-4-sub-address-length)) OPTIONAL }, 4730 psap-address [0] PresentationAddress } 4732 PresentationAddress ::= SEQUENCE { 4733 pSelector [0] EXPLICIT OCTET STRING OPTIONAL, 4734 sSelector [1] EXPLICIT OCTET STRING OPTIONAL, 4735 tSelector [2] EXPLICIT OCTET STRING OPTIONAL, 4736 nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING } 4738 terminal-type INTEGER ::= 23 4740 TerminalType ::= INTEGER { 4741 telex (3), 4742 teletex (4), 4743 g3-facsimile (5), 4744 g4-facsimile (6), 4745 ia5-terminal (7), 4746 videotex (8) } (0..ub-integer-options) 4748 -- Extension Domain-defined Attributes 4750 teletex-domain-defined-attributes INTEGER ::= 6 4752 TeletexDomainDefinedAttributes ::= SEQUENCE SIZE 4753 (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute 4755 TeletexDomainDefinedAttribute ::= SEQUENCE { 4756 type TeletexString 4757 (SIZE (1..ub-domain-defined-attribute-type-length)), 4758 value TeletexString 4759 (SIZE (1..ub-domain-defined-attribute-value-length)) } 4761 -- specifications of Upper Bounds MUST be regarded as mandatory 4762 -- from Annex B of ITU-T X.411 Reference Definition of MTS Parameter 4763 -- Upper Bounds 4765 -- Upper Bounds 4766 ub-name INTEGER ::= 32768 4767 ub-common-name INTEGER ::= 64 4768 ub-locality-name INTEGER ::= 128 4769 ub-state-name INTEGER ::= 128 4770 ub-organization-name INTEGER ::= 64 4771 ub-organizational-unit-name INTEGER ::= 64 4772 ub-title INTEGER ::= 64 4773 ub-serial-number INTEGER ::= 64 4774 ub-match INTEGER ::= 128 4775 ub-emailaddress-length INTEGER ::= 128 4776 ub-common-name-length INTEGER ::= 64 4777 ub-country-name-alpha-length INTEGER ::= 2 4778 ub-country-name-numeric-length INTEGER ::= 3 4779 ub-domain-defined-attributes INTEGER ::= 4 4780 ub-domain-defined-attribute-type-length INTEGER ::= 8 4781 ub-domain-defined-attribute-value-length INTEGER ::= 128 4782 ub-domain-name-length INTEGER ::= 16 4783 ub-extension-attributes INTEGER ::= 256 4784 ub-e163-4-number-length INTEGER ::= 15 4785 ub-e163-4-sub-address-length INTEGER ::= 40 4786 ub-generation-qualifier-length INTEGER ::= 3 4787 ub-given-name-length INTEGER ::= 16 4788 ub-initials-length INTEGER ::= 5 4789 ub-integer-options INTEGER ::= 256 4790 ub-numeric-user-id-length INTEGER ::= 32 4791 ub-organization-name-length INTEGER ::= 64 4792 ub-organizational-unit-name-length INTEGER ::= 32 4793 ub-organizational-units INTEGER ::= 4 4794 ub-pds-name-length INTEGER ::= 16 4795 ub-pds-parameter-length INTEGER ::= 30 4796 ub-pds-physical-address-lines INTEGER ::= 6 4797 ub-postal-code-length INTEGER ::= 16 4798 ub-pseudonym INTEGER ::= 128 4799 ub-surname-length INTEGER ::= 40 4800 ub-terminal-id-length INTEGER ::= 24 4801 ub-unformatted-address-length INTEGER ::= 180 4802 ub-x121-address-length INTEGER ::= 16 4804 -- Note - upper bounds on string types, such as TeletexString, are 4805 -- measured in characters. Excepting PrintableString or IA5String, a 4806 -- significantly greater number of octets will be required to hold 4807 -- such a value. As a minimum, 16 octets, or twice the specified upper 4808 -- bound, whichever is the larger, should be allowed for TeletexString. 4809 -- For UTF8String or UniversalString at least four times the upper 4810 -- bound should be allowed. 4812 END 4813 A.2 Implicitly Tagged Module, 1988 Syntax 4815 PKIX1Implicit88 { iso(1) identified-organization(3) dod(6) internet(1) 4816 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19) } 4818 DEFINITIONS IMPLICIT TAGS ::= 4820 BEGIN 4822 -- EXPORTS ALL -- 4824 IMPORTS 4825 id-pe, id-kp, id-qt-unotice, id-qt-cps, 4826 -- delete following line if "new" types are supported -- 4827 BMPString, UTF8String, -- end "new" types -- 4828 ORAddress, Name, RelativeDistinguishedName, 4829 CertificateSerialNumber, Attribute, DirectoryString 4830 FROM PKIX1Explicit88 { iso(1) identified-organization(3) 4831 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 4832 id-mod(0) id-pkix1-explicit(18) }; 4834 -- ISO arc for standard certificate and CRL extensions 4836 id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 4838 -- authority key identifier OID and syntax 4840 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 4842 AuthorityKeyIdentifier ::= SEQUENCE { 4843 keyIdentifier [0] KeyIdentifier OPTIONAL, 4844 authorityCertIssuer [1] GeneralNames OPTIONAL, 4845 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 4846 -- authorityCertIssuer and authorityCertSerialNumber MUST both 4847 -- be present or both be absent 4849 KeyIdentifier ::= OCTET STRING 4851 -- subject key identifier OID and syntax 4853 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 4855 SubjectKeyIdentifier ::= KeyIdentifier 4857 -- key usage extension OID and syntax 4859 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 4860 KeyUsage ::= BIT STRING { 4861 digitalSignature (0), 4862 nonRepudiation (1), 4863 keyEncipherment (2), 4864 dataEncipherment (3), 4865 keyAgreement (4), 4866 keyCertSign (5), 4867 cRLSign (6), 4868 encipherOnly (7), 4869 decipherOnly (8) } 4871 -- private key usage period extension OID and syntax 4873 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 4875 PrivateKeyUsagePeriod ::= SEQUENCE { 4876 notBefore [0] GeneralizedTime OPTIONAL, 4877 notAfter [1] GeneralizedTime OPTIONAL } 4878 -- either notBefore or notAfter MUST be present 4880 -- certificate policies extension OID and syntax 4882 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 4884 anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 } 4886 CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 4888 PolicyInformation ::= SEQUENCE { 4889 policyIdentifier CertPolicyId, 4890 policyQualifiers SEQUENCE SIZE (1..MAX) OF 4891 PolicyQualifierInfo OPTIONAL } 4893 CertPolicyId ::= OBJECT IDENTIFIER 4895 PolicyQualifierInfo ::= SEQUENCE { 4896 policyQualifierId PolicyQualifierId, 4897 qualifier ANY DEFINED BY policyQualifierId } 4899 -- Implementations that recognize additional policy qualifiers MUST 4900 -- augment the following definition for PolicyQualifierId 4902 PolicyQualifierId ::= 4903 OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) 4905 -- CPS pointer qualifier 4907 CPSuri ::= IA5String 4908 -- user notice qualifier 4910 UserNotice ::= SEQUENCE { 4911 noticeRef NoticeReference OPTIONAL, 4912 explicitText DisplayText OPTIONAL} 4914 NoticeReference ::= SEQUENCE { 4915 organization DisplayText, 4916 noticeNumbers SEQUENCE OF INTEGER } 4918 DisplayText ::= CHOICE { 4919 ia5String IA5String (SIZE (1..200)), 4920 visibleString VisibleString (SIZE (1..200)), 4921 bmpString BMPString (SIZE (1..200)), 4922 utf8String UTF8String (SIZE (1..200)) } 4924 -- policy mapping extension OID and syntax 4926 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 4928 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 4929 issuerDomainPolicy CertPolicyId, 4930 subjectDomainPolicy CertPolicyId } 4932 -- subject alternative name extension OID and syntax 4934 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 4936 SubjectAltName ::= GeneralNames 4938 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 4940 GeneralName ::= CHOICE { 4941 otherName [0] AnotherName, 4942 rfc822Name [1] IA5String, 4943 dNSName [2] IA5String, 4944 x400Address [3] ORAddress, 4945 directoryName [4] Name, 4946 ediPartyName [5] EDIPartyName, 4947 uniformResourceIdentifier [6] IA5String, 4948 iPAddress [7] OCTET STRING, 4949 registeredID [8] OBJECT IDENTIFIER } 4951 -- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as 4952 -- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax 4954 AnotherName ::= SEQUENCE { 4955 type-id OBJECT IDENTIFIER, 4956 value [0] EXPLICIT ANY DEFINED BY type-id } 4958 EDIPartyName ::= SEQUENCE { 4959 nameAssigner [0] DirectoryString OPTIONAL, 4960 partyName [1] DirectoryString } 4962 -- issuer alternative name extension OID and syntax 4964 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 4966 IssuerAltName ::= GeneralNames 4968 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 4970 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 4972 -- basic constraints extension OID and syntax 4974 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 4976 BasicConstraints ::= SEQUENCE { 4977 cA BOOLEAN DEFAULT FALSE, 4978 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 4980 -- name constraints extension OID and syntax 4982 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 4984 NameConstraints ::= SEQUENCE { 4985 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 4986 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 4988 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 4990 GeneralSubtree ::= SEQUENCE { 4991 base GeneralName, 4992 minimum [0] BaseDistance DEFAULT 0, 4993 maximum [1] BaseDistance OPTIONAL } 4995 BaseDistance ::= INTEGER (0..MAX) 4997 -- policy constraints extension OID and syntax 4999 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } 5001 PolicyConstraints ::= SEQUENCE { 5002 requireExplicitPolicy [0] SkipCerts OPTIONAL, 5003 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 5005 SkipCerts ::= INTEGER (0..MAX) 5007 -- CRL distribution points extension OID and syntax 5009 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31} 5011 CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 5013 DistributionPoint ::= SEQUENCE { 5014 distributionPoint [0] DistributionPointName OPTIONAL, 5015 reasons [1] ReasonFlags OPTIONAL, 5016 cRLIssuer [2] GeneralNames OPTIONAL } 5018 DistributionPointName ::= CHOICE { 5019 fullName [0] GeneralNames, 5020 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 5022 ReasonFlags ::= BIT STRING { 5023 unused (0), 5024 keyCompromise (1), 5025 cACompromise (2), 5026 affiliationChanged (3), 5027 superseded (4), 5028 cessationOfOperation (5), 5029 certificateHold (6), 5030 privilegeWithdrawn (7), 5031 aACompromise (8) } 5033 -- extended key usage extension OID and syntax 5035 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 5037 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 5039 KeyPurposeId ::= OBJECT IDENTIFIER 5041 -- extended key purpose OIDs 5042 id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } 5043 id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } 5044 id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } 5045 id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } 5046 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 5047 id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 } 5049 -- inhibit any policy OID and syntax 5051 id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 } 5052 InhibitAnyPolicy ::= SkipCerts 5054 -- freshest (delta)CRL extension OID and syntax 5056 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } 5058 FreshestCRL ::= CRLDistributionPoints 5060 -- authority info access 5062 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 5064 AuthorityInfoAccessSyntax ::= 5065 SEQUENCE SIZE (1..MAX) OF AccessDescription 5067 AccessDescription ::= SEQUENCE { 5068 accessMethod OBJECT IDENTIFIER, 5069 accessLocation GeneralName } 5071 -- CRL number extension OID and syntax 5073 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 5075 CRLNumber ::= INTEGER (0..MAX) 5077 -- issuing distribution point extension OID and syntax 5079 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 5081 IssuingDistributionPoint ::= SEQUENCE { 5082 distributionPoint [0] DistributionPointName OPTIONAL, 5083 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 5084 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 5085 onlySomeReasons [3] ReasonFlags OPTIONAL, 5086 indirectCRL [4] BOOLEAN DEFAULT FALSE, 5087 onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE } 5089 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 5091 BaseCRLNumber ::= CRLNumber 5093 -- CRL reasons extension OID and syntax 5095 id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 } 5097 CRLReason ::= ENUMERATED { 5098 unspecified (0), 5099 keyCompromise (1), 5100 cACompromise (2), 5101 affiliationChanged (3), 5102 superseded (4), 5103 cessationOfOperation (5), 5104 certificateHold (6), 5105 removeFromCRL (8), 5106 privilegeWithdrawn (9), 5107 aACompromise (10) } 5109 -- certificate issuer CRL entry extension OID and syntax 5111 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } 5113 CertificateIssuer ::= GeneralNames 5115 -- hold instruction extension OID and syntax 5117 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 5119 HoldInstructionCode ::= OBJECT IDENTIFIER 5121 -- ANSI x9 holdinstructions 5123 -- ANSI x9 arc holdinstruction arc 5124 holdInstruction OBJECT IDENTIFIER ::= 5125 {joint-iso-itu-t(2) member-body(2) us(840) x9cm(10040) 2} 5127 -- ANSI X9 holdinstructions referenced by this standard 5128 id-holdinstruction-none OBJECT IDENTIFIER ::= 5129 {holdInstruction 1} -- deprecated 5130 id-holdinstruction-callissuer OBJECT IDENTIFIER ::= 5131 {holdInstruction 2} 5132 id-holdinstruction-reject OBJECT IDENTIFIER ::= 5133 {holdInstruction 3} 5135 -- invalidity date CRL entry extension OID and syntax 5137 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 5139 InvalidityDate ::= GeneralizedTime 5141 END 5142 Appendix B. ASN.1 Notes 5144 CAs MUST force the serialNumber to be a non-negative integer, that 5145 is, the sign bit in the DER encoding of the INTEGER value MUST be 5146 zero - this can be done by adding a leading (leftmost) `00'H octet if 5147 necessary. This removes a potential ambiguity in mapping between a 5148 string of octets and an integer value. 5150 As noted in section 4.1.2.2, serial numbers can be expected to 5151 contain long integers. Certificate users MUST be able to handle 5152 serialNumber values up to 20 octets in length. Conformant CAs MUST 5153 NOT use serialNumber values longer than 20 octets. 5155 The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 5156 constructs. A valid ASN.1 sequence will have zero or more entries. 5157 The SIZE (1..MAX) construct constrains the sequence to have at least 5158 one entry. MAX indicates the upper bound is unspecified. 5159 Implementations are free to choose an upper bound that suits their 5160 environment. 5162 The construct "positiveInt ::= INTEGER (0..MAX)" defines positiveInt 5163 as a subtype of INTEGER containing integers greater than or equal to 5164 zero. The upper bound is unspecified. Implementations are free to 5165 select an upper bound that suits their environment. 5167 The character string type PrintableString supports a very basic Latin 5168 character set: the lower case letters 'a' through 'z', upper case 5169 letters 'A' through 'Z', the digits '0' through '9', eleven special 5170 characters ' = ( ) + , - . / : ? and space. 5172 Implementers should note that the at sign ('@') and underscore ('_') 5173 characters are not supported by the ASN.1 type PrintableString. 5174 These characters often appear in internet addresses. Such addresses 5175 MUST be encoded using an ASN.1 type that supports them. They are 5176 usually encoded as IA5String in either the emailAddress attribute 5177 within a distinguished name or the rfc822Name field of GeneralName. 5178 Conforming implementations MUST NOT encode strings which include 5179 either the at sign or underscore character as PrintableString. 5181 The character string type TeletexString is a superset of 5182 PrintableString. TeletexString supports a fairly standard (ASCII- 5183 like) Latin character set, Latin characters with non-spacing accents 5184 and Japanese characters. 5186 Named bit lists are BIT STRINGs where the values have been assigned 5187 names. This specification makes use of named bit lists in the 5188 definitions for the key usage extension and CRL reasons field in the 5189 CRL distribution points and freshest CRL certificate extensions, and 5190 the issuing distribution point CRL extension. When DER encoding a 5191 named bit list, trailing zeroes MUST be omitted. That is, the 5192 encoded value ends with the last named bit that is set to one. 5194 The character string type UniversalString supports any of the 5195 characters allowed by ISO 10646-1 [ISO 10646]. ISO 10646-1 is the 5196 Universal multiple-octet coded Character Set (UCS). ISO 10646-1 5197 specifies the architecture and the "basic multilingual plane" - a 5198 large standard character set which includes all major world character 5199 standards. 5201 The character string type UTF8String was introduced in the 1997 5202 version of ASN.1, and UTF8String was added to the list of choices for 5203 DirectoryString in the 2001 version of X.520 [X.520]. UTF8String is 5204 a universal type and has been assigned tag number 12. The content of 5205 UTF8String was defined by RFC 2044 [RFC 2044] and updated in RFC 2279 5206 [RFC 2279]. 5208 In anticipation of these changes, and in conformance with IETF Best 5209 Practices codified in RFC 2277 [RFC 2277], IETF Policy on Character 5210 Sets and Languages, this document includes UTF8String as a choice in 5211 DirectoryString and the CPS qualifier extensions. 5213 Implementers should note that the DER encoding of the SET OF values 5214 requires ordering of the encodings of the values. In particular, 5215 this issue arises with respect to distinguished names. 5217 Implementers should note that the DER encoding of SET or SEQUENCE 5218 components whose value is the DEFAULT omit the component from the 5219 encoded certificate or CRL. For example, a BasicConstraints 5220 extension whose cA value is FALSE would omit the cA boolean from the 5221 encoded certificate. 5223 Object Identifiers (OIDs) are used throughout this specification to 5224 identify certificate policies, public key and signature algorithms, 5225 certificate extensions, etc. There is no maximum size for OIDs. 5226 This specification mandates support for OIDs which have arc elements 5227 with values that are less than 2^28, that is, they MUST be between 0 5228 and 268,435,455, inclusive. This allows each arc element to be 5229 represented within a single 32 bit word. Implementations MUST also 5230 support OIDs where the length of the dotted decimal (see [RFC 2252], 5231 section 4.1) string representation can be up to 100 bytes 5232 (inclusive). Implementations MUST be able to handle OIDs with up to 5233 20 elements (inclusive). CAs SHOULD NOT issue certificates which 5234 contain OIDs that exceed these requirements. 5236 Implementors are warned that the X.500 standards community has 5237 developed a series of extensibility rules. These rules determine 5238 when an ASN.1 definition can be changed without assigning a new 5239 object identifier (OID). For example, at least two extension 5240 definitions included in RFC 2459 [RFC 2459], the predecessor to this 5241 profile document, have different ASN.1 definitions in this 5242 specification, but the same OID is used. If unknown elements appear 5243 within an extension, and the extension is not marked critical, those 5244 unknown elements ought to be ignored, as follows: 5246 (a) ignore all unknown bit name assignments within a bit string; 5248 (b) ignore all unknown named numbers in an ENUMERATED type or 5249 INTEGER type that is being used in the enumerated style, provided 5250 the number occurs as an optional element of a SET or SEQUENCE; and 5252 (c) ignore all unknown elements in SETs, at the end of SEQUENCEs, 5253 or in CHOICEs where the CHOICE is itself an optional element of a 5254 SET or SEQUENCE. 5256 If an extension containing unexpected values is marked critical, the 5257 implementation MUST reject the certificate or CRL containing the 5258 unrecognized extension. 5260 Appendix C. Examples 5262 This section contains four examples: three certificates and a CRL. 5263 The first two certificates and the CRL comprise a minimal 5264 certification path. 5266 Section C.1 contains an annotated hex dump of a "self-signed" 5267 certificate issued by a CA whose distinguished name is 5268 cn=us,o=gov,ou=nist. The certificate contains a DSA public key with 5269 parameters, and is signed by the corresponding DSA private key. 5271 Section C.2 contains an annotated hex dump of an end entity 5272 certificate. The end entity certificate contains a DSA public key, 5273 and is signed by the private key corresponding to the "self-signed" 5274 certificate in section C.1. 5276 Section C.3 contains a dump of an end entity certificate which 5277 contains an RSA public key and is signed with RSA and MD5. This 5278 certificate is not part of the minimal certification path. 5280 Section C.4 contains an annotated hex dump of a CRL. The CRL is 5281 issued by the CA whose distinguished name is cn=us,o=gov,ou=nist and 5282 the list of revoked certificates includes the end entity certificate 5283 presented in C.2. 5285 The certificates were processed using Peter Gutman's dumpasn1 utility 5286 to generate the output. The source for the dumpasn1 utility is 5287 available at . The 5288 binaries for the certificates and CRLs are available at 5289 . 5291 C.1 Certificate 5293 This section contains an annotated hex dump of a 699 byte version 3 5294 certificate. The certificate contains the following information: 5295 (a) the serial number is 23 (17 hex); 5296 (b) the certificate is signed with DSA and the SHA-1 hash algorithm; 5297 (c) the issuer's distinguished name is OU=NIST; O=gov; C=US 5298 (d) and the subject's distinguished name is OU=NIST; O=gov; C=US 5299 (e) the certificate was issued on June 30, 1997 and will expire on 5300 December 31, 1997; 5301 (f) the certificate contains a 1024 bit DSA public key with 5302 parameters; 5303 (g) the certificate contains a subject key identifier extension 5304 generated using method (1) of section 4.2.1.2; and 5305 (h) the certificate is a CA certificate (as indicated through the 5306 basic constraints extension.) 5308 0 30 699: SEQUENCE { 5309 4 30 635: SEQUENCE { 5310 8 A0 3: [0] { 5311 10 02 1: INTEGER 2 5312 : } 5313 13 02 1: INTEGER 17 5314 16 30 9: SEQUENCE { 5315 18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5316 : } 5317 27 30 42: SEQUENCE { 5318 29 31 11: SET { 5319 31 30 9: SEQUENCE { 5320 33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5321 38 13 2: PrintableString 'US' 5322 : } 5323 : } 5324 42 31 12: SET { 5325 44 30 10: SEQUENCE { 5326 46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5327 51 13 3: PrintableString 'gov' 5328 : } 5329 : } 5330 56 31 13: SET { 5331 58 30 11: SEQUENCE { 5332 60 06 3: OBJECT IDENTIFIER 5333 : organizationalUnitName (2 5 4 11) 5335 65 13 4: PrintableString 'NIST' 5336 : } 5337 : } 5338 : } 5339 71 30 30: SEQUENCE { 5340 73 17 13: UTCTime '970630000000Z' 5341 88 17 13: UTCTime '971231000000Z' 5342 : } 5343 103 30 42: SEQUENCE { 5344 105 31 11: SET { 5345 107 30 9: SEQUENCE { 5346 109 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5347 114 13 2: PrintableString 'US' 5348 : } 5349 : } 5350 118 31 12: SET { 5351 120 30 10: SEQUENCE { 5352 122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5353 127 13 3: PrintableString 'gov' 5354 : } 5355 : } 5356 132 31 13: SET { 5357 134 30 11: SEQUENCE { 5358 136 06 3: OBJECT IDENTIFIER 5359 : organizationalUnitName (2 5 4 11) 5360 141 13 4: PrintableString 'NIST' 5361 : } 5362 : } 5363 : } 5364 147 30 440: SEQUENCE { 5365 151 30 300: SEQUENCE { 5366 155 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) 5367 164 30 287: SEQUENCE { 5368 168 02 129: INTEGER 5369 : 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC 5370 : FB 95 32 AC 01 12 33 B9 E0 1C AD 90 9B BC 5371 : 48 54 9E F3 94 77 3C 2C 71 35 55 E6 FE 4F 5372 : 22 CB D5 D8 3E 89 93 33 4D FC BD 4F 41 64 5373 : 3E A2 98 70 EC 31 B4 50 DE EB F1 98 28 0A 5374 : C9 3E 44 B3 FD 22 97 96 83 D0 18 A3 E3 BD 5375 : 35 5B FF EE A3 21 72 6A 7B 96 DA B9 3F 1E 5376 : 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A 5377 : FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48 5378 : 63 FE 43 5379 300 02 21: INTEGER 5380 : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA 5381 : 55 F7 7D 57 74 81 E5 5382 323 02 129: INTEGER 5383 : 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91 5384 : C0 8E 47 F1 0A C3 01 47 C2 44 42 36 A9 92 5385 : 81 DE 57 C5 E0 68 86 58 00 7B 1F F9 9B 77 5386 : A1 C5 10 A5 80 91 78 51 51 3C F6 FC FC CC 5387 : 46 C6 81 78 92 84 3D F4 93 3D 0C 38 7E 1A 5388 : 5B 99 4E AB 14 64 F6 0C 21 22 4E 28 08 9C 5389 : 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 39 A2 5390 : 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF 5391 : F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE 5392 : 1E 57 18 5393 : } 5394 : } 5395 455 03 133: BIT STRING 0 unused bits, encapsulates { 5396 459 02 129: INTEGER 5397 : 00 B5 9E 1F 49 04 47 D1 DB F5 3A DD CA 04 5398 : 75 E8 DD 75 F6 9B 8A B1 97 D6 59 69 82 D3 5399 : 03 4D FD 3B 36 5F 4A F2 D1 4E C1 07 F5 D1 5400 : 2A D3 78 77 63 56 EA 96 61 4D 42 0B 7A 1D 5401 : FB AB 91 A4 CE DE EF 77 C8 E5 EF 20 AE A6 5402 : 28 48 AF BE 69 C3 6A A5 30 F2 C2 B9 D9 82 5403 : 2B 7D D9 C4 84 1F DE 0D E8 54 D7 1B 99 2E 5404 : B3 D0 88 F6 D6 63 9B A7 E2 0E 82 D4 3B 8A 5405 : 68 1B 06 56 31 59 0B 49 EB 99 A5 D5 81 41 5406 : 7B C9 55 5407 : } 5408 : } 5409 591 A3 50: [3] { 5410 593 30 48: SEQUENCE { 5411 595 30 29: SEQUENCE { 5412 597 06 3: OBJECT IDENTIFIER 5413 : subjectKeyIdentifier (2 5 29 14) 5414 602 04 22: OCTET STRING, encapsulates { 5415 604 04 20: OCTET STRING 5416 : 86 CA A5 22 81 62 EF AD 0A 89 BC AD 72 41 5417 : 2C 29 49 F4 86 56 5418 : } 5419 : } 5420 626 30 15: SEQUENCE { 5421 628 06 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19) 5422 633 01 1: BOOLEAN TRUE 5423 636 04 5: OCTET STRING, encapsulates { 5424 638 30 3: SEQUENCE { 5425 640 01 1: BOOLEAN TRUE 5426 : } 5427 : } 5428 : } 5429 : } 5430 : } 5431 : } 5432 643 30 9: SEQUENCE { 5433 645 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5434 : } 5435 654 03 47: BIT STRING 0 unused bits, encapsulates { 5436 657 30 44: SEQUENCE { 5437 659 02 20: INTEGER 5438 : 43 1B CF 29 25 45 C0 4E 52 E7 7D D6 FC B1 5439 : 66 4C 83 CF 2D 77 5440 681 02 20: INTEGER 5441 : 0B 5B 9A 24 11 98 E8 F3 86 90 04 F6 08 A9 5442 : E1 8D A5 CC 3A D4 5443 : } 5444 : } 5445 : } 5447 C.2 Certificate 5449 This section contains an annotated hex dump of a 730 byte version 3 5450 certificate. The certificate contains the following information: 5451 (a the serial number is 18 (12 hex); 5452 (b) the certificate is signed with DSA and the SHA-1 hash algorithm; 5453 (c) the issuer's distinguished name is OU=nist; O=gov; C=US 5454 (d) and the subject's distinguished name is CN=Tim Polk; OU=nist; 5455 O=gov; C=US 5456 (e) the certificate was valid from July 30, 1997 through December 1, 5457 1997; 5458 (f) the certificate contains a 1024 bit DSA public key; 5459 (g) the certificate is an end entity certificate, as the basic 5460 constraints extension is not present; 5461 (h) the certificate contains an authority key identifier extension 5462 matching the subject key identifier of the certificate in Appendix 5463 C.1; and 5464 (i) the certificate includes one alternative name - an RFC 822 5465 address of "wpolk@nist.gov". 5467 0 30 730: SEQUENCE { 5468 4 30 665: SEQUENCE { 5469 8 A0 3: [0] { 5470 10 02 1: INTEGER 2 5471 : } 5472 13 02 1: INTEGER 18 5473 16 30 9: SEQUENCE { 5474 18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5475 : } 5476 27 30 42: SEQUENCE { 5477 29 31 11: SET { 5478 31 30 9: SEQUENCE { 5479 33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5480 38 13 2: PrintableString 'US' 5481 : } 5482 : } 5483 42 31 12: SET { 5484 44 30 10: SEQUENCE { 5485 46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5486 51 13 3: PrintableString 'gov' 5487 : } 5488 : } 5489 56 31 13: SET { 5490 58 30 11: SEQUENCE { 5491 60 06 3: OBJECT IDENTIFIER 5492 : organizationalUnitName (2 5 4 11) 5493 65 13 4: PrintableString 'NIST' 5494 : } 5495 : } 5496 : } 5497 71 30 30: SEQUENCE { 5498 73 17 13: UTCTime '970730000000Z' 5499 88 17 13: UTCTime '971201000000Z' 5500 : } 5501 103 30 61: SEQUENCE { 5502 105 31 11: SET { 5503 107 30 9: SEQUENCE { 5504 109 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5505 114 13 2: PrintableString 'US' 5506 : } 5507 : } 5508 118 31 12: SET { 5509 120 30 10: SEQUENCE { 5510 122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5511 127 13 3: PrintableString 'gov' 5512 : } 5513 : } 5514 132 31 13: SET { 5515 134 30 11: SEQUENCE { 5516 136 06 3: OBJECT IDENTIFIER 5517 : organizationalUnitName (2 5 4 11) 5518 141 13 4: PrintableString 'NIST' 5519 : } 5520 : } 5521 147 31 17: SET { 5522 149 30 15: SEQUENCE { 5523 151 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 5524 156 13 8: PrintableString 'Tim Polk' 5525 : } 5526 : } 5527 : } 5528 166 30 439: SEQUENCE { 5529 170 30 300: SEQUENCE { 5530 174 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) 5531 183 30 287: SEQUENCE { 5532 187 02 129: INTEGER 5533 : 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC 5534 : FB 95 32 AC 01 12 33 B9 E0 1C AD 90 9B BC 5535 : 48 54 9E F3 94 77 3C 2C 71 35 55 E6 FE 4F 5536 : 22 CB D5 D8 3E 89 93 33 4D FC BD 4F 41 64 5537 : 3E A2 98 70 EC 31 B4 50 DE EB F1 98 28 0A 5538 : C9 3E 44 B3 FD 22 97 96 83 D0 18 A3 E3 BD 5539 : 35 5B FF EE A3 21 72 6A 7B 96 DA B9 3F 1E 5540 : 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A 5541 : FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48 5542 : 63 FE 43 5543 319 02 21: INTEGER 5544 : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA 5545 : 55 F7 7D 57 74 81 E5 5546 342 02 129: INTEGER 5547 : 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91 5548 : C0 8E 47 F1 0A C3 01 47 C2 44 42 36 A9 92 5549 : 81 DE 57 C5 E0 68 86 58 00 7B 1F F9 9B 77 5550 : A1 C5 10 A5 80 91 78 51 51 3C F6 FC FC CC 5551 : 46 C6 81 78 92 84 3D F4 93 3D 0C 38 7E 1A 5552 : 5B 99 4E AB 14 64 F6 0C 21 22 4E 28 08 9C 5553 : 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 39 A2 5554 : 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF 5555 : F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE 5556 : 1E 57 18 5557 : } 5558 : } 5559 474 03 132: BIT STRING 0 unused bits, encapsulates { 5560 478 02 128: INTEGER 5561 : 30 B6 75 F7 7C 20 31 AE 38 BB 7E 0D 2B AB 5562 : A0 9C 4B DF 20 D5 24 13 3C CD 98 E5 5F 6C 5563 : B7 C1 BA 4A BA A9 95 80 53 F0 0D 72 DC 33 5564 : 37 F4 01 0B F5 04 1F 9D 2E 1F 62 D8 84 3A 5565 : 9B 25 09 5A 2D C8 46 8E 2B D4 F5 0D 3B C7 5566 : 2D C6 6C B9 98 C1 25 3A 44 4E 8E CA 95 61 5567 : 35 7C CE 15 31 5C 23 13 1E A2 05 D1 7A 24 5568 : 1C CB D3 72 09 90 FF 9B 9D 28 C0 A1 0A EC 5569 : 46 9F 0D B8 D0 DC D0 18 A6 2B 5E F9 8F B5 5570 : 95 BE 5571 : } 5572 : } 5573 609 A3 62: [3] { 5574 611 30 60: SEQUENCE { 5575 613 30 25: SEQUENCE { 5576 615 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 5577 620 04 18: OCTET STRING, encapsulates { 5578 622 30 16: SEQUENCE { 5579 624 81 14: [1] 'wpolk@nist.gov' 5580 : } 5581 : } 5582 : } 5583 640 30 31: SEQUENCE { 5584 642 06 3: OBJECT IDENTIFIER 5585 : authorityKeyIdentifier (2 5 29 35) 5586 647 04 24: OCTET STRING, encapsulates { 5587 649 30 22: SEQUENCE { 5588 651 80 20: [0] 5589 : 86 CA A5 22 81 62 EF AD 0A 89 BC AD 72 5590 : 41 2C 29 49 F4 86 56 5591 : } 5592 : } 5593 : } 5594 : } 5595 : } 5596 : } 5597 673 30 9: SEQUENCE { 5598 675 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5599 : } 5600 684 03 48: BIT STRING 0 unused bits, encapsulates { 5601 687 30 45: SEQUENCE { 5602 689 02 20: INTEGER 5603 : 36 97 CB E3 B4 2C E1 BB 61 A9 D3 CC 24 CC 5604 : 22 92 9F F4 F5 87 5605 711 02 21: INTEGER 5606 : 00 AB C9 79 AF D2 16 1C A9 E3 68 A9 14 10 5607 : B4 A0 2E FF 22 5A 73 5608 : } 5609 : } 5610 : } 5612 C.3 End Entity Certificate Using RSA 5614 This section contains an annotated hex dump of a 654 byte version 3 5615 certificate. The certificate contains the following information: 5616 (a) the serial number is 256; 5617 (b) the certificate is signed with RSA and the SHA-1 hash algorithm; 5618 (c) the issuer's distinguished name is OU=NIST; O=gov; C=US 5619 (d) and the subject's distinguished name is CN=Tim Polk; OU=NIST; 5620 O=gov; C=US 5621 (e) the certificate was issued on May 21, 1996 at 09:58:26 and 5622 expired on May 21, 1997 at 09:58:26; 5623 (f) the certificate contains a 1024 bit RSA public key; 5624 (g) the certificate is an end entity certificate (not a CA 5625 certificate); 5626 (h) the certificate includes an alternative subject name of 5627 "" and an 5628 alternative issuer name of "" - both are URLs; 5629 (i) the certificate include an authority key identifier extension 5630 and a certificate policies extension psecifying the policy OID 5631 2.16.840.1.101.3.2.1.48.9; and 5632 (j) the certificate includes a critical key usage extension 5633 specifying that the public key is intended for verification of 5634 digital signatures. 5636 0 30 654: SEQUENCE { 5637 4 30 503: SEQUENCE { 5638 8 A0 3: [0] { 5639 10 02 1: INTEGER 2 5640 : } 5641 13 02 2: INTEGER 256 5642 17 30 13: SEQUENCE { 5643 19 06 9: OBJECT IDENTIFIER 5644 : sha1withRSAEncryption (1 2 840 113549 1 1 5) 5645 30 05 0: NULL 5646 : } 5647 32 30 42: SEQUENCE { 5648 34 31 11: SET { 5649 36 30 9: SEQUENCE { 5650 38 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5651 43 13 2: PrintableString 'US' 5652 : } 5653 : } 5654 47 31 12: SET { 5655 49 30 10: SEQUENCE { 5656 51 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5657 56 13 3: PrintableString 'gov' 5658 : } 5659 : } 5660 61 31 13: SET { 5661 63 30 11: SEQUENCE { 5662 65 06 3: OBJECT IDENTIFIER 5663 : organizationalUnitName (2 5 4 11) 5664 70 13 4: PrintableString 'NIST' 5665 : } 5666 : } 5667 : } 5668 76 30 30: SEQUENCE { 5669 78 17 13: UTCTime '960521095826Z' 5670 93 17 13: UTCTime '970521095826Z' 5671 : } 5672 108 30 61: SEQUENCE { 5673 110 31 11: SET { 5674 112 30 9: SEQUENCE { 5675 114 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5676 119 13 2: PrintableString 'US' 5677 : } 5678 : } 5679 123 31 12: SET { 5680 125 30 10: SEQUENCE { 5681 127 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5682 132 13 3: PrintableString 'gov' 5683 : } 5684 : } 5685 137 31 13: SET { 5686 139 30 11: SEQUENCE { 5687 141 06 3: OBJECT IDENTIFIER 5688 : organizationalUnitName (2 5 4 11) 5689 146 13 4: PrintableString 'NIST' 5690 : } 5691 : } 5692 152 31 17: SET { 5693 154 30 15: SEQUENCE { 5694 156 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 5695 161 13 8: PrintableString 'Tim Polk' 5696 : } 5697 : } 5698 : } 5699 171 30 159: SEQUENCE { 5700 174 30 13: SEQUENCE { 5701 176 06 9: OBJECT IDENTIFIER 5702 : rsaEncryption (1 2 840 113549 1 1 1) 5703 187 05 0: NULL 5704 : } 5705 189 03 141: BIT STRING 0 unused bits, encapsulates { 5706 193 30 137: SEQUENCE { 5707 196 02 129: INTEGER 5708 : 00 E1 6A E4 03 30 97 02 3C F4 10 F3 B5 1E 5709 : 4D 7F 14 7B F6 F5 D0 78 E9 A4 8A F0 A3 75 5710 : EC ED B6 56 96 7F 88 99 85 9A F2 3E 68 77 5711 : 87 EB 9E D1 9F C0 B4 17 DC AB 89 23 A4 1D 5712 : 7E 16 23 4C 4F A8 4D F5 31 B8 7C AA E3 1A 5713 : 49 09 F4 4B 26 DB 27 67 30 82 12 01 4A E9 5714 : 1A B6 C1 0C 53 8B 6C FC 2F 7A 43 EC 33 36 5715 : 7E 32 B2 7B D5 AA CF 01 14 C6 12 EC 13 F2 5716 : 2D 14 7A 8B 21 58 14 13 4C 46 A3 9A F2 16 5717 : 95 FF 23 5718 328 02 3: INTEGER 65537 5719 : } 5720 : } 5721 : } 5722 333 A3 175: [3] { 5723 336 30 172: SEQUENCE { 5724 339 30 63: SEQUENCE { 5725 341 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 5726 346 04 56: OCTET STRING, encapsulates { 5727 348 30 54: SEQUENCE { 5728 350 86 52: [6] 5729 : 'http://www.itl.nist.gov/div893/staff/' 5730 : 'polk/index.html' 5731 : } 5732 : } 5733 : } 5734 404 30 31: SEQUENCE { 5735 406 06 3: OBJECT IDENTIFIER issuerAltName (2 5 29 18) 5736 411 04 24: OCTET STRING, encapsulates { 5737 413 30 22: SEQUENCE { 5738 415 86 20: [6] 'http://www.nist.gov/' 5739 : } 5740 : } 5741 : } 5742 437 30 31: SEQUENCE { 5743 439 06 3: OBJECT IDENTIFIER 5744 : authorityKeyIdentifier (2 5 29 35) 5745 444 04 24: OCTET STRING, encapsulates { 5746 446 30 22: SEQUENCE { 5747 448 80 20: [0] 5748 : 08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E 5749 : 70 6A 4A 20 84 2C 32 5750 : } 5751 : } 5752 : } 5753 470 30 23: SEQUENCE { 5754 472 06 3: OBJECT IDENTIFIER 5755 : certificatePolicies (2 5 29 32) 5756 477 04 16: OCTET STRING, encapsulates { 5757 479 30 14: SEQUENCE { 5758 481 30 12: SEQUENCE { 5759 483 06 10: OBJECT IDENTIFIER 5760 : '2 16 840 1 101 3 2 1 48 9' 5761 : } 5762 : } 5763 : } 5764 : } 5765 495 30 14: SEQUENCE { 5766 497 06 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) 5767 502 01 1: BOOLEAN TRUE 5768 505 04 4: OCTET STRING, encapsulates { 5769 507 03 2: BIT STRING 7 unused bits 5770 : '1'B (bit 0) 5771 : } 5772 : } 5773 : } 5774 : } 5775 : } 5776 511 30 13: SEQUENCE { 5777 513 06 9: OBJECT IDENTIFIER 5778 : sha1withRSAEncryption (1 2 840 113549 1 1 5) 5779 524 05 0: NULL 5780 : } 5781 526 03 129: BIT STRING 0 unused bits 5782 : 1E 07 77 6E 66 B5 B6 B8 57 F0 03 DC 6F 77 5783 : 6D AF 55 1D 74 E5 CE 36 81 FC 4B C5 F4 47 5784 : 82 C4 0A 25 AA 8D D6 7D 3A 89 AB 44 34 39 5785 : F6 BD 61 1A 78 85 7A B8 1E 92 A2 22 2F CE 5786 : 07 1A 08 8E F1 46 03 59 36 4A CB 60 E6 03 5787 : 40 01 5B 2A 44 D6 E4 7F EB 43 5E 74 0A E6 5788 : E4 F9 3E E1 44 BE 1F E7 5F 5B 2C 41 8D 08 5789 : BD 26 FE 6A A6 C3 2F B2 3B 41 12 6B C1 06 5790 : 8A B8 4C 91 59 EB 2F 38 20 2A 67 74 20 0B 5791 : 77 F3 5792 : } 5794 C.4 Certificate Revocation List 5796 This section contains an annotated hex dump of a version 2 CRL with 5797 one extension (cRLNumber). The CRL was issued by OU=NIST; O=gov; C=US 5798 on August 7, 1997; the next scheduled issuance was September 7, 1997. 5799 The CRL includes one revoked certificates: serial number 18 (12 hex), 5800 which was revoked on July 31, 1997 due to keyCompromise. The CRL 5801 itself is number 18, and it was signed with DSA and SHA-1. 5803 0 30 203: SEQUENCE { 5804 3 30 140: SEQUENCE { 5805 6 02 1: INTEGER 1 5806 9 30 9: SEQUENCE { 5807 11 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5808 : } 5809 20 30 42: SEQUENCE { 5810 22 31 11: SET { 5811 24 30 9: SEQUENCE { 5812 26 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5813 31 13 2: PrintableString 'US' 5814 : } 5815 : } 5816 35 31 12: SET { 5817 37 30 10: SEQUENCE { 5818 39 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5819 44 13 3: PrintableString 'gov' 5820 : } 5821 : } 5822 49 31 13: SET { 5823 51 30 11: SEQUENCE { 5824 53 06 3: OBJECT IDENTIFIER 5825 : organizationalUnitName (2 5 4 11) 5826 58 13 4: PrintableString 'NIST' 5827 : } 5828 : } 5829 : } 5830 64 17 13: UTCTime '970807000000Z' 5831 79 17 13: UTCTime '970907000000Z' 5832 94 30 34: SEQUENCE { 5833 96 30 32: SEQUENCE { 5834 98 02 1: INTEGER 18 5835 101 17 13: UTCTime '970731000000Z' 5836 116 30 12: SEQUENCE { 5837 118 30 10: SEQUENCE { 5838 120 06 3: OBJECT IDENTIFIER cRLReason (2 5 29 21) 5839 125 04 3: OCTET STRING, encapsulates { 5840 127 0A 1: ENUMERATED 1 5841 : } 5842 : } 5843 : } 5844 : } 5845 : } 5846 130 A0 14: [0] { 5847 132 30 12: SEQUENCE { 5848 134 30 10: SEQUENCE { 5849 136 06 3: OBJECT IDENTIFIER cRLNumber (2 5 29 20) 5850 141 04 3: OCTET STRING, encapsulates { 5851 143 02 1: INTEGER 12 5852 : } 5853 : } 5854 : } 5855 : } 5856 : } 5857 146 30 9: SEQUENCE { 5858 148 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5859 : } 5860 157 03 47: BIT STRING 0 unused bits, encapsulates { 5861 160 30 44: SEQUENCE { 5862 162 02 20: INTEGER 5863 : 22 4E 9F 43 BA 95 06 34 F2 BB 5E 65 DB A6 5864 : 80 05 C0 3A 29 47 5865 184 02 20: INTEGER 5866 : 59 1A 57 C9 82 D7 02 21 14 C3 D4 0B 32 1B 5867 : 96 16 B1 1F 46 5A 5868 : } 5869 : } 5870 : } 5872 Appendix D. Author Addresses: 5874 Russell Housley 5875 RSA Laboratories 5876 918 Spring Knoll Drive 5877 Herndon, VA 20170 5878 USA 5879 rhousley@rsasecurity.com 5881 Warwick Ford 5882 VeriSign, Inc. 5883 One Alewife Center 5884 Cambridge, MA 02140 5885 USA 5886 wford@verisign.com 5888 Tim Polk 5889 NIST 5890 Building 820, Room 426 5891 Gaithersburg, MD 20899 5892 USA 5893 wpolk@nist.gov 5895 David Solo 5896 Citigroup 5897 909 Third Ave, 16th Floor 5898 New York, NY 10043 5899 USA 5900 dsolo@alum.mit.edu 5902 Appendix E. Full Copyright Statement 5904 Copyright (C) The Internet Society (date). All Rights Reserved. 5906 This document and translations of it may be copied and furnished to 5907 others, and derivative works that comment on or otherwise explain it 5908 or assist in its implementation may be prepared, copied, published 5909 and distributed, in whole or in part, without restriction of any 5910 kind, provided that the above copyright notice and this paragraph are 5911 included on all such copies and derivative works. In addition, the 5912 ASN.1 modules presented in Appendix A may be used in whole or in part 5913 without inclusion of the copyright notice. However, this document 5914 itself may not be modified in any way, such as by removing the 5915 copyright notice or references to the Internet Society or other 5916 Internet organizations, except as needed for the purpose of 5917 developing Internet standards in which case the procedures for 5918 copyrights defined in the Internet Standards process shall be 5919 followed, or as required to translate it into languages other than 5920 English. 5922 The limited permissions granted above are perpetual and will not be 5923 revoked by the Internet Society or its successors or assigns. This 5924 document and the information contained herein is provided on an "AS 5925 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 5926 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 5927 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 5928 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 5929 OR FITNESS FOR A PARTICULAR PURPOSE.