idnits 2.17.00 (12 Aug 2021) /tmp/idnits30188/draft-ietf-pkix-new-part1-11.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 587 has weird spacing: '...issuing a cer...' == Line 599 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 5839 -- Looks like a reference, but probably isn't: '1' on line 5572 -- Looks like a reference, but probably isn't: '2' on line 5077 -- Looks like a reference, but probably isn't: '3' on line 5715 == Missing Reference: 'ISO 8859-1' is mentioned on line 896, but not defined -- Looks like a reference, but probably isn't: '4' on line 5079 -- Looks like a reference, but probably isn't: '5' on line 5080 -- Looks like a reference, but probably isn't: '6' on line 5731 -- Looks like a reference, but probably isn't: '7' on line 4941 -- Looks like a reference, but probably isn't: '8' on line 4942 == Missing Reference: 'RFC1738' is mentioned on line 2711, but not defined ** Obsolete undefined reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) == Missing Reference: 'RFC1778' is mentioned on line 2711, but not defined ** Obsolete undefined reference: RFC 1778 (Obsoleted by RFC 3494) == Missing Reference: 'UNIVERSAL 28' is mentioned on line 4212, but not defined == Missing Reference: 'UNIVERSAL 30' is mentioned on line 4215, but not defined == Missing Reference: 'UNIVERSAL 12' is mentioned on line 4219, but not defined == Missing Reference: 'APPLICATION 1' is mentioned on line 4545, but not defined == Missing Reference: 'APPLICATION 2' is mentioned on line 4551, but not defined == Unused Reference: 'RFC 1423' is defined on line 3939, but no explicit reference was found in the text == Unused Reference: 'RFC 1778' is defined on line 3954, but no explicit reference was found in the text == Unused Reference: 'RFC 1883' is defined on line 3958, but no explicit reference was found in the text == Unused Reference: 'RFC 2119' is defined on line 3965, 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 When complete, this specification will obsolete RFC 2459. 45 Please send comments on this document to the ietf-pkix@imc.org mail 46 list. 48 This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use 49 in the Internet. An overview of the approach and model are provided 50 as an introduction. The X.509 v3 certificate format is described in 51 detail, with additional information regarding the format and 52 semantics of Internet name forms (e.g., IP addresses). Standard 53 certificate extensions are described and one new Internet-specific 54 extension is defined. A required set of certificate extensions is 55 specified. The X.509 v2 CRL format is described and a required 56 extension set is defined as well. An algorithm for X.509 certificate 57 path validation is described. Supplemental information is provided 58 describing the format of public keys and digital signatures in X.509 59 certificates for common Internet public key encryption algorithms 60 (i.e., RSA, DSA, and Diffie-Hellman). ASN.1 modules and examples are 61 provided in the appendices. 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in RFC 2119. 67 Table of Contents 69 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 2 Requirements and Assumptions . . . . . . . . . . . . . . . . . . 7 71 2.1 Communication and Topology . . . . . . . . . . . . . . . . . . 7 72 2.2 Acceptability Criteria . . . . . . . . . . . . . . . . . . . . 8 73 2.3 User Expectations . . . . . . . . . . . . . . . . . . . . . . . 8 74 2.4 Administrator Expectations . . . . . . . . . . . . . . . . . . 8 75 3 Overview of Approach . . . . . . . . . . . . . . . . . . . . . . 8 76 3.1 X.509 Version 3 Certificate . . . . . . . . . . . . . . . . . . 10 77 3.2 Certification Paths and Trust . . . . . . . . . . . . . . . . . 11 78 3.3 Revocation . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 3.4 Operational Protocols . . . . . . . . . . . . . . . . . . . . . 14 80 3.5 Management Protocols . . . . . . . . . . . . . . . . . . . . . 14 81 4 Certificate and Certificate Extensions Profile . . . . . . . . . 15 82 4.1 Basic Certificate Fields . . . . . . . . . . . . . . . . . . . 16 83 4.1.1 Certificate Fields . . . . . . . . . . . . . . . . . . . . . 17 84 4.1.1.1 tbsCertificate . . . . . . . . . . . . . . . . . . . . . . 17 85 4.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . . . . . 17 86 4.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . . . . . 18 87 4.1.2 TBSCertificate . . . . . . . . . . . . . . . . . . . . . . . 18 88 4.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 4.1.2.2 Serial number . . . . . . . . . . . . . . . . . . . . . . . 19 90 4.1.2.3 Signature . . . . . . . . . . . . . . . . . . . . . . . . . 19 91 4.1.2.4 Issuer . . . . . . . . . . . . . . . . . . . . . . . . . . 19 92 4.1.2.5 Validity . . . . . . . . . . . . . . . . . . . . . . . . . 23 93 4.1.2.5.1 UTCTime . . . . . . . . . . . . . . . . . . . . . . . . . 23 94 4.1.2.5.2 GeneralizedTime . . . . . . . . . . . . . . . . . . . . . 23 95 4.1.2.6 Subject . . . . . . . . . . . . . . . . . . . . . . . . . . 24 96 4.1.2.7 Subject Public Key Info . . . . . . . . . . . . . . . . . . 25 97 4.1.2.8 Unique Identifiers . . . . . . . . . . . . . . . . . . . . 25 98 4.1.2.9 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 25 99 4.2 Certificate Extensions . . . . . . . . . . . . . . . . . . . . 25 100 4.2.1 Standard Extensions . . . . . . . . . . . . . . . . . . . . . 26 101 4.2.1.1 Authority Key Identifier . . . . . . . . . . . . . . . . . 27 102 4.2.1.2 Subject Key Identifier . . . . . . . . . . . . . . . . . . 28 103 4.2.1.3 Key Usage . . . . . . . . . . . . . . . . . . . . . . . . . 29 104 4.2.1.4 Private Key Usage Period . . . . . . . . . . . . . . . . . 30 105 4.2.1.5 Certificate Policies . . . . . . . . . . . . . . . . . . . 31 106 4.2.1.6 Policy Mappings . . . . . . . . . . . . . . . . . . . . . . 33 107 4.2.1.7 Subject Alternative Name . . . . . . . . . . . . . . . . . 34 108 4.2.1.8 Issuer Alternative Name . . . . . . . . . . . . . . . . . . 37 109 4.2.1.9 Subject Directory Attributes . . . . . . . . . . . . . . . 37 110 4.2.1.10 Basic Constraints . . . . . . . . . . . . . . . . . . . . 37 111 4.2.1.11 Name Constraints . . . . . . . . . . . . . . . . . . . . . 38 112 4.2.1.12 Policy Constraints . . . . . . . . . . . . . . . . . . . . 40 113 4.2.1.13 Extended key usage field . . . . . . . . . . . . . . . . . 41 114 4.2.1.14 CRL Distribution Points . . . . . . . . . . . . . . . . . 43 115 4.2.1.15 Inhibit Any-Policy . . . . . . . . . . . . . . . . . . . . 44 116 4.2.1.16 Freshest CRL . . . . . . . . . . . . . . . . . . . . . . . 45 117 4.2.2 Internet Certificate Extensions . . . . . . . . . . . . . . . 45 118 4.2.2.1 Authority Information Access . . . . . . . . . . . . . . . 45 119 4.2.2.2 Subject Information Access . . . . . . . . . . . . . . . . 47 120 5 CRL and CRL Extensions Profile . . . . . . . . . . . . . . . . . 48 121 5.1 CRL Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 49 122 5.1.1 CertificateList Fields . . . . . . . . . . . . . . . . . . . 50 123 5.1.1.1 tbsCertList . . . . . . . . . . . . . . . . . . . . . . . . 50 124 5.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . . . . . 51 125 5.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . . . . . 51 126 5.1.2 Certificate List "To Be Signed" . . . . . . . . . . . . . . . 52 127 5.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . . . . . 52 128 5.1.2.2 Signature . . . . . . . . . . . . . . . . . . . . . . . . . 52 129 5.1.2.3 Issuer Name . . . . . . . . . . . . . . . . . . . . . . . . 52 130 5.1.2.4 This Update . . . . . . . . . . . . . . . . . . . . . . . . 52 131 5.1.2.5 Next Update . . . . . . . . . . . . . . . . . . . . . . . . 53 132 5.1.2.6 Revoked Certificates . . . . . . . . . . . . . . . . . . . 53 133 5.1.2.7 Extensions . . . . . . . . . . . . . . . . . . . . . . . . 53 134 5.2 CRL Extensions . . . . . . . . . . . . . . . . . . . . . . . . 54 135 5.2.1 Authority Key Identifier . . . . . . . . . . . . . . . . . . 54 136 5.2.2 Issuer Alternative Name . . . . . . . . . . . . . . . . . . . 54 137 5.2.3 CRL Number . . . . . . . . . . . . . . . . . . . . . . . . . 55 138 5.2.4 Delta CRL Indicator . . . . . . . . . . . . . . . . . . . . . 55 139 5.2.5 Issuing Distribution Point . . . . . . . . . . . . . . . . . 58 140 5.2.6 Freshest CRL . . . . . . . . . . . . . . . . . . . . . . . . 59 141 5.3 CRL Entry Extensions . . . . . . . . . . . . . . . . . . . . . 60 142 5.3.1 Reason Code . . . . . . . . . . . . . . . . . . . . . . . . . 60 143 5.3.2 Hold Instruction Code . . . . . . . . . . . . . . . . . . . . 61 144 5.3.3 Invalidity Date . . . . . . . . . . . . . . . . . . . . . . . 61 145 5.3.4 Certificate Issuer . . . . . . . . . . . . . . . . . . . . . 62 146 6 Certificate Path Validation . . . . . . . . . . . . . . . . . . . 62 147 6.1 Basic Path Validation . . . . . . . . . . . . . . . . . . . . . 63 148 6.1.1 Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 149 6.1.2 Initialization . . . . . . . . . . . . . . . . . . . . . . . 67 150 6.1.3 Basic Certificate Processing . . . . . . . . . . . . . . . . 69 151 6.1.4 Preparation for Certificate i+1 . . . . . . . . . . . . . . . 74 152 6.1.5 Wrap-up procedure . . . . . . . . . . . . . . . . . . . . . . 77 153 6.1.6 Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 154 6.2 Extending Path Validation . . . . . . . . . . . . . . . . . . . 79 155 6.3 CRL Validation . . . . . . . . . . . . . . . . . . . . . . . . 80 156 6.3.1 Revocation Inputs . . . . . . . . . . . . . . . . . . . . . . 80 157 6.3.2 Initialization and Revocation State Variables . . . . . . . . 81 158 6.3.3 CRL Processing . . . . . . . . . . . . . . . . . . . . . . . 81 159 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 160 8 Intellectual Property Rights . . . . . . . . . . . . . . . . . . 87 161 9 Security Considerations . . . . . . . . . . . . . . . . . . . . . 87 162 Appendix A. ASN.1 Structures and OIDs . . . . . . . . . . . . . . . 91 163 A.1 Explicitly Tagged Module, 1988 Syntax . . . . . . . . . . . . . 91 164 A.2 Implicitly Tagged Module, 1988 Syntax . . . . . . . . . . . . . 105 165 Appendix B. ASN.1 Notes . . . . . . . . . . . . . . . . . . . . . . 112 166 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . . 114 167 C.1 DSA Self-Signed Certificate . . . . . . . . . . . . . . . . . . 115 168 C.2 End Entity Certificate Using DSA . . . . . . . . . . . . . . . 118 169 C.3 End Entity Certificate Using RSA . . . . . . . . . . . . . . . 121 170 C.4 Certificate Revocation List . . . . . . . . . . . . . . . . . . 125 171 Appendix D. Author Addresses . . . . . . . . . . . . . . . . . . . 128 172 Appendix E. Full Copyright Statement . . . . . . . . . . . . . . . 128 173 1 Introduction 175 This specification is one part of a family of standards for the X.509 176 Public Key Infrastructure (PKI) for the Internet. This specification 177 is a standalone document; implementations of this standard may 178 proceed independent from the other parts. 180 This specification profiles the format and semantics of certificates 181 and certificate revocation lists for the Internet PKI. Procedures 182 are described for processing of certification paths in the Internet 183 environment. Encoding rules are provided for popular cryptographic 184 algorithms. Finally, ASN.1 modules are provided in the appendices 185 for all data structures defined or referenced. 187 The specification describes the requirements which inspire the 188 creation of this document and the assumptions which affect its scope 189 in Section 2. Section 3 presents an architectural model and 190 describes its relationship to previous IETF and ISO/IEC/ITU 191 standards. In particular, this document's relationship with the IETF 192 PEM specifications and the ISO/IEC/ITU X.509 documents are described. 194 The specification profiles the X.509 version 3 certificate in Section 195 4, and the X.509 version 2 certificate revocation list (CRL) in 196 Section 5. The profiles include the identification of ISO/IEC/ITU 197 and ANSI extensions which may be useful in the Internet PKI. The 198 profiles are presented in the 1988 Abstract Syntax Notation One 199 (ASN.1) rather than the 1997 ASN.1 syntax used in the ISO/IEC/ITU 200 standards. 202 This specification also includes path validation procedures in 203 Section 6. These procedures are based upon the ISO/IEC/ITU 204 definition, but the presentation assumes one or more self-signed 205 trusted CA certificates. Implementations are required to derive the 206 same results but are not required to use the specified procedures. 208 Procedures for identification and encoding of public key materials 209 and digital signatures are defined in [PKIXALGS]. Implementations of 210 this specification are not required to use any particular 211 cryptographic algorithms. However, conforming implementations which 212 use the algorithms identified in [PKIXALGS] MUST identify and encode 213 the public key materials and digital signatures as described in that 214 specification. 216 Finally, three appendices are provided to aid implementers. Appendix 217 A contains all ASN.1 structures defined or referenced within this 218 specification. As above, the material is presented in the 1988 219 ASN.1. Appendix B contains notes on less familiar features of the 220 ASN.1 notation used within this specification. Appendix C contains 221 examples of a conforming certificate and a conforming CRL. 223 2 Requirements and Assumptions 225 The goal of this specification is to develop a profile to facilitate 226 the use of X.509 certificates within Internet applications for those 227 communities wishing to make use of X.509 technology. Such 228 applications may include WWW, electronic mail, user authentication, 229 and IPsec. In order to relieve some of the obstacles to using X.509 230 certificates, this document defines a profile to promote the 231 development of certificate management systems; development of 232 application tools; and interoperability determined by policy. 234 Some communities will need to supplement, or possibly replace, this 235 profile in order to meet the requirements of specialized application 236 domains or environments with additional authorization, assurance, or 237 operational requirements. However, for basic applications, common 238 representations of frequently used attributes are defined so that 239 application developers can obtain necessary information without 240 regard to the issuer of a particular certificate or certificate 241 revocation list (CRL). 243 A certificate user should review the certificate policy generated by 244 the certification authority (CA) before relying on the authentication 245 or non-repudiation services associated with the public key in a 246 particular certificate. To this end, this standard does not 247 prescribe legally binding rules or duties. 249 As supplemental authorization and attribute management tools emerge, 250 such as attribute certificates, it may be appropriate to limit the 251 authenticated attributes that are included in a certificate. These 252 other management tools may provide more appropriate methods of 253 conveying many authenticated attributes. 255 2.1 Communication and Topology 257 The users of certificates will operate in a wide range of 258 environments with respect to their communication topology, especially 259 users of secure electronic mail. This profile supports users without 260 high bandwidth, real-time IP connectivity, or high connection 261 availability. In addition, the profile allows for the presence of 262 firewall or other filtered communication. 264 This profile does not assume the deployment of an X.500 Directory 265 system or a LDAP directory system. The profile does not prohibit the 266 use of an X.500 Directory or a LDAP directory; however, any means of 267 distributing certificates and certificate revocation lists (CRLs) may 268 be used. 270 2.2 Acceptability Criteria 272 The goal of the Internet Public Key Infrastructure (PKI) is to meet 273 the needs of deterministic, automated identification, authentication, 274 access control, and authorization functions. Support for these 275 services determines the attributes contained in the certificate as 276 well as the ancillary control information in the certificate such as 277 policy data and certification path constraints. 279 2.3 User Expectations 281 Users of the Internet PKI are people and processes who use client 282 software and are the subjects named in certificates. These uses 283 include readers and writers of electronic mail, the clients for WWW 284 browsers, WWW servers, and the key manager for IPsec within a router. 285 This profile recognizes the limitations of the platforms these users 286 employ and the limitations in sophistication and attentiveness of the 287 users themselves. This manifests itself in minimal user 288 configuration responsibility (e.g., trusted CA keys, rules), explicit 289 platform usage constraints within the certificate, certification path 290 constraints which shield the user from many malicious actions, and 291 applications which sensibly automate validation functions. 293 2.4 Administrator Expectations 295 As with user expectations, the Internet PKI profile is structured to 296 support the individuals who generally operate CAs. Providing 297 administrators with unbounded choices increases the chances that a 298 subtle CA administrator mistake will result in broad compromise. 299 Also, unbounded choices greatly complicate the software that process 300 and validate the certificates created by the CA. 302 3 Overview of Approach 304 Following is a simplified view of the architectural model assumed by 305 the PKIX specifications. 307 +---+ 308 | C | +------------+ 309 | e | <-------------------->| End entity | 310 | r | Operational +------------+ 311 | t | transactions ^ 312 | i | and management | Management 313 | f | transactions | transactions PKI 314 | i | | users 315 | c | v 316 | a | ======================= +--+------------+ ============== 317 | t | ^ ^ 318 | e | | | PKI 319 | | v | management 320 | & | +------+ | entities 321 | | <---------------------| RA |<----+ | 322 | C | Publish certificate +------+ | | 323 | R | | | 324 | L | | | 325 | | v v 326 | R | +------------+ 327 | e | <------------------------------| CA | 328 | p | Publish certificate +------------+ 329 | o | Publish CRL ^ ^ 330 | s | | | Management 331 | i | +------------+ | | transactions 332 | t | <--------------| CRL Issuer |<----+ | 333 | o | Publish CRL +------------+ v 334 | r | +------+ 335 | y | | CA | 336 +---+ +------+ 338 Figure 1 - PKI Entities 340 The components in this model are: 342 end entity: user of PKI certificates and/or end user system that 343 is the subject of a certificate; 344 CA: certification authority; 345 RA: registration authority, i.e., an optional system to 346 which a CA delegates certain management functions; 347 CRL issuer: an optional system to which a CA delegates the 348 publication of certificate revocation lists; 349 repository: a system or collection of distributed systems that 350 store certificates and CRLs and serves as a means of 351 distributing these certificates and CRLs to end 352 entities. 354 Note that an Attribute Authority (AA) might also choose to delegate 355 the publication of CRLs to a CRL issuer. 357 3.1 X.509 Version 3 Certificate 359 Users of a public key require confidence that the associated private 360 key is owned by the correct remote subject (person or system) with 361 which an encryption or digital signature mechanism will be used. 362 This confidence is obtained through the use of public key 363 certificates, which are data structures that bind public key values 364 to subjects. The binding is asserted by having a trusted CA 365 digitally sign each certificate. The CA may base this assertion upon 366 technical means (a.k.a., proof of possession through a challenge- 367 response protocol), presentation of the private key, or on an 368 assertion by the subject. A certificate has a limited valid lifetime 369 which is indicated in its signed contents. Because a certificate's 370 signature and timeliness can be independently checked by a 371 certificate-using client, certificates can be distributed via 372 untrusted communications and server systems, and can be cached in 373 unsecured storage in certificate-using systems. 375 ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8, which was 376 first published in 1988 as part of the X.500 Directory 377 recommendations, defines a standard certificate format [X.509]. The 378 certificate format in the 1988 standard is called the version 1 (v1) 379 format. When X.500 was revised in 1993, two more fields were added, 380 resulting in the version 2 (v2) format. 382 The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993, 383 include specifications for a public key infrastructure based on X.509 384 v1 certificates [RFC 1422]. The experience gained in attempts to 385 deploy RFC 1422 made it clear that the v1 and v2 certificate formats 386 are deficient in several respects. Most importantly, more fields 387 were needed to carry information which PEM design and implementation 388 experience has proven necessary. In response to these new 389 requirements, ISO/IEC/ITU and ANSI X9 developed the X.509 version 3 390 (v3) certificate format. The v3 format extends the v2 format by 391 adding provision for additional extension fields. Particular 392 extension field types may be specified in standards or may be defined 393 and registered by any organization or community. In June 1996, 394 standardization of the basic v3 format was completed [X.509]. 396 ISO/IEC/ITU and ANSI X9 have also developed standard extensions for 397 use in the v3 extensions field [X.509][X9.55]. These extensions can 398 convey such data as additional subject identification information, 399 key attribute information, policy information, and certification path 400 constraints. 402 However, the ISO/IEC/ITU and ANSI X9 standard extensions are very 403 broad in their applicability. In order to develop interoperable 404 implementations of X.509 v3 systems for Internet use, it is necessary 405 to specify a profile for use of the X.509 v3 extensions tailored for 406 the Internet. It is one goal of this document to specify a profile 407 for Internet WWW, electronic mail, and IPsec applications. 408 Environments with additional requirements may build on this profile 409 or may replace it. 411 3.2 Certification Paths and Trust 413 A user of a security service requiring knowledge of a public key 414 generally needs to obtain and validate a certificate containing the 415 required public key. If the public-key user does not already hold an 416 assured copy of the public key of the CA that signed the certificate, 417 the CA's name, and related information (such as the validity period 418 or name constraints), then it might need an additional certificate to 419 obtain that public key. In general, a chain of multiple certificates 420 may be needed, comprising a certificate of the public key owner (the 421 end entity) signed by one CA, and zero or more additional 422 certificates of CAs signed by other CAs. Such chains, called 423 certification paths, are required because a public key user is only 424 initialized with a limited number of assured CA public keys. 426 There are different ways in which CAs might be configured in order 427 for public key users to be able to find certification paths. For 428 PEM, RFC 1422 defined a rigid hierarchical structure of CAs. There 429 are three types of PEM certification authority: 431 (a) Internet Policy Registration Authority (IPRA): This 432 authority, operated under the auspices of the Internet Society, 433 acts as the root of the PEM certification hierarchy at level 1. 434 It issues certificates only for the next level of authorities, 435 PCAs. All certification paths start with the IPRA. 437 (b) Policy Certification Authorities (PCAs): PCAs are at level 2 438 of the hierarchy, each PCA being certified by the IPRA. A PCA 439 shall establish and publish a statement of its policy with respect 440 to certifying users or subordinate certification authorities. 441 Distinct PCAs aim to satisfy different user needs. For example, 442 one PCA (an organizational PCA) might support the general 443 electronic mail needs of commercial organizations, and another PCA 444 (a high-assurance PCA) might have a more stringent policy designed 445 for satisfying legally binding digital signature requirements. 447 (c) Certification Authorities (CAs): CAs are at level 3 of the 448 hierarchy and can also be at lower levels. Those at level 3 are 449 certified by PCAs. CAs represent, for example, particular 450 organizations, particular organizational units (e.g., departments, 451 groups, sections), or particular geographical areas. 453 RFC 1422 furthermore has a name subordination rule which requires 454 that a CA can only issue certificates for entities whose names are 455 subordinate (in the X.500 naming tree) to the name of the CA itself. 456 The trust associated with a PEM certification path is implied by the 457 PCA name. The name subordination rule ensures that CAs below the PCA 458 are sensibly constrained as to the set of subordinate entities they 459 can certify (e.g., a CA for an organization can only certify entities 460 in that organization's name tree). Certificate user systems are able 461 to mechanically check that the name subordination rule has been 462 followed. 464 The RFC 1422 uses the X.509 v1 certificate formats. The limitations 465 of X.509 v1 required imposition of several structural restrictions to 466 clearly associate policy information or restrict the utility of 467 certificates. These restrictions included: 469 (a) a pure top-down hierarchy, with all certification paths 470 starting from IPRA; 472 (b) a naming subordination rule restricting the names of a CA's 473 subjects; and 475 (c) use of the PCA concept, which requires knowledge of 476 individual PCAs to be built into certificate chain verification 477 logic. Knowledge of individual PCAs was required to determine if 478 a chain could be accepted. 480 With X.509 v3, most of the requirements addressed by RFC 1422 can be 481 addressed using certificate extensions, without a need to restrict 482 the CA structures used. In particular, the certificate extensions 483 relating to certificate policies obviate the need for PCAs and the 484 constraint extensions obviate the need for the name subordination 485 rule. As a result, this document supports a more flexible 486 architecture, including: 488 (a) Certification paths start with a public key of a CA in a 489 user's own domain, or with the public key of the top of a 490 hierarchy. Starting with the public key of a CA in a user's own 491 domain has certain advantages. In some environments, the local 492 domain is the most trusted. 494 (b) Name constraints may be imposed through explicit inclusion of 495 a name constraints extension in a certificate, but are not 496 required. 498 (c) Policy extensions and policy mappings replace the PCA 499 concept, which permits a greater degree of automation. The 500 application can determine if the certification path is acceptable 501 based on the contents of the certificates instead of a priori 502 knowledge of PCAs. This permits automation of certificate chain 503 processing. 505 3.3 Revocation 507 When a certificate is issued, it is expected to be in use for its 508 entire validity period. However, various circumstances may cause a 509 certificate to become invalid prior to the expiration of the validity 510 period. Such circumstances include change of name, change of 511 association between subject and CA (e.g., an employee terminates 512 employment with an organization), and compromise or suspected 513 compromise of the corresponding private key. Under such 514 circumstances, the CA needs to revoke the certificate. 516 X.509 defines one method of certificate revocation. This method 517 involves each CA periodically issuing a signed data structure called 518 a certificate revocation list (CRL). A CRL is a time stamped list 519 identifying revoked certificates which is signed by a CA and made 520 freely available in a public repository. Each revoked certificate is 521 identified in a CRL by its certificate serial number. When a 522 certificate-using system uses a certificate (e.g., for verifying a 523 remote user's digital signature), that system not only checks the 524 certificate signature and validity but also acquires a suitably- 525 recent CRL and checks that the certificate serial number is not on 526 that CRL. The meaning of "suitably-recent" may vary with local 527 policy, but it usually means the most recently-issued CRL. A CA 528 issues a new CRL on a regular periodic basis (e.g., hourly, daily, or 529 weekly). An entry is added to the CRL as part of the next update 530 following notification of revocation. An entry MUST NOT be removed 531 from the CRL until it appears on one regularly scheduled CRL issued 532 beyond the revoked certificate's validity period. 534 An advantage of this revocation method is that CRLs may be 535 distributed by exactly the same means as certificates themselves, 536 namely, via untrusted servers and untrusted communications. 538 One limitation of the CRL revocation method, using untrusted 539 communications and servers, is that the time granularity of 540 revocation is limited to the CRL issue period. For example, if a 541 revocation is reported now, that revocation will not be reliably 542 notified to certificate-using systems until all currently issued CRLs 543 are updated -- this may be up to one hour, one day, or one week 544 depending on the frequency that CRLs are issued. 546 As with the X.509 v3 certificate format, in order to facilitate 547 interoperable implementations from multiple vendors, the X.509 v2 CRL 548 format needs to be profiled for Internet use. It is one goal of this 549 document to specify that profile. However, this profile does not 550 require CAs to issue CRLs. Message formats and protocols supporting 551 on-line revocation notification are defined in other PKIX 552 specifications. On-line methods of revocation notification may be 553 applicable in some environments as an alternative to the X.509 CRL. 554 On-line revocation checking may significantly reduce the latency 555 between a revocation report and the distribution of the information 556 to relying parties. Once the CA accepts the report as authentic and 557 valid, any query to the on-line service will correctly reflect the 558 certificate validation impacts of the revocation. However, these 559 methods impose new security requirements: the certificate validator 560 needs to trust the on-line validation service while the repository 561 does not need to be trusted. 563 3.4 Operational Protocols 565 Operational protocols are required to deliver certificates and CRLs 566 (or status information) to certificate using client systems. 567 Provision is needed for a variety of different means of certificate 568 and CRL delivery, including distribution procedures based on LDAP, 569 HTTP, FTP, and X.500. Operational protocols supporting these 570 functions are defined in other PKIX specifications. These 571 specifications may include definitions of message formats and 572 procedures for supporting all of the above operational environments, 573 including definitions of or references to appropriate MIME content 574 types. 576 3.5 Management Protocols 578 Management protocols are required to support on-line interactions 579 between PKI user and management entities. For example, a management 580 protocol might be used between a CA and a client system with which a 581 key pair is associated, or between two CAs which cross-certify each 582 other. The set of functions which potentially need to be supported 583 by management protocols include: 585 (a) registration: This is the process whereby a user first makes 586 itself known to a CA (directly, or through an RA), prior to that 587 CA issuing a certificate or certificates for that user. 589 (b) initialization: Before a client system can operate securely 590 it is necessary to install key materials which have the 591 appropriate relationship with keys stored elsewhere in the 592 infrastructure. For example, the client needs to be securely 593 initialized with the public key and other assured information of 594 the trusted CA(s), to be used in validating certificate paths. 596 Furthermore, a client typically needs to be initialized with its 597 own key pair(s). 599 (c) certification: This is the process in which a CA issues a 600 certificate for a user's public key, and returns that certificate 601 to the user's client system and/or posts that certificate in a 602 repository. 604 (d) key pair recovery: As an option, user client key materials 605 (e.g., a user's private key used for encryption purposes) may be 606 backed up by a CA or a key backup system. If a user needs to 607 recover these backed up key materials (e.g., as a result of a 608 forgotten password or a lost key chain file), an on-line protocol 609 exchange may be needed to support such recovery. 611 (e) key pair update: All key pairs need to be updated regularly, 612 i.e., replaced with a new key pair, and new certificates issued. 614 (f) revocation request: An authorized person advises a CA of an 615 abnormal situation requiring certificate revocation. 617 (g) cross-certification: Two CAs exchange information used in 618 establishing a cross-certificate. A cross-certificate is a 619 certificate issued by one CA to another CA which contains a CA 620 signature key used for issuing certificates. 622 Note that on-line protocols are not the only way of implementing the 623 above functions. For all functions there are off-line methods of 624 achieving the same result, and this specification does not mandate 625 use of on-line protocols. For example, when hardware tokens are 626 used, many of the functions may be achieved as part of the physical 627 token delivery. Furthermore, some of the above functions may be 628 combined into one protocol exchange. In particular, two or more of 629 the registration, initialization, and certification functions can be 630 combined into one protocol exchange. 632 The PKIX series of specifications defines a set of standard message 633 formats supporting the above functions. The protocols for conveying 634 these messages in different environments (e.g., e-mail, file 635 transfer, and WWW) are described in those specifications. 637 4 Certificate and Certificate Extensions Profile 639 This section presents a profile for public key certificates that will 640 foster interoperability and a reusable PKI. This section is based 641 upon the X.509 v3 certificate format and the standard certificate 642 extensions defined in [X.509]. The ISO/IEC/ITU documents use the 643 1997 version of ASN.1; while this document uses the 1988 ASN.1 644 syntax, the encoded certificate and standard extensions are 645 equivalent. This section also defines private extensions required to 646 support a PKI for the Internet community. 648 Certificates may be used in a wide range of applications and 649 environments covering a broad spectrum of interoperability goals and 650 a broader spectrum of operational and assurance requirements. The 651 goal of this document is to establish a common baseline for generic 652 applications requiring broad interoperability and limited special 653 purpose requirements. In particular, the emphasis will be on 654 supporting the use of X.509 v3 certificates for informal Internet 655 electronic mail, IPsec, and WWW applications. 657 4.1 Basic Certificate Fields 659 The X.509 v3 certificate basic syntax is as follows. For signature 660 calculation, the certificate is encoded using the ASN.1 distinguished 661 encoding rules (DER) [X.208]. ASN.1 DER encoding is a tag, length, 662 value encoding system for each element. 664 Certificate ::= SEQUENCE { 665 tbsCertificate TBSCertificate, 666 signatureAlgorithm AlgorithmIdentifier, 667 signatureValue BIT STRING } 669 TBSCertificate ::= SEQUENCE { 670 version [0] EXPLICIT Version DEFAULT v1, 671 serialNumber CertificateSerialNumber, 672 signature AlgorithmIdentifier, 673 issuer Name, 674 validity Validity, 675 subject Name, 676 subjectPublicKeyInfo SubjectPublicKeyInfo, 677 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 678 -- If present, version MUST be v2 or v3 679 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 680 -- If present, version MUST be v2 or v3 681 extensions [3] EXPLICIT Extensions OPTIONAL 682 -- If present, version MUST be v3 683 } 685 Version ::= INTEGER { v1(0), v2(1), v3(2) } 687 CertificateSerialNumber ::= INTEGER 689 Validity ::= SEQUENCE { 690 notBefore Time, 691 notAfter Time } 693 Time ::= CHOICE { 694 utcTime UTCTime, 695 generalTime GeneralizedTime } 697 UniqueIdentifier ::= BIT STRING 699 SubjectPublicKeyInfo ::= SEQUENCE { 700 algorithm AlgorithmIdentifier, 701 subjectPublicKey BIT STRING } 703 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 705 Extension ::= SEQUENCE { 706 extnID OBJECT IDENTIFIER, 707 critical BOOLEAN DEFAULT FALSE, 708 extnValue OCTET STRING } 710 The following items describe the X.509 v3 certificate for use in the 711 Internet. 713 4.1.1 Certificate Fields 715 The Certificate is a SEQUENCE of three required fields. The fields 716 are described in detail in the following subsections. 718 4.1.1.1 tbsCertificate 720 The field contains the names of the subject and issuer, a public key 721 associated with the subject, a validity period, and other associated 722 information. The fields are described in detail in section 4.1.2; 723 the tbsCertificate MAY also include extensions which are described in 724 section 4.2. 726 4.1.1.2 signatureAlgorithm 728 The signatureAlgorithm field contains the identifier for the 729 cryptographic algorithm used by the CA to sign this certificate. 730 [PKIXALGS] lists supported signature algorithms, but other signature 731 algorithms MAY also be supported. 733 An algorithm identifier is defined by the following ASN.1 structure: 735 AlgorithmIdentifier ::= SEQUENCE { 736 algorithm OBJECT IDENTIFIER, 737 parameters ANY DEFINED BY algorithm OPTIONAL } 739 The algorithm identifier is used to identify a cryptographic 740 algorithm. The OBJECT IDENTIFIER component identifies the algorithm 741 (such as DSA with SHA-1). The contents of the optional parameters 742 field will vary according to the algorithm identified. [PKIXALGS] 743 lists supported algorithms, but other algorithms MAY also be 744 implemented. 746 This field MUST contain the same algorithm identifier as the 747 signature field in the sequence tbsCertificate (section 4.1.2.3). 749 4.1.1.3 signatureValue 751 The signatureValue field contains a digital signature computed upon 752 the ASN.1 DER encoded tbsCertificate. The ASN.1 DER encoded 753 tbsCertificate is used as the input to the signature function. This 754 signature value is then ASN.1 encoded as a BIT STRING and included in 755 the signature field. The details of this process are specified for 756 each of algorithms listed in [PKIXALGS]. 758 By generating this signature, a CA certifies the validity of the 759 information in the tbsCertificate field. In particular, the CA 760 certifies the binding between the public key material and the subject 761 of the certificate. 763 4.1.2 TBSCertificate 765 The sequence TBSCertificate contains information associated with the 766 subject of the certificate and the CA who issued it. Every 767 TBSCertificate contains the names of the subject and issuer, a public 768 key associated with the subject, a validity period, a version number, 769 and a serial number; some MAY contain optional unique identifier 770 fields. The remainder of this section describes the syntax and 771 semantics of these fields. A TBSCertificate MAY also include 772 extensions. Extensions for the Internet PKI are described in Section 773 4.2. 775 4.1.2.1 Version 777 This field describes the version of the encoded certificate. When 778 extensions are used, as expected in this profile, use X.509 version 3 779 (value is 2). If no extensions are present, but a UniqueIdentifier 780 is present, use version 2 (value is 1). If only basic fields are 781 present, use version 1 (the value is omitted from the certificate as 782 the default value). 784 Implementations SHOULD be prepared to accept any version certificate. 785 At a minimum, conforming implementations MUST recognize version 3 786 certificates. 788 Generation of version 2 certificates is not expected by 789 implementations based on this profile. 791 4.1.2.2 Serial number 793 The serial number MUST be a positive integer assigned by the CA to 794 each certificate. It MUST be unique for each certificate issued by a 795 given CA (i.e., the issuer name and serial number identify a unique 796 certificate). CAs MUST force the serialNumber to be a non-negative 797 integer. 799 Given the uniqueness requirements above, serial numbers can be 800 expected to contain long integers. Certificate users MUST be able to 801 handle serialNumber values up to 20 octets. Conformant CAs MUST NOT 802 use serialNumber values longer than 20 octets. 804 Note: Non-conforming CAs MAY issue certificates with serial numbers 805 that are negative, or zero. Certificate users SHOULD be prepared to 806 handle such certificates. 808 4.1.2.3 Signature 810 This field contains the algorithm identifier for the algorithm used 811 by the CA to sign the certificate. 813 This field MUST contain the same algorithm identifier as the 814 signatureAlgorithm field in the sequence Certificate (section 815 4.1.1.2). The contents of the optional parameters field will vary 816 according to the algorithm identified. [PKIXALGS] lists the 817 supported signature algorithms. 819 4.1.2.4 Issuer 821 The issuer field identifies the entity who has signed and issued the 822 certificate. The issuer field MUST contain a non-empty distinguished 823 name (DN). The issuer field is defined as the X.501 type Name 824 [X.501]. Name is defined by the following ASN.1 structures: 826 Name ::= CHOICE { 827 RDNSequence } 829 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 831 RelativeDistinguishedName ::= 832 SET OF AttributeTypeAndValue 834 AttributeTypeAndValue ::= SEQUENCE { 835 type AttributeType, 836 value AttributeValue } 838 AttributeType ::= OBJECT IDENTIFIER 840 AttributeValue ::= ANY DEFINED BY AttributeType 842 DirectoryString ::= CHOICE { 843 teletexString TeletexString (SIZE (1..MAX)), 844 printableString PrintableString (SIZE (1..MAX)), 845 universalString UniversalString (SIZE (1..MAX)), 846 utf8String UTF8String (SIZE (1..MAX)), 847 bmpString BMPString (SIZE (1..MAX)) } 849 The Name describes a hierarchical name composed of attributes, such 850 as country name, and corresponding values, such as US. The type of 851 the component AttributeValue is determined by the AttributeType; in 852 general it will be a DirectoryString. 854 The DirectoryString type is defined as a choice of PrintableString, 855 TeletexString, BMPString, UTF8String, and UniversalString. The 856 UTF8String encoding [RFC 2279] is the preferred encoding, and all 857 certificates issued after December 31, 2003 MUST use the UTF8String 858 encoding of DirectoryString (except as noted below). Until that 859 date, conforming CAs MUST choose from the following options when 860 creating a distinguished name, including their own: 862 (a) if the character set is sufficient, the string MAY be 863 represented as a PrintableString; 865 (b) failing (a), if the BMPString character set is sufficient the 866 string MAY be represented as a BMPString; and 868 (c) failing (a) and (b), the string MUST be represented as a 869 UTF8String. If (a) or (b) is satisfied, the CA MAY still choose 870 to represent the string as a UTF8String. 872 Exceptions to the December 31, 2003 UTF8 encoding requirements are as 873 follows: 875 (a) CAs MAY issue "name rollover" certificates to support an 876 orderly migration to UTF8String encoding. Such certificates would 877 include the CA's UTF8String encoded name as issuer and and the old 878 name encoding as subject, or vice-versa. 880 (b) As stated in section 4.1.2.6, the subject field MUST be 881 populated with a non-empty distinguished name matching the 882 contents of the issuer field in all certificates issued by the 883 subject CA regardless of encoding. 885 The TeletexString and UniversalString are included for backward 886 compatibility, and SHOULD NOT be used for certificates for new 887 subjects. However, these types MAY be used in certificates where the 888 name was previously established. Certificate users SHOULD be 889 prepared to receive certificates with these types. 891 In addition, many legacy implementations support names encoded in the 892 ISO 8859-1 character set (Latin1String) but tag them as 893 TeletexString. The Latin1String includes characters used in Western 894 European countries which are not part of the TeletexString charcter 895 set. Implementations that process TeletexString SHOULD be prepared 896 to handle the entire ISO 8859-1 character set.[ISO 8859-1] 898 As noted above, distinguished names are composed of attributes. This 899 specification does not restrict the set of attribute types that may 900 appear in names. However, conforming implementations MUST be 901 prepared to receive certificates with issuer names containing the set 902 of attribute types defined below. This specification RECOMMENDS 903 support for additional attribute types. 905 Standard sets of attributes have been defined in the X.500 series of 906 specifications.[X.520] Implementations of this specification MUST be 907 prepared to receive the following standard attribute types in issuer 908 and subject (section 4.1.2.6) names: 910 * country, 911 * organization, 912 * organizational-unit, 913 * distinguished name qualifier, 914 * state or province name, 915 * common name (e.g., "Susan Housley"), and 916 * serial number. 918 In addition, implementations of this specification SHOULD be prepared 919 to receive the following standard attribute types in issuer and 920 subject names: 922 * locality, 923 * title, 924 * surname, 925 * given name, 926 * initials, 927 * pseudonym, and 928 * generation qualifier (e.g., "Jr.", "3rd", or "IV"). 930 The syntax and associated object identifiers (OIDs) for these 931 attribute types are provided in the ASN.1 modules in Appendix A. 933 In addition, implementations of this specification MUST be prepared 934 to receive the domainComponent attribute, as defined in [RFC 2247]. 935 The Domain (Nameserver) System (DNS) provides a hierarchical resource 936 labeling system. This attribute provides a convenient mechanism for 937 organizations that wish to use DNs that parallel their DNS names. 938 This is not a replacement for the dNSName component of the 939 alternative name field. Implementations are not required to convert 940 such names into DNS names. The syntax and associated OID for this 941 attribute type is provided in the ASN.1 modules in Appendix A. 943 Certificate users MUST be prepared to process the issuer 944 distinguished name and subject distinguished name (section 4.1.2.6) 945 fields to perform name chaining for certification path validation 946 (section 6). Name chaining is performed by matching the issuer 947 distinguished name in one certificate with the subject name in a CA 948 certificate. 950 This specification requires only a subset of the name comparison 951 functionality specified in the X.500 series of specifications. The 952 requirements for conforming implementations are as follows: 954 (a) attribute values encoded in different types (e.g., 955 PrintableString and BMPString) MAY be assumed to represent 956 different strings; 958 (b) attribute values in types other than PrintableString are case 959 sensitive (this permits matching of attribute values as binary 960 objects); 962 (c) attribute values in PrintableString are not case sensitive 963 (e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and 965 (d) attribute values in PrintableString are compared after 966 removing leading and trailing white space and converting internal 967 substrings of one or more consecutive white space characters to a 968 single space. 970 These name comparison rules permit a certificate user to validate 971 certificates issued using languages or encodings unfamiliar to the 972 certificate user. 974 In addition, implementations of this specification MAY use these 975 comparison rules to process unfamiliar attribute types for name 976 chaining. This allows implementations to process certificates with 977 unfamiliar attributes in the issuer name. 979 Note that the comparison rules defined in the X.500 series of 980 specifications indicate that the character sets used to encode data 981 in distinguished names are irrelevant. The characters themselves are 982 compared without regard to encoding. Implementations of the profile 983 are permitted to use the comparison algorithm defined in the X.500 984 series. Such an implementation will recognize a superset of name 985 matches recognized by the algorithm specified above. 987 4.1.2.5 Validity 989 The certificate validity period is the time interval during which the 990 CA warrants that it will maintain information about the status of the 991 certificate. The field is represented as a SEQUENCE of two dates: 992 the date on which the certificate validity period begins (notBefore) 993 and the date on which the certificate validity period ends 994 (notAfter). Both notBefore and notAfter may be encoded as UTCTime or 995 GeneralizedTime. 997 CAs conforming to this profile MUST always encode certificate 998 validity dates through the year 2049 as UTCTime; certificate validity 999 dates in 2050 or later MUST be encoded as GeneralizedTime. 1001 The validity period for a certificate is the period of time from 1002 notBefore through notAfter, inclusive. 1004 4.1.2.5.1 UTCTime 1006 The universal time type, UTCTime, is a standard ASN.1 type intended 1007 for representation of dates and time. UTCTime specifies the year 1008 through the two low order digits and time is specified to the 1009 precision of one minute or one second. UTCTime includes either Z 1010 (for Zulu, or Greenwich Mean Time) or a time differential. 1012 For the purposes of this profile, UTCTime values MUST be expressed 1013 Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are 1014 YYMMDDHHMMSSZ), even where the number of seconds is zero. Conforming 1015 systems MUST interpret the year field (YY) as follows: 1017 Where YY is greater than or equal to 50, the year SHALL be 1018 interpreted as 19YY; and 1020 Where YY is less than 50, the year SHALL be interpreted as 20YY. 1022 4.1.2.5.2 GeneralizedTime 1024 The generalized time type, GeneralizedTime, is a standard ASN.1 type 1025 for variable precision representation of time. Optionally, the 1026 GeneralizedTime field can include a representation of the time 1027 differential between local and Greenwich Mean Time. 1029 For the purposes of this profile, GeneralizedTime values MUST be 1030 expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e., 1031 times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. 1032 GeneralizedTime values MUST NOT include fractional seconds. 1034 4.1.2.6 Subject 1036 The subject field identifies the entity associated with the public 1037 key stored in the subject public key field. The subject name MAY be 1038 carried in the subject field and/or the subjectAltName extension. If 1039 the subject is a CA (e.g., the basic constraints extension, as 1040 discussed in 4.2.1.10, is present and the value of cA is TRUE,) then 1041 the subject field MUST be populated with a non-empty distinguished 1042 name matching the contents of the issuer field (section 4.1.2.4) in 1043 all certificates issued by the subject CA. If subject naming 1044 information is present only in the subjectAltName extension (e.g., a 1045 key bound only to an email address or URI), then the subject name 1046 MUST be an empty sequence and the subjectAltName extension MUST be 1047 critical. 1049 Where it is non-empty, the subject field MUST contain an X.500 1050 distinguished name (DN). The DN MUST be unique for each subject 1051 entity certified by the one CA as defined by the issuer name field. 1052 A CA MAY issue more than one certificate with the same DN to the same 1053 subject entity. 1055 The subject name field is defined as the X.501 type Name. 1056 Implementation requirements for this field are those defined for the 1057 issuer field (section 4.1.2.4). When encoding attribute values of 1058 type DirectoryString, the encoding rules for the issuer field MUST be 1059 implemented. Implementations of this specification MUST be prepared 1060 to receive subject names containing the attribute types required for 1061 the issuer field. Implementations of this specification SHOULD be 1062 prepared to receive subject names containing the recommended 1063 attribute types for the issuer field. The syntax and associated 1064 object identifiers (OIDs) for these attribute types are provided in 1065 the ASN.1 modules in Appendix A. Implementations of this 1066 specification MAY use these comparison rules to process unfamiliar 1067 attribute types (i.e., for name chaining). This allows 1068 implementations to process certificates with unfamiliar attributes in 1069 the subject name. 1071 In addition, legacy implementations exist where an RFC 822 name is 1072 embedded in the subject distinguished name as an EmailAddress 1073 attribute. The attribute value for EmailAddress is of type IA5String 1074 to permit inclusion of the character '@', which is not part of the 1075 PrintableString character set. EmailAddress attribute values are not 1076 case sensitive (e.g., "fanfeedback@redsox.com" is the same as 1077 "FANFEEDBACK@REDSOX.COM"). 1079 Conforming implementations generating new certificates with 1080 electronic mail addresses MUST use the rfc822Name in the subject 1081 alternative name field (section 4.2.1.7) to describe such identities. 1082 Simultaneous inclusion of the EmailAddress attribute in the subject 1083 distinguished name to support legacy implementations is deprecated 1084 but permitted. 1086 4.1.2.7 Subject Public Key Info 1088 This field is used to carry the public key and identify the algorithm 1089 with which the key is used (e.g., RSA, DSA, or Diffie-Hellman). The 1090 algorithm is identified using the AlgorithmIdentifier structure 1091 specified in section 4.1.1.2. The object identifiers for the 1092 supported algorithms and the methods for encoding the public key 1093 materials (public key and parameters) are specified in [PKIXALGS]. 1095 4.1.2.8 Unique Identifiers 1097 These fields MUST only appear if the version is 2 or 3 (section 1098 4.1.2.1). These fields MUST NOT appear if the version is 1. The 1099 subject and issuer unique identifiers are present in the certificate 1100 to handle the possibility of reuse of subject and/or issuer names 1101 over time. This profile RECOMMENDS that names not be reused for 1102 different entities and that Internet certificates not make use of 1103 unique identifiers. CAs conforming to this profile SHOULD NOT 1104 generate certificates with unique identifiers. Applications 1105 conforming to this profile SHOULD be capable of parsing unique 1106 identifiers and making comparisons. 1108 4.1.2.9 Extensions 1110 This field MUST only appear if the version is 3 (section 4.1.2.1). 1111 If present, this field is a SEQUENCE of one or more certificate 1112 extensions. The format and content of certificate extensions in the 1113 Internet PKI is defined in section 4.2. 1115 4.2 Certificate Extensions 1117 The extensions defined for X.509 v3 certificates provide methods for 1118 associating additional attributes with users or public keys and for 1119 managing the certification hierarchy. The X.509 v3 certificate 1120 format also allows communities to define private extensions to carry 1121 information unique to those communities. Each extension in a 1122 certificate is designated as either critical or non-critical. A 1123 certificate using system MUST reject the certificate if it encounters 1124 a critical extension it does not recognize; however, a non-critical 1125 extension MAY be ignored if it is not recognized. The following 1126 sections present recommended extensions used within Internet 1127 certificates and standard locations for information. Communities MAY 1128 elect to use additional extensions; however, caution SHOULD be 1129 exercised in adopting any critical extensions in certificates which 1130 might prevent use in a general context. 1132 Each extension includes an OID and an ASN.1 structure. When an 1133 extension appears in a certificate, the OID appears as the field 1134 extnID and the corresponding ASN.1 encoded structure is the value of 1135 the octet string extnValue. Only one instance of a particular 1136 extension MUST appear in a particular certificate. For example, a 1137 certificate may contain only one authority key identifier extension 1138 (section 4.2.1.1). An extension includes the boolean critical, with 1139 a default value of FALSE. The text for each extension specifies the 1140 acceptable values for the critical field. 1142 Conforming CAs MUST support key identifiers (sections 4.2.1.1 and 1143 4.2.1.2), basic constraints (section 4.2.1.10), key usage (section 1144 4.2.1.3), and certificate policies (section 4.2.1.5) extensions. If 1145 the CA issues certificates with an empty sequence for the subject 1146 field, the CA MUST support the subject alternative name extension 1147 (section 4.2.1.7). Support for the remaining extensions is OPTIONAL. 1148 Conforming CAs MAY support extensions that are not identified within 1149 this specification; certificate issuers are cautioned that marking 1150 such extensions as critical may inhibit interoperability. 1152 At a minimum, applications conforming to this profile MUST recognize 1153 the following extensions: key usage (section 4.2.1.3), certificate 1154 policies (section 4.2.1.5), the subject alternative name (section 1155 4.2.1.7), basic constraints (section 4.2.1.10), name constraints 1156 (section 4.2.1.11), policy constraints (section 4.2.1.12), extended 1157 key usage (section 4.2.1.13), and inhibit any-policy (section 1158 4.2.1.15). 1160 In addition, applications conforming to this profile SHOULD recognize 1161 the authority and subject key identifier (sections 4.2.1.1 and 1162 4.2.1.2), and policy mapping (section 4.2.1.6) extensions. 1164 4.2.1 Standard Extensions 1166 This section identifies standard certificate extensions defined in 1167 [X.509] for use in the Internet PKI. Each extension is associated 1168 with an OID defined in [X.509]. These OIDs are members of the id-ce 1169 arc, which is defined by the following: 1171 id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 1173 4.2.1.1 Authority Key Identifier 1175 The authority key identifier extension provides a means of 1176 identifying the public key corresponding to the private key used to 1177 sign a certificate. This extension is used where an issuer has 1178 multiple signing keys (either due to multiple concurrent key pairs or 1179 due to changeover). The identification MAY be based on either the 1180 key identifier (the subject key identifier in the issuer's 1181 certificate) or on the issuer name and serial number. 1183 The keyIdentifier field of the authorityKeyIdentifier extension MUST 1184 be included in all certificates generated by conforming CAs to 1185 facilitate chain building. There is one exception; where a CA 1186 distributes its public key in the form of a "self-signed" 1187 certificate, the authority key identifier MAY be omitted. The 1188 signature on a self-signed certificate is generated with the private 1189 key associated with the certificate's subject public key. (This 1190 proves that the issuer possesses both the public and private keys.) 1191 In this case, the subject and authority key identifiers would be 1192 identical, but only the subject key identifier is needed for 1193 certification path building. 1195 The value of the keyIdentifier field SHOULD be derived from the 1196 public key used to verify the certificate's signature or a method 1197 that generates unique values. Two common methods for generating key 1198 identifiers from the public key are described in (sec. 4.2.1.2). One 1199 common method for generating unique values is described in (sec. 1200 4.2.1.2). Where a key identifier has not been previously 1201 established, this specification recommends use of one of these 1202 methods for generating keyIdentifiers. 1204 This profile recommends support for the key identifier method by all 1205 certificate users. 1207 This extension MUST NOT be marked critical. 1209 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 1211 AuthorityKeyIdentifier ::= SEQUENCE { 1212 keyIdentifier [0] KeyIdentifier OPTIONAL, 1213 authorityCertIssuer [1] GeneralNames OPTIONAL, 1214 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 1216 KeyIdentifier ::= OCTET STRING 1218 4.2.1.2 Subject Key Identifier 1220 The subject key identifier extension provides a means of identifying 1221 certificates that contain a particular public key. 1223 To facilitate chain building, this extension MUST appear in all 1224 conforming CA certificates, that is, all certificates including the 1225 basic constraints extension (section 4.2.1.10) where the value of cA 1226 is TRUE. The value of the subject key identifier MUST be the value 1227 placed in the key identifier field of the Authority Key Identifier 1228 extension (section 4.2.1.1) of certificates issued by the subject of 1229 this certificate. 1231 For CA certificates, subject key identifiers SHOULD be derived from 1232 the public key or a method that generates unique values. The key 1233 identifier is an explicit value placed in the certificate by the 1234 issuer, not a value generated by a certificate user. Two common 1235 methods for generating key identifiers from the public key are: 1237 (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the 1238 value of the BIT STRING subjectPublicKey (excluding the tag, 1239 length, and number of unused bits). 1241 (2) The keyIdentifier is composed of a four bit type field with 1242 the value 0100 followed by the least significant 60 bits of the 1243 SHA-1 hash of the value of the BIT STRING subjectPublicKey 1244 (excluding the tag, length, and number of unused bit string bits). 1246 One common method for generating unique values is a monotonically 1247 increasing sequence of integers. 1249 For end entity certificates, the subject key identifier extension 1250 provides a means for identifying certificates containing the 1251 particular public key used in an application. Where an end entity 1252 has obtained multiple certificates, especially from multiple CAs, the 1253 subject key identifier provides a means to quickly identify the set 1254 of certificates containing a particular public key. To assist 1255 applications in identifying the appropriate end entity certificate, 1256 this extension SHOULD be included in all end entity certificates. 1258 For end entity certificates, subject key identifiers SHOULD be 1259 derived from the public key. Two common methods for generating key 1260 identifiers from the public key are identified above. 1262 Where a key identifier has not been previously established, this 1263 specification recommends use of one of these methods for generating 1264 keyIdentifiers. 1266 This extension MUST NOT be marked critical. 1268 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 1270 SubjectKeyIdentifier ::= KeyIdentifier 1272 4.2.1.3 Key Usage 1274 The key usage extension defines the purpose (e.g., encipherment, 1275 signature, certificate signing) of the key contained in the 1276 certificate. The usage restriction might be employed when a key that 1277 could be used for more than one operation is to be restricted. For 1278 example, when an RSA key should be used only to verify signatures on 1279 objects other than public key certificates and CRLs, the 1280 digitalSignature and/or nonRepudiation bits would be asserted. 1281 Likewise, when an RSA key should be used only for key management, the 1282 keyEncipherment bit would be asserted. 1284 This extension MUST appear in certificates that contain public keys 1285 that are used to validate digital signatures on other public key 1286 certificates or CRLs. When this extension appears, it SHOULD be 1287 marked critical. 1289 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 1291 KeyUsage ::= BIT STRING { 1292 digitalSignature (0), 1293 nonRepudiation (1), 1294 keyEncipherment (2), 1295 dataEncipherment (3), 1296 keyAgreement (4), 1297 keyCertSign (5), 1298 cRLSign (6), 1299 encipherOnly (7), 1300 decipherOnly (8) } 1302 Bits in the KeyUsage type are used as follows: 1304 The digitalSignature bit is asserted when the subject public key 1305 is used with a digital signature mechanism to support security 1306 services other than non-repudiation (bit 1), certificate signing 1307 (bit 5), or CRL signing (bit 6). Digital signature mechanisms are 1308 often used for entity authentication and data origin 1309 authentication with integrity. 1311 The nonRepudiation bit is asserted when the subject public key is 1312 used to verify digital signatures used to provide a non- 1313 repudiation service which protects against the signing entity 1314 falsely denying some action, excluding certificate or CRL signing. 1315 In the case of later conflict, a reliable third party may 1316 determine the authenticity of the signed data. 1318 Further distinctions between the digitalSignature and 1319 nonRepudiation bits may be provided in specific certificate 1320 policies. 1322 The keyEncipherment bit is asserted when the subject public key is 1323 used for key transport. For example, when an RSA key is to be 1324 used for key management, then this bit is set. 1326 The dataEncipherment bit is asserted when the subject public key 1327 is used for enciphering user data, other than cryptographic keys. 1329 The keyAgreement bit is asserted when the subject public key is 1330 used for key agreement. For example, when a Diffie-Hellman key is 1331 to be used for key management, then this bit is set. 1333 The keyCertSign bit is asserted when the subject public key is 1334 used for verifying a signature on public key certificates. If the 1335 keyCertSign bit is asserted, then the cA bit in the basic 1336 constraints extension (section 4.2.1.10) MUST also be asserted. 1338 The cRLSign bit is asserted when the subject public key is used 1339 for verifying a signature on certificate revocation list (e.g., a 1340 CRL, delta CRL, or an ARL). This bit MUST be asserted in 1341 certificates that are used to verify signatures on CRLs. 1343 The meaning of the encipherOnly bit is undefined in the absence of 1344 the keyAgreement bit. When the encipherOnly bit is asserted and 1345 the keyAgreement bit is also set, the subject public key may be 1346 used only for enciphering data while performing key agreement. 1348 The meaning of the decipherOnly bit is undefined in the absence of 1349 the keyAgreement bit. When the decipherOnly bit is asserted and 1350 the keyAgreement bit is also set, the subject public key may be 1351 used only for deciphering data while performing key agreement. 1353 This profile does not restrict the combinations of bits that may be 1354 set in an instantiation of the keyUsage extension. However, 1355 appropriate values for keyUsage extensions for particular algorithms 1356 are specified in [PKIXALGS]. 1358 4.2.1.4 Private Key Usage Period 1360 This profile RECOMMENDS against the use of this extension. CAs 1361 conforming to this profile MUST NOT generate certificates that 1362 include a critical private key usage period extension. 1364 The private key usage period extension allows the certificate issuer 1365 to specify a different validity period for the private key than the 1366 certificate. This extension is intended for use with digital 1367 signature keys. This extension consists of two optional components, 1368 notBefore and notAfter. The private key associated with the 1369 certificate SHOULD NOT be used to sign objects before or after the 1370 times specified by the two components, respectively. CAs conforming 1371 to this profile MUST NOT generate certificates with private key usage 1372 period extensions unless at least one of the two components is 1373 present. 1375 Where used, notBefore and notAfter are represented as GeneralizedTime 1376 and MUST be specified and interpreted as defined in section 1377 4.1.2.5.2. 1379 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 1381 PrivateKeyUsagePeriod ::= SEQUENCE { 1382 notBefore [0] GeneralizedTime OPTIONAL, 1383 notAfter [1] GeneralizedTime OPTIONAL } 1385 4.2.1.5 Certificate Policies 1387 The certificate policies extension contains a sequence of one or more 1388 policy information terms, each of which consists of an object 1389 identifier (OID) and optional qualifiers. Optional qualifiers, which 1390 MAY be present, are not expected to change the definition of the 1391 policy. 1393 In an end entity certificate, these policy information terms indicate 1394 the policy under which the certificate has been issued and the 1395 purposes for which the certificate may be used. In a CA certificate, 1396 these policy information terms limit the set of policies for 1397 certification paths which include this certificate. When a CA does 1398 not wish to limit the set of policies for certification paths which 1399 include this certificate, they MAY assert the special policy 1400 anyPolicy, with a value of { 2 5 29 32 0 }. 1402 Applications with specific policy requirements are expected to have a 1403 list of those policies which they will accept and to compare the 1404 policy OIDs in the certificate to that list. If this extension is 1405 critical, the path validation software MUST be able to interpret this 1406 extension (including the optional qualifier), or MUST reject the 1407 certificate. 1409 To promote interoperability, this profile RECOMMENDS that policy 1410 information terms consist of only an OID. Where an OID alone is 1411 insufficient, this profile strongly recommends that use of qualifiers 1412 be limited to those identified in this section. When qualifiers are 1413 used with the special policy anyPolicy, they MUST be limited to the 1414 qualifiers identified in this section. 1416 This specification defines two policy qualifier types for use by 1417 certificate policy writers and certificate issuers. The qualifier 1418 types are the CPS Pointer and User Notice qualifiers. 1420 The CPS Pointer qualifier contains a pointer to a Certification 1421 Practice Statement (CPS) published by the CA. The pointer is in the 1422 form of a URI. Processing requirements for this qualifier are a 1423 local matter. No action is mandated by this specification regardless 1424 of the criticality value asserted for the extension. 1426 User notice is intended for display to a relying party when a 1427 certificate is used. The application software SHOULD display all 1428 user notices in all certificates of the certification path used, 1429 except that if a notice is duplicated only one copy need be 1430 displayed. To prevent such duplication, this qualifier SHOULD only 1431 be present in end entity certificates and CA certificates issued to 1432 other organizations. 1434 The user notice has two optional fields: the noticeRef field and the 1435 explicitText field. 1437 The noticeRef field, if used, names an organization and 1438 identifies, by number, a particular textual statement prepared by 1439 that organization. For example, it might identify the 1440 organization "CertsRUs" and notice number 1. In a typical 1441 implementation, the application software will have a notice file 1442 containing the current set of notices for CertsRUs; the 1443 application will extract the notice text from the file and display 1444 it. Messages MAY be multilingual, allowing the software to select 1445 the particular language message for its own environment. 1447 An explicitText field includes the textual statement directly in 1448 the certificate. The explicitText field is a string with a 1449 maximum size of 200 characters. 1451 If both the noticeRef and explicitText options are included in the 1452 one qualifier and if the application software can locate the notice 1453 text indicated by the noticeRef option then that text SHOULD be 1454 displayed; otherwise, the explicitText string SHOULD be displayed. 1456 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 1457 anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificate-policies 0 } 1459 certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 1461 PolicyInformation ::= SEQUENCE { 1462 policyIdentifier CertPolicyId, 1463 policyQualifiers SEQUENCE SIZE (1..MAX) OF 1464 PolicyQualifierInfo OPTIONAL } 1466 CertPolicyId ::= OBJECT IDENTIFIER 1468 PolicyQualifierInfo ::= SEQUENCE { 1469 policyQualifierId PolicyQualifierId, 1470 qualifier ANY DEFINED BY policyQualifierId } 1472 -- policyQualifierIds for Internet policy qualifiers 1474 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 1475 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 1476 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 1478 PolicyQualifierId ::= 1479 OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) 1481 Qualifier ::= CHOICE { 1482 cPSuri CPSuri, 1483 userNotice UserNotice } 1485 CPSuri ::= IA5String 1487 UserNotice ::= SEQUENCE { 1488 noticeRef NoticeReference OPTIONAL, 1489 explicitText DisplayText OPTIONAL} 1491 NoticeReference ::= SEQUENCE { 1492 organization DisplayText, 1493 noticeNumbers SEQUENCE OF INTEGER } 1495 DisplayText ::= CHOICE { 1496 ia5String IA5String (SIZE (1..200)), 1497 visibleString VisibleString (SIZE (1..200)), 1498 bmpString BMPString (SIZE (1..200)), 1499 utf8String UTF8String (SIZE (1..200)) } 1501 4.2.1.6 Policy Mappings 1503 This extension is used in CA certificates. It lists one or more 1504 pairs of OIDs; each pair includes an issuerDomainPolicy and a 1505 subjectDomainPolicy. The pairing indicates the issuing CA considers 1506 its issuerDomainPolicy equivalent to the subject CA's 1507 subjectDomainPolicy. 1509 The issuing CA's users might accept an issuerDomainPolicy for certain 1510 applications. The policy mapping defines the list of policies 1511 associated with the subject CA that may be accepted as comparable to 1512 the issuerDomainPolicy. 1514 Each issuerDomainPolicy named in the policy mapping extension SHOULD 1515 also be asserted in a certificate policies extension in the same 1516 certificate. Policies SHOULD NOT be mapped either to or from the 1517 special value anyPolicy (section 4.2.1.5). 1519 This extension MAY be supported by CAs and/or applications, and it 1520 MUST be non-critical. 1522 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 1524 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 1525 issuerDomainPolicy CertPolicyId, 1526 subjectDomainPolicy CertPolicyId } 1528 4.2.1.7 Subject Alternative Name 1530 The subject alternative names extension allows additional identities 1531 to be bound to the subject of the certificate. Defined options 1532 include an Internet electronic mail address, a DNS name, an IP 1533 address, and a uniform resource identifier (URI). Other options 1534 exist, including completely local definitions. Multiple name forms, 1535 and multiple instances of each name form, MAY be included. Whenever 1536 such identities are to be bound into a certificate, the subject 1537 alternative name (or issuer alternative name) extension MUST be used; 1538 however, a DNS name MAY be represented in the subject field using the 1539 domainComponent attribute as described in section 4.1.2.4. 1541 Because the subject alternative name is considered to be definitively 1542 bound to the public key, all parts of the subject alternative name 1543 MUST be verified by the CA. 1545 Further, if the only subject identity included in the certificate is 1546 an alternative name form (e.g., an electronic mail address), then the 1547 subject distinguished name MUST be empty (an empty sequence), and the 1548 subjectAltName extension MUST be present. If the subject field 1549 contains an empty sequence, the subjectAltName extension MUST be 1550 marked critical. 1552 When the subjectAltName extension contains an Internet mail address, 1553 the address MUST be included as an rfc822Name. The format of an 1554 rfc822Name is an "addr-spec" as defined in RFC 822 [RFC 822]. An 1555 addr-spec has the form "local-part@domain". Note that an addr-spec 1556 has no phrase (such as a common name) before it, has no comment (text 1557 surrounded in parentheses) after it, and is not surrounded by "<" and 1558 ">". Note that while upper and lower case letters are allowed in an 1559 RFC 822 addr-spec, no significance is attached to the case. 1561 When the subjectAltName extension contains a iPAddress, the address 1562 MUST be stored in the octet string in "network byte order," as 1563 specified in RFC 791 [RFC 791]. The least significant bit (LSB) of 1564 each octet is the LSB of the corresponding byte in the network 1565 address. For IP Version 4, as specified in RFC 791, the octet string 1566 MUST contain exactly four octets. For IP Version 6, as specified in 1567 RFC 1883, the octet string MUST contain exactly sixteen octets [RFC 1568 1883]. 1570 When the subjectAltName extension contains a domain name service 1571 label, the domain name MUST be stored in the dNSName (an IA5String). 1572 The name MUST be in the "preferred name syntax," as specified by RFC 1573 1034 [RFC 1034]. Note that while upper and lower case letters are 1574 allowed in domain names, no signifigance is attached to the case. In 1575 addition, while the string " " is a legal domain name, subjectAltName 1576 extensions with a dNSName " " are not permitted. Finally, the use of 1577 the DNS representation for Internet mail addresses (wpolk.nist.gov 1578 instead of wpolk@nist.gov) MUST NOT be used; such identities are to 1579 be encoded as rfc822Name. 1581 Note: work is currently underway to specify domain names in 1582 international character sets. This names will likely not be 1583 accomodated by IA5String. Once this work is complete, this profile 1584 will be revisited and the appropriate functionality will be added. 1586 When the subjectAltName extension contains a URI, the name MUST be 1587 stored in the uniformResourceIdentifier (an IA5String). The name 1588 MUST NOT be a relative URL, and it MUST follow the URL syntax and 1589 encoding rules specified in [RFC 1738]. The name MUST include both a 1590 scheme (e.g., "http" or "ftp") and a scheme-specific-part. The 1591 scheme-specific-part MUST include a fully qualified domain name or IP 1592 address as the host. 1594 As specified in [RFC 1738], the scheme name is not case-sensitive 1595 (e.g., "http" is equivalent to "HTTP"). The host part is also not 1596 case-sensitive, but other components of the scheme-specific-part may 1597 be case-sensitive. When comparing URIs, conforming implementations 1598 MUST compare the scheme and host without regard to case, but assume 1599 the remainder of the scheme-specific-part is case sensitive. 1601 When the subjectAltName extension contains a DN in the directoryName, 1602 the DN MUST be unique for each subject entity certified by the one CA 1603 as defined by the issuer name field. A CA MAY issue more than one 1604 certificate with the same DN to the same subject entity. 1606 The subjectAltName MAY carry additional name types through the use of 1607 the otherName field. The format and semantics of the name are 1608 indicated through the OBJECT IDENTIFIER in the type-id field. The 1609 name itself is conveyed as value field in otherName. For example, 1610 Kerberos [RFC 1510] format names can be encoded into the otherName, 1611 using using a Kerberos 5 principal name OID and a SEQUENCE of the 1612 Realm and the PrincipalName. 1614 Subject alternative names MAY be constrained in the same manner as 1615 subject distinguished names using the name constraints extension as 1616 described in section 4.2.1.11. 1618 If the subjectAltName extension is present, the sequence MUST contain 1619 at least one entry. Unlike the subject field, conforming CAs MUST 1620 NOT issue certificates with subjectAltNames containing empty 1621 GeneralName fields. For example, an rfc822Name is represented as an 1622 IA5String. While an empty string is a valid IA5String, such an 1623 rfc822Name is not permitted by this profile. The behavior of clients 1624 that encounter such a certificate when processing a certificication 1625 path is not defined by this profile. 1627 Finally, the semantics of subject alternative names that include 1628 wildcard characters (e.g., as a placeholder for a set of names) are 1629 not addressed by this specification. Applications with specific 1630 requirements MAY use such names, but they MUST define the semantics. 1632 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 1634 SubjectAltName ::= GeneralNames 1636 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 1638 GeneralName ::= CHOICE { 1639 otherName [0] OtherName, 1640 rfc822Name [1] IA5String, 1641 dNSName [2] IA5String, 1642 x400Address [3] ORAddress, 1643 directoryName [4] Name, 1644 ediPartyName [5] EDIPartyName, 1645 uniformResourceIdentifier [6] IA5String, 1646 iPAddress [7] OCTET STRING, 1647 registeredID [8] OBJECT IDENTIFIER} 1649 OtherName ::= SEQUENCE { 1650 type-id OBJECT IDENTIFIER, 1651 value [0] EXPLICIT ANY DEFINED BY type-id } 1653 EDIPartyName ::= SEQUENCE { 1654 nameAssigner [0] DirectoryString OPTIONAL, 1655 partyName [1] DirectoryString } 1657 4.2.1.8 Issuer Alternative Names 1659 As with 4.2.1.7, this extension is used to associate Internet style 1660 identities with the certificate issuer. Issuer alternative names MUST 1661 be encoded as in 4.2.1.7. 1663 Where present, this extension SHOULD NOT be marked critical. 1665 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 1667 IssuerAltName ::= GeneralNames 1669 4.2.1.9 Subject Directory Attributes 1671 The subject directory attributes extension is used to convey 1672 identification attributes (e.g., nationality) of the subject. The 1673 extension is defined as a sequence of one or more attributes. This 1674 extension MUST be non-critical. 1676 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 1678 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 1680 4.2.1.10 Basic Constraints 1682 The basic constraints extension identifies whether the subject of the 1683 certificate is a CA and the maximum depth of valid certification 1684 paths that include this certificate. 1686 The cA boolean indicates whether the certified public key belongs to 1687 a CA. If the cA boolean is not asserted, then the keyCertSign bit in 1688 the key usage extension MUST NOT be asserted. 1690 The pathLenConstraint field is meaningful only if the cA boolean is 1691 asserted and the key usage extension asserts the keyCertSign bit 1692 (section 4.2.1.3). In this case, it gives the maximum number of non- 1693 self-issued intermediate certificates that may follow this 1694 certificate in a valid certification path. A certificate is self- 1695 issued if the DNs that appear in the subject and issuer fields are 1696 identical and are not empty. (Note: The last certificate in the 1697 certification path is not an intermediate certificate, and is not 1698 included in this limit. Usually, the last certificate is an end 1699 entity certificate, but it can be a CA certificate.) A 1700 pathLenConstraint of zero indicates that only one more certificate 1701 may follow in a valid certification path. Where it appears, the 1702 pathLenConstraint field MUST be greater than or equal to zero. Where 1703 pathLenConstraint does not appear, no limit is imposed. 1705 This extension MUST appear as a critical extension in all CA 1706 certificates that contain public keys used to validate digital 1707 signatures on certificates. This extension MAY appear as a critical 1708 or non-critical extension in CA certificates that contain public keys 1709 used exclusively for purposes other than validating digital 1710 signatures on certificates. Such CA certificates include ones that 1711 contain public keys used exclusively for validating digital 1712 signatures on CRLs and ones that contain key management public keys 1713 used with certificate enrollment protocols. This extension MAY 1714 appear as a critical or non-critical extension in end entity 1715 certificates. 1717 CAs MUST NOT include the pathLenConstraint field unless the cA 1718 boolean is asserted and the key usage extension asserts the 1719 keyCertSign bit. 1721 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 1723 BasicConstraints ::= SEQUENCE { 1724 cA BOOLEAN DEFAULT FALSE, 1725 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 1727 4.2.1.11 Name Constraints 1729 The name constraints extension, which MUST be used only in a CA 1730 certificate, indicates a name space within which all subject names in 1731 subsequent certificates in a certification path MUST be located. 1732 Restrictions apply to the subject distinguished name and apply to 1733 subject alternative names. Restrictions apply only when the 1734 specified name form is present. If no name of the type is in the 1735 certificate, the certificate is acceptable. 1737 Name constraints are not applied to certificates whose issuer and 1738 subject are identical (unless the certificate is the final 1739 certificate in the path). (This could prevent CAs that use name 1740 constraints from employing self-issued certificates to implement key 1741 rollover.) 1743 Restrictions are defined in terms of permitted or excluded name 1744 subtrees. Any name matching a restriction in the excludedSubtrees 1745 field is invalid regardless of information appearing in the 1746 permittedSubtrees. This extension MUST be critical. 1748 Within this profile, the minimum and maximum fields are not used with 1749 any name forms, thus minimum is always zero, and maximum is always 1750 absent. 1752 For URIs, the constraint applies to the host part of the name. The 1753 constraint MAY specify a host or a domain. Examples would be 1754 "foo.bar.com"; and ".xyz.com". When the the constraint begins with 1755 a period, it MAY be expanded with one or more subdomains. That is, 1756 the constraint ".xyz.com" is satisfied by both abc.xyz.com and 1757 abc.def.xyz.com. However, the constraint ".xyz.com" is not satisfied 1758 by "xyz.com". When the constraint does not begin with a period, it 1759 specifies a host. 1761 A name constraint for Internet mail addresses MAY specify a 1762 particular mailbox, all addresses at a particular host, or all 1763 mailboxes in a domain. To indicate a particular mailbox, the 1764 constraint is the complete mail address. For example, "root@xyz.com" 1765 indicates the root mailbox on the host "xyz.com". To indicate all 1766 Internet mail addresses on a particular host, the constraint is 1767 specified as the host name. For example, the constraint "xyz.com" is 1768 satisfied by any mail address at the host "xyz.com". To specify any 1769 address within a domain, the constraint is specified with a leading 1770 period (as with URIs). For example, ".xyz.com" indicates all the 1771 Internet mail addresses in the domain "xyz.com", but not Internet 1772 mail addresses on the host "xyz.com". 1774 DNS name restrictions are expressed as foo.bar.com. Any DNS name that 1775 can be constructed by simply adding to the left hand side of the name 1776 satisfies the name constraint. For example, www.foo.bar.com would 1777 satisfy the constraint but foo1.bar.com would not. 1779 Legacy implementations exist where an RFC 822 name is embedded in the 1780 subject distinguished name in an attribute of type EmailAddress 1781 (section 4.1.2.6). When rfc822 names are constrained, but the 1782 certificate does not include a subject alternative name, the rfc822 1783 name constraint MUST be applied to the attribute of type EmailAddress 1784 in the subject distinguished name. The ASN.1 syntax for EmailAddress 1785 and the corresponding OID are supplied in Appendix A. 1787 Restrictions of the form directoryName MUST be applied to the subject 1788 field in the certificate and to the subjectAltName extensions of type 1789 directoryName. Restrictions of the form x400Address MUST be applied 1790 to subjectAltName extensions of type x400Address. 1792 When applying restrictions of the form directoryName, an 1793 implementation MUST compare DN attributes. At a minimum, 1794 implementations MUST perform the DN comparison rules specified in 1795 Section 4.1.2.4. CAs issuing certificates with a restriction of the 1796 form directoryName SHOULD NOT rely on implementation of the full ISO 1797 DN name comparison algorithm. This implies name restrictions MUST be 1798 stated identically to the encoding used in the subject field or 1799 subjectAltName extension. 1801 The syntax of iPAddress MUST be as described in section 4.2.1.7 with 1802 the following additions specifically for Name Constraints. For IPv4 1803 addresses, the ipAddress field of generalName MUST contain eight (8) 1804 octets, encoded in the style of RFC 1519 (CIDR) to represent an 1805 address range.[RFC 1519] For IPv6 addresses, the ipAddress field 1806 MUST contain 32 octets similarly encoded. For example, a name 1807 constraint for "class C" subnet 10.9.8.0 is represented as the octets 1808 0A 09 08 00 FF FF FF 00, representing the CIDR notation 1809 10.9.8.0/255.255.255.0. 1811 The syntax and semantics for name constraints for otherName, 1812 ediPartyName, and registeredID are not defined by this specification. 1814 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 1816 NameConstraints ::= SEQUENCE { 1817 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 1818 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 1820 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 1822 GeneralSubtree ::= SEQUENCE { 1823 base GeneralName, 1824 minimum [0] BaseDistance DEFAULT 0, 1825 maximum [1] BaseDistance OPTIONAL } 1827 BaseDistance ::= INTEGER (0..MAX) 1829 4.2.1.12 Policy Constraints 1831 The policy constraints extension can be used in certificates issued 1832 to CAs. The policy constraints extension constrains path validation 1833 in two ways. It can be used to prohibit policy mapping or require 1834 that each certificate in a path contain an acceptable policy 1835 identifier. 1837 If the inhibitPolicyMapping field is present, the value indicates the 1838 number of additional certificates that may appear in the path before 1839 policy mapping is no longer permitted. For example, a value of one 1840 indicates that policy mapping may be processed in certificates issued 1841 by the subject of this certificate, but not in additional 1842 certificates in the path. 1844 If the requireExplicitPolicy field is present, subsequent 1845 certificates MUST include an acceptable policy identifier. The value 1846 of requireExplicitPolicy indicates the number of additional 1847 certificates that may appear in the path before an explicit policy is 1848 required. An acceptable policy identifier is the identifier of a 1849 policy required by the user of the certification path or the 1850 identifier of a policy which has been declared equivalent through 1851 policy mapping. 1853 Conforming CAs MUST NOT issue certificates where policy constraints 1854 is a empty sequence. That is, at least one of the 1855 inhibitPolicyMapping field or the requireExplicitPolicy field MUST be 1856 present. The behavior of clients that encounter a empty policy 1857 constraints field is not addressed in this profile. 1859 This extension MAY be critical or non-critical. 1861 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } 1863 PolicyConstraints ::= SEQUENCE { 1864 requireExplicitPolicy [0] SkipCerts OPTIONAL, 1865 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 1867 SkipCerts ::= INTEGER (0..MAX) 1869 4.2.1.13 Extended key usage field 1871 This field indicates one or more purposes for which the certified 1872 public key may be used, in addition to or in place of the basic 1873 purposes indicated in the key usage extension field. In general, 1874 this extension will appear only in end entity certificates. This 1875 field is defined as follows: 1877 id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 } 1879 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 1881 KeyPurposeId ::= OBJECT IDENTIFIER 1883 Key purposes may be defined by any organization with a need. Object 1884 identifiers used to identify key purposes MUST be assigned in 1885 accordance with IANA or ITU-T Recommendation X.660. [X.660] 1887 This extension MAY, at the option of the certificate issuer, be 1888 either critical or non-critical. 1890 If the extension is flagged critical, then the certificate MUST only 1891 be used for one of the purposes indicated. If multiple purposes are 1892 indicated the application need not recognize all purposes indicated, 1893 as long as the intended purpose is present and recognized. 1895 If the extension is flagged non-critical, then it indicates the 1896 intended purpose or purposes of the key, and MAY be used in finding 1897 the correct key/certificate of an entity that has multiple 1898 keys/certificates. It is an advisory field and does not imply that 1899 usage of the key is restricted by the certification authority to the 1900 purpose indicated. Certificate using applications MAY nevertheless 1901 require that a particular purpose be indicated in order for the 1902 certificate to be acceptable to that application. 1904 If a certificate contains both a critical key usage field and a 1905 critical extended key usage field, then both fields MUST be processed 1906 independently and the certificate MUST only be used for a purpose 1907 consistent with both fields. If there is no purpose consistent with 1908 both fields, then the certificate MUST NOT be used for any purpose. 1910 The following key usage purposes are defined by this profile: 1912 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 1914 id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } 1915 -- TLS WWW server authentication 1916 -- Key usage bits that may be consistent: digitalSignature, 1917 -- keyEncipherment or keyAgreement 1919 id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } 1920 -- TLS WWW client authentication 1921 -- Key usage bits that may be consistent: digitalSignature 1922 -- and/or keyAgreement 1924 id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } 1925 -- Signing of downloadable executable code 1926 -- Key usage bits that may be consistent: digitalSignature 1928 id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } 1929 -- E-mail protection 1930 -- Key usage bits that may be consistent: digitalSignature, 1931 -- nonRepudiation, and/or (keyEncipherment or keyAgreement) 1933 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 1934 -- Binding the hash of an object to a time 1935 -- Key usage bits that may be consistent: digitalSignature 1936 -- and/or nonRepudiation 1937 id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 } 1938 -- Signing OCSP responses 1939 -- Key usage bits that may be consistent: digitalSignature 1940 -- and/or nonRepudiation 1942 4.2.1.14 CRL Distribution Points 1944 The CRL distribution points extension identifies how CRL information 1945 is obtained. The extension SHOULD be non-critical, but this profile 1946 RECOMMENDS support for this extension by CAs and applications. 1947 Further discussion of CRL management is contained in section 5. 1949 The cRLDistributionPoints extension is a SEQUENCE of 1950 DistributionPoint. A DistributionPoint consists of three fields, 1951 each of which is optional: distributionPoint, reasons, and cRLIssuer. 1952 While each of these fields is optional, a DistributionPoint MUST NOT 1953 consist of only the reasons field; either distributionPoint or 1954 cRLIssuer MUST be present. If the certificate issuer is not the CRL 1955 issuer, then the cRLIssuer field MUST be present and contain the Name 1956 of the CRL issuer. If the certificate issuer is also the CRL issuer, 1957 then the cRLIssuer field MUST be omitted and the distributionPoint 1958 field MUST be present. If the the distributionPoint field is 1959 omitted, cRLIssuer MUST be present and include a Name corresponding 1960 to an X.500 or LDAP directory entry where the CRL is located. 1962 When the distributionPoint field is present, it contains either a 1963 SEQUENCE of general names or a single value, nameRelativeToCRLIssuer. 1964 If the cRLDistributionPoints extension contains a general name of 1965 type URI, the following semantics MUST be assumed: the URI is a 1966 pointer to the current CRL for the associated reasons and will be 1967 issued by the associated cRLIssuer. The expected values for the URI 1968 are those defined in 4.2.1.7. Processing rules for other values are 1969 not defined by this specification. 1971 If the DistributionPointName contains multiple values, each name 1972 describes a different mechanism to obtain the same CRL. For example, 1973 the same CRL could be available for retrieval through both LDAP and 1974 HTTP. 1976 If the DistributionPointName contains the single value 1977 nameRelativeToCRLIssuer, the value provides a distinguished name 1978 fragment. The fragment is appended to the X.500 distinguished name 1979 of the CRL issuer to obtain the distribution point name. If the 1980 cRLIssuer field in the DistributionPoint is present, then the name 1981 fragment is appended to the distinguished name that it contains; 1982 otherwise, the name fragment is appended to the certificate issuer 1983 distinguished name. The DistributionPointName MUST NOT use the 1984 nameRealtiveToCRLIssuer alternative when cRLIssuer contains more than 1985 one distinguished name. 1987 If the DistributionPoint omits the reasons field, the CRL MUST 1988 include revocation information for all reasons. 1990 The cRLIssuer identifies the entity who signs and issues the CRL. If 1991 present, the cRLIssuer MUST contain at least one an X.500 1992 distinguished name (DN), and MAY also contain other name forms. 1993 Since the cRLIssuer is compared to the CRL issuer name, the X.501 1994 type Name MUST follow the encoding rules for the issuer name field in 1995 the certificate (section 4.1.2.4). 1997 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 } 1999 CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 2001 DistributionPoint ::= SEQUENCE { 2002 distributionPoint [0] DistributionPointName OPTIONAL, 2003 reasons [1] ReasonFlags OPTIONAL, 2004 cRLIssuer [2] GeneralNames OPTIONAL } 2006 DistributionPointName ::= CHOICE { 2007 fullName [0] GeneralNames, 2008 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 2010 ReasonFlags ::= BIT STRING { 2011 unused (0), 2012 keyCompromise (1), 2013 cACompromise (2), 2014 affiliationChanged (3), 2015 superseded (4), 2016 cessationOfOperation (5), 2017 certificateHold (6), 2018 privilegeWithdrawn (7), 2019 aACompromise (8) } 2021 4.2.1.15 Inhibit Any-Policy 2023 The inhibit any-policy extension can be used in certificates issued 2024 to CAs. The inhibit any-policy indicates that the special any-policy 2025 OID, with the value { 2 5 29 32 0 }, is not considered an explicit 2026 match for other certificate policies. The value indicates the number 2027 of additional certificates that may appear in the path before any- 2028 policy is no longer permitted. For example, a value of one indicates 2029 that any-policy may be processed in certificates issued by the 2030 subject of this certificate, but not in additional certificates in 2031 the path. 2033 This extension MUST be critical. 2035 id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 } 2037 InhibitAnyPolicy ::= SkipCerts 2039 SkipCerts ::= INTEGER (0..MAX) 2041 4.2.1.16 Freshest CRL (a.k.a. Delta CRL Distribution Point) 2043 The freshest CRL extension identifies how delta CRL information is 2044 obtained. The extension MUST be non-critical. Further discussion of 2045 CRL management is contained in section 5. 2047 The same syntax is used for this extension and the 2048 cRLDistributionPoints extension, and is described in section 2049 4.2.1.14. The same conventions apply to both extensions. 2051 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } 2053 FreshestCRL ::= CRLDistributionPoints 2055 4.2.2 Private Internet Extensions 2057 This section defines two extensions for use in the Internet Public 2058 Key Infrastructure. These extensions may be used to direct 2059 applications to on-line information about the issuing CA or the 2060 subject. As the information may be available in multiple forms, each 2061 extension is a sequence of IA5String values, each of which represents 2062 a URI. The URI implicitly specifies the location and format of the 2063 information and the method for obtaining the information. 2065 An object identifier is defined for the private extension. The 2066 object identifier associated with the private extension is defined 2067 under the arc id-pe within the arc id-pkix. Any future extensions 2068 defined for the Internet PKI are also expected to be defined under 2069 the arc id-pe. 2071 id-pkix OBJECT IDENTIFIER ::= 2072 { iso(1) identified-organization(3) dod(6) internet(1) 2073 security(5) mechanisms(5) pkix(7) } 2075 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 2077 4.2.2.1 Authority Information Access 2079 The authority information access extension indicates how to access CA 2080 information and services for the issuer of the certificate in which 2081 the extension appears. Information and services may include on-line 2082 validation services and CA policy data. (The location of CRLs is not 2083 specified in this extension; that information is provided by the 2084 cRLDistributionPoints extension.) This extension may be included in 2085 subject or CA certificates, and it MUST be non-critical. 2087 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 2089 AuthorityInfoAccessSyntax ::= 2090 SEQUENCE SIZE (1..MAX) OF AccessDescription 2092 AccessDescription ::= SEQUENCE { 2093 accessMethod OBJECT IDENTIFIER, 2094 accessLocation GeneralName } 2096 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 2098 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 2100 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 2102 Each entry in the sequence AuthorityInfoAccessSyntax describes the 2103 format and location of additional information provided by the CA that 2104 issued the certificate in which this extension appears. The type and 2105 format of the information is specified by the accessMethod field; the 2106 accessLocation field specifies the location of the information. The 2107 retrieval mechanism may be implied by the accessMethod or specified 2108 by accessLocation. 2110 This profile defines two accessMethod OIDs: id-ad-caIssuers and id- 2111 ad-ocsp. 2113 The id-ad-caIssuers OID is used when the additional information lists 2114 CAs that have issued certificates superior to the CA that issued the 2115 certificate containing this extension. The referenced CA Issuers 2116 description is intended to aid certificate users in the selection of 2117 a certification path that terminates at a point trusted by the 2118 certificate user. 2120 When id-ad-caIssuers appears as accessMethod, the accessLocation 2121 field describes the referenced description server and the access 2122 protocol to obtain the referenced description. The accessLocation 2123 field is defined as a GeneralName, which can take several forms. 2124 Where the information is available via http, ftp, or ldap, 2125 accessLocation MUST be a uniformResourceIdentifier. Where the 2126 information is available via the Directory Access Protocol (DAP), 2127 accessLocation MUST be a directoryName. The entry for that 2128 directoryName contains CA certificates in the crossCertificatePair 2129 attribute. When the information is available via electronic mail, 2130 accessLocation MUST be an rfc822Name. The semantics of other id-ad- 2131 caIssuers accessLocation name forms are not defined. 2133 The id-ad-ocsp OID is used when revocation information for the 2134 certificate containing this extension is available using the Online 2135 Certificate Status Protocol (OCSP) [RFC 2560]. 2137 When id-ad-ocsp appears as accessMethod, the accessLocation field is 2138 the location of the OCSP responder, using the conventions defined in 2139 [RFC 2560]. Additional access descriptors may be defined in other 2140 PKIX specifications. 2142 4.2.2.2 Subject Information Access 2144 The subject information access extension indicates how to access 2145 information and services for the subject of the certificate in which 2146 the extension appears. When the subject is a CA, information and 2147 services may include certificate validation services and CA policy 2148 data. When the subject is an end entity, the information describes 2149 the type of services offered and how to access them. In this case, 2150 the contents of this extension are defined in the protocol 2151 specifications for the suported services. This extension may be 2152 included in subject or CA certificates, and it MUST be non-critical. 2154 id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 } 2156 SubjectInfoAccessSyntax ::= 2157 SEQUENCE SIZE (1..MAX) OF AccessDescription 2159 AccessDescription ::= SEQUENCE { 2160 accessMethod OBJECT IDENTIFIER, 2161 accessLocation GeneralName } 2163 Each entry in the sequence SubjectInfoAccessSyntax describes the 2164 format and location of additional information provided by the subject 2165 of the certificate in which this extension appears. The type and 2166 format of the information is specified by the accessMethod field; the 2167 accessLocation field specifies the location of the information. The 2168 retrieval mechanism may be implied by the accessMethod or specified 2169 by accessLocation. 2171 This profile defines one access method to be used when the subject is 2172 a CA, and one access method to be used when the subject is an end 2173 entity. Additional access methods may be defined in the future in 2174 the protocol specifications for other services. 2176 The id-ad-caRepository OID is used when the subject is a CA, and 2177 publishes its certificates and CRLs (if issued) in a repository. The 2178 accessLocation field is defined as a GeneralName, which can take 2179 several forms. Where the information is available via http, ftp, or 2180 ldap, accessLocation MUST be a uniformResourceIdentifier. Where the 2181 information is available via the directory access protocol (dap), 2182 accessLocation MUST be a directoryName. When the information is 2183 available via electronic mail, accessLocation MUST be an rfc822Name. 2184 The semantics of other name forms of of accessLocation (when 2185 accessMethod is id-ad-caRepository) are not defined by this 2186 specification. 2188 The id-ad-timeStamping OID is used when the subject offers 2189 timestamping services using the Time Stamp Protocol defined in 2190 [PKIXTSA]. Where the timestamping services are available via http or 2191 ftp, accessLocation MUST be a uniformResourceIdentifier. Where the 2192 timestamping services are available via electronic mail, 2193 accessLocation MUST be an rfc822Name. Where timestamping services 2194 are available using TCP/IP, the dNSName or ipAddress name forms may 2195 be used. The semantics of other name forms of accessLocation (when 2196 accessMethod is id-ad-timeStamping) are not defined by this 2197 specification. 2199 Additional access descriptors may be defined in other PKIX 2200 specifications. 2202 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 2204 id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 } 2206 id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 } 2208 5 CRL and CRL Extensions Profile 2210 As discussed above, one goal of this X.509 v2 CRL profile is to 2211 foster the creation of an interoperable and reusable Internet PKI. 2212 To achieve this goal, guidelines for the use of extensions are 2213 specified, and some assumptions are made about the nature of 2214 information included in the CRL. 2216 CRLs may be used in a wide range of applications and environments 2217 covering a broad spectrum of interoperability goals and an even 2218 broader spectrum of operational and assurance requirements. This 2219 profile establishes a common baseline for generic applications 2220 requiring broad interoperability. The profile defines a set of 2221 information that can be expected in every CRL. Also, the profile 2222 defines common locations within the CRL for frequently used 2223 attributes as well as common representations for these attributes. 2225 CRL issuers issue CRLs. In general, the CRL issuer is the CA. CAs 2226 publish CRLs to provide status information about the certificates 2227 they issued. However, a CA may delegate this responsibility to 2228 another trusted authority. Whenever the CRL issuer is not the CA 2229 that issued the certificates, the CRL is referred to as an indirect 2230 CRL. 2232 Each CRL has a particular scope. The CRL scope is the set of 2233 certificates that could appear on a given CRL. For example, the 2234 scope could be "all certificates issued by CA X", "all CA 2235 certificates issued by CA X", "all certificates issued by CA X that 2236 have been revoked for reasons of key compromise and CA compromise", 2237 or could be a set of certificates based on arbitrary local 2238 information, such as "all certificates issued to the NIST employees 2239 located in Boulder". 2241 A complete CRL lists all unexpired certificates, within its scope, 2242 that have been revoked for one of the revocation reasons covered by 2243 the CRL scope. The CRL issuer MAY also generate delta CRLs. A delta 2244 CRL only lists those certificates, within its scope, whose revocation 2245 status has changed since the issuance of a referenced complete CRL. 2246 The referenced complete CRL is referred to as a base CRL. The scope 2247 of a delta CRL MUST be the same as the base CRL that it references. 2249 This profile does not define any private Internet CRL extensions or 2250 CRL entry extensions. 2252 Environments with additional or special purpose requirements may 2253 build on this profile or may replace it. 2255 Conforming CAs are not required to issue CRLs if other revocation or 2256 certificate status mechanisms are provided. Conforming CAs that 2257 issue CRLs MUST issue version 2 CRLs, include the date by which the 2258 next CRL will be issued in the nextUpdate field (section 5.1.2.5), 2259 include the CRL number extension (section 5.2.3), and include the 2260 authority key identifier extension (section 5.2.1). Conforming 2261 applications that support CRLs are required to process both version 1 2262 and version 2 complete CRLs that provide revocation information for 2263 all certificates issued by one CA. Conforming applications are not 2264 required to support processing of delta CRLs, indirect CRLs, or CRLs 2265 with a scope other than all certificates issued by the CA. 2267 5.1 CRL Fields 2269 The X.509 v2 CRL syntax is as follows. For signature calculation, 2270 the data that is to be signed is ASN.1 DER encoded. ASN.1 DER 2271 encoding is a tag, length, value encoding system for each element. 2273 CertificateList ::= SEQUENCE { 2274 tbsCertList TBSCertList, 2275 signatureAlgorithm AlgorithmIdentifier, 2276 signatureValue BIT STRING } 2278 TBSCertList ::= SEQUENCE { 2279 version Version OPTIONAL, 2280 -- if present, MUST be v2 2281 signature AlgorithmIdentifier, 2282 issuer Name, 2283 thisUpdate Time, 2284 nextUpdate Time OPTIONAL, 2285 revokedCertificates SEQUENCE OF SEQUENCE { 2286 userCertificate CertificateSerialNumber, 2287 revocationDate Time, 2288 crlEntryExtensions Extensions OPTIONAL 2289 -- if present, MUST be v2 2290 } OPTIONAL, 2291 crlExtensions [0] EXPLICIT Extensions OPTIONAL 2292 -- if present, MUST be v2 2293 } 2295 -- Version, Time, CertificateSerialNumber, and Extensions 2296 -- are all defined in the ASN.1 in section 4.1 2298 -- AlgorithmIdentifier is defined in section 4.1.1.2 2300 The following items describe the use of the X.509 v2 CRL in the 2301 Internet PKI. 2303 5.1.1 CertificateList Fields 2305 The CertificateList is a SEQUENCE of three required fields. The 2306 fields are described in detail in the following subsections. 2308 5.1.1.1 tbsCertList 2310 The first field in the sequence is the tbsCertList. This field is 2311 itself a sequence containing the name of the issuer, issue date, 2312 issue date of the next list, the optional list of revoked 2313 certificates, and optional CRL extensions. When there are no revoked 2314 certificates, the revoked certificates list is absent. When one or 2315 more certificates are revoked, each entry on the revoked certificate 2316 list is defined by a sequence of user certificate serial number, 2317 revocation date, and optional CRL entry extensions. 2319 5.1.1.2 signatureAlgorithm 2321 The signatureAlgorithm field contains the algorithm identifier for 2322 the algorithm used by the CRL issuer to sign the CertificateList. 2323 The field is of type AlgorithmIdentifier, which is defined in section 2324 4.1.1.2. [PKIXALGS] lists the supported algorithms for this 2325 specification. Conforming CAs MUST use the algorithm identifiers 2326 presented in [PKIXALGS] when signing with a supported signature 2327 algorithm. 2329 This field MUST contain the same algorithm identifier as the 2330 signature field in the sequence tbsCertList (section 5.1.2.2). 2332 5.1.1.3 signatureValue 2334 The signatureValue field contains a digital signature computed upon 2335 the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded tbsCertList 2336 is used as the input to the signature function. This signature value 2337 is then ASN.1 encoded as a BIT STRING and included in the CRL's 2338 signatureValue field. The details of this process are specified for 2339 each of the supported algorithms in [PKIXALGS]. 2341 CAs that are also CRL issuers MAY use one private key to digitally 2342 sign certificates and CRLs, or MAY use separate private keys to 2343 digitally sign certificates and CRLs. When separate private keys are 2344 employed, each of the public keys associated with these private keys 2345 is placed in a separate certificate, one with the keyCertSign bit set 2346 in the key usage extension, and one with the cRLSign bit set in the 2347 key usage extension (section 4.2.1.3). When separate private keys 2348 are employed, certificates issued by the CA contain one authority key 2349 identifier, and the corresponding CRLs contain a different authority 2350 key identifier. The use of separate CA certificates for validation 2351 of certificate signatures and CRL signatures can offer improved 2352 security characteristics; however, it imposes a burden on 2353 applications, and it might limit interoperability. Many applications 2354 construct a certification path, and then validate the certification 2355 path (section 6). CRL checking in turn requires a separate 2356 certification path to be constructed and validated for the CA's CRL 2357 signature validation certificate. Applications that perform CRL 2358 checking MUST support certification path validation when certificates 2359 and CRLs are digitally signed with the same CA private key. These 2360 applications SHOULD support certification path validation when 2361 certificates and CRLs are digitally signed with different CA private 2362 keys. 2364 5.1.2 Certificate List "To Be Signed" 2366 The certificate list to be signed, or TBSCertList, is a SEQUENCE of 2367 required and optional fields. The required fields identify the CRL 2368 issuer, the algorithm used to sign the CRL, the date and time the CRL 2369 was issued, and the date and time by which the CRL issuer will issue 2370 the next CRL. 2372 Optional fields include lists of revoked certificates and CRL 2373 extensions. The revoked certificate list is optional to support the 2374 case where a CA has not revoked any unexpired certificates that it 2375 has issued. The profile requires conforming CRL issuers to use the 2376 CRL Number CRL extension in all CRLs issued. 2378 5.1.2.1 Version 2380 This optional field describes the version of the encoded CRL. When 2381 extensions are used, as required by this profile, this field MUST be 2382 present and MUST specify version 2 (the integer value is 1). 2384 5.1.2.2 Signature 2386 This field contains the algorithm identifier for the algorithm used 2387 to sign the CRL. [PKIXALGS] lists OIDs for the most popular 2388 signature algorithms used in the Internet PKI. 2390 This field MUST contain the same algorithm identifier as the 2391 signatureAlgorithm field in the sequence CertificateList (section 2392 5.1.1.2). 2394 5.1.2.3 Issuer Name 2396 The issuer name identifies the entity who has signed and issued the 2397 CRL. The issuer identity is carried in the issuer name field. 2398 Alternative name forms may also appear in the issuerAltName extension 2399 (section 5.2.2). The issuer name field MUST contain an X.500 2400 distinguished name (DN). The issuer name field is defined as the 2401 X.501 type Name, and MUST follow the encoding rules for the issuer 2402 name field in the certificate (section 4.1.2.4). 2404 5.1.2.4 This Update 2406 This field indicates the issue date of this CRL. ThisUpdate may be 2407 encoded as UTCTime or GeneralizedTime. 2409 CRL issuers conforming to this profile MUST encode thisUpdate as 2410 UTCTime for dates through the year 2049. CRL issuers conforming to 2411 this profile MUST encode thisUpdate as GeneralizedTime for dates in 2412 the year 2050 or later. 2414 Where encoded as UTCTime, thisUpdate MUST be specified and 2415 interpreted as defined in section 4.1.2.5.1. Where encoded as 2416 GeneralizedTime, thisUpdate MUST be specified and interpreted as 2417 defined in section 4.1.2.5.2. 2419 5.1.2.5 Next Update 2421 This field indicates the date by which the next CRL will be issued. 2422 The next CRL could be issued before the indicated date, but it will 2423 not be issued any later than the indicated date. CRL issuers SHOULD 2424 issue CRLs with a nextUpdate time equal to or later than all previous 2425 CRLs. nextUpdate may be encoded as UTCTime or GeneralizedTime. 2427 This profile requires inclusion of nextUpdate in all CRLs issued by 2428 conforming CRL issuers. Note that the ASN.1 syntax of TBSCertList 2429 describes this field as OPTIONAL, which is consistent with the ASN.1 2430 structure defined in [X.509]. The behavior of clients processing CRLs 2431 which omit nextUpdate is not specified by this profile. 2433 CRL issuers conforming to this profile MUST encode nextUpdate as 2434 UTCTime for dates through the year 2049. CRL issuers conforming to 2435 this profile MUST encode nextUpdate as GeneralizedTime for dates in 2436 the year 2050 or later. 2438 Where encoded as UTCTime, nextUpdate MUST be specified and 2439 interpreted as defined in section 4.1.2.5.1. Where encoded as 2440 GeneralizedTime, nextUpdate MUST be specified and interpreted as 2441 defined in section 4.1.2.5.2. 2443 5.1.2.6 Revoked Certificates 2445 When there are no revoked certificates, the revoked certificates list 2446 is absent. Otherwise, revoked certificates are listed by their 2447 serial numbers. Certificates revoked by the CA are uniquely 2448 identified by the certificate serial number. The date on which the 2449 revocation occurred is specified. The time for revocationDate MUST 2450 be expressed as described in section 5.1.2.4. Additional information 2451 may be supplied in CRL entry extensions; CRL entry extensions are 2452 discussed in section 5.3. 2454 5.1.2.7 Extensions 2456 This field may only appear if the version is 2 (section 5.1.2.1). If 2457 present, this field is a SEQUENCE of one or more CRL extensions. CRL 2458 extensions are discussed in section 5.2. 2460 5.2 CRL Extensions 2462 The extensions defined by ANSI X9 and ISO/IEC/ITU for X.509 v2 CRLs 2463 [X.509] [X9.55] provide methods for associating additional attributes 2464 with CRLs. The X.509 v2 CRL format also allows communities to define 2465 private extensions to carry information unique to those communities. 2466 Each extension in a CRL may be designated as critical or non- 2467 critical. A CRL validation MUST fail if it encounters a critical 2468 extension which it does not know how to process. However, an 2469 unrecognized non-critical extension may be ignored. The following 2470 subsections present those extensions used within Internet CRLs. 2471 Communities MAY elect to include extensions in CRLs which are not 2472 defined in this specification. However, caution SHOULD be exercised 2473 in adopting any critical extensions in CRLs which might be used in a 2474 general context. 2476 Conforming CRL issuers are required to include the authority key 2477 identifier (section 5.2.1) and the CRL number (section 5.2.3) 2478 extensions in all CRLs issued. 2480 5.2.1 Authority Key Identifier 2482 The authority key identifier extension provides a means of 2483 identifying the public key corresponding to the private key used to 2484 sign a CRL. The identification can be based on either the key 2485 identifier (the subject key identifier in the CRL signer's 2486 certificate) or on the issuer name and serial number. This extension 2487 is especially useful where an issuer has more than one signing key, 2488 either due to multiple concurrent key pairs or due to changeover. 2490 Conforming CRL issuers MUST use the key identifier method, and MUST 2491 include this extension in all CRLs issued. 2493 The syntax for this CRL extension is defined in section 4.2.1.1. 2495 5.2.2 Issuer Alternative Name 2497 The issuer alternative names extension allows additional identities 2498 to be associated with the issuer of the CRL. Defined options include 2499 an rfc822 name (electronic mail address), a DNS name, an IP address, 2500 and a URI. Multiple instances of a name and multiple name forms may 2501 be included. Whenever such identities are used, the issuer 2502 alternative name extension MUST be used; however, a DNS name MAY be 2503 represented in the issuer field using the domainComponent attribute 2504 as described in section 4.1.2.4. 2506 The issuerAltName extension SHOULD NOT be marked critical. 2508 The OID and syntax for this CRL extension are defined in section 2509 4.2.1.8. 2511 5.2.3 CRL Number 2513 The CRL number is a non-critical CRL extension which conveys a 2514 monotonically increasing sequence number for a given CRL scope and 2515 CRL issuer. This extension allows users to easily determine when a 2516 particular CRL supersedes another CRL. CRL numbers also support the 2517 identification of complementary complete CRLs and delta CRLs. CRL 2518 issuers conforming to this profile MUST include this extension in all 2519 CRLs. 2521 If a CRL issuer generates delta CRLs in addition to complete CRLs for 2522 a given scope, the complete CRLs and delta CRLs MUST share one 2523 numbering sequence. If a delta CRL and a complete CRL that cover the 2524 same scope are issued at the same time, they MUST have the same CRL 2525 number and provide the same revocation information. That is, the 2526 combination of the delta CRL and an acceptable complete CRL MUST 2527 provide the same revocation information as the simultaneously issued 2528 complete CRL. 2530 If a CRL issuer generates two CRLs (two complete CRLs, two delta 2531 CRLs, or a complete CRL and a delta CRL) for the same scope at 2532 different times, the two CRLs MUST NOT have the same CRL number. 2533 That is, if the this update field (section 5.1.2.4) in the two CRLs 2534 are not identical, the CRL numbers MUST be different. 2536 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 2538 CRLNumber ::= INTEGER (0..MAX) 2540 5.2.4 Delta CRL Indicator 2542 The delta CRL indicator is a critical CRL extension that identifies a 2543 CRL as being a delta CRL. Delta CRLs contain updates to revocation 2544 information previously distributed, rather than all the information 2545 that would appear in a complete CRL. The use of delta CRLs can 2546 significantly reduce network load and processing time in some 2547 environments. Delta CRLs are generally smaller than the CRLs they 2548 update, so applications that obtain delta CRLs consume less network 2549 bandwidth than applications that obtain the corresponding complete 2550 CRLs. Applications which store revocation information in a format 2551 other than the CRL structure can add new revocation information to 2552 the local database without reprocessing information. 2554 The delta CRL indicator extension contains the single value of type 2555 BaseCRLNumber. The CRL number identifies the CRL, complete for a 2556 given scope, that was used as the starting point in the generation of 2557 this delta CRL. A conforming CRL issuer MUST publish the referenced 2558 base CRL as a complete CRL. The delta CRL contains all updates to 2559 the revocation status for that same scope. The combination of a 2560 delta CRL plus the referenced base CRL is equivalent to a complete 2561 CRL, for the applicable scope, at the time of publication of the 2562 delta CRL. 2564 When a conforming CRL issuer generates a delta CRL, the delta CRL 2565 MUST include a critical delta CRL indicator extension. 2567 When a delta CRL is issued, it MUST cover the same set of reasons and 2568 the same set of certificates that were covered by the base CRL it 2569 references. That is, the scope of the delta CRL MUST be the same as 2570 the scope of the complete CRL referenced as the base. The referenced 2571 base CRL and the delta CRL MUST omit the issuing distribution point 2572 extension or contain identical issuing distribution point extensions. 2573 Further, the CRL issuer MUST use the same private key to sign the 2574 delta CRL and any complete CRL that it can be used to update. 2576 An application that supports delta CRLs can construct a CRL that is 2577 complete for a given scope by combining a delta CRL for that scope 2578 with either an issued CRL that is complete for that scope or a 2579 locally constructed CRL that is complete for that scope. 2581 When a delta CRL is combined with a complete CRL or a locally 2582 constructed CRL, the resulting locally constructed CRL has the CRL 2583 number specified in the CRL number extension found in the delta CRL 2584 used in its construction. In addition, the resulting locally 2585 constructed CRL has the thisUpdate and nextUpdate times specified in 2586 the corresponding fields of the delta CRL used in its construction. 2587 In addition, the locally constructed CRL inherits the issuing 2588 distribution point from the delta CRL. 2590 A complete CRL and a delta CRL MAY be combined if the following four 2591 conditions are satisfied: 2593 (a) The complete CRL and delta CRL have the same issuer. 2595 (b) The complete CRL and delta CRL have the same scope. The two 2596 CRLs have the same scope if either of the following conditions are 2597 met: 2599 (1) The issuingDistributionPoint extension is omitted from 2600 both the complete CRL and the delta CRL. 2602 (2) The issuingDistributionPoint extension is present in both 2603 the complete CRL and the delta CRL, and the values for each of 2604 the fields in the extensions are the same in both CRLs. 2606 (c) The CRL number of the complete CRL is equal to or greater 2607 than the BaseCRLNumber specified in the delta CRL. That is, the 2608 complete CRL contains (at a minimum) all the revocation 2609 information held by the referenced base CRL. 2611 (d) The CRL number of the complete CRL is less than the CRL 2612 number of the delta CRL. That is, the delta CRL follows the 2613 complete CRL in the numbering sequence. 2615 CRL issuers MUST ensure that the combination of a delta CRL and any 2616 appropriate complete CRL accurately reflects the current revocation 2617 status. The CRL issuer MUST include an entry in the delta CRL for 2618 each certificate within the scope of the delta CRL whose status has 2619 changed since the generation of the referenced base CRL: 2621 (a) If the certificate is revoked for a reason included in the 2622 scope of the CRL, list the certificate as revoked. 2624 (b) If the certificate is valid and was listed on the referenced 2625 base CRL or any subsequent CRL with reason code certificateHold, 2626 and the reason code certificateHold is included in the scope of 2627 the CRL, list the certificate with the reason code removeFromCRL. 2629 (c) If the certificate is revoked for a reason outside the scope 2630 of the CRL, but the certificate was listed on the referenced base 2631 CRL or any subsequent CRL with a reason code included in the scope 2632 of this CRL, list the certificate as revoked but omit the reason 2633 code. 2635 (d) If the certificate is revoked for a reason outside the scope 2636 of the CRL and the certificate was neither listed on the 2637 referenced base CRL nor any subsequent CRL with a reason code 2638 included in the scope of this CRL, do not list the certificate on 2639 this CRL. 2641 The status of a certificate is considered to have changed if it is 2642 revoked, placed on hold, released from hold, or if its revocation 2643 reason changes. 2645 It is appropriate to list a certificate with reason code 2646 removeFromCRL on a delta CRL even if the certificate was not on hold 2647 in the referenced base CRL. If the certificate was placed on hold in 2648 any CRL issued after the base but before this delta CRL and then 2649 released from hold, it MUST be listed on the delta CRL with 2650 revocation reason removeFromCRL. 2652 A CRL issuer MAY optionally list a certificate on a delta CRL with 2653 reason code removeFromCRL if the notAfter time specified in the 2654 certificate precedes the thisUpdate time specified in the delta CRL 2655 and the certificate was listed on the referenced base CRL or in any 2656 CRL issued after the base but before this delta CRL. 2658 If a certificate revocation notice first appears on a delta CRL, then 2659 it is possible for the certificate validity period to expire before 2660 the next complete CRL for the same scope is issued. In this case, 2661 the revocation notice MUST be included in all subsequent delta CRLs 2662 until the revocation notice is included on at least one explicitly 2663 issued complete CRL for this scope. 2665 An application that supports delta CRLs MUST be able to construct a 2666 current complete CRL by combining a previously issued complete CRL 2667 and the most current delta CRL. An application that supports delta 2668 CRLs MAY also be able to construct a current complete CRL by 2669 combining a previously locally constructed complete CRL and the 2670 current delta CRL. A delta CRL is considered to be the current one 2671 if the current time is between the times contained in the thisUpdate 2672 and nextUpdate fields. Under some circumstances, the CRL issuer may 2673 publish one or more delta CRLs before indicated by the nextUpdate 2674 field. If more than one current delta CRL for a given scope is 2675 encountered, the application SHOULD consider the one with the latest 2676 value in thisUpdate to be the most current one. 2678 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 2680 BaseCRLNumber ::= CRLNumber 2682 5.2.5 Issuing Distribution Point 2684 The issuing distribution point is a critical CRL extension that 2685 identifies the CRL distribution point and scope for a particular CRL, 2686 and it indicates whether the CRL covers revocation for end entity 2687 certificates only, CA certificates only, attribute certificates 2688 only, or a limited set of reason codes. Although the extension is 2689 critical, conforming implementations are not required to support this 2690 extension. 2692 The CRL is signed using the CRL issuer's private key. CRL 2693 Distribution Points do not have their own key pairs. If the CRL is 2694 stored in the X.500 Directory, it is stored in the Directory entry 2695 corresponding to the CRL distribution point, which may be different 2696 than the Directory entry of the CRL issuer. 2698 The reason codes associated with a distribution point MUST be 2699 specified in onlySomeReasons. If onlySomeReasons does not appear, 2700 the distribution point MUST contain revocations for all reason codes. 2701 CAs may use CRL distribution points to partition the CRL on the basis 2702 of compromise and routine revocation. In this case, the revocations 2703 with reason code keyCompromise (1), cACompromise (2), and 2704 aACompromise (8) appear in one distribution point, and the 2705 revocations with other reason codes appear in another distribution 2706 point. 2708 If the distributionPoint field is present and contains a URI, the 2709 following semantics MUST be assumed: the object is a pointer to the 2710 most current CRL issued by this CRL issuer. The URI schemes ftp, 2711 http, mailto [RFC1738] and ldap [RFC1778] are defined for this 2712 purpose. The URI MUST be an absolute pathname, not a relative 2713 pathname, and MUST specify the host. 2715 If the distributionPoint field is absent, the CRL MUST contain 2716 entries for all revoked unexpired certificates issued by the CRL 2717 issuer, if any, within the scope of the CRL. 2719 The CRL issuer MUST assert the indirectCRL boolean, if the scope of 2720 the CRL includes certificates issued by authorities other than the 2721 CRL issuer. The authority responsible for each entry is indicated by 2722 the certificate issuer CRL entry extension (section 5.3.4). 2724 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 2726 issuingDistributionPoint ::= SEQUENCE { 2727 distributionPoint [0] DistributionPointName OPTIONAL, 2728 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 2729 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 2730 onlySomeReasons [3] ReasonFlags OPTIONAL, 2731 indirectCRL [4] BOOLEAN DEFAULT FALSE, 2732 onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE } 2734 5.2.6 Freshest CRL (a.k.a. Delta CRL Distribution Point) 2736 The freshest CRL extension identifies how delta CRL information for 2737 this complete CRL is obtained. The extension MUST be non-critical. 2738 This extension MUST NOT appear in delta CRLs. 2740 The same syntax is used for this extension as the 2741 cRLDistributionPoints certificate extension, and is described in 2742 section 4.2.1.14. However, only the distribution point field is 2743 meaningful in this context. The reasons and CRLIssuer fields MUST be 2744 omitted from this CRL extension. 2746 Each distribution point name provides the location at which a delta 2747 CRL for this complete CRL can be found. The scope of these delta 2748 CRLs MUST be the same as the scope of this complete CRL. The 2749 contents of this CRL extension are only used to locate delta CRLs; 2750 the contents are not used to validate the CRL or the referenced delta 2751 CRLs. The encoding conventions defined for distribution points in 2752 section 4.2.1.14 apply to this extension. 2754 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } 2756 FreshestCRL ::= CRLDistributionPoints 2758 5.3 CRL Entry Extensions 2760 The CRL entry extensions already defined by ANSI X9 and ISO/IEC/ITU 2761 for X.509 v2 CRLs provide methods for associating additional 2762 attributes with CRL entries [X.509] [X9.55]. The X.509 v2 CRL format 2763 also allows communities to define private CRL entry extensions to 2764 carry information unique to those communities. Each extension in a 2765 CRL entry may be designated as critical or non-critical. A CRL 2766 validation MUST fail if it encounters a critical CRL entry extension 2767 which it does not know how to process. However, an unrecognized non- 2768 critical CRL entry extension may be ignored. The following 2769 subsections present recommended extensions used within Internet CRL 2770 entries and standard locations for information. Communities MAY 2771 elect to use additional CRL entry extensions; however, caution SHOULD 2772 be exercised in adopting any critical extensions in CRL entries which 2773 might be used in a general context. 2775 All CRL entry extensions used in this specification are non-critical. 2776 Support for these extensions is optional for conforming CRL issuers 2777 and applications. However, CRL issuers SHOULD include reason codes 2778 (section 5.3.1) and invalidity dates (section 5.3.3) whenever this 2779 information is available. 2781 5.3.1 Reason Code 2783 The reasonCode is a non-critical CRL entry extension that identifies 2784 the reason for the certificate revocation. CRL issuers are strongly 2785 encouraged to include meaningful reason codes in CRL entries; 2786 however, the reason code CRL entry extension SHOULD be absent instead 2787 of using the unspecified (0) reasonCode value. 2789 id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 } 2791 -- reasonCode ::= { CRLReason } 2793 CRLReason ::= ENUMERATED { 2794 unspecified (0), 2795 keyCompromise (1), 2796 cACompromise (2), 2797 affiliationChanged (3), 2798 superseded (4), 2799 cessationOfOperation (5), 2800 certificateHold (6), 2801 removeFromCRL (8), 2802 privilegeWithdrawn (9), 2803 aACompromise (10) } 2805 5.3.2 Hold Instruction Code 2807 The hold instruction code is a non-critical CRL entry extension that 2808 provides a registered instruction identifier which indicates the 2809 action to be taken after encountering a certificate that has been 2810 placed on hold. 2812 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 2814 holdInstructionCode ::= OBJECT IDENTIFIER 2816 The following instruction codes have been defined. Conforming 2817 applications that process this extension MUST recognize the following 2818 instruction codes. 2820 holdInstruction OBJECT IDENTIFIER ::= 2821 { iso(1) member-body(2) us(840) x9-57(10040) 2 } 2823 id-holdinstruction-none OBJECT IDENTIFIER ::= {holdInstruction 1} 2824 id-holdinstruction-callissuer 2825 OBJECT IDENTIFIER ::= {holdInstruction 2} 2826 id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3} 2828 Conforming applications which encounter an id-holdinstruction- 2829 callissuer MUST call the certificate issuer or reject the 2830 certificate. Conforming applications which encounter an id- 2831 holdinstruction-reject MUST reject the certificate. The hold 2832 instruction id-holdinstruction-none is semantically equivalent to the 2833 absence of a holdInstructionCode, and its use is strongly deprecated 2834 for the Internet PKI. 2836 5.3.3 Invalidity Date 2838 The invalidity date is a non-critical CRL entry extension that 2839 provides the date on which it is known or suspected that the private 2840 key was compromised or that the certificate otherwise became invalid. 2841 This date may be earlier than the revocation date in the CRL entry, 2842 which is the date at which the CA processed the revocation. When a 2843 revocation is first posted by a CRL issuer in a CRL, the invalidity 2844 date may precede the date of issue of earlier CRLs, but the 2845 revocation date SHOULD NOT precede the date of issue of earlier CRLs. 2846 Whenever this information is available, CRL issuers are strongly 2847 encouraged to share it with CRL users. 2849 The GeneralizedTime values included in this field MUST be expressed 2850 in Greenwich Mean Time (Zulu), and MUST be specified and interpreted 2851 as defined in section 4.1.2.5.2. 2853 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 2855 invalidityDate ::= GeneralizedTime 2857 5.3.4 Certificate Issuer 2859 This CRL entry extension identifies the certificate issuer associated 2860 with an entry in an indirect CRL, that is, a CRL that has the 2861 indirectCRL indicator set in its issuing distribution point 2862 extension. If this extension is not present on the first entry in an 2863 indirect CRL, the certificate issuer defaults to the CRL issuer. On 2864 subsequent entries in an indirect CRL, if this extension is not 2865 present, the certificate issuer for the entry is the same as that for 2866 the preceding entry. This field is defined as follows: 2868 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } 2870 certificateIssuer ::= GeneralNames 2872 If used by conforming CRL issuers, this extension MUST always be 2873 critical. If an implementation ignored this extension it could not 2874 correctly attribute CRL entries to certificates. This specification 2875 RECOMMENDS that implementations recognize this extension. 2877 6 Certification Path Validation 2879 Certification path validation procedures for the Internet PKI are 2880 based on the algorithm supplied in [X.509]. Certification path 2881 processing verifies the binding between the subject distinguished 2882 name and/or subject alternative name and subject public key. The 2883 binding is limited by constraints which are specified in the 2884 certificates which comprise the path and inputs which are specified 2885 by the relying party. The basic constraints and policy constraints 2886 extensions allow the certification path processing logic to automate 2887 the decision making process. 2889 This section describes an algorithm for validating certification 2890 paths. Conforming implementations of this specification are not 2891 required to implement this algorithm, but MUST provide functionality 2892 equivalent to the external behavior resulting from this procedure. 2893 Any algorithm may be used by a particular implementation so long as 2894 it derives the correct result. 2896 In section 6.1, the text describes basic path validation. Valid 2897 paths begin with certificates issued by a "most-trusted CA". The 2898 algorithm requires the public key of the CA, the CA's name, and any 2899 constraints upon the set of paths which may be validated using this 2900 key. 2902 The selection of a "most-trusted CA" is a matter of policy: it could 2903 be the top CA in a hierarchical PKI; the CA that issued the 2904 verifier's own certificate(s); or any other CA in a network PKI. The 2905 path validation procedure is the same regardless of the choice of 2906 "most-trusted CA." In addition, different applications may rely on 2907 different "most-trusted CA", or may accept paths that begin with any 2908 of a set of "most-trusted CAs." 2910 Section 6.2 describes methods for using the path validation algorithm 2911 in specific implementations. Two specific cases are discussed: the 2912 case where paths may begin with one of several trusted CAs; and where 2913 compatibility with the PEM architecture is required. 2915 Section 6.3 describes the steps necessary to determine if a 2916 certificate is revoked or on hold status when CRLs are the revocation 2917 mechanism used by the certificate issuer. 2919 6.1 Basic Path Validation 2921 This text describes an algorithm for X.509 path processing. A 2922 conformant implementation MUST include an X.509 path processing 2923 procedure that is functionally equivalent to the external behavior of 2924 this algorithm. However, support for some of the certificate 2925 extensions processed in this algorithm are OPTIONAL for compliant 2926 implementations. Clients that do not support these extensions MAY 2927 omit the corresponding steps in the path validation algorithm. 2929 For example, clients are NOT REQUIRED to support the policy mapping 2930 extension. Clients that do not support this extension MAY omit the 2931 path validation steps where policy mappings are processed. Note that 2932 clients MUST reject the certificate if it contains an unsupported 2933 critical extension. 2935 The algorithm presented in this section validates the certificate 2936 with respect to the current date and time. A conformant 2937 implementation MAY also support validation with respect to some point 2938 in the past. Note that mechanisms are not available for validating a 2939 certificate with respect to a time outside the certificate validity 2940 period. 2942 The trust anchor is an input to the algorithm. There is no 2943 requirement that the same trust anchor be used to validate all 2944 certification paths. Different trust anchors MAY be used to validate 2945 different paths, as discussed further in Section 6.2. 2947 The primary goal of path validation is to verify the binding between 2948 a subject distinguished name or a subject alternative name and 2949 subject public key, as represented in the end entity certificate, 2950 based on the public key of the trust anchor. This requires obtaining 2951 a sequence of certificates that support that binding. The procedure 2952 performed to obtain this sequence of certificates is outside the 2953 scope of this specification. 2955 To meet this goal, the path validation process verifies, among other 2956 things, that a prospective certification path (a sequence of n 2957 certificates) satisfies the following conditions: 2959 (a) for all x in {1, ..., n-1}, the subject of certificate x is 2960 the issuer of certificate x+1; 2962 (b) certificate 1 is issued by the trust anchor; 2964 (c) certificate n is the certificate to be validated; and 2966 (d) for all x in {1, ..., n}, the certificate was valid at the 2967 time in question. 2969 When the trust anchor is provided in the form of a self-signed 2970 certificate, this self-signed certificate is not included as part of 2971 the prospective certification path. Information about trust anchors 2972 are provided as inputs to the certification path validation algorithm 2973 (section 6.1.1). 2975 A particular certification path may not, however, be appropriate for 2976 all applications. Therefore, an application MAY augment this 2977 algorithm to further limit the set of valid paths. The path 2978 validation process also determines the set of certificate policies 2979 that are valid for this path, based on the certificate policies 2980 extension, policy mapping extension, policy constraints extension, 2981 and inhibit any-policy extension. To achieve this, the path 2982 validation algorithm constructs a valid policy tree. If the set of 2983 certificate policies that are valid for this path is not empty, then 2984 the result will be a valid policy tree of depth n, otherwise the 2985 result will be a null valid policy tree. 2987 A certificate is self-issued if the DNs that appear in the subject 2988 and issuer fields are identical and are not empty. In general, the 2989 issuer and subject of the certificates that make up a path are 2990 different for each certificate. However, a CA may issue a 2991 certificate to itself to support key rollover or changes in 2992 certificate policies. These self-issued certificates are not counted 2993 when evaluating path length or name constraints. 2995 This section presents the algorithm in four basic steps: (1) 2996 initialization, (2) basic certificate processing, (3) preparation for 2997 the next certificate, and (4) wrap-up. Steps (1) and (4) are 2998 performed exactly once. Step (2) is performed for all certificates 2999 in the path. Step (3) is performed for all certificates in the path 3000 except the final certificate. Figure 2 provides a high-level 3001 flowchart of this algorithm. 3003 +-------+ 3004 | START | 3005 +-------+ 3006 | 3007 V 3008 +----------------+ 3009 | Initialization | 3010 +----------------+ 3011 | 3012 +<--------------------+ 3013 | | 3014 V | 3015 +----------------+ | 3016 | Process Cert | | 3017 +----------------+ | 3018 | | 3019 V | 3020 +================+ | 3021 | IF Last Cert | | 3022 | in Path | | 3023 +================+ | 3024 | | | 3025 THEN | | ELSE | 3026 V V | 3027 +----------------+ +----------------+ | 3028 | Wrap up | | Prepare for | | 3029 +----------------+ | Next Cert | | 3030 | +----------------+ | 3031 V | | 3032 +-------+ +--------------+ 3033 | STOP | 3034 +-------+ 3036 Figure 2. Certification Path Processing Flowchart 3038 6.1.1 Inputs 3040 This algorithm assumes the following seven inputs are provided to the 3041 path processing logic: 3043 (a) a prospective certification path of length n. 3045 (b) the current date/time. 3047 (c) user-initial-policy-set: A set of certificate policy 3048 identifiers naming the policies that are acceptable to the 3049 certificate user. The user-initial-policy-set contains the special 3050 value any-policy if the user is not concerned about certificate 3051 policy. 3053 (d) trust anchor information, describing a CA that serves as a 3054 trust anchor for the certification path. The trust anchor 3055 information includes: 3057 (1) the trusted issuer name, 3059 (2) the trusted public key algorithm, 3061 (3) the trusted public key, and 3063 (4) optionally, the trusted public key parameters associated 3064 with the public key. 3066 The trust anchor information may be provided to the path 3067 processing procedure in the form of a self-signed certificate. 3068 The trusted anchor information is trusted because it was delivered 3069 to the path processing procedure by some trustworthy out-of-band 3070 procedure. If the trusted public key algorithm requires 3071 parameters, then the parameters are provided along with the 3072 trusted public key. 3074 (e) initial-policy-mapping-inhibit, which indicates if policy 3075 mapping is allowed in the certification path. 3077 (f) initial-explicit-policy, which indicates if the path must be 3078 valid for at least one of the certificate policies in the user- 3079 initial-policy-set. 3081 (g) initial-any-policy-inhibit, which indicates whether the 3082 anyPolicy OID should be processed if it is included in a 3083 certificate. 3085 6.1.2 Initialization 3087 The initialization phase establishes eleven state variables based 3088 upon the seven inputs: 3090 (a) valid_policy_tree: A tree of certificate policies with their 3091 optional qualifiers; each of the leaves of the tree represents a 3092 valid policy at this stage in the certification path validation. 3093 If valid policies exist at this stage in the certification path 3094 validation, the depth of the tree is equal to the number of 3095 certificates in the chain that have been processed. If valid 3096 policies do not exist at this stage in the certification path 3097 validation, the tree is set to NULL. Once the tree is set to NULL, 3098 policy processing ceases. 3100 Each node in the valid_policy_tree includes four data objects: the 3101 valid policy, a set of associated policy qualifiers, a set of one 3102 or more expected policy values, and a criticality indicator. If 3103 the node is at depth x, the components of the node have the 3104 following semantics: 3106 (1) The valid_policy is a single policy OID representing a 3107 valid policy for the path of length x. 3109 (2) The qualifier_set is a set of policy qualifiers associated 3110 with the valid policy in certificate x. 3112 (3) The criticality_indicator indicates whether the 3113 certificate policy extension in certificate x was marked as 3114 critical. 3116 (4) The expected_policy_set contains one or more policy OIDs 3117 that would satisfy this policy in the certificate x+1. 3119 The initial value of the valid_policy_tree is a single node with 3120 valid_policy any-policy, an empty qualifier_set, an 3121 expected_policy_set with the single value any-policy, and a 3122 criticality_indicator of FALSE. This node is considered to be at 3123 depth zero. 3125 Figure 3 is a graphic representation of the initial state of the 3126 valid_policy_tree. Additional figures will use this format to 3127 describe changes in the valid_policy_tree during path processing. 3129 +----------------+ 3130 | any-policy | <---- valid_policy 3131 +----------------+ 3132 | {} | <---- qualifier_set 3133 +----------------+ 3134 | FALSE | <---- criticality_indicator 3135 +----------------+ 3136 | {any-policy} | <---- expected_policy_set 3137 +----------------+ 3139 Figure 3. Initial value of the valid_policy_tree state variable 3141 (b) permitted_subtrees: A set of root names for each name type 3142 (e.g., X.500 distinguished names, email addresses, or ip 3143 addresses) defining a set of subtrees within which all subject 3144 names in subsequent certificates in the certification path MUST 3145 fall. This variable includes a set for each name type: the 3146 initial value for the set for Distinguished Names is the set of 3147 all Distinguished names; the initial value for the set of RFC822 3148 names is the set of all RFC822 names, etc. 3150 (c) excluded_subtrees: A set of root names for each name type 3151 (e.g., X.500 distinguished names, email addresses, or ip 3152 addresses) defining a set of subtrees within which no subject name 3153 in subsequent certificates in the certification path may fall. 3154 This variable includes a set for each name type, and the initial 3155 value for each set is empty. 3157 (d) explicit_policy: an integer which indicates if a non-NULL 3158 valid_policy_tree is required. The integer indicates the number of 3159 non-self-issued certificates to be processed before this 3160 requirement is imposed. Once set, this variable may be decreased, 3161 but may not be increased. That is, if a certificate in the path 3162 requires a non-NULL valid_policy_tree, a later certificate can not 3163 remove this requirement. If initial-explicit-policy is set, then 3164 the initial value is 0, otherwise the initial value is n+1. 3166 (e) inhibit_any-policy: an integer which indicates whether the 3167 any-policy policy identifier is considered a match. The integer 3168 indicates the number of non-self-issued certificates to be 3169 processed before the any-policy OID, if asserted in a certificate, 3170 is ignored. Once set, this variable may be decreased, but may not 3171 be increased. That is, if a certificate in the path inhibits 3172 processing of any-policy, a later certificate can not permit it. 3173 If initial-any-policy-inhibit is set, then the initial value is 0, 3174 otherwise the initial value is n+1. 3176 (f) policy_mapping: an integer which indicates if policy mapping 3177 is permitted. The integer indicates the number of non-self-issued 3178 certificates to be processed before policy mapping is inhibited. 3180 Once set, this variable may be decreased, but may not be 3181 increased. That is, if a certificate in the path specifies policy 3182 mapping is not permitted, it can not be overridden by a later 3183 certificate. If initial-policy-mapping-inhibit is set, then the 3184 initial value is 0, otherwise the initial value is n+1. 3186 (g) working_public_key_algorithm: the digital signature algorithm 3187 used to verify the signature of a certificate. The 3188 working_public_key_algorithm is initialized from the trusted 3189 public key algorithm provided in the trust anchor information. 3191 (h) working_public_key: the public key used to verify the 3192 signature of a certificate. The working_public_key is initialized 3193 from the trusted public key provided in the trust anchor 3194 information. 3196 (i) working_public_key_parameters: parameters associated with the 3197 current public key, that may be required to verify a signature 3198 (depending upon the algorithm). The working_public_key_parameters 3199 variable is initialized from the trusted public key parameters 3200 provided in the trust anchor information. 3202 (j) working_issuer_name: the issuer distinguished name expected 3203 in the next certificate in the chain. The working_issuer_name is 3204 initialized to the trusted issuer provided in the trust anchor 3205 information. 3207 (k) max_path_length: this integer is initialized to n, is 3208 decremented for each non-self-issued certificate in the path, and 3209 may be reduced to the value in the path length constraint field 3210 within the basic constraints extension of a CA certificate. 3212 Upon completion of the initialization steps, perform the basic 3213 certificate processing steps specified in 6.1.3. 3215 6.1.3 Basic Certificate Processing 3217 The basic path processing actions to be performed for certificate i 3218 (for all i in [1..n]) are listed below. 3220 (a) Verify the basic certificate information. The certificate 3221 MUST satisfy each of the following: 3223 (1) The certificate was signed with the 3224 working_public_key_algorithm using the working_public_key and 3225 the working_public_key_parameters. 3227 (2) The certificate validity period includes the current time. 3229 (3) At the current time, the certificate is not revoked and is 3230 not on hold status. This may be determined by obtaining the 3231 appropriate CRL (section 6.3), status information, or by out- 3232 of-band mechanisms. 3234 (4) The certificate issuer name is the working_issuer_name. 3236 (b) If certificate i is self-issued and it is not the final 3237 certificate in the path, skip this step for certificate i. 3238 Otherwise, verify that the subject name is within one of the 3239 permitted_subtrees for X.500 distinguished names, and verify that 3240 each of the alternative names in the subjectAltName extension 3241 (critical or non-critical) is within one of the permitted_subtrees 3242 for that name type. 3244 (c) If certificate i is self-issued and it is not the final 3245 certificate in the path, skip this step for certificate i. 3246 Otherwise, verify that the subject name is not within one of the 3247 excluded_subtrees for X.500 distinguished names, and verify that 3248 each of the alternative names in the subjectAltName extension 3249 (critical or non-critical) is not within one of the 3250 excluded_subtrees for that name type. 3252 (d) If the certificate policies extension is present in the 3253 certificiate and the valid_policy_tree is not NULL, process the 3254 policy information by performing the following steps in order: 3256 (1) For each policy P not equal to any-policy in the 3257 certificate policies extension, let P-OID denote the OID in 3258 policy P and P-Q denote the qualifier set for policy P. 3259 Perform the following steps in order: 3261 (i) If the valid_policy_tree includes a node of depth i-1 3262 where P-OID is in the expected_policy_set, create a child 3263 node as follows: set the valid_policy to OID-P; set the 3264 qualifier_set to P-Q, and set the expected_policy_set to {P- 3265 OID}. 3267 For example, consider a valid_policy_tree with a node of 3268 depth i-1 where the expected_policy_set is {Gold, White}. 3269 Assume the certificate policies Gold and Silver appear in 3270 the certificate policies extension of certificate i. The 3271 Gold policy is matched but the Silver policy is not. This 3272 rule will generate a child node of depth i for the Gold 3273 policy. The result is shown as Figure 4. 3275 |-----------------| 3276 | Red | 3277 |-----------------| 3278 | {} | 3279 |-----------------| node of depth i-1 3280 | FALSE | 3281 |-----------------| 3282 | {Gold, White} | 3283 |-----------------| 3284 | 3285 | 3286 | 3287 V 3288 |-----------------| 3289 | Gold | 3290 |-----------------| 3291 | {} | 3292 |-----------------| node of depth i 3293 | uninitialized | 3294 |-----------------| 3295 | {Gold} | 3296 |-----------------| 3298 Figure 4. Processing an exact match 3300 (ii) If there was no match in step (i) and the 3301 valid_policy_tree includes a node of depth i-1 with the 3302 valid policy any-policy, generate a child node with the 3303 following values: set the valid_policy to P-OID; set the 3304 qualifier_set to P-Q, and set the expected_policy_set to {P- 3305 OID}. 3307 For example, consider a valid_policy_tree with a node of 3308 depth i-1 where the valid_policy is any-policy. Assume the 3309 certificate policies Gold and Silver appear in the 3310 certificate policies extension of certificate i. The Gold 3311 policy does not have a qualifier, but the Silver policy has 3312 the qualifier Q-Silver. If Gold and Silver were not matched 3313 in (i) above, this rule will generate two child nodes of 3314 depth i, one for each policy. The result is shown as Figure 3315 5. 3317 |-----------------| 3318 | any-policy | 3319 |-----------------| 3320 | {} | 3321 |-----------------| node of depth i-1 3322 | FALSE | 3323 |-----------------| 3324 | {any-policy} | 3325 |-----------------| 3326 / \ 3327 / \ 3328 / \ 3329 / \ 3330 |-----------------| |-----------------| 3331 | Gold | | Silver | 3332 |-----------------| |-----------------| 3333 | {} | | {Q-Silver} | 3334 |-----------------| nodes of |-----------------| 3335 | uninitialized | depth i | uninitialized | 3336 |-----------------| |-----------------| 3337 | {Gold} | | {Silver} | 3338 |-----------------| |-----------------| 3340 Figure 5. Processing unmatched policies when a leaf node 3341 specifies any-policy 3343 (2) If the certificate policies extension includes the policy 3344 anyPolicy with the qualifier set AP-Q and inhibit_any-policy is 3345 greater than 0, then: 3347 For each node in the valid_policy_tree of depth i-1, for each 3348 value in the expected_policy_set (including any-policy) that 3349 does not appear in a child node, create a child node with the 3350 following values: set the valid_policy to the value from the 3351 expected_policy_set in the parent node; set the qualifier_set 3352 to AP-Q, and set the expected_policy_set to the value in the 3353 valid_policy from this node. 3355 For example, consider a valid_policy_tree with a node of depth 3356 i-1 where the expected_policy_set = {Gold, Silver}. Assume 3357 any-policy appears in the certificate policies extension of 3358 certificate i, but Gold and Silver do not. This rule will 3359 generate two child nodes of depth i, one for each policy. The 3360 result is shown below as Figure 6. 3362 |-----------------| 3363 | Red | 3364 |-----------------| 3365 | {} | 3366 |-----------------| node of depth i-1 3367 | FALSE | 3368 |-----------------| 3369 | {Gold, Silver} | 3370 |-----------------| 3371 / \ 3372 / \ 3373 / \ 3374 / \ 3375 |-----------------| |-----------------| 3376 | Gold | | Silver | 3377 |-----------------| |-----------------| 3378 | {} | | {} | 3379 |-----------------| nodes of |-----------------| 3380 | uninitialized | depth i | uninitialized | 3381 |-----------------| |-----------------| 3382 | {Gold} | | {Silver} | 3383 |-----------------| |-----------------| 3385 Figure 6. Processing unmatched policies when the certificate 3386 policies extension specifies any-policy 3388 (3) If there is a node in the valid_policy_tree of depth i-1 3389 or less without any child nodes, delete that node. Repeat this 3390 step until there are no nodes of depth i-1 or less without 3391 children. 3393 For example, consider the valid_policy_tree shown in Figure 7 3394 below. The two nodes at depth i-1 that are marked with an 'X' 3395 have no children, and are deleted. Applying this rule to the 3396 resulting tree will cause the node at depth i-2 that is marked 3397 with an 'Y' to be deleted. The following application of the 3398 rule does not cause any nodes to be deleted, and this step is 3399 complete. 3401 +-----------+ 3402 | | node of depth i-3 3403 +-----------+ 3404 / | \ 3405 / | \ 3406 / | \ 3407 +-----------+ +-----------+ +-----------+ 3408 | | | | | Y | nodes of 3409 +-----------+ +-----------+ +-----------+ depth i-2 3410 / \ | | 3411 / \ | | 3412 / \ | | 3413 +-----------+ +-----------+ +-----------+ +-----------+ nodes of 3414 | | | X | | | | X | depth 3415 +-----------+ +-----------+ +-----------+ +-----------+ i-1 3416 | / | \ 3417 | / | \ 3418 | / | \ 3419 +-----------+ +-----------+ +-----------+ +-----------+ nodes of 3420 | | | | | | | | depth 3421 +-----------+ +-----------+ +-----------+ +-----------+ i 3423 Figure 7. Pruning the valid_policy_tree 3425 (4) If the certificate policies extension was marked as 3426 critical, set the criticality_indicator in all nodes of depth i 3427 to TRUE. If the certificate policies extension was not marked 3428 critical, set the criticality_indicator in all nodes of depth i 3429 to FALSE. 3431 (e) If the certificate policies extension is not present, set the 3432 valid_policy_tree to NULL. 3434 (f) Verify that either explicit_policy is greater than 0 or the 3435 valid_policy_tree is not equal to NULL; 3437 If any of steps (a), (b), (c), or (f) fails, the procedure 3438 terminates, returning a failure indication and an appropriate reason. 3440 If i is not equal to n, continue by performing the preparatory steps 3441 listed in 6.1.4. If i is equal to n, perform the wrap-up steps 3442 listed in 6.1.5. 3444 6.1.4 Preparation for Certificate i+1 3446 To prepare for processing of certificate i+1, perform the following 3447 steps for certificate i: 3449 (a) If a policy mapping extension is present, verify that the 3450 special value any-policy does not appear as an issuerDomainPolicy 3451 or a subjectDomainPolicy. 3453 (b) If a policy mapping extension is present, then for each 3454 issuerDomainPolicy ID-P in the policy mapping extension: 3456 (1) If the policy_mapping variable is greater than 0, for each 3457 node in the valid_policy_tree of depth i where ID-P is the 3458 valid_policy, set expected_policy_set to the set of 3459 subjectDomainPolicy values that are specified as equivalent to 3460 ID-P by the policy mapping extension. 3462 If no node of depth i in the valid_policy_tree has a 3463 valid_policy of ID-P but there is a node of depth i with a 3464 valid_policy of any-policy, then generate a child node of the 3465 node of depth i-1 that has a valid_policy of any-policy as 3466 follows: 3468 (i) set the valid_policy to ID-P; 3470 (ii) set the qualifier_set to the qualifier set of the 3471 policy any-policy in the certificate policies extension of 3472 certificate i; 3474 (iii) set the criticality_indicator to the criticality of 3475 the certificate policies extension of certificate i; 3477 (iv) and set the expected_policy_set to the set of 3478 subjectDomainPolicy values that are specified as equivalent 3479 to ID-P by the policy mappings extension. 3481 (2) If the policy_mapping variable is equal to 0: 3483 (i) delete each node of depth i in the valid_policy_tree 3484 where ID-P is the valid_policy. 3486 (ii) If there is a node in the valid_policy_tree of depth 3487 i-1 or less without any child nodes, delete that node. 3488 Repeat this step until there are no nodes of depth i-1 or 3489 less without children. 3491 (c) Assign the certificate subject name to working_issuer_name. 3493 (d) Assign the certificate subjectPublicKey to 3494 working_public_key. 3496 (e) If the subjectPublicKeyInfo field of the certificate contains 3497 an algorithm field with non-null parameters, assign the parameters 3498 to the working_public_key_parameters variable. 3500 If the subjectPublicKeyInfo field of the certificate contains an 3501 algorithm field with null parameters or parameters are omitted, 3502 compare the certificate subjectPublicKey algorithm to the 3503 working_public_key_algorithm. If the certificate subjectPublicKey 3504 algorithm and the working_public_key_algorithm are different, set 3505 the working_public_key_parameters to null. 3507 (f) Assign the certificate subjectPublicKey algorithm to the 3508 working_public_key_algorithm variable. 3510 (g) If a name constraints extension is included in the 3511 certificate, modify the permitted_subtrees and excluded_subtrees 3512 state variables as follows: 3514 (1) If permittedSubtrees is present in the certificate, set 3515 the permitted_subtrees state variable to the intersection of 3516 its previous value and the value indicated in the extension 3517 field. If permittedSubtrees does not include a particular name 3518 type, the permitted_subtrees state variable is unchanged for 3519 that name type. For example, the intersection of the name 3520 spaces nist.gov and csrc.nist.gov is csrc.nist.gov. And, the 3521 intersection of nist.gov and rsasecurity.com is the empty set. 3523 (2) If excludedSubtrees is present in the certificate, set the 3524 excluded_subtrees state variable to the union of its previous 3525 value and the value indicated in the extension field. If 3526 excludedSubtrees does not include a particular name type, the 3527 excluded_subtrees state variable is unchanged for that name 3528 type. For example, the union of the name spaces nist.gov and 3529 csrc.nist.gov is nist.gov. And, the union of nist.gov and 3530 rsasecurity.com is both name spaces. 3532 (h) If the issuer and subject names are not identical: 3534 (1) If explicit_policy is not 0, decrement explicit_policy by 3535 1. 3537 (2) If policy_mapping is not 0, decrement policy_mapping by 1. 3539 (3) If inhibit_any-policy is not 0, decrement inhibit_any- 3540 policy by 1. 3542 (i) If a policy constraints extension is included in the 3543 certificate, modify the explicit_policy and policy_mapping state 3544 variables as follows: 3546 (1) If requireExplicitPolicy is present and is less than 3547 explicit_policy, set explicit_policy to the value of 3548 requireExplicitPolicy. 3550 (2) If inhibitPolicyMapping is present and is less than 3551 policy_mapping, set policy_mapping to the value of 3552 inhibitPolicyMapping. 3554 (j) If the inhibitAnyPolicy extension is included in the 3555 certificate and is less than inhibit_any-policy, set inhibit_any- 3556 policy to the value of inhibitAnyPolicy. 3558 (k) Verify that the certificate is a CA certificate (as specified 3559 in a basicConstraints extension or as verified out-of-band). 3561 (l) If the certificate was not self-issued, verify that 3562 max_path_length is greater than zero and decrement max_path_length 3563 by 1. 3565 (m) If pathLengthConstraint is present in the certificate and is 3566 less than max_path_length, set max_path_length to the value of 3567 pathLengthConstraint. 3569 (n) If a key usage extension is present, verify that the 3570 keyCertSign bit is set. 3572 (o) Recognize and process any other critical extension present in 3573 the certificate. Process any other recognized non-critical 3574 extension present in the certificate. 3576 If check (a), (k), (l), (n) or (o) fails, the procedure terminates, 3577 returning a failure indication and an appropriate reason. 3579 If (a), (k), (l), (n) and (o) have completed successfully, increment 3580 i and perform the basic certificate processing specified in 6.1.3. 3582 6.1.5 Wrap-up procedure 3584 To complete the processing of the end entity certificate, perform the 3585 following steps for certificate n: 3587 (a) If certificate n was not self-issued and explicit_policy is 3588 not 0, decrement explicit_policy by 1. 3590 (b) If a policy constraints extension is included in the 3591 certificate and requireExplicitPolicy is present and has a value 3592 of 0, set the explicit_policy state variable to 0. 3594 (c) Assign the certificate subjectPublicKey to 3595 working_public_key. 3597 (d) If the subjectPublicKeyInfo field of the certificate contains 3598 an algorithm field with non-null parameters, assign the parameters 3599 to the working_public_key_parameters variable. 3601 If the subjectPublicKeyInfo field of the certificate contains an 3602 algorithm field with null parameters or parameters are omitted, 3603 compare the certificate subjectPublicKey algorithm to the 3604 working_public_key_algorithm. If the certificate subjectPublicKey 3605 algorithm and the working_public_key_algorithm are different, set 3606 the working_public_key_parameters to null. 3608 (e) Assign the certificate subjectPublicKey algorithm to the 3609 working_public_key_algorithm variable. 3611 (f) Recognize and process any other critical extension present in 3612 the certificate n. Process any other recognized non-critical 3613 extension present in certificate n. 3615 (g) Calculate the intersection of the valid_policy_tree and the 3616 user-initial-policy-set, as follows: 3618 (i) If the valid_policy_tree is NULL, the intersection is 3619 NULL. 3621 (ii) If the valid_policy_tree is not NULL and the user- 3622 initial-policy-set is any-policy, the intersection is the 3623 entire valid_policy_tree. 3625 (iii) If the valid_policy_tree is not NULL and the user- 3626 initial-policy-set is not any-policy, calculate the 3627 intersection of the valid_policy_tree and the user-initial- 3628 policy-set as follows: 3630 1. Determine the set of policy nodes whose parent nodes 3631 have a valid_policy of any-policy. This is the 3632 valid_policy_node_set. 3634 2. If the valid_policy of any node in the 3635 valid_policy_node_set is not in the user-initial-policy-set 3636 and is not any-policy, delete this node and all its 3637 children. 3639 3. If there is a node in the valid_policy_tree of depth n-1 3640 or less without any child nodes, delete that node. Repeat 3641 this step until there are no nodes of depth n-1 or less 3642 without children. 3644 If either (1) the value of explicit_policy variable is greater than 3645 zero, or (2) the valid_policy_tree is not NULL, then path processing 3646 has succeeded. 3648 6.1.6 Outputs 3650 If path processing succeeds, the procedure terminates, returning a 3651 success indication together with final value of the 3652 valid_policy_tree, the working_public_key, the 3653 working_public_key_algorithm, and the working_public_key_parameters. 3655 6.2 Using the Path Validation Algorithm 3657 The path validation algorithm describes the process of validating a 3658 single certification path. While each certification path begins with 3659 a specific trust anchor, there is no requirement that all 3660 certification paths validated by a particular system share a single 3661 trust anchor. An implementation that supports multiple trust anchors 3662 MAY augment the algorithm presented in section 6.1 to further limit 3663 the set of valid certification paths which begin with a particular 3664 trust anchor. For example, an implementation MAY modify the 3665 algorithm to apply name constraints to a specific trust anchor during 3666 the initialization phase, or the application MAY require the presence 3667 of a particular alternative name form in the end entity certificate, 3668 or the application MAY impose requirements on application-specific 3669 extensions. Thus, the path validation algorithm presented in section 3670 6.1 defines the minimum conditions for a path to be considered valid. 3672 The selection of one or more trusted CAs is a local decision. A 3673 system may provide any one of its trusted CAs as the trust anchor for 3674 a particular path. The inputs to the path validation algorithm may 3675 be different for each path. The inputs used to process a path may 3676 reflect application-specific requirements or limitations in the trust 3677 accorded a particular trust anchor. For example, a trusted CA may 3678 only be trusted for a particular certificate policy. This 3679 restriction can be expressed through the inputs to the path 3680 validation procedure. 3682 It is also possible to specify an extended version of the above 3683 certification path processing procedure which results in default 3684 behavior identical to the rules of PEM [RFC 1422]. In this extended 3685 version, additional inputs to the procedure are a list of one or more 3686 Policy Certification Authority (PCA) names and an indicator of the 3687 position in the certification path where the PCA is expected. At the 3688 nominated PCA position, the CA name is compared against this list. 3690 If a recognized PCA name is found, then a constraint of 3691 SubordinateToCA is implicitly assumed for the remainder of the 3692 certification path and processing continues. If no valid PCA name is 3693 found, and if the certification path cannot be validated on the basis 3694 of identified policies, then the certification path is considered 3695 invalid. 3697 6.3 CRL Validation 3699 This section describes the steps necessary to determine if a 3700 certificate is revoked or on hold status when CRLs are the revocation 3701 mechanism used by the certificate issuer. Conforming implementations 3702 that support CRLs are not required to implement this algorithm, but 3703 they MUST be functionally equivalent to the external behavior 3704 resulting from this procedure. Any algorithm may be used by a 3705 particular implementation so long as it derives the correct result. 3707 This algorithm assumes that all of the needed CRLs are available in a 3708 local cache. Further, if the next update time of a CRL has passed, 3709 the algorithm assumes a mechanism to fetch a current CRL and place it 3710 in the local CRL cache. 3712 This algorithm defines a set of inputs, a set of state variables, and 3713 processing steps that are performed for each certificate in the path. 3714 The algorithm output is the revocation status of the certificate. 3716 6.3.1 Revocation Inputs 3718 To support revocation processing, the algorithm requires two inputs: 3720 (a) certificate: The algorithm requires the certificate serial 3721 number and issuer name to determine whether a certificate is on a 3722 particular CRL. The basicConstraints extension is used to 3723 determine whether the supplied certificate is associated with a CA 3724 or an end entity. If present, the algorithm uses the 3725 cRLDistributionsPoint and freshestCRL extensions to determine 3726 revocation status. 3728 (b) use-deltas: This boolean input determines whether delta CRLs 3729 are applied to CRLs. 3731 Note that implementations supporting legacy PKIs, such as RFC 1422 3732 and X.509 version 1, will need an additional input indicating 3733 whether the supplied certificate is associated with a CA or an end 3734 entity. 3736 6.3.2 Initialization and Revocation State Variables 3738 To support CRL processing, the algorithm requires the following state 3739 variables: 3741 (a) reasons_mask: This variable contains the set of revocation 3742 reasons supported by the CRLs and delta CRLs processed so far. 3743 The legal members of the set are the possible revocation reason 3744 values: unspecified, keyCompromise, caCompromise, 3745 affiliationChanged, superseded, cessationOfOperation, 3746 certificateHold, privilegeWithdrawn, and aACompromise. The 3747 special value all-reasons is used to denote the set of all legal 3748 members. This variable is initialized to the empty set. 3750 (b) cert_status: This variable contains the status of the 3751 certificate. This variable may be assigned one of the following 3752 values: unspecified, keyCompromise, caCompromise, 3753 affiliationChanged, superseded, cessationOfOperation, 3754 certificateHold, removeFromCRL, privilegeWithdrawn, aACompromise, 3755 the special value UNREVOKED, or the special value UNDETERMINED. 3756 This variable is initialized to the special value UNREVOKED. 3758 (c) interim_reasons_mask: This contains the set of revocation 3759 reasons supported by the CRL or delta CRL currently being 3760 processed. 3762 Note: In some environments, it is not necessary to check all reason 3763 codes. For example, some environments are only concerned with 3764 caCompromise and keyCompromise for CA certificates. This algorithm 3765 checks all reason codes. Additional processing and state variables 3766 may be necessary to limit the checking to a subset of the reason 3767 codes. 3769 6.3.3 CRL Processing 3771 This algorithm begins by assuming the certificate is not revoked. 3772 The algorithm checks one or more CRLs until either the certificate 3773 status is determined to be revoked or sufficient CRLs have been 3774 checked to cover all reason codes. 3776 For each distribution point (DP) in the certificate CRL distribution 3777 points extension, for each corresponding CRL in the local CRL cache, 3778 while ((reasons_mask is not all-reasons) and 3779 (cert_status is UNREVOKED)) perform the following: 3781 (a) Update the local CRL cache by obtaining a complete CRL, a 3782 delta CRL, or both, as required: 3784 (1) If the current time is after the value of the CRL next 3785 update field, then do one of the following: 3787 (i) If use-deltas is set and either the certificate or the 3788 CRL contains the freshest CRL extension, obtain a delta CRL 3789 with the a next update value that is after the current time 3790 and can be used to update the locally cached CRL as 3791 specified in section 5.2.4. 3793 (ii) Update the local CRL cache with a current complete 3794 CRL, verify that the current time is before the next update 3795 value in the new CRL, and continue processing with the new 3796 CRL. If use-deltas is set, then obtain the current delta 3797 CRL that can be used to update the new locally cached 3798 complete CRL as specified in section 5.2.4. 3800 (2) If the current time is before the value of the next update 3801 field and use-deltas is set, then obtain the current delta CRL 3802 that can be used to update the locally cached complete CRL as 3803 specified in section 5.2.4. 3805 (b) Verify the issuer and scope of the complete CRL as follows: 3807 (1) If the DP includes cRLIssuer, then verify that the issuer 3808 field in the complete CRL matches cRLIssuer in the DP and that 3809 the complete CRL contains an issuing distribution point 3810 extension with the indrectCRL boolean asserted. Otherwise, 3811 verify that the CRL issuer matches the certificate issuer. 3813 (2) If the complete CRL includes an issuing distribution point 3814 (IDP) CRL extension check the following: 3816 (i) If the distribution point name is present in the IDP 3817 CRL extension and the distribution field is present in the 3818 DP, then verify that one of the names in the IDP matches one 3819 of the names in the DP. If the distribution point name is 3820 present in the IDP CRL extension and the distribution field 3821 is omitted from the DP, then verify that one of the names in 3822 the IDP matches one of the names in the cRLIssuer field of 3823 the DP. 3825 (ii) If the onlyContainsUserCerts boolean is asserted in 3826 the IDP CRL extension, verify that the certificate does not 3827 include the basic constraints extension with the cA boolean 3828 asserted. 3830 (iii) If the onlyContainsCACerts boolean is asserted in the 3831 IDP CRL extension, verify that the certificate includes the 3832 basic constraints extension with the cA boolean asserted. 3834 (iv) Verify that the onlyContainsAttributeCerts boolean is 3835 not asserted. 3837 (c) If use-deltas is set, verify the issuer and scope of the 3838 delta CRL as follows: 3840 (1) Verify that the delta CRL issuer matches complete CRL 3841 issuer. 3843 (2) If the complete CRL includes an issuing distribution point 3844 (IDP) CRL extension, verify that the delta CRL contains a 3845 matching IDP CRL extension. If the complete CRL omits an IDP 3846 CRL extension, verify that the delta CRL also omits an IDP CRL 3847 extension. 3849 (3) Verify that the delta CRL authority key identifier 3850 extension matches complete CRL authority key identifier 3851 extension. 3853 (d) Compute the interim_reasons_mask for this CRL as follows: 3855 (1) If the issuing distribution point (IDP) CRL extension is 3856 present and includes onlySomeReasons and the DP includes 3857 reasons, then set interim_reasons_mask to the intersection of 3858 reasons in the DP and onlySomeReasons in IDP CRL extension. 3860 (2) If the IDP CRL extension includes onlySomeReasons but the 3861 DP omits reasons, then set interim_reasons_mask to the value of 3862 onlySomeReasons in IDP CRL extension. 3864 (3) If the IDP CRL extension is not present or omits 3865 onlySomeReasons but the DP includes reasons, then set 3866 interim_reasons_mask to the value of DP reasons. 3868 (4) If the IDP CRL extension is not present or omits 3869 onlySomeReasons and the DP omits reasons, then set 3870 interim_reasons_mask to the special value all-reasons. 3872 (e) Verify that interim_reasons_mask includes one or more reasons 3873 that is not included in the reasons_mask. 3875 (f) Obtain and validate the certification path for the complete 3876 CRL issuer. 3878 (g) Validate the signature on the complete CRL using the public 3879 key validated in step (f). 3881 (h) If use-deltas is set, then validate the signature on the 3882 delta CRL using the public key validated in step (f). 3884 (i) If use-deltas is set, then search for the certificate on the 3885 delta CRL. If an entry is found that matches the certificate 3886 issuer and serial number as described in section 5.3.4, then set 3887 the cert_status variable to the indicated reason as follows: 3889 (1) If the reason code CRL entry extension is present, set the 3890 cert_status variable to the value of the reason code CRL entry 3891 extension. 3893 (2) If the reason code CRL entry extension is not present, set 3894 the cert_status variable to the value unspecified. 3896 (j) If (cert_status is UNREVOKED), then search for the 3897 certificate on the complete CRL. If an entry is found that 3898 matches the certificate issuer and serial number as described in 3899 section 5.3.4, then set the cert_status variable to the indicated 3900 reason as described in step (i). 3902 (k) If (cert_status is removeFromCRL), then set cert_status to 3903 UNREVOKED. 3905 If ((reasons_mask is all-reasons) OR (cert_status is not UNREVOKED)), 3906 then the revocation status has been determined, so return 3907 cert_status. 3909 If the revocation status has not been determined, repeat the process 3910 above with any available CRLs not specified in a distribution point 3911 but issued by the certificate issuer. For the processing of such a 3912 CRL, assume a DP with both the reasons and the cRLIssuer fields 3913 omitted and a distribution point name of the certificate issuer. 3914 That is, the sequence of names in fullName is generated from the 3915 certificate issuer field as well as the certificate issuerAltName 3916 extension. If the revocation status remains undetermined, then 3917 return the cert_status UNDETERMINED. 3919 7 References 3921 [ISO 10646] ISO/IEC 10646-1:1993. International Standard -- 3922 Information technology -- Universal Multiple-Octet Coded 3923 Character Set (UCS) -- Part 1: Architecture and Basic 3924 Multilingual Plane. 3926 [RFC 791] Postel, J., "Internet Protocol", RFC 791, 3927 September 1981. 3929 [RFC 822] Crocker, D., "Standard for the format of ARPA Internet 3930 text messages", RFC 822, August 1982. 3932 [RFC 1034] Mockapetris, P.V., "Domain names - concepts and 3933 facilities", RFC 1034, November 1987. 3935 [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic 3936 Mail: Part II: Certificate-Based Key Management," 3937 RFC 1422, February 1993. 3939 [RFC 1423] Balenson, D., "Privacy Enhancement for Internet 3940 Electronic Mail: Part III: Algorithms, Modes, and 3941 Identifiers," RFC 1423, February 1993. 3943 [RFC 1510] Kohl, J., and C. Neuman, "The Kerberos Network 3944 Authentication Service (V5)," RFC 1510, September 1993. 3946 [RFC 1519] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless 3947 Inter-Domain Routing (CIDR): An Address Assignment and 3948 Aggregation Strategy", RFC 1519, September 1993. 3950 [RFC 1738] Berners-Lee, T., L. Masinter, and M. McCahill, 3951 "Uniform Resource Locators (URL)", RFC 1738, 3952 December 1994. 3954 [RFC 1778] Howes, T., S. Kille, W. Yeong, and C. Robbins, "The 3955 String Representation of Standard Attribute Syntaxes," 3956 RFC 1778, March 1995. 3958 [RFC 1883] Deering, S., and R. Hinden. "Internet Protocol, 3959 Version 6 (IPv6) Specification", RFC 1883, December 3960 1995. 3962 [RFC 2044] F. Yergeau, F., "UTF-8, a transformation format of 3963 Unicode and ISO 10646", RFC 2044, October 1996. 3965 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 3966 Requirement Levels", RFC 2119, March 1997. 3968 [RFC 2247] Kille, S., M. Wahl, A. Grimstad, R. Huber, and 3969 S. Sataluri, "Using Domains in LDAP/X.500 3970 Distinguished Names", RFC 2247, January 1998. 3972 [RFC 2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille, 3973 "Lightweight Directory Access Protocol (v3): 3974 Attribute Syntax Definitions", RFC 2252, 3975 December 1997. 3977 [RFC 2277] Alvestrand, H., "IETF Policy on Character Sets and 3978 Languages", January 1998. 3980 [RFC 2279] Yergeau, F., "UTF-8, a transformation format of 3981 ISO 10646", RFC 2279, January 1998. 3983 [RFC 2459] Housley, R., W. Ford, W. Polk, and D. Solo, "Internet 3984 X.509 Public Key Infrastructure: Certificate and CRL 3985 Profile", RFC 2459, January 1999. 3987 [RFC 2560] Myers, M., R. Ankney, A. Malpani, S. Galperin, and 3988 C. Adams, "Online Certificate Status Protocal - OCSP", 3989 June 1999. 3991 [SDN.701] SDN.701, "Message Security Protocol 4.0", Revision A, 3992 1997-02-06. 3994 [X.208] CCITT Recommendation X.208: Specification of Abstract 3995 Syntax Notation One (ASN.1), 1988. 3997 [X.501] ITU-T Recommendation X.501: Information 3998 Technology - Open Systems Interconnection - The 3999 Directory: Models, 1993. 4001 [X.509] ITU-T Recommendation X.509 (1997 E): Information 4002 Technology - Open Systems Interconnection - The 4003 Directory: Authentication Framework, June 1997. 4005 [X.520] ITU-T Recommendation X.520: Information 4006 Technology - Open Systems Interconnection - The 4007 Directory: Selected Attribute Types, 1993. 4009 [X.660] ITU-T Recommendation X.660 Information 4010 Technology - Open Systems Interconnection - 4011 Procedures for the operation of OSI 4012 Registration Authorities: General procedures, 1992. 4014 [X9.55] ANSI X9.55-1995, Public Key Cryptography For The 4015 Financial Services Industry: Extensions To Public 4016 Key Certificates And Certificate Revocation Lists, 4017 8 December, 1995. 4019 [PKIXALGS] Bassham, L., R. Housley, and W. Polk, "Internet X.509 4020 Public Key Infrastructure Representation of Public Keys 4021 and Digital Signatures," 4022 draft-ietf-pkix-ipki-pkalgs-02.txt, March 2001. 4024 [PKIXTSA] Cain, P., D. Pinkas, and R. Zuccherato, "Internet 4025 X.509 Public Key Infrastructure Time Stamp Protocol," 4026 draft-ietf-pkix-time-stamp-13.txt, January 2001. 4028 8 Intellectual Property Rights 4030 The IETF has been notified of intellectual property rights claimed in 4031 regard to some or all of the specification contained in this 4032 document. For more information consult the online list of claimed 4033 rights (see http://www.ietf.org/ipr.html). 4035 The IETF takes no position regarding the validity or scope of any 4036 intellectual property or other rights that might be claimed to 4037 pertain to the implementation or use of the technology described in 4038 this document or the extent to which any license under such rights 4039 might or might not be available; neither does it represent that it 4040 has made any effort to identify any such rights. Information on the 4041 IETF's procedures with respect to rights in standards-track and 4042 standards-related documentation can be found in BCP-11. Copies of 4043 claims of rights made available for publication and any assurances of 4044 licenses to be made available, or the result of an attempt made to 4045 obtain a general license or permission for the use of such 4046 proprietary rights by implementors or users of this specification can 4047 be obtained from the IETF Secretariat. 4049 9 Security Considerations 4051 The majority of this specification is devoted to the format and 4052 content of certificates and CRLs. Since certificates and CRLs are 4053 digitally signed, no additional integrity service is necessary. 4054 Neither certificates nor CRLs need be kept secret, and unrestricted 4055 and anonymous access to certificates and CRLs has no security 4056 implications. 4058 However, security factors outside the scope of this specification 4059 will affect the assurance provided to certificate users. This 4060 section highlights critical issues to be considered by implementers, 4061 administrators, and users. 4063 The procedures performed by CAs and RAs to validate the binding of 4064 the subject's identity to their public key greatly affect the 4065 assurance that ought to be placed in the certificate. Relying 4066 parties might wish to review the CA's certificate practice statement. 4067 This is particularly important when issuing certificates to other 4068 CAs. 4070 The use of a single key pair for both signature and other purposes is 4071 strongly discouraged. Use of separate key pairs for signature and 4072 key management provides several benefits to the users. The 4073 ramifications associated with loss or disclosure of a signature key 4074 are different from loss or disclosure of a key management key. Using 4075 separate key pairs permits a balanced and flexible response. 4076 Similarly, different validity periods or key lengths for each key 4077 pair may be appropriate in some application environments. 4078 Unfortunately, some legacy applications (e.g., SSL) use a single key 4079 pair for signature and key management. 4081 The protection afforded private keys is a critical security factor. 4082 On a small scale, failure of users to protect their private keys will 4083 permit an attacker to masquerade as them, or decrypt their personal 4084 information. On a larger scale, compromise of a CA's private signing 4085 key may have a catastrophic effect. If an attacker obtains the 4086 private key unnoticed, the attacker may issue bogus certificates and 4087 CRLs. Existence of bogus certificates and CRLs will undermine 4088 confidence in the system. If such a compromise is detected, all 4089 certificates issued to the compromised CA MUST be revoked, preventing 4090 services between its users and users of other CAs. Rebuilding after 4091 such a compromise will be problematic, so CAs are advised to 4092 implement a combination of strong technical measures (e.g., tamper- 4093 resistant cryptographic modules) and appropriate management 4094 procedures (e.g., separation of duties) to avoid such an incident. 4096 Loss of a CA's private signing key may also be problematic. The CA 4097 would not be able to produce CRLs or perform normal key rollover. 4098 CAs SHOULD maintain secure backup for signing keys. The security of 4099 the key backup procedures is a critical factor in avoiding key 4100 compromise. 4102 The availability and freshness of revocation information affects the 4103 degree of assurance that ought to be placed in a certificate. While 4104 certificates expire naturally, events may occur during its natural 4105 lifetime which negate the binding between the subject and public key. 4106 If revocation information is untimely or unavailable, the assurance 4107 associated with the binding is clearly reduced. Relying parties 4108 might not be able to process every critical extension that can appear 4109 in a CRL. CAs SHOULD take extra care when making revocation 4110 information available only through CRLs that contain critical 4111 extensions, particularly if support for those extensions is not 4112 mandated by this profile. For example, if revocation information is 4113 supplied using a combination of delta CRLs and full CRLs, and the 4114 delta CRLs are issued more frequently than the full CRLs, then 4115 relying parties that cannot handle the critical extensions related to 4116 delta CRL processing will not be able to obtain the most recent 4117 revocation information. Alternatively, if a full CRL is issued 4118 whenever a delta CRL is issued, then timely revocation information 4119 will be available to all relying parties. Similarly, implementations 4120 of the certification path validation mechanism described in section 6 4121 that omit revocation checking provide less assurance than those that 4122 support it. 4124 The path validation algorithm depends on the certain knowledge of the 4125 public keys (and other information) about one or more trusted CAs. 4126 The decision to trust a CA is an important decision as it ultimately 4127 determines the trust afforded a certificate. The authenticated 4128 distribution of trusted CA public keys (usually in the form of a 4129 "self-signed" certificate) is a security critical out-of-band process 4130 that is beyond the scope of this specification. 4132 In addition, where a key compromise or CA failure occurs for a 4133 trusted CA, the user will need to modify the information provided to 4134 the path validation routine. Selection of too many trusted CAs makes 4135 the trusted CA information difficult to maintain. On the other hand, 4136 selection of only one trusted CA could limit users to a closed 4137 community of users. 4139 The quality of implementations that process certificates also affects 4140 the degree of assurance provided. The path validation algorithm 4141 described in section 6 relies upon the integrity of the trusted CA 4142 information, and especially the integrity of the public keys 4143 associated with the trusted CAs. By substituting public keys for 4144 which an attacker has the private key, an attacker could trick the 4145 user into accepting false certificates. 4147 The binding between a key and certificate subject cannot be stronger 4148 than the cryptographic module implementation and algorithms used to 4149 generate the signature. Short key lengths or weak hash algorithms 4150 will limit the utility of a certificate. CAs are encouraged to note 4151 advances in cryptology so they can employ strong cryptographic 4152 techniques. In addition, CAs SHOULD decline to issue certificates to 4153 CAs or end entities that generate weak signatures. 4155 Inconsistent application of name comparison rules can result in 4156 acceptance of invalid X.509 certification paths, or rejection of 4157 valid ones. The X.500 series of specifications defines rules for 4158 comparing distinguished names that require comparison of strings 4159 without regard to case, character set, multi-character white space 4160 substring, or leading and trailing white space. This specification 4161 relaxes these requirements, requiring support for binary comparison 4162 at a minimum. 4164 CAs MUST encode the distinguished name in the subject field of a CA 4165 certificate identically to the distinguished name in the issuer field 4166 in certificates issued by that CA. If CAs use different encodings, 4167 implementations might fail to recognize name chains for paths that 4168 include this certificate. As a consequence, valid paths could be 4169 rejected. 4171 In addition, name constraints for distinguished names MUST be stated 4172 identically to the encoding used in the subject field or 4173 subjectAltName extension. If not, then name constraints stated as 4174 excludedSubTrees will not match and invalid paths will be accepted 4175 and name constraints expressed as permittedSubtrees will not match 4176 and valid paths will be rejected. To avoid acceptance of invalid 4177 paths, CAs SHOULD state name constraints for distinguished names as 4178 permittedSubtrees wherever possible. 4180 Appendix A. Psuedo-ASN.1 Structures and OIDs 4182 This section describes data objects used by conforming PKI components 4183 in an "ASN.1-like" syntax. This syntax is a hybrid of the 1988 and 4184 1993 ASN.1 syntaxes. The 1988 ASN.1 syntax is augmented with 1993 4185 UNIVERSAL Types UniversalString, BMPString and UTF8String. 4187 The ASN.1 syntax does not permit the inclusion of type statements in 4188 the ASN.1 module, and the 1993 ASN.1 standard does not permit use of 4189 the new UNIVERSAL types in modules using the 1988 syntax. As a 4190 result, this module does not conform to either version of the ASN.1 4191 standard. 4193 This appendix may be converted into 1988 ASN.1 by replacing the 4194 defintions for the UNIVERSAL Types with the 1988 catch-all "ANY". 4196 A.1 Explicitly Tagged Module, 1988 Syntax 4198 PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) 4199 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) } 4201 DEFINITIONS EXPLICIT TAGS ::= 4203 BEGIN 4205 -- EXPORTS ALL -- 4207 -- IMPORTS NONE -- 4209 -- UNIVERSAL Types defined in 1993 and 1998 ASN.1 4210 -- and required by this specification 4212 UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING 4213 -- UniversalString is defined in ASN.1:1993 4215 BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING 4216 -- BMPString is the subtype of UniversalString and models 4217 -- the Basic Multilingual Plane of ISO/IEC/ITU 10646-1 4219 UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 4220 -- The content of this type conforms to RFC 2279. 4222 -- PKIX specific OIDs 4224 id-pkix OBJECT IDENTIFIER ::= 4225 { iso(1) identified-organization(3) dod(6) internet(1) 4226 security(5) mechanisms(5) pkix(7) } 4228 -- PKIX arcs 4230 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 4231 -- arc for private certificate extensions 4232 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 4233 -- arc for policy qualifier types 4234 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 4235 -- arc for extended key purpose OIDS 4236 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 4237 -- arc for access descriptors 4239 -- policyQualifierIds for Internet policy qualifiers 4241 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 4242 -- OID for CPS qualifier 4243 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 4244 -- OID for user notice qualifier 4246 -- access descriptor definitions 4248 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 4249 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 4250 id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 } 4251 id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 } 4253 -- attribute data types 4255 Attribute ::= SEQUENCE { 4256 type AttributeType, 4257 values SET OF AttributeValue } 4258 -- at least one value is required 4260 AttributeType ::= OBJECT IDENTIFIER 4262 AttributeValue ::= ANY 4264 AttributeTypeAndValue ::= SEQUENCE { 4265 type AttributeType, 4266 value AttributeValue } 4268 -- suggested naming attributes: Definition of the following 4269 -- information object set may be augmented to meet local 4270 -- requirements. Note that deleting members of the set may 4271 -- prevent interoperability with conforming implementations. 4272 -- presented in pairs: the AttributeType followed by the 4273 -- type definition for the corresponding AttributeValue 4275 --Arc for standard naming attributes 4276 id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 } 4278 -- Naming attributes of type X520name 4280 id-at-name AttributeType ::= { id-at 41 } 4281 id-at-surname AttributeType ::= { id-at 4 } 4282 id-at-givenName AttributeType ::= { id-at 42 } 4283 id-at-initials AttributeType ::= { id-at 43 } 4284 id-at-generationQualifier AttributeType ::= { id-at 44 } 4286 X520name ::= CHOICE { 4287 teletexString TeletexString (SIZE (1..ub-name)), 4288 printableString PrintableString (SIZE (1..ub-name)), 4289 universalString UniversalString (SIZE (1..ub-name)), 4290 utf8String UTF8String (SIZE (1..ub-name)), 4291 bmpString BMPString (SIZE (1..ub-name)) } 4293 -- Naming attributes of type X520CommonName 4295 id-at-commonName AttributeType ::= { id-at 3 } 4297 X520CommonName ::= CHOICE { 4298 teletexString TeletexString (SIZE (1..ub-common-name)), 4299 printableString PrintableString (SIZE (1..ub-common-name)), 4300 universalString UniversalString (SIZE (1..ub-common-name)), 4301 utf8String UTF8String (SIZE (1..ub-common-name)), 4302 bmpString BMPString (SIZE (1..ub-common-name)) } 4304 -- Naming attributes of type X520LocalityName 4306 id-at-localityName AttributeType ::= { id-at 7 } 4308 X520LocalityName ::= CHOICE { 4309 teletexString TeletexString (SIZE (1..ub-locality-name)), 4310 printableString PrintableString (SIZE (1..ub-locality-name)), 4311 universalString UniversalString (SIZE (1..ub-locality-name)), 4312 utf8String UTF8String (SIZE (1..ub-locality-name)), 4313 bmpString BMPString (SIZE (1..ub-locality-name)) } 4315 -- Naming attributes of type X520StateOrProvinceName 4317 id-at-stateOrProvinceName AttributeType ::= { id-at 8 } 4319 X520StateOrProvinceName ::= CHOICE { 4320 teletexString TeletexString (SIZE (1..ub-state-name)), 4321 printableString PrintableString (SIZE (1..ub-state-name)), 4322 universalString UniversalString (SIZE (1..ub-state-name)), 4323 utf8String UTF8String (SIZE (1..ub-state-name)), 4324 bmpString BMPString (SIZE(1..ub-state-name)) } 4326 -- Naming attributes of type X520OrganizationName 4328 id-at-organizationName AttributeType ::= { id-at 10 } 4330 X520OrganizationName ::= CHOICE { 4331 teletexString TeletexString 4332 (SIZE (1..ub-organization-name)), 4333 printableString PrintableString 4334 (SIZE (1..ub-organization-name)), 4335 universalString UniversalString 4336 (SIZE (1..ub-organization-name)), 4337 utf8String UTF8String 4338 (SIZE (1..ub-organization-name)), 4339 bmpString BMPString 4340 (SIZE (1..ub-organization-name)) } 4342 -- Naming attributes of type X520OrganizationalUnitName 4344 id-at-organizationalUnitName AttributeType ::= { id-at 11 } 4346 X520OrganizationalUnitName ::= CHOICE { 4347 teletexString TeletexString 4348 (SIZE (1..ub-organizational-unit-name)), 4349 printableString PrintableString 4350 (SIZE (1..ub-organizational-unit-name)), 4351 universalString UniversalString 4352 (SIZE (1..ub-organizational-unit-name)), 4353 utf8String UTF8String 4354 (SIZE (1..ub-organizational-unit-name)), 4355 bmpString BMPString 4356 (SIZE (1..ub-organizational-unit-name)) } 4358 -- Naming attributes of type X520Title 4360 id-at-title AttributeType ::= { id-at 12 } 4362 X520Title ::= CHOICE { 4363 teletexString TeletexString (SIZE (1..ub-title)), 4364 printableString PrintableString (SIZE (1..ub-title)), 4365 universalString UniversalString (SIZE (1..ub-title)), 4366 utf8String UTF8String (SIZE (1..ub-title)), 4367 bmpString BMPString (SIZE (1..ub-title)) } 4369 -- Naming attributes of type X520dnQualifier 4370 id-at-dnQualifier AttributeType ::= { id-at 46 } 4372 X520dnQualifier ::= PrintableString 4374 -- Naming attributes of type X520countryName (digraph from IS 3166) 4376 id-at-countryName AttributeType ::= { id-at 6 } 4378 X520countryName ::= PrintableString (SIZE (2)) 4380 -- Naming attributes of type X520SerialNumber 4382 id-at-serialNumber AttributeType ::= { id-at 5 } 4384 X520SerialNumber ::= PrintableString (SIZE (1..ub-serial-number)) 4386 -- Naming attributes of type X520Pseudonym 4388 id-at-pseudonym AttributeType ::= { id-at 65 } 4390 X520Pseudonym ::= CHOICE { 4391 teletexString TeletexString (SIZE (1..ub-pseudonym)), 4392 printableString PrintableString (SIZE (1..ub-pseudonym)), 4393 universalString UniversalString (SIZE (1..ub-pseudonym)), 4394 utf8String UTF8String (SIZE (1..ub-pseudonym)), 4395 bmpString BMPString (SIZE (1..ub-pseudonym)) } 4397 -- Naming attributes of type DomainComponent (from RFC 2247) 4399 id-domainComponent AttributeType ::= 4400 { 0 9 2342 19200300 100 1 25 } 4402 DomainComponent ::= IA5String 4404 -- Legacy attributes 4406 pkcs-9 OBJECT IDENTIFIER ::= 4407 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 } 4409 id-emailAddress AttributeType ::= { pkcs-9 1 } 4411 EmailAddress ::= IA5String (SIZE (1..ub-emailaddress-length)) 4413 -- naming data types -- 4415 Name ::= CHOICE { -- only one possibility for now -- 4416 rdnSequence RDNSequence } 4418 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 4420 DistinguishedName ::= RDNSequence 4422 RelativeDistinguishedName ::= 4423 SET SIZE (1 .. MAX) OF AttributeTypeAndValue 4425 -- Directory string type -- 4427 DirectoryString ::= CHOICE { 4428 teletexString TeletexString (SIZE (1..MAX)), 4429 printableString PrintableString (SIZE (1..MAX)), 4430 universalString UniversalString (SIZE (1..MAX)), 4431 utf8String UTF8String (SIZE (1..MAX)), 4432 bmpString BMPString (SIZE (1..MAX)) } 4434 -- certificate and CRL specific structures begin here 4436 Certificate ::= SEQUENCE { 4437 tbsCertificate TBSCertificate, 4438 signatureAlgorithm AlgorithmIdentifier, 4439 signature BIT STRING } 4441 TBSCertificate ::= SEQUENCE { 4442 version [0] Version DEFAULT v1, 4443 serialNumber CertificateSerialNumber, 4444 signature AlgorithmIdentifier, 4445 issuer Name, 4446 validity Validity, 4447 subject Name, 4448 subjectPublicKeyInfo SubjectPublicKeyInfo, 4449 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 4450 -- If present, version MUST be v2 or v3 4451 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 4452 -- If present, version MUST be v2 or v3 4453 extensions [3] Extensions OPTIONAL 4454 -- If present, version MUST be v3 -- } 4456 Version ::= INTEGER { v1(0), v2(1), v3(2) } 4458 CertificateSerialNumber ::= INTEGER 4460 Validity ::= SEQUENCE { 4461 notBefore Time, 4462 notAfter Time } 4464 Time ::= CHOICE { 4465 utcTime UTCTime, 4466 generalTime GeneralizedTime } 4468 UniqueIdentifier ::= BIT STRING 4470 SubjectPublicKeyInfo ::= SEQUENCE { 4471 algorithm AlgorithmIdentifier, 4472 subjectPublicKey BIT STRING } 4474 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 4476 Extension ::= SEQUENCE { 4477 extnID OBJECT IDENTIFIER, 4478 critical BOOLEAN DEFAULT FALSE, 4479 extnValue OCTET STRING } 4481 -- CRL structures 4483 CertificateList ::= SEQUENCE { 4484 tbsCertList TBSCertList, 4485 signatureAlgorithm AlgorithmIdentifier, 4486 signature BIT STRING } 4488 TBSCertList ::= SEQUENCE { 4489 version Version OPTIONAL, 4490 -- if present, MUST be v2 4491 signature AlgorithmIdentifier, 4492 issuer Name, 4493 thisUpdate Time, 4494 nextUpdate Time OPTIONAL, 4495 revokedCertificates SEQUENCE OF SEQUENCE { 4496 userCertificate CertificateSerialNumber, 4497 revocationDate Time, 4498 crlEntryExtensions Extensions OPTIONAL 4499 -- if present, MUST be v2 4500 } OPTIONAL, 4501 crlExtensions [0] Extensions OPTIONAL 4502 -- if present, MUST be v2 -- } 4504 -- Version, Time, CertificateSerialNumber, and Extensions were 4505 -- defined earlier for use in the certificate structure 4507 AlgorithmIdentifier ::= SEQUENCE { 4508 algorithm OBJECT IDENTIFIER, 4509 parameters ANY DEFINED BY algorithm OPTIONAL } 4510 -- contains a value of the type 4511 -- registered for use with the 4512 -- algorithm object identifier value 4514 -- X.400 address syntax starts here 4516 ORAddress ::= SEQUENCE { 4517 built-in-standard-attributes BuiltInStandardAttributes, 4518 built-in-domain-defined-attributes 4519 BuiltInDomainDefinedAttributes OPTIONAL, 4520 -- see also teletex-domain-defined-attributes 4521 extension-attributes ExtensionAttributes OPTIONAL } 4522 -- [[[*** What is this comment about? OR-Name is not defined ***]]] 4523 -- The OR-address is semantically absent from the OR-name if the 4524 -- built-in-standard-attribute sequence is empty and the 4525 -- built-in-domain-defined-attributes and extension-attributes are 4526 -- both omitted. 4528 -- Built-in Standard Attributes 4530 BuiltInStandardAttributes ::= SEQUENCE { 4531 country-name CountryName OPTIONAL, 4532 administration-domain-name AdministrationDomainName OPTIONAL, 4533 network-address [0] NetworkAddress OPTIONAL, 4534 -- see also extended-network-address 4535 terminal-identifier [1] TerminalIdentifier OPTIONAL, 4536 private-domain-name [2] PrivateDomainName OPTIONAL, 4537 organization-name [3] OrganizationName OPTIONAL, 4538 -- see also teletex-organization-name 4539 numeric-user-identifier [4] NumericUserIdentifier OPTIONAL, 4540 personal-name [5] PersonalName OPTIONAL, 4541 -- see also teletex-personal-name 4542 organizational-unit-names [6] OrganizationalUnitNames OPTIONAL 4543 -- see also teletex-organizational-unit-names -- } 4545 CountryName ::= [APPLICATION 1] CHOICE { 4546 x121-dcc-code NumericString 4547 (SIZE (ub-country-name-numeric-length)), 4548 iso-3166-alpha2-code PrintableString 4549 (SIZE (ub-country-name-alpha-length)) } 4551 AdministrationDomainName ::= [APPLICATION 2] CHOICE { 4552 numeric NumericString (SIZE (0..ub-domain-name-length)), 4553 printable PrintableString (SIZE (0..ub-domain-name-length)) } 4555 NetworkAddress ::= X121Address -- see also extended-network-address 4557 X121Address ::= NumericString (SIZE (1..ub-x121-address-length)) 4559 TerminalIdentifier ::= PrintableString (SIZE (1..ub-terminal-id-length)) 4560 PrivateDomainName ::= CHOICE { 4561 numeric NumericString (SIZE (1..ub-domain-name-length)), 4562 printable PrintableString (SIZE (1..ub-domain-name-length)) } 4564 OrganizationName ::= PrintableString 4565 (SIZE (1..ub-organization-name-length)) 4566 -- see also teletex-organization-name 4568 NumericUserIdentifier ::= NumericString 4569 (SIZE (1..ub-numeric-user-id-length)) 4571 PersonalName ::= SET { 4572 surname [0] PrintableString (SIZE (1..ub-surname-length)), 4573 given-name [1] PrintableString 4574 (SIZE (1..ub-given-name-length)) OPTIONAL, 4575 initials [2] PrintableString (SIZE (1..ub-initials-length)) OPTIONAL, 4576 generation-qualifier [3] PrintableString 4577 (SIZE (1..ub-generation-qualifier-length)) OPTIONAL } 4578 -- see also teletex-personal-name 4580 OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units) 4581 OF OrganizationalUnitName 4582 -- see also teletex-organizational-unit-names 4584 OrganizationalUnitName ::= PrintableString (SIZE 4585 (1..ub-organizational-unit-name-length)) 4587 -- Built-in Domain-defined Attributes 4589 BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE 4590 (1..ub-domain-defined-attributes) OF 4591 BuiltInDomainDefinedAttribute 4593 BuiltInDomainDefinedAttribute ::= SEQUENCE { 4594 type PrintableString (SIZE 4595 (1..ub-domain-defined-attribute-type-length)), 4596 value PrintableString (SIZE 4597 (1..ub-domain-defined-attribute-value-length)) } 4599 -- Extension Attributes 4601 ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF 4602 ExtensionAttribute 4604 ExtensionAttribute ::= SEQUENCE { 4605 extension-attribute-type [0] INTEGER (0..ub-extension-attributes), 4606 extension-attribute-value [1] 4607 ANY DEFINED BY extension-attribute-type } 4609 -- Extension types and attribute values 4611 common-name INTEGER ::= 1 4613 CommonName ::= PrintableString (SIZE (1..ub-common-name-length)) 4615 teletex-common-name INTEGER ::= 2 4617 TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length)) 4619 teletex-organization-name INTEGER ::= 3 4621 TeletexOrganizationName ::= 4622 TeletexString (SIZE (1..ub-organization-name-length)) 4624 teletex-personal-name INTEGER ::= 4 4626 TeletexPersonalName ::= SET { 4627 surname [0] TeletexString (SIZE (1..ub-surname-length)), 4628 given-name [1] TeletexString 4629 (SIZE (1..ub-given-name-length)) OPTIONAL, 4630 initials [2] TeletexString (SIZE (1..ub-initials-length)) OPTIONAL, 4631 generation-qualifier [3] TeletexString (SIZE 4632 (1..ub-generation-qualifier-length)) OPTIONAL } 4634 teletex-organizational-unit-names INTEGER ::= 5 4636 TeletexOrganizationalUnitNames ::= SEQUENCE SIZE 4637 (1..ub-organizational-units) OF TeletexOrganizationalUnitName 4639 TeletexOrganizationalUnitName ::= TeletexString 4640 (SIZE (1..ub-organizational-unit-name-length)) 4642 pds-name INTEGER ::= 7 4644 PDSName ::= PrintableString (SIZE (1..ub-pds-name-length)) 4646 physical-delivery-country-name INTEGER ::= 8 4648 PhysicalDeliveryCountryName ::= CHOICE { 4649 x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)), 4650 iso-3166-alpha2-code PrintableString 4651 (SIZE (ub-country-name-alpha-length)) } 4653 postal-code INTEGER ::= 9 4655 PostalCode ::= CHOICE { 4656 numeric-code NumericString (SIZE (1..ub-postal-code-length)), 4657 printable-code PrintableString (SIZE (1..ub-postal-code-length)) } 4659 physical-delivery-office-name INTEGER ::= 10 4661 PhysicalDeliveryOfficeName ::= PDSParameter 4663 physical-delivery-office-number INTEGER ::= 11 4665 PhysicalDeliveryOfficeNumber ::= PDSParameter 4667 extension-OR-address-components INTEGER ::= 12 4669 ExtensionORAddressComponents ::= PDSParameter 4671 physical-delivery-personal-name INTEGER ::= 13 4673 PhysicalDeliveryPersonalName ::= PDSParameter 4675 physical-delivery-organization-name INTEGER ::= 14 4677 PhysicalDeliveryOrganizationName ::= PDSParameter 4679 extension-physical-delivery-address-components INTEGER ::= 15 4681 ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter 4683 unformatted-postal-address INTEGER ::= 16 4685 UnformattedPostalAddress ::= SET { 4686 printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) OF 4687 PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL, 4688 teletex-string TeletexString 4689 (SIZE (1..ub-unformatted-address-length)) OPTIONAL } 4691 street-address INTEGER ::= 17 4693 StreetAddress ::= PDSParameter 4695 post-office-box-address INTEGER ::= 18 4697 PostOfficeBoxAddress ::= PDSParameter 4699 poste-restante-address INTEGER ::= 19 4701 PosteRestanteAddress ::= PDSParameter 4703 unique-postal-name INTEGER ::= 20 4704 UniquePostalName ::= PDSParameter 4706 local-postal-attributes INTEGER ::= 21 4708 LocalPostalAttributes ::= PDSParameter 4710 PDSParameter ::= SET { 4711 printable-string PrintableString 4712 (SIZE(1..ub-pds-parameter-length)) OPTIONAL, 4713 teletex-string TeletexString 4714 (SIZE(1..ub-pds-parameter-length)) OPTIONAL } 4716 extended-network-address INTEGER ::= 22 4718 ExtendedNetworkAddress ::= CHOICE { 4719 e163-4-address SEQUENCE { 4720 number [0] NumericString (SIZE (1..ub-e163-4-number-length)), 4721 sub-address [1] NumericString 4722 (SIZE (1..ub-e163-4-sub-address-length)) OPTIONAL }, 4723 psap-address [0] PresentationAddress } 4725 PresentationAddress ::= SEQUENCE { 4726 pSelector [0] EXPLICIT OCTET STRING OPTIONAL, 4727 sSelector [1] EXPLICIT OCTET STRING OPTIONAL, 4728 tSelector [2] EXPLICIT OCTET STRING OPTIONAL, 4729 nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING } 4731 terminal-type INTEGER ::= 23 4733 TerminalType ::= INTEGER { 4734 telex (3), 4735 teletex (4), 4736 g3-facsimile (5), 4737 g4-facsimile (6), 4738 ia5-terminal (7), 4739 videotex (8) } (0..ub-integer-options) 4741 -- Extension Domain-defined Attributes 4743 teletex-domain-defined-attributes INTEGER ::= 6 4745 TeletexDomainDefinedAttributes ::= SEQUENCE SIZE 4746 (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute 4748 TeletexDomainDefinedAttribute ::= SEQUENCE { 4749 type TeletexString 4750 (SIZE (1..ub-domain-defined-attribute-type-length)), 4751 value TeletexString 4752 (SIZE (1..ub-domain-defined-attribute-value-length)) } 4754 -- specifications of Upper Bounds MUST be regarded as mandatory 4755 -- from Annex B of ITU-T X.411 Reference Definition of MTS Parameter 4756 -- Upper Bounds 4758 -- Upper Bounds 4759 ub-name INTEGER ::= 32768 4760 ub-common-name INTEGER ::= 64 4761 ub-locality-name INTEGER ::= 128 4762 ub-state-name INTEGER ::= 128 4763 ub-organization-name INTEGER ::= 64 4764 ub-organizational-unit-name INTEGER ::= 64 4765 ub-title INTEGER ::= 64 4766 ub-serial-number INTEGER ::= 64 4767 ub-match INTEGER ::= 128 4768 ub-emailaddress-length INTEGER ::= 128 4769 ub-common-name-length INTEGER ::= 64 4770 ub-country-name-alpha-length INTEGER ::= 2 4771 ub-country-name-numeric-length INTEGER ::= 3 4772 ub-domain-defined-attributes INTEGER ::= 4 4773 ub-domain-defined-attribute-type-length INTEGER ::= 8 4774 ub-domain-defined-attribute-value-length INTEGER ::= 128 4775 ub-domain-name-length INTEGER ::= 16 4776 ub-extension-attributes INTEGER ::= 256 4777 ub-e163-4-number-length INTEGER ::= 15 4778 ub-e163-4-sub-address-length INTEGER ::= 40 4779 ub-generation-qualifier-length INTEGER ::= 3 4780 ub-given-name-length INTEGER ::= 16 4781 ub-initials-length INTEGER ::= 5 4782 ub-integer-options INTEGER ::= 256 4783 ub-numeric-user-id-length INTEGER ::= 32 4784 ub-organization-name-length INTEGER ::= 64 4785 ub-organizational-unit-name-length INTEGER ::= 32 4786 ub-organizational-units INTEGER ::= 4 4787 ub-pds-name-length INTEGER ::= 16 4788 ub-pds-parameter-length INTEGER ::= 30 4789 ub-pds-physical-address-lines INTEGER ::= 6 4790 ub-postal-code-length INTEGER ::= 16 4791 ub-pseudonym INTEGER ::= 128 4792 ub-surname-length INTEGER ::= 40 4793 ub-terminal-id-length INTEGER ::= 24 4794 ub-unformatted-address-length INTEGER ::= 180 4795 ub-x121-address-length INTEGER ::= 16 4797 -- Note - upper bounds on string types, such as TeletexString, are 4798 -- measured in characters. Excepting PrintableString or IA5String, a 4799 -- significantly greater number of octets will be required to hold 4800 -- such a value. As a minimum, 16 octets, or twice the specified upper 4801 -- bound, whichever is the larger, should be allowed for TeletexString. 4802 -- For UTF8String or UniversalString at least four times the upper 4803 -- bound should be allowed. 4805 END 4806 A.2 Implicitly Tagged Module, 1988 Syntax 4808 PKIX1Implicit88 { iso(1) identified-organization(3) dod(6) internet(1) 4809 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19) } 4811 DEFINITIONS IMPLICIT TAGS ::= 4813 BEGIN 4815 -- EXPORTS ALL -- 4817 IMPORTS 4818 id-pe, id-kp, id-qt-unotice, id-qt-cps, 4819 -- delete following line if "new" types are supported -- 4820 BMPString, UTF8String, -- end "new" types -- 4821 ORAddress, Name, RelativeDistinguishedName, 4822 CertificateSerialNumber, Attribute, DirectoryString 4823 FROM PKIX1Explicit88 { iso(1) identified-organization(3) 4824 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 4825 id-mod(0) id-pkix1-explicit(18) }; 4827 -- ISO arc for standard certificate and CRL extensions 4829 id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 4831 -- authority key identifier OID and syntax 4833 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 4835 AuthorityKeyIdentifier ::= SEQUENCE { 4836 keyIdentifier [0] KeyIdentifier OPTIONAL, 4837 authorityCertIssuer [1] GeneralNames OPTIONAL, 4838 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 4839 -- authorityCertIssuer and authorityCertSerialNumber MUST both 4840 -- be present or both be absent 4842 KeyIdentifier ::= OCTET STRING 4844 -- subject key identifier OID and syntax 4846 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 4848 SubjectKeyIdentifier ::= KeyIdentifier 4850 -- key usage extension OID and syntax 4852 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 4853 KeyUsage ::= BIT STRING { 4854 digitalSignature (0), 4855 nonRepudiation (1), 4856 keyEncipherment (2), 4857 dataEncipherment (3), 4858 keyAgreement (4), 4859 keyCertSign (5), 4860 cRLSign (6), 4861 encipherOnly (7), 4862 decipherOnly (8) } 4864 -- private key usage period extension OID and syntax 4866 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 4868 PrivateKeyUsagePeriod ::= SEQUENCE { 4869 notBefore [0] GeneralizedTime OPTIONAL, 4870 notAfter [1] GeneralizedTime OPTIONAL } 4871 -- either notBefore or notAfter MUST be present 4873 -- certificate policies extension OID and syntax 4875 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 4877 anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 } 4879 CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 4881 PolicyInformation ::= SEQUENCE { 4882 policyIdentifier CertPolicyId, 4883 policyQualifiers SEQUENCE SIZE (1..MAX) OF 4884 PolicyQualifierInfo OPTIONAL } 4886 CertPolicyId ::= OBJECT IDENTIFIER 4888 PolicyQualifierInfo ::= SEQUENCE { 4889 policyQualifierId PolicyQualifierId, 4890 qualifier ANY DEFINED BY policyQualifierId } 4892 -- Implementations that recognize additional policy qualifiers MUST 4893 -- augment the following definition for PolicyQualifierId 4895 PolicyQualifierId ::= 4896 OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) 4898 -- CPS pointer qualifier 4900 CPSuri ::= IA5String 4901 -- user notice qualifier 4903 UserNotice ::= SEQUENCE { 4904 noticeRef NoticeReference OPTIONAL, 4905 explicitText DisplayText OPTIONAL} 4907 NoticeReference ::= SEQUENCE { 4908 organization DisplayText, 4909 noticeNumbers SEQUENCE OF INTEGER } 4911 DisplayText ::= CHOICE { 4912 ia5String IA5String (SIZE (1..200)), 4913 visibleString VisibleString (SIZE (1..200)), 4914 bmpString BMPString (SIZE (1..200)), 4915 utf8String UTF8String (SIZE (1..200)) } 4917 -- policy mapping extension OID and syntax 4919 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 4921 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 4922 issuerDomainPolicy CertPolicyId, 4923 subjectDomainPolicy CertPolicyId } 4925 -- subject alternative name extension OID and syntax 4927 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 4929 SubjectAltName ::= GeneralNames 4931 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 4933 GeneralName ::= CHOICE { 4934 otherName [0] AnotherName, 4935 rfc822Name [1] IA5String, 4936 dNSName [2] IA5String, 4937 x400Address [3] ORAddress, 4938 directoryName [4] Name, 4939 ediPartyName [5] EDIPartyName, 4940 uniformResourceIdentifier [6] IA5String, 4941 iPAddress [7] OCTET STRING, 4942 registeredID [8] OBJECT IDENTIFIER } 4944 -- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as 4945 -- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax 4947 AnotherName ::= SEQUENCE { 4948 type-id OBJECT IDENTIFIER, 4949 value [0] EXPLICIT ANY DEFINED BY type-id } 4951 EDIPartyName ::= SEQUENCE { 4952 nameAssigner [0] DirectoryString OPTIONAL, 4953 partyName [1] DirectoryString } 4955 -- issuer alternative name extension OID and syntax 4957 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 4959 IssuerAltName ::= GeneralNames 4961 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 4963 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 4965 -- basic constraints extension OID and syntax 4967 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 4969 BasicConstraints ::= SEQUENCE { 4970 cA BOOLEAN DEFAULT FALSE, 4971 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 4973 -- name constraints extension OID and syntax 4975 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 4977 NameConstraints ::= SEQUENCE { 4978 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 4979 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 4981 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 4983 GeneralSubtree ::= SEQUENCE { 4984 base GeneralName, 4985 minimum [0] BaseDistance DEFAULT 0, 4986 maximum [1] BaseDistance OPTIONAL } 4988 BaseDistance ::= INTEGER (0..MAX) 4990 -- policy constraints extension OID and syntax 4992 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } 4994 PolicyConstraints ::= SEQUENCE { 4995 requireExplicitPolicy [0] SkipCerts OPTIONAL, 4996 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 4998 SkipCerts ::= INTEGER (0..MAX) 5000 -- CRL distribution points extension OID and syntax 5002 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31} 5004 CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 5006 DistributionPoint ::= SEQUENCE { 5007 distributionPoint [0] DistributionPointName OPTIONAL, 5008 reasons [1] ReasonFlags OPTIONAL, 5009 cRLIssuer [2] GeneralNames OPTIONAL } 5011 DistributionPointName ::= CHOICE { 5012 fullName [0] GeneralNames, 5013 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 5015 ReasonFlags ::= BIT STRING { 5016 unused (0), 5017 keyCompromise (1), 5018 cACompromise (2), 5019 affiliationChanged (3), 5020 superseded (4), 5021 cessationOfOperation (5), 5022 certificateHold (6), 5023 privilegeWithdrawn (7), 5024 aACompromise (8) } 5026 -- extended key usage extension OID and syntax 5028 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 5030 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 5032 KeyPurposeId ::= OBJECT IDENTIFIER 5034 -- extended key purpose OIDs 5035 id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } 5036 id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } 5037 id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } 5038 id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } 5039 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 5040 id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 } 5042 -- inhibit any policy OID and syntax 5044 id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 } 5045 InhibitAnyPolicy ::= SkipCerts 5047 -- freshest (delta)CRL extension OID and syntax 5049 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } 5051 FreshestCRL ::= CRLDistributionPoints 5053 -- authority info access 5055 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 5057 AuthorityInfoAccessSyntax ::= 5058 SEQUENCE SIZE (1..MAX) OF AccessDescription 5060 AccessDescription ::= SEQUENCE { 5061 accessMethod OBJECT IDENTIFIER, 5062 accessLocation GeneralName } 5064 -- CRL number extension OID and syntax 5066 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 5068 CRLNumber ::= INTEGER (0..MAX) 5070 -- issuing distribution point extension OID and syntax 5072 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 5074 IssuingDistributionPoint ::= SEQUENCE { 5075 distributionPoint [0] DistributionPointName OPTIONAL, 5076 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 5077 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 5078 onlySomeReasons [3] ReasonFlags OPTIONAL, 5079 indirectCRL [4] BOOLEAN DEFAULT FALSE, 5080 onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE } 5082 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 5084 BaseCRLNumber ::= CRLNumber 5086 -- CRL reasons extension OID and syntax 5088 id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 } 5090 CRLReason ::= ENUMERATED { 5091 unspecified (0), 5092 keyCompromise (1), 5093 cACompromise (2), 5094 affiliationChanged (3), 5095 superseded (4), 5096 cessationOfOperation (5), 5097 certificateHold (6), 5098 removeFromCRL (8), 5099 privilegeWithdrawn (9), 5100 aACompromise (10) } 5102 -- certificate issuer CRL entry extension OID and syntax 5104 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } 5106 CertificateIssuer ::= GeneralNames 5108 -- hold instruction extension OID and syntax 5110 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 5112 HoldInstructionCode ::= OBJECT IDENTIFIER 5114 -- ANSI x9 holdinstructions 5116 -- ANSI x9 arc holdinstruction arc 5117 holdInstruction OBJECT IDENTIFIER ::= 5118 {joint-iso-itu-t(2) member-body(2) us(840) x9cm(10040) 2} 5120 -- ANSI X9 holdinstructions referenced by this standard 5121 id-holdinstruction-none OBJECT IDENTIFIER ::= 5122 {holdInstruction 1} -- deprecated 5123 id-holdinstruction-callissuer OBJECT IDENTIFIER ::= 5124 {holdInstruction 2} 5125 id-holdinstruction-reject OBJECT IDENTIFIER ::= 5126 {holdInstruction 3} 5128 -- invalidity date CRL entry extension OID and syntax 5130 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 5132 InvalidityDate ::= GeneralizedTime 5134 END 5135 Appendix B. ASN.1 Notes 5137 CAs MUST force the serialNumber to be a non-negative integer, that 5138 is, the sign bit in the DER encoding of the INTEGER value MUST be 5139 zero - this can be done by adding a leading (leftmost) `00'H octet if 5140 necessary. This removes a potential ambiguity in mapping between a 5141 string of octets and an integer value. 5143 As noted in section 4.1.2.2, serial numbers can be expected to 5144 contain long integers. Certificate users MUST be able to handle 5145 serialNumber values up to 20 octets in length. Conformant CAs MUST 5146 NOT use serialNumber values longer than 20 octets. 5148 The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 5149 constructs. A valid ASN.1 sequence will have zero or more entries. 5150 The SIZE (1..MAX) construct constrains the sequence to have at least 5151 one entry. MAX indicates the upper bound is unspecified. 5152 Implementations are free to choose an upper bound that suits their 5153 environment. 5155 The construct "positiveInt ::= INTEGER (0..MAX)" defines positiveInt 5156 as a subtype of INTEGER containing integers greater than or equal to 5157 zero. The upper bound is unspecified. Implementations are free to 5158 select an upper bound that suits their environment. 5160 The character string type PrintableString supports a very basic Latin 5161 character set: the lower case letters 'a' through 'z', upper case 5162 letters 'A' through 'Z', the digits '0' through '9', eleven special 5163 characters ' = ( ) + , - . / : ? and space. 5165 Implementers should note that the at sign ('@') and underscore ('_') 5166 characters are not supported by the ASN.1 type PrintableString. 5167 These characters often appear in internet addresses. Such addresses 5168 MUST be encoded using an ASN.1 type that supports them. They are 5169 usually encoded as IA5String in either the emailAddress attribute 5170 within a distinguished name or the rfc822Name field of GeneralName. 5171 Conforming implementations MUST NOT encode strings which include 5172 either the at sign or underscore character as PrintableString. 5174 The character string type TeletexString is a superset of 5175 PrintableString. TeletexString supports a fairly standard (ASCII- 5176 like) Latin character set, Latin characters with non-spacing accents 5177 and Japanese characters. 5179 Named bit lists are BIT STRINGs where the values have been assigned 5180 names. This specification makes use of named bit lists in the 5181 definitions for the key usage extension and CRL reasons field in the 5182 CRL distribution points and freshest CRL certificate extensions, and 5183 the issuing distribution point CRL extension. When DER encoding a 5184 named bit list, trailing zeroes MUST be omitted. That is, the 5185 encoded value ends with the last named bit that is set to one. 5187 The character string type UniversalString supports any of the 5188 characters allowed by ISO 10646-1 [ISO 10646]. ISO 10646-1 is the 5189 Universal multiple-octet coded Character Set (UCS). ISO 10646-1 5190 specifies the architecture and the "basic multilingual plane" - a 5191 large standard character set which includes all major world character 5192 standards. 5194 The character string type UTF8String was introduced in the 1997 5195 version of ASN.1, and UTF8String was added to the list of choices for 5196 DirectoryString in the 2001 version of X.520 [X.520]. UTF8String is 5197 a universal type and has been assigned tag number 12. The content of 5198 UTF8String was defined by RFC 2044 [RFC 2044] and updated in RFC 2279 5199 [RFC 2279]. 5201 In anticipation of these changes, and in conformance with IETF Best 5202 Practices codified in RFC 2277 [RFC 2277], IETF Policy on Character 5203 Sets and Languages, this document includes UTF8String as a choice in 5204 DirectoryString and the CPS qualifier extensions. 5206 Implementers should note that the DER encoding of the SET OF values 5207 requires ordering of the encodings of the values. In particular, 5208 this issue arises with respect to distinguished names. 5210 Implementers should note that the DER encoding of SET or SEQUENCE 5211 components whose value is the DEFAULT omit the component from the 5212 encoded certificate or CRL. For example, a BasicConstraints 5213 extension whose cA value is FALSE would omit the cA boolean from the 5214 encoded certificate. 5216 Object Identifiers (OIDs) are used throughout this specification to 5217 identify certificate policies, public key and signature algorithms, 5218 certificate extensions, etc. There is no maximum size for OIDs. 5219 This specification mandates support for OIDs which have arc elements 5220 with values that are less than 2^28, that is, they MUST be between 0 5221 and 268,435,455, inclusive. This allows each arc element to be 5222 represented within a single 32 bit word. Implementations MUST also 5223 support OIDs where the length of the dotted decimal (see [RFC 2252], 5224 section 4.1) string representation can be up to 100 bytes 5225 (inclusive). Implementations MUST be able to handle OIDs with up to 5226 20 elements (inclusive). CAs SHOULD NOT issue certificates which 5227 contain OIDs that exceed these requirements. 5229 Implementors are warned that the X.500 standards community has 5230 developed a series of extensibility rules. These rules determine 5231 when an ASN.1 definition can be changed without assigning a new 5232 object identifier (OID). For example, at least two extension 5233 definitions included in RFC 2459 [RFC 2459], the predecessor to this 5234 profile document, have different ASN.1 definitions in this 5235 specification, but the same OID is used. If unknown elements appear 5236 within an extension, and the extension is not marked critical, those 5237 unknown elements ought to be ignored, as follows: 5239 (a) ignore all unknown bit name assignments within a bit string; 5241 (b) ignore all unknown named numbers in an ENUMERATED type or 5242 INTEGER type that is being used in the enumerated style, provided 5243 the number occurs as an optional element of a SET or SEQUENCE; and 5245 (c) ignore all unknown elements in SETs, at the end of SEQUENCEs, 5246 or in CHOICEs where the CHOICE is itself an optional element of a 5247 SET or SEQUENCE. 5249 If an extension containing unexpected values is marked critical, the 5250 implementation MUST reject the certificate or CRL containing the 5251 unrecognized extension. 5253 Appendix C. Examples 5255 This section contains four examples: three certificates and a CRL. 5256 The first two certificates and the CRL comprise a minimal 5257 certification path. 5259 Section C.1 contains an annotated hex dump of a "self-signed" 5260 certificate issued by a CA whose distinguished name is 5261 cn=us,o=gov,ou=nist. The certificate contains a DSA public key with 5262 parameters, and is signed by the corresponding DSA private key. 5264 Section C.2 contains an annotated hex dump of an end entity 5265 certificate. The end entity certificate contains a DSA public key, 5266 and is signed by the private key corresponding to the "self-signed" 5267 certificate in section C.1. 5269 Section C.3 contains a dump of an end entity certificate which 5270 contains an RSA public key and is signed with RSA and MD5. This 5271 certificate is not part of the minimal certification path. 5273 Section C.4 contains an annotated hex dump of a CRL. The CRL is 5274 issued by the CA whose distinguished name is cn=us,o=gov,ou=nist and 5275 the list of revoked certificates includes the end entity certificate 5276 presented in C.2. 5278 The certificates were processed using Peter Gutman's dumpasn1 utility 5279 to generate the output. The source for the dumpasn1 utility is 5280 available at . The 5281 binaries for the certificates and CRLs are available at 5282 . 5284 C.1 Certificate 5286 This section contains an annotated hex dump of a 699 byte version 3 5287 certificate. The certificate contains the following information: 5288 (a) the serial number is 23 (17 hex); 5289 (b) the certificate is signed with DSA and the SHA-1 hash algorithm; 5290 (c) the issuer's distinguished name is OU=NIST; O=gov; C=US 5291 (d) and the subject's distinguished name is OU=NIST; O=gov; C=US 5292 (e) the certificate was issued on June 30, 1997 and will expire on 5293 December 31, 1997; 5294 (f) the certificate contains a 1024 bit DSA public key with 5295 parameters; 5296 (g) the certificate contains a subject key identifier extension 5297 generated using method (1) of section 4.2.1.2; and 5298 (h) the certificate is a CA certificate (as indicated through the 5299 basic constraints extension.) 5301 0 30 699: SEQUENCE { 5302 4 30 635: SEQUENCE { 5303 8 A0 3: [0] { 5304 10 02 1: INTEGER 2 5305 : } 5306 13 02 1: INTEGER 17 5307 16 30 9: SEQUENCE { 5308 18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5309 : } 5310 27 30 42: SEQUENCE { 5311 29 31 11: SET { 5312 31 30 9: SEQUENCE { 5313 33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5314 38 13 2: PrintableString 'US' 5315 : } 5316 : } 5317 42 31 12: SET { 5318 44 30 10: SEQUENCE { 5319 46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5320 51 13 3: PrintableString 'gov' 5321 : } 5322 : } 5323 56 31 13: SET { 5324 58 30 11: SEQUENCE { 5325 60 06 3: OBJECT IDENTIFIER 5326 : organizationalUnitName (2 5 4 11) 5328 65 13 4: PrintableString 'NIST' 5329 : } 5330 : } 5331 : } 5332 71 30 30: SEQUENCE { 5333 73 17 13: UTCTime '970630000000Z' 5334 88 17 13: UTCTime '971231000000Z' 5335 : } 5336 103 30 42: SEQUENCE { 5337 105 31 11: SET { 5338 107 30 9: SEQUENCE { 5339 109 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5340 114 13 2: PrintableString 'US' 5341 : } 5342 : } 5343 118 31 12: SET { 5344 120 30 10: SEQUENCE { 5345 122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5346 127 13 3: PrintableString 'gov' 5347 : } 5348 : } 5349 132 31 13: SET { 5350 134 30 11: SEQUENCE { 5351 136 06 3: OBJECT IDENTIFIER 5352 : organizationalUnitName (2 5 4 11) 5353 141 13 4: PrintableString 'NIST' 5354 : } 5355 : } 5356 : } 5357 147 30 440: SEQUENCE { 5358 151 30 300: SEQUENCE { 5359 155 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) 5360 164 30 287: SEQUENCE { 5361 168 02 129: INTEGER 5362 : 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC 5363 : FB 95 32 AC 01 12 33 B9 E0 1C AD 90 9B BC 5364 : 48 54 9E F3 94 77 3C 2C 71 35 55 E6 FE 4F 5365 : 22 CB D5 D8 3E 89 93 33 4D FC BD 4F 41 64 5366 : 3E A2 98 70 EC 31 B4 50 DE EB F1 98 28 0A 5367 : C9 3E 44 B3 FD 22 97 96 83 D0 18 A3 E3 BD 5368 : 35 5B FF EE A3 21 72 6A 7B 96 DA B9 3F 1E 5369 : 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A 5370 : FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48 5371 : 63 FE 43 5372 300 02 21: INTEGER 5373 : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA 5374 : 55 F7 7D 57 74 81 E5 5375 323 02 129: INTEGER 5376 : 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91 5377 : C0 8E 47 F1 0A C3 01 47 C2 44 42 36 A9 92 5378 : 81 DE 57 C5 E0 68 86 58 00 7B 1F F9 9B 77 5379 : A1 C5 10 A5 80 91 78 51 51 3C F6 FC FC CC 5380 : 46 C6 81 78 92 84 3D F4 93 3D 0C 38 7E 1A 5381 : 5B 99 4E AB 14 64 F6 0C 21 22 4E 28 08 9C 5382 : 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 39 A2 5383 : 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF 5384 : F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE 5385 : 1E 57 18 5386 : } 5387 : } 5388 455 03 133: BIT STRING 0 unused bits, encapsulates { 5389 459 02 129: INTEGER 5390 : 00 B5 9E 1F 49 04 47 D1 DB F5 3A DD CA 04 5391 : 75 E8 DD 75 F6 9B 8A B1 97 D6 59 69 82 D3 5392 : 03 4D FD 3B 36 5F 4A F2 D1 4E C1 07 F5 D1 5393 : 2A D3 78 77 63 56 EA 96 61 4D 42 0B 7A 1D 5394 : FB AB 91 A4 CE DE EF 77 C8 E5 EF 20 AE A6 5395 : 28 48 AF BE 69 C3 6A A5 30 F2 C2 B9 D9 82 5396 : 2B 7D D9 C4 84 1F DE 0D E8 54 D7 1B 99 2E 5397 : B3 D0 88 F6 D6 63 9B A7 E2 0E 82 D4 3B 8A 5398 : 68 1B 06 56 31 59 0B 49 EB 99 A5 D5 81 41 5399 : 7B C9 55 5400 : } 5401 : } 5402 591 A3 50: [3] { 5403 593 30 48: SEQUENCE { 5404 595 30 29: SEQUENCE { 5405 597 06 3: OBJECT IDENTIFIER 5406 : subjectKeyIdentifier (2 5 29 14) 5407 602 04 22: OCTET STRING, encapsulates { 5408 604 04 20: OCTET STRING 5409 : 86 CA A5 22 81 62 EF AD 0A 89 BC AD 72 41 5410 : 2C 29 49 F4 86 56 5411 : } 5412 : } 5413 626 30 15: SEQUENCE { 5414 628 06 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19) 5415 633 01 1: BOOLEAN TRUE 5416 636 04 5: OCTET STRING, encapsulates { 5417 638 30 3: SEQUENCE { 5418 640 01 1: BOOLEAN TRUE 5419 : } 5420 : } 5421 : } 5422 : } 5423 : } 5424 : } 5425 643 30 9: SEQUENCE { 5426 645 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5427 : } 5428 654 03 47: BIT STRING 0 unused bits, encapsulates { 5429 657 30 44: SEQUENCE { 5430 659 02 20: INTEGER 5431 : 43 1B CF 29 25 45 C0 4E 52 E7 7D D6 FC B1 5432 : 66 4C 83 CF 2D 77 5433 681 02 20: INTEGER 5434 : 0B 5B 9A 24 11 98 E8 F3 86 90 04 F6 08 A9 5435 : E1 8D A5 CC 3A D4 5436 : } 5437 : } 5438 : } 5440 C.2 Certificate 5442 This section contains an annotated hex dump of a 730 byte version 3 5443 certificate. The certificate contains the following information: 5444 (a the serial number is 18 (12 hex); 5445 (b) the certificate is signed with DSA and the SHA-1 hash algorithm; 5446 (c) the issuer's distinguished name is OU=nist; O=gov; C=US 5447 (d) and the subject's distinguished name is CN=Tim Polk; OU=nist; 5448 O=gov; C=US 5449 (e) the certificate was valid from July 30, 1997 through December 1, 5450 1997; 5451 (f) the certificate contains a 1024 bit DSA public key; 5452 (g) the certificate is an end entity certificate, as the basic 5453 constraints extension is not present; 5454 (h) the certificate contains an authority key identifier extension 5455 matching the subject key identifier of the certificate in Appendix 5456 C.1; and 5457 (i) the certificate includes one alternative name - an RFC 822 5458 address of "wpolk@nist.gov". 5460 0 30 730: SEQUENCE { 5461 4 30 665: SEQUENCE { 5462 8 A0 3: [0] { 5463 10 02 1: INTEGER 2 5464 : } 5465 13 02 1: INTEGER 18 5466 16 30 9: SEQUENCE { 5467 18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5468 : } 5469 27 30 42: SEQUENCE { 5470 29 31 11: SET { 5471 31 30 9: SEQUENCE { 5472 33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5473 38 13 2: PrintableString 'US' 5474 : } 5475 : } 5476 42 31 12: SET { 5477 44 30 10: SEQUENCE { 5478 46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5479 51 13 3: PrintableString 'gov' 5480 : } 5481 : } 5482 56 31 13: SET { 5483 58 30 11: SEQUENCE { 5484 60 06 3: OBJECT IDENTIFIER 5485 : organizationalUnitName (2 5 4 11) 5486 65 13 4: PrintableString 'NIST' 5487 : } 5488 : } 5489 : } 5490 71 30 30: SEQUENCE { 5491 73 17 13: UTCTime '970730000000Z' 5492 88 17 13: UTCTime '971201000000Z' 5493 : } 5494 103 30 61: SEQUENCE { 5495 105 31 11: SET { 5496 107 30 9: SEQUENCE { 5497 109 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5498 114 13 2: PrintableString 'US' 5499 : } 5500 : } 5501 118 31 12: SET { 5502 120 30 10: SEQUENCE { 5503 122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5504 127 13 3: PrintableString 'gov' 5505 : } 5506 : } 5507 132 31 13: SET { 5508 134 30 11: SEQUENCE { 5509 136 06 3: OBJECT IDENTIFIER 5510 : organizationalUnitName (2 5 4 11) 5511 141 13 4: PrintableString 'NIST' 5512 : } 5513 : } 5514 147 31 17: SET { 5515 149 30 15: SEQUENCE { 5516 151 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 5517 156 13 8: PrintableString 'Tim Polk' 5518 : } 5519 : } 5520 : } 5521 166 30 439: SEQUENCE { 5522 170 30 300: SEQUENCE { 5523 174 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) 5524 183 30 287: SEQUENCE { 5525 187 02 129: INTEGER 5526 : 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC 5527 : FB 95 32 AC 01 12 33 B9 E0 1C AD 90 9B BC 5528 : 48 54 9E F3 94 77 3C 2C 71 35 55 E6 FE 4F 5529 : 22 CB D5 D8 3E 89 93 33 4D FC BD 4F 41 64 5530 : 3E A2 98 70 EC 31 B4 50 DE EB F1 98 28 0A 5531 : C9 3E 44 B3 FD 22 97 96 83 D0 18 A3 E3 BD 5532 : 35 5B FF EE A3 21 72 6A 7B 96 DA B9 3F 1E 5533 : 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A 5534 : FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48 5535 : 63 FE 43 5536 319 02 21: INTEGER 5537 : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA 5538 : 55 F7 7D 57 74 81 E5 5539 342 02 129: INTEGER 5540 : 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91 5541 : C0 8E 47 F1 0A C3 01 47 C2 44 42 36 A9 92 5542 : 81 DE 57 C5 E0 68 86 58 00 7B 1F F9 9B 77 5543 : A1 C5 10 A5 80 91 78 51 51 3C F6 FC FC CC 5544 : 46 C6 81 78 92 84 3D F4 93 3D 0C 38 7E 1A 5545 : 5B 99 4E AB 14 64 F6 0C 21 22 4E 28 08 9C 5546 : 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 39 A2 5547 : 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF 5548 : F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE 5549 : 1E 57 18 5550 : } 5551 : } 5552 474 03 132: BIT STRING 0 unused bits, encapsulates { 5553 478 02 128: INTEGER 5554 : 30 B6 75 F7 7C 20 31 AE 38 BB 7E 0D 2B AB 5555 : A0 9C 4B DF 20 D5 24 13 3C CD 98 E5 5F 6C 5556 : B7 C1 BA 4A BA A9 95 80 53 F0 0D 72 DC 33 5557 : 37 F4 01 0B F5 04 1F 9D 2E 1F 62 D8 84 3A 5558 : 9B 25 09 5A 2D C8 46 8E 2B D4 F5 0D 3B C7 5559 : 2D C6 6C B9 98 C1 25 3A 44 4E 8E CA 95 61 5560 : 35 7C CE 15 31 5C 23 13 1E A2 05 D1 7A 24 5561 : 1C CB D3 72 09 90 FF 9B 9D 28 C0 A1 0A EC 5562 : 46 9F 0D B8 D0 DC D0 18 A6 2B 5E F9 8F B5 5563 : 95 BE 5564 : } 5565 : } 5566 609 A3 62: [3] { 5567 611 30 60: SEQUENCE { 5568 613 30 25: SEQUENCE { 5569 615 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 5570 620 04 18: OCTET STRING, encapsulates { 5571 622 30 16: SEQUENCE { 5572 624 81 14: [1] 'wpolk@nist.gov' 5573 : } 5574 : } 5575 : } 5576 640 30 31: SEQUENCE { 5577 642 06 3: OBJECT IDENTIFIER 5578 : authorityKeyIdentifier (2 5 29 35) 5579 647 04 24: OCTET STRING, encapsulates { 5580 649 30 22: SEQUENCE { 5581 651 80 20: [0] 5582 : 86 CA A5 22 81 62 EF AD 0A 89 BC AD 72 5583 : 41 2C 29 49 F4 86 56 5584 : } 5585 : } 5586 : } 5587 : } 5588 : } 5589 : } 5590 673 30 9: SEQUENCE { 5591 675 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5592 : } 5593 684 03 48: BIT STRING 0 unused bits, encapsulates { 5594 687 30 45: SEQUENCE { 5595 689 02 20: INTEGER 5596 : 36 97 CB E3 B4 2C E1 BB 61 A9 D3 CC 24 CC 5597 : 22 92 9F F4 F5 87 5598 711 02 21: INTEGER 5599 : 00 AB C9 79 AF D2 16 1C A9 E3 68 A9 14 10 5600 : B4 A0 2E FF 22 5A 73 5601 : } 5602 : } 5603 : } 5605 C.3 End Entity Certificate Using RSA 5607 This section contains an annotated hex dump of a 654 byte version 3 5608 certificate. The certificate contains the following information: 5609 (a) the serial number is 256; 5610 (b) the certificate is signed with RSA and the SHA-1 hash algorithm; 5611 (c) the issuer's distinguished name is OU=NIST; O=gov; C=US 5612 (d) and the subject's distinguished name is CN=Tim Polk; OU=NIST; 5613 O=gov; C=US 5614 (e) the certificate was issued on May 21, 1996 at 09:58:26 and 5615 expired on May 21, 1997 at 09:58:26; 5616 (f) the certificate contains a 1024 bit RSA public key; 5617 (g) the certificate is an end entity certificate (not a CA 5618 certificate); 5619 (h) the certificate includes an alternative subject name of 5620 "" and an 5621 alternative issuer name of "" - both are URLs; 5622 (i) the certificate include an authority key identifier extension 5623 and a certificate policies extension psecifying the policy OID 5624 2.16.840.1.101.3.2.1.48.9; and 5625 (j) the certificate includes a critical key usage extension 5626 specifying that the public key is intended for verification of 5627 digital signatures. 5629 0 30 654: SEQUENCE { 5630 4 30 503: SEQUENCE { 5631 8 A0 3: [0] { 5632 10 02 1: INTEGER 2 5633 : } 5634 13 02 2: INTEGER 256 5635 17 30 13: SEQUENCE { 5636 19 06 9: OBJECT IDENTIFIER 5637 : sha1withRSAEncryption (1 2 840 113549 1 1 5) 5638 30 05 0: NULL 5639 : } 5640 32 30 42: SEQUENCE { 5641 34 31 11: SET { 5642 36 30 9: SEQUENCE { 5643 38 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5644 43 13 2: PrintableString 'US' 5645 : } 5646 : } 5647 47 31 12: SET { 5648 49 30 10: SEQUENCE { 5649 51 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5650 56 13 3: PrintableString 'gov' 5651 : } 5652 : } 5653 61 31 13: SET { 5654 63 30 11: SEQUENCE { 5655 65 06 3: OBJECT IDENTIFIER 5656 : organizationalUnitName (2 5 4 11) 5657 70 13 4: PrintableString 'NIST' 5658 : } 5659 : } 5660 : } 5661 76 30 30: SEQUENCE { 5662 78 17 13: UTCTime '960521095826Z' 5663 93 17 13: UTCTime '970521095826Z' 5664 : } 5665 108 30 61: SEQUENCE { 5666 110 31 11: SET { 5667 112 30 9: SEQUENCE { 5668 114 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5669 119 13 2: PrintableString 'US' 5670 : } 5671 : } 5672 123 31 12: SET { 5673 125 30 10: SEQUENCE { 5674 127 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5675 132 13 3: PrintableString 'gov' 5676 : } 5677 : } 5678 137 31 13: SET { 5679 139 30 11: SEQUENCE { 5680 141 06 3: OBJECT IDENTIFIER 5681 : organizationalUnitName (2 5 4 11) 5682 146 13 4: PrintableString 'NIST' 5683 : } 5684 : } 5685 152 31 17: SET { 5686 154 30 15: SEQUENCE { 5687 156 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 5688 161 13 8: PrintableString 'Tim Polk' 5689 : } 5690 : } 5691 : } 5692 171 30 159: SEQUENCE { 5693 174 30 13: SEQUENCE { 5694 176 06 9: OBJECT IDENTIFIER 5695 : rsaEncryption (1 2 840 113549 1 1 1) 5696 187 05 0: NULL 5697 : } 5698 189 03 141: BIT STRING 0 unused bits, encapsulates { 5699 193 30 137: SEQUENCE { 5700 196 02 129: INTEGER 5701 : 00 E1 6A E4 03 30 97 02 3C F4 10 F3 B5 1E 5702 : 4D 7F 14 7B F6 F5 D0 78 E9 A4 8A F0 A3 75 5703 : EC ED B6 56 96 7F 88 99 85 9A F2 3E 68 77 5704 : 87 EB 9E D1 9F C0 B4 17 DC AB 89 23 A4 1D 5705 : 7E 16 23 4C 4F A8 4D F5 31 B8 7C AA E3 1A 5706 : 49 09 F4 4B 26 DB 27 67 30 82 12 01 4A E9 5707 : 1A B6 C1 0C 53 8B 6C FC 2F 7A 43 EC 33 36 5708 : 7E 32 B2 7B D5 AA CF 01 14 C6 12 EC 13 F2 5709 : 2D 14 7A 8B 21 58 14 13 4C 46 A3 9A F2 16 5710 : 95 FF 23 5711 328 02 3: INTEGER 65537 5712 : } 5713 : } 5714 : } 5715 333 A3 175: [3] { 5716 336 30 172: SEQUENCE { 5717 339 30 63: SEQUENCE { 5718 341 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 5719 346 04 56: OCTET STRING, encapsulates { 5720 348 30 54: SEQUENCE { 5721 350 86 52: [6] 5722 : 'http://www.itl.nist.gov/div893/staff/' 5723 : 'polk/index.html' 5724 : } 5725 : } 5726 : } 5727 404 30 31: SEQUENCE { 5728 406 06 3: OBJECT IDENTIFIER issuerAltName (2 5 29 18) 5729 411 04 24: OCTET STRING, encapsulates { 5730 413 30 22: SEQUENCE { 5731 415 86 20: [6] 'http://www.nist.gov/' 5732 : } 5733 : } 5734 : } 5735 437 30 31: SEQUENCE { 5736 439 06 3: OBJECT IDENTIFIER 5737 : authorityKeyIdentifier (2 5 29 35) 5738 444 04 24: OCTET STRING, encapsulates { 5739 446 30 22: SEQUENCE { 5740 448 80 20: [0] 5741 : 08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E 5742 : 70 6A 4A 20 84 2C 32 5743 : } 5744 : } 5745 : } 5746 470 30 23: SEQUENCE { 5747 472 06 3: OBJECT IDENTIFIER 5748 : certificatePolicies (2 5 29 32) 5749 477 04 16: OCTET STRING, encapsulates { 5750 479 30 14: SEQUENCE { 5751 481 30 12: SEQUENCE { 5752 483 06 10: OBJECT IDENTIFIER 5753 : '2 16 840 1 101 3 2 1 48 9' 5754 : } 5755 : } 5756 : } 5757 : } 5758 495 30 14: SEQUENCE { 5759 497 06 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) 5760 502 01 1: BOOLEAN TRUE 5761 505 04 4: OCTET STRING, encapsulates { 5762 507 03 2: BIT STRING 7 unused bits 5763 : '1'B (bit 0) 5764 : } 5765 : } 5766 : } 5767 : } 5768 : } 5769 511 30 13: SEQUENCE { 5770 513 06 9: OBJECT IDENTIFIER 5771 : sha1withRSAEncryption (1 2 840 113549 1 1 5) 5772 524 05 0: NULL 5773 : } 5774 526 03 129: BIT STRING 0 unused bits 5775 : 1E 07 77 6E 66 B5 B6 B8 57 F0 03 DC 6F 77 5776 : 6D AF 55 1D 74 E5 CE 36 81 FC 4B C5 F4 47 5777 : 82 C4 0A 25 AA 8D D6 7D 3A 89 AB 44 34 39 5778 : F6 BD 61 1A 78 85 7A B8 1E 92 A2 22 2F CE 5779 : 07 1A 08 8E F1 46 03 59 36 4A CB 60 E6 03 5780 : 40 01 5B 2A 44 D6 E4 7F EB 43 5E 74 0A E6 5781 : E4 F9 3E E1 44 BE 1F E7 5F 5B 2C 41 8D 08 5782 : BD 26 FE 6A A6 C3 2F B2 3B 41 12 6B C1 06 5783 : 8A B8 4C 91 59 EB 2F 38 20 2A 67 74 20 0B 5784 : 77 F3 5785 : } 5787 C.4 Certificate Revocation List 5789 This section contains an annotated hex dump of a version 2 CRL with 5790 one extension (cRLNumber). The CRL was issued by OU=NIST; O=gov; C=US 5791 on August 7, 1997; the next scheduled issuance was September 7, 1997. 5792 The CRL includes one revoked certificates: serial number 18 (12 hex), 5793 which was revoked on July 31, 1997 due to keyCompromise. The CRL 5794 itself is number 18, and it was signed with DSA and SHA-1. 5796 0 30 203: SEQUENCE { 5797 3 30 140: SEQUENCE { 5798 6 02 1: INTEGER 1 5799 9 30 9: SEQUENCE { 5800 11 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5801 : } 5802 20 30 42: SEQUENCE { 5803 22 31 11: SET { 5804 24 30 9: SEQUENCE { 5805 26 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5806 31 13 2: PrintableString 'US' 5807 : } 5808 : } 5809 35 31 12: SET { 5810 37 30 10: SEQUENCE { 5811 39 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5812 44 13 3: PrintableString 'gov' 5813 : } 5814 : } 5815 49 31 13: SET { 5816 51 30 11: SEQUENCE { 5817 53 06 3: OBJECT IDENTIFIER 5818 : organizationalUnitName (2 5 4 11) 5819 58 13 4: PrintableString 'NIST' 5820 : } 5821 : } 5822 : } 5823 64 17 13: UTCTime '970807000000Z' 5824 79 17 13: UTCTime '970907000000Z' 5825 94 30 34: SEQUENCE { 5826 96 30 32: SEQUENCE { 5827 98 02 1: INTEGER 18 5828 101 17 13: UTCTime '970731000000Z' 5829 116 30 12: SEQUENCE { 5830 118 30 10: SEQUENCE { 5831 120 06 3: OBJECT IDENTIFIER cRLReason (2 5 29 21) 5832 125 04 3: OCTET STRING, encapsulates { 5833 127 0A 1: ENUMERATED 1 5834 : } 5835 : } 5836 : } 5837 : } 5838 : } 5839 130 A0 14: [0] { 5840 132 30 12: SEQUENCE { 5841 134 30 10: SEQUENCE { 5842 136 06 3: OBJECT IDENTIFIER cRLNumber (2 5 29 20) 5843 141 04 3: OCTET STRING, encapsulates { 5844 143 02 1: INTEGER 12 5845 : } 5846 : } 5847 : } 5848 : } 5849 : } 5850 146 30 9: SEQUENCE { 5851 148 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5852 : } 5853 157 03 47: BIT STRING 0 unused bits, encapsulates { 5854 160 30 44: SEQUENCE { 5855 162 02 20: INTEGER 5856 : 22 4E 9F 43 BA 95 06 34 F2 BB 5E 65 DB A6 5857 : 80 05 C0 3A 29 47 5858 184 02 20: INTEGER 5859 : 59 1A 57 C9 82 D7 02 21 14 C3 D4 0B 32 1B 5860 : 96 16 B1 1F 46 5A 5861 : } 5862 : } 5863 : } 5865 Appendix D. Author Addresses: 5867 Russell Housley 5868 RSA Laboratories 5869 918 Spring Knoll Drive 5870 Herndon, VA 20170 5871 USA 5872 rhousley@rsasecurity.com 5874 Warwick Ford 5875 VeriSign, Inc. 5876 One Alewife Center 5877 Cambridge, MA 02140 5878 USA 5879 wford@verisign.com 5881 Tim Polk 5882 NIST 5883 Building 820, Room 426 5884 Gaithersburg, MD 20899 5885 USA 5886 wpolk@nist.gov 5888 David Solo 5889 Citigroup 5890 909 Third Ave, 16th Floor 5891 New York, NY 10043 5892 USA 5893 dsolo@alum.mit.edu 5895 Appendix E. Full Copyright Statement 5897 Copyright (C) The Internet Society (date). All Rights Reserved. 5899 This document and translations of it may be copied and furnished to 5900 others, and derivative works that comment on or otherwise explain it 5901 or assist in its implementation may be prepared, copied, published 5902 and distributed, in whole or in part, without restriction of any 5903 kind, provided that the above copyright notice and this paragraph are 5904 included on all such copies and derivative works. In addition, the 5905 ASN.1 modules presented in Appendix A may be used in whole or in part 5906 without inclusion of the copyright notice. However, this document 5907 itself may not be modified in any way, such as by removing the 5908 copyright notice or references to the Internet Society or other 5909 Internet organizations, except as needed for the purpose of 5910 developing Internet standards in which case the procedures for 5911 copyrights defined in the Internet Standards process shall be 5912 followed, or as required to translate it into languages other than 5913 English. 5915 The limited permissions granted above are perpetual and will not be 5916 revoked by the Internet Society or its successors or assigns. This 5917 document and the information contained herein is provided on an "AS 5918 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 5919 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 5920 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 5921 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 5922 OR FITNESS FOR A PARTICULAR PURPOSE.