idnits 2.17.00 (12 Aug 2021) /tmp/idnits35890/draft-ietf-pkix-new-part1-07.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 62 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 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 5 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 609 has weird spacing: '...issuing a cer...' == Line 620 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 (June 2001) is 7644 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 5665 -- Looks like a reference, but probably isn't: '1' on line 4986 -- Looks like a reference, but probably isn't: '2' on line 4987 -- Looks like a reference, but probably isn't: '3' on line 5561 == Missing Reference: 'ISO 8859-1' is mentioned on line 917, but not defined -- Looks like a reference, but probably isn't: '4' on line 4989 -- Looks like a reference, but probably isn't: '5' on line 4990 -- Looks like a reference, but probably isn't: '6' on line 4850 -- Looks like a reference, but probably isn't: '7' on line 4851 -- Looks like a reference, but probably isn't: '8' on line 4852 == Missing Reference: 'RFC1738' is mentioned on line 2698, but not defined ** Obsolete undefined reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) == Missing Reference: 'RFC1778' is mentioned on line 2698, but not defined ** Obsolete undefined reference: RFC 1778 (Obsoleted by RFC 3494) == Missing Reference: 'UNIVERSAL 28' is mentioned on line 4134, but not defined == Missing Reference: 'UNIVERSAL 30' is mentioned on line 4137, but not defined == Missing Reference: 'UNIVERSAL 12' is mentioned on line 4141, but not defined == Missing Reference: 'APPLICATION 1' is mentioned on line 4456, but not defined == Missing Reference: 'APPLICATION 2' is mentioned on line 4462, but not defined == Missing Reference: 'LDAP' is mentioned on line 5108, but not defined == Unused Reference: 'RFC 1423' is defined on line 3876, but no explicit reference was found in the text == Unused Reference: 'RFC 1778' is defined on line 3890, but no explicit reference was found in the text == Unused Reference: 'RFC 1883' is defined on line 3894, but no explicit reference was found in the text == Unused Reference: 'RFC 2119' is defined on line 3897, but no explicit reference was found in the text == Unused Reference: 'RFC 2277' is defined on line 3904, but no explicit reference was found in the text == Unused Reference: 'RFC 2279' is defined on line 3907, but no explicit reference was found in the text ** 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 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) == Outdated reference: draft-ietf-cat-kerberos-pk-init has been published as RFC 4556 == 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: 19 errors (**), 0 flaws (~~), 26 warnings (==), 12 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 June 2001 8 Internet X.509 Public Key Infrastructure 10 Certificate and CRL Profile 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 To view the entire list of current Internet-Drafts, please check the 34 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 35 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 36 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 37 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 39 Copyright (C) The Internet Society (2001). All Rights Reserved. 41 Abstract 43 This is the seventh draft of a specification based upon RFC 2459. 44 When complete, this specification will obsolete RFC 2459. This 45 specification includes minor edits and clarifications. The most 46 notable departures from RFC 2459 are found in Section 6, Path 47 Validation. In RFC 2459, the reader was expected to augment the path 48 validation algorithm, which concentrated upon policy processing, with 49 information embedded in other sections. For example, parameter 50 inheritance is discussed in Section 7, Algorithm Support, and can 51 certainly affect the validity of a certification path. However, 52 parameter inheritance was omitted from the path validation algorithm 53 in RFC 2459. In this document, the path validation algorithm has a 54 comprehensive and extremely detailed description. Details such as 55 parameter inheritance are covered thoroughly. In addition, this 56 document anticipates certain corrections proposed in the X.509 57 standard for the policy processing aspects of path validation. 59 A new section 6.3, CRL validation, has been added. This section 60 provides a supplement to the path validation algorithm that 61 determines whether a particular CRL may be used to verify the status 62 of a particular certificate. The basic certification path validation 63 algorithm is, by design, independent of the type and format of status 64 information. 66 Significant corrections have been made to the ASN.1 modules contained 67 in the appendices. 69 This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use 70 in the Internet. An overview of the approach and model are provided 71 as an introduction. The X.509 v3 certificate format is described in 72 detail, with additional information regarding the format and 73 semantics of Internet name forms (e.g., IP addresses). Standard 74 certificate extensions are described and one new Internet-specific 75 extension is defined. A required set of certificate extensions is 76 specified. The X.509 v2 CRL format is described, including a 77 required set of extensions. An algorithm for X.509 certification 78 path validation is described. Supplemental information describing 79 the format of public keys and digital signatures in X.509 80 certificates for common Internet public key algorithms. ASN.1 81 modules and examples are provided in the appendices. 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC 2119. 87 Please send comments on this document to the ietf-pkix@imc.org mail 88 list. 90 Table of Contents 92 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 6 93 2 Requirements and Assumptions . . . . . . . . . . . . . . . . . . 7 94 2.1 Communication and Topology . . . . . . . . . . . . . . . . . . 7 95 2.2 Acceptability Criteria . . . . . . . . . . . . . . . . . . . . 8 96 2.3 User Expectations . . . . . . . . . . . . . . . . . . . . . . . 8 97 2.4 Administrator Expectations . . . . . . . . . . . . . . . . . . 8 98 3 Overview of Approach . . . . . . . . . . . . . . . . . . . . . . 8 99 3.1 X.509 Version 3 Certificate . . . . . . . . . . . . . . . . . . 10 100 3.2 Certification Paths and Trust . . . . . . . . . . . . . . . . . 11 101 3.3 Revocation . . . . . . . . . . . . . . . . . . . . . . . . . . 13 102 3.4 Operational Protocols . . . . . . . . . . . . . . . . . . . . . 14 103 3.5 Management Protocols . . . . . . . . . . . . . . . . . . . . . 14 104 4 Certificate and Certificate Extensions Profile . . . . . . . . . 15 105 4.1 Basic Certificate Fields . . . . . . . . . . . . . . . . . . . 16 106 4.1.1 Certificate Fields . . . . . . . . . . . . . . . . . . . . . 17 107 4.1.1.1 tbsCertificate . . . . . . . . . . . . . . . . . . . . . . 17 108 4.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . . . . . 17 109 4.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . . . . . 18 110 4.1.2 TBSCertificate . . . . . . . . . . . . . . . . . . . . . . . 18 111 4.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . . . . . 18 112 4.1.2.2 Serial number . . . . . . . . . . . . . . . . . . . . . . . 19 113 4.1.2.3 Signature . . . . . . . . . . . . . . . . . . . . . . . . . 19 114 4.1.2.4 Issuer . . . . . . . . . . . . . . . . . . . . . . . . . . 19 115 4.1.2.5 Validity . . . . . . . . . . . . . . . . . . . . . . . . . 23 116 4.1.2.5.1 UTCTime . . . . . . . . . . . . . . . . . . . . . . . . . 23 117 4.1.2.5.2 GeneralizedTime . . . . . . . . . . . . . . . . . . . . . 23 118 4.1.2.6 Subject . . . . . . . . . . . . . . . . . . . . . . . . . . 24 119 4.1.2.7 Subject Public Key Info . . . . . . . . . . . . . . . . . . 25 120 4.1.2.8 Unique Identifiers . . . . . . . . . . . . . . . . . . . . 25 121 4.1.2.9 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 25 122 4.2 Certificate Extensions . . . . . . . . . . . . . . . . . . . . 25 123 4.2.1 Standard Extensions . . . . . . . . . . . . . . . . . . . . . 26 124 4.2.1.1 Authority Key Identifier . . . . . . . . . . . . . . . . . 27 125 4.2.1.2 Subject Key Identifier . . . . . . . . . . . . . . . . . . 27 126 4.2.1.3 Key Usage . . . . . . . . . . . . . . . . . . . . . . . . . 29 127 4.2.1.4 Private Key Usage Period . . . . . . . . . . . . . . . . . 30 128 4.2.1.5 Certificate Policies . . . . . . . . . . . . . . . . . . . 31 129 4.2.1.6 Policy Mappings . . . . . . . . . . . . . . . . . . . . . . 33 130 4.2.1.7 Subject Alternative Name . . . . . . . . . . . . . . . . . 34 131 4.2.1.8 Issuer Alternative Name . . . . . . . . . . . . . . . . . . 36 132 4.2.1.9 Subject Directory Attributes . . . . . . . . . . . . . . . 37 133 4.2.1.10 Basic Constraints . . . . . . . . . . . . . . . . . . . . 37 134 4.2.1.11 Name Constraints . . . . . . . . . . . . . . . . . . . . . 38 135 4.2.1.12 Policy Constraints . . . . . . . . . . . . . . . . . . . . 40 136 4.2.1.13 Extended key usage field . . . . . . . . . . . . . . . . . 41 137 4.2.1.14 CRL Distribution Points . . . . . . . . . . . . . . . . . 42 138 4.2.1.15 Inhibit Any-Policy . . . . . . . . . . . . . . . . . . . . 43 139 4.2.1.16 Freshest CRL . . . . . . . . . . . . . . . . . . . . . . . 43 140 4.2.2 Internet Certificate Extensions . . . . . . . . . . . . . . . 44 141 4.2.2.1 Authority Information Access . . . . . . . . . . . . . . . 44 142 4.2.2.2 Subject Information Access . . . . . . . . . . . . . . . . 45 143 5 CRL and CRL Extensions Profile . . . . . . . . . . . . . . . . . 47 144 5.1 CRL Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 47 145 5.1.1 CertificateList Fields . . . . . . . . . . . . . . . . . . . 48 146 5.1.1.1 tbsCertList . . . . . . . . . . . . . . . . . . . . . . . . 48 147 5.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . . . . . 49 148 5.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . . . . . 49 149 5.1.2 Certificate List "To Be Signed" . . . . . . . . . . . . . . . 49 150 5.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . . . . . 49 151 5.1.2.2 Signature . . . . . . . . . . . . . . . . . . . . . . . . . 49 152 5.1.2.3 Issuer Name . . . . . . . . . . . . . . . . . . . . . . . . 50 153 5.1.2.4 This Update . . . . . . . . . . . . . . . . . . . . . . . . 50 154 5.1.2.5 Next Update . . . . . . . . . . . . . . . . . . . . . . . . 50 155 5.1.2.6 Revoked Certificates . . . . . . . . . . . . . . . . . . . 51 156 5.1.2.7 Extensions . . . . . . . . . . . . . . . . . . . . . . . . 51 157 5.2 CRL Extensions . . . . . . . . . . . . . . . . . . . . . . . . 51 158 5.2.1 Authority Key Identifier . . . . . . . . . . . . . . . . . . 51 159 5.2.2 Issuer Alternative Name . . . . . . . . . . . . . . . . . . . 52 160 5.2.3 CRL Number . . . . . . . . . . . . . . . . . . . . . . . . . 52 161 5.2.4 Delta CRL Indicator . . . . . . . . . . . . . . . . . . . . . 52 162 5.2.5 Issuing Distribution Point . . . . . . . . . . . . . . . . . 54 163 5.2.6 Freshest CRL . . . . . . . . . . . . . . . . . . . . . . . . 55 164 5.3 CRL Entry Extensions . . . . . . . . . . . . . . . . . . . . . 55 165 5.3.1 Reason Code . . . . . . . . . . . . . . . . . . . . . . . . . 56 166 5.3.2 Hold Instruction Code . . . . . . . . . . . . . . . . . . . . 56 167 5.3.3 Invalidity Date . . . . . . . . . . . . . . . . . . . . . . . 57 168 5.3.4 Certificate Issuer . . . . . . . . . . . . . . . . . . . . . 57 169 6 Certificate Path Validation . . . . . . . . . . . . . . . . . . . 58 170 6.1 Basic Path Validation . . . . . . . . . . . . . . . . . . . . . 58 171 6.1.1 Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 172 6.1.2 Initialization . . . . . . . . . . . . . . . . . . . . . . . . 62 173 6.1.3 Basic Certificate Processing . . . . . . . . . . . . . . . . . 65 174 6.1.4 Preparation for Certificate i+1 . . . . . . . . . . . . . . . 70 175 6.1.5 Wrap-up procedure . . . . . . . . . . . . . . . . . . . . . . 73 176 6.1.6 Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 177 6.2 Extending Path Validation . . . . . . . . . . . . . . . . . . . 75 178 6.3 CRL Validation . . . . . . . . . . . . . . . . . . . . . . . . 75 179 6.3.1 Revocation Inputs . . . . . . . . . . . . . . . . . . . . . . 76 180 6.3.2 Initialization and Revocation State Variables . . . . . . . . 76 181 6.3.3 CRL Processing . . . . . . . . . . . . . . . . . . . . . . . 77 182 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 183 8 Intellectual Property Rights . . . . . . . . . . . . . . . . . . 81 184 9 Security Considerations . . . . . . . . . . . . . . . . . . . . . 81 185 Appendix A. ASN.1 Structures and OIDs . . . . . . . . . . . . . . . 85 186 A.1 Explicitly Tagged Module, 1988 Syntax . . . . . . . . . . . . . 85 187 A.2 Implicitly Tagged Module, 1988 Syntax . . . . . . . . . . . . . 98 188 Appendix B. ASN.1 Notes . . . . . . . . . . . . . . . . . . . . . . 105 189 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . . 106 190 C.1 Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . 107 191 C.2 Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . 110 192 C.3 End Entity Certificate Using RSA . . . . . . . . . . . . . . . 113 193 C.4 Certificate Revocation List . . . . . . . . . . . . . . . . . . 116 194 Appendix D. Author Addresses . . . . . . . . . . . . . . . . . . . 118 195 Appendix E. Full Copyright Statement . . . . . . . . . . . . . . . 118 196 1 Introduction 198 This specification is one part of a family of standards for the X.509 199 Public Key Infrastructure (PKI) for the Internet. This specification 200 is a standalone document; implementations of this standard may 201 proceed independent from the other parts. 203 This specification profiles the format and semantics of certificates 204 and certificate revocation lists for the Internet PKI. Procedures 205 are described for processing of certification paths in the Internet 206 environment. Encoding rules are provided for popular cryptographic 207 algorithms. Finally, ASN.1 modules are provided in the appendices 208 for all data structures defined or referenced. 210 The specification describes the requirements which inspire the 211 creation of this document and the assumptions which affect its scope 212 in Section 2. Section 3 presents an architectural model and 213 describes its relationship to previous IETF and ISO/IEC/ITU 214 standards. In particular, this document's relationship with the IETF 215 PEM specifications and the ISO/IEC/ITU X.509 documents are described. 217 The specification profiles the X.509 version 3 certificate in Section 218 4, and the X.509 version 2 certificate revocation list (CRL) in 219 Section 5. The profiles include the identification of ISO/IEC/ITU 220 and ANSI extensions which may be useful in the Internet PKI. The 221 profiles are presented in the 1988 Abstract Syntax Notation One 222 (ASN.1) rather than the 1997 ASN.1 syntax used in the ISO/IEC/ITU 223 standards. 225 This specification also includes path validation procedures in 226 Section 6. These procedures are based upon the ISO/IEC/ITU 227 definition, but the presentation assumes one or more self-signed 228 trusted CA certificates. Implementations are required to derive the 229 same results but are not required to use the specified procedures. 231 Procedures for identification and encoding of public key materials 232 and digital signatures are defined in [PKIXALGS]. Implementations of 233 this specification are not required to use any particular 234 cryptographic algorithms. However, conforming implementations which 235 use the algorithms identified in [PKIXALGS] MUST identify and encode 236 the public key materials and digital signatures as described in that 237 specification. 239 Finally, three appendices are provided to aid implementers. Appendix 240 A contains all ASN.1 structures defined or referenced within this 241 specification. As above, the material is presented in the 1988 242 ASN.1. Appendix B contains notes on less familiar features of the 243 ASN.1 notation used within this specification. Appendix C contains 244 examples of a conforming certificate and a conforming CRL. 246 2 Requirements and Assumptions 248 The goal of this specification is to develop a profile to facilitate 249 the use of X.509 certificates within Internet applications for those 250 communities wishing to make use of X.509 technology. Such 251 applications may include WWW, electronic mail, user authentication, 252 and IPsec. In order to relieve some of the obstacles to using X.509 253 certificates, this document defines a profile to promote the 254 development of certificate management systems; development of 255 application tools; and interoperability determined by policy. 257 Some communities will need to supplement, or possibly replace, this 258 profile in order to meet the requirements of specialized application 259 domains or environments with additional authorization, assurance, or 260 operational requirements. However, for basic applications, common 261 representations of frequently used attributes are defined so that 262 application developers can obtain necessary information without 263 regard to the issuer of a particular certificate or certificate 264 revocation list (CRL). 266 A certificate user should review the certificate policy generated by 267 the certification authority (CA) before relying on the authentication 268 or non-repudiation services associated with the public key in a 269 particular certificate. To this end, this standard does not 270 prescribe legally binding rules or duties. 272 As supplemental authorization and attribute management tools emerge, 273 such as attribute certificates, it may be appropriate to limit the 274 authenticated attributes that are included in a certificate. These 275 other management tools may provide more appropriate methods of 276 conveying many authenticated attributes. 278 2.1 Communication and Topology 280 The users of certificates will operate in a wide range of 281 environments with respect to their communication topology, especially 282 users of secure electronic mail. This profile supports users without 283 high bandwidth, real-time IP connectivity, or high connection 284 availability. In addition, the profile allows for the presence of 285 firewall or other filtered communication. 287 This profile does not assume the deployment of an X.500 Directory 288 system or a LDAP directory system. The profile does not prohibit the 289 use of an X.500 Directory or a LDAP directory; however, any means of 290 distributing certificates and certificate revocation lists (CRLs) may 291 be used. 293 2.2 Acceptability Criteria 295 The goal of the Internet Public Key Infrastructure (PKI) is to meet 296 the needs of deterministic, automated identification, authentication, 297 access control, and authorization functions. Support for these 298 services determines the attributes contained in the certificate as 299 well as the ancillary control information in the certificate such as 300 policy data and certification path constraints. 302 2.3 User Expectations 304 Users of the Internet PKI are people and processes who use client 305 software and are the subjects named in certificates. These uses 306 include readers and writers of electronic mail, the clients for WWW 307 browsers, WWW servers, and the key manager for IPsec within a router. 308 This profile recognizes the limitations of the platforms these users 309 employ and the limitations in sophistication and attentiveness of the 310 users themselves. This manifests itself in minimal user 311 configuration responsibility (e.g., trusted CA keys, rules), explicit 312 platform usage constraints within the certificate, certification path 313 constraints which shield the user from many malicious actions, and 314 applications which sensibly automate validation functions. 316 2.4 Administrator Expectations 318 As with user expectations, the Internet PKI profile is structured to 319 support the individuals who generally operate CAs. Providing 320 administrators with unbounded choices increases the chances that a 321 subtle CA administrator mistake will result in broad compromise. 322 Also, unbounded choices greatly complicate the software that process 323 and validate the certificates created by the CA. 325 3 Overview of Approach 327 Following is a simplified view of the architectural model assumed by 328 the PKIX specifications. 330 +---+ 331 | C | +------------+ 332 | e | <-------------------->| End entity | 333 | r | Operational +------------+ 334 | t | transactions ^ 335 | i | and management | Management 336 | f | transactions | transactions PKI 337 | i | | users 338 | c | v 339 | a | ======================= +--+------------+ ============== 340 | t | ^ ^ 341 | e | | | PKI 342 | | v | management 343 | & | +------+ | entities 344 | | <---------------------| RA |<----+ | 345 | C | Publish certificate +------+ | | 346 | R | | | 347 | L | | | 348 | | v v 349 | R | +------------+ 350 | e | <------------------------------| CA | 351 | p | Publish certificate +------------+ 352 | o | Publish CRL ^ ^ 353 | s | | | Management 354 | i | +------------+ | | transactions 355 | t | <--------------| CRL Issuer |<----+ | 356 | o | Publish CRL +------------+ v 357 | r | +------+ 358 | y | | CA | 359 +---+ +------+ 361 Figure 1 - PKI Entities 363 The components in this model are: 365 end entity: user of PKI certificates and/or end user system that 366 is the subject of a certificate; 367 CA: certification authority; 368 RA: registration authority, i.e., an optional system to 369 which a CA delegates certain management functions; 370 CRL issuer: an optional system to which a CA delegates the 371 publication of certificate revocation lists; 372 repository: a system or collection of distributed systems that 373 store certificates and CRLs and serves as a means of 374 distributing these certificates and CRLs to end 375 entities. 377 Note that an Attribute Authority (AA) might also choose to delegate 378 the publication of CRLs to a CRL issuer. 380 3.1 X.509 Version 3 Certificate 382 Users of a public key require confidence that the associated private 383 key is owned by the correct remote subject (person or system) with 384 which an encryption or digital signature mechanism will be used. 385 This confidence is obtained through the use of public key 386 certificates, which are data structures that bind public key values 387 to subjects. The binding is asserted by having a trusted CA 388 digitally sign each certificate. The CA may base this assertion upon 389 technical means (a.k.a., proof of possession through a challenge- 390 response protocol), presentation of the private key, or on an 391 assertion by the subject. A certificate has a limited valid lifetime 392 which is indicated in its signed contents. Because a certificate's 393 signature and timeliness can be independently checked by a 394 certificate-using client, certificates can be distributed via 395 untrusted communications and server systems, and can be cached in 396 unsecured storage in certificate-using systems. 398 ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8, which was 399 first published in 1988 as part of the X.500 Directory 400 recommendations, defines a standard certificate format [X.509]. The 401 certificate format in the 1988 standard is called the version 1 (v1) 402 format. When X.500 was revised in 1993, two more fields were added, 403 resulting in the version 2 (v2) format. 405 The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993, 406 include specifications for a public key infrastructure based on X.509 407 v1 certificates [RFC 1422]. The experience gained in attempts to 408 deploy RFC 1422 made it clear that the v1 and v2 certificate formats 409 are deficient in several respects. Most importantly, more fields 410 were needed to carry information which PEM design and implementation 411 experience has proven necessary. In response to these new 412 requirements, ISO/IEC/ITU and ANSI X9 developed the X.509 version 3 413 (v3) certificate format. The v3 format extends the v2 format by 414 adding provision for additional extension fields. Particular 415 extension field types may be specified in standards or may be defined 416 and registered by any organization or community. In June 1996, 417 standardization of the basic v3 format was completed [X.509]. 419 ISO/IEC/ITU and ANSI X9 have also developed standard extensions for 420 use in the v3 extensions field [X.509][X9.55]. These extensions can 421 convey such data as additional subject identification information, 422 key attribute information, policy information, and certification path 423 constraints. 425 However, the ISO/IEC/ITU and ANSI X9 standard extensions are very 426 broad in their applicability. In order to develop interoperable 427 implementations of X.509 v3 systems for Internet use, it is necessary 428 to specify a profile for use of the X.509 v3 extensions tailored for 429 the Internet. It is one goal of this document to specify a profile 430 for Internet WWW, electronic mail, and IPsec applications. 431 Environments with additional requirements may build on this profile 432 or may replace it. 434 3.2 Certification Paths and Trust 436 A user of a security service requiring knowledge of a public key 437 generally needs to obtain and validate a certificate containing the 438 required public key. If the public-key user does not already hold an 439 assured copy of the public key of the CA that signed the certificate, 440 the CA's name, and related information (such as the validity period 441 or name constraints), then it might need an additional certificate to 442 obtain that public key. In general, a chain of multiple certificates 443 may be needed, comprising a certificate of the public key owner (the 444 end entity) signed by one CA, and zero or more additional 445 certificates of CAs signed by other CAs. Such chains, called 446 certification paths, are required because a public key user is only 447 initialized with a limited number of assured CA public keys. 449 There are different ways in which CAs might be configured in order 450 for public key users to be able to find certification paths. For 451 PEM, RFC 1422 defined a rigid hierarchical structure of CAs. There 452 are three types of PEM certification authority: 454 (a) Internet Policy Registration Authority (IPRA): This 455 authority, operated under the auspices of the Internet Society, 456 acts as the root of the PEM certification hierarchy at level 1. 457 It issues certificates only for the next level of authorities, 458 PCAs. All certification paths start with the IPRA. 460 (b) Policy Certification Authorities (PCAs): PCAs are at level 2 461 of the hierarchy, each PCA being certified by the IPRA. A PCA 462 shall establish and publish a statement of its policy with respect 463 to certifying users or subordinate certification authorities. 464 Distinct PCAs aim to satisfy different user needs. For example, 465 one PCA (an organizational PCA) might support the general 466 electronic mail needs of commercial organizations, and another PCA 467 (a high-assurance PCA) might have a more stringent policy designed 468 for satisfying legally binding digital signature requirements. 470 (c) Certification Authorities (CAs): CAs are at level 3 of the 471 hierarchy and can also be at lower levels. Those at level 3 are 472 certified by PCAs. CAs represent, for example, particular 473 organizations, particular organizational units (e.g., departments, 474 groups, sections), or particular geographical areas. 476 RFC 1422 furthermore has a name subordination rule which requires 477 that a CA can only issue certificates for entities whose names are 478 subordinate (in the X.500 naming tree) to the name of the CA itself. 479 The trust associated with a PEM certification path is implied by the 480 PCA name. The name subordination rule ensures that CAs below the PCA 481 are sensibly constrained as to the set of subordinate entities they 482 can certify (e.g., a CA for an organization can only certify entities 483 in that organization's name tree). Certificate user systems are able 484 to mechanically check that the name subordination rule has been 485 followed. 487 The RFC 1422 uses the X.509 v1 certificate formats. The limitations 488 of X.509 v1 required imposition of several structural restrictions to 489 clearly associate policy information or restrict the utility of 490 certificates. These restrictions included: 492 (a) a pure top-down hierarchy, with all certification paths 493 starting from IPRA; 495 (b) a naming subordination rule restricting the names of a CA's 496 subjects; and 498 (c) use of the PCA concept, which requires knowledge of individual 499 PCAs to be built into certificate chain verification logic. 500 Knowledge of individual PCAs was required to determine if a chain 501 could be accepted. 503 With X.509 v3, most of the requirements addressed by RFC 1422 can be 504 addressed using certificate extensions, without a need to restrict 505 the CA structures used. In particular, the certificate extensions 506 relating to certificate policies obviate the need for PCAs and the 507 constraint extensions obviate the need for the name subordination 508 rule. As a result, this document supports a more flexible 509 architecture, including: 511 (a) Certification paths start with a public key of a CA in a 512 user's own domain, or with the public key of the top of a 513 hierarchy. Starting with the public key of a CA in a user's own 514 domain has certain advantages. In some environments, the local 515 domain is the most trusted. 517 (b) Name constraints may be imposed through explicit inclusion of 518 a name constraints extension in a certificate, but are not 519 required. 521 (c) Policy extensions and policy mappings replace the PCA concept, 522 which permits a greater degree of automation. The application can 523 determine if the certification path is acceptable based on the 524 contents of the certificates instead of a priori knowledge of 525 PCAs. This permits automation of certificate chain processing. 527 3.3 Revocation 529 When a certificate is issued, it is expected to be in use for its 530 entire validity period. However, various circumstances may cause a 531 certificate to become invalid prior to the expiration of the validity 532 period. Such circumstances include change of name, change of 533 association between subject and CA (e.g., an employee terminates 534 employment with an organization), and compromise or suspected 535 compromise of the corresponding private key. Under such 536 circumstances, the CA needs to revoke the certificate. 538 X.509 defines one method of certificate revocation. This method 539 involves each CA periodically issuing a signed data structure called 540 a certificate revocation list (CRL). A CRL is a time stamped list 541 identifying revoked certificates which is signed by a CA and made 542 freely available in a public repository. Each revoked certificate is 543 identified in a CRL by its certificate serial number. When a 544 certificate-using system uses a certificate (e.g., for verifying a 545 remote user's digital signature), that system not only checks the 546 certificate signature and validity but also acquires a suitably- 547 recent CRL and checks that the certificate serial number is not on 548 that CRL. The meaning of "suitably-recent" may vary with local 549 policy, but it usually means the most recently-issued CRL. A CA 550 issues a new CRL on a regular periodic basis (e.g., hourly, daily, or 551 weekly). An entry is added to the CRL as part of the next update 552 following notification of revocation. An entry may be removed from 553 the CRL after appearing on one regularly scheduled CRL issued beyond 554 the revoked certificate's validity period. 556 An advantage of this revocation method is that CRLs may be 557 distributed by exactly the same means as certificates themselves, 558 namely, via untrusted servers and untrusted communications. 560 One limitation of the CRL revocation method, using untrusted 561 communications and servers, is that the time granularity of 562 revocation is limited to the CRL issue period. For example, if a 563 revocation is reported now, that revocation will not be reliably 564 notified to certificate-using systems until all currently issued CRLs 565 are updated -- this may be up to one hour, one day, or one week 566 depending on the frequency that CRLs are issued. 568 As with the X.509 v3 certificate format, in order to facilitate 569 interoperable implementations from multiple vendors, the X.509 v2 CRL 570 format needs to be profiled for Internet use. It is one goal of this 571 document to specify that profile. However, this profile does not 572 require CAs to issue CRLs. Message formats and protocols supporting 573 on-line revocation notification are defined in other PKIX 574 specifications. On-line methods of revocation notification may be 575 applicable in some environments as an alternative to the X.509 CRL. 576 On-line revocation checking may significantly reduce the latency 577 between a revocation report and the distribution of the information 578 to relying parties. Once the CA accepts the report as authentic and 579 valid, any query to the on-line service will correctly reflect the 580 certificate validation impacts of the revocation. However, these 581 methods impose new security requirements: the certificate validator 582 needs to trust the on-line validation service while the repository 583 does not need to be trusted. 585 3.4 Operational Protocols 587 Operational protocols are required to deliver certificates and CRLs 588 (or status information) to certificate using client systems. 589 Provision is needed for a variety of different means of certificate 590 and CRL delivery, including distribution procedures based on LDAP, 591 HTTP, FTP, and X.500. Operational protocols supporting these 592 functions are defined in other PKIX specifications. These 593 specifications may include definitions of message formats and 594 procedures for supporting all of the above operational environments, 595 including definitions of or references to appropriate MIME content 596 types. 598 3.5 Management Protocols 600 Management protocols are required to support on-line interactions 601 between PKI user and management entities. For example, a management 602 protocol might be used between a CA and a client system with which a 603 key pair is associated, or between two CAs which cross-certify each 604 other. The set of functions which potentially need to be supported 605 by management protocols include: 607 (a) registration: This is the process whereby a user first makes 608 itself known to a CA (directly, or through an RA), prior to that 609 CA issuing a certificate or certificates for that user. 611 (b) initialization: Before a client system can operate securely 612 it is necessary to install key materials which have the 613 appropriate relationship with keys stored elsewhere in the 614 infrastructure. For example, the client needs to be securely 615 initialized with the public key and other assured information of 616 the trusted CA(s), to be used in validating certificate paths. 617 Furthermore, a client typically needs to be initialized with its 618 own key pair(s). 620 (c) certification: This is the process in which a CA issues a 621 certificate for a user's public key, and returns that certificate 622 to the user's client system and/or posts that certificate in a 623 repository. 625 (d) key pair recovery: As an option, user client key materials 626 (e.g., a user's private key used for encryption purposes) may be 627 backed up by a CA or a key backup system. If a user needs to 628 recover these backed up key materials (e.g., as a result of a 629 forgotten password or a lost key chain file), an on-line protocol 630 exchange may be needed to support such recovery. 632 (e) key pair update: All key pairs need to be updated regularly, 633 i.e., replaced with a new key pair, and new certificates issued. 635 (f) revocation request: An authorized person advises a CA of an 636 abnormal situation requiring certificate revocation. 638 (g) cross-certification: Two CAs exchange information used in 639 establishing a cross-certificate. A cross-certificate is a 640 certificate issued by one CA to another CA which contains a CA 641 signature key used for issuing certificates. 643 Note that on-line protocols are not the only way of implementing the 644 above functions. For all functions there are off-line methods of 645 achieving the same result, and this specification does not mandate 646 use of on-line protocols. For example, when hardware tokens are 647 used, many of the functions may be achieved as part of the physical 648 token delivery. Furthermore, some of the above functions may be 649 combined into one protocol exchange. In particular, two or more of 650 the registration, initialization, and certification functions can be 651 combined into one protocol exchange. 653 The PKIX series of specifications defines a set of standard message 654 formats supporting the above functions. The protocols for conveying 655 these messages in different environments (e.g., e-mail, file 656 transfer, and WWW) are described in those specifications. 658 4 Certificate and Certificate Extensions Profile 660 This section presents a profile for public key certificates that will 661 foster interoperability and a reusable PKI. This section is based 662 upon the X.509 v3 certificate format and the standard certificate 663 extensions defined in [X.509]. The ISO/IEC/ITU documents use the 664 1997 version of ASN.1; while this document uses the 1988 ASN.1 665 syntax, the encoded certificate and standard extensions are 666 equivalent. This section also defines private extensions required to 667 support a PKI for the Internet community. 669 Certificates may be used in a wide range of applications and 670 environments covering a broad spectrum of interoperability goals and 671 a broader spectrum of operational and assurance requirements. The 672 goal of this document is to establish a common baseline for generic 673 applications requiring broad interoperability and limited special 674 purpose requirements. In particular, the emphasis will be on 675 supporting the use of X.509 v3 certificates for informal Internet 676 electronic mail, IPsec, and WWW applications. 678 4.1 Basic Certificate Fields 680 The X.509 v3 certificate basic syntax is as follows. For signature 681 calculation, the certificate is encoded using the ASN.1 distinguished 682 encoding rules (DER) [X.208]. ASN.1 DER encoding is a tag, length, 683 value encoding system for each element. 685 Certificate ::= SEQUENCE { 686 tbsCertificate TBSCertificate, 687 signatureAlgorithm AlgorithmIdentifier, 688 signatureValue BIT STRING } 690 TBSCertificate ::= SEQUENCE { 691 version [0] EXPLICIT Version DEFAULT v1, 692 serialNumber CertificateSerialNumber, 693 signature AlgorithmIdentifier, 694 issuer Name, 695 validity Validity, 696 subject Name, 697 subjectPublicKeyInfo SubjectPublicKeyInfo, 698 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 699 -- If present, version MUST be v2 or v3 700 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 701 -- If present, version MUST be v2 or v3 702 extensions [3] EXPLICIT Extensions OPTIONAL 703 -- If present, version MUST be v3 704 } 706 Version ::= INTEGER { v1(0), v2(1), v3(2) } 708 CertificateSerialNumber ::= INTEGER 710 Validity ::= SEQUENCE { 711 notBefore Time, 712 notAfter Time } 714 Time ::= CHOICE { 715 utcTime UTCTime, 716 generalTime GeneralizedTime } 718 UniqueIdentifier ::= BIT STRING 720 SubjectPublicKeyInfo ::= SEQUENCE { 721 algorithm AlgorithmIdentifier, 722 subjectPublicKey BIT STRING } 724 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 726 Extension ::= SEQUENCE { 727 extnID OBJECT IDENTIFIER, 728 critical BOOLEAN DEFAULT FALSE, 729 extnValue OCTET STRING } 731 The following items describe the X.509 v3 certificate for use in the 732 Internet. 734 4.1.1 Certificate Fields 736 The Certificate is a SEQUENCE of three required fields. The fields 737 are described in detail in the following subsections. 739 4.1.1.1 tbsCertificate 741 The field contains the names of the subject and issuer, a public key 742 associated with the subject, a validity period, and other associated 743 information. The fields are described in detail in section 4.1.2; 744 the tbsCertificate MAY also include extensions which are described in 745 section 4.2. 747 4.1.1.2 signatureAlgorithm 749 The signatureAlgorithm field contains the identifier for the 750 cryptographic algorithm used by the CA to sign this certificate. 751 [PKIXALGS] lists supported signature algorithms, but other signature 752 algorithms MAY also be supported. 754 An algorithm identifier is defined by the following ASN.1 structure: 756 AlgorithmIdentifier ::= SEQUENCE { 757 algorithm OBJECT IDENTIFIER, 758 parameters ANY DEFINED BY algorithm OPTIONAL } 760 The algorithm identifier is used to identify a cryptographic 761 algorithm. The OBJECT IDENTIFIER component identifies the algorithm 762 (such as DSA with SHA-1). The contents of the optional parameters 763 field will vary according to the algorithm identified. [PKIXALGS] 764 lists supported algorithms, but other algorithms MAY also be 765 implemented. 767 This field MUST contain the same algorithm identifier as the 768 signature field in the sequence tbsCertificate (section 4.1.2.3). 770 4.1.1.3 signatureValue 772 The signatureValue field contains a digital signature computed upon 773 the ASN.1 DER encoded tbsCertificate. The ASN.1 DER encoded 774 tbsCertificate is used as the input to the signature function. This 775 signature value is then ASN.1 encoded as a BIT STRING and included in 776 the signature field. The details of this process are specified for 777 each of algorithms listed in [PKIXALGS]. 779 By generating this signature, a CA certifies the validity of the 780 information in the tbsCertificate field. In particular, the CA 781 certifies the binding between the public key material and the subject 782 of the certificate. 784 4.1.2 TBSCertificate 786 The sequence TBSCertificate contains information associated with the 787 subject of the certificate and the CA who issued it. Every 788 TBSCertificate contains the names of the subject and issuer, a public 789 key associated with the subject, a validity period, a version number, 790 and a serial number; some MAY contain optional unique identifier 791 fields. The remainder of this section describes the syntax and 792 semantics of these fields. A TBSCertificate MAY also include 793 extensions. Extensions for the Internet PKI are described in Section 794 4.2. 796 4.1.2.1 Version 798 This field describes the version of the encoded certificate. When 799 extensions are used, as expected in this profile, use X.509 version 3 800 (value is 2). If no extensions are present, but a UniqueIdentifier 801 is present, use version 2 (value is 1). If only basic fields are 802 present, use version 1 (the value is omitted from the certificate as 803 the default value). 805 Implementations SHOULD be prepared to accept any version certificate. 806 At a minimum, conforming implementations MUST recognize version 3 807 certificates. 809 Generation of version 2 certificates is not expected by 810 implementations based on this profile. 812 4.1.2.2 Serial number 814 The serial number MUST be a positive integer assigned by the CA to 815 each certificate. It MUST be unique for each certificate issued by a 816 given CA (i.e., the issuer name and serial number identify a unique 817 certificate). CAs MUST force the serialNumber to be a non-negative 818 integer. 820 Given the uniqueness requirements above serial numbers can be 821 expected to contain long integers. Certificate users MUST be able to 822 handle serialNumber values up to 20 octets. Conformant CAs MUST NOT 823 use serialNumber values longer than 20 octets. 825 Note: Non-conforming CAs MAY issue certificates with serial numbers 826 that are negative, or zero. Certificate users SHOULD be prepared to 827 handle such certificates. 829 4.1.2.3 Signature 831 This field contains the algorithm identifier for the algorithm used 832 by the CA to sign the certificate. 834 This field MUST contain the same algorithm identifier as the 835 signatureAlgorithm field in the sequence Certificate (section 836 4.1.1.2). The contents of the optional parameters field will vary 837 according to the algorithm identified. [PKIXALGS] lists the 838 supported signature algorithms. 840 4.1.2.4 Issuer 842 The issuer field identifies the entity who has signed and issued the 843 certificate. The issuer field MUST contain a non-empty distinguished 844 name (DN). The issuer field is defined as the X.501 type Name 845 [X.501]. Name is defined by the following ASN.1 structures: 847 Name ::= CHOICE { 848 RDNSequence } 850 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 852 RelativeDistinguishedName ::= 853 SET OF AttributeTypeAndValue 855 AttributeTypeAndValue ::= SEQUENCE { 856 type AttributeType, 857 value AttributeValue } 859 AttributeType ::= OBJECT IDENTIFIER 861 AttributeValue ::= ANY DEFINED BY AttributeType 863 DirectoryString ::= CHOICE { 864 teletexString TeletexString (SIZE (1..MAX)), 865 printableString PrintableString (SIZE (1..MAX)), 866 universalString UniversalString (SIZE (1..MAX)), 867 utf8String UTF8String (SIZE (1..MAX)), 868 bmpString BMPString (SIZE (1..MAX)) } 870 The Name describes a hierarchical name composed of attributes, such 871 as country name, and corresponding values, such as US. The type of 872 the component AttributeValue is determined by the AttributeType; in 873 general it will be a DirectoryString. 875 The DirectoryString type is defined as a choice of PrintableString, 876 TeletexString, BMPString, UTF8String, and UniversalString. The 877 UTF8String encoding is the preferred encoding, and all certificates 878 issued after December 31, 2003 MUST use the UTF8String encoding of 879 DirectoryString (except as noted below). Until that date, conforming 880 CAs MUST choose from the following options when creating a 881 distinguished name, including their own: 883 (a) if the character set is sufficient, the string MAY be 884 represented as a PrintableString; 886 (b) failing (a), if the BMPString character set is sufficient the 887 string MAY be represented as a BMPString; and 889 (c) failing (a) and (b), the string MUST be represented as a 890 UTF8String. If (a) or (b) is satisfied, the CA MAY still choose 891 to represent the string as a UTF8String. 893 Exceptions to the December 31, 2003 UTF8 encoding requirements are as 894 follows: 896 (a) CAs MAY issue "name rollover" certificates to support an 897 orderly migration to UTF8String encoding. Such certificates would 898 include the CA's UTF8String encoded name as issuer and and the old 899 name encoding as subject, or vice-versa. 901 (b) As stated in section 4.1.2.6, the subject field MUST be 902 populated with a non-empty distinguished name matching the 903 contents of the issuer field in all certificates issued by the 904 subject CA regardless of encoding. 906 The TeletexString and UniversalString are included for backward 907 compatibility, and SHOULD NOT be used for certificates for new 908 subjects. However, these types MAY be used in certificates where the 909 name was previously established. Certificate users SHOULD be 910 prepared to receive certificates with these types. 912 In addition, many legacy implementations support names encoded in the 913 ISO 8859-1 character set (Latin1String) but tag them as 914 TeletexString. The Latin1String includes characters used in Western 915 European countries which are not part of the TeletexString charcter 916 set. Implementations that process TeletexString SHOULD be prepared 917 to handle the entire ISO 8859-1 character set.[ISO 8859-1] 919 As noted above, distinguished names are composed of attributes. This 920 specification does not restrict the set of attribute types that may 921 appear in names. However, conforming implementations MUST be 922 prepared to receive certificates with issuer names containing the set 923 of attribute types defined below. This specification RECOMMENDS 924 support for additional attribute types. 926 Standard sets of attributes have been defined in the X.500 series of 927 specifications.[X.520] Implementations of this specification MUST be 928 prepared to receive the following standard attribute types in issuer 929 and subject (section 4.1.2.6) names: 931 * country, 932 * organization, 933 * organizational-unit, 934 * distinguished name qualifier, 935 * state or province name, 936 * common name (e.g., "Susan Housley"), and 937 * serial number. 939 In addition, implementations of this specification SHOULD be prepared 940 to receive the following standard attribute types in issuer and 941 subject names: 943 * locality, 944 * title, 945 * surname, 946 * given name, 947 * initials, 948 * pseudonym, and 949 * generation qualifier (e.g., "Jr.", "3rd", or "IV"). 951 The syntax and associated object identifiers (OIDs) for these 952 attribute types are provided in the ASN.1 modules in Appendix A. 954 In addition, implementations of this specification MUST be prepared 955 to receive the domainComponent attribute, as defined in [RFC 2247]. 956 The Domain (Nameserver) System (DNS) provides a hierarchical resource 957 labeling system. This attribute provides is a convenient mechanism 958 for organizations that wish to use DNs that parallel their DNS names. 959 This is not a replacement for the dNSName component of the 960 alternative name field. Implementations are not required to convert 961 such names into DNS names. The syntax and associated OID for this 962 attribute type is provided in the ASN.1 modules in Appendix A. 964 Certificate users MUST be prepared to process the issuer 965 distinguished name and subject distinguished name (section 4.1.2.6) 966 fields to perform name chaining for certification path validation 967 (section 6). Name chaining is performed by matching the issuer 968 distinguished name in one certificate with the subject name in a CA 969 certificate. 971 This specification requires only a subset of the name comparison 972 functionality specified in the X.500 series of specifications. The 973 requirements for conforming implementations are as follows: 975 (a) attribute values encoded in different types (e.g., 976 PrintableString and BMPString) MAY be assumed to represent 977 different strings; 979 (b) attribute values in types other than PrintableString are case 980 sensitive (this permits matching of attribute values as binary 981 objects); 983 (c) attribute values in PrintableString are not case sensitive 984 (e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and 986 (d) attribute values in PrintableString are compared after 987 removing leading and trailing white space and converting internal 988 substrings of one or more consecutive white space characters to a 989 single space. 991 These name comparison rules permit a certificate user to validate 992 certificates issued using languages or encodings unfamiliar to the 993 certificate user. 995 In addition, implementations of this specification MAY use these 996 comparison rules to process unfamiliar attribute types for name 997 chaining. This allows implementations to process certificates with 998 unfamiliar attributes in the issuer name. 1000 Note that the comparison rules defined in the X.500 series of 1001 specifications indicate that the character sets used to encode data 1002 in distinguished names are irrelevant. The characters themselves are 1003 compared without regard to encoding. Implementations of the profile 1004 are permitted to use the comparison algorithm defined in the X.500 1005 series. Such an implementation will recognize a superset of name 1006 matches recognized by the algorithm specified above. 1008 4.1.2.5 Validity 1010 The certificate validity period is the time interval during which the 1011 CA warrants that it will maintain information about the status of the 1012 certificate. The field is represented as a SEQUENCE of two dates: 1013 the date on which the certificate validity period begins (notBefore) 1014 and the date on which the certificate validity period ends 1015 (notAfter). Both notBefore and notAfter may be encoded as UTCTime or 1016 GeneralizedTime. 1018 CAs conforming to this profile MUST always encode certificate 1019 validity dates through the year 2049 as UTCTime; certificate validity 1020 dates in 2050 or later MUST be encoded as GeneralizedTime. 1022 The validity period for a certificate is the period of time from 1023 notBefore through notAfter, inclusive. 1025 4.1.2.5.1 UTCTime 1027 The universal time type, UTCTime, is a standard ASN.1 type intended 1028 for representation of dates and time. UTCTime specifies the year 1029 through the two low order digits and time is specified to the 1030 precision of one minute or one second. UTCTime includes either Z 1031 (for Zulu, or Greenwich Mean Time) or a time differential. 1033 For the purposes of this profile, UTCTime values MUST be expressed 1034 Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are 1035 YYMMDDHHMMSSZ), even where the number of seconds is zero. Conforming 1036 systems MUST interpret the year field (YY) as follows: 1038 Where YY is greater than or equal to 50, the year SHALL be 1039 interpreted as 19YY; and 1041 Where YY is less than 50, the year SHALL be interpreted as 20YY. 1043 4.1.2.5.2 GeneralizedTime 1045 The generalized time type, GeneralizedTime, is a standard ASN.1 type 1046 for variable precision representation of time. Optionally, the 1047 GeneralizedTime field can include a representation of the time 1048 differential between local and Greenwich Mean Time. 1050 For the purposes of this profile, GeneralizedTime values MUST be 1051 expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e., 1052 times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. 1053 GeneralizedTime values MUST NOT include fractional seconds. 1055 4.1.2.6 Subject 1057 The subject field identifies the entity associated with the public 1058 key stored in the subject public key field. The subject name MAY be 1059 carried in the subject field and/or the subjectAltName extension. If 1060 the subject is a CA (e.g., the basic constraints extension, as 1061 discussed in 4.2.1.10, is present and the value of cA is TRUE,) then 1062 the subject field MUST be populated with a non-empty distinguished 1063 name matching the contents of the issuer field (section 4.1.2.4) in 1064 all certificates issued by the subject CA. If subject naming 1065 information is present only in the subjectAltName extension (e.g., a 1066 key bound only to an email address or URI), then the subject name 1067 MUST be an empty sequence and the subjectAltName extension MUST be 1068 critical. 1070 Where it is non-empty, the subject field MUST contain an X.500 1071 distinguished name (DN). The DN MUST be unique for each subject 1072 entity certified by the one CA as defined by the issuer name field. 1073 A CA MAY issue more than one certificate with the same DN to the same 1074 subject entity. 1076 The subject name field is defined as the X.501 type Name. 1077 Implementation requirements for this field are those defined for the 1078 issuer field (section 4.1.2.4). When encoding attribute values of 1079 type DirectoryString, the encoding rules for the issuer field MUST be 1080 implemented. Implementations of this specification MUST be prepared 1081 to receive subject names containing the attribute types required for 1082 the issuer field. Implementations of this specification SHOULD be 1083 prepared to receive subject names containing the recommended 1084 attribute types for the issuer field. The syntax and associated 1085 object identifiers (OIDs) for these attribute types are provided in 1086 the ASN.1 modules in Appendix A. Implementations of this 1087 specification MAY use these comparison rules to process unfamiliar 1088 attribute types (i.e., for name chaining). This allows 1089 implementations to process certificates with unfamiliar attributes in 1090 the subject name. 1092 In addition, legacy implementations exist where an RFC 822 name is 1093 embedded in the subject distinguished name as an EmailAddress 1094 attribute. The attribute value for EmailAddress is of type IA5String 1095 to permit inclusion of the character '@', which is not part of the 1096 PrintableString character set. EmailAddress attribute values are not 1097 case sensitive (e.g., "fanfeedback@redsox.com" is the same as 1098 "FANFEEDBACK@REDSOX.COM"). 1100 Conforming implementations generating new certificates with 1101 electronic mail addresses MUST use the rfc822Name in the subject 1102 alternative name field (section 4.2.1.7) to describe such identities. 1103 Simultaneous inclusion of the EmailAddress attribute in the subject 1104 distinguished name to support legacy implementations is deprecated 1105 but permitted. 1107 4.1.2.7 Subject Public Key Info 1109 This field is used to carry the public key and identify the algorithm 1110 with which the key is used. The algorithm is identified using the 1111 AlgorithmIdentifier structure specified in section 4.1.1.2. The 1112 object identifiers for the supported algorithms and the methods for 1113 encoding the public key materials (public key and parameters) are 1114 specified in [PKIXALGS]. 1116 4.1.2.8 Unique Identifiers 1118 These fields MUST only appear if the version is 2 or 3 (section 1119 4.1.2.1). These fields MUST NOT appear if the version is 1. The 1120 subject and issuer unique identifiers are present in the certificate 1121 to handle the possibility of reuse of subject and/or issuer names 1122 over time. This profile RECOMMENDS that names not be reused for 1123 different entities and that Internet certificates not make use of 1124 unique identifiers. CAs conforming to this profile SHOULD NOT 1125 generate certificates with unique identifiers. Applications 1126 conforming to this profile SHOULD be capable of parsing unique 1127 identifiers and making comparisons. 1129 4.1.2.9 Extensions 1131 This field MUST only appear if the version is 3 (section 4.1.2.1). 1132 If present, this field is a SEQUENCE of one or more certificate 1133 extensions. The format and content of certificate extensions in the 1134 Internet PKI is defined in section 4.2. 1136 4.2 Standard Certificate Extensions 1138 The extensions defined for X.509 v3 certificates provide methods for 1139 associating additional attributes with users or public keys and for 1140 managing the certification hierarchy. The X.509 v3 certificate 1141 format also allows communities to define private extensions to carry 1142 information unique to those communities. Each extension in a 1143 certificate is designated as either critical or non-critical. A 1144 certificate using system MUST reject the certificate if it encounters 1145 a critical extension it does not recognize; however, a non-critical 1146 extension MAY be ignored if it is not recognized. The following 1147 sections present recommended extensions used within Internet 1148 certificates and standard locations for information. Communities MAY 1149 elect to use additional extensions; however, caution SHOULD be 1150 exercised in adopting any critical extensions in certificates which 1151 might prevent use in a general context. 1153 Each extension includes an OID and an ASN.1 structure. When an 1154 extension appears in a certificate, the OID appears as the field 1155 extnID and the corresponding ASN.1 encoded structure is the value of 1156 the octet string extnValue. Only one instance of a particular 1157 extension MUST appear in a particular certificate. For example, a 1158 certificate may contain only one authority key identifier extension 1159 (section 4.2.1.1). An extension includes the boolean critical, with 1160 a default value of FALSE. The text for each extension specifies the 1161 acceptable values for the critical field. 1163 Conforming CAs MUST support key identifiers (sections 4.2.1.1 and 1164 4.2.1.2), basic constraints (section 4.2.1.10), key usage (section 1165 4.2.1.3), and certificate policies (section 4.2.1.5) extensions. If 1166 the CA issues certificates with an empty sequence for the subject 1167 field, the CA MUST support the subject alternative name extension 1168 (section 4.2.1.7). Support for the remaining extensions is OPTIONAL. 1169 Conforming CAs MAY support extensions that are not identified within 1170 this specification; certificate issuers are cautioned that marking 1171 such extensions as critical may inhibit interoperability. 1173 At a minimum, applications conforming to this profile MUST recognize 1174 the following extensions: key usage (section 4.2.1.3), certificate 1175 policies (section 4.2.1.5), the subject alternative name (section 1176 4.2.1.7), basic constraints (section 4.2.1.10), name constraints 1177 (section 4.2.1.11), policy constraints (section 4.2.1.12), extended 1178 key usage (section 4.2.1.13), and inhibit any-policy (section 1179 4.2.1.15). 1181 In addition, applications conforming to this profile SHOULD recognize 1182 the authority and subject key identifier (sections 4.2.1.1 and 1183 4.2.1.2), and policy mapping (section 4.2.1.6) extensions. 1185 4.2.1 Standard Extensions 1187 This section identifies standard certificate extensions defined in 1188 [X.509] for use in the Internet PKI. Each extension is associated 1189 with an OID defined in [X.509]. These OIDs are members of the id-ce 1190 arc, which is defined by the following: 1192 id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 1194 4.2.1.1 Authority Key Identifier 1196 The authority key identifier extension provides a means of 1197 identifying the public key corresponding to the private key used to 1198 sign a certificate. This extension is used where an issuer has 1199 multiple signing keys (either due to multiple concurrent key pairs or 1200 due to changeover). The identification MAY be based on either the 1201 key identifier (the subject key identifier in the issuer's 1202 certificate) or on the issuer name and serial number. 1204 The keyIdentifier field of the authorityKeyIdentifier extension MUST 1205 be included in all certificates generated by conforming CAs to 1206 facilitate chain building. There is one exception; where a CA 1207 distributes its public key in the form of a "self-signed" 1208 certificate, the authority key identifier MAY be omitted. In this 1209 case, the subject and authority key identifiers would be identical. 1211 The value of the keyIdentifier field SHOULD be derived from the 1212 public key used to verify the certificate's signature or a method 1213 that generates unique values. Two common methods for generating key 1214 identifiers from the public key are described in (sec. 4.2.1.2). One 1215 common method for generating unique values is described in (sec. 1216 4.2.1.2). Where a key identifier has not been previously 1217 established, this specification recommends use of one of these 1218 methods for generating keyIdentifiers. 1220 This profile recommends support for the key identifier method by all 1221 certificate users. 1223 This extension MUST NOT be marked critical. 1225 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 1227 AuthorityKeyIdentifier ::= SEQUENCE { 1228 keyIdentifier [0] KeyIdentifier OPTIONAL, 1229 authorityCertIssuer [1] GeneralNames OPTIONAL, 1230 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 1232 KeyIdentifier ::= OCTET STRING 1234 4.2.1.2 Subject Key Identifier 1236 The subject key identifier extension provides a means of identifying 1237 certificates that contain a particular public key. 1239 To facilitate chain building, this extension MUST appear in all 1240 conforming CA certificates, that is, all certificates including the 1241 basic constraints extension (section 4.2.1.10) where the value of cA 1242 is TRUE. The value of the subject key identifier MUST be the value 1243 placed in the key identifier field of the Authority Key Identifier 1244 extension (section 4.2.1.1) of certificates issued by the subject of 1245 this certificate. 1247 For CA certificates, subject key identifiers SHOULD be derived from 1248 the public key or a method that generates unique values. The key 1249 identifier is an explicit value placed in the certificate by the 1250 issuer, not a value generated by a certificate user. Two common 1251 methods for generating key identifiers from the public key are: 1253 (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the 1254 value of the BIT STRING subjectPublicKey (excluding the tag, 1255 length, and number of unused bits). 1257 (2) The keyIdentifier is composed of a four bit type field with 1258 the value 0100 followed by the least significant 60 bits of the 1259 SHA-1 hash of the value of the BIT STRING subjectPublicKey. 1261 One common method for generating unique values is a monotonically 1262 increasing sequence of integers. 1264 For end entity certificates, the subject key identifier extension 1265 provides a means for identifying certificates containing the 1266 particular public key used in an application. Where an end entity 1267 has obtained multiple certificates, especially from multiple CAs, the 1268 subject key identifier provides a means to quickly identify the set 1269 of certificates containing a particular public key. To assist 1270 applications in identifying the appropriate end entity certificate, 1271 this extension SHOULD be included in all end entity certificates. 1273 For end entity certificates, subject key identifiers SHOULD be 1274 derived from the public key. Two common methods for generating key 1275 identifiers from the public key are identified above. 1277 Where a key identifier has not been previously established, this 1278 specification recommends use of one of these methods for generating 1279 keyIdentifiers. 1281 This extension MUST NOT be marked critical. 1283 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 1285 SubjectKeyIdentifier ::= KeyIdentifier 1287 4.2.1.3 Key Usage 1289 The key usage extension defines the purpose (e.g., encipherment, 1290 signature, certificate signing) of the key contained in the 1291 certificate. The usage restriction might be employed when a key that 1292 could be used for more than one operation is to be restricted. For 1293 example, when an RSA key should be used only to verify signatures on 1294 objects other than public key certificates and CRLs, the 1295 digitalSignature and/or nonRepudiation bits would be asserted. 1296 Likewise, when an RSA key should be used only for key management, the 1297 keyEncipherment bit would be asserted. 1299 This extension MUST appear in certificates that contain public keys 1300 that are used to validate digital signatures on other public key 1301 certificates or CRLs. When this extension appears, it SHOULD be 1302 marked critical. 1304 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 1306 KeyUsage ::= BIT STRING { 1307 digitalSignature (0), 1308 nonRepudiation (1), 1309 keyEncipherment (2), 1310 dataEncipherment (3), 1311 keyAgreement (4), 1312 keyCertSign (5), 1313 cRLSign (6), 1314 encipherOnly (7), 1315 decipherOnly (8) } 1317 Bits in the KeyUsage type are used as follows: 1319 The digitalSignature bit is asserted when the subject public key 1320 is used with a digital signature mechanism to support security 1321 services other than non-repudiation (bit 1), certificate signing 1322 (bit 5), or CRL signing (bit 6). Digital signature mechanisms are 1323 often used for entity authentication and data origin 1324 authentication with integrity. 1326 The nonRepudiation bit is asserted when the subject public key is 1327 used to verify digital signatures used to provide a non- 1328 repudiation service which protects against the signing entity 1329 falsely denying some action, excluding certificate or CRL signing. 1330 In the case of later conflict, a reliable third party may 1331 determine the authenticity of the signed data. 1333 Further distinctions between the digitalSignature and 1334 nonRepudiation bits may be provided in specific certificate 1335 policies. 1337 The keyEncipherment bit is asserted when the subject public key is 1338 used for key transport. For example, when an RSA key is to be 1339 used for key management, then this bit is set. 1341 The dataEncipherment bit is asserted when the subject public key 1342 is used for enciphering user data, other than cryptographic keys. 1344 The keyAgreement bit is asserted when the subject public key is 1345 used for key agreement. For example, when a Diffie-Hellman key is 1346 to be used for key management, then this bit is set. 1348 The keyCertSign bit is asserted when the subject public key is 1349 used for verifying a signature on public key certificates. If the 1350 keyCertSign bit is asserted, then the cA bit in the basic 1351 constraints extension (section 4.2.1.10) MUST also be asserted. 1353 The cRLSign bit is asserted when the subject public key is used 1354 for verifying a signature on certificate revocation list (e.g., a 1355 CRL, delta CRL, or an ARL). This bit MUST be asserted in 1356 certificates that are used to verify signatures on CRLs. 1358 The meaning of the encipherOnly bit is undefined in the absence of 1359 the keyAgreement bit. When the encipherOnly bit is asserted and 1360 the keyAgreement bit is also set, the subject public key may be 1361 used only for enciphering data while performing key agreement. 1363 The meaning of the decipherOnly bit is undefined in the absence of 1364 the keyAgreement bit. When the decipherOnly bit is asserted and 1365 the keyAgreement bit is also set, the subject public key may be 1366 used only for deciphering data while performing key agreement. 1368 This profile does not restrict the combinations of bits that may be 1369 set in an instantiation of the keyUsage extension. However, 1370 appropriate values for keyUsage extensions for particular algorithms 1371 are specified in [PKIXALGS]. 1373 4.2.1.4 Private Key Usage Period 1375 This profile RECOMMENDS against the use of this extension. CAs 1376 conforming to this profile MUST NOT generate certificates with 1377 critical private key usage period extensions. 1379 The private key usage period extension allows the certificate issuer 1380 to specify a different validity period for the private key than the 1381 certificate. This extension is intended for use with digital 1382 signature keys. This extension consists of two optional components, 1383 notBefore and notAfter. The private key associated with the 1384 certificate SHOULD NOT be used to sign objects before or after the 1385 times specified by the two components, respectively. CAs conforming 1386 to this profile MUST NOT generate certificates with private key usage 1387 period extensions unless at least one of the two components is 1388 present. 1390 Where used, notBefore and notAfter are represented as GeneralizedTime 1391 and MUST be specified and interpreted as defined in section 1392 4.1.2.5.2. 1394 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 1396 PrivateKeyUsagePeriod ::= SEQUENCE { 1397 notBefore [0] GeneralizedTime OPTIONAL, 1398 notAfter [1] GeneralizedTime OPTIONAL } 1400 4.2.1.5 Certificate Policies 1402 The certificate policies extension contains a sequence of one or more 1403 policy information terms, each of which consists of an object 1404 identifier (OID) and optional qualifiers. Optional qualifiers, which 1405 MAY be present, are not expected to change the definition of the 1406 policy. 1408 In an end entity certificate, these policy information terms indicate 1409 the policy under which the certificate has been issued and the 1410 purposes for which the certificate may be used. In a CA certificate, 1411 these policy information terms limit the set of policies for 1412 certification paths which include this certificate. When a CA does 1413 not wish to limit the set of policies for certification paths which 1414 include this certificate, they MAY assert the special policy 1415 anyPolicy, with a value of { 2 5 29 32 0 }. 1417 Applications with specific policy requirements are expected to have a 1418 list of those policies which they will accept and to compare the 1419 policy OIDs in the certificate to that list. If this extension is 1420 critical, the path validation software MUST be able to interpret this 1421 extension (including the optional qualifier), or MUST reject the 1422 certificate. 1424 To promote interoperability, this profile RECOMMENDS that policy 1425 information terms consist of only an OID. Where an OID alone is 1426 insufficient, this profile strongly recommends that use of qualifiers 1427 be limited to those identified in this section. When qualifiers are 1428 used with the special policy anyPolicy, they MUST be limited to the 1429 qualifiers identified in this section. 1431 This specification defines two policy qualifier types for use by 1432 certificate policy writers and certificate issuers. The qualifier 1433 types are the CPS Pointer and User Notice qualifiers. 1435 The CPS Pointer qualifier contains a pointer to a Certification 1436 Practice Statement (CPS) published by the CA. The pointer is in the 1437 form of a URI. Processing requirements for this qualifier are a 1438 local matter. No action is mandated by this specification regardless 1439 of the criticality value asserted for the extension. 1441 User notice is intended for display to a relying party when a 1442 certificate is used. The application software SHOULD display all 1443 user notices in all certificates of the certification path used, 1444 except that if a notice is duplicated only one copy need be 1445 displayed. To prevent such duplication, this qualifier SHOULD only 1446 be present in end entity certificates and CA certificates issued to 1447 other organizations. 1449 The user notice has two optional fields: the noticeRef field and the 1450 explicitText field. 1452 The noticeRef field, if used, names an organization and 1453 identifies, by number, a particular textual statement prepared by 1454 that organization. For example, it might identify the 1455 organization "CertsRUs" and notice number 1. In a typical 1456 implementation, the application software will have a notice file 1457 containing the current set of notices for CertsRUs; the 1458 application will extract the notice text from the file and display 1459 it. Messages MAY be multilingual, allowing the software to select 1460 the particular language message for its own environment. 1462 An explicitText field includes the textual statement directly in 1463 the certificate. The explicitText field is a string with a 1464 maximum size of 200 characters. 1466 If both the noticeRef and explicitText options are included in the 1467 one qualifier and if the application software can locate the notice 1468 text indicated by the noticeRef option then that text SHOULD be 1469 displayed; otherwise, the explicitText string SHOULD be displayed. 1471 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 1473 anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificate-policies 0 } 1475 certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 1477 PolicyInformation ::= SEQUENCE { 1478 policyIdentifier CertPolicyId, 1479 policyQualifiers SEQUENCE SIZE (1..MAX) OF 1480 PolicyQualifierInfo OPTIONAL } 1482 CertPolicyId ::= OBJECT IDENTIFIER 1484 PolicyQualifierInfo ::= SEQUENCE { 1485 policyQualifierId PolicyQualifierId, 1486 qualifier ANY DEFINED BY policyQualifierId } 1488 -- policyQualifierIds for Internet policy qualifiers 1490 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 1491 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 1492 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 1494 PolicyQualifierId ::= 1495 OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) 1497 Qualifier ::= CHOICE { 1498 cPSuri CPSuri, 1499 userNotice UserNotice } 1501 CPSuri ::= IA5String 1503 UserNotice ::= SEQUENCE { 1504 noticeRef NoticeReference OPTIONAL, 1505 explicitText DisplayText OPTIONAL} 1507 NoticeReference ::= SEQUENCE { 1508 organization DisplayText, 1509 noticeNumbers SEQUENCE OF INTEGER } 1511 DisplayText ::= CHOICE { 1512 ia5String IA5String (SIZE (1..200)), 1513 visibleString VisibleString (SIZE (1..200)), 1514 bmpString BMPString (SIZE (1..200)), 1515 utf8String UTF8String (SIZE (1..200)) } 1517 4.2.1.6 Policy Mappings 1519 This extension is used in CA certificates. It lists one or more 1520 pairs of OIDs; each pair includes an issuerDomainPolicy and a 1521 subjectDomainPolicy. The pairing indicates the issuing CA considers 1522 its issuerDomainPolicy equivalent to the subject CA's 1523 subjectDomainPolicy. 1525 The issuing CA's users MAY accept an issuerDomainPolicy for certain 1526 applications. The policy mapping tells the issuing CA's users which 1527 policies associated with the subject CA are comparable to the policy 1528 they accept. 1530 Each issuerDomainPolicy named in the policy mapping extension SHOULD 1531 also be asserted in a certificate policies extension in the same 1532 certificate. Policies SHOULD NOT be mapped either to or from the 1533 special value anyPolicy (section 4.2.1.5). 1535 This extension MAY be supported by CAs and/or applications, and it 1536 MUST be non-critical. 1538 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 1540 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 1541 issuerDomainPolicy CertPolicyId, 1542 subjectDomainPolicy CertPolicyId } 1544 4.2.1.7 Subject Alternative Name 1546 The subject alternative names extension allows additional identities 1547 to be bound to the subject of the certificate. Defined options 1548 include an Internet electronic mail address, a DNS name, an IP 1549 address, and a uniform resource identifier (URI). Other options 1550 exist, including completely local definitions. Multiple name forms, 1551 and multiple instances of each name form, MAY be included. Whenever 1552 such identities are to be bound into a certificate, the subject 1553 alternative name (or issuer alternative name) extension MUST be used. 1555 Because the subject alternative name is considered to be definitively 1556 bound to the public key, all parts of the subject alternative name 1557 MUST be verified by the CA. 1559 Further, if the only subject identity included in the certificate is 1560 an alternative name form (e.g., an electronic mail address), then the 1561 subject distinguished name MUST be empty (an empty sequence), and the 1562 subjectAltName extension MUST be present. If the subject field 1563 contains an empty sequence, the subjectAltName extension MUST be 1564 marked critical. 1566 When the subjectAltName extension contains an Internet mail address, 1567 the address MUST be included as an rfc822Name. The format of an 1568 rfc822Name is an "addr-spec" as defined in RFC 822 [RFC 822]. An 1569 addr-spec has the form "local-part@domain". Note that an addr-spec 1570 has no phrase (such as a common name) before it, has no comment (text 1571 surrounded in parentheses) after it, and is not surrounded by "<" and 1572 ">". Note that while upper and lower case letters are allowed in an 1573 RFC 822 addr-spec, no significance is attached to the case. 1575 When the subjectAltName extension contains a iPAddress, the address 1576 MUST be stored in the octet string in "network byte order," as 1577 specified in RFC 791 [RFC 791]. The least significant bit (LSB) of 1578 each octet is the LSB of the corresponding byte in the network 1579 address. For IP Version 4, as specified in RFC 791, the octet string 1580 MUST contain exactly four octets. For IP Version 6, as specified in 1581 RFC 1883, the octet string MUST contain exactly sixteen octets [RFC 1582 1883]. 1584 When the subjectAltName extension contains a domain name service 1585 label, the domain name MUST be stored in the dNSName (an IA5String). 1586 The name MUST be in the "preferred name syntax," as specified by RFC 1587 1034 [RFC 1034]. Note that while upper and lower case letters are 1588 allowed in domain names, no signifigance is attached to the case. In 1589 addition, while the string " " is a legal domain name, subjectAltName 1590 extensions with a dNSName " " are not permitted. Finally, the use of 1591 the DNS representation for Internet mail addresses (wpolk.nist.gov 1592 instead of wpolk@nist.gov) MUST NOT be used; such identities are to 1593 be encoded as rfc822Name. 1595 Note: work is currently underway to specify domain names in 1596 international character sets. This names will likely not be 1597 accomodated by IA5String. Once this work is complete, this profile 1598 will be revisited and the appropriate functionality will be added. 1600 When the subjectAltName extension contains a URI, the name MUST be 1601 stored in the uniformResourceIdentifier (an IA5String). The name 1602 MUST NOT be a relative URL, and it MUST follow the URL syntax and 1603 encoding rules specified in [RFC 1738]. The name MUST include both a 1604 scheme (e.g., "http" or "ftp") and a scheme-specific-part. The 1605 scheme-specific-part MUST include a fully qualified domain name or IP 1606 address as the host. 1608 As specified in [RFC 1738], the scheme name is not case-sensitive 1609 (e.g., "http" is equivalent to "HTTP"). The host part is also not 1610 case-sensitive, but other components of the scheme-specific-part may 1611 be case-sensitive. When comparing URIs, conforming implementations 1612 MUST compare the scheme and host without regard to case, but assume 1613 the remainder of the scheme-specific-part is case sensitive. 1615 When the subjectAltName extension contains a DN in the directoryName, 1616 the DN MUST be unique for each subject entity certified by the one CA 1617 as defined by the issuer name field. A CA MAY issue more than one 1618 certificate with the same DN to the same subject entity. 1620 The subjectAltName MAY carry additional name types through the use of 1621 the otherName field. The format and semantics of the name are 1622 indicated through the OBJECT IDENTIFIER in the type-id field. The 1623 name itself is conveyed as value field in otherName. For example, 1624 Kerberos [RFC 1510] format names can be encoded into the otherName, 1625 using the krb5PrincipalName OID and the KerberosName syntax as 1626 defined in [PKINIT]. 1628 Subject alternative names MAY be constrained in the same manner as 1629 subject distinguished names using the name constraints extension as 1630 described in section 4.2.1.11. 1632 If the subjectAltName extension is present, the sequence MUST contain 1633 at least one entry. Unlike the subject field, conforming CAs MUST 1634 NOT issue certificates with subjectAltNames containing empty 1635 GeneralName fields. For example, an rfc822Name is represented as an 1636 IA5String. While an empty string is a valid IA5String, such an 1637 rfc822Name is not permitted by this profile. The behavior of clients 1638 that encounter such a certificate when processing a certificication 1639 path is not defined by this profile. 1641 Finally, the semantics of subject alternative names that include 1642 wildcard characters (e.g., as a placeholder for a set of names) are 1643 not addressed by this specification. Applications with specific 1644 requirements MAY use such names, but they MUST define the semantics. 1646 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 1648 SubjectAltName ::= GeneralNames 1650 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 1652 GeneralName ::= CHOICE { 1653 otherName [0] OtherName, 1654 rfc822Name [1] IA5String, 1655 dNSName [2] IA5String, 1656 x400Address [3] ORAddress, 1657 directoryName [4] Name, 1658 ediPartyName [5] EDIPartyName, 1659 uniformResourceIdentifier [6] IA5String, 1660 iPAddress [7] OCTET STRING, 1661 registeredID [8] OBJECT IDENTIFIER} 1663 OtherName ::= SEQUENCE { 1664 type-id OBJECT IDENTIFIER, 1665 value [0] EXPLICIT ANY DEFINED BY type-id } 1667 EDIPartyName ::= SEQUENCE { 1668 nameAssigner [0] DirectoryString OPTIONAL, 1669 partyName [1] DirectoryString } 1671 4.2.1.8 Issuer Alternative Names 1673 As with 4.2.1.7, this extension is used to associate Internet style 1674 identities with the certificate issuer. Issuer alternative names MUST 1675 be encoded as in 4.2.1.7. 1677 Where present, this extension SHOULD NOT be marked critical. 1679 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 1681 IssuerAltName ::= GeneralNames 1683 4.2.1.9 Subject Directory Attributes 1685 The subject directory attributes extension is used to convey 1686 identification attributes (e.g.,nationality) of the subject. The 1687 extension is defined as a sequence of one or more attributes. This 1688 extension MUST be non-critical. 1690 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 1692 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 1694 4.2.1.10 Basic Constraints 1696 The basic constraints extension identifies whether the subject of the 1697 certificate is a CA and the maximum depth of valid certification 1698 paths that include this certificate. 1700 The cA bit indicates whether the certified public key belongs to a 1701 CA. If the cA bit is not asserted, then the keyCertSign bit in the 1702 key usage extension MUST NOT be asserted. 1704 The pathLenConstraint field is meaningful only if the cA bit is 1705 asserted and the key usage extension asserts the keyCertSign bit 1706 (section 4.2.1.3). In this case, it gives the maximum number of non- 1707 self-issued intermediate certificates that may follow this 1708 certificate in a valid certification path. A certificate is self- 1709 issued if the DNs that appear in the subject and issuer fields are 1710 identical and are not empty. (Note: The last certificate in the 1711 certification path is not an intermediate certificate, and is not 1712 included in this limit. Usually, the last certificate is an end 1713 entity certificate, but it can be a CA certificate.) A 1714 pathLenConstraint of zero indicates that only one more certificate 1715 may follow in a valid certification path. Where it appears, the 1716 pathLenConstraint field MUST be greater than or equal to zero. Where 1717 pathLenConstraint does not appear, no limit is imposed. 1719 This extension MUST appear as a critical extension in all CA 1720 certificates that contain public keys used to validate digital 1721 signatures on certificates. This extension MAY appear as a critical 1722 or non-critical extension in CA certificates that contain public keys 1723 used exclusively for purposes other than validating digital 1724 signatures on certificates. Such CA certificates include ones that 1725 contain public keys used exclusively for validating digital 1726 signatures on CRLs and ones that contain key management public keys 1727 used with certificate enrollment protocols. This extension MAY 1728 appear as a critical or non-critical extension in end entity 1729 certificates. 1731 CAs MUST NOT include the pathLenConstraint field unless the cA bit is 1732 asserted and the key usage extension asserts the keyCertSign bit. 1734 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 1736 BasicConstraints ::= SEQUENCE { 1737 cA BOOLEAN DEFAULT FALSE, 1738 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 1740 4.2.1.11 Name Constraints 1742 The name constraints extension, which MUST be used only in a CA 1743 certificate, indicates a name space within which all subject names in 1744 subsequent certificates in a certification path MUST be located. 1745 Restrictions apply to the subject distinguished name and apply to 1746 subject alternative names. Restrictions apply only when the 1747 specified name form is present. If no name of the type is in the 1748 certificate, the certificate is acceptable. 1750 Name constraints are not applied to certificates whose issuer and 1751 subject are identical (unless the certificate is the final 1752 certificate in the path). (This could prevent CAs that use name 1753 constraints from issuing self-signed certificates to implement key 1754 rollover.) 1756 Restrictions are defined in terms of permitted or excluded name 1757 subtrees. Any name matching a restriction in the excludedSubtrees 1758 field is invalid regardless of information appearing in the 1759 permittedSubtrees. This extension MUST be critical. 1761 Within this profile, the minimum and maximum fields are not used with 1762 any name forms, thus minimum is always zero, and maximum is always 1763 absent. 1765 For URIs, the constraint applies to the host part of the name. The 1766 constraint MAY specify a host or a domain. Examples would be 1767 "foo.bar.com"; and ".xyz.com". When the the constraint begins with 1768 a period, it MAY be expanded with one or more subdomains. That is, 1769 the constraint ".xyz.com" is satisfied by both abc.xyz.com and 1770 abc.def.xyz.com. However, the constraint ".xyz.com" is not satisfied 1771 by "xyz.com". When the constraint does not begin with a period, it 1772 specifies a host. 1774 A name constraint for Internet mail addresses MAY specify a 1775 particular mailbox, all addresses at a particular host, or all 1776 mailboxes in a domain. To indicate a particular mailbox, the 1777 constraint is the complete mail address. For example, "root@xyz.com" 1778 indicates the root mailbox on the host "xyz.com". To indicate all 1779 Internet mail addresses on a particular host, the constraint is 1780 specified as the host name. For example, the constraint "xyz.com" is 1781 satisfied by any mail address at the host "xyz.com". To specify any 1782 address within a domain, the constraint is specified with a leading 1783 period (as with URIs). For example, ".xyz.com" indicates all the 1784 Internet mail addresses in the domain "xyz.com", but not Internet 1785 mail addresses on the host "xyz.com". 1787 DNS name restrictions are expressed as foo.bar.com. Any DNS name that 1788 can be constructed by simply adding to the left hand side of the name 1789 satisfies the name constraint. For example, www.foo.bar.com would 1790 satisfy the constraint but foo1.bar.com would not. 1792 Legacy implementations exist where an RFC 822 name is embedded in the 1793 subject distinguished name in an attribute of type EmailAddress 1794 (section 4.1.2.6). When rfc822 names are constrained, but the 1795 certificate does not include a subject alternative name, the rfc822 1796 name constraint MUST be applied to the attribute of type EmailAddress 1797 in the subject distinguished name. The ASN.1 syntax for EmailAddress 1798 and the corresponding OID are supplied in Appendix A. 1800 Restrictions of the form directoryName MUST be applied to the subject 1801 field in the certificate and to the subjectAltName extensions of type 1802 directoryName. Restrictions of the form x400Address MUST be applied 1803 to subjectAltName extensions of type x400Address. 1805 When applying restrictions of the form directoryName, an 1806 implementation MUST compare DN attributes. At a minimum, 1807 implementations MUST perform the DN comparison rules specified in 1808 Section 4.1.2.4. CAs issuing certificates with a restriction of the 1809 form directoryName SHOULD NOT rely on implementation of the full ISO 1810 DN name comparison algorithm. This implies name restrictions MUST be 1811 stated identically to the encoding used in the subject field or 1812 subjectAltName extension. 1814 The syntax of iPAddress MUST be as described in section 4.2.1.7 with 1815 the following additions specifically for Name Constraints. For IPv4 1816 addresses, the ipAddress field of generalName MUST contain eight (8) 1817 octets, encoded in the style of RFC 1519 (CIDR) to represent an 1818 address range.[RFC 1519] For IPv6 addresses, the ipAddress field 1819 MUST contain 32 octets similarly encoded. For example, a name 1820 constraint for "class C" subnet 10.9.8.0 is represented as the octets 1821 0A 09 08 00 FF FF FF 00, representing the CIDR notation 1822 10.9.8.0/255.255.255.0. 1824 The syntax and semantics for name constraints for otherName, 1825 ediPartyName, and registeredID are not defined by this specification. 1827 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 1829 NameConstraints ::= SEQUENCE { 1830 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 1831 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 1833 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 1835 GeneralSubtree ::= SEQUENCE { 1836 base GeneralName, 1837 minimum [0] BaseDistance DEFAULT 0, 1838 maximum [1] BaseDistance OPTIONAL } 1840 BaseDistance ::= INTEGER (0..MAX) 1842 4.2.1.12 Policy Constraints 1844 The policy constraints extension can be used in certificates issued 1845 to CAs. The policy constraints extension constrains path validation 1846 in two ways. It can be used to prohibit policy mapping or require 1847 that each certificate in a path contain an acceptable policy 1848 identifier. 1850 If the inhibitPolicyMapping field is present, the value indicates the 1851 number of additional certificates that may appear in the path before 1852 policy mapping is no longer permitted. For example, a value of one 1853 indicates that policy mapping may be processed in certificates issued 1854 by the subject of this certificate, but not in additional 1855 certificates in the path. 1857 If the requireExplicitPolicy field is present, subsequent 1858 certificates MUST include an acceptable policy identifier. The value 1859 of requireExplicitPolicy indicates the number of additional 1860 certificates that may appear in the path before an explicit policy is 1861 required. An acceptable policy identifier is the identifier of a 1862 policy required by the user of the certification path or the 1863 identifier of a policy which has been declared equivalent through 1864 policy mapping. 1866 Conforming CAs MUST NOT issue certificates where policy constraints 1867 is a null sequence. That is, at least one of the inhibitPolicyMapping 1868 field or the requireExplicitPolicy field MUST be present. The 1869 behavior of clients that encounter a null policy constraints field is 1870 not addressed in this profile. 1872 This extension MAY be critical or non-critical. 1874 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } 1876 PolicyConstraints ::= SEQUENCE { 1877 requireExplicitPolicy [0] SkipCerts OPTIONAL, 1878 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 1880 SkipCerts ::= INTEGER (0..MAX) 1882 4.2.1.13 Extended key usage field 1884 This field indicates one or more purposes for which the certified 1885 public key may be used, in addition to or in place of the basic 1886 purposes indicated in the key usage extension field. In general, 1887 this extension will appear only in end entity certificates. This 1888 field is defined as follows: 1890 id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 } 1892 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 1894 KeyPurposeId ::= OBJECT IDENTIFIER 1896 Key purposes may be defined by any organization with a need. Object 1897 identifiers used to identify key purposes MUST be assigned in 1898 accordance with IANA or ITU-T Recommendation X.660 | ISO/IEC/ITU 1899 9834-1. 1901 This extension MAY, at the option of the certificate issuer, be 1902 either critical or non-critical. 1904 If the extension is flagged critical, then the certificate MUST only 1905 be used for one of the purposes indicated. If multiple purposes are 1906 indicated the application need not recognize all purposes indicated, 1907 as long as the intended purpose is present and recognized. 1909 If the extension is flagged non-critical, then it indicates the 1910 intended purpose or purposes of the key, and MAY be used in finding 1911 the correct key/certificate of an entity that has multiple 1912 keys/certificates. It is an advisory field and does not imply that 1913 usage of the key is restricted by the certification authority to the 1914 purpose indicated. Certificate using applications MAY nevertheless 1915 require that a particular purpose be indicated in order for the 1916 certificate to be acceptable to that application. 1918 If a certificate contains both a critical key usage field and a 1919 critical extended key usage field, then both fields MUST be processed 1920 independently and the certificate MUST only be used for a purpose 1921 consistent with both fields. If there is no purpose consistent with 1922 both fields, then the certificate MUST NOT be used for any purpose. 1924 The following key usage purposes are defined by this profile: 1926 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 1928 id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } 1929 -- TLS WWW server authentication 1930 -- Key usage bits that may be consistent: digitalSignature, 1931 -- keyEncipherment or keyAgreement 1933 id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } 1934 -- TLS WWW client authentication 1935 -- Key usage bits that may be consistent: digitalSignature 1936 -- and/or keyAgreement 1938 id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } 1939 -- Signing of downloadable executable code 1940 -- Key usage bits that may be consistent: digitalSignature 1942 id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } 1943 -- E-mail protection 1944 -- Key usage bits that may be consistent: digitalSignature, 1945 -- nonRepudiation, and/or (keyEncipherment or keyAgreement) 1947 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 1948 -- Binding the hash of an object to a time 1949 -- Key usage bits that may be consistent: digitalSignature 1950 -- and/or nonRepudiation 1952 id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 } 1953 -- Signing OCSP responses 1954 -- Key usage bits that may be consistent: digitalSignature 1955 -- and/or nonRepudiation 1957 4.2.1.14 CRL Distribution Points 1959 The CRL distribution points extension identifies how CRL information 1960 is obtained. The extension SHOULD be non-critical, but this profile 1961 RECOMMENDS support for this extension by CAs and applications. 1962 Further discussion of CRL management is contained in section 5. 1964 The cRLDistributionPoints extension is a SEQUENCE of 1965 DistributionPoint. A DistributionPoint consists of three fields, 1966 each of which is optional: distributionPoint, reasons, and cRLIssuer. 1967 While each of these fields is optional, a DistributionPoint MUST NOT 1968 consist of only the reasons field; either distributionPoint or 1969 cRLIssuer MUST be present. If the certificate issuer is not the CRL 1970 issuer, then the cRLIssuer field MUST be present and contain the Name 1971 of the CRL issuer. If the certificate issuer is also the CRL issuer, 1972 then the cRLIssuer field MUST be omitted and the distributionPoint 1973 field MUST be present. If the the distributionPoint field is 1974 omitted, cRLIssuer MUST be present and include a Name corresponding 1975 to an X.500 or LDAP directory entry where the CRL is located. 1977 When the distributionPoint field is present, it contains either a 1978 SEQUENCE of general names or a single value, nameRelativeToCRLIssuer. 1979 If the cRLDistributionPoints extension contains a general name of 1980 type URI, the following semantics MUST be assumed: the URI is a 1981 pointer to the current CRL for the associated reasons and will be 1982 issued by the associated cRLIssuer. The expected values for the URI 1983 are those defined in 4.2.1.7. Processing rules for other values are 1984 not defined by this specification. 1986 If the DistributionPointName contains multiple values, each name 1987 describes a different mechanism to obtain the same CRL. For example, 1988 the same CRL could be available for retrieval through both LDAP and 1989 HTTP. 1991 If the DistributionPointName contains the single value 1992 nameRelativeToCRLIssuer, the value provides a distinguished name 1993 fragment. The fragment is appended to the X.500 distinguished name 1994 of the CRL issuer to obtain the distribution point name. If the 1995 cRLIssuer field in the DistributionPoint is present, then the name 1996 fragment is appended to the distinguished name that it contains; 1997 otherwise, the name fragment is appended to the certificate issuer 1998 distinguished name. The DistributionPointName MUST NOT use the 1999 nameRealtiveToCRLIssuer alternative when cRLIssuer contains more than 2000 one distinguished name. 2002 If the DistributionPoint omits the reasons field, the CRL MUST 2003 include revocation information for all reasons. 2005 The cRLIssuer identifies the entity who signs and issues the CRL. If 2006 present, the cRLIssuer MUST contain at least one an X.500 2007 distinguished name (DN), and MAY also contain other name forms. 2008 Since the cRLIssuer is compared to the CRL issuer name, the X.501 2009 type Name MUST follow the encoding rules for the issuer name field in 2010 the certificate (section 4.1.2.4). 2012 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 } 2014 CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 2016 DistributionPoint ::= SEQUENCE { 2017 distributionPoint [0] DistributionPointName OPTIONAL, 2018 reasons [1] ReasonFlags OPTIONAL, 2019 cRLIssuer [2] GeneralNames OPTIONAL } 2021 DistributionPointName ::= CHOICE { 2022 fullName [0] GeneralNames, 2023 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 2025 ReasonFlags ::= BIT STRING { 2026 unused (0), 2027 keyCompromise (1), 2028 cACompromise (2), 2029 affiliationChanged (3), 2030 superseded (4), 2031 cessationOfOperation (5), 2032 certificateHold (6), 2033 privilegeWithdrawn (7), 2034 aACompromise (8) } 2036 4.2.1.15 Inhibit Any-Policy 2038 The inhibit any-policy extension can be used in certificates issued 2039 to CAs. The inhibit any-policy indicates that the special any-policy 2040 OID, with the value { 2 5 29 32 0 }, is not considered an explicit 2041 match for other certificate policies. The value indicates the number 2042 of additional certificates that may appear in the path before any- 2043 policy is no longer permitted. For example, a value of one indicates 2044 that any-policy may be processed in certificates issued by the 2045 subject of this certificate, but not in additional certificates in 2046 the path. 2048 This extension MUST be critical. 2050 id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 } 2052 InhibitAnyPolicy ::= SkipCerts 2053 SkipCerts ::= INTEGER (0..MAX) 2055 4.2.1.16 Freshest CRL (a.k.a. Delta CRL Distribution Point) 2057 The freshest CRL extension identifies how delta CRL information is 2058 obtained. The extension MUST be non-critical. Further discussion of 2059 CRL management is contained in section 5. 2061 The same syntax is used for this extension and the 2062 cRLDistributionPoints extension, and is described in section 2063 4.2.1.14. The same conventions apply to both extensions. 2065 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } 2067 FreshestCRL ::= CRLDistributionPoints 2069 4.2.2 Private Internet Extensions 2071 This section defines one new extension for use in the Internet Public 2072 Key Infrastructure. This extension may be used to direct 2073 applications to identify an on-line validation service supporting the 2074 issuing CA. As the information may be available in multiple forms, 2075 each extension is a sequence of IA5String values, each of which 2076 represents a URI. The URI implicitly specifies the location and 2077 format of the information and the method for obtaining the 2078 information. 2080 An object identifier is defined for the private extension. The 2081 object identifier associated with the private extension is defined 2082 under the arc id-pe within the id-pkix name space. Any future 2083 extensions defined for the Internet PKI will also be defined under 2084 the arc id-pe. 2086 id-pkix OBJECT IDENTIFIER ::= 2087 { iso(1) identified-organization(3) dod(6) internet(1) 2088 security(5) mechanisms(5) pkix(7) } 2090 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 2092 4.2.2.1 Authority Information Access 2094 The authority information access extension indicates how to access CA 2095 information and services for the issuer of the certificate in which 2096 the extension appears. Information and services may include on-line 2097 validation services and CA policy data. (The location of CRLs is not 2098 specified in this extension; that information is provided by the 2099 cRLDistributionPoints extension.) This extension may be included in 2100 subject or CA certificates, and it MUST be non-critical. 2102 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 2104 AuthorityInfoAccessSyntax ::= 2105 SEQUENCE SIZE (1..MAX) OF AccessDescription 2107 AccessDescription ::= SEQUENCE { 2108 accessMethod OBJECT IDENTIFIER, 2109 accessLocation GeneralName } 2111 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 2113 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 2115 Each entry in the sequence AuthorityInfoAccessSyntax describes the 2116 format and location of additional information provided by the CA who 2117 issued the certificate in which this extension appears. The type and 2118 format of the information is specified by the accessMethod field; the 2119 accessLocation field specifies the location of the information. The 2120 retrieval mechanism may be implied by the accessMethod or specified 2121 by accessLocation. 2123 This profile defines one OID for accessMethod. The id-ad-caIssuers 2124 OID is used when the additional information lists CAs that have 2125 issued certificates superior to the CA that issued the certificate 2126 containing this extension. The referenced CA Issuers description is 2127 intended to aid certificate users in the selection of a certification 2128 path that terminates at a point trusted by the certificate user. 2130 When id-ad-caIssuers appears as accessInfoType, the accessLocation 2131 field describes the referenced description server and the access 2132 protocol to obtain the referenced description. The accessLocation 2133 field is defined as a GeneralName, which can take several forms. 2134 Where the information is available via http, ftp, or ldap, 2135 accessLocation MUST be a uniformResourceIdentifier. Where the 2136 information is available via the directory access protocol (dap), 2137 accessLocation MUST be a directoryName. When the information is 2138 available via electronic mail, accessLocation MUST be an rfc822Name. 2139 The semantics of other name forms of accessLocation (when 2140 accessMethod is id-ad-caIssuers) are not defined by this 2141 specification. 2143 [RFC 2560] defines the access descriptor for the Online Certificate 2144 Status Protocol. When this access descriptor appears in the 2145 authority information access extension, this indicates the issuer 2146 provides revocation information for this certificate through the 2147 named OCSP service. Additional access descriptors may be defined in 2148 other PKIX specifications. 2150 4.2.2.2 Subject Information Access 2152 The subject information access extension indicates how to access 2153 information and services for the subject of the certificate in which 2154 the extension appears. When the subject is a CA, information and 2155 services may include certificate validation services and CA policy 2156 data. When the subject is an end entity, the information describes 2157 the type of services offered and how to access them. In this case, 2158 the contents of this extension are defined in the protocol 2159 specifications for the suported services. This extension may be 2160 included in subject or CA certificates, and it MUST be non-critical. 2162 id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 } 2164 SubjectInfoAccessSyntax ::= 2165 SEQUENCE SIZE (1..MAX) OF AccessDescription 2167 AccessDescription ::= SEQUENCE { 2168 accessMethod OBJECT IDENTIFIER, 2169 accessLocation GeneralName } 2171 Each entry in the sequence SubjectInfoAccessSyntax describes the 2172 format and location of additional information provided by the subject 2173 of the certificate in which this extension appears. The type and 2174 format of the information is specified by the accessMethod field; the 2175 accessLocation field specifies the location of the information. The 2176 retrieval mechanism may be implied by the accessMethod or specified 2177 by accessLocation. 2179 This profile defines one access method to be used when the subject is 2180 a CA, and one access method to be used when the subject is an end 2181 entity. Additional access methods may be defined in the future in 2182 the protocol specifications for other services. 2184 The id-ad-caRepository OID is used when the subject is a CA, and 2185 publishes its certificates and CRLs (if issued) in a repository. The 2186 accessLocation field is defined as a GeneralName, which can take 2187 several forms. Where the information is available via http, ftp, or 2188 ldap, accessLocation MUST be a uniformResourceIdentifier. Where the 2189 information is available via the directory access protocol (dap), 2190 accessLocation MUST be a directoryName. When the information is 2191 available via electronic mail, accessLocation MUST be an rfc822Name. 2192 The semantics of other name forms of of accessLocation (when 2193 accessMethod is id-ad-caRepository) are not defined by this 2194 specification. 2196 The id-ad-timeStamping OID is used when the subject offers 2197 timestamping services using the Time Stamp Protocol defined in 2199 [PKIXTSA]. Where the timestamping services are available via http or 2200 ftp, accessLocation MUST be a uniformResourceIdentifier. Where the 2201 timestamping services are available via electronic mail, 2202 accessLocation MUST be an rfc822Name. Where timestamping services 2203 are available using TCP/IP, the dNSName and ipAddress name forms may 2204 be used. The semantics of other name forms of accessLocation (when 2205 accessMethod is id-ad-timeStamping) are not defined by this 2206 specification. 2208 Additional access descriptors may be defined in other PKIX 2209 specifications. 2211 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 2213 id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 } 2215 id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 } 2217 5 CRL and CRL Extensions Profile 2219 As discussed above, one goal of this X.509 v2 CRL profile is to 2220 foster the creation of an interoperable and reusable Internet PKI. 2221 To achieve this goal, guidelines for the use of extensions are 2222 specified, and some assumptions are made about the nature of 2223 information included in the CRL. 2225 CRLs may be used in a wide range of applications and environments 2226 covering a broad spectrum of interoperability goals and an even 2227 broader spectrum of operational and assurance requirements. This 2228 profile establishes a common baseline for generic applications 2229 requiring broad interoperability. The profile defines a set of 2230 information that can be expected in every CRL. Also, the profile 2231 defines common locations within the CRL for frequently used 2232 attributes as well as common representations for these attributes. 2234 CRL issuers issue CRLs. In general, the CRL issuer is the CA. CAs 2235 publish CRLs to provide status information about the certificates 2236 they issued. However, a CA may delegate this responsibility to 2237 another trusted authority. Whenever the CRL issuer is not the CA 2238 that issued the certificates, the CRL is referred to as an indirect 2239 CRL. 2241 Each CRL has a particular scope. The CRL scope is the set of 2242 certificates that could appear on a given CRL. For example, the 2243 scope could be "all certificates issued by CA X", "all CA 2244 certificates issued by CA X", "all certificates issued by CA X that 2245 have been revoked for reasons of key compromise and CA compromise", 2246 or could be a set of certificates based on arbitrary local 2247 information, such as "all certificates issued to the NIST employees 2248 located in Boulder". 2250 A complete CRL lists all unexpired certificates, within its scope, 2251 that have been revoked for one of the revocation reasons covered by 2252 the CRL scope. The CRL issuer MAY also generate delta CRLs. A delta 2253 CRL only lists those certificates, within its scope, whose revocation 2254 status has changed since the issuance of a referenced complete CRL. 2255 The referenced complete CRL is referred to as a base CRL. The scope 2256 of a delta CRL MUST be the same as the base CRL that it references. 2258 This profile does not define any private Internet CRL extensions or 2259 CRL entry extensions. 2261 Environments with additional or special purpose requirements may 2262 build on this profile or may replace it. 2264 Conforming CAs are not required to issue CRLs if other revocation or 2265 certificate status mechanisms are provided. Conforming CAs that 2266 issue CRLs MUST issue version 2 CRLs, include the date by which the 2267 next CRL will be issued in the nextUpdate field (section 5.1.2.5), 2268 include the CRL number extension (section 5.2.3), and include the 2269 authority key identifier extension (section 5.2.1). Conforming 2270 applications that support CRLs are required to process both version 1 2271 and 2 CRLs that are complete for a given scope. Conforming 2272 applications are not required to support processing of delta CRLs or 2273 indirect CRLs. 2275 5.1 CRL Fields 2277 The X.509 v2 CRL syntax is as follows. For signature calculation, 2278 the data that is to be signed is ASN.1 DER encoded. ASN.1 DER 2279 encoding is a tag, length, value encoding system for each element. 2281 CertificateList ::= SEQUENCE { 2282 tbsCertList TBSCertList, 2283 signatureAlgorithm AlgorithmIdentifier, 2284 signatureValue BIT STRING } 2286 TBSCertList ::= SEQUENCE { 2287 version Version OPTIONAL, 2288 -- if present, MUST be v2 2289 signature AlgorithmIdentifier, 2290 issuer Name, 2291 thisUpdate Time, 2292 nextUpdate Time OPTIONAL, 2293 revokedCertificates SEQUENCE OF SEQUENCE { 2294 userCertificate CertificateSerialNumber, 2295 revocationDate Time, 2296 crlEntryExtensions Extensions OPTIONAL 2297 -- if present, MUST be v2 2298 } OPTIONAL, 2299 crlExtensions [0] EXPLICIT Extensions OPTIONAL 2300 -- if present, MUST be v2 2301 } 2303 -- Version, Time, CertificateSerialNumber, and Extensions 2304 -- are all defined in the ASN.1 in section 4.1 2306 -- AlgorithmIdentifier is defined in section 4.1.1.2 2308 The following items describe the use of the X.509 v2 CRL in the 2309 Internet PKI. 2311 5.1.1 CertificateList Fields 2313 The CertificateList is a SEQUENCE of three required fields. The 2314 fields are described in detail in the following subsections. 2316 5.1.1.1 tbsCertList 2318 The first field in the sequence is the tbsCertList. This field is 2319 itself a sequence containing the name of the issuer, issue date, 2320 issue date of the next list, the optional list of revoked 2321 certificates, and optional CRL extensions. When there are no revoked 2322 certificates, the revoked certificates list is absent. When one or 2323 more certificates are revoked, each entry on the revoked certificate 2324 list is defined by a sequence of user certificate serial number, 2325 revocation date, and optional CRL entry extensions. 2327 5.1.1.2 signatureAlgorithm 2329 The signatureAlgorithm field contains the algorithm identifier for 2330 the algorithm used by the CRL issuer to sign the CertificateList. 2331 The field is of type AlgorithmIdentifier, which is defined in section 2332 4.1.1.2. [PKIXALGS] lists the supported algorithms for this 2333 specification. Conforming CAs MUST use the algorithm identifiers 2334 presented in [PKIXALGS] when signing with a supported signature 2335 algorithm. 2337 This field MUST contain the same algorithm identifier as the 2338 signature field in the sequence tbsCertList (section 5.1.2.2). 2340 5.1.1.3 signatureValue 2342 The signatureValue field contains a digital signature computed upon 2343 the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded tbsCertList 2344 is used as the input to the signature function. This signature value 2345 is then ASN.1 encoded as a BIT STRING and included in the CRL's 2346 signatureValue field. The details of this process are specified for 2347 each of the supported algorithms in [PKIXALGS]. 2349 CAs that are also CRL issuers MAY use one private key to digitally 2350 sign certificates and CRLs, or MAY use separate private keys to 2351 digitally sign certificates and CRLs. When separate private keys are 2352 employed, each of the public keys associated with these private keys 2353 is placed in a separate certificate, one with the keyCertSign bit set 2354 in the key usage extension, and one with the cRLSign bit set in the 2355 key usage extension (section 4.2.1.3). When separate private keys 2356 are employed, certificates issued by the CA contain one authority key 2357 identifier, and the corresponding CRLs contain a different authority 2358 key identifier. The use of separate CA certificates for validation 2359 of certificate signatures and CRL signatures can offer improved 2360 security characteristics; however, it imposes a burden on 2361 applications, and it might limit interoperability. Many applications 2362 construct a certification path, and then validate the certification 2363 path (section 6). CRL checking in turn requires a separate 2364 certification path to be constructed and validated for the CA's CRL 2365 signature validation certificate. Applications that perform CRL 2366 checking MUST support certification path validation when certificates 2367 and CRLs are digitally signed with the same CA private key. These 2368 applications SHOULD support certification path validation when 2369 certificates and CRLs are digitally signed with different CA private 2370 keys. 2372 5.1.2 Certificate List "To Be Signed" 2374 The certificate list to be signed, or TBSCertList, is a SEQUENCE of 2375 required and optional fields. The required fields identify the CRL 2376 issuer, the algorithm used to sign the CRL, the date and time the CRL 2377 was issued, and the date and time by which the CRL issuer will issue 2378 the next CRL. 2380 Optional fields include lists of revoked certificates and CRL 2381 extensions. The revoked certificate list is optional to support the 2382 case where a CA has not revoked any unexpired certificates that it 2383 has issued. The profile requires conforming CRL issuers to use the 2384 CRL Number CRL extension in all CRLs issued. 2386 5.1.2.1 Version 2388 This optional field describes the version of the encoded CRL. When 2389 extensions are used, as required by this profile, this field MUST be 2390 present and MUST specify version 2 (the integer value is 1). 2392 5.1.2.2 Signature 2394 This field contains the algorithm identifier for the algorithm used 2395 to sign the CRL. [PKIXALGS] lists OIDs for the most popular 2396 signature algorithms used in the Internet PKI. 2398 This field MUST contain the same algorithm identifier as the 2399 signatureAlgorithm field in the sequence CertificateList (section 2400 5.1.1.2). 2402 5.1.2.3 Issuer Name 2404 The issuer name identifies the entity who has signed and issued the 2405 CRL. The issuer identity is carried in the issuer name field. 2406 Alternative name forms may also appear in the issuerAltName extension 2407 (section 5.2.2). The issuer name field MUST contain an X.500 2408 distinguished name (DN). The issuer name field is defined as the 2409 X.501 type Name, and MUST follow the encoding rules for the issuer 2410 name field in the certificate (section 4.1.2.4). 2412 5.1.2.4 This Update 2414 This field indicates the issue date of this CRL. ThisUpdate may be 2415 encoded as UTCTime or GeneralizedTime. 2417 CRL issuers conforming to this profile MUST encode thisUpdate as 2418 UTCTime for dates through the year 2049. CRL issuers conforming to 2419 this profile MUST encode thisUpdate as GeneralizedTime for dates in 2420 the year 2050 or later. 2422 Where encoded as UTCTime, thisUpdate MUST be specified and 2423 interpreted as defined in section 4.1.2.5.1. Where encoded as 2424 GeneralizedTime, thisUpdate MUST be specified and interpreted as 2425 defined in section 4.1.2.5.2. 2427 5.1.2.5 Next Update 2429 This field indicates the date by which the next CRL will be issued. 2430 The next CRL could be issued before the indicated date, but it will 2431 not be issued any later than the indicated date. CRL issuers SHOULD 2432 issue CRLs with a nextUpdate time equal to or later than all previous 2433 CRLs. nextUpdate may be encoded as UTCTime or GeneralizedTime. 2435 This profile requires inclusion of nextUpdate in all CRLs issued by 2436 conforming CRL issuers. Note that the ASN.1 syntax of TBSCertList 2437 describes this field as OPTIONAL, which is consistent with the ASN.1 2438 structure defined in [X.509]. The behavior of clients processing CRLs 2439 which omit nextUpdate is not specified by this profile. 2441 CRL issuers conforming to this profile MUST encode nextUpdate as 2442 UTCTime for dates through the year 2049. CRL issuers conforming to 2443 this profile MUST encode nextUpdate as GeneralizedTime for dates in 2444 the year 2050 or later. 2446 Where encoded as UTCTime, nextUpdate MUST be specified and 2447 interpreted as defined in section 4.1.2.5.1. Where encoded as 2448 GeneralizedTime, nextUpdate MUST be specified and interpreted as 2449 defined in section 4.1.2.5.2. 2451 5.1.2.6 Revoked Certificates 2453 When there are no revoked certificates, the revoked certificates list 2454 is absent. Otherwise, revoked certificates are listed by their 2455 serial numbers. Certificates revoked by the CA are uniquely 2456 identified by the certificate serial number. The date on which the 2457 revocation occurred is specified. The time for revocationDate MUST 2458 be expressed as described in section 5.1.2.4. Additional information 2459 may be supplied in CRL entry extensions; CRL entry extensions are 2460 discussed in section 5.3. 2462 5.1.2.7 Extensions 2464 This field may only appear if the version is 2 (section 5.1.2.1). If 2465 present, this field is a SEQUENCE of one or more CRL extensions. CRL 2466 extensions are discussed in section 5.2. 2468 5.2 CRL Extensions 2470 The extensions defined by ANSI X9 and ISO/IEC/ITU for X.509 v2 CRLs 2471 [X.509] [X9.55] provide methods for associating additional attributes 2472 with CRLs. The X.509 v2 CRL format also allows communities to define 2473 private extensions to carry information unique to those communities. 2474 Each extension in a CRL may be designated as critical or non- 2475 critical. A CRL validation MUST fail if it encounters a critical 2476 extension which it does not know how to process. However, an 2477 unrecognized non-critical extension may be ignored. The following 2478 subsections present those extensions used within Internet CRLs. 2479 Communities MAY elect to include extensions in CRLs which are not 2480 defined in this specification. However, caution SHOULD be exercised 2481 in adopting any critical extensions in CRLs which might be used in a 2482 general context. 2484 Conforming CRL issuers are required to include the authority key 2485 identifier (section 5.2.1) and the CRL number (section 5.2.3) 2486 extensions in all CRLs issued. 2488 5.2.1 Authority Key Identifier 2490 The authority key identifier extension provides a means of 2491 identifying the public key corresponding to the private key used to 2492 sign a CRL. The identification can be based on either the key 2493 identifier (the subject key identifier in the CRL signer's 2494 certificate) or on the issuer name and serial number. This extension 2495 is especially useful where an issuer has more than one signing key, 2496 either due to multiple concurrent key pairs or due to changeover. 2498 Conforming CRL issuers MUST use the key identifier method, and MUST 2499 include this extension in all CRLs issued. 2501 The syntax for this CRL extension is defined in section 4.2.1.1. 2503 5.2.2 Issuer Alternative Name 2505 The issuer alternative names extension allows additional identities 2506 to be associated with the issuer of the CRL. Defined options include 2507 an rfc822 name (electronic mail address), a DNS name, an IP address, 2508 and a URI. Multiple instances of a name and multiple name forms may 2509 be included. Whenever such identities are used, the issuer 2510 alternative name extension MUST be used. 2512 The issuerAltName extension SHOULD NOT be marked critical. 2514 The OID and syntax for this CRL extension are defined in section 2515 4.2.1.8. 2517 5.2.3 CRL Number 2519 The CRL number is a non-critical CRL extension which conveys a 2520 monotonically increasing sequence number for a given CRL scope and 2521 CRL issuer. This extension allows users to easily determine when a 2522 particular CRL supersedes another CRL. CRL numbers also support the 2523 identification of complementary complete CRLs and delta CRLs. CRL 2524 issuers conforming to this profile MUST include this extension in all 2525 CRLs. 2527 If a CRL issuer generates delta CRLs in addition to complete CRLs for 2528 a given scope, the complete CRLs and delta CRLs MUST share one 2529 numbering sequence. If a delta CRL and a complete CRL that cover the 2530 same scope are issued at the same time, they MUST have the same CRL 2531 number and provide the same revocation information. That is, the 2532 combination of the delta CRL and an acceptable complete CRL MUST 2533 provide the same revocation information as the simultaneously issued 2534 complete CRL. 2536 If a CRL issuer generates two CRLs (two complete CRLs, two delta 2537 CRLs, or a complete CRL and a delta CRL) for the same scope at 2538 different times, the two CRLs MUST NOT have the same CRL number. 2539 That is, if the this update field (section 5.1.2.4) in the two CRLs 2540 are not identical, the CRL numbers MUST be different. 2542 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 2544 CRLNumber ::= INTEGER (0..MAX) 2546 5.2.4 Delta CRL Indicator 2548 The delta CRL indicator is a critical CRL extension that identifies a 2549 CRL as being a delta CRL. Delta CRLs contain updates to revocation 2550 information previously distributed, rather than all the information 2551 that would appear in a complete CRL. The use of delta CRLs can 2552 significantly reduce network load and processing time in some 2553 environments. Delta CRLs are generally smaller than the CRLs they 2554 update, so applications that obtain delta CRLs consume less network 2555 bandwidth than applications that obtain the corresponding complete 2556 CRLs. Applications which store revocation information in a format 2557 other than the CRL structure can add new revocation information to 2558 the local database without reprocessing information. 2560 The delta CRL indicator extension contains the single value of type 2561 BaseCRLNumber. This value identifies the CRL number of the complete 2562 CRL that was used as the foundation in the generation of this delta 2563 CRL. The referenced base CRL is a CRL that was explicitly issued as 2564 a CRL that is complete for a given scope. The CRL containing the 2565 delta CRL indicator extension contains all updates to the revocation 2566 status for that same scope. The combination of a CRL containing the 2567 delta CRL indicator extension plus the CRL referenced in the 2568 BaseCRLNumber component of this extension is equivalent to a complete 2569 CRL, for the applicable scope, at the time of publication of the 2570 delta CRL. 2572 When a conforming CRL issuer generates a delta CRL, the delta CRL 2573 MUST include a critical delta CRL indicator extension. 2575 When a delta CRL is issued, it MUST cover the same set of reasons and 2576 the same set of certificates that were covered by the base CRL it 2577 references. That is, the scope of the delta CRL MUST be the same as 2578 the scope of the complete CRL referenced as the base. The referenced 2579 base CRL and the delta CRL MUST omit the issuing distribution point 2580 extension or contain identical issuing distribution point extensions. 2581 Further, the CRL issuer MUST use the same private key to sign the 2582 delta CRL and any complete CRL that it can be used to update. 2584 An application that supports delta CRLs can construct a CRL that is 2585 complete for a given scope by combining a delta CRL for that scope 2586 with either an issued CRL that is complete for that scope or a 2587 locally constructed CRL that is complete for that scope. 2589 When a delta CRL is combined with a complete CRL or a locally 2590 constructed CRL, the resulting locally constructed CRL has the CRL 2591 number specified in the CRL number extension found in the delta CRL 2592 used in its construction. In addition, the resulting locally 2593 constructed CRL has the thisUpdate and nextUpdate times specified in 2594 the corresponding fields of the delta CRL used in its construction. 2595 In addition, the locally constructed CRL inherits the issuing 2596 distribution point from the delta CRL. 2598 A complete CRL and a delta CRL MAY be combined if the following four 2599 conditions are satisfied: 2601 (a) The complete CRL and delta CRL have the same issuer. 2603 (b) The complete CRL and delta CRL have the same scope. The two 2604 CRLs have the same scope if either of the following conditions are 2605 met: 2607 (1) The issuingDistributionPoint extension is omitted from 2608 both the complete CRL and the delta CRL. 2610 (2) The issuingDistributionPoint extension is present in both 2611 the complete CRL and the delta CRL, and the values for each of 2612 the fields in the extensions are the same in both CRLs. 2614 (c) The CRL number of the complete CRL is greater than or equal 2615 to the BaseCRLNumber specified in the delta CRL. That is, the 2616 complete CRL contains (at a minimum) all the revocation 2617 information held by the referenced base CRL. 2619 (d) The CRL number of the complete CRL is less than the CRL 2620 number of the delta CRL. That is, the delta CRL follows the 2621 complete CRL in the numbering sequence. 2623 CRL issuers MUST ensure that the combination of a delta CRL and any 2624 appropriate complete CRL accurately reflects the current revocation 2625 status. The CRL issuer MUST include an entry in the delta CRL for 2626 each certificate within the scope of the delta CRL whose status has 2627 changed since the generation of the referenced base CRL: 2629 (a) If the certificate is revoked for a reason included in the 2630 scope of the CRL, list the certificate as revoked. 2632 (b) If not (a), list the certificate with the reason code 2633 removeFromCRL. 2635 The status of a certificate is considered to have changed if it is 2636 revoked, placed on hold, released from hold, or if its revocation 2637 reason changes. 2639 It is appropriate to list a certificate with reason code 2640 removeFromCRL on a delta CRL even if the certificate was not on hold 2641 in the referenced base CRL. If the certificate was placed on hold in 2642 any CRL issued after the base but before this delta CRL and then 2643 released from hold, it MUST be listed on the delta CRL with 2644 revocation reason removeFromCRL. 2646 A CRL issuer MAY optionally list a certificate on a delta CRL with 2647 reason code removeFromCRL if the notAfter time specified in the 2648 certificate precedes the thisUpdate time specified in the delta CRL 2649 and the certificate was listed on the referenced base CRL or in any 2650 CRL issued after the base but before this delta CRL. 2652 If a certificate revocation notice first appears on a delta CRL, then 2653 it is possible for the certificate validity period to expire before 2654 the next complete CRL for the same scope is issued. In this case, 2655 the revocation notice MUST be included in all subsequent delta CRLs 2656 until the revocation notice is included on at least one explicitly 2657 issued complete CRL for this scope. 2659 Applications that support delta CRLs are not required to support 2660 local construction of CRLs. Since the delta CRLs are required to 2661 reference a base CRL that was explicitly issued as a complete CRL, 2662 the information required to process delta CRLs is always available in 2663 a complete CRL. 2665 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 2667 BaseCRLNumber ::= CRLNumber 2669 5.2.5 Issuing Distribution Point 2671 The issuing distribution point is a critical CRL extension that 2672 identifies the CRL distribution point and scope for a particular CRL, 2673 and it indicates whether the CRL covers revocation for end entity 2674 certificates only, CA certificates only, attribute certificates 2675 only, or a limited set of reason codes. Although the extension is 2676 critical, conforming implementations are not required to support this 2677 extension. 2679 The CRL is signed using the CRL issuer's private key. CRL 2680 Distribution Points do not have their own key pairs. If the CRL is 2681 stored in the X.500 Directory, it is stored in the Directory entry 2682 corresponding to the CRL distribution point, which may be different 2683 than the Directory entry of the CRL issuer. 2685 The reason codes associated with a distribution point MUST be 2686 specified in onlySomeReasons. If onlySomeReasons does not appear, 2687 the distribution point MUST contain revocations for all reason codes. 2688 CAs may use CRL distribution points to partition the CRL on the basis 2689 of compromise and routine revocation. In this case, the revocations 2690 with reason code keyCompromise (1), cACompromise (2), and 2691 aACompromise (8) appear in one distribution point, and the 2692 revocations with other reason codes appear in another distribution 2693 point. 2695 If the distributionPoint field is present and contains a URI, the 2696 following semantics MUST be assumed: the object is a pointer to the 2697 most current CRL issued by this CRL issuer. The URI schemes ftp, 2698 http, mailto [RFC1738] and ldap [RFC1778] are defined for this 2699 purpose. The URI MUST be an absolute pathname, not a relative 2700 pathname, and MUST specify the host. 2702 If the distributionPoint field is absent, the CRL MUST contain 2703 entries for all revoked unexpired certificates issued by the CRL 2704 issuer, if any, within the scope of the CRL. 2706 The CRL issuer MUST assert the indirectCRL boolean, if the scope of 2707 the CRL includes certificates issued by authorities other than the 2708 CRL issuer. The authority responsible for each entry is indicated by 2709 the certificate issuer CRL entry extension (section 5.3.4). 2711 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 2713 issuingDistributionPoint ::= SEQUENCE { 2714 distributionPoint [0] DistributionPointName OPTIONAL, 2715 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 2716 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 2717 onlySomeReasons [3] ReasonFlags OPTIONAL, 2718 indirectCRL [4] BOOLEAN DEFAULT FALSE, 2719 onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE } 2721 5.2.6 Freshest CRL (a.k.a. Delta CRL Distribution Point) 2723 The freshest CRL extension identifies how delta CRL information for 2724 this complete CRL is obtained. The extension MUST be non-critical. 2726 This extension MUST NOT appear in delta CRLs. 2728 The same syntax is used for this extension as the 2729 cRLDistributionPoints certificate extension, and is described in 2730 section 4.2.1.14. The same conventions apply to both extensions. 2732 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } 2734 FreshestCRL ::= CRLDistributionPoints 2736 5.3 CRL Entry Extensions 2738 The CRL entry extensions already defined by ANSI X9 and ISO/IEC/ITU 2739 for X.509 v2 CRLs provide methods for associating additional 2740 attributes with CRL entries [X.509] [X9.55]. The X.509 v2 CRL format 2741 also allows communities to define private CRL entry extensions to 2742 carry information unique to those communities. Each extension in a 2743 CRL entry may be designated as critical or non-critical. A CRL 2744 validation MUST fail if it encounters a critical CRL entry extension 2745 which it does not know how to process. However, an unrecognized non- 2746 critical CRL entry extension may be ignored. The following 2747 subsections present recommended extensions used within Internet CRL 2748 entries and standard locations for information. Communities MAY 2749 elect to use additional CRL entry extensions; however, caution SHOULD 2750 be exercised in adopting any critical extensions in CRL entries which 2751 might be used in a general context. 2753 All CRL entry extensions used in this specification are non-critical. 2754 Support for these extensions is optional for conforming CRL issuers 2755 and applications. However, CRL issuers SHOULD include reason codes 2756 (section 5.3.1) and invalidity dates (section 5.3.3) whenever this 2757 information is available. 2759 5.3.1 Reason Code 2761 The reasonCode is a non-critical CRL entry extension that identifies 2762 the reason for the certificate revocation. CRL issuers are strongly 2763 encouraged to include meaningful reason codes in CRL entries; 2764 however, the reason code CRL entry extension SHOULD be absent instead 2765 of using the unspecified (0) reasonCode value. 2767 id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 } 2769 -- reasonCode ::= { CRLReason } 2771 CRLReason ::= ENUMERATED { 2772 unspecified (0), 2773 keyCompromise (1), 2774 cACompromise (2), 2775 affiliationChanged (3), 2776 superseded (4), 2777 cessationOfOperation (5), 2778 certificateHold (6), 2779 removeFromCRL (8), 2780 privilegeWithdrawn (9), 2781 aACompromise (10) } 2783 5.3.2 Hold Instruction Code 2785 The hold instruction code is a non-critical CRL entry extension that 2786 provides a registered instruction identifier which indicates the 2787 action to be taken after encountering a certificate that has been 2788 placed on hold. 2790 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 2792 holdInstructionCode ::= OBJECT IDENTIFIER 2794 The following instruction codes have been defined. Conforming 2795 applications that process this extension MUST recognize the following 2796 instruction codes. 2798 holdInstruction OBJECT IDENTIFIER ::= 2799 { iso(1) member-body(2) us(840) x9-57(10040) 2 } 2801 id-holdinstruction-none OBJECT IDENTIFIER ::= {holdInstruction 1} 2802 id-holdinstruction-callissuer 2803 OBJECT IDENTIFIER ::= {holdInstruction 2} 2804 id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3} 2806 Conforming applications which encounter an id-holdinstruction- 2807 callissuer MUST call the certificate issuer or reject the 2808 certificate. Conforming applications which encounter an id- 2809 holdinstruction-reject MUST reject the certificate. The hold 2810 instruction id-holdinstruction-none is semantically equivalent to the 2811 absence of a holdInstructionCode, and its use is strongly deprecated 2812 for the Internet PKI. 2814 5.3.3 Invalidity Date 2816 The invalidity date is a non-critical CRL entry extension that 2817 provides the date on which it is known or suspected that the private 2818 key was compromised or that the certificate otherwise became invalid. 2819 This date may be earlier than the revocation date in the CRL entry, 2820 which is the date at which the CA processed the revocation. When a 2821 revocation is first posted by a CRL issuer in a CRL, the invalidity 2822 date may precede the date of issue of earlier CRLs, but the 2823 revocation date SHOULD NOT precede the date of issue of earlier CRLs. 2824 Whenever this information is available, CRL issuers are strongly 2825 encouraged to share it with CRL users. 2827 The GeneralizedTime values included in this field MUST be expressed 2828 in Greenwich Mean Time (Zulu), and MUST be specified and interpreted 2829 as defined in section 4.1.2.5.2. 2831 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 2833 invalidityDate ::= GeneralizedTime 2835 5.3.4 Certificate Issuer 2837 This CRL entry extension identifies the certificate issuer associated 2838 with an entry in an indirect CRL, i.e. a CRL that has the indirectCRL 2839 indicator set in its issuing distribution point extension. If this 2840 extension is not present on the first entry in an indirect CRL, the 2841 certificate issuer defaults to the CRL issuer. On subsequent entries 2842 in an indirect CRL, if this extension is not present, the certificate 2843 issuer for the entry is the same as that for the preceding entry. 2844 This field is defined as follows: 2846 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } 2848 certificateIssuer ::= GeneralNames 2850 If used by conforming CRL issuers, this extension MUST always be 2851 critical. If an implementation ignored this extension it could not 2852 correctly attribute CRL entries to certificates. This specification 2853 RECOMMENDS that implementations recognize this extension. 2855 6 Certification Path Validation 2857 Certification path validation procedures for the Internet PKI are 2858 based on the algorithm supplied in [X.509]. Certification path 2859 processing verifies the binding between the subject distinguished 2860 name and/or subject alternative name and subject public key. The 2861 binding is limited by constraints which are specified in the 2862 certificates which comprise the path and inputs which are specified 2863 by the relying party. The basic constraints and policy constraints 2864 extensions allow the certification path processing logic to automate 2865 the decision making process. 2867 This section describes an algorithm for validating certification 2868 paths. Conforming implementations of this specification are not 2869 required to implement this algorithm, but MUST provide functionality 2870 equivalent to the external behavior resulting from this procedure. 2871 Any algorithm may be used by a particular implementation so long as 2872 it derives the correct result. 2874 In section 6.1, the text describes basic path validation. Valid 2875 paths begin with certificates issued by a "most-trusted CA". The 2876 algorithm requires the public key of the CA, the CA's name, and any 2877 constraints upon the set of paths which may be validated using this 2878 key. 2880 The selection of a "most-trusted CA" is a matter of policy: it could 2881 be the top CA in a hierarchical PKI; the CA that issued the 2882 verifier's own certificate(s); or any other CA in a network PKI. The 2883 path validation procedure is the same regardless of the choice of 2884 "most-trusted CA." In addition, different applications may rely on 2885 different "most-trusted CA", or may accept paths that begin with any 2886 of a set of "most-trusted CAs." 2888 Section 6.2 describes methods for using the path validation algorithm 2889 in specific implementations. Two specific cases are discussed: the 2890 case where paths may begin with one of several trusted CAs; and where 2891 compatibility with the PEM architecture is required. 2893 Section 6.3 describes the steps necessary to determine if a 2894 certificate is revoked or on hold status when CRLs are the revocation 2895 mechanism used by the certificate issuer. 2897 6.1 Basic Path Validation 2899 This text describes an algorithm for X.509 path processing. A 2900 conformant implementation MUST include an X.509 path processing 2901 procedure that is functionally equivalent to the external behavior of 2902 this algorithm. However, support for some of the certificate 2903 extensions processed in this algorithm are OPTIONAL for compliant 2904 implementations. Clients that do not support these extensions MAY 2905 omit the corresponding steps in the path validation algorithm. 2907 For example, clients are NOT REQUIRED to support the policy mapping 2908 extension. Clients that do not support this extension MAY omit the 2909 path validation steps where policy mappings are processed. Note that 2910 clients MUST reject the certificate if it contains an unsupported 2911 critical extension. 2913 The trust anchor is an input to the algorithm. There is no 2914 requirement that the same trust anchor be used to validate all 2915 certification paths. Different trust anchors MAY be used to validate 2916 different paths, as discussed further in Section 6.2. 2918 The primary goal of path validation is to verify the binding between 2919 a subject distinguished name or subject alternative name and subject 2920 public key, as represented in the end entity certificate, based on 2921 the public key of the trust anchor. This requires obtaining a 2922 sequence of certificates that support that binding. The procedure 2923 performed to obtain this sequence of certificates is outside the 2924 scope of this specification. 2926 To meet this goal, the path validation process verifies, among other 2927 things, that a prospective certification path (a sequence of n 2928 certificates) satisfies the following conditions: 2930 (a) for all x in {1, ..., n-1}, the subject of certificate x is 2931 the issuer of certificate x+1; 2933 (b) certificate 1 is issued by the trust anchor; 2935 (c) certificate n is the end entity certificate; and 2937 (d) for all x in {1, ..., n}, the certificate was valid at the 2938 time in question. 2940 A particular certification path may not, however, be appropriate for 2941 all applications. Therefore, an application MAY augment this 2942 algorithm to further limit the set of valid paths. The path 2943 validation process also determines the set of certificate policies 2944 that are valid for this path, based on the certificate policies 2945 extension, policy mapping extension, policy constraints extension, 2946 and inhibit any-policy extension. To achieve this, the path 2947 validation algorithm constructs a valid policy tree. If the set of 2948 certificate policies that are valid for this path is not empty, then 2949 the result will be a valid policy tree of depth n, otherwise the 2950 result will be a null valid policy tree. 2952 A certificate is self-issued if the DNs that appear in the subject 2953 and issuer fields are identical and are not empty. In general, the 2954 issuer and subject of the certificates that make up a path are 2955 different for each certificate. However, a CA may issue a 2956 certificate to itself to support key rollover or changes in 2957 certificate policies. These self-issued certificates are not counted 2958 when evaluating path length or name constraints. 2960 This section presents the algorithm in four basic steps: (1) 2961 initialization, (2) basic certificate processing, (3) preparation for 2962 the next certificate, and (4) wrap-up. Steps (1) and (4) are 2963 performed exactly once. Step (2) is performed for all certificates 2964 in the path. Step (3) is performed for all certificates in the path 2965 except the final certificate. Figure 2 provides a high-level 2966 flowchart of this algorithm. 2968 +-------+ 2969 | START | 2970 +-------+ 2971 | 2972 V 2973 +----------------+ 2974 | Initialization | 2975 +----------------+ 2976 | 2977 +<--------------------+ 2978 | | 2979 V | 2980 +----------------+ | 2981 | Process Cert | | 2982 +----------------+ | 2983 | | 2984 V | 2985 +================+ | 2986 | IF Last Cert | | 2987 | in Path | | 2988 +================+ | 2989 | | | 2990 THEN | | ELSE | 2991 V V | 2992 +----------------+ +----------------+ | 2993 | Wrap up | | Prepare for | | 2994 +----------------+ | Next Cert | | 2995 | +----------------+ | 2996 V | | 2997 +-------+ +--------------+ 2998 | STOP | 2999 +-------+ 3001 Figure 2. Certification Path Processing Flowchart 3003 6.1.1 Inputs 3005 This algorithm assumes the following seven inputs are provided to the 3006 path processing logic: 3008 (a) a prospective certification path of length n; 3010 (b) the time, T, for which the validity of the path should be 3011 determined. This may be the current date/time, or some point in 3012 the past. 3014 (c) user-initial-policy-set: A set of certificate policy 3015 identifiers naming the policies that are acceptable to the 3016 certificate user. The user-initial-policy-set contains the special 3017 value any-policy if the user is not concerned about certificate 3018 policy. 3020 (d) trust anchor information, describing a CA that serves as a 3021 trust anchor for the certification path. The trust anchor 3022 information includes: 3024 (1) the trusted issuer name, 3026 (2) the trusted public key algorithm, 3028 (3) the trusted public key, and 3030 (4) optionally, the trusted public key parameters associated 3031 with the public key. 3033 The trust anchor information may be provided to the path 3034 processing procedure in the form of a self-signed certificate. 3035 The trusted anchor information is trusted because it was delivered 3036 to the path processing procedure by some trustworthy out-of-band 3037 procedure. If the trusted public key algorithm requires 3038 parameters, then the parameters are provided along with the 3039 trusted public key. 3041 (e) initial-policy-mapping-inhibit, which indicates if policy 3042 mapping is allowed in the certification path. 3044 (f) initial-explicit-policy, which indicates if the path must be 3045 valid for at least one of the certificate policies in the user- 3046 initial-policy-set. 3048 (g) initial-any-policy-inhibit, which indicates whether the any- 3049 policy OID should be processed if it is included in a certificate. 3051 6.1.2 Initialization 3053 The initialization phase establishes eleven state variables based 3054 upon the seven inputs: 3056 (a) valid_policy_tree: A tree of certificate policies with their 3057 optional qualifiers; each of the leaves of the tree represents a 3058 valid policy at this stage in the certification path validation. 3059 If valid policies exist at this stage in the certification path 3060 validation, the depth of the tree is equal to the number of 3061 certificates in the chain that have been processed. If valid 3062 policies do not exist at this stage in the certification path 3063 validation, the tree is set to NULL. Once the tree is set to NULL, 3064 policy processing ceases. 3066 Each node in the valid_policy_tree includes four data objects: the 3067 valid policy, a set of associated policy qualifiers, a set of one 3068 or more expected policy values, and a criticality indicator. If 3069 the node is at depth x, the components of the node have the 3070 following semantics: 3072 (1) The valid_policy is a single policy OID representing a 3073 valid policy for the path of length x. 3075 (2) The qualifier_set is a set of policy qualifiers associated 3076 with the valid policy in certificate x. 3078 (3) The criticality_indicator indicates whether the certificate 3079 policy extension in certificate x was marked as critical. 3081 (4) The expected_policy_set contains one or more policy OIDs 3082 that would satisfy this policy in the certificate x+1. 3084 The initial value of the valid_policy_tree is a single node with 3085 valid_policy any-policy, an empty qualifier_set, an 3086 expected_policy_set with the single value any-policy, and a 3087 criticality_indicator of FALSE. This node is considered to be at 3088 depth zero. 3090 Figure 3 is a graphic representation of the initial state of the 3091 valid_policy_tree. Additional figures will use this format to 3092 describe changes in the valid_policy_tree during path processing. 3094 +----------------+ 3095 | any-policy | <---- valid_policy 3096 +----------------+ 3097 | {} | <---- qualifier_set 3098 +----------------+ 3099 | FALSE | <---- criticality_indicator 3100 +----------------+ 3101 | {any-policy} | <---- expected_policy_set 3102 +----------------+ 3104 Figure 3. Initial value of the valid_policy_tree state variable 3106 (b) permitted_subtrees: A set of root names for each name type 3107 (e.g., X.500 distinguished names, email addresses, or ip 3108 addresses) defining a set of subtrees within which all subject 3109 names in subsequent certificates in the certification path MUST 3110 fall. This variable includes a set for each name type: the 3111 initial value for the set for Distinguished Names is the set of 3112 all Distinguished names; the initial value for the set of RFC822 3113 names is the set of all RFC822 names, etc. 3115 (c) excluded_subtrees: A set of root names for each name type 3116 (e.g., X.500 distinguished names, email addresses, or ip 3117 addresses) defining a set of subtrees within which no subject name 3118 in subsequent certificates in the certification path may fall. 3119 This variable includes a set for each name type, and the initial 3120 value for each set is empty. 3122 (d) explicit_policy: an integer which indicates if a non-NULL 3123 valid_policy_tree is required. The integer indicates the number of 3124 non-self-issued certificates to be processed before this 3125 requirement is imposed. Once set, this variable may be decreased, 3126 but may not be increased. That is, if a certificate in the path 3127 requires a non-NULL valid_policy_tree, a later certificate can not 3128 remove this requirement. If initial-explicit-policy is set, then 3129 the initial value is 0, otherwise the initial value is n+1. 3131 (e) inhibit_any-policy: an integer which indicates whether the 3132 any-policy policy identifier is considered a match. The integer 3133 indicates the number of non-self-issued certificates to be 3134 processed before the any-policy OID, if asserted in a certificate, 3135 is ignored. Once set, this variable may be decreased, but may not 3136 be increased. That is, if a certificate in the path inhibits 3137 processing of any-policy, a later certificate can not permit it. 3138 If initial-any-policy-inhibit is set, then the initial value is 0, 3139 otherwise the initial value is n+1. 3141 (f) policy_mapping: an integer which indicates if policy mapping 3142 is permitted. The integer indicates the number of non-self-issued 3143 certificates to be processed before policy mapping is inhibited. 3144 Once set, this variable may be decreased, but may not be 3145 increased. That is, if a certificate in the path specifies policy 3146 mapping is not permitted, it can not be overridden by a later 3147 certificate. If initial-policy-mapping-inhibit is set, then the 3148 initial value is 0, otherwise the initial value is n+1. 3150 (g) working_public_key_algorithm: the digital signature algorithm 3151 used to verify the signature of a certificate. The 3152 working_public_key_algorithm is initialized from the trusted 3153 public key algorithm provided in the trust anchor information. 3155 (h) working_public_key: the public key used to verify the 3156 signature of a certificate. The working_public_key is initialized 3157 from the trusted public key provided in the trust anchor 3158 information. 3160 (i) working_public_key_parameters: parameters associated with the 3161 current public key, that may required to verify a signature 3162 (depending upon the algorithm). The working_public_key_parameters 3163 variable is initialized from the trusted public key parameters 3164 provided in the trust anchor information. 3166 (j) working_issuer_name: the issuer distinguished name expected 3167 in the next certificate in the chain. The working_issuer_name is 3168 initialized to the trusted issuer provided in the trust anchor 3169 information. 3171 (k) max_path_length: this integer is initialized to n, and is 3172 reset by the path length constraint field within the basic 3173 constraints extension of a CA certificate. 3175 Upon completion of the initialization steps, perform the basic 3176 certificate processing steps specified in 6.1.3. 3178 6.1.3 Basic Certificate Processing 3180 The basic path processing actions to be performed for certificate i 3181 are listed below. 3183 (a) Verify the basic certificate information. The certificate 3184 MUST satisfy each of the following: 3186 (1) The certificate was signed with the 3187 working_public_key_algorithm using the working_public_key and 3188 the working_public_key_parameters. 3190 (2) The certificate validity period includes time T. 3192 (3) At time T, the certificate is not revoked and is not on 3193 hold status. This may be determined by obtaining the 3194 appropriate CRL (section 6.3), status information, or by out- 3195 of-band mechanisms. 3197 (4) The certificate issuer name is the working_issuer_name. 3199 (b) If certificate i is self-issued and it is not the final 3200 certificate in the path, skip this step for certificate i. 3201 Otherwise, verify that the subject name is within one of the 3202 permitted_subtrees for X.500 distinguished names, and verify that 3203 each of the alternative names in the subjectAltName extension 3204 (critical or non-critical) is within one of the permitted_subtrees 3205 for that name type. 3207 (c) If certificate i is self-issued and it is not the final 3208 certificate in the path, skip this step for certificate i. 3209 Otherwise, verify that the subject name is not within one of the 3210 excluded_subtrees for X.500 distinguished names, and verify that 3211 each of the alternative names in the subjectAltName extension 3212 (critical or non-critical) is not within one of the 3213 excluded_subtrees for that name type. 3215 (d) If the certificate policies extension is present in the 3216 certificiate and the valid_policy_tree is not NULL, process the 3217 policy information by performing the following steps in order: 3219 (1) For each policy P not equal to any-policy in the 3220 certificate policies extension, let P-OID denote the OID in 3221 policy P and P-Q denote the qualifier set for policy P. 3222 Perform the following steps in order: 3224 (i) If the valid_policy_tree includes a node of depth i-1 3225 where P-OID is in the expected_policy_set, create a child 3226 node as follows: set the valid_policy to OID-P; set the 3227 qualifier_set to P-Q, and set the expected_policy_set to {P- 3228 OID}. 3230 For example, consider a valid_policy_tree with a node of 3231 depth i-1 where the expected_policy_set is {Gold, White}. 3232 Assume the certificate policies Gold and Silver appear in 3233 the certificate policies extension of certificate i. The 3234 Gold policy is matched but the Silver policy is not. This 3235 rule will generate a child node of depth i for the Gold 3236 policy. The result is shown as Figure 4. 3238 |-----------------| 3239 | Red | 3240 |-----------------| 3241 | {} | 3242 |-----------------| node of depth i-1 3243 | FALSE | 3244 |-----------------| 3245 | {Gold, White} | 3246 |-----------------| 3247 | 3248 | 3249 | 3250 V 3251 |-----------------| 3252 | Gold | 3253 |-----------------| 3254 | {} | 3255 |-----------------| node of depth i 3256 | uninitialized | 3257 |-----------------| 3258 | {Gold} | 3259 |-----------------| 3261 Figure 4. Processing an exact match 3263 (ii) If there was no match in step (i) and the 3264 valid_policy_tree includes a node of depth i-1 with the 3265 valid policy any-policy, generate a child node with the 3266 following values: set the valid_policy to P-OID; set the 3267 qualifier_set to P-Q, and set the expected_policy_set to {P- 3268 OID}. 3270 For example, consider a valid_policy_tree with a node of 3271 depth i-1 where the valid_policy is any-policy. Assume the 3272 certificate policies Gold and Silver appear in the 3273 certificate policies extension of certificate i. The Gold 3274 policy does not have a qualifier, but the Silver policy has 3275 the qualifier Q-Silver. If Gold and Silver were not matched 3276 in (i) above, this rule will generate two child nodes of 3277 depth i, one for each policy. The result is shown as Figure 3278 5. 3280 |-----------------| 3281 | any-policy | 3282 |-----------------| 3283 | {} | 3284 |-----------------| node of depth i-1 3285 | FALSE | 3286 |-----------------| 3287 | {any-policy} | 3288 |-----------------| 3289 / \ 3290 / \ 3291 / \ 3292 / \ 3293 |-----------------| |-----------------| 3294 | Gold | | Silver | 3295 |-----------------| |-----------------| 3296 | {} | | {Q-Silver} | 3297 |-----------------| nodes of |-----------------| 3298 | uninitialized | depth i | uninitialized | 3299 |-----------------| |-----------------| 3300 | {Gold} | | {Silver} | 3301 |-----------------| |-----------------| 3303 Figure 5. Processing unmatched policies when a leaf node 3304 specifies any-policy 3306 (2) If the certificate policies extension includes the policy 3307 any-policy with the qualifier set AP-Q and inhibit_any-policy 3308 is greater than 0, then: 3310 For each node in the valid_policy_tree of depth i-1, for each 3311 value in the expected_policy_set (including any-policy) that 3312 does not appear in a child node, create a child node with the 3313 following values: set the valid_policy to the value from the 3314 expected_policy_set in the parent node; set the qualifier_set 3315 to AP-Q, and set the expected_policy_set to the value in the 3316 valid_policy from this node. 3318 For example, consider a valid_policy_tree with a node of depth 3319 i-1 where the expected_policy_set = {Gold, Silver}. Assume 3320 any-policy appears in the certificate policies extension of 3321 certificate i, but Gold and Silver do not. This rule will 3322 generate two child nodes of depth i, one for each policy. The 3323 result is shown below as Figure 6. 3325 |-----------------| 3326 | Red | 3327 |-----------------| 3328 | {} | 3329 |-----------------| node of depth i-1 3330 | FALSE | 3331 |-----------------| 3332 | {Gold, Silver} | 3333 |-----------------| 3334 / \ 3335 / \ 3336 / \ 3337 / \ 3338 |-----------------| |-----------------| 3339 | Gold | | Silver | 3340 |-----------------| |-----------------| 3341 | {} | | {} | 3342 |-----------------| nodes of |-----------------| 3343 | uninitialized | depth i | uninitialized | 3344 |-----------------| |-----------------| 3345 | {Gold} | | {Silver} | 3346 |-----------------| |-----------------| 3348 Figure 6. Processing unmatched policies when the certificate 3349 policies extension specifies any-policy 3351 (3) If there is a node in the valid_policy_tree of depth i-1 or 3352 less without any child nodes, delete that node. Repeat this 3353 step until there are no nodes of depth i-1 or less without 3354 children. 3356 For example, consider the valid_policy_tree shown in Figure 7 3357 below. The two nodes at depth i-1 that are marked with an 'X' 3358 have no children, and are deleted. Applying this rule to the 3359 resulting tree will cause the node at depth i-2 that is marked 3360 with an 'Y' to be deleted. The following application of the 3361 rule does not cause any nodes to be deleted, and this step is 3362 complete. 3364 +-----------+ 3365 | | node of depth i-3 3366 +-----------+ 3367 / | \ 3368 / | \ 3369 / | \ 3370 +-----------+ +-----------+ +-----------+ 3371 | | | | | Y | nodes of 3372 +-----------+ +-----------+ +-----------+ depth i-2 3373 / \ || || 3374 / \ || || 3375 / \ || || 3376 +-----------+ +-----------+ +-----------+ +-----------+ nodes of 3377 | | | X | | | | X | depth 3378 +-----------+ +-----------+ +-----------+ +-----------+ i-1 3379 | / | \ 3380 | / | \ 3381 | / | \ 3382 +-----------+ +-----------+ +-----------+ +-----------+ nodes of 3383 | | | | | | | | depth 3384 +-----------+ +-----------+ +-----------+ +-----------+ i 3386 Figure 7. Pruning the valid_policy_tree 3388 (4) If the certificate policies extension was marked as 3389 critical, set the criticality_indicator in all nodes of depth i 3390 to TRUE. If the certificate policies extension was not marked 3391 critical, set the criticality_indicator in all nodes of depth i 3392 to FALSE. 3394 (e) If the certificate policies extension is not present, set the 3395 valid_policy_tree to NULL. 3397 (f) verify that either explicit_policy is greater than 0 or the 3398 valid_policy_tree is not equal to NULL; 3400 If any of steps (a), (b), (c), or (f) fails, the procedure 3401 terminates, returning a failure indication and an appropriate reason. 3403 If i is not equal to n, continue by performing the preparatory steps 3404 listed in 6.1.4. If i is equal to n, perform the wrap-up steps 3405 listed in 6.1.5. 3407 6.1.4 Preparation for Certificate i+1 3409 To prepare for processing of certificate i+1, perform the following 3410 steps for certificate i: 3412 (a) If a policy mapping extension is present, verify that the 3413 special value any-policy does not appear as an issuerDomainPolicy 3414 or a subjectDomainPolicy. 3416 (b) If a policy mapping extension is present, then for each 3417 issuerDomainPolicy ID-P in the policy mapping extension: 3419 (1) If the policy_mapping variable is greater than 0, for each 3420 node in the valid_policy_tree of depth i where ID-P is the 3421 valid_policy, set expected_policy_set to the set of 3422 subjectDomainPolicy values that are specified as equivalent to 3423 ID-P by the policy mapping extension. 3425 If no node of depth i in the valid_policy_tree has a 3426 valid_policy of ID-P but there is a node of depth i with a 3427 valid_policy of any-policy, then generate a child node of the 3428 node of depth i-1 that has a valid_policy of any-policy as 3429 follows: 3431 (i) set the valid_policy to ID-P; 3433 (ii) set the qualifier_set to the qualifier set of the 3434 policy any-policy in the certificate policies extension of 3435 certificate i; 3437 (iii) set the criticality_indicator to the criticality of 3438 the certificate policies extension of certificate i; 3440 (iv) and set the expected_policy_set to the set of 3441 subjectDomainPolicy values that are specified as equivalent 3442 to ID-P by the policy mappings extension. 3444 (2) If the policy_mapping variable is equal to 0: 3446 (i) delete each node of depth i in the valid_policy_tree 3447 where ID-P is the valid_policy. 3449 (ii) If there is a node in the valid_policy_tree of depth 3450 i-1 or less without any child nodes, delete that node. 3451 Repeat this step until there are no nodes of depth i-1 or 3452 less without children. 3454 (c) Assign the certificate subject name to working_issuer_name. 3456 (d) Assign the certificate subjectPublicKey to working_public_key. 3458 (e) If the subjectPublicKeyInfo field of the certificate contains 3459 an algorithm field with non-null parameters, assign the parameters 3460 to the working_public_key_parameters variable. 3462 If the subjectPublicKeyInfo field of the certificate contains an 3463 algorithm field with null parameters or parameters are omitted, 3464 compare the certificate subjectPublicKey algorithm to the 3465 working_public_key_algorithm. If the certificate subjectPublicKey 3466 algorithm and the working_public_key_algorithm are different, set 3467 the working_public_key_parameters to null. 3469 (f) Assign the certificate subjectPublicKey algorithm to the 3470 working_public_key_algorithm variable. 3472 (g) If a name constraints extension is included in the 3473 certificate, modify the permitted_subtrees and excluded_subtrees 3474 state variables as follows: 3476 (1) If permittedSubtrees is present in the certificate, set the 3477 permitted_subtrees state variable to the intersection of its 3478 previous value and the value indicated in the extension field. 3479 If permittedSubtrees does not include a particular name type, 3480 the permitted_subtrees state variable is unchanged for that 3481 name type. 3483 (2) If excludedSubtrees is present in the certificate, set the 3484 excluded_subtrees state variable to the union of its previous 3485 value and the value indicated in the extension field. If 3486 excludedSubtrees does not include a particular name type, the 3487 excluded_subtrees state variable is unchanged for that name 3488 type. 3490 (h) If the issuer and subject names are not identical: 3492 (1) If explicit_policy is not 0, decrement explicit_policy by 3493 1. 3495 (2) If policy_mapping is not 0, decrement policy_mapping by 1. 3497 (3) If inhibit_any-policy is not 0, decrement inhibit_any- 3498 policy by 1. 3500 (i) If a policy constraints extension is included in the 3501 certificate, modify the explicit_policy and policy_mapping state 3502 variables as follows: 3504 (1) If requireExplicitPolicy is present and is less than 3505 explicit_policy, set explicit_policy to the value of 3506 requireExplicitPolicy. 3508 (2) If inhibitPolicyMapping is present and is less than 3509 policy_mapping, set policy_mapping to the value of 3510 inhibitPolicyMapping. 3512 (j) If the inhibitAnyPolicy extension is included in the 3513 certificate and is less than inhibit_any-policy, set inhibit_any- 3514 policy to the value of inhibitAnyPolicy. 3516 (k) Verify that the certificate is a CA certificate (as specified 3517 in a basicConstraints extension or as verified out-of-band). 3519 (l) If the certificate was not self-issued, verify that 3520 max_path_length is greater than zero and decrement max_path_length 3521 by 1. 3523 (m) If pathLengthConstraint is present in the certificate and is 3524 less than max_path_length, set max_path_length to the value of 3525 pathLengthConstraint. 3527 (n) If a key usage extension is present and marked critical, 3528 verify that the keyCertSign bit is set. 3530 (o) Recognize and process any other critical extension present in 3531 the certificate. 3533 If check (a), (k), (l), (n) or (o) fails, the procedure terminates, 3534 returning a failure indication and an appropriate reason. 3536 If (a), (k), (l), (n) and (o) have completed successfully, increment 3537 i and perform the basic certificate processing specified in 6.1.2. 3539 6.1.5 Wrap-up procedure 3541 To complete the processing of the end entity certificate, perform the 3542 following steps for certificate n: 3544 (a) If certificate n was not self-issued and explicit_policy is 3545 not 0, decrement explicit_policy by 1. 3547 (b) If a policy constraints extension is included in the 3548 certificate and requireExplicitPolicy is present and has a value 3549 of 0, set the explicit_policy state variable to 0. 3551 (c) Assign the certificate subjectPublicKey to working_public_key. 3553 (d) If the subjectPublicKeyInfo field of the certificate contains 3554 an algorithm field with non-null parameters, assign the parameters 3555 to the working_public_key_parameters variable. 3557 If the subjectPublicKeyInfo field of the certificate contains an 3558 algorithm field with null parameters or parameters are omitted, 3559 compare the certificate subjectPublicKey algorithm to the 3560 working_public_key_algorithm. If the certificate subjectPublicKey 3561 algorithm and the working_public_key_algorithm are different, set 3562 the working_public_key_parameters to null. 3564 (e) Assign the certificate subjectPublicKey algorithm to the 3565 working_public_key_algorithm variable. 3567 (f) Recognize and process any other critical extension present in 3568 the certificate n. 3570 (g) Calculate the intersection of the valid_policy_tree and the 3571 user-initial-policy-set, as follows: 3573 (i) If the valid_policy_tree is NULL, the intersection is NULL. 3575 (ii) If the valid_policy_tree is not NULL and the user-initial- 3576 policy-set is any-policy, the intersection is the entire 3577 valid_policy_tree. 3579 (iii) If the valid_policy_tree is not NULL and the user- 3580 initial-policy-set is not any-policy, calculate the 3581 intersection of the valid_policy_tree and the user-initial- 3582 policy-set as follows: 3584 1. Determine the set of policy nodes whose parent nodes have 3585 a valid_policy of any-policy. This is the 3586 valid_policy_node_set. 3588 2. If the valid_policy of any node in the 3589 valid_policy_node_set is not in the user-initial-policy-set 3590 and is not any-policy, delete this node and all its 3591 children. 3593 3. If there is a node in the valid_policy_tree of depth n-1 3594 or less without any child nodes, delete that node. Repeat 3595 this step until there are no nodes of depth n-1 or less 3596 without children. 3598 If either (1) the value of explicit_policy variable is greater than 3599 zero, or (2) the valid_policy_tree is not NULL, then path processing 3600 has succeeded. 3602 6.1.6 Outputs 3604 If path processing succeeds, the procedure terminates, returning a 3605 success indication together with final value of the 3606 valid_policy_tree, the working_public_key, the 3607 working_public_key_algorithm, and the working_public_key_parameters. 3609 6.2 Using the Path Validation Algorithm 3611 The path validation algorithm describes the process of validating a 3612 single certification path. While each certification path begins with 3613 a specific trust anchor, there is no requirement that all 3614 certification paths validated by a particular system share a single 3615 trust anchor. An implementation that supports multiple trust anchors 3616 MAY augment the algorithm presented in section 6.1 to further limit 3617 the set of valid certification paths which begin with a particular 3618 trust anchor. For example, an implementation MAY modify the 3619 algorithm to apply name constraints to a specific trust anchor during 3620 the initialization phase, or the application MAY require the presence 3621 of a particular alternative name form in the end entity certificate, 3622 or the application MAY impose requirements on application-specific 3623 extensions. Thus, the path validation algorithm presented in section 3624 6.1 defines the minimum conditions for a path to be considered valid. 3626 The selection of one or more trusted CAs is a local decision. A 3627 system may provide any one of its trusted CAs as the trust anchor for 3628 a particular path. The inputs to the path validation algorithm may 3629 be different for each path. The inputs used to process a path may 3630 reflect application-specific requirements or limitations in the trust 3631 accorded a particular trust anchor. For example, a trusted CA may 3632 only be trusted for a particular certificate policy. This 3633 restriction can be expressed through the inputs to the path 3634 validation procedure. 3636 It is also possible to specify an extended version of the above 3637 certification path processing procedure which results in default 3638 behavior identical to the rules of PEM [RFC 1422]. In this extended 3639 version, additional inputs to the procedure are a list of one or more 3640 Policy Certification Authorities (PCAs) names and an indicator of the 3641 position in the certification path where the PCA is expected. At the 3642 nominated PCA position, the CA name is compared against this list. 3643 If a recognized PCA name is found, then a constraint of 3644 SubordinateToCA is implicitly assumed for the remainder of the 3645 certification path and processing continues. If no valid PCA name is 3646 found, and if the certification path cannot be validated on the basis 3647 of identified policies, then the certification path is considered 3648 invalid. 3650 6.3 CRL Validation 3652 This section describes the steps necessary to determine if a 3653 certificate is revoked or on hold status when CRLs are the revocation 3654 mechanism used by the certificate issuer. Conforming implementations 3655 that support CRLs are not required to implement this algorithm, but 3656 they MUST be functionally equivalent to the external behavior 3657 resulting from this procedure. Any algorithm may be used by a 3658 particular implementation so long as it derives the correct result. 3660 This algorithm assumes that all of the needed CRLs are available in a 3661 local cache. Further, if the next update time of a CRL has passed, 3662 the algorithm assumes a mechanism to fetch a current CRL and place it 3663 in the local CRL cache. 3665 This algorithm defines a set of inputs, a set of state variables, and 3666 processing steps that are performed for each certificate in the path. 3667 The algorithm output is the revocation status of the certificate. 3669 6.3.1 Revocation Inputs 3671 To support revocation processing, the algorithm requires two inputs: 3673 (a) certificate: The algorithm requires the certificate serial 3674 number and issuer name to determine whether a certificate is on a 3675 particular CRL. The basicConstraints extension is used to 3676 determine whether the supplied certificate is associated with a CA 3677 or an end entity. If present, the algorithm uses the 3678 cRLDistributionsPoint and freshestCRL extensions to determine 3679 revocation status. 3681 (b) use-deltas: This boolean input determines whether delta CRLs 3682 are applied to CRLs. 3684 Note that implementations supporting legacy PKIs, such as RFC 1422 3685 and X.509 version 1, will need an additional input indicating 3686 whether the supplied certificate is associated with a CA or an end 3687 entity. 3689 6.3.2 Initialization and Revocation State Variables 3691 To support CRL processing, the algorithm requires the following state 3692 variables: 3694 (a) reasons_mask: This variable contains the set of revocation 3695 reasons supported by the CRLs and delta CRLs processed so far. 3696 The legal members of the set are the possible revocation reason 3697 values: unspecified, keyCompromise, caCompromise, 3698 affiliationChanged, superseded, cessationOfOperation, 3699 certificateHold, privilegeWithdrawn, and aACompromise. The 3700 special value all-reasons is used to denote the set of all legal 3701 members. This variable is initialized to the empty set. 3703 (b) cert_status: This variable contains the status of the 3704 certificate. This variable may be assigned one of the following 3705 values: unspecified, keyCompromise, caCompromise, 3706 affiliationChanged, superseded, cessationOfOperation, 3707 certificateHold, removeFromCRL, privilegeWithdrawn, aACompromise, 3708 the special value UNREVOKED, or the special value UNDETERMINED. 3709 This variable is initialized to the special value UNREVOKED. 3711 (c) interim_reasons_mask: This contains the set of revocation 3712 reasons supported by the CRL or delta CRL currently being 3713 processed. 3715 Note: In some environments, it is not necessary to check all reason 3716 codes. For example, some environments are only concerned with 3717 caCompromise and keyCompromise for CA certificates. This algorithm 3718 checks all reason codes. Additional processing and state variables 3719 may be necessary to limit the checking to a subset of the reason 3720 codes. 3722 6.3.3 CRL Processing 3724 This algorithm begins by assuming the certificate is not revoked. 3725 The algorithm checks one or more CRLs until either the certificate 3726 status is determined to be revoked or sufficient CRLs have been 3727 checked to cover all reason codes. 3729 For each distribution point (DP) in the certificate CRL distribution 3730 points extension, for each corresponding CRL in the local CRL cache, 3731 while ((reasons_mask is not all-reasons) and 3732 (cert_status is UNREVOKED)) perform the following: 3734 (a) Update the local CRL cache by obtaining a complete CRL, a 3735 delta CRL, or both, as required: 3737 (1) If the current time is after the value of the CRL next 3738 update field, then do one of the following: 3740 (i) If use-deltas is set and either the certificate or the 3741 CRL contains the freshest CRL extension, obtain a delta CRL 3742 with the a next update value that is after the current time 3743 and can be used to update the locally cached CRL as 3744 specified in section 5.2.4. 3746 (ii) Update the local CRL cache with a current complete 3747 CRL, verify that the current time is before the next update 3748 value in the new CRL, and continue processing with the new 3749 CRL. If use-deltas is set, then obtain the current delta 3750 CRL that can be used to update the new locally cached 3751 complete CRL as specified in section 5.2.4. 3753 (2) If the current time is before the value of the next update 3754 field and use-deltas is set, then obtain the current delta CRL 3755 that can be used to update the locally cached complete CRL as 3756 specified in section 5.2.4. 3758 (b) Verify the issuer and scope of the complete CRL as follows: 3760 (1) If the DP includes cRLIssuer, then verify that the issuer 3761 field in the complete CRL matches cRLIssuer in the DP and that 3762 the complete CRL contains an issuing distribution point 3763 extension with the indrectCRL boolean asserted. Otherwise, 3764 verify that the CRL issuer matches the certificate issuer. 3766 (2) If the complete CRL includes an issuing distribution point 3767 (IDP) CRL extension check the following: 3769 (i) If the distribution point name is present in the IDP 3770 CRL extension, then verify that it matches one of the names 3771 in the DP. 3773 (ii) If the onlyContainsUserCerts boolean is asserted in 3774 the IDP CRL extension, verify that the certificate does not 3775 include the basic constraints extension with the cA boolean 3776 asserted. 3778 (iii) If the onlyContainsCACerts boolean is asserted in the 3779 IDP CRL extension, verify that the certificate includes the 3780 basic constraints extension with the cA boolean asserted. 3782 (iv) Verify that the onlyContainsAttributeCerts boolean is 3783 not asserted. 3785 (c) If use-deltas is set, verify the issuer and scope of the 3786 delta CRL as follows: 3788 (1) Verify that the delta CRL issuer matches complete CRL 3789 issuer. 3791 (2) If the complete CRL includes an issuing distribution point 3792 (IDP) CRL extension, verify that the delta CRL contains a 3793 matching IDP CRL extension. If the complete CRL omits an IDP 3794 CRL extension, verify that the delta CRL also omits an IDP CRL 3795 extension. 3797 (3) Verify that the delta CRL authority key identifier 3798 extension matches complete CRL authority key identifier 3799 extension. 3801 (d) Compute the interim_reasons_mask for this CRL as follows: 3803 (1) If the issuing distribution point (IDP) CRL extension is 3804 present and includes onlySomeReasons and the DP includes 3805 reasons, then set interim_reasons_mask to the intersection of 3806 reasons in the DP and onlySomeReasons in IDP CRL extension. 3808 (2) If the IDP CRL extension includes onlySomeReasons but the 3809 DP omits reasons, then set interim_reasons_mask to the value of 3810 onlySomeReasons in IDP CRL extension. 3812 (3) If the IDP CRL extension omits onlySomeReasons but the DP 3813 includes reasons, then set interim_reasons_mask to the value of 3814 DP reasons. 3816 (4) If the IDP CRL extension omits onlySomeReasons and the DP 3817 omits reasons, then set interim_reasons_mask to the special 3818 value all-reasons. 3820 (e) Verify that interim_reasons_mask includes one or more reasons 3821 that is not included in the reasons_mask. 3823 (f) Obtain and validate the certification path for the complete 3824 CRL issuer. 3826 (g) Validate the signature on the complete CRL using the public 3827 key validated in step (f). 3829 (h) If use-deltas is set, then validate the signature on the 3830 delta CRL using the public key validated in step (f). 3832 (i) If use-deltas is set, then search for the certificate on the 3833 delta CRL. If an entry is found that matches the certificate 3834 issuer and serial number as described in section 5.3.4, then set 3835 the cert_status variable to the indicated reason as follows: 3837 (1) If the reason code CRL entry extension is present, set the 3838 cert_status variable to the value of the reason code CRL entry 3839 extension. 3841 (2) If the reason code CRL entry extension is not present, set 3842 the cert_status variable to the value unspecified. 3844 (j) If (cert_status is UNREVOKED), then search for the 3845 certificate on the complete CRL. If an entry is found that 3846 matches the certificate issuer and serial number as described in 3847 section 5.3.4, then set the cert_status variable to the indicated 3848 reason as described in step (i). 3850 (k) If (cert_status is removeFromCRL), then set cert_status to 3851 UNREVOKED. 3853 If ((reasons_mask is all-reasons) OR (cert_status is not UNREVOKED)), 3854 then the revocation status has been determined, so return 3855 cert_status. 3857 If the revocation status has not been determined, repeat the process 3858 above with any available CRLs not specified in a distribution point 3859 but issued by the certificate issuer. If the revocation status 3860 remains undetermined, then return the cert_status UNDETERMINED. 3862 7 References 3864 [RFC 791] J. Postel, "Internet Protocol", September 1981. 3866 [RFC 822] D. Crocker, "Standard for the format of ARPA Internet text 3867 messages", August 1982. 3869 [RFC 1034] P.V. Mockapetris, "Domain names - concepts and 3870 facilities", November 1987. 3872 [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic 3873 Mail: Part II: Certificate-Based Key Management," RFC 3874 1422, BBN Communications, February 1993. 3876 [RFC 1423] Balenson, D., "Privacy Enhancement for Internet Electronic 3877 Mail: Part III: Algorithms, Modes, and Identifiers," 3878 RFC 1423, Trusted Information Systems, February 1993. 3880 [RFC 1510] Kohl, J., and C. Neuman, "The Kerberos Network 3881 Authentication Service (V5)," RFC 1510, September 1993. 3883 [RFC 1519] V. Fuller, T. Li, J. Yu, and K. Varadhan. "Classless 3884 Inter-Domain Routing (CIDR): an Address Assignment and 3885 Aggregation Strategy", September 1993. 3887 [RFC 1738] Berners-Lee, T., Masinter L., and M. McCahill. 3888 "Uniform Resource Locators (URL)", RFC 1738, December 1994. 3890 [RFC 1778] Howes, T., Kille S., Yeong, W. and C. Robbins. "The 3891 String Representation of Standard Attribute Syntaxes," 3892 RFC 1778, March 1995. 3894 [RFC 1883] S. Deering and R. Hinden. "Internet Protocol, Version 6 3895 (IPv6) Specification", December 1995. 3897 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 3898 Requirement Levels", March 1997. 3900 [RFC 2247] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. 3901 Sataluri. "Using Domains in LDAP/X.500 Distinguished Names", 3902 RFC 2247, January 1998. 3904 [RFC 2277] H. Alvestrand, "IETF Policy on Character Sets and 3905 Languages", January 1998. 3907 [RFC 2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646", 3908 January 1998. 3910 [RFC 2560] Myers, M., Ankney R., Malpani A., Galperin S., and 3911 C. Adams, "Online Certificate Status Protocal - OCSP", 3912 June 1999. 3914 [SDN.701] SDN.701, "Message Security Protocol 4.0", Revision A 3915 1997-02-06. 3917 [X.208] CCITT Recommendation X.208: Specification of Abstract 3918 Syntax Notation One (ASN.1), 1988. 3920 [X.501] ITU-T Recommendation X.501: Information 3921 Technology - Open Systems Interconnection - The 3922 Directory: Models, 1993. 3924 [X.509] ITU-T Recommendation X.509 (1997 E): Information 3925 Technology - Open Systems Interconnection - The 3926 Directory: Authentication Framework, June 1997. 3928 [X.520] ITU-T Recommendation X.520: Information 3929 Technology - Open Systems Interconnection - The 3930 Directory: Selected Attribute Types, 1993. 3932 [X9.55] ANSI X9.55-1995, Public Key Cryptography For The Financial 3933 Services Industry: Extensions To Public Key Certificates 3934 And Certificate Revocation Lists, 8 December, 1995. 3936 [PKINIT] Tung, B., Neuman C., Hur M., Medvinsky A., Medvinsky S., 3937 Wray J., and J. Trostle, "Public Key Cryptography for 3938 Initial Authentciaion in Kerberos," 3939 draft-ietf-cat-kerberos-pk-init-11.txt, March 15, 2000. 3941 [PKIXALGS] Bassham, L., Housley, R., and W. Polk, "Internet X.509 3942 Public Key Infrastructure Representation of Public Keys 3943 and Digital Signatures," 3944 draft-ietf-pkix-ipki-pkalgs-00.txt, July 14, 2000. 3946 [PKIXTSA] Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 3947 Public Key Infrastructure Time Stamp Protocol," 3948 draft-ietf-pkix-time-stamp-12.txt, November, 2000. 3950 8 Intellectual Property Rights 3952 The IETF has been notified of intellectual property rights claimed in 3953 regard to some or all of the specification contained in this 3954 document. For more information consult the online list of claimed 3955 rights (see http://www.ietf.org/ipr.html). 3957 The IETF takes no position regarding the validity or scope of any 3958 intellectual property or other rights that might be claimed to 3959 pertain to the implementation or use of the technology described in 3960 this document or the extent to which any license under such rights 3961 might or might not be available; neither does it represent that it 3962 has made any effort to identify any such rights. Information on the 3963 IETF's procedures with respect to rights in standards-track and 3964 standards-related documentation can be found in BCP-11. Copies of 3965 claims of rights made available for publication and any assurances of 3966 licenses to be made available, or the result of an attempt made to 3967 obtain a general license or permission for the use of such 3968 proprietary rights by implementors or users of this specification can 3969 be obtained from the IETF Secretariat. 3971 9 Security Considerations 3973 The majority of this specification is devoted to the format and 3974 content of certificates and CRLs. Since certificates and CRLs are 3975 digitally signed, no additional integrity service is necessary. 3976 Neither certificates nor CRLs need be kept secret, and unrestricted 3977 and anonymous access to certificates and CRLs has no security 3978 implications. 3980 However, security factors outside the scope of this specification 3981 will affect the assurance provided to certificate users. This 3982 section highlights critical issues to be considered by implementers, 3983 administrators, and users. 3985 The procedures performed by CAs and RAs to validate the binding of 3986 the subject's identity of their public key greatly affect the 3987 assurance that ought to be placed in the certificate. Relying 3988 parties might wish to review the CA's certificate practice statement. 3989 This is particularly important when issuing certificates to other 3990 CAs. 3992 The use of a single key pair for both signature and other purposes is 3993 strongly discouraged. Use of separate key pairs for signature and 3994 key management provides several benefits to the users. The 3995 ramifications associated with loss or disclosure of a signature key 3996 are different from loss or disclosure of a key management key. Using 3997 separate key pairs permits a balanced and flexible response. 3998 Similarly, different validity periods or key lengths for each key 3999 pair may be appropriate in some application environments. 4000 Unfortunately, some legacy applications (e.g., SSL) use a single key 4001 pair for signature and key management. 4003 The protection afforded private keys is a critical security factor. 4004 On a small scale, failure of users to protect their private keys will 4005 permit an attacker to masquerade as them, or decrypt their personal 4006 information. On a larger scale, compromise of a CA's private signing 4007 key may have a catastrophic effect. If an attacker obtains the 4008 private key unnoticed, the attacker may issue bogus certificates and 4009 CRLs. Existence of bogus certificates and CRLs will undermine 4010 confidence in the system. If such a compromise is detected, all 4011 certificates issued to the compromised CA MUST be revoked, preventing 4012 services between its users and users of other CAs. Rebuilding after 4013 such a compromise will be problematic, so CAs are advised to 4014 implement a combination of strong technical measures (e.g., tamper- 4015 resistant cryptographic modules) and appropriate management 4016 procedures (e.g., separation of duties) to avoid such an incident. 4018 Loss of a CA's private signing key may also be problematic. The CA 4019 would not be able to produce CRLs or perform normal key rollover. 4020 CAs SHOULD maintain secure backup for signing keys. The security of 4021 the key backup procedures is a critical factor in avoiding key 4022 compromise. 4024 The availability and freshness of revocation information affects the 4025 degree of assurance that ought to be placed in a certificate. While 4026 certificates expire naturally, events may occur during its natural 4027 lifetime which negate the binding between the subject and public key. 4028 If revocation information is untimely or unavailable, the assurance 4029 associated with the binding is clearly reduced. Relying parties 4030 might not be able to process every critical extension that can appear 4031 in a CRL. CAs SHOULD take extra care when making revocation 4032 information available only through CRLs that contain critical 4033 extensions, particularly if support for those extensions is not 4034 mandated by this profile. For example, if revocation information is 4035 supplied using a combination of delta CRLs and full CRLs, and the 4036 delta CRLs are issued more frequently than the full CRLs, then 4037 relying parties that cannot handle the critical extensions related to 4038 delta CRL processing will not be able to obtain the most recent 4039 revocation information. Alternatively, if a full CRL is issued 4040 whenever a delta CRL is issued, then timely revocation information 4041 will be available to all relying parties. Similarly, implementations 4042 of the certification path validation mechanism described in section 6 4043 that omit revocation checking provide less assurance than those that 4044 support it. 4046 The path validation algorithm depends on the certain knowledge of the 4047 public keys (and other information) about one or more trusted CAs. 4048 The decision to trust a CA is an important decision as it ultimately 4049 determines the trust afforded a certificate. The authenticated 4050 distribution of trusted CA public keys (usually in the form of a 4051 "self-signed" certificate) is a security critical out of band process 4052 that is beyond the scope of this specification. 4054 In addition, where a key compromise or CA failure occurs for a 4055 trusted CA, the user will need to modify the information provided to 4056 the path validation routine. Selection of too many trusted CAs makes 4057 the trusted CA information difficult to maintain. On the other hand, 4058 selection of only one trusted CA could limit users to a closed 4059 community of users. 4061 The quality of implementations that process certificates also affects 4062 the degree of assurance provided. The path validation algorithm 4063 described in section 6 relies upon the integrity of the trusted CA 4064 information, and especially the integrity of the public keys 4065 associated with the trusted CAs. By substituting public keys for 4066 which an attacker has the private key, an attacker could trick the 4067 user into accepting false certificates. 4069 The binding between a key and certificate subject cannot be stronger 4070 than the cryptographic module implementation and algorithms used to 4071 generate the signature. Short key lengths or weak hash algorithms 4072 will limit the utility of a certificate. CAs are encouraged to note 4073 advances in cryptology so they can employ strong cryptographic 4074 techniques. In addition, CAs SHOULD decline to issue certificates to 4075 CAs or end entities that generate weak signatures. 4077 Inconsistent application of name comparison rules can result in 4078 acceptance of invalid X.509 certification paths, or rejection of 4079 valid ones. The X.500 series of specifications defines rules for 4080 comparing distinguished names that require comparison of strings 4081 without regard to case, character set, multi-character white space 4082 substring, or leading and trailing white space. This specification 4083 relaxes these requirements, requiring support for binary comparison 4084 at a minimum. 4086 CAs MUST encode the distinguished name in the subject field of a CA 4087 certificate identically to the distinguished name in the issuer field 4088 in certificates issued by the latter CA. If CAs use different 4089 encodings, implementations might fail to recognize name chains for 4090 paths that include this certificate. As a consequence, valid paths 4091 could be rejected. 4093 In addition, name constraints for distinguished names MUST be stated 4094 identically to the encoding used in the subject field or 4095 subjectAltName extension. If not, then name constraints stated as 4096 excludedSubTrees will not match and invalid paths will be accepted 4097 and name constraints expressed as permittedSubtrees will not match 4098 and valid paths will be rejected. To avoid acceptance of invalid 4099 paths, CAs SHOULD state name constraints for distinguished names as 4100 permittedSubtrees wherever possible. 4102 Appendix A. Psuedo-ASN.1 Structures and OIDs 4104 This section describes data objects used by conforming PKI components 4105 in an "ASN.1-like" syntax. This syntax is a hybrid of the 1988 and 4106 1993 ASN.1 syntaxes. The 1988 ASN.1 syntax is augmented with 1993 4107 UNIVERSAL Types UniversalString, BMPString and UTF8String. 4109 The ASN.1 syntax does not permit the inclusion of type statements in 4110 the ASN.1 module, and the 1993 ASN.1 standard does not permit use of 4111 the new UNIVERSAL types in modules using the 1988 syntax. As a 4112 result, this module does not conform to either version of the ASN.1 4113 standard. 4115 This appendix may be converted into 1988 ASN.1 by replacing the 4116 defintions for the UNIVERSAL Types with the 1988 catch-all "ANY". 4118 A.1 Explicitly Tagged Module, 1988 Syntax 4120 PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) 4121 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) } 4123 DEFINITIONS EXPLICIT TAGS ::= 4125 BEGIN 4127 -- EXPORTS ALL -- 4129 -- IMPORTS NONE -- 4131 -- UNIVERSAL Types defined in 1993 and 1998 ASN.1 4132 -- and required by this specification 4134 UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING 4135 -- UniversalString is defined in ASN.1:1993 4137 BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING 4138 -- BMPString is the subtype of UniversalString and models 4139 -- the Basic Multilingual Plane of ISO/IEC/ITU 10646-1 4141 UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 4142 -- The content of this type conforms to RFC 2279. 4144 -- PKIX specific OIDs 4146 id-pkix OBJECT IDENTIFIER ::= 4147 { iso(1) identified-organization(3) dod(6) internet(1) 4148 security(5) mechanisms(5) pkix(7) } 4150 -- PKIX arcs 4152 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 4153 -- arc for private certificate extensions 4154 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 4155 -- arc for policy qualifier types 4156 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 4157 -- arc for extended key purpose OIDS 4158 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 4159 -- arc for access descriptors 4161 -- policyQualifierIds for Internet policy qualifiers 4163 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 4164 -- OID for CPS qualifier 4165 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 4166 -- OID for user notice qualifier 4168 -- access descriptor definitions 4170 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 4171 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 4172 id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 } 4173 id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 } 4175 -- attribute data types 4177 Attribute ::= SEQUENCE { 4178 type AttributeType, 4179 values SET OF AttributeValue } 4180 -- at least one value is required 4182 AttributeType ::= OBJECT IDENTIFIER 4184 AttributeValue ::= ANY 4186 AttributeTypeAndValue ::= SEQUENCE { 4187 type AttributeType, 4188 value AttributeValue } 4190 -- suggested naming attributes: Definition of the following 4191 -- information object set may be augmented to meet local 4192 -- requirements. Note that deleting members of the set may 4193 -- prevent interoperability with conforming implementations. 4194 -- presented in pairs: the AttributeType followed by the 4195 -- type definition for the corresponding AttributeValue 4197 --Arc for standard naming attributes 4198 id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 } 4200 -- Naming attributes of type X520name 4202 id-at-name AttributeType ::= { id-at 41 } 4203 id-at-surname AttributeType ::= { id-at 4 } 4204 id-at-givenName AttributeType ::= { id-at 42 } 4205 id-at-initials AttributeType ::= { id-at 43 } 4206 id-at-generationQualifier AttributeType ::= { id-at 44 } 4208 X520name ::= CHOICE { 4209 teletexString TeletexString (SIZE (1..ub-name)), 4210 printableString PrintableString (SIZE (1..ub-name)), 4211 universalString UniversalString (SIZE (1..ub-name)), 4212 utf8String UTF8String (SIZE (1..ub-name)), 4213 bmpString BMPString (SIZE (1..ub-name)) } 4215 -- Naming attributes of type X520CommonName 4217 id-at-commonName AttributeType ::= { id-at 3 } 4219 X520CommonName ::= CHOICE { 4220 teletexString TeletexString (SIZE (1..ub-common-name)), 4221 printableString PrintableString (SIZE (1..ub-common-name)), 4222 universalString UniversalString (SIZE (1..ub-common-name)), 4223 utf8String UTF8String (SIZE (1..ub-common-name)), 4224 bmpString BMPString (SIZE (1..ub-common-name)) } 4226 -- Naming attributes of type X520LocalityName 4228 id-at-localityName AttributeType ::= { id-at 7 } 4230 X520LocalityName ::= CHOICE { 4231 teletexString TeletexString (SIZE (1..ub-locality-name)), 4232 printableString PrintableString (SIZE (1..ub-locality-name)), 4233 universalString UniversalString (SIZE (1..ub-locality-name)), 4234 utf8String UTF8String (SIZE (1..ub-locality-name)), 4235 bmpString BMPString (SIZE (1..ub-locality-name)) } 4237 -- Naming attributes of type X520StateOrProvinceName 4239 id-at-stateOrProvinceName AttributeType ::= { id-at 8 } 4241 X520StateOrProvinceName ::= CHOICE { 4242 teletexString TeletexString (SIZE (1..ub-state-name)), 4243 printableString PrintableString (SIZE (1..ub-state-name)), 4244 universalString UniversalString (SIZE (1..ub-state-name)), 4245 utf8String UTF8String (SIZE (1..ub-state-name)), 4246 bmpString BMPString (SIZE(1..ub-state-name)) } 4248 -- Naming attributes of type X520OrganizationName 4250 id-at-organizationName AttributeType ::= { id-at 10 } 4252 X520OrganizationName ::= CHOICE { 4253 teletexString TeletexString 4254 (SIZE (1..ub-organization-name)), 4255 printableString PrintableString 4256 (SIZE (1..ub-organization-name)), 4257 universalString UniversalString 4258 (SIZE (1..ub-organization-name)), 4259 utf8String UTF8String 4260 (SIZE (1..ub-organization-name)), 4261 bmpString BMPString 4262 (SIZE (1..ub-organization-name)) } 4264 -- Naming attributes of type X520OrganizationalUnitName 4266 id-at-organizationalUnitName AttributeType ::= { id-at 11 } 4268 X520OrganizationalUnitName ::= CHOICE { 4269 teletexString TeletexString 4270 (SIZE (1..ub-organizational-unit-name)), 4271 printableString PrintableString 4272 (SIZE (1..ub-organizational-unit-name)), 4273 universalString UniversalString 4274 (SIZE (1..ub-organizational-unit-name)), 4275 utf8String UTF8String 4276 (SIZE (1..ub-organizational-unit-name)), 4277 bmpString BMPString 4278 (SIZE (1..ub-organizational-unit-name)) } 4280 -- Naming attributes of type X520Title 4282 id-at-title AttributeType ::= { id-at 12 } 4284 X520Title ::= CHOICE { 4285 teletexString TeletexString (SIZE (1..ub-title)), 4286 printableString PrintableString (SIZE (1..ub-title)), 4287 universalString UniversalString (SIZE (1..ub-title)), 4288 utf8String UTF8String (SIZE (1..ub-title)), 4289 bmpString BMPString (SIZE (1..ub-title)) } 4291 -- Naming attributes of type X520dnQualifier 4292 id-at-dnQualifier AttributeType ::= { id-at 46 } 4294 X520dnQualifier ::= PrintableString 4296 -- Naming attributes of type X520countryName (digraph from IS 3166) 4298 id-at-countryName AttributeType ::= { id-at 6 } 4300 X520countryName ::= PrintableString (SIZE (2)) 4302 -- Naming attributes of type X520SerialNumber 4304 id-at-serialNumber AttributeType ::= { id-at 5 } 4306 X520SerialNumber ::= PrintableString (SIZE (1..ub-serial-number)) 4308 -- Naming attributes of type DomainComponent (from RFC 2247) 4310 id-domainComponent AttributeType ::= 4311 { 0 9 2342 19200300 100 1 25 } 4313 DomainComponent ::= IA5String 4315 -- Legacy attributes 4317 pkcs-9 OBJECT IDENTIFIER ::= 4318 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 } 4320 id-emailAddress AttributeType ::= { pkcs-9 1 } 4322 EmailAddress ::= IA5String (SIZE (1..ub-emailaddress-length)) 4324 -- naming data types -- 4326 Name ::= CHOICE { -- only one possibility for now -- 4327 rdnSequence RDNSequence } 4329 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 4331 DistinguishedName ::= RDNSequence 4333 RelativeDistinguishedName ::= 4334 SET SIZE (1 .. MAX) OF AttributeTypeAndValue 4336 -- Directory string type -- 4338 DirectoryString ::= CHOICE { 4339 teletexString TeletexString (SIZE (1..MAX)), 4340 printableString PrintableString (SIZE (1..MAX)), 4341 universalString UniversalString (SIZE (1..MAX)), 4342 utf8String UTF8String (SIZE (1..MAX)), 4343 bmpString BMPString (SIZE (1..MAX)) } 4345 -- certificate and CRL specific structures begin here 4347 Certificate ::= SEQUENCE { 4348 tbsCertificate TBSCertificate, 4349 signatureAlgorithm AlgorithmIdentifier, 4350 signature BIT STRING } 4352 TBSCertificate ::= SEQUENCE { 4353 version [0] Version DEFAULT v1, 4354 serialNumber CertificateSerialNumber, 4355 signature AlgorithmIdentifier, 4356 issuer Name, 4357 validity Validity, 4358 subject Name, 4359 subjectPublicKeyInfo SubjectPublicKeyInfo, 4360 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 4361 -- If present, version MUST be v2 or v3 4362 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 4363 -- If present, version MUST be v2 or v3 4364 extensions [3] Extensions OPTIONAL 4365 -- If present, version MUST be v3 -- } 4367 Version ::= INTEGER { v1(0), v2(1), v3(2) } 4369 CertificateSerialNumber ::= INTEGER 4371 Validity ::= SEQUENCE { 4372 notBefore Time, 4373 notAfter Time } 4375 Time ::= CHOICE { 4376 utcTime UTCTime, 4377 generalTime GeneralizedTime } 4379 UniqueIdentifier ::= BIT STRING 4381 SubjectPublicKeyInfo ::= SEQUENCE { 4382 algorithm AlgorithmIdentifier, 4383 subjectPublicKey BIT STRING } 4385 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 4387 Extension ::= SEQUENCE { 4388 extnID OBJECT IDENTIFIER, 4389 critical BOOLEAN DEFAULT FALSE, 4390 extnValue OCTET STRING } 4392 -- CRL structures 4394 CertificateList ::= SEQUENCE { 4395 tbsCertList TBSCertList, 4396 signatureAlgorithm AlgorithmIdentifier, 4397 signature BIT STRING } 4399 TBSCertList ::= SEQUENCE { 4400 version Version OPTIONAL, 4401 -- if present, MUST be v2 4402 signature AlgorithmIdentifier, 4403 issuer Name, 4404 thisUpdate Time, 4405 nextUpdate Time OPTIONAL, 4406 revokedCertificates SEQUENCE OF SEQUENCE { 4407 userCertificate CertificateSerialNumber, 4408 revocationDate Time, 4409 crlEntryExtensions Extensions OPTIONAL 4410 -- if present, MUST be v2 4411 } OPTIONAL, 4412 crlExtensions [0] Extensions OPTIONAL 4413 -- if present, MUST be v2 -- } 4415 -- Version, Time, CertificateSerialNumber, and Extensions were 4416 -- defined earlier for use in the certificate structure 4418 AlgorithmIdentifier ::= SEQUENCE { 4419 algorithm OBJECT IDENTIFIER, 4420 parameters ANY DEFINED BY algorithm OPTIONAL } 4421 -- contains a value of the type 4422 -- registered for use with the 4423 -- algorithm object identifier value 4425 -- X.400 address syntax starts here 4427 ORAddress ::= SEQUENCE { 4428 built-in-standard-attributes BuiltInStandardAttributes, 4429 built-in-domain-defined-attributes 4430 BuiltInDomainDefinedAttributes OPTIONAL, 4431 -- see also teletex-domain-defined-attributes 4432 extension-attributes ExtensionAttributes OPTIONAL } 4433 -- [[[*** What is this comment about? OR-Name is not defined ***]]] 4434 -- The OR-address is semantically absent from the OR-name if the 4435 -- built-in-standard-attribute sequence is empty and the 4436 -- built-in-domain-defined-attributes and extension-attributes are 4437 -- both omitted. 4439 -- Built-in Standard Attributes 4441 BuiltInStandardAttributes ::= SEQUENCE { 4442 country-name CountryName OPTIONAL, 4443 administration-domain-name AdministrationDomainName OPTIONAL, 4444 network-address [0] NetworkAddress OPTIONAL, 4445 -- see also extended-network-address 4446 terminal-identifier [1] TerminalIdentifier OPTIONAL, 4447 private-domain-name [2] PrivateDomainName OPTIONAL, 4448 organization-name [3] OrganizationName OPTIONAL, 4449 -- see also teletex-organization-name 4450 numeric-user-identifier [4] NumericUserIdentifier OPTIONAL, 4451 personal-name [5] PersonalName OPTIONAL, 4452 -- see also teletex-personal-name 4453 organizational-unit-names [6] OrganizationalUnitNames OPTIONAL 4454 -- see also teletex-organizational-unit-names -- } 4456 CountryName ::= [APPLICATION 1] CHOICE { 4457 x121-dcc-code NumericString 4458 (SIZE (ub-country-name-numeric-length)), 4459 iso-3166-alpha2-code PrintableString 4460 (SIZE (ub-country-name-alpha-length)) } 4462 AdministrationDomainName ::= [APPLICATION 2] CHOICE { 4463 numeric NumericString (SIZE (0..ub-domain-name-length)), 4464 printable PrintableString (SIZE (0..ub-domain-name-length)) } 4466 NetworkAddress ::= X121Address -- see also extended-network-address 4468 X121Address ::= NumericString (SIZE (1..ub-x121-address-length)) 4470 TerminalIdentifier ::= PrintableString (SIZE (1..ub-terminal-id-length)) 4472 PrivateDomainName ::= CHOICE { 4473 numeric NumericString (SIZE (1..ub-domain-name-length)), 4474 printable PrintableString (SIZE (1..ub-domain-name-length)) } 4476 OrganizationName ::= PrintableString 4477 (SIZE (1..ub-organization-name-length)) 4478 -- see also teletex-organization-name 4480 NumericUserIdentifier ::= NumericString 4481 (SIZE (1..ub-numeric-user-id-length)) 4483 PersonalName ::= SET { 4484 surname [0] PrintableString (SIZE (1..ub-surname-length)), 4485 given-name [1] PrintableString 4486 (SIZE (1..ub-given-name-length)) OPTIONAL, 4487 initials [2] PrintableString (SIZE (1..ub-initials-length)) OPTIONAL, 4488 generation-qualifier [3] PrintableString 4489 (SIZE (1..ub-generation-qualifier-length)) OPTIONAL } 4490 -- see also teletex-personal-name 4492 OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units) 4493 OF OrganizationalUnitName 4494 -- see also teletex-organizational-unit-names 4496 OrganizationalUnitName ::= PrintableString (SIZE 4497 (1..ub-organizational-unit-name-length)) 4499 -- Built-in Domain-defined Attributes 4501 BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE 4502 (1..ub-domain-defined-attributes) OF 4503 BuiltInDomainDefinedAttribute 4505 BuiltInDomainDefinedAttribute ::= SEQUENCE { 4506 type PrintableString (SIZE 4507 (1..ub-domain-defined-attribute-type-length)), 4508 value PrintableString (SIZE 4509 (1..ub-domain-defined-attribute-value-length)) } 4511 -- Extension Attributes 4513 ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF 4514 ExtensionAttribute 4516 ExtensionAttribute ::= SEQUENCE { 4517 extension-attribute-type [0] INTEGER (0..ub-extension-attributes), 4518 extension-attribute-value [1] 4519 ANY DEFINED BY extension-attribute-type } 4521 -- Extension types and attribute values 4523 common-name INTEGER ::= 1 4525 CommonName ::= PrintableString (SIZE (1..ub-common-name-length)) 4527 teletex-common-name INTEGER ::= 2 4529 TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length)) 4531 teletex-organization-name INTEGER ::= 3 4532 TeletexOrganizationName ::= 4533 TeletexString (SIZE (1..ub-organization-name-length)) 4535 teletex-personal-name INTEGER ::= 4 4537 TeletexPersonalName ::= SET { 4538 surname [0] TeletexString (SIZE (1..ub-surname-length)), 4539 given-name [1] TeletexString 4540 (SIZE (1..ub-given-name-length)) OPTIONAL, 4541 initials [2] TeletexString (SIZE (1..ub-initials-length)) OPTIONAL, 4542 generation-qualifier [3] TeletexString (SIZE 4543 (1..ub-generation-qualifier-length)) OPTIONAL } 4545 teletex-organizational-unit-names INTEGER ::= 5 4547 TeletexOrganizationalUnitNames ::= SEQUENCE SIZE 4548 (1..ub-organizational-units) OF TeletexOrganizationalUnitName 4550 TeletexOrganizationalUnitName ::= TeletexString 4551 (SIZE (1..ub-organizational-unit-name-length)) 4553 pds-name INTEGER ::= 7 4555 PDSName ::= PrintableString (SIZE (1..ub-pds-name-length)) 4557 physical-delivery-country-name INTEGER ::= 8 4559 PhysicalDeliveryCountryName ::= CHOICE { 4560 x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)), 4561 iso-3166-alpha2-code PrintableString 4562 (SIZE (ub-country-name-alpha-length)) } 4564 postal-code INTEGER ::= 9 4566 PostalCode ::= CHOICE { 4567 numeric-code NumericString (SIZE (1..ub-postal-code-length)), 4568 printable-code PrintableString (SIZE (1..ub-postal-code-length)) } 4570 physical-delivery-office-name INTEGER ::= 10 4572 PhysicalDeliveryOfficeName ::= PDSParameter 4574 physical-delivery-office-number INTEGER ::= 11 4576 PhysicalDeliveryOfficeNumber ::= PDSParameter 4578 extension-OR-address-components INTEGER ::= 12 4579 ExtensionORAddressComponents ::= PDSParameter 4581 physical-delivery-personal-name INTEGER ::= 13 4583 PhysicalDeliveryPersonalName ::= PDSParameter 4585 physical-delivery-organization-name INTEGER ::= 14 4587 PhysicalDeliveryOrganizationName ::= PDSParameter 4589 extension-physical-delivery-address-components INTEGER ::= 15 4591 ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter 4593 unformatted-postal-address INTEGER ::= 16 4595 UnformattedPostalAddress ::= SET { 4596 printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) OF 4597 PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL, 4598 teletex-string TeletexString 4599 (SIZE (1..ub-unformatted-address-length)) OPTIONAL } 4601 street-address INTEGER ::= 17 4603 StreetAddress ::= PDSParameter 4605 post-office-box-address INTEGER ::= 18 4607 PostOfficeBoxAddress ::= PDSParameter 4609 poste-restante-address INTEGER ::= 19 4611 PosteRestanteAddress ::= PDSParameter 4613 unique-postal-name INTEGER ::= 20 4615 UniquePostalName ::= PDSParameter 4617 local-postal-attributes INTEGER ::= 21 4619 LocalPostalAttributes ::= PDSParameter 4621 PDSParameter ::= SET { 4622 printable-string PrintableString 4623 (SIZE(1..ub-pds-parameter-length)) OPTIONAL, 4624 teletex-string TeletexString 4625 (SIZE(1..ub-pds-parameter-length)) OPTIONAL } 4627 extended-network-address INTEGER ::= 22 4629 ExtendedNetworkAddress ::= CHOICE { 4630 e163-4-address SEQUENCE { 4631 number [0] NumericString (SIZE (1..ub-e163-4-number-length)), 4632 sub-address [1] NumericString 4633 (SIZE (1..ub-e163-4-sub-address-length)) OPTIONAL }, 4634 psap-address [0] PresentationAddress } 4636 PresentationAddress ::= SEQUENCE { 4637 pSelector [0] EXPLICIT OCTET STRING OPTIONAL, 4638 sSelector [1] EXPLICIT OCTET STRING OPTIONAL, 4639 tSelector [2] EXPLICIT OCTET STRING OPTIONAL, 4640 nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING } 4642 terminal-type INTEGER ::= 23 4644 TerminalType ::= INTEGER { 4645 telex (3), 4646 teletex (4), 4647 g3-facsimile (5), 4648 g4-facsimile (6), 4649 ia5-terminal (7), 4650 videotex (8) } (0..ub-integer-options) 4652 -- Extension Domain-defined Attributes 4654 teletex-domain-defined-attributes INTEGER ::= 6 4656 TeletexDomainDefinedAttributes ::= SEQUENCE SIZE 4657 (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute 4659 TeletexDomainDefinedAttribute ::= SEQUENCE { 4660 type TeletexString 4661 (SIZE (1..ub-domain-defined-attribute-type-length)), 4662 value TeletexString 4663 (SIZE (1..ub-domain-defined-attribute-value-length)) } 4665 -- specifications of Upper Bounds MUST be regarded as mandatory 4666 -- from Annex B of ITU-T X.411 Reference Definition of MTS Parameter 4667 -- Upper Bounds 4669 -- Upper Bounds 4670 ub-name INTEGER ::= 32768 4671 ub-common-name INTEGER ::= 64 4672 ub-locality-name INTEGER ::= 128 4673 ub-state-name INTEGER ::= 128 4674 ub-organization-name INTEGER ::= 64 4675 ub-organizational-unit-name INTEGER ::= 64 4676 ub-title INTEGER ::= 64 4677 ub-serial-number INTEGER ::= 64 4678 ub-match INTEGER ::= 128 4679 ub-emailaddress-length INTEGER ::= 128 4680 ub-common-name-length INTEGER ::= 64 4681 ub-country-name-alpha-length INTEGER ::= 2 4682 ub-country-name-numeric-length INTEGER ::= 3 4683 ub-domain-defined-attributes INTEGER ::= 4 4684 ub-domain-defined-attribute-type-length INTEGER ::= 8 4685 ub-domain-defined-attribute-value-length INTEGER ::= 128 4686 ub-domain-name-length INTEGER ::= 16 4687 ub-extension-attributes INTEGER ::= 256 4688 ub-e163-4-number-length INTEGER ::= 15 4689 ub-e163-4-sub-address-length INTEGER ::= 40 4690 ub-generation-qualifier-length INTEGER ::= 3 4691 ub-given-name-length INTEGER ::= 16 4692 ub-initials-length INTEGER ::= 5 4693 ub-integer-options INTEGER ::= 256 4694 ub-numeric-user-id-length INTEGER ::= 32 4695 ub-organization-name-length INTEGER ::= 64 4696 ub-organizational-unit-name-length INTEGER ::= 32 4697 ub-organizational-units INTEGER ::= 4 4698 ub-pds-name-length INTEGER ::= 16 4699 ub-pds-parameter-length INTEGER ::= 30 4700 ub-pds-physical-address-lines INTEGER ::= 6 4701 ub-postal-code-length INTEGER ::= 16 4702 ub-surname-length INTEGER ::= 40 4703 ub-terminal-id-length INTEGER ::= 24 4704 ub-unformatted-address-length INTEGER ::= 180 4705 ub-x121-address-length INTEGER ::= 16 4707 -- Note - upper bounds on string types, such as TeletexString, are 4708 -- measured in characters. Excepting PrintableString or IA5String, a 4709 -- significantly greater number of octets will be required to hold 4710 -- such a value. As a minimum, 16 octets, or twice the specified upper 4711 -- bound, whichever is the larger, should be allowed for TeletexString. 4712 -- For UTF8String or UniversalString at least four times the upper 4713 -- bound should be allowed. 4715 END 4716 A.2 Implicitly Tagged Module, 1988 Syntax 4718 PKIX1Implicit88 { iso(1) identified-organization(3) dod(6) internet(1) 4719 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19) } 4721 DEFINITIONS IMPLICIT TAGS ::= 4723 BEGIN 4725 -- EXPORTS ALL -- 4727 IMPORTS 4728 id-pe, id-kp, id-qt-unotice, id-qt-cps, 4729 -- delete following line if "new" types are supported -- 4730 BMPString, UTF8String, -- end "new" types -- 4731 ORAddress, Name, RelativeDistinguishedName, 4732 CertificateSerialNumber, Attribute, DirectoryString 4733 FROM PKIX1Explicit88 { iso(1) identified-organization(3) 4734 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 4735 id-mod(0) id-pkix1-explicit(18) }; 4737 -- ISO arc for standard certificate and CRL extensions 4739 id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 4741 -- authority key identifier OID and syntax 4743 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 4745 AuthorityKeyIdentifier ::= SEQUENCE { 4746 keyIdentifier [0] KeyIdentifier OPTIONAL, 4747 authorityCertIssuer [1] GeneralNames OPTIONAL, 4748 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 4749 -- authorityCertIssuer and authorityCertSerialNumber MUST both 4750 -- be present or both be absent 4752 KeyIdentifier ::= OCTET STRING 4754 -- subject key identifier OID and syntax 4756 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 4758 SubjectKeyIdentifier ::= KeyIdentifier 4760 -- key usage extension OID and syntax 4762 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 4763 KeyUsage ::= BIT STRING { 4764 digitalSignature (0), 4765 nonRepudiation (1), 4766 keyEncipherment (2), 4767 dataEncipherment (3), 4768 keyAgreement (4), 4769 keyCertSign (5), 4770 cRLSign (6), 4771 encipherOnly (7), 4772 decipherOnly (8) } 4774 -- private key usage period extension OID and syntax 4776 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 4778 PrivateKeyUsagePeriod ::= SEQUENCE { 4779 notBefore [0] GeneralizedTime OPTIONAL, 4780 notAfter [1] GeneralizedTime OPTIONAL } 4781 -- either notBefore or notAfter MUST be present 4783 -- certificate policies extension OID and syntax 4785 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 4787 anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 } 4789 CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 4791 PolicyInformation ::= SEQUENCE { 4792 policyIdentifier CertPolicyId, 4793 policyQualifiers SEQUENCE SIZE (1..MAX) OF 4794 PolicyQualifierInfo OPTIONAL } 4796 CertPolicyId ::= OBJECT IDENTIFIER 4798 PolicyQualifierInfo ::= SEQUENCE { 4799 policyQualifierId PolicyQualifierId, 4800 qualifier ANY DEFINED BY policyQualifierId } 4802 -- Implementations that recognize additional policy qualifiers MUST 4803 -- augment the following definition for PolicyQualifierId 4805 PolicyQualifierId ::= 4806 OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) 4808 -- CPS pointer qualifier 4810 CPSuri ::= IA5String 4811 -- user notice qualifier 4813 UserNotice ::= SEQUENCE { 4814 noticeRef NoticeReference OPTIONAL, 4815 explicitText DisplayText OPTIONAL} 4817 NoticeReference ::= SEQUENCE { 4818 organization DisplayText, 4819 noticeNumbers SEQUENCE OF INTEGER } 4821 DisplayText ::= CHOICE { 4822 ia5String IA5String (SIZE (1..200)), 4823 visibleString VisibleString (SIZE (1..200)), 4824 bmpString BMPString (SIZE (1..200)), 4825 utf8String UTF8String (SIZE (1..200)) } 4827 -- policy mapping extension OID and syntax 4829 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 4831 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 4832 issuerDomainPolicy CertPolicyId, 4833 subjectDomainPolicy CertPolicyId } 4835 -- subject alternative name extension OID and syntax 4837 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 4839 SubjectAltName ::= GeneralNames 4841 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 4843 GeneralName ::= CHOICE { 4844 otherName [0] AnotherName, 4845 rfc822Name [1] IA5String, 4846 dNSName [2] IA5String, 4847 x400Address [3] ORAddress, 4848 directoryName [4] Name, 4849 ediPartyName [5] EDIPartyName, 4850 uniformResourceIdentifier [6] IA5String, 4851 iPAddress [7] OCTET STRING, 4852 registeredID [8] OBJECT IDENTIFIER } 4854 -- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as 4855 -- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax 4857 AnotherName ::= SEQUENCE { 4858 type-id OBJECT IDENTIFIER, 4859 value [0] EXPLICIT ANY DEFINED BY type-id } 4861 EDIPartyName ::= SEQUENCE { 4862 nameAssigner [0] DirectoryString OPTIONAL, 4863 partyName [1] DirectoryString } 4865 -- issuer alternative name extension OID and syntax 4867 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 4869 IssuerAltName ::= GeneralNames 4871 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 4873 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 4875 -- basic constraints extension OID and syntax 4877 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 4879 BasicConstraints ::= SEQUENCE { 4880 cA BOOLEAN DEFAULT FALSE, 4881 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 4883 -- name constraints extension OID and syntax 4885 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 4887 NameConstraints ::= SEQUENCE { 4888 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 4889 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 4891 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 4893 GeneralSubtree ::= SEQUENCE { 4894 base GeneralName, 4895 minimum [0] BaseDistance DEFAULT 0, 4896 maximum [1] BaseDistance OPTIONAL } 4898 BaseDistance ::= INTEGER (0..MAX) 4900 -- policy constraints extension OID and syntax 4902 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } 4904 PolicyConstraints ::= SEQUENCE { 4905 requireExplicitPolicy [0] SkipCerts OPTIONAL, 4906 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 4908 SkipCerts ::= INTEGER (0..MAX) 4910 -- CRL distribution points extension OID and syntax 4912 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31} 4914 CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 4916 DistributionPoint ::= SEQUENCE { 4917 distributionPoint [0] DistributionPointName OPTIONAL, 4918 reasons [1] ReasonFlags OPTIONAL, 4919 cRLIssuer [2] GeneralNames OPTIONAL } 4921 DistributionPointName ::= CHOICE { 4922 fullName [0] GeneralNames, 4923 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 4925 ReasonFlags ::= BIT STRING { 4926 unused (0), 4927 keyCompromise (1), 4928 cACompromise (2), 4929 affiliationChanged (3), 4930 superseded (4), 4931 cessationOfOperation (5), 4932 certificateHold (6), 4933 privilegeWithdrawn (7), 4934 aACompromise (8) } 4936 -- extended key usage extension OID and syntax 4938 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 4940 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 4942 KeyPurposeId ::= OBJECT IDENTIFIER 4944 -- extended key purpose OIDs 4945 id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } 4946 id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } 4947 id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } 4948 id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } 4949 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 4950 id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 } 4952 -- inhibit any policy OID and syntax 4954 id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 } 4955 InhibitAnyPolicy ::= SkipCerts 4957 -- freshest (delta)CRL extension OID and syntax 4959 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } 4961 FreshestCRL ::= CRLDistributionPoints 4963 -- authority info access 4965 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 4967 AuthorityInfoAccessSyntax ::= 4968 SEQUENCE SIZE (1..MAX) OF AccessDescription 4970 AccessDescription ::= SEQUENCE { 4971 accessMethod OBJECT IDENTIFIER, 4972 accessLocation GeneralName } 4974 -- CRL number extension OID and syntax 4976 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 4978 CRLNumber ::= INTEGER (0..MAX) 4980 -- issuing distribution point extension OID and syntax 4982 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 4984 IssuingDistributionPoint ::= SEQUENCE { 4985 distributionPoint [0] DistributionPointName OPTIONAL, 4986 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 4987 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 4988 onlySomeReasons [3] ReasonFlags OPTIONAL, 4989 indirectCRL [4] BOOLEAN DEFAULT FALSE, 4990 onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE } 4992 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 4994 BaseCRLNumber ::= CRLNumber 4996 -- CRL reasons extension OID and syntax 4998 id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 } 5000 CRLReason ::= ENUMERATED { 5001 unspecified (0), 5002 keyCompromise (1), 5003 cACompromise (2), 5004 affiliationChanged (3), 5005 superseded (4), 5006 cessationOfOperation (5), 5007 certificateHold (6), 5008 removeFromCRL (8), 5009 privilegeWithdrawn (9), 5010 aACompromise (10) } 5012 -- certificate issuer CRL entry extension OID and syntax 5014 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } 5016 CertificateIssuer ::= GeneralNames 5018 -- hold instruction extension OID and syntax 5020 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 5022 HoldInstructionCode ::= OBJECT IDENTIFIER 5024 -- ANSI x9 holdinstructions 5026 -- ANSI x9 arc holdinstruction arc 5027 holdInstruction OBJECT IDENTIFIER ::= 5028 {joint-iso-itu-t(2) member-body(2) us(840) x9cm(10040) 2} 5030 -- ANSI X9 holdinstructions referenced by this standard 5031 id-holdinstruction-none OBJECT IDENTIFIER ::= 5032 {holdInstruction 1} -- deprecated 5033 id-holdinstruction-callissuer OBJECT IDENTIFIER ::= 5034 {holdInstruction 2} 5035 id-holdinstruction-reject OBJECT IDENTIFIER ::= 5036 {holdInstruction 3} 5038 -- invalidity date CRL entry extension OID and syntax 5040 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 5042 InvalidityDate ::= GeneralizedTime 5044 END 5045 Appendix B. ASN.1 Notes 5047 CAs MUST force the serialNumber to be a non-negative integer, that 5048 is, the sign bit in the DER encoding of the INTEGER value MUST be 5049 zero - this can be done by adding a leading (leftmost) `00'H octet if 5050 necessary. This removes a potential ambiguity in mapping between a 5051 string of octets and an integer value. 5053 As noted in section 4.1.2.2, serial numbers can be expected to 5054 contain long integers. Certificate users MUST be able to handle 5055 serialNumber values up to 20 octets in length. Conformant CAs MUST 5056 NOT use serialNumber values longer than 20 octets. 5058 The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 5059 constructs. A valid ASN.1 sequence will have zero or more entries. 5060 The SIZE (1..MAX) construct constrains the sequence to have at least 5061 one entry. MAX indicates the upper bound is unspecified. 5062 Implementations are free to choose an upper bound that suits their 5063 environment. 5065 The construct "positiveInt ::= INTEGER (0..MAX)" defines positiveInt 5066 as a subtype of INTEGER containing integers greater than or equal to 5067 zero. The upper bound is unspecified. Implementations are free to 5068 select an upper bound that suits their environment. 5070 The character string type PrintableString supports a very basic Latin 5071 character set: the lower case letters 'a' through 'z', upper case 5072 letters 'A' through 'Z', the digits '0' through '9', eleven special 5073 characters ' = ( ) + , - . / : ? and space. 5075 The character string type TeletexString is a superset of 5076 PrintableString. TeletexString supports a fairly standard (ascii- 5077 like) Latin character set, Latin characters with non-spacing accents 5078 and Japanese characters. 5080 The character string type UniversalString supports any of the 5081 characters allowed by ISO 10646-1. ISO 10646 is the Universal 5082 multiple-octet coded Character Set (UCS). ISO 10646-1 specifies the 5083 architecture and the "basic multilingual plane" - a large standard 5084 character set which includes all major world character standards. 5086 The character string type UTF8String was introduced in the 1997 5087 version of ASN.1, and UTF8String was added to the list of choices for 5088 DirectoryString in the 2001 version of X.520. UTF8String is a 5089 universal type and has been assigned tag number 12. The content of 5090 UTF8String was defined by RFC 2044 and updated in RFC 2279, "UTF-8, a 5091 transformation format of ISO 10646." 5092 In anticipation of these changes, and in conformance with IETF Best 5093 Practices codified in RFC 2277, IETF Policy on Character Sets and 5094 Languages, this document includes UTF8String as a choice in 5095 DirectoryString and the CPS qualifier extensions. 5097 Implementers should note that the DER encoding of the SET OF values 5098 requires ordering of the encodings of the values. In particular, 5099 this issue arises with respect to distinguished names. 5101 Object Identifiers (OIDs) are used throughout this specification to 5102 identify certificate policies, public key and signature algorithms, 5103 certificate extensions, etc. There is no maximum size for OIDs. 5104 This specification mandates support for OIDs which have arc elements 5105 with values that are less than 2^28, that is, they MUST be between 0 5106 and 268,435,455, inclusive. This allows each arc element to be 5107 represented within a single 32 bit word. Implementations MUST also 5108 support OIDs where the length of the dotted decimal (see [LDAP], 5109 section 4.1.2) string representation can be up to 100 bytes 5110 (inclusive). Implementations MUST be able to handle OIDs with up to 5111 20 elements (inclusive). CAs SHOULD NOT issue certificates which 5112 contain OIDs that exceed these requirements. 5114 Implementors are warned that the X.500 standards community has 5115 developed a series of extensibility rules. These rules determine 5116 when an ASN.1 definition can be changed without assigning a new 5117 object identifier (OID). For example, at least two extension 5118 definitions included in RFC 2459 have different ASN.1 definitions in 5119 this specification, but the same OID is used. If unknown elements 5120 appear within an extension, and the extension is not marked critical, 5121 those unknown elements ought to be ignored, as follows: 5123 (a) ignore all unknown bit name assignments within a bit string; 5125 (b) ignore all unknown named numbers in an ENUMERATED type or 5126 INTEGER type that is being used in the enumerated style, provided 5127 the number occurs as an optional element of a SET or SEQUENCE; and 5129 (c) ignore all unknown elements in SETs, at the end of SEQUENCEs, 5130 or in CHOICEs where the CHOICE is itself an optional element of a 5131 SET or SEQUENCE. 5133 If an extension containing unexpected values is marked critical, the 5134 implementation MUST reject the certificate or CRL containing the 5135 unrecognized extension. 5137 Appendix C. Examples 5139 This section contains four examples: three certificates and a CRL. 5141 The first two certificates and the CRL comprise a minimal 5142 certification path. 5144 Section C.1 contains an annotated hex dump of a "self-signed" 5145 certificate issued by a CA whose distinguished name is 5146 cn=us,o=gov,ou=nist. The certificate contains a DSA public key with 5147 parameters, and is signed by the corresponding DSA private key. 5149 Section C.2 contains an annotated hex dump of an end entity 5150 certificate. The end entity certificate contains a DSA public key, 5151 and is signed by the private key corresponding to the "self-signed" 5152 certificate in section C.1. 5154 Section C.3 contains a dump of an end entity certificate which 5155 contains an RSA public key and is signed with RSA and MD5. This 5156 certificate is not part of the minimal certification path. 5158 Section C.4 contains an annotated hex dump of a CRL. The CRL is 5159 issued by the CA whose distinguished name is cn=us,o=gov,ou=nist and 5160 the list of revoked certificates includes the end entity certificate 5161 presented in C.2. 5163 The certificates were processed using Peter Gutman's dumpasn1 utility 5164 to generate the output. The source for the dumpasn1 utility is 5165 available at . The 5166 binaries for the certificates and CRLs are available at 5167 . 5169 C.1 Certificate 5171 This section contains an annotated hex dump of a 699 byte version 3 5172 certificate. The certificate contains the following information: 5173 (a) the serial number is 23 (17 hex); 5174 (b) the certificate is signed with DSA and the SHA-1 hash algorithm; 5175 (c) the issuer's distinguished name is OU=NIST; O=gov; C=US 5176 (d) and the subject's distinguished name is OU=NIST; O=gov; C=US 5177 (e) the certificate was issued on June 30, 1997 and will expire on 5178 December 31, 1997; 5179 (f) the certificate contains a 1024 bit DSA public key with 5180 parameters; 5181 (g) the certificate contains a subject key identifier extension; and 5182 (h) the certificate is a CA certificate (as indicated through the 5183 basic constraints extension.) 5185 0 30 701: SEQUENCE { 5186 4 30 637: SEQUENCE { 5187 8 A0 3: [0] { 5189 10 02 1: INTEGER 2 5190 : } 5191 13 02 1: INTEGER 23 5192 16 30 9: SEQUENCE { 5193 18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5194 : } 5195 27 30 42: SEQUENCE { 5196 29 31 11: SET { 5197 31 30 9: SEQUENCE { 5198 33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5199 38 13 2: PrintableString 'US' 5200 : } 5201 : } 5202 42 31 12: SET { 5203 44 30 10: SEQUENCE { 5204 46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5205 51 13 3: PrintableString 'gov' 5206 : } 5207 : } 5208 56 31 13: SET { 5209 58 30 11: SEQUENCE { 5210 60 06 3: OBJECT IDENTIFIER 5211 organizationalUnitName (2 5 4 11) 5212 65 13 4: PrintableString 'NIST' 5213 : } 5214 : } 5215 : } 5216 71 30 30: SEQUENCE { 5217 73 17 13: UTCTime '970630000000Z' 5218 88 17 13: UTCTime '971231000000Z' 5219 : } 5220 103 30 42: SEQUENCE { 5221 105 31 11: SET { 5222 107 30 9: SEQUENCE { 5223 109 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5224 114 13 2: PrintableString 'US' 5225 : } 5226 : } 5227 118 31 12: SET { 5228 120 30 10: SEQUENCE { 5229 122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5230 127 13 3: PrintableString 'gov' 5231 : } 5232 : } 5233 132 31 13: SET { 5234 134 30 11: SEQUENCE { 5235 136 06 3: OBJECT IDENTIFIER 5236 organizationalUnitName (2 5 4 11) 5238 141 13 4: PrintableString 'NIST' 5239 : } 5240 : } 5241 : } 5242 147 30 440: SEQUENCE { 5243 151 30 300: SEQUENCE { 5244 155 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) 5245 164 30 287: SEQUENCE { 5246 168 02 129: INTEGER 5247 : 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC FB 95 5248 : 32 AC 01 12 33 B9 E0 1C AD 90 9B BC 48 54 9E F3 5249 : 94 77 3C 2C 71 35 55 E6 FE 4F 22 CB D5 D8 3E 89 5250 : 93 33 4D FC BD 4F 41 64 3E A2 98 70 EC 31 B4 50 5251 : DE EB F1 98 28 0A C9 3E 44 B3 FD 22 97 96 83 D0 5252 : 18 A3 E3 BD 35 5B FF EE A3 21 72 6A 7B 96 DA B9 5253 : 3F 1E 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A 5254 : FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48 63 FE 5255 : 43 5256 300 02 21: INTEGER 5257 : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA 55 F7 5258 : 7D 57 74 81 E5 5259 323 02 129: INTEGER 5260 : 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91 C0 8E 5261 : 47 F1 0A C3 01 47 C2 44 42 36 A9 92 81 DE 57 C5 5262 : E0 68 86 58 00 7B 1F F9 9B 77 A1 C5 10 A5 80 91 5263 : 78 51 51 3C F6 FC FC CC 46 C6 81 78 92 84 3D F4 5264 : 93 3D 0C 38 7E 1A 5B 99 4E AB 14 64 F6 0C 21 22 5265 : 4E 28 08 9C 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 5266 : 39 A2 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF 5267 : F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE 1E 57 5268 : 18 5269 : } 5270 : } 5271 455 03 133: BIT STRING 0 unused bits 5272 : 02 81 81 00 B5 9E 1F 49 04 47 D1 DB F5 3A DD CA 5273 : 04 75 E8 DD 75 F6 9B 8A B1 97 D6 59 69 82 D3 03 5274 : 4D FD 3B 36 5F 4A F2 D1 4E C1 07 F5 D1 2A D3 78 5275 : 77 63 56 EA 96 61 4D 42 0B 7A 1D FB AB 91 A4 CE 5276 : DE EF 77 C8 E5 EF 20 AE A6 28 48 AF BE 69 C3 6A 5277 : A5 30 F2 C2 B9 D9 82 2B 7D D9 C4 84 1F DE 0D E8 5278 : 54 D7 1B 99 2E B3 D0 88 F6 D6 63 9B A7 E2 0E 82 5279 : D4 3B 8A 68 1B 06 56 31 59 0B 49 EB 99 A5 D5 81 5280 : 41 7B C9 55 5281 : } 5282 591 A3 52: [3] { 5283 593 30 50: SEQUENCE { 5284 595 30 31: SEQUENCE { 5285 597 06 3: OBJECT IDENTIFIER 5286 subjectKeyIdentifier (2 5 29 14) 5287 602 04 24: OCTET STRING 5288 : 04 16 04 14 E7 26 C5 54 CD 5B A3 6F 35 68 95 AA 5289 : D5 FF 1C 21 E4 22 75 D6 5290 : } 5291 628 30 15: SEQUENCE { 5292 630 06 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19) 5293 635 01 1: BOOLEAN TRUE 5294 638 04 5: OCTET STRING 5295 : 30 03 01 01 FF 5296 : } 5297 : } 5298 : } 5299 : } 5300 645 30 9: SEQUENCE { 5301 647 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5302 : } 5303 656 03 47: BIT STRING 0 unused bits 5304 : 30 2C 02 14 6A F9 3F 72 30 7F 45 DC E5 50 C1 5E 5305 : 94 A0 6D C7 92 4C E5 E1 02 14 6F 61 B8 65 F7 AA 5306 : DF 46 1B F7 39 0D 0D 88 9E FE B6 83 F7 1A 5307 : } 5309 C.2 Certificate 5311 This section contains an annotated hex dump of a 730 byte version 3 5312 certificate. The certificate contains the following information: 5313 (a) the serial number is 18 (12 hex); 5314 (b) the certificate is signed with DSA and the SHA-1 hash algorithm; 5315 (c) the issuer's distinguished name is OU=nist; O=gov; C=US 5316 (d) and the subject's distinguished name is CN=Tim Polk; OU=nist; 5317 O=gov; C=US 5318 (e) the certificate was valid from July 30, 1997 through December 1, 5319 1997; 5320 (f) the certificate contains a 1024 bit DSA public key; 5321 (g) the certificate is an end entity certificate, as the basic 5322 constraints extension is not present; 5323 (h) the certificate contains an authority key identifier extension; 5324 and 5325 (i) the certificate includes one alternative name - an RFC 822 5326 address. 5328 0 30 734: SEQUENCE { 5329 4 30 669: SEQUENCE { 5330 8 A0 3: [0] { 5331 10 02 1: INTEGER 2 5332 : } 5333 13 02 1: INTEGER 18 5334 16 30 9: SEQUENCE { 5335 18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5336 : } 5337 27 30 42: SEQUENCE { 5338 29 31 11: SET { 5339 31 30 9: SEQUENCE { 5340 33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5341 38 13 2: PrintableString 'US' 5342 : } 5343 : } 5344 42 31 12: SET { 5345 44 30 10: SEQUENCE { 5346 46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5347 51 13 3: PrintableString 'gov' 5348 : } 5349 : } 5350 56 31 13: SET { 5351 58 30 11: SEQUENCE { 5352 60 06 3: OBJECT IDENTIFIER 5353 organizationalUnitName (2 5 4 11) 5354 65 13 4: PrintableString 'NIST' 5355 : } 5356 : } 5357 : } 5358 71 30 30: SEQUENCE { 5359 73 17 13: UTCTime '970730000000Z' 5360 88 17 13: UTCTime '971201000000Z' 5361 : } 5362 103 30 61: SEQUENCE { 5363 105 31 11: SET { 5364 107 30 9: SEQUENCE { 5365 109 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5366 114 13 2: PrintableString 'US' 5367 : } 5368 : } 5369 118 31 12: SET { 5370 120 30 10: SEQUENCE { 5371 122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5372 127 13 3: PrintableString 'gov' 5373 : } 5374 : } 5375 132 31 13: SET { 5376 134 30 11: SEQUENCE { 5377 136 06 3: OBJECT IDENTIFIER 5378 organizationalUnitName (2 5 4 11) 5379 141 13 4: PrintableString 'NIST' 5380 : } 5381 : } 5383 147 31 17: SET { 5384 149 30 15: SEQUENCE { 5385 151 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 5386 156 13 8: PrintableString 'Tim Polk' 5387 : } 5388 : } 5389 : } 5390 166 30 439: SEQUENCE { 5391 170 30 300: SEQUENCE { 5392 174 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) 5393 183 30 287: SEQUENCE { 5394 187 02 129: INTEGER 5395 : 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC FB 95 5396 : 32 AC 01 12 33 B9 E0 1C AD 90 9B BC 48 54 9E F3 5397 : 94 77 3C 2C 71 35 55 E6 FE 4F 22 CB D5 D8 3E 89 5398 : 93 33 4D FC BD 4F 41 64 3E A2 98 70 EC 31 B4 50 5399 : DE EB F1 98 28 0A C9 3E 44 B3 FD 22 97 96 83 D0 5400 : 18 A3 E3 BD 35 5B FF EE A3 21 72 6A 7B 96 DA B9 5401 : 3F 1E 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A 5402 : FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48 63 FE 5403 : 43 5404 319 02 21: INTEGER 5405 : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA 55 F7 5406 : 7D 57 74 81 E5 5407 342 02 129: INTEGER 5408 : 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91 C0 8E 5409 : 47 F1 0A C3 01 47 C2 44 42 36 A9 92 81 DE 57 C5 5410 : E0 68 86 58 00 7B 1F F9 9B 77 A1 C5 10 A5 80 91 5411 : 78 51 51 3C F6 FC FC CC 46 C6 81 78 92 84 3D F4 5412 : 93 3D 0C 38 7E 1A 5B 99 4E AB 14 64 F6 0C 21 22 5413 : 4E 28 08 9C 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 5414 : 39 A2 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF 5415 : F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE 1E 57 5416 : 18 5417 : } 5418 : } 5419 474 03 132: BIT STRING 0 unused bits 5420 : 02 81 80 30 B6 75 F7 7C 20 31 AE 38 BB 7E 0D 2B 5421 : AB A0 9C 4B DF 20 D5 24 13 3C CD 98 E5 5F 6C B7 5422 : C1 BA 4A BA A9 95 80 53 F0 0D 72 DC 33 37 F4 01 5423 : 0B F5 04 1F 9D 2E 1F 62 D8 84 3A 9B 25 09 5A 2D 5424 : C8 46 8E 2B D4 F5 0D 3B C7 2D C6 6C B9 98 C1 25 5425 : 3A 44 4E 8E CA 95 61 35 7C CE 15 31 5C 23 13 1E 5426 : A2 05 D1 7A 24 1C CB D3 72 09 90 FF 9B 9D 28 C0 5427 : A1 0A EC 46 9F 0D B8 D0 DC D0 18 A6 2B 5E F9 8F 5428 : B5 95 BE 5429 : } 5430 609 A3 66: [3] { 5431 611 30 64: SEQUENCE { 5432 613 30 25: SEQUENCE { 5433 615 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 5434 620 04 18: OCTET STRING 5435 : 30 10 81 0E 77 70 6F 6C 6B 40 6E 69 73 74 2E 67 5436 : 6F 76 5437 : } 5438 640 30 35: SEQUENCE { 5439 642 06 3: OBJECT IDENTIFIER 5440 authorityKeyIdentifier (2 5 29 35) 5441 647 04 28: OCTET STRING 5442 : 30 1A 80 18 04 16 04 14 E7 26 C5 54 CD 5B A3 6F 5443 : 35 68 95 AA D5 FF 1C 21 E4 22 75 D6 5444 : } 5445 : } 5446 : } 5447 : } 5448 677 30 9: SEQUENCE { 5449 679 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5450 : } 5451 688 03 48: BIT STRING 0 unused bits 5452 : 30 2D 02 14 37 FC 44 BF 7F 8D 18 1F 40 04 2F CF 5453 : EA CC 22 B2 16 01 FF 13 02 15 00 97 D0 24 96 0F 5454 : 64 8A C3 8D 41 B2 0E B9 26 D5 31 D1 A0 F1 BC 5455 : } 5457 C.3 End Entity Certificate Using RSA 5459 This section contains an annotated hex dump of a 675 byte version 3 5460 certificate. The certificate contains the following information: 5461 (a) the serial number is 256; 5462 (b) the certificate is signed with RSA and the MD2 hash algorithm; 5463 (c) the issuer's distinguished name is OU=Dept. Arquitectura de 5464 Computadors; O=Universitat Politecnica de Catalunya; C=ES 5465 (d) and the subject's distinguished name is CN=Francisco Jordan; 5466 OU=Dept. Arquitectura de Computadors; O=Universitat Politecnica de 5467 Catalunya; C=ES 5468 (e) the certificate was issued on May 21, 1996 and expired on May 21, 5469 1997; 5470 (f) the certificate contains a 768 bit RSA public key; 5471 (g) the certificate is an end entity certificate (not a CA 5472 certificate); 5473 (h) the certificate includes an alternative subject name and an 5474 alternative issuer name - bothe are URLs; 5475 (i) the certificate include an authority key identifier and 5476 certificate policies extensions; and 5477 (j) the certificate includes a critical key usage extension 5478 specifying the public is intended for generation of digital 5479 signatures. 5481 0 30 654: SEQUENCE { 5482 4 30 503: SEQUENCE { 5483 8 A0 3: [0] { 5484 10 02 1: INTEGER 2 5485 : } 5486 13 02 2: INTEGER 256 5487 17 30 13: SEQUENCE { 5488 19 06 9: OBJECT IDENTIFIER 5489 : sha1withRSAEncryption (1 2 840 113549 1 1 5) 5490 30 05 0: NULL 5491 : } 5492 32 30 42: SEQUENCE { 5493 34 31 11: SET { 5494 36 30 9: SEQUENCE { 5495 38 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5496 43 13 2: PrintableString 'US' 5497 : } 5498 : } 5499 47 31 12: SET { 5500 49 30 10: SEQUENCE { 5501 51 06 3: OBJECT IDENTIFIER 5502 organizationalUnitName (2 5 4 11) 5503 56 13 3: PrintableString 'gov' 5504 : } 5505 : } 5506 61 31 13: SET { 5507 63 30 11: SEQUENCE { 5508 65 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5509 70 13 4: PrintableString 'NIST' 5510 : } 5511 : } 5512 : } 5513 76 30 30: SEQUENCE { 5514 78 17 13: UTCTime '960521095826Z' 5515 93 17 13: UTCTime '970521095826Z' 5516 : } 5517 108 30 61: SEQUENCE { 5518 110 31 11: SET { 5519 112 30 9: SEQUENCE { 5520 114 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5521 119 13 2: PrintableString 'US' 5522 : } 5523 : } 5524 123 31 12: SET { 5525 125 30 10: SEQUENCE { 5526 127 06 3: OBJECT IDENTIFIER 5527 organizationalUnitName (2 5 4 11) 5528 132 13 3: PrintableString 'gov' 5529 : } 5530 : } 5531 137 31 13: SET { 5532 139 30 11: SEQUENCE { 5533 141 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5534 146 13 4: PrintableString 'NIST' 5535 : } 5536 : } 5537 152 31 17: SET { 5538 154 30 15: SEQUENCE { 5539 156 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 5540 161 13 8: PrintableString 'Tim Polk' 5541 : } 5542 : } 5543 : } 5544 171 30 159: SEQUENCE { 5545 174 30 13: SEQUENCE { 5546 176 06 9: OBJECT IDENTIFIER 5547 rsaEncryption (1 2 840 113549 1 1 1) 5548 187 05 0: NULL 5549 : } 5550 189 03 141: BIT STRING 0 unused bits 5551 : 30 81 89 02 81 81 00 E1 CE 06 C9 D7 00 DF 65 27 5552 : 45 1E 63 6A 09 A0 A0 10 4B AF DF 9D 36 1D 44 1F 5553 : B7 07 5D 36 92 09 6A 1A 96 C7 4E D9 86 0D 0F 77 5554 : 94 F5 82 62 68 9A F2 D7 76 F5 9A 35 C7 B3 7F 4F 5555 : BE 64 CF A3 0C B3 84 32 80 F5 CA 77 29 C9 76 0B 5556 : 4C 38 19 EE 61 6F BA 68 E0 03 85 46 34 AB 84 64 5557 : 7F 43 69 02 C0 20 86 BD B1 D4 AD 21 A9 1A 8F CF 5558 : 96 83 86 92 57 5B 43 09 28 4C F2 5A 04 AD E5 DE 5559 : 9E 4F E8 38 3C F0 89 02 03 01 00 01 5560 : } 5561 333 A3 175: [3] { 5562 336 30 172: SEQUENCE { 5563 339 30 63: SEQUENCE { 5564 341 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 5565 346 04 56: OCTET STRING 5566 : 30 36 86 34 68 74 74 70 3A 2F 2F 77 77 77 2E 69 5567 : 74 6C 2E 6E 69 73 74 2E 67 6F 76 2F 64 69 76 38 5568 : 39 33 2F 73 74 61 66 66 2F 70 6F 6C 6B 2F 69 6E 5569 : 64 65 78 2E 68 74 6D 6C 5570 : } 5571 404 30 31: SEQUENCE { 5572 406 06 3: OBJECT IDENTIFIER issuerAltName (2 5 29 18) 5573 411 04 24: OCTET STRING 5574 : 30 16 86 14 68 74 74 70 3A 2F 2F 77 77 77 2E 6E 5575 : 69 73 74 2E 67 6F 76 2F 5576 : } 5577 437 30 31: SEQUENCE { 5578 439 06 3: OBJECT IDENTIFIER 5579 authorityKeyIdentifier (2 5 29 35) 5580 444 04 24: OCTET STRING 5581 : 30 16 80 14 30 12 80 10 0E 6B 3A BF 04 EA 04 C3 5582 : 0E 6B 3A BF 04 EA 04 C3 5583 : } 5584 470 30 23: SEQUENCE { 5585 472 06 3: OBJECT IDENTIFIER 5586 certificatePolicies (2 5 29 32) 5587 477 04 16: OCTET STRING 5588 : 30 0E 30 0C 06 0A 60 86 48 01 65 03 02 01 30 09 5589 : } 5590 495 30 14: SEQUENCE { 5591 497 06 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) 5592 502 01 1: BOOLEAN TRUE 5593 505 04 4: OCTET STRING 5594 : 03 02 07 80 5595 : } 5596 : } 5597 : } 5598 : } 5599 511 30 13: SEQUENCE { 5600 513 06 9: OBJECT IDENTIFIER 5601 : sha1withRSAEncryption (1 2 840 113549 1 1 5) 5602 524 05 0: NULL 5603 : } 5604 526 03 129: BIT STRING 0 unused bits 5605 : C1 25 6F AB 72 C0 5D DA E4 2F D5 E1 B0 25 D8 B4 5606 : F1 82 95 D6 0D A5 4E 4F A1 23 E1 13 A4 9C 3D C5 5607 : 7F FD 05 EC 75 06 30 66 97 75 A6 5D 8F 97 BA B4 5608 : EC A9 43 19 8D B7 54 FD E9 AD 43 B8 3C 8B D3 9E 5609 : C7 C7 27 E3 1A AD D3 79 AC 65 5A 52 78 C4 D0 43 5610 : 81 50 F7 8A BA E2 30 1A 6D D0 78 A0 4E AE 2E 79 5611 : 37 0C 93 05 5C D1 9C 1B B2 62 73 D1 EA 50 B7 84 5612 : 29 92 74 34 CF BA AA 2C 4D 43 59 EF 98 0C 41 6C 5613 : } 5615 C.4 Certificate Revocation List 5617 This section contains an annotated hex dump of a version 2 CRL with 5618 one extension (cRLNumber). The CRL was issued by OU=nist;O=gov;C=us 5619 on July 7, 1996; the next scheduled issuance was August 7, 1996. The 5620 CRL includes one revoked certificates: serial number 18 (12 hex). 5621 The CRL itself is number 18, and it was signed with DSA and SHA-1. 5623 0 30 203: SEQUENCE { 5624 3 30 140: SEQUENCE { 5625 6 02 1: INTEGER 1 5626 9 30 9: SEQUENCE { 5627 11 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5628 : } 5629 20 30 42: SEQUENCE { 5630 22 31 11: SET { 5631 24 30 9: SEQUENCE { 5632 26 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5633 31 13 2: PrintableString 'US' 5634 : } 5635 : } 5636 35 31 12: SET { 5637 37 30 10: SEQUENCE { 5638 39 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5639 44 13 3: PrintableString 'gov' 5640 : } 5641 : } 5642 49 31 13: SET { 5643 51 30 11: SEQUENCE { 5644 53 06 3: OBJECT IDENTIFIER 5645 organizationalUnitName (2 5 4 11) 5646 58 13 4: PrintableString 'NIST' 5647 : } 5648 : } 5649 : } 5650 64 17 13: UTCTime '970807000000Z' 5651 79 17 13: UTCTime '970907000000Z' 5652 94 30 34: SEQUENCE { 5653 96 30 32: SEQUENCE { 5654 98 02 1: INTEGER 18 5655 101 17 13: UTCTime '970731000000Z' 5656 116 30 12: SEQUENCE { 5657 118 30 10: SEQUENCE { 5658 120 06 3: OBJECT IDENTIFIER cRLReason (2 5 29 21) 5659 125 04 3: OCTET STRING 5660 : 0A 01 01 5661 : } 5662 : } 5663 : } 5664 : } 5665 130 A0 14: [0] { 5666 132 30 12: SEQUENCE { 5667 134 30 10: SEQUENCE { 5668 136 06 3: OBJECT IDENTIFIER cRLNumber (2 5 29 20) 5669 141 04 3: OCTET STRING 5670 : 02 01 12 5671 : } 5672 : } 5673 : } 5674 : } 5675 146 30 9: SEQUENCE { 5676 148 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5677 : } 5678 157 03 47: BIT STRING 0 unused bits 5679 : 30 2C 02 14 79 1F F6 93 0B 84 06 D6 A0 7C 8D 68 5680 : A7 52 2E 5F 3F 89 9B 4B 02 14 66 D4 B5 2A 68 36 5681 : 9B 72 88 58 E3 89 19 AD 81 89 2E 96 BB CC 5682 : } 5684 Appendix D. Author Addresses: 5686 Russell Housley 5687 RSA Laboratories 5688 918 Spring Knoll Drive 5689 Herndon, VA 20170 5690 USA 5691 rhousley@rsasecurity.com 5693 Warwick Ford 5694 VeriSign, Inc. 5695 One Alewife Center 5696 Cambridge, MA 02140 5697 USA 5698 wford@verisign.com 5700 Tim Polk 5701 NIST 5702 Building 820, Room 426 5703 Gaithersburg, MD 20899 5704 USA 5705 wpolk@nist.gov 5707 David Solo 5708 Citigroup 5709 909 Third Ave, 16th Floor 5710 New York, NY 10043 5711 USA 5712 dsolo@alum.mit.edu 5714 Appendix E. Full Copyright Statement 5716 Copyright (C) The Internet Society (date). All Rights Reserved. 5718 This document and translations of it may be copied and furnished to 5719 others, and derivative works that comment on or otherwise explain it 5720 or assist in its implementation may be prepared, copied, published 5721 and distributed, in whole or in part, without restriction of any 5722 kind, provided that the above copyright notice and this paragraph are 5723 included on all such copies and derivative works. In addition, the 5724 ASN.1 modules presented in Appendix A may be used in whole or in part 5725 without inclusion of the copyright notice. However, this document 5726 itself may not be modified in any way, such as by removing the 5727 copyright notice or references to the Internet Society or other 5728 Internet organizations, except as needed for the purpose of 5729 developing Internet standards in which case the procedures for 5730 copyrights defined in the Internet Standards process shall be 5731 followed, or as required to translate it into languages other than 5732 English. 5734 The limited permissions granted above are perpetual and will not be 5735 revoked by the Internet Society or its successors or assigns. This 5736 document and the information contained herein is provided on an "AS 5737 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 5738 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 5739 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 5740 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 5741 OR FITNESS FOR A PARTICULAR PURPOSE.