idnits 2.17.00 (12 Aug 2021) /tmp/idnits18481/draft-ietf-pkix-new-part1-06.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 59 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 5 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 25 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 first octets (the first characters of the first line) of this draft are 'PK', which can make Internet Explorer erroneously think that it is a zip file. It is recommended that you change this, for instance by inserting a blank line before the line starting with 'PK'. == 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 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 (April 2001) is 7705 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 5411 -- Looks like a reference, but probably isn't: '1' on line 4759 -- Looks like a reference, but probably isn't: '2' on line 4760 -- Looks like a reference, but probably isn't: '3' on line 5306 == Missing Reference: 'ISO 8859-1' is mentioned on line 915, but not defined -- Looks like a reference, but probably isn't: '4' on line 4762 -- Looks like a reference, but probably isn't: '5' on line 4622 -- Looks like a reference, but probably isn't: '6' on line 4623 -- Looks like a reference, but probably isn't: '7' on line 4624 -- Looks like a reference, but probably isn't: '8' on line 4625 == Missing Reference: 'RFC1738' is mentioned on line 2558, but not defined ** Obsolete undefined reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) == Missing Reference: 'RFC1778' is mentioned on line 2558, but not defined ** Obsolete undefined reference: RFC 1778 (Obsoleted by RFC 3494) == Missing Reference: 'UNIVERSAL 28' is mentioned on line 3915, but not defined == Missing Reference: 'UNIVERSAL 30' is mentioned on line 3918, but not defined == Missing Reference: 'UNIVERSAL 12' is mentioned on line 3922, but not defined == Missing Reference: 'APPLICATION 1' is mentioned on line 4228, but not defined == Missing Reference: 'APPLICATION 2' is mentioned on line 4234, but not defined == Missing Reference: 'LDAP' is mentioned on line 4878, but not defined == Unused Reference: 'RFC 1423' is defined on line 3669, but no explicit reference was found in the text == Unused Reference: 'RFC 1778' is defined on line 3683, but no explicit reference was found in the text == Unused Reference: 'RFC 1883' is defined on line 3687, but no explicit reference was found in the text == Unused Reference: 'RFC 2119' is defined on line 3690, but no explicit reference was found in the text == Unused Reference: 'RFC 2277' is defined on line 3697, but no explicit reference was found in the text == Unused Reference: 'RFC 2279' is defined on line 3700, but no explicit reference was found in the text == Unused Reference: 'PKIX TSA' is defined on line 3739, 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: 18 errors (**), 0 flaws (~~), 27 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PKIX Working Group R. Housley (RSA Laboratories) 2 Internet Draft W. Ford (VeriSign) 3 W. Polk (NIST) 4 D. Solo (Citigroup) 5 expires in six months April 2001 7 Internet X.509 Public Key Infrastructure 9 Certificate and CRL Profile 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 To view the entire list of current Internet-Drafts, please check the 33 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 34 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 35 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 36 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 38 Copyright (C) The Internet Society (2001). All Rights Reserved. 40 Abstract 42 This is the sixth draft of a specification based upon RFC 2459. When 43 complete, this specification will obsolete RFC 2459. This 44 specification includes minor edits and clarifications. The most 45 notable departures from RFC 2459 are found in Section 6, Path 46 Validation. In RFC 2459, the reader was expected to augment the path 47 validation algorithm, which concentrated upon policy processing, with 48 information embedded in earlier sections. For example, parameter 49 inheritance is discussed in Section 7, Algorithm Support, and can 50 certainly affect the validity of a certification path. However, 51 parameter inheritance was omitted from the path validation algorithm 52 in RFC 2459. In this draft, the path validation algorithm has a 53 comprehensive and extremely detailed description. Details such as 54 parameter inheritance are covered thoroughly. In addition, this 55 draft anticipates certain corrections proposed in the X.509 standard 56 for the policy processing aspects of path validation. 58 A new section 6.3, CRL validation, has been added as well. This 59 section provides a supplement to the path validation algorithm that 60 determines if a particular CRL may be used to verify the status of a 61 particular certificate. (The basic path validation algorithm is, by 62 design, independent of the type and format of status information.) 64 The most significant enhancement in draft five is a refinement of the 65 processing rules for path length constraints when applied to CA 66 certificates. This draft also completes the removal of processing 67 rules for unique identifiers. This was generally performed in the 68 fourth draft, but some details were overlooked. This draft also 69 incorporates significant corrections to the ASN.1 modules in the 70 appendices. 72 This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use 73 in the Internet. An overview of the approach and model are provided 74 as an introduction. The X.509 v3 certificate format is described in 75 detail, with additional information regarding the format and 76 semantics of Internet name forms (e.g., IP addresses). Standard 77 certificate extensions are described and one new Internet-specific 78 extension is defined. A required set of certificate extensions is 79 specified. The X.509 v2 CRL format is described and a required 80 extension set is defined as well. An algorithm for X.509 certificate 81 path validation is described. Supplemental information is provided 82 describing the format of public keys and digital signatures in X.509 83 certificates for common Internet public key encryption algorithms 84 (i.e., RSA, DSA, and Diffie-Hellman). ASN.1 modules and examples are 85 provided in the appendices. 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119. 91 Please send comments on this document to the ietf-pkix@imc.org mail 92 list. 94 Table of Contents 96 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 6 97 2 Requirements and Assumptions . . . . . . . . . . . . . . . . . . 7 98 2.1 Communication and Topology . . . . . . . . . . . . . . . . . . 7 99 2.2 Acceptability Criteria . . . . . . . . . . . . . . . . . . . . 8 100 2.3 User Expectations . . . . . . . . . . . . . . . . . . . . . . . 8 101 2.4 Administrator Expectations . . . . . . . . . . . . . . . . . . 8 102 3 Overview of Approach . . . . . . . . . . . . . . . . . . . . . . 8 103 3.1 X.509 Version 3 Certificate . . . . . . . . . . . . . . . . . . 10 104 3.2 Certification Paths and Trust . . . . . . . . . . . . . . . . . 11 105 3.3 Revocation . . . . . . . . . . . . . . . . . . . . . . . . . . 13 106 3.4 Operational Protocols . . . . . . . . . . . . . . . . . . . . . 14 107 3.5 Management Protocols . . . . . . . . . . . . . . . . . . . . . 14 108 4 Certificate and Certificate Extensions Profile . . . . . . . . . 15 109 4.1 Basic Certificate Fields . . . . . . . . . . . . . . . . . . . 16 110 4.1.1 Certificate Fields . . . . . . . . . . . . . . . . . . . . . 17 111 4.1.1.1 tbsCertificate . . . . . . . . . . . . . . . . . . . . . . 17 112 4.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . . . . . 17 113 4.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . . . . . 18 114 4.1.2 TBSCertificate . . . . . . . . . . . . . . . . . . . . . . . 18 115 4.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . . . . . 18 116 4.1.2.2 Serial number . . . . . . . . . . . . . . . . . . . . . . . 19 117 4.1.2.3 Signature . . . . . . . . . . . . . . . . . . . . . . . . . 19 118 4.1.2.4 Issuer . . . . . . . . . . . . . . . . . . . . . . . . . . 19 119 4.1.2.5 Validity . . . . . . . . . . . . . . . . . . . . . . . . . 23 120 4.1.2.5.1 UTCTime . . . . . . . . . . . . . . . . . . . . . . . . . 23 121 4.1.2.5.2 GeneralizedTime . . . . . . . . . . . . . . . . . . . . . 23 122 4.1.2.6 Subject . . . . . . . . . . . . . . . . . . . . . . . . . . 24 123 4.1.2.7 Subject Public Key Info . . . . . . . . . . . . . . . . . . 25 124 4.1.2.8 Unique Identifiers . . . . . . . . . . . . . . . . . . . . 25 125 4.1.2.9 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 25 126 4.2 Certificate Extensions . . . . . . . . . . . . . . . . . . . . 25 127 4.2.1 Standard Extensions . . . . . . . . . . . . . . . . . . . . . 26 128 4.2.1.1 Authority Key Identifier . . . . . . . . . . . . . . . . . 27 129 4.2.1.2 Subject Key Identifier . . . . . . . . . . . . . . . . . . 27 130 4.2.1.3 Key Usage . . . . . . . . . . . . . . . . . . . . . . . . . 29 131 4.2.1.4 Private Key Usage Period . . . . . . . . . . . . . . . . . 30 132 4.2.1.5 Certificate Policies . . . . . . . . . . . . . . . . . . . 31 133 4.2.1.6 Policy Mappings . . . . . . . . . . . . . . . . . . . . . . 33 134 4.2.1.7 Subject Alternative Name . . . . . . . . . . . . . . . . . 34 135 4.2.1.8 Issuer Alternative Name . . . . . . . . . . . . . . . . . . 36 136 4.2.1.9 Subject Directory Attributes . . . . . . . . . . . . . . . 37 137 4.2.1.10 Basic Constraints . . . . . . . . . . . . . . . . . . . . 37 138 4.2.1.11 Name Constraints . . . . . . . . . . . . . . . . . . . . . 38 139 4.2.1.12 Policy Constraints . . . . . . . . . . . . . . . . . . . . 40 140 4.2.1.13 Extended key usage field . . . . . . . . . . . . . . . . . 41 141 4.2.1.14 CRL Distribution Points . . . . . . . . . . . . . . . . . 42 142 4.2.1.15 Inhibit Any-Policy . . . . . . . . . . . . . . . . . . . . 43 143 4.2.1.16 Freshest CRL . . . . . . . . . . . . . . . . . . . . . . . 43 144 4.2.2 Internet Certificate Extensions . . . . . . . . . . . . . . . 44 145 4.2.2.1 Authority Information Access . . . . . . . . . . . . . . . 44 146 4.2.2.2 Subject Information Access . . . . . . . . . . . . . . . . 45 147 5 CRL and CRL Extensions Profile . . . . . . . . . . . . . . . . . 47 148 5.1 CRL Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 47 149 5.1.1 CertificateList Fields . . . . . . . . . . . . . . . . . . . 48 150 5.1.1.1 tbsCertList . . . . . . . . . . . . . . . . . . . . . . . . 48 151 5.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . . . . . 49 152 5.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . . . . . 49 153 5.1.2 Certificate List "To Be Signed" . . . . . . . . . . . . . . . 49 154 5.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . . . . . 49 155 5.1.2.2 Signature . . . . . . . . . . . . . . . . . . . . . . . . . 49 156 5.1.2.3 Issuer Name . . . . . . . . . . . . . . . . . . . . . . . . 50 157 5.1.2.4 This Update . . . . . . . . . . . . . . . . . . . . . . . . 50 158 5.1.2.5 Next Update . . . . . . . . . . . . . . . . . . . . . . . . 50 159 5.1.2.6 Revoked Certificates . . . . . . . . . . . . . . . . . . . 51 160 5.1.2.7 Extensions . . . . . . . . . . . . . . . . . . . . . . . . 51 161 5.2 CRL Extensions . . . . . . . . . . . . . . . . . . . . . . . . 51 162 5.2.1 Authority Key Identifier . . . . . . . . . . . . . . . . . . 51 163 5.2.2 Issuer Alternative Name . . . . . . . . . . . . . . . . . . . 52 164 5.2.3 CRL Number . . . . . . . . . . . . . . . . . . . . . . . . . 52 165 5.2.4 Delta CRL Indicator . . . . . . . . . . . . . . . . . . . . . 52 166 5.2.5 Issuing Distribution Point . . . . . . . . . . . . . . . . . 54 167 5.2.6 Freshest CRL . . . . . . . . . . . . . . . . . . . . . . . . 55 168 5.3 CRL Entry Extensions . . . . . . . . . . . . . . . . . . . . . 55 169 5.3.1 Reason Code . . . . . . . . . . . . . . . . . . . . . . . . . 56 170 5.3.2 Hold Instruction Code . . . . . . . . . . . . . . . . . . . . 56 171 5.3.3 Invalidity Date . . . . . . . . . . . . . . . . . . . . . . . 57 172 5.3.4 Certificate Issuer . . . . . . . . . . . . . . . . . . . . . 57 173 6 Certificate Path Validation . . . . . . . . . . . . . . . . . . . 58 174 6.1 Basic Path Validation . . . . . . . . . . . . . . . . . . . . . 58 175 6.1.1 Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 176 6.1.2 Initialization . . . . . . . . . . . . . . . . . . . . . . . . 62 177 6.1.3 Basic Certificate Processing . . . . . . . . . . . . . . . . . 65 178 6.1.4 Preparation for Certificate i+1 . . . . . . . . . . . . . . . 70 179 6.1.5 Wrap-up procedure . . . . . . . . . . . . . . . . . . . . . . 73 180 6.1.6 Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 181 6.2 Extending Path Validation . . . . . . . . . . . . . . . . . . . 75 182 6.3 CRL Validation . . . . . . . . . . . . . . . . . . . . . . . . 75 183 6.3.1 Revocation Inputs . . . . . . . . . . . . . . . . . . . . . . 76 184 6.3.2 Initialization and Revocation State Variables . . . . . . . . 76 185 6.3.3 CRL Processing . . . . . . . . . . . . . . . . . . . . . . . 77 186 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 187 8 Intellectual Property Rights . . . . . . . . . . . . . . . . . . 81 188 9 Security Considerations . . . . . . . . . . . . . . . . . . . . . 81 189 Appendix A. ASN.1 Structures and OIDs . . . . . . . . . . . . . . . 85 190 A.1 Explicitly Tagged Module, 1988 Syntax . . . . . . . . . . . . . 85 191 A.2 Implicitly Tagged Module, 1988 Syntax . . . . . . . . . . . . . 98 192 Appendix B. ASN.1 Notes . . . . . . . . . . . . . . . . . . . . . . 105 193 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . . 106 194 C.1 Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . 107 195 C.2 Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . 110 196 C.3 End-Entity Certificate Using RSA . . . . . . . . . . . . . . . 113 197 C.4 Certificate Revocation List . . . . . . . . . . . . . . . . . . 116 198 Appendix D. Author Addresses . . . . . . . . . . . . . . . . . . . 118 199 Appendix E. Full Copyright Statement . . . . . . . . . . . . . . . 118 200 1 Introduction 202 This specification is one part of a family of standards for the X.509 203 Public Key Infrastructure (PKI) for the Internet. This specification 204 is a standalone document; implementations of this standard may 205 proceed independent from the other parts. 207 This specification profiles the format and semantics of certificates 208 and certificate revocation lists for the Internet PKI. Procedures 209 are described for processing of certification paths in the Internet 210 environment. Encoding rules are provided for popular cryptographic 211 algorithms. Finally, ASN.1 modules are provided in the appendices 212 for all data structures defined or referenced. 214 The specification describes the requirements which inspire the 215 creation of this document and the assumptions which affect its scope 216 in Section 2. Section 3 presents an architectural model and 217 describes its relationship to previous IETF and ISO/IEC/ITU 218 standards. In particular, this document's relationship with the IETF 219 PEM specifications and the ISO/IEC/ITU X.509 documents are described. 221 The specification profiles the X.509 version 3 certificate in Section 222 4, and the X.509 version 2 certificate revocation list (CRL) in 223 Section 5. The profiles include the identification of ISO/IEC/ITU 224 and ANSI extensions which may be useful in the Internet PKI. The 225 profiles are presented in the 1988 Abstract Syntax Notation One 226 (ASN.1) rather than the 1994 syntax used in the ISO/IEC/ITU 227 standards. 229 This specification also includes path validation procedures in 230 Section 6. These procedures are based upon the ISO/IEC/ITU 231 definition, but the presentation assumes one or more self-signed 232 trusted CA certificates. Implementations are required to derive the 233 same results but are not required to use the specified procedures. 235 Procedures for identification and encoding of public key materials 236 and digital signatures are defined in [PKIX ALGS]. Implementations of 237 this specification are not required to use any particular 238 cryptographic algorithms. However, conforming implementations which 239 use the algorithms identified in [PKIX ALGS] are required to identify 240 and encode the public key materials and digital signatures as 241 described in that specification. 243 Finally, three appendices are provided to aid implementers. Appendix 244 A contains all ASN.1 structures defined or referenced within this 245 specification. As above, the material is presented in the 1988 246 Abstract Syntax Notation One (ASN.1) rather than the 1994 syntax. 247 Appendix B contains notes on less familiar features of the ASN.1 248 notation used within this specification. Appendix C contains 249 examples of a conforming certificate and a conforming CRL. 251 2 Requirements and Assumptions 253 The goal of this specification is to develop a profile to facilitate 254 the use of X.509 certificates within Internet applications for those 255 communities wishing to make use of X.509 technology. Such 256 applications may include WWW, electronic mail, user authentication, 257 and IPsec. In order to relieve some of the obstacles to using X.509 258 certificates, this document defines a profile to promote the 259 development of certificate management systems; development of 260 application tools; and interoperability determined by policy. 262 Some communities will need to supplement, or possibly replace, this 263 profile in order to meet the requirements of specialized application 264 domains or environments with additional authorization, assurance, or 265 operational requirements. However, for basic applications, common 266 representations of frequently used attributes are defined so that 267 application developers can obtain necessary information without 268 regard to the issuer of a particular certificate or certificate 269 revocation list (CRL). 271 A certificate user should review the certificate policy generated by 272 the certification authority (CA) before relying on the authentication 273 or non-repudiation services associated with the public key in a 274 particular certificate. To this end, this standard does not 275 prescribe legally binding rules or duties. 277 As supplemental authorization and attribute management tools emerge, 278 such as attribute certificates, it may be appropriate to limit the 279 authenticated attributes that are included in a certificate. These 280 other management tools may provide more appropriate methods of 281 conveying many authenticated attributes. 283 2.1 Communication and Topology 285 The users of certificates will operate in a wide range of 286 environments with respect to their communication topology, especially 287 users of secure electronic mail. This profile supports users without 288 high bandwidth, real-time IP connectivity, or high connection 289 availability. In addition, the profile allows for the presence of 290 firewall or other filtered communication. 292 This profile does not assume the deployment of an X.500 Directory 293 system. The profile does not prohibit the use of an X.500 Directory, 294 but other means of distributing certificates and certificate 295 revocation lists (CRLs) may be used. 297 2.2 Acceptability Criteria 299 The goal of the Internet Public Key Infrastructure (PKI) is to meet 300 the needs of deterministic, automated identification, authentication, 301 access control, and authorization functions. Support for these 302 services determines the attributes contained in the certificate as 303 well as the ancillary control information in the certificate such as 304 policy data and certification path constraints. 306 2.3 User Expectations 308 Users of the Internet PKI are people and processes who use client 309 software and are the subjects named in certificates. These uses 310 include readers and writers of electronic mail, the clients for WWW 311 browsers, WWW servers, and the key manager for IPsec within a router. 312 This profile recognizes the limitations of the platforms these users 313 employ and the limitations in sophistication and attentiveness of the 314 users themselves. This manifests itself in minimal user 315 configuration responsibility (e.g., trusted CA keys, rules), explicit 316 platform usage constraints within the certificate, certification path 317 constraints which shield the user from many malicious actions, and 318 applications which sensibly automate validation functions. 320 2.4 Administrator Expectations 322 As with user expectations, the Internet PKI profile is structured to 323 support the individuals who generally operate CAs. Providing 324 administrators with unbounded choices increases the chances that a 325 subtle CA administrator mistake will result in broad compromise. 326 Also, unbounded choices greatly complicate the software that process 327 and validate the certificates created by the CA. 329 3 Overview of Approach 331 Following is a simplified view of the architectural model assumed by 332 the PKIX specifications. 334 +---+ 335 | C | +------------+ 336 | e | <-------------------->| End entity | 337 | r | Operational +------------+ 338 | t | transactions ^ 339 | | and management | Management 340 | / | transactions | transactions 341 | | | PKI users 342 | C | v 343 | R | -------------------+--+-----------+---------------- 344 | L | ^ ^ 345 | | | | PKI management 346 | | v | entities 347 | R | +------+ | 348 | e | <---------------------| RA | <---+ | 349 | p | Publish certificate +------+ | | 350 | o | | | 351 | s | | | 352 | I | v v 353 | t | +------------+ 354 | o | <------------------------------| CA | 355 | r | Publish certificate +------------+ 356 | y | Publish CRL ^ 357 | | | 358 +---+ Management | 359 transactions | 360 v 361 +------+ 362 | CA | 363 +------+ 365 Figure 1 - PKI Entities 367 The components in this model are: 369 end entity: user of PKI certificates and/or end user system that 370 is the subject of a certificate; 371 CA: certification authority; 372 RA: registration authority, i.e., an optional system to 373 which a CA delegates certain management functions; 374 repository: a system or collection of distributed systems that 375 store certificates and CRLs and serves as a means of 376 distributing these certificates and CRLs to end 377 entities. 379 3.1 X.509 Version 3 Certificate 381 Users of a public key require confidence that the associated private 382 key is owned by the correct remote subject (person or system) with 383 which an encryption or digital signature mechanism will be used. 384 This confidence is obtained through the use of public key 385 certificates, which are data structures that bind public key values 386 to subjects. The binding is asserted by having a trusted CA 387 digitally sign each certificate. The CA may base this assertion upon 388 technical means (a.k.a., proof of posession through a challenge- 389 response protocol), presentation of the private key, or on an 390 assertion by the subject. A certificate has a limited valid lifetime 391 which is indicated in its signed contents. Because a certificate's 392 signature and timeliness can be independently checked by a 393 certificate-using client, certificates can be distributed via 394 untrusted communications and server systems, and can be cached in 395 unsecured storage in certificate-using systems. 397 ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8, which was 398 first published in 1988 as part of the X.500 Directory 399 recommendations, defines a standard certificate format [X.509]. The 400 certificate format in the 1988 standard is called the version 1 (v1) 401 format. When X.500 was revised in 1993, two more fields were added, 402 resulting in the version 2 (v2) format. 404 The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993, 405 include specifications for a public key infrastructure based on X.509 406 v1 certificates [RFC 1422]. The experience gained in attempts to 407 deploy RFC 1422 made it clear that the v1 and v2 certificate formats 408 are deficient in several respects. Most importantly, more fields 409 were needed to carry information which PEM design and implementation 410 experience has proven necessary. In response to these new 411 requirements, ISO/IEC/ITU and ANSI X9 developed the X.509 version 3 412 (v3) certificate format. The v3 format extends the v2 format by 413 adding provision for additional extension fields. Particular 414 extension field types may be specified in standards or may be defined 415 and registered by any organization or community. In June 1996, 416 standardization of the basic v3 format was completed [X.509]. 418 ISO/IEC/ITU and ANSI X9 have also developed standard extensions for 419 use in the v3 extensions field [X.509][X9.55]. These extensions can 420 convey such data as additional subject identification information, 421 key attribute information, policy information, and certification path 422 constraints. 424 However, the ISO/IEC/ITU and ANSI X9 standard extensions are very 425 broad in their applicability. In order to develop interoperable 426 implementations of X.509 v3 systems for Internet use, it is necessary 427 to specify a profile for use of the X.509 v3 extensions tailored for 428 the Internet. It is one goal of this document to specify a profile 429 for Internet WWW, electronic mail, and IPsec applications. 430 Environments with additional requirements may build on this profile 431 or may replace it. 433 3.2 Certification Paths and Trust 435 A user of a security service requiring knowledge of a public key 436 generally needs to obtain and validate a certificate containing the 437 required public key. If the public-key user does not already hold an 438 assured copy of the public key of the CA that signed the certificate, 439 the CA's name, and related information (such as the validity period 440 or name constraints), then it might need an additional certificate to 441 obtain that public key. In general, a chain of multiple certificates 442 may be needed, comprising a certificate of the public key owner (the 443 end entity) signed by one CA, and zero or more additional 444 certificates of CAs signed by other CAs. Such chains, called 445 certification paths, are required because a public key user is only 446 initialized with a limited number of assured CA public keys. 448 There are different ways in which CAs might be configured in order 449 for public key users to be able to find certification paths. For 450 PEM, RFC 1422 defined a rigid hierarchical structure of CAs. There 451 are three types of PEM certification authority: 453 (a) Internet Policy Registration Authority (IPRA): This 454 authority, operated under the auspices of the Internet Society, 455 acts as the root of the PEM certification hierarchy at level 1. 456 It issues certificates only for the next level of authorities, 457 PCAs. All certification paths start with the IPRA. 459 (b) Policy Certification Authorities (PCAs): PCAs are at level 2 460 of the hierarchy, each PCA being certified by the IPRA. A PCA 461 shall establish and publish a statement of its policy with respect 462 to certifying users or subordinate certification authorities. 463 Distinct PCAs aim to satisfy different user needs. For example, 464 one PCA (an organizational PCA) might support the general 465 electronic mail needs of commercial organizations, and another PCA 466 (a high-assurance PCA) might have a more stringent policy designed 467 for satisfying legally binding digital signature requirements. 469 (c) Certification Authorities (CAs): CAs are at level 3 of the 470 hierarchy and can also be at lower levels. Those at level 3 are 471 certified by PCAs. CAs represent, for example, particular 472 organizations, particular organizational units (e.g., departments, 473 groups, sections), or particular geographical areas. 475 RFC 1422 furthermore has a name subordination rule which requires 476 that a CA can only issue certificates for entities whose names are 477 subordinate (in the X.500 naming tree) to the name of the CA itself. 478 The trust associated with a PEM certification path is implied by the 479 PCA name. The name subordination rule ensures that CAs below the PCA 480 are sensibly constrained as to the set of subordinate entities they 481 can certify (e.g., a CA for an organization can only certify entities 482 in that organization's name tree). Certificate user systems are able 483 to mechanically check that the name subordination rule has been 484 followed. 486 The RFC 1422 uses the X.509 v1 certificate formats. The limitations 487 of X.509 v1 required imposition of several structural restrictions to 488 clearly associate policy information or restrict the utility of 489 certificates. These restrictions included: 491 (a) a pure top-down hierarchy, with all certification paths 492 starting from IPRA; 494 (b) a naming subordination rule restricting the names of a CA's 495 subjects; and 497 (c) use of the PCA concept, which requires knowledge of individual 498 PCAs to be built into certificate chain verification logic. 499 Knowledge of individual PCAs was required to determine if a chain 500 could be accepted. 502 With X.509 v3, most of the requirements addressed by RFC 1422 can be 503 addressed using certificate extensions, without a need to restrict 504 the CA structures used. In particular, the certificate extensions 505 relating to certificate policies obviate the need for PCAs and the 506 constraint extensions obviate the need for the name subordination 507 rule. As a result, this document supports a more flexible 508 architecture, including: 510 (a) Certification paths may start with a public key of a CA in a 511 user's own domain, or with the public key of the top of a 512 hierarchy. Starting with the public key of a CA in a user's own 513 domain has certain advantages. In some environments, the local 514 domain is the most trusted. 516 (b) Name constraints may be imposed through explicit inclusion of 517 a name constraints extension in a certificate, but are not 518 required. 520 (c) Policy extensions and policy mappings replace the PCA 521 concept, which permits a greater degree of automation. The 522 application can determine if the certification path is acceptable 523 based on the contents of the certificates instead of a priori 524 knowledge of PCAs. This permits automation of certificate chain 525 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 communications and server systems. 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 the CA issues CRLs. 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 may be 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 may define a set of standard 654 message formats supporting the above functions in future 655 specifications. In that case, the protocols for conveying these 656 messages in different environments (e.g., on-line, file transfer, e- 657 mail, and WWW) will also be described in those specifications. 659 4 Certificate and Certificate Extensions Profile 661 This section presents a profile for public key certificates that will 662 foster interoperability and a reusable PKI. This section is based 663 upon the X.509 v3 certificate format and the standard certificate 664 extensions defined in [X.509]. The ISO/IEC/ITU documents use the 665 1993 version of ASN.1; while this document uses the 1988 ASN.1 666 syntax, the encoded certificate and standard extensions are 667 equivalent. This section also defines private extensions required to 668 support a PKI for the Internet community. 670 Certificates may be used in a wide range of applications and 671 environments covering a broad spectrum of interoperability goals and 672 a broader spectrum of operational and assurance requirements. The 673 goal of this document is to establish a common baseline for generic 674 applications requiring broad interoperability and limited special 675 purpose requirements. In particular, the emphasis will be on 676 supporting the use of X.509 v3 certificates for informal Internet 677 electronic mail, IPsec, and WWW applications. 679 4.1 Basic Certificate Fields 681 The X.509 v3 certificate basic syntax is as follows. For signature 682 calculation, the certificate is encoded using the ASN.1 distinguished 683 encoding rules (DER) [X.208]. ASN.1 DER encoding is a tag, length, 684 value encoding system for each element. 686 Certificate ::= SEQUENCE { 687 tbsCertificate TBSCertificate, 688 signatureAlgorithm AlgorithmIdentifier, 689 signatureValue BIT STRING } 691 TBSCertificate ::= SEQUENCE { 692 version [0] EXPLICIT Version DEFAULT v1, 693 serialNumber CertificateSerialNumber, 694 signature AlgorithmIdentifier, 695 issuer Name, 696 validity Validity, 697 subject Name, 698 subjectPublicKeyInfo SubjectPublicKeyInfo, 699 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 700 -- If present, version MUST be v2 or v3 701 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 702 -- If present, version MUST be v2 or v3 703 extensions [3] EXPLICIT Extensions OPTIONAL 704 -- If present, version MUST be v3 705 } 707 Version ::= INTEGER { v1(0), v2(1), v3(2) } 709 CertificateSerialNumber ::= INTEGER 711 Validity ::= SEQUENCE { 712 notBefore Time, 713 notAfter Time } 715 Time ::= CHOICE { 716 utcTime UTCTime, 717 generalTime GeneralizedTime } 719 UniqueIdentifier ::= BIT STRING 721 SubjectPublicKeyInfo ::= SEQUENCE { 722 algorithm AlgorithmIdentifier, 723 subjectPublicKey BIT STRING } 725 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 727 Extension ::= SEQUENCE { 728 extnID OBJECT IDENTIFIER, 729 critical BOOLEAN DEFAULT FALSE, 730 extnValue OCTET STRING } 732 The following items describe the X.509 v3 certificate for use in the 733 Internet. 735 4.1.1 Certificate Fields 737 The Certificate is a SEQUENCE of three required fields. The fields 738 are described in detail in the following subsections. 740 4.1.1.1 tbsCertificate 742 The field contains the names of the subject and issuer, a public key 743 associated with the subject, a validity period, and other associated 744 information. The fields are described in detail in section 4.1.2; 745 the tbscertificate may also include extensions which are described in 746 section 4.2. 748 4.1.1.2 signatureAlgorithm 750 The signatureAlgorithm field contains the identifier for the 751 cryptographic algorithm used by the CA to sign this certificate. 752 [PKIX ALGS] lists the supported signature algorithms. 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. [PKIX ALGS] 764 lists the supported algorithms for this specification. 766 This field MUST contain the same algorithm identifier as the 767 signature field in the sequence tbsCertificate (see sec. 4.1.2.3). 769 4.1.1.3 signatureValue 771 The signatureValue field contains a digital signature computed upon 772 the ASN.1 DER encoded tbsCertificate. The ASN.1 DER encoded 773 tbsCertificate is used as the input to the signature function. This 774 signature value is then ASN.1 encoded as a BIT STRING and included in 775 the Certificate's signature field. The details of this process are 776 specified for each of the supported algorithms in [PKIX ALGS]. 778 By generating this signature, a CA certifies the validity of the 779 information in the tbsCertificate field. In particular, the CA 780 certifies the binding between the public key material and the subject 781 of the certificate. 783 4.1.2 TBSCertificate 785 The sequence TBSCertificate contains information associated with the 786 subject of the certificate and the CA who issued it. Every 787 TBSCertificate contains the names of the subject and issuer, a public 788 key associated with the subject, a validity period, a version number, 789 and a serial number; some may contain optional unique identifier 790 fields. The remainder of this section describes the syntax and 791 semantics of these fields. A TBSCertificate may also include 792 extensions. Extensions for the Internet PKI are described in Section 793 4.2. 795 4.1.2.1 Version 797 This field describes the version of the encoded certificate. When 798 extensions are used, as expected in this profile, use X.509 version 3 799 (value is 2). If no extensions are present, but a UniqueIdentifier 800 is present, use version 2 (value is 1). If only basic fields are 801 present, use version 1 (the value is omitted from the certificate as 802 the default value). 804 Implementations SHOULD be prepared to accept any version certificate. 805 At a minimum, conforming implementations MUST recognize version 3 806 certificates. 808 Generation of version 2 certificates is not expected by 809 implementations based on this profile. 811 4.1.2.2 Serial number 813 The serial number MUST be a positive integer assigned by the CA to 814 each certificate. It MUST be unique for each certificate issued by a 815 given CA (i.e., the issuer name and serial number identify a unique 816 certificate). CAs MUST force the serialNumber to be a non-negative 817 integer. 819 Given the uniqueness requirements above serial numbers can be 820 expected to contain long integers. Certificate users MUST be able to 821 handle serialNumber values up to 20 octets. Conformant CAs MUST NOT 822 use serialNumber values longer than 20 octets. 824 Note: Non-conforming CAs may issue certificates with serial numbers 825 that are negative, or zero. Certificate users SHOULD be prepared to 826 handle such certificates. 828 4.1.2.3 Signature 830 This field contains the algorithm identifier for the algorithm used 831 by the CA to sign the certificate. 833 This field MUST contain the same algorithm identifier as the 834 signatureAlgorithm field in the sequence Certificate (see sec. 835 4.1.1.2). The contents of the optional parameters field will vary 836 according to the algorithm identified. [PKIX ALGS] lists the 837 supported signature algorithms. 839 4.1.2.4 Issuer 841 The issuer field identifies the entity who has signed and issued the 842 certificate. The issuer field MUST contain a non-empty distinguished 843 name (DN). The issuer field is defined as the X.501 type Name. 844 [X.501] Name is defined by the following ASN.1 structures: 846 Name ::= CHOICE { 847 RDNSequence } 849 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 851 RelativeDistinguishedName ::= 852 SET OF AttributeTypeAndValue 854 AttributeTypeAndValue ::= SEQUENCE { 855 type AttributeType, 856 value AttributeValue } 858 AttributeType ::= OBJECT IDENTIFIER 859 AttributeValue ::= ANY DEFINED BY AttributeType 861 DirectoryString ::= CHOICE { 862 teletexString TeletexString (SIZE (1..MAX)), 863 printableString PrintableString (SIZE (1..MAX)), 864 universalString UniversalString (SIZE (1..MAX)), 865 utf8String UTF8String (SIZE (1.. MAX)), 866 bmpString BMPString (SIZE (1..MAX)) } 868 The Name describes a hierarchical name composed of attributes, such 869 as country name, and corresponding values, such as US. The type of 870 the component AttributeValue is determined by the AttributeType; in 871 general it will be a DirectoryString. 873 The DirectoryString type is defined as a choice of PrintableString, 874 TeletexString, BMPString, UTF8String, and UniversalString. The 875 UTF8String encoding is the preferred encoding, and all certificates 876 issued after December 31, 2003 MUST use the UTF8String encoding of 877 DirectoryString (except as noted below). Until that date, conforming 878 CAs MUST choose from the following options when creating a 879 distinguished name, including their own: 881 (a) if the character set is sufficient, the string MAY be 882 represented as a PrintableString; 884 (b) failing (a), if the BMPString character set is sufficient the 885 string MAY be represented as a BMPString; and 887 (c) failing (a) and (b), the string MUST be represented as a 888 UTF8String. If (a) or (b) is satisfied, the CA MAY still choose 889 to represent the string as a UTF8String. 891 Exceptions to the December 31, 2003 UTF8 encoding requirements are as 892 follows: 894 (a) CAs MAY issue "name rollover" certificates to support an 895 orderly migration to UTF8String encoding. Such certificates would 896 include the CA's UTF8String encoded name as issuer and and the old 897 name encoding as subject, or vice-versa. 899 (b) As stated in section 4.1.2.6, the subject field MUST be 900 populated with a non-empty distinguished name matching the 901 contents of the issuer field in all certificates issued by the 902 subject CA regardless of encoding. 904 The TeletexString and UniversalString are included for backward 905 compatibility, and should not be used for certificates for new 906 subjects. However, these types may be used in certificates where the 907 name was previously established. Certificate users SHOULD be 908 prepared to receive certificates with these types. 910 In addition, many legacy implementations support names encoded in the 911 ISO 8859-1 character set (Latin1String) but tag them as 912 TeletexString. The Latin1String includes characters used in Western 913 European countries which are not part of the TeletexString charcter 914 set. Implementations that process TeletexString SHOULD be prepared 915 to handle the entire ISO 8859-1 character set.[ISO 8859-1] 917 As noted above, distinguished names are composed of attributes. This 918 specification does not restrict the set of attribute types that may 919 appear in names. However, conforming implementations MUST be 920 prepared to receive certificates with issuer names containing the set 921 of attribute types defined below. This specification also recommends 922 support for additional attribute types. 924 Standard sets of attributes have been defined in the X.500 series of 925 specifications.[X.520] Implementations of this specification MUST be 926 prepared to receive the following standard attribute types in issuer 927 and subject (see 4.1.2.6) names: 929 * country, 930 * organization, 931 * organizational-unit, 932 * distinguished name qualifier, 933 * state or province name, 934 * common name (e.g., "Susan Housley"), and 935 * serial number. 937 In addition, implementations of this specification SHOULD be prepared 938 to receive the following standard attribute types in issuer and 939 subject names: 941 * locality, 942 * title, 943 * surname, 944 * given name, 945 * initials, 946 * pseudonym, and 947 * generation qualifier (e.g., "Jr.", "3rd", or "IV"). 949 The syntax and associated object identifiers (OIDs) for these 950 attribute types are provided in the ASN.1 modules in Appendices A and 951 B. 953 In addition, implementations of this specification MUST be prepared 954 to receive the domainComponent attribute, as defined in [RFC 2247]. 955 The Domain (Nameserver) System (DNS) provides a hierarchical resource 956 labeling system. This attribute provides is a convenient mechanism 957 for organizations that wish to use DNs that parallel their DNS names. 958 This is not a replacement for the dNSName component of the 959 alternative name field. Implementations are not required to convert 960 such names into DNS names. The syntax and associated OID for this 961 attribute type is provided in the ASN.1 modules in Appendices A and 962 B. 964 Certificate users MUST be prepared to process the issuer 965 distinguished name and subject distinguished name (see sec. 4.1.2.6) 966 fields to perform name chaining for certification path validation 967 (see 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: the 1013 date on which the certificate validity period begins (notBefore) and 1014 the date on which the certificate validity period ends (notAfter). 1015 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 (see sec. 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. A 1073 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 (see sec. 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 Appendices A and B. 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 (see sec. 4.2.1.7) to describe such 1103 identities. Simultaneous inclusion of the EmailAddress attribute in 1104 the subject distinguished name to support legacy implementations is 1105 deprecated 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 [PKIX ALGS]. 1116 4.1.2.8 Unique Identifiers 1118 These fields may only appear if the version is 2 or 3 (see sec. 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 may only appear if the version is 3 (see sec. 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 may be designated as 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 may appear in a particular certificate. For example, a 1158 certificate may contain only one authority key identifier extension 1159 (see sec. 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 (see sec. 4.2.1.1 and 1164 4.2.1.2), basic constraints (see sec. 4.2.1.10), key usage (see sec. 1165 4.2.1.3), and certificate policies (see sec. 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 (see sec. 4.2.1.7). Support for the remaining extensions is 1169 OPTIONAL. Conforming CAs may support extensions that are not 1170 identified within this specification; certificate issuers are 1171 cautioned that marking such extensions as critical may inhibit 1172 interoperability. 1174 At a minimum, applications conforming to this profile MUST recognize 1175 the following extensions: key usage (see sec. 4.2.1.3), certificate 1176 policies (see sec. 4.2.1.5), the subject alternative name (see sec. 1177 4.2.1.7), basic constraints (see sec. 4.2.1.10), name constraints 1178 (see sec. 4.2.1.11), policy constraints (see sec. 4.2.1.12), extended 1179 key usage (see sec. 4.2.1.13), and inhibit any-policy (see sec. 1180 4.2.1.15). 1182 In addition, this profile RECOMMENDS application support for the 1183 authority and subject key identifier (see sec. 4.2.1.1 and 4.2.1.2), 1184 and policy mapping (see sec. 4.2.1.6) extensions. 1186 4.2.1 Standard Extensions 1188 This section identifies standard certificate extensions defined in 1189 [X.509] for use in the Internet PKI. Each extension is associated 1190 with an OID defined in [X.509]. These OIDs are members of the id-ce 1191 arc, which is defined by the following: 1193 id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 1195 4.2.1.1 Authority Key Identifier 1197 The authority key identifier extension provides a means of 1198 identifying the public key corresponding to the private key used to 1199 sign a certificate. This extension is used where an issuer has 1200 multiple signing keys (either due to multiple concurrent key pairs or 1201 due to changeover). The identification may be based on either the 1202 key identifier (the subject key identifier in the issuer's 1203 certificate) or on the issuer name and serial number. 1205 The keyIdentifier field of the authorityKeyIdentifier extension MUST 1206 be included in all certificates generated by conforming CAs to 1207 facilitate chain building. There is one exception; where a CA 1208 distributes its public key in the form of a "self-signed" 1209 certificate, the authority key identifier may be omitted. In this 1210 case, the subject and authority key identifiers would be identical. 1212 The value of the keyIdentifier field SHOULD be derived from the 1213 public key used to verify the certificate's signature or a method 1214 that generates unique values. Two common methods for generating key 1215 identifiers from the public key are described in (sec. 4.2.1.2). One 1216 common method for generating unique values is described in (sec. 1217 4.2.1.2). Where a key identifier has not been previously 1218 established, this specification recommends use of one of these 1219 methods for generating keyIdentifiers. 1221 This profile recommends support for the key identifier method by all 1222 certificate users. 1224 This extension MUST NOT be marked critical. 1226 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 1228 AuthorityKeyIdentifier ::= SEQUENCE { 1229 keyIdentifier [0] KeyIdentifier OPTIONAL, 1230 authorityCertIssuer [1] GeneralNames OPTIONAL, 1231 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 1233 KeyIdentifier ::= OCTET STRING 1235 4.2.1.2 Subject Key Identifier 1237 The subject key identifier extension provides a means of identifying 1238 certificates that contain a particular public key. 1240 To facilitate chain building, this extension MUST appear in all con- 1241 forming CA certificates, that is, all certificates including the 1242 basic constraints extension (see sec. 4.2.1.10) where the value of cA 1243 is TRUE. The value of the subject key identifier MUST be the value 1244 placed in the key identifier field of the Authority Key Identifier 1245 extension (see sec. 4.2.1.1) of certificates issued by the subject of 1246 this certificate. 1248 For CA certificates, subject key identifiers SHOULD be derived from 1249 the public key or a method that generates unique values. The key 1250 identifier is an explicit value placed in the certificate by the 1251 issuer, not a value generated by a certificate user. Two common 1252 methods for generating key identifiers from the public key are: 1254 (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the 1255 value of the BIT STRING subjectPublicKey (excluding the tag, 1256 length, and number of unused bits). 1258 (2) The keyIdentifier is composed of a four bit type field with 1259 the value 0100 followed by the least significant 60 bits of the 1260 SHA-1 hash of the value of the BIT STRING subjectPublicKey. 1262 One common method for generating unique values is a monotonically 1263 increasing sequence of integers. 1265 For end entity certificates, the subject key identifier extension 1266 provides a means for identifying certificates containing the 1267 particular public key used in an application. Where an end entity has 1268 obtained multiple certificates, especially from multiple CAs, the 1269 subject key identifier provides a means to quickly identify the set 1270 of certificates containing a particular public key. To assist 1271 applications in identifying the appropriate end entity certificate, 1272 this extension SHOULD be included in all end entity certificates. 1274 For end entity certificates, subject key identifiers SHOULD be 1275 derived from the public key. Two common methods for generating key 1276 identifiers from the public key are identifed above. 1278 Where a key identifier has not been previously established, this 1279 specification recommends use of one of these methods for generating 1280 keyIdentifiers. 1282 This extension MUST NOT be marked critical. 1284 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 1286 SubjectKeyIdentifier ::= KeyIdentifier 1288 4.2.1.3 Key Usage 1290 The key usage extension defines the purpose (e.g., encipherment, 1291 signature, certificate signing) of the key contained in the 1292 certificate. The usage restriction might be employed when a key that 1293 could be used for more than one operation is to be restricted. For 1294 example, when an RSA key should be used only for signing, 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. When used, this extension 1298 SHOULD be marked critical. 1300 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 1302 KeyUsage ::= BIT STRING { 1303 digitalSignature (0), 1304 nonRepudiation (1), 1305 keyEncipherment (2), 1306 dataEncipherment (3), 1307 keyAgreement (4), 1308 keyCertSign (5), 1309 cRLSign (6), 1310 encipherOnly (7), 1311 decipherOnly (8) } 1313 Bits in the KeyUsage type are used as follows: 1315 The digitalSignature bit is asserted when the subject public key 1316 is used with a digital signature mechanism to support security 1317 services other than non-repudiation (bit 1), certificate signing 1318 (bit 5), or revocation information signing (bit 6). Digital 1319 signature mechanisms are often used for entity authentication and 1320 data origin authentication with integrity. 1322 The nonRepudiation bit is asserted when the subject public key is 1323 used to verify digital signatures used to provide a non- 1324 repudiation service which protects against the signing entity 1325 falsely denying some action, excluding certificate or CRL signing. 1326 In the case of later conflict, a reliable third party may 1327 determine the authenticity of the signed data. 1329 Further distinctions between the digitalSignature and 1330 nonRepudiation bits may be provided in specific certificate 1331 policies. 1333 The keyEncipherment bit is asserted when the subject public key is 1334 used for key transport. For example, when an RSA key is to be 1335 used for key management, then this bit is set. 1337 The dataEncipherment bit is asserted when the subject public key 1338 is used for enciphering user data, other than cryptographic keys. 1340 The keyAgreement bit is asserted when the subject public key is 1341 used for key agreement. For example, when a Diffie-Hellman key is 1342 to be used for key management, then this bit is set. 1344 The keyCertSign bit is asserted when the subject public key is 1345 used for verifying a signature on certificates. This bit may only 1346 be asserted in CA certificates. If the keyCertSign bit is 1347 asserted, then the cA bit in the basic constraints extension (see 1348 4.2.1.10) MUST also be asserted. If neither the cRLSign bit nor 1349 the keyCertSign bit are asserted, then the cA bit in the basic 1350 constraints extension MUST NOT be asserted. 1352 The cRLSign bit is asserted when the subject public key is used 1353 for verifying a signature on revocation information (e.g., a CRL). 1354 This bit may only be asserted in CA certificates. If the cRLSign 1355 bit is asserted, then the cA bit in the basic constraints 1356 extension (see 4.2.1.10) MUST also be asserted. If neither the 1357 cRLSign bit nor the keyCertSign bit are asserted, then the cA bit 1358 in the basic constraints extension MUST NOT be asserted. 1360 The meaning of the encipherOnly bit is undefined in the absence of 1361 the keyAgreement bit. When the encipherOnly bit is asserted and 1362 the keyAgreement bit is also set, the subject public key may be 1363 used only for enciphering data while performing key agreement. 1365 The meaning of the decipherOnly bit is undefined in the absence of 1366 the keyAgreement bit. When the decipherOnly bit is asserted and 1367 the keyAgreement bit is also set, the subject public key may be 1368 used only for deciphering data while performing key agreement. 1370 This profile does not restrict the combinations of bits that may be 1371 set in An instantiation of the keyUsage extension. However, 1372 appropriate values for keyUsage extensions for particular algorithms 1373 are specified in [PKIX ALGS]. 1375 4.2.1.4 Private Key Usage Period 1377 This profile RECOMMENDS against the use of this extension. CAs 1378 conforming to this profile MUST NOT generate certificates with 1379 critical private key usage period extensions. 1381 The private key usage period extension allows the certificate issuer 1382 to specify a different validity period for the private key than the 1383 certificate. This extension is intended for use with digital 1384 signature keys. This extension consists of two optional components, 1385 notBefore and notAfter. The private key associated with the 1386 certificate should not be used to sign objects before or after the 1387 times specified by the two components, respectively. CAs conforming 1388 to this profile MUST NOT generate certificates with private key usage 1389 period extensions unless at least one of the two components is 1390 present. 1392 Where used, notBefore and notAfter are represented as GeneralizedTime 1393 and MUST be specified and interpreted as defined in section 1394 4.1.2.5.2. 1396 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 1398 PrivateKeyUsagePeriod ::= SEQUENCE { 1399 notBefore [0] GeneralizedTime OPTIONAL, 1400 notAfter [1] GeneralizedTime OPTIONAL } 1402 4.2.1.5 Certificate Policies 1404 The certificate policies extension contains a sequence of one or more 1405 policy information terms, each of which consists of an object 1406 identifier (OID) and optional qualifiers. Optional qualifiers, which 1407 may be present, are not expected to change the definition of the 1408 policy. 1410 In an end-entity certificate, these policy information terms indicate 1411 the policy under which the certificate has been issued and the 1412 purposes for which the certificate may be used. In a CA certificate, 1413 these policy information terms limit the set of policies for 1414 certification paths which include this certificate. When a CA does 1415 not wish to limit the set of policies for certification paths which 1416 include this certificate, they may assert the special policy 1417 anyPolicy, with a value of {2 5 29 32 0}. 1419 Applications with specific policy requirements are expected to have a 1420 list of those policies which they will accept and to compare the 1421 policy OIDs in the certificate to that list. If this extension is 1422 critical, the path validation software MUST be able to interpret this 1423 extension (including the optional qualifier), or MUST reject the 1424 certificate. 1426 To promote interoperability, this profile RECOMMENDS that policy 1427 information terms consist of only an OID. Where an OID alone is 1428 insufficient, this profile strongly recommends that use of qualifiers 1429 be limited to those identified in this section. When qualifiers are 1430 used with the special policy anyPolicy, they MUST be limited to the 1431 qualifers identified in this section. 1433 This specification defines two policy qualifier types for use by 1434 certificate policy writers and certificate issuers. The qualifier 1435 types are the CPS Pointer and User Notice qualifiers. 1437 The CPS Pointer qualifier contains a pointer to a Certification 1438 Practice Statement (CPS) published by the CA. The pointer is in the 1439 form of a URI. Processing requirements for this qualifier are a 1440 local matter. No action is mandated by this specification regardless 1441 of the criticality value asserted for the extension. 1443 User notice is intended for display to a relying party when a 1444 certificate is used. The application software SHOULD display all 1445 user notices in all certificates of the certification path used, 1446 except that if a notice is duplicated only one copy need be 1447 displayed. To prevent such duplication, this qualifier SHOULD only 1448 be present in end-entity certificates and CA certificates issued to 1449 other organizations. 1451 The user notice has two optional fields: the noticeRef field and the 1452 explicitText field. 1454 The noticeRef field, if used, names an organization and 1455 identifies, by number, a particular textual statement prepared by 1456 that organization. For example, it might identify the 1457 organization "CertsRUs" and notice number 1. In a typical 1458 implementation, the application software will have a notice file 1459 containing the current set of notices for CertsRUs; the 1460 application will extract the notice text from the file and display 1461 it. Messages may be multilingual, allowing the software to select 1462 the particular language message for its own environment. 1464 An explicitText field includes the textual statement directly in 1465 the certificate. The explicitText field is a string with a 1466 maximum size of 200 characters. 1468 If both the noticeRef and explicitText options are included in the 1469 one qualifier and if the application software can locate the notice 1470 text indicated by the noticeRef option then that text should be 1471 displayed; otherwise, the explicitText string should be displayed. 1473 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 1475 anyPolicy OBJECT IDENTIFIER ::= {id-ce-certificate-policies 0} 1477 certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 1478 PolicyInformation ::= SEQUENCE { 1479 policyIdentifier CertPolicyId, 1480 policyQualifiers SEQUENCE SIZE (1..MAX) OF 1481 PolicyQualifierInfo OPTIONAL } 1483 CertPolicyId ::= OBJECT IDENTIFIER 1485 PolicyQualifierInfo ::= SEQUENCE { 1486 policyQualifierId PolicyQualifierId, 1487 qualifier ANY DEFINED BY policyQualifierId } 1489 -- policyQualifierIds for Internet policy qualifiers 1491 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 1492 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 1493 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 1495 PolicyQualifierId ::= 1496 OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) 1498 Qualifier ::= CHOICE { 1499 cPSuri CPSuri, 1500 userNotice UserNotice } 1502 CPSuri ::= IA5String 1504 UserNotice ::= SEQUENCE { 1505 noticeRef NoticeReference OPTIONAL, 1506 explicitText DisplayText OPTIONAL} 1508 NoticeReference ::= SEQUENCE { 1509 organization DisplayText, 1510 noticeNumbers SEQUENCE OF INTEGER } 1512 DisplayText ::= CHOICE { 1513 ia5String IA5String (SIZE (1..200)), 1514 visibleString VisibleString (SIZE (1..200)), 1515 bmpString BMPString (SIZE (1..200)), 1516 utf8String UTF8String (SIZE (1..200)) } 1518 4.2.1.6 Policy Mappings 1520 This extension is used in CA certificates. It lists one or more 1521 pairs of OIDs; each pair includes an issuerDomainPolicy and a 1522 subjectDomainPolicy. The pairing indicates the issuing CA considers 1523 its issuerDomainPolicy equivalent to the subject CA's 1524 subjectDomainPolicy. 1526 The issuing CA's users may accept an issuerDomainPolicy for certain 1527 applications. The policy mapping tells the issuing CA's users which 1528 policies associated with the subject CA are comparable to the policy 1529 they accept. 1531 Each issuerDomainPolicy named in the the policy mapping extension 1532 should also be asserted in a certificate policies extension in the 1533 same certificate. Policies should not be mapped either to or from 1534 the special value anyPolicy. (See 4.2.1.5 certificate policies). 1536 This extension may be supported by CAs and/or applications, and it 1537 MUST be non-critical. 1539 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 1541 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 1542 issuerDomainPolicy CertPolicyId, 1543 subjectDomainPolicy CertPolicyId } 1545 4.2.1.7 Subject Alternative Name 1547 The subject alternative names extension allows additional identities 1548 to be bound to the subject of the certificate. Defined options 1549 include an Internet electronic mail address, a DNS name, an IP 1550 address, and a uniform resource identifier (URI). Other options 1551 exist, including completely local definitions. Multiple name forms, 1552 and multiple instances of each name form, may be included. Whenever 1553 such identities are to be bound into a certificate, the subject 1554 alternative name (or issuer alternative name) extension MUST be used. 1556 Because the subject alternative name is considered to be definitively 1557 bound to the public key, all parts of the subject alternative name 1558 MUST be verified by the CA. 1560 Further, if the only subject identity included in the certificate is 1561 an alternative name form (e.g., an electronic mail address), then the 1562 subject distinguished name MUST be empty (an empty sequence), and the 1563 subjectAltName extension MUST be present. If the subject field 1564 contains an empty sequence, the subjectAltName extension MUST be 1565 marked critical. 1567 When the subjectAltName extension contains an Internet mail address, 1568 the address MUST be included as an rfc822Name. The format of an 1569 rfc822Name is an "addr-spec" as defined in RFC 822 [RFC 822]. An 1570 addr-spec has the form "local-part@domain". Note that an addr-spec 1571 has no phrase (such as a common name) before it, has no comment (text 1572 surrounded in parentheses) after it, and is not surrounded by "<" and 1573 ">". Note that while upper and lower case letters are allowed in an 1574 RFC 822 addr-spec, no significance is attached to the case. 1576 When the subjectAltName extension contains a iPAddress, the address 1577 MUST be stored in the octet string in "network byte order," as 1578 specified in RFC 791 [RFC 791]. The least significant bit (LSB) of 1579 each octet is the LSB of the corresponding byte in the network 1580 address. For IP Version 4, as specified in RFC 791, the octet string 1581 MUST contain exactly four octets. For IP Version 6, as specified in 1582 RFC 1883, the octet string MUST contain exactly sixteen octets [RFC 1583 1883]. 1585 When the subjectAltName extension contains a domain name service 1586 label, the domain name MUST be stored in the dNSName (an IA5String). 1587 The name MUST be in the "preferred name syntax," as specified by RFC 1588 1034 [RFC 1034]. Note that while upper and lower case letters are 1589 allowed in domain names, no signifigance is attached to the case. In 1590 addition, while the string " " is a legal domain name, subjectAltName 1591 extensions with a dNSName " " are not permitted. Finally, the use of 1592 the DNS representation for Internet mail addresses (wpolk.nist.gov 1593 instead of wpolk@nist.gov) MUST NOT be used; such identities are to 1594 be encoded as rfc822Name. 1596 Note: work is currently underway to specify domain names in 1597 international character sets. This names will likely not be 1598 accomodated by IA5String. Once this work is complete, this profile 1599 will be revisited and the appropriate functionality will be added. 1601 When the subjectAltName extension contains a URI, the name MUST be 1602 stored in the uniformResourceIdentifier (an IA5String). The name MUST 1603 be a non-relative URL, and MUST follow the URL syntax and encoding 1604 rules specified in [RFC 1738]. The name must include both a scheme 1605 (e.g., "http" or "ftp") and a scheme-specific-part. The scheme- 1606 specific-part must include a fully qualified domain name or IP 1607 address as the host. 1609 As specified in [RFC 1738], the scheme name is not case-sensitive 1610 (e.g., "http" is equivalent to "HTTP"). The host part is also not 1611 case-sensitive, but other components of the scheme-specific-part may 1612 be case-sensitive. When comparing URIs, conforming implementations 1613 MUST compare the scheme and host without regard to case, but assume 1614 the remainder of the scheme-specific-part is case sensitive. 1616 When the subjectAltName extension contains a DN in the directoryName, 1617 the DN MUST be unique for each subject entity certified by the one CA 1618 as defined by the issuer name field. A CA may issue more than one 1619 certificate with the same DN to the same subject entity. 1621 The subjectAltName may carry additional name types through the use of 1622 the otherName field. The format and semantics of the name are 1623 indicated through the OBJECT IDENTIFIER in the type-id field. The 1624 name itself is conveyed as value field in otherName. For example, 1625 Kerberos [RFC 1510] format names can be encoded into the otherName, 1626 using the krb5PrincipalName OID and the KerberosName syntax as 1627 defined in [PKINIT]. 1629 Subject alternative names may be constrained in the same manner as 1630 subject distinguished names using the name constraints extension as 1631 described in section 4.2.1.11. 1633 If the subjectAltName extension is present, the sequence MUST contain 1634 at least one entry. Unlike the subject field, conforming CAs MUST 1635 NOT issue certificates with subjectAltNames containing empty 1636 GeneralName fields. For example, an rfc822Name is represented as an 1637 IA5String. While an empty string is a valid IA5String, such an 1638 rfc822Name is not permitted by this profile. The behavior of clients 1639 that encounter such a certificate when processing a certificication 1640 path is not defined by this profile. 1642 Finally, the semantics of subject alternative names that include 1643 wildcard characters (e.g., as a placeholder for a set of names) are 1644 not addressed by this specification. Applications with specific 1645 requirements may use such names but MUST define the semantics. 1647 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 1649 SubjectAltName ::= GeneralNames 1651 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 1653 GeneralName ::= CHOICE { 1654 otherName [0] OtherName, 1655 rfc822Name [1] IA5String, 1656 dNSName [2] IA5String, 1657 x400Address [3] ORAddress, 1658 directoryName [4] Name, 1659 ediPartyName [5] EDIPartyName, 1660 uniformResourceIdentifier [6] IA5String, 1661 iPAddress [7] OCTET STRING, 1662 registeredID [8] OBJECT IDENTIFIER} 1664 OtherName ::= SEQUENCE { 1665 type-id OBJECT IDENTIFIER, 1666 value [0] EXPLICIT ANY DEFINED BY type-id } 1668 EDIPartyName ::= SEQUENCE { 1669 nameAssigner [0] DirectoryString OPTIONAL, 1670 partyName [1] DirectoryString } 1672 4.2.1.8 Issuer Alternative Names 1674 As with 4.2.1.7, this extension is used to associate Internet style 1675 identities with the certificate issuer. Issuer alternative names MUST 1676 be encoded as in 4.2.1.7. 1678 Where present, this extension SHOULD NOT be marked critical. 1680 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 1682 IssuerAltName ::= GeneralNames 1684 4.2.1.9 Subject Directory Attributes 1686 The subject directory attributes extension is used to convey 1687 identification attributes (e.g.,nationality) of the subject. The 1688 extension is defined as a sequence of one or more attributes. This 1689 extension MUST be non-critical. 1691 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 1693 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 1695 4.2.1.10 Basic Constraints 1697 The basic constraints extension identifies whether the subject of the 1698 certificate is a CA and how deep a certification path may exist 1699 through that CA. 1701 The cA bit indicates if the certified public key may be used to 1702 verify signatures on other certificates. If the cA bit is asserted, 1703 then either the keyCertSign bit or the cRLSign bit in the key usage 1704 extension (see 4.2.1.3) MUST also be asserted. If the cA bit is not 1705 asserted, then both the keyCertSign bit and the cRLSign in the key 1706 usage extension MUST NOT be asserted. 1708 The pathLenConstraint field is meaningful only if cA is set to TRUE. 1709 In this case, it gives the maximum number of CA certificates that may 1710 follow this certificate in a certification path. (Note: The last 1711 certificate in the certification path is not included in this limit. 1712 Usually, the last certificate is an end-entity certificate, but it 1713 can be a CA certificate.) A pathLenConstraint of zero indicates that 1714 only one more certificate may follow in the certification path. 1715 Where it appears, the pathLenConstraint field MUST be greater than or 1716 equal to zero. Where pathLenConstraint does not appear, there is no 1717 limit to the allowed length of the certification path. 1719 This extension MUST appear as a critical extension in all CA 1720 certificates. This extension MAY appear as a critical or non- 1721 critical extension in end entity certificates. 1723 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 1725 BasicConstraints ::= SEQUENCE { 1726 cA BOOLEAN DEFAULT FALSE, 1727 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 1729 4.2.1.11 Name Constraints 1731 The name constraints extension, which MUST be used only in a CA 1732 certificate, indicates a name space within which all subject names in 1733 subsequent certificates in a certification path MUST be located. 1734 Restrictions apply to the subject distinguished name and apply to 1735 subject alternative names. Restrictions apply only when the 1736 specified name form is present. If no name of the type is in the 1737 certificate, the certificate is acceptable. 1739 Name constraints are not applied to certificates whose issuer and 1740 subject are identical. (This could prevent CAs that use name 1741 constraints from issuing self-signed certificates to implement key 1742 rollover.) 1744 Restrictions are defined in terms of permitted or excluded name 1745 subtrees. Any name matching a restriction in the excludedSubtrees 1746 field is invalid regardless of information appearing in the 1747 permittedSubtrees. This extension MUST be critical. 1749 Within this profile, the minimum and maximum fields are not used with 1750 any name forms, thus minimum is always zero, and maximum is always 1751 absent. 1753 For URIs, the constraint applies to the host part of the name. The 1754 constraint may specify a host or a domain. Examples would be 1755 "foo.bar.com"; and ".xyz.com". When the the constraint begins with 1756 a period, it may be expanded with one or more subdomains. That is, 1757 the constraint ".xyz.com" is satisfied by both abc.xyz.com and 1758 abc.def.xyz.com. However, the constraint ".xyz.com" is not satisfied 1759 by "xyz.com". When the constraint does not begin with a period, it 1760 specifies a host. 1762 A name constraint for Internet mail addresses may specify a 1763 particular mailbox, all addresses at a particular host, or all 1764 mailboxes in a domain. To indicate a particular mailbox, the 1765 constraint is the complete mail address. For example, "root@xyz.com" 1766 indicates the root mailbox on the host "xyz.com". To indicate all 1767 Internet mail addresses on a particular host, the constraint is 1768 specified as the host name. For example, the constraint "xyz.com" is 1769 satisfied by any mail address at the host "xyz.com". To specify any 1770 address within a domain, the constraint is specified with a leading 1771 period (as with URIs). For example, ".xyz.com" indicates all the 1772 Internet mail addresses in the domain "xyz.com", but not Internet 1773 mail addresses on the host "xyz.com". 1775 DNS name restrictions are expressed as foo.bar.com. Any DNS name that 1776 can be constructed by simply adding to the left hand side of the name 1777 satisfies the name constraint. For example, www.foo.bar.com would 1778 satisfy the constraint but foo1.bar.com would not. 1780 Legacy implementations exist where an RFC 822 name is embedded in the 1781 subject distinguished name in an attribute of type EmailAddress (see 1782 sec. 4.1.2.6). When rfc822 names are constrained, but the certificate 1783 does not include a subject alternative name, the rfc822 name 1784 constraint MUST be applied to the attribute of type EmailAddress in 1785 the subject distinguished name. The ASN.1 syntax for EmailAddress 1786 and the corresponding OID are supplied in Appendix A and B. 1788 Restrictions of the form directoryName MUST be applied to the subject 1789 field in the certificate and to the subjectAltName extensions of type 1790 directoryName. Restrictions of the form x400Address MUST be applied 1791 to subjectAltName extensions of type x400Address. 1793 When applying restrictions of the form directoryName, an 1794 implementation MUST compare DN attributes. At a minimum, 1795 implementations MUST perform the DN comparison rules specified in 1796 Section 4.1.2.4. CAs issuing certificates with a restriction of the 1797 form directoryName SHOULD NOT rely on implementation of the full ISO 1798 DN name comparison algorithm. This implies name restrictions MUST be 1799 stated identically to the encoding used in the subject field or 1800 subjectAltName extension. 1802 The syntax of iPAddress MUST be as described in section 4.2.1.7 with 1803 the following additions specifically for Name Constraints. For IPv4 1804 addresses, the ipAddress field of generalName MUST contain eight (8) 1805 octets, encoded in the style of RFC 1519 (CIDR) to represent an 1806 address range.[RFC 1519] For IPv6 addresses, the ipAddress field 1807 MUST contain 32 octets similarly encoded. For example, a name 1808 constraint for "class C" subnet 10.9.8.0 is represented as the octets 1809 0A 09 08 00 FF FF FF 00, representing the CIDR notation 1810 10.9.8.0/255.255.255.0. 1812 The syntax and semantics for name constraints for otherName, 1813 ediPartyName, and registeredID are not defined by this specification. 1815 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 1817 NameConstraints ::= SEQUENCE { 1818 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 1819 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 1821 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 1823 GeneralSubtree ::= SEQUENCE { 1824 base GeneralName, 1825 minimum [0] BaseDistance DEFAULT 0, 1826 maximum [1] BaseDistance OPTIONAL } 1828 BaseDistance ::= INTEGER (0..MAX) 1830 4.2.1.12 Policy Constraints 1832 The policy constraints extension can be used in certificates issued 1833 to CAs. The policy constraints extension constrains path validation 1834 in two ways. It can be used to prohibit policy mapping or require 1835 that each certificate in a path contain an acceptable policy 1836 identifier. 1838 If the inhibitPolicyMapping field is present, the value indicates the 1839 number of additional certificates that may appear in the path before 1840 policy mapping is no longer permitted. For example, a value of one 1841 indicates that policy mapping may be processed in certificates issued 1842 by the subject of this certificate, but not in additional 1843 certificates in the path. 1845 If the requireExplicitPolicy field is present, subsequent 1846 certificates MUST include an acceptable policy identifier. The value 1847 of requireExplicitPolicy indicates the number of additional 1848 certificates that may appear in the path before an explicit policy is 1849 required. An acceptable policy identifier is the identifier of a 1850 policy required by the user of the certification path or the 1851 identifier of a policy which has been declared equivalent through 1852 policy mapping. 1854 Conforming CAs MUST NOT issue certificates where policy constraints 1855 is a null sequence. That is, at least one of the inhibitPolicyMapping 1856 field or the requireExplicitPolicy field MUST be present. The 1857 behavior of clients that encounter a null policy constraints field is 1858 not addressed in this profile. 1860 This extension may be critical or non-critical. 1862 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } 1864 PolicyConstraints ::= SEQUENCE { 1865 requireExplicitPolicy [0] SkipCerts OPTIONAL, 1866 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 1868 SkipCerts ::= INTEGER (0..MAX) 1870 4.2.1.13 Extended key usage field 1872 This field indicates one or more purposes for which the certified 1873 public key may be used, in addition to or in place of the basic 1874 purposes indicated in the key usage extension field. In general, 1875 this extension will appear only in end entity certificates. This 1876 field is defined as follows: 1878 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 1880 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 1882 KeyPurposeId ::= OBJECT IDENTIFIER 1884 Key purposes may be defined by any organization with a need. Object 1885 identifiers used to identify key purposes MUST be assigned in 1886 accordance with IANA or ITU-T Rec. X.660 | ISO/IEC/ITU 9834-1. 1888 This extension may, at the option of the certificate issuer, be 1889 either critical or non-critical. 1891 If the extension is flagged critical, then the certificate MUST only 1892 be used for one of the purposes indicated. If multiple purposes are 1893 indicated the application need not recognize all purposes indicated, 1894 as long as the intended purpose is present and recognized. 1896 If the extension is flagged non-critical, then it indicates the 1897 intended purpose or purposes of the key, and may be used in finding 1898 the correct key/certificate of an entity that has multiple 1899 keys/certificates. It is an advisory field and does not imply that 1900 usage of the key is restricted by the certification authority to the 1901 purpose indicated. Certificate using applications may nevertheless 1902 require that a particular purpose be indicated in order for the 1903 certificate to be acceptable to that application. 1905 If a certificate contains both a critical key usage field and a 1906 critical extended key usage field, then both fields MUST be processed 1907 independently and the certificate MUST only be used for a purpose 1908 consistent with both fields. If there is no purpose consistent with 1909 both fields, then the certificate MUST NOT be used for any purpose. 1911 The following key usage purposes are defined by this profile: 1913 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 1915 id-kp-serverAuth OBJECT IDENTIFIER ::= {id-kp 1} 1916 -- TLS Web server authentication 1917 -- Key usage bits that may be consistent: digitalSignature, 1918 -- keyEncipherment or keyAgreement 1919 -- 1920 id-kp-clientAuth OBJECT IDENTIFIER ::= {id-kp 2} 1921 -- TLS Web client authentication 1922 -- Key usage bits that may be consistent: digitalSignature and/or 1923 -- keyAgreement 1924 -- 1925 id-kp-codeSigning OBJECT IDENTIFIER ::= {id-kp 3} 1926 -- Signing of downloadable executable code 1927 -- Key usage bits that may be consistent: digitalSignature 1928 -- 1929 id-kp-emailProtection OBJECT IDENTIFIER ::= {id-kp 4} 1930 -- E-mail protection 1931 -- Key usage bits that may be consistent: digitalSignature, 1932 -- nonRepudiation, and/or (keyEncipherment 1933 -- or keyAgreement) 1934 -- 1935 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 1936 -- Binding the hash of an object to a time from an agreed-upon time 1937 -- source. Key usage bits that may be consistent: digitalSignature, 1938 -- nonRepudiation 1940 4.2.1.14 CRL Distribution Points 1942 The CRL distribution points extension identifies how CRL information 1943 is obtained. The extension SHOULD be non-critical, but this profile 1944 RECOMMENDS support for this extension by CAs and applications. 1945 Further discussion of CRL management is contained in section 5. 1947 The cRLDistributionPoints extension is a SEQUENCE of 1948 DistributionPoint. A DistributionPoint consists of three fields, 1949 each of which is optional: the name of the DistributionPoint, 1950 ReasonsFlags, and the cRLIssuer. While each component is optional, a 1951 DistributionPoint MUST NOT consist of only the ReasonsFlags field. 1952 If the distributionPoint omits cRLIssuer, the CRL MUST be issued by 1953 the CA that issued the certificate. If the distributionPointName is 1954 absent, cRLIssuer MUST be present and include a Name corresponding to 1955 an X.500 or LDAP directory entry where the CRL is located. 1957 If the cRLDistributionPoints extension contains a 1958 DistributionPointName of type URI, the following semantics MUST be 1959 assumed: the URI is a pointer to the current CRL for the associated 1960 reasons and will be issued by the associated cRLIssuer. The expected 1961 values for the URI are those defined in 4.2.1.7. Processing rules for 1962 other values are not defined by this specification. If the 1963 distributionPoint omits reasons, the CRL MUST include revocations for 1964 all reasons. 1966 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 } 1968 CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 1970 DistributionPoint ::= SEQUENCE { 1971 distributionPoint [0] DistributionPointName OPTIONAL, 1972 reasons [1] ReasonFlags OPTIONAL, 1973 cRLIssuer [2] GeneralNames OPTIONAL } 1975 DistributionPointName ::= CHOICE { 1976 fullName [0] GeneralNames, 1977 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 1979 ReasonFlags ::= BIT STRING { 1980 unused (0), 1981 keyCompromise (1), 1982 cACompromise (2), 1983 affiliationChanged (3), 1984 superseded (4), 1985 cessationOfOperation (5), 1986 certificateHold (6) } 1988 4.2.1.15 Inhibit Any-Policy 1990 The inhibit any-policy extension can be used in certificates issued 1991 to CAs. The inhibit any-policy indicates that the special any-policy 1992 OID, with the value {2 5 29 32 0}, is not considered an explicit 1993 match for other certificate policies. The value indicates the number 1994 of additional certificates that may appear in the path before any- 1995 policy is no longer permitted. For example, a value of one indicates 1996 that any-policy may be processed in certificates issued by the 1997 subject of this certificate, but not in additional certificates in 1998 the path. 2000 This extension MUST be critical. 2002 id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 } 2004 InhibitAnyPolicy ::= SkipCerts 2006 SkipCerts ::= INTEGER (0..MAX) 2008 4.2.1.16 Freshest CRL (a.k.a. Delta CRL Distribution Point) 2010 The freshest CRL extension identifies how delta-CRL information is 2011 obtained. The extension MUST be non-critical. Further discussion of 2012 CRL management is contained in section 5. 2014 The same syntax is used for this extension and the 2015 cRLDistributionPoints extension, and is described in section 2016 4.2.1.14. The same conventions apply to both extensions. 2018 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } 2020 FreshestCRL ::= CRLDistributionPoints 2022 4.2.2 Private Internet Extensions 2024 This section defines one new extension for use in the Internet Public 2025 Key Infrastructure. This extension may be used to direct 2026 applications to identify an on-line validation service supporting the 2027 issuing CA. As the information may be available in multiple forms, 2028 each extension is a sequence of IA5String values, each of which 2029 represents a URI. The URI implicitly specifies the location and 2030 format of the information and the method for obtaining the 2031 information. 2033 An object identifier is defined for the private extension. The 2034 object identifier associated with the private extension is defined 2035 under the arc id-pe within the id-pkix name space. Any future 2036 extensions defined for the Internet PKI will also be defined under 2037 the arc id-pe. 2039 id-pkix OBJECT IDENTIFIER ::= 2040 { iso(1) identified-organization(3) dod(6) internet(1) 2041 security(5) mechanisms(5) pkix(7) } 2043 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 2045 4.2.2.1 Authority Information Access 2047 The authority information access extension indicates how to access CA 2048 information and services for the issuer of the certificate in which 2049 the extension appears. Information and services may include on-line 2050 validation services and CA policy data. (The location of CRLs is not 2051 specified in this extension; that information is provided by the 2052 cRLDistributionPoints extension.) This extension may be included in 2053 subject or CA certificates, and it MUST be non-critical. 2055 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 2056 AuthorityInfoAccessSyntax ::= 2057 SEQUENCE SIZE (1..MAX) OF AccessDescription 2059 AccessDescription ::= SEQUENCE { 2060 accessMethod OBJECT IDENTIFIER, 2061 accessLocation GeneralName } 2063 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 2065 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 2067 Each entry in the sequence AuthorityInfoAccessSyntax describes the 2068 format and location of additional information provided by the CA who 2069 issued the certificate in which this extension appears. The type and 2070 format of the information is specified by the accessMethod field; the 2071 accessLocation field specifies the location of the information. The 2072 retrieval mechanism may be implied by the accessMethod or specified 2073 by accessLocation. 2075 This profile defines one OID for accessMethod. The id-ad-caIssuers 2076 OID is used when the additional information lists CAs that have 2077 issued certificates superior to the CA that issued the certificate 2078 containing this extension. The referenced CA Issuers description is 2079 intended to aid certificate users in the selection of a certification 2080 path that terminates at a point trusted by the certificate user. 2082 When id-ad-caIssuers appears as accessInfoType, the accessLocation 2083 field describes the referenced description server and the access 2084 protocol to obtain the referenced description. The accessLocation 2085 field is defined as a GeneralName, which can take several forms. 2086 Where the information is available via http, ftp, or ldap, 2087 accessLocation MUST be a uniformResourceIdentifier. Where the 2088 information is available via the directory access protocol (dap), 2089 accessLocation MUST be a directoryName. When the information is 2090 available via electronic mail, accessLocation MUST be an rfc822Name. 2091 The semantics of other name forms of accessLocation (when 2092 accessMethod is id-ad-caIssuers) are not defined by this 2093 specification. 2095 [RFC 2560] defines the access descriptor for the Online Certificate 2096 Status Protocol. When this access descriptor appears in the 2097 authority information access extension, this indicates the issuer 2098 provides revocation information for this certificate through the 2099 named OCSP service. Additional access descriptors may be defined in 2100 other PKIX specifications. 2102 4.2.2.2 Subject Information Access 2104 The subject information access extension indicates how to access 2105 information and services for the subject of the certificate in which 2106 the extension appears. When the subject is a CA, information and 2107 services may include certificate validation services and CA policy 2108 data. When the subject is an end entity, the information describes 2109 the type of services offered and how to access them. In this case, 2110 the contents of this extension are defined in the protocol 2111 specifications for the suported services. This extension may be 2112 included in subject or CA certificates, and it MUST be non-critical. 2114 id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 } 2116 SubjectInfoAccessSyntax ::= 2117 SEQUENCE SIZE (1..MAX) OF AccessDescription 2119 AccessDescription ::= SEQUENCE { 2120 accessMethod OBJECT IDENTIFIER, 2121 accessLocation GeneralName } 2123 Each entry in the sequence SubjectInfoAccessSyntax describes the 2124 format and location of additional information provided by the subject 2125 of the certificate in which this extension appears. The type and 2126 format of the information is specified by the accessMethod field; the 2127 accessLocation field specifies the location of the information. The 2128 retrieval mechanism may be implied by the accessMethod or specified 2129 by accessLocation. 2131 This profile defines one access method to be used when the subject is 2132 a CA, and one access method to be used when the subject is an end 2133 entity. Additional access methods may be defined in the future in 2134 the protocol specifications for other services. 2136 The id-ad-caRepository OID is used when the subject is a CA, and 2137 publishes its certificates and CRLs (if issued) in a repository. The 2138 accessLocation field is defined as a GeneralName, which can take 2139 several forms. Where the information is available via http, ftp, or 2140 ldap, accessLocation MUST be a uniformResourceIdentifier. Where the 2141 information is available via the directory access protocol (dap), 2142 accessLocation MUST be a directoryName. When the information is 2143 available via electronic mail, accessLocation MUST be an rfc822Name. 2144 The semantics of other name forms of of accessLocation (when 2145 accessMethod is id-ad-caRepository) are not defined by this 2146 specification. 2148 The id-ad-timeStamping OID is used when the subject offers 2149 timestamping services using the Time Stamp Protocol defined in [PKIX 2150 TSA]. Where the timestamping services are available via http or ftp, 2151 accessLocation MUST be a uniformResourceIdentifier. Where the 2152 timestamping services are available via electronic mail, 2153 accessLocation MUST be an rfc822Name. Where timestamping services 2154 are available using TCP/IP, the dNSName and ipAddress name forms may 2155 be used. The semantics of other name forms of accessLocation (when 2156 accessMethod is id-ad-timeStamping) are not defined by this 2157 specification. 2159 Additional access descriptors may be defined in other PKIX 2160 specifications. 2162 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 2164 id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 } 2166 id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 } 2168 5 CRL and CRL Extensions Profile 2170 As described above, one goal of this X.509 v2 CRL profile is to 2171 foster the creation of an interoperable and reusable Internet PKI. 2172 To achieve this goal, guidelines for the use of extensions are 2173 specified, and some assumptions are made about the nature of 2174 information included in the CRL. 2176 CRLs may be used in a wide range of applications and environments 2177 covering a broad spectrum of interoperability goals and an even 2178 broader spectrum of operational and assurance requirements. This 2179 profile establishes a common baseline for generic applications 2180 requiring broad interoperability. The profile defines a baseline set 2181 of information that can be expected in every CRL. Also, the profile 2182 defines common locations within the CRL for frequently used 2183 attributes as well as common representations for these attributes. 2185 This profile does not define any private Internet CRL extensions or 2186 CRL entry extensions. 2188 Environments with additional or special purpose requirements may 2189 build on this profile or may replace it. 2191 Conforming CAs are not required to issue CRLs if other revocation or 2192 certificate status mechanisms are provided. Conforming CAs that 2193 issue CRLs MUST issue version 2 CRLs, and CAs MUST include the date 2194 by which the next CRL will be issued in the nextUpdate field (see 2195 sec. 5.1.2.5), the CRL number extension (see sec. 5.2.3) and the 2196 authority key identifier extension (see sec. 5.2.1). Conforming 2197 applications are required to process version 1 and 2 CRLs. 2199 5.1 CRL Fields 2201 The X.509 v2 CRL syntax is as follows. For signature calculation, 2202 the data that is to be signed is ASN.1 DER encoded. ASN.1 DER 2203 encoding is a tag, length, value encoding system for each element. 2205 CertificateList ::= SEQUENCE { 2206 tbsCertList TBSCertList, 2207 signatureAlgorithm AlgorithmIdentifier, 2208 signatureValue BIT STRING } 2210 TBSCertList ::= SEQUENCE { 2211 version Version OPTIONAL, 2212 -- if present, MUST be v2 2213 signature AlgorithmIdentifier, 2214 issuer Name, 2215 thisUpdate Time, 2216 nextUpdate Time OPTIONAL, 2217 revokedCertificates SEQUENCE OF SEQUENCE { 2218 userCertificate CertificateSerialNumber, 2219 revocationDate Time, 2220 crlEntryExtensions Extensions OPTIONAL 2221 -- if present, MUST be v2 2222 } OPTIONAL, 2223 crlExtensions [0] EXPLICIT Extensions OPTIONAL 2224 -- if present, MUST be v2 2225 } 2227 -- Version, Time, CertificateSerialNumber, and Extensions 2228 -- are all defined in the ASN.1 in section 4.1 2230 -- AlgorithmIdentifier is defined in section 4.1.1.2 2232 The following items describe the use of the X.509 v2 CRL in the 2233 Internet PKI. 2235 5.1.1 CertificateList Fields 2237 The CertificateList is a SEQUENCE of three required fields. The 2238 fields are described in detail in the following subsections. 2240 5.1.1.1 tbsCertList 2242 The first field in the sequence is the tbsCertList. This field is 2243 itself a sequence containing the name of the issuer, issue date, 2244 issue date of the next list, the optional list of revoked 2245 certificates, and optional CRL extensions. When there are no revoked 2246 certificates, the revoked certificates list is absent. When one or 2247 more certificates are revoked, each entry on the revoked certificate 2248 list is defined by a sequence of user certificate serial number, 2249 revocation date, and optional CRL entry extensions. 2251 5.1.1.2 signatureAlgorithm 2253 The signatureAlgorithm field contains the algorithm identifier for 2254 the algorithm used by the CA to sign the CertificateList. The field 2255 is of type AlgorithmIdentifier, which is defined in section 4.1.1.2. 2256 [PKIX ALGS] lists the supported algorithms for this specification. 2257 Conforming CAs MUST use the algorithm identifiers presented in [PKIX 2258 ALGS] when signing with a supported signature algorithm. 2260 This field MUST contain the same algorithm identifier as the 2261 signature field in the sequence tbsCertList (see sec. 5.1.2.2). 2263 5.1.1.3 signatureValue 2265 The signatureValue field contains a digital signature computed upon 2266 the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded tbsCertList 2267 is used as the input to the signature function. This signature value 2268 is then ASN.1 encoded as a BIT STRING and included in the CRL's 2269 signatureValue field. The details of this process are specified for 2270 each of the supported algorithms in [PKIX ALGS]. 2272 CAs MAY use one private key to digitally sign certificates and CRLs, 2273 or CAs MAY use separate private keys to digitally sign certificates 2274 and CRLs. When separate private keys are employed, each of the 2275 public keys associated with these private keys is placed in a 2276 separate certificate, one with the keyCertSign bit set in the key 2277 usage extension, and one with the cRLSign bit set in the key usage 2278 extension (see sec. 4.2.1.3). When separate private keys are 2279 employed, certificates issued by the CA contain one authority key 2280 identifier, and the corresponding CRLs contain a different authority 2281 key identifier. The use of separate CA certificates for validation 2282 of certificate signatures and CRL signatures can offer improved 2283 security characteristics; however, it imposes a burden on 2284 applications, and it might limit interoperability. Many applications 2285 construct a certification path, and then validate the certification 2286 path (see sec. 6). CRL checking in turn requires a separate 2287 certification path to be constructed and validated for the CA's CRL 2288 signature validation certificate. Applications that perform CRL 2289 checking MUST support certification path validation when certificates 2290 and CRLs are digitally signed with the same CA private key. These 2291 applications SHOULD support certification path validation when 2292 certificates and CRLs are digitally signed with different CA private 2293 keys. 2295 5.1.2 Certificate List "To Be Signed" 2297 The certificate list to be signed, or TBSCertList, is a SEQUENCE of 2298 required and optional fields. The required fields identify the CRL 2299 issuer, the algorithm used to sign the CRL, the date and time the CRL 2300 was issued, and the date and time by which the CA will issue the next 2301 CRL. 2303 Optional fields include lists of revoked certificates and CRL 2304 extensions. The revoked certificate list is optional to support the 2305 case where a CA has not revoked any unexpired certificates that it 2306 has issued. The profile requires conforming CAs to use the CRL 2307 extension cRLNumber in all CRLs issued. 2309 5.1.2.1 Version 2311 This optional field describes the version of the encoded CRL. When 2312 extensions are used, as required by this profile, this field MUST be 2313 present and MUST specify version 2 (the integer value is 1). 2315 5.1.2.2 Signature 2317 This field contains the algorithm identifier for the algorithm used 2318 to sign the CRL. [PKIX ALGS] lists OIDs for the most popular 2319 signature algorithms used in the Internet PKI. 2321 This field MUST contain the same algorithm identifier as the 2322 signatureAlgorithm field in the sequence CertificateList (see section 2323 5.1.1.2). 2325 5.1.2.3 Issuer Name 2327 The issuer name identifies the entity who has signed and issued the 2328 CRL. The issuer identity is carried in the issuer name field. 2329 Alternative name forms may also appear in the issuerAltName extension 2330 (see sec. 5.2.2). The issuer name field MUST contain an X.500 2331 distinguished name (DN). The issuer name field is defined as the 2332 X.501 type Name, and MUST follow the encoding rules for the issuer 2333 name field in the certificate (see sec. 4.1.2.4). 2335 5.1.2.4 This Update 2337 This field indicates the issue date of this CRL. ThisUpdate may be 2338 encoded as UTCTime or GeneralizedTime. 2340 CAs conforming to this profile that issue CRLs MUST encode thisUpdate 2341 as UTCTime for dates through the year 2049. CAs conforming to this 2342 profile that issue CRLs MUST encode thisUpdate as GeneralizedTime for 2343 dates in the year 2050 or later. 2345 Where encoded as UTCTime, thisUpdate MUST be specified and 2346 interpreted as defined in section 4.1.2.5.1. Where encoded as 2347 GeneralizedTime, thisUpdate MUST be specified and interpreted as 2348 defined in section 4.1.2.5.2. 2350 5.1.2.5 Next Update 2352 This field indicates the date by which the next CRL will be issued. 2353 The next CRL could be issued before the indicated date, but it will 2354 not be issued any later than the indicated date. CAs SHOULD issue 2355 CRLs with a nextUpdate time equal to or later than all previous CRLs. 2356 nextUpdate may be encoded as UTCTime or GeneralizedTime. 2358 This profile requires inclusion of nextUpdate in all CRLs issued by 2359 conforming CAs. Note that the ASN.1 syntax of TBSCertList describes 2360 this field as OPTIONAL, which is consistent with the ASN.1 structure 2361 defined in [X.509]. The behavior of clients processing CRLs which 2362 omit nextUpdate is not specified by this profile. 2364 CAs conforming to this profile that issue CRLs MUST encode nextUpdate 2365 as UTCTime for dates through the year 2049. CAs conforming to this 2366 profile that issue CRLs MUST encode nextUpdate as GeneralizedTime for 2367 dates in the year 2050 or later. 2369 Where encoded as UTCTime, nextUpdate MUST be specified and 2370 interpreted as defined in section 4.1.2.5.1. Where encoded as 2371 GeneralizedTime, nextUpdate MUST be specified and interpreted as 2372 defined in section 4.1.2.5.2. 2374 5.1.2.6 Revoked Certificates 2376 When there are no revoked certificates, the revoked certificates list 2377 is absent. Otherwise, revoked certificates are listed by their 2378 serial numbers. Certificates revoked by the CA are uniquely 2379 identified by the certificate serial number. The date on which the 2380 revocation occurred is specified. The time for revocationDate MUST 2381 be expressed as described in section 5.1.2.4. Additional information 2382 may be supplied in CRL entry extensions; CRL entry extensions are 2383 discussed in section 5.3. 2385 5.1.2.7 Extensions 2387 This field may only appear if the version is 2 (see sec. 5.1.2.1). 2388 If present, this field is a SEQUENCE of one or more CRL extensions. 2389 CRL extensions are discussed in section 5.2. 2391 5.2 CRL Extensions 2393 The extensions defined by ANSI X9 and ISO/IEC/ITU for X.509 v2 CRLs 2394 [X.509] [X9.55] provide methods for associating additional attributes 2395 with CRLs. The X.509 v2 CRL format also allows communities to define 2396 private extensions to carry information unique to those communities. 2397 Each extension in a CRL may be designated as critical or non- 2398 critical. A CRL validation MUST fail if it encounters a critical 2399 extension which it does not know how to process. However, an 2400 unrecognized non-critical extension may be ignored. The following 2401 subsections present those extensions used within Internet CRLs. 2402 Communities may elect to include extensions in CRLs which are not 2403 defined in this specification. However, caution should be exercised 2404 in adopting any critical extensions in CRLs which might be used in a 2405 general context. 2407 Conforming CAs that issue CRLs are required to include the authority 2408 key identifier (see sec. 5.2.1) and the CRL number (see sec. 5.2.3) 2409 extensions in all CRLs issued. 2411 5.2.1 Authority Key Identifier 2413 The authority key identifier extension provides a means of 2414 identifying the public key corresponding to the private key used to 2415 sign a CRL. The identification can be based on either the key 2416 identifier (the subject key identifier in the CRL signer's 2417 certificate) or on the issuer name and serial number. This extension 2418 is especially useful where an issuer has more than one signing key, 2419 either due to multiple concurrent key pairs or due to changeover. 2421 Conforming CAs MUST use the key identifier method, and MUST include 2422 this extension in all CRLs issued. 2424 The syntax for this CRL extension is defined in section 4.2.1.1. 2426 5.2.2 Issuer Alternative Name 2428 The issuer alternative names extension allows additional identities 2429 to be associated with the issuer of the CRL. Defined options include 2430 an rfc822 name (electronic mail address), a DNS name, an IP address, 2431 and a URI. Multiple instances of a name and multiple name forms may 2432 be included. Whenever such identities are used, the issuer 2433 alternative name extension MUST be used. 2435 The issuerAltName extension SHOULD NOT be marked critical. 2437 The OID and syntax for this CRL extension are defined in section 2438 4.2.1.8. 2440 5.2.3 CRL Number 2442 The CRL number is a non-critical CRL extension which conveys a 2443 monotonically increasing sequence number for each CRL issued by a CA. 2444 This extension allows users to easily determine when a particular CRL 2445 supersedes another CRL. CAs conforming to this profile MUST include 2446 this extension in all CRLs. 2448 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 2450 cRLNumber ::= INTEGER (0..MAX) 2452 5.2.4 Delta CRL Indicator 2454 The delta CRL indicator is a critical CRL extension that identifies a 2455 CRL as being a delta CRL. Delta CRLs contain updates to revocation 2456 information previously distributed, rather than all the information 2457 that would appear in a complete CRL. The use of delta CRLs can 2458 significantly reduce network load and processing time in some 2459 environments. Delta CRLs are generally smaller than the CRLs they 2460 update, so applications that obtain delta CRLs consume less network 2461 bandwidth than applications that obtain the corresponding complete 2462 CRLs. Applications which store revocation information in a format 2463 other than the CRL structure can add new revocation information to 2464 the local database without reprocessing information. 2466 The delta CRL indicator extension contains a single value of type 2467 BaseCRLNumber. This value identifies the CRL number of the base CRL 2468 that was used as the foundation in the generation of this delta CRL. 2469 The referenced base CRL is a CRL that was explicitly issued as a CRL 2470 that is complete for a given scope (e.g., a set of revocation reasons 2471 or a particular distribution point.) The CRL containing the delta CRL 2472 indicator extension contains all updates to the certificate 2473 revocation status for that same scope. The combination of a CRL 2474 containing the delta CRL indicator extension plus the CRL referenced 2475 in the BaseCRLNumber component of this extension is equivalent to a 2476 full CRL, for the applicable scope, at the time of publication of the 2477 delta CRL. 2479 When a conforming CA issues a delta CRL, the CA MUST also issue a CRL 2480 that is complete for the given scope. Both the delta CRL and the 2481 complete CRL MUST include the CRL number extension (see sec. 5.2.3). 2482 The CRL number extension in the delta CRL and the complete CRL MUST 2483 contain the same value. When a delta CRL is issued, it MUST cover 2484 the same set of reasons and same set of certificates that were 2485 covered by the base CRL it references. 2487 An application can construct a CRL that is complete for a given 2488 scope, at the current time, in either of the following ways: 2490 (a) by retrieving the current delta CRL for that scope, and 2491 combining it with an issued CRL that is complete for that scope 2492 and that has a cRLNumber greater than or equal to the cRLNumber of 2493 the base CRL referenced in the delta CRL; or 2495 (b) by retrieving the current delta CRL for that scope and 2496 combining it with a locally constructed CRL whose cRLNumber is 2497 greater than or equal to the cRLNumber of the base CRL referenced 2498 in the current delta CRL. 2500 The constructed CRL has the CRL number specified in the CRL number 2501 extension found in the delta CRL used in its construction. 2503 CAs must ensure that application of a delta CRL to the referenced 2504 base revocation information accurately reflects the current status of 2505 revocation. If a CA supports the certificateHold revocation reason 2506 the following rules must be applied when generating delta CRLs: 2508 (a) If a certificate was listed as revoked with revocation reason 2509 certificateHold on a CRL (either a delta CRL or a CRL that is 2510 complete for a given scope), whose cRLNumber is n, and the hold is 2511 subsequently released, the certificate must be included in all 2512 delta CRLs issued after the hold is released where the cRLNumber 2513 of the referenced base CRL is less than or equal to n. The 2514 certificate must be listed with revocation reason removeFromCRL 2515 unless the certificate is subsequently revoked again for one of 2516 the revocation reasons covered by the delta CRL, in which case the 2517 certificate must be listed with the revocation reason appropriate 2518 for the subsequent revocation. 2520 (b) If the certificate was not removed from hold, but was 2521 permanently revoked, then it must be listed on all subsequent 2522 delta CRLs where the cRLNumber of the referenced base CRL is less 2523 than the cRLNumber of the CRL (either a delta CRL or a CRL that is 2524 complete for the given scope) on which the permanent revocation 2525 notice first appeared. 2527 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 2529 BaseCRLNumber ::= CRLNumber 2531 5.2.5 Issuing Distribution Point 2533 The issuing distribution point is a critical CRL extension that 2534 identifies the CRL distribution point for a particular CRL, and it 2535 indicates whether the CRL covers revocation for end entity 2536 certificates only, CA certificates only, or a limited set of reason 2537 codes. Although the extension is critical, conforming 2538 implementations are not required to support this extension. 2540 The CRL is signed using the CA's private key. CRL Distribution 2541 Points do not have their own key pairs. If the CRL is stored in the 2542 X.500 Directory, it is stored in the Directory entry corresponding to 2543 the CRL distribution point, which may be different than the Directory 2544 entry of the CA. 2546 The reason codes associated with a distribution point MUST be 2547 specified in onlySomeReasons. If onlySomeReasons does not appear, 2548 the distribution point shall contain revocations for all reason 2549 codes. CAs MAY use CRL distribution points to partition the CRL on 2550 the basis of compromise and routine revocation. In this case, the 2551 revocations with reason code keyCompromise (1) and cACompromise (2) 2552 appear in one distribution point, and the revocations with other 2553 reason codes appear in another distribution point. 2555 Where the issuingDistributionPoint extension contains a URL, the 2556 following semantics MUST be assumed: the object is a pointer to the 2557 most current CRL issued by this CA. The URI schemes ftp, http, 2558 mailto [RFC1738] and ldap [RFC1778] are defined for this purpose. 2559 The URI MUST be an absolute, not relative, pathname and MUST specify 2560 the host. 2562 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 2564 issuingDistributionPoint ::= SEQUENCE { 2565 distributionPoint [0] DistributionPointName OPTIONAL, 2566 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 2567 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 2568 onlySomeReasons [3] ReasonFlags OPTIONAL, 2569 indirectCRL [4] BOOLEAN DEFAULT FALSE } 2571 5.2.6 Freshest CRL (a.k.a. Delta CRL Distribution Point) 2573 The freshest CRL extension identifies how delta-CRL information for 2574 this CRL is obtained. The extension MUST be non-critical. 2576 The same syntax is used for this extension as the 2577 cRLDistributionPoints certificate extension, and is described in 2578 section 4.2.1.14. The same conventions apply to both extensions. 2580 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } 2582 FreshestCRL ::= CRLDistributionPoints 2584 5.3 CRL Entry Extensions 2586 The CRL entry extensions already defined by ANSI X9 and ISO/IEC/ITU 2587 for X.509 v2 CRLs provide methods for associating additional 2588 attributes with CRL entries [X.509] [X9.55]. The X.509 v2 CRL format 2589 also allows communities to define private CRL entry extensions to 2590 carry information unique to those communities. Each extension in a 2591 CRL entry may be designated as critical or non-critical. A CRL 2592 validation MUST fail if it encounters a critical CRL entry extension 2593 which it does not know how to process. However, an unrecognized non- 2594 critical CRL entry extension may be ignored. The following 2595 subsections present recommended extensions used within Internet CRL 2596 entries and standard locations for information. Communities may 2597 elect to use additional CRL entry extensions; however, caution should 2598 be exercised in adopting any critical extensions in CRL entries which 2599 might be used in a general context. 2601 All CRL entry extensions used in this specification are non-critical. 2602 Support for these extensions is optional for conforming CAs and 2603 applications. However, CAs that issue CRLs SHOULD include reason 2604 codes (see sec. 5.3.1) and invalidity dates (see sec. 5.3.3) whenever 2605 this information is available. 2607 5.3.1 Reason Code 2609 The reasonCode is a non-critical CRL entry extension that identifies 2610 the reason for the certificate revocation. CAs are strongly 2611 encouraged to include meaningful reason codes in CRL entries; 2612 however, the reason code CRL entry extension SHOULD be absent instead 2613 of using the unspecified (0) reasonCode value. 2615 id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 } 2617 -- reasonCode ::= { CRLReason } 2619 CRLReason ::= ENUMERATED { 2620 unspecified (0), 2621 keyCompromise (1), 2622 cACompromise (2), 2623 affiliationChanged (3), 2624 superseded (4), 2625 cessationOfOperation (5), 2626 certificateHold (6), 2627 removeFromCRL (8) } 2629 5.3.2 Hold Instruction Code 2631 The hold instruction code is a non-critical CRL entry extension that 2632 provides a registered instruction identifier which indicates the 2633 action to be taken after encountering a certificate that has been 2634 placed on hold. 2636 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 2638 holdInstructionCode ::= OBJECT IDENTIFIER 2640 The following instruction codes have been defined. Conforming 2641 applications that process this extension MUST recognize the following 2642 instruction codes. 2644 holdInstruction OBJECT IDENTIFIER ::= 2645 { iso(1) member-body(2) us(840) x9-57(10040) 2 } 2647 id-holdinstruction-none OBJECT IDENTIFIER ::= {holdInstruction 1} 2648 id-holdinstruction-callissuer 2649 OBJECT IDENTIFIER ::= {holdInstruction 2} 2650 id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3} 2652 Conforming applications which encounter an id-holdinstruction- 2653 callissuer MUST call the certificate issuer or reject the 2654 certificate. Conforming applications which encounter an id- 2655 holdinstruction-reject MUST reject the certificate. The hold 2656 instruction id-holdinstruction-none is semantically equivalent to the 2657 absence of a holdInstructionCode, and its use is strongly deprecated 2658 for the Internet PKI. 2660 5.3.3 Invalidity Date 2662 The invalidity date is a non-critical CRL entry extension that 2663 provides the date on which it is known or suspected that the private 2664 key was compromised or that the certificate otherwise became invalid. 2665 This date may be earlier than the revocation date in the CRL entry, 2666 which is the date at which the CA processed the revocation. When a 2667 revocation is first posted by a CA in a CRL, the invalidity date may 2668 precede the date of issue of earlier CRLs, but the revocation date 2669 SHOULD NOT precede the date of issue of earlier CRLs. Whenever this 2670 information is available, CAs are strongly encouraged to share it 2671 with CRL users. 2673 The GeneralizedTime values included in this field MUST be expressed 2674 in Greenwich Mean Time (Zulu), and MUST be specified and interpreted 2675 as defined in section 4.1.2.5.2. 2677 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 2679 invalidityDate ::= GeneralizedTime 2681 5.3.4 Certificate Issuer 2683 This CRL entry extension identifies the certificate issuer associated 2684 with an entry in an indirect CRL, i.e. a CRL that has the indirectCRL 2685 indicator set in its issuing distribution point extension. If this 2686 extension is not present on the first entry in an indirect CRL, the 2687 certificate issuer defaults to the CRL issuer. On subsequent entries 2688 in an indirect CRL, if this extension is not present, the certificate 2689 issuer for the entry is the same as that for the preceding entry. 2690 This field is defined as follows: 2692 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } 2694 certificateIssuer ::= GeneralNames 2696 If used by conforming CAs that issue CRLs, this extension MUST always 2697 be critical. If an implementation ignored this extension it could 2698 not correctly attribute CRL entries to certificates. This 2699 specification RECOMMENDS that implementations recognize this 2700 extension. 2702 6 Certification Path Validation 2704 Certification path validation procedures for the Internet PKI are 2705 based on the algorithm supplied in [X.509]. Certification path 2706 processing verifies the binding between the subject distinguished 2707 name and/or subject alternative name and subject public key. The 2708 binding is limited by constraints which are specified in the 2709 certificates which comprise the path and inputs which are specified 2710 by the relying party. The basic constraints and policy constraints 2711 extensions allow the certification path processing logic to automate 2712 the decision making process. 2714 This section describes an algorithm for validating certification 2715 paths. Conforming implementations of this specification are not 2716 required to implement this algorithm, but MUST provide functionality 2717 equivalent to the external behavior resulting from this procedure. 2718 Any algorithm may be used by a particular implementation so long as 2719 it derives the correct result. 2721 In section 6.1, the text describes basic path validation. Valid 2722 paths begin with certificates issued by a "most-trusted CA". The 2723 algorithm requires the public key of the CA, the CA's name, and any 2724 constraints upon the set of paths which may be validated using this 2725 key. 2727 The selection of a "most-trusted CA" is a matter of policy: it could 2728 be the top CA in a hierarchical PKI; the CA that issued the 2729 verifier's own certificate(s); or any other CA in a network PKI. The 2730 path validation procedure is the same regardless of the choice of 2731 "most-trusted CA." In addition, different applications may rely on 2732 different "most-trusted CA", or may accept paths that begin with any 2733 of a set of "most-trusted CAs." 2735 Section 6.2 describes methods for using the path validation algorithm 2736 in specific implementations. Two specific cases are discussed: the 2737 case where paths may begin with one of several trusted CAs; and where 2738 compatibility with the PEM architecture is required. 2740 Section 6.3 describes the steps necessary to determine if a 2741 certificate is revoked or on hold status when CRLs are the revocation 2742 mechanism used by the certificate issuer. 2744 6.1 Basic Path Validation 2746 This text describes an algorithm for X.509 path processing. A 2747 conformant implementation MUST include an X.509 path processing 2748 procedure that is functionally equivalent to the external behavior of 2749 this algorithm. However, some of the certificate fields processed in 2750 this algorithm are optional for compliant implementations. Clients 2751 that do not support these fields may omit the corresponding steps in 2752 the path validation algorithm. 2754 For example, clients are not required to support the policy mapping 2755 extension. Clients that do not support this extension may omit the 2756 path validation steps where policy mappings are processed. Note that 2757 clients MUST reject the certificate if it contains critical 2758 extensions that are not supported. 2760 This text describes the trust anchor as an input to the algorithm. 2761 There is no requirement that the same trust anchor be used to 2762 validate all certification paths. Different trust anchors may be 2763 used to validate different paths, as discussed further in Section 2764 6.2. 2766 The primary goal of path validation is to verify the binding between 2767 a subject distinguished name or subject alternative name and subject 2768 public key, as represented in the end entity certificate, based on 2769 the public key of the trust anchor. This requires obtaining a 2770 sequence of certificates that support that binding. The procedure 2771 performed to obtain this sequence of certificates is outside the 2772 scope of this section. 2774 To meet this goal, the path validation process verifies, among other 2775 things, that a prospective certification path (a sequence of n 2776 certificates) satisfies the following conditions: 2778 (a) for all x in {1, ..., n-1}, the subject of certificate x is 2779 the issuer of certificate x+1; 2781 (b) certificate 1 is issued by the trust anchor; 2783 (c) certificate n is the end entity certificate; and 2785 (d) for all x in {1, ..., n}, the certificate was valid at the 2786 time in question. 2788 A particular certification path may not, however, be appropriate for 2789 all applications. The path validation process also determines the 2790 set of certificate policies that are valid for this path, based on 2791 the certificate policies extension, policy mapping extension, policy 2792 constraints extension, and inhibit any-policy extension. To achieve 2793 this, the path validation algorithm constructs a valid policy tree. 2794 If the set of certificate policies that are valid for this path is 2795 not empty, then the result will be a valid policy tree of depth n, 2796 otherwise the result will be a NULL valid policy tree. 2798 A certificate is termed self-issued if the DNs that appear in the 2799 subject and issuer fields are identical and are not empty. In 2800 general, the issuer and subject of the certificates that make up a 2801 path are different for each certificate. However, a CA may issue a 2802 certificate to itself to support key rollover or changes in 2803 certificate policies. These self-issued certificates are not counted 2804 when evaluating path length or name constraints. 2806 This section presents the algorithm in four basic steps: (1) 2807 initialization, (2) basic certificate processing, (3) preparation for 2808 the next certificate, and (4) wrap-up. Steps (1) and (4) are 2809 performed exactly once. Step (2) is performed for all certificates 2810 in the path. Step (3) is performed for all certificates in the path 2811 except the final certificate. Figure 2 provides a high-level 2812 flowchart of this algorithm. 2814 +-------+ 2815 | START | 2816 +-------+ 2817 | 2818 V 2819 +----------------+ 2820 | Initialization | 2821 +----------------+ 2822 | 2823 +<--------------------+ 2824 | | 2825 V | 2826 +----------------+ | 2827 | Process Cert | | 2828 +----------------+ | 2829 | | 2830 V | 2831 +================+ | 2832 | IF Last Cert | | 2833 | in Path | | 2834 +================+ | 2835 | | | 2836 THEN | | ELSE | 2837 V V | 2838 +----------------+ +----------------+ | 2839 | Wrap up | | Prepare for | | 2840 +----------------+ | Next Cert | | 2841 | +----------------+ | 2842 V | | 2843 +-------+ +--------------+ 2844 | STOP | 2845 +-------+ 2847 Figure 2. Path Processing Flowchart 2849 6.1.1 Inputs 2851 This algorithm assumes the following seven inputs are provided to the 2852 path processing logic: 2854 (a) a prospective certification path of length n; 2856 (b) the time, T, for which the validity of the path should be 2857 determined. This may be the current date/time, or some point in 2858 the past. 2860 (c) user-initial-policy-set: A set of certificate policy 2861 identifiers naming the policies that are acceptable to the 2862 certificate user. The user-initial-policy-set contains the special 2863 value any-policy if the user is not concerned about certificate 2864 policy. 2866 (d) trust anchor information, describing a CA that serves as a 2867 trust anchor for the certification path. The trust anchor 2868 information includes: 2870 (1) the trusted issuer name, 2872 (2) the trusted public key algorithm, 2874 (3) the trusted public key, and 2876 (4) optionally, the trusted public key parameters associated 2877 with the public key. 2879 The trust anchor information may be provided to the path 2880 processing procedure in the form of a self-signed certificate. 2881 The trusted anchor information is trusted because it was delivered 2882 to the path processing procedure by some trustworthy out-of-band 2883 procedure. If the trusted public key algorithm requires 2884 parameters, then the parameters are provided along with the 2885 trusted public key. 2887 (e) initial-policy-mapping-inhibit, which indicates if policy 2888 mapping is allowed in the certification path. 2890 (f) initial-explicit-policy, which indicates if the path must be 2891 valid for at least one of the certificate policies in the user- 2892 initial-policy-set. 2894 (g) initial-any-policy-inhibit, which indicates whether the any- 2895 policy OID should be processed if it is included in a certificate. 2897 6.1.2 Initialization 2899 The initialization phase establishes eleven state variables based 2900 upon the seven inputs: 2902 (a) valid_policy_tree: A tree of certificate policies with their 2903 optional qualifiers; each of the leaves of the tree represents a 2904 valid policy at this stage in the certification path validation. 2905 If valid policies exist at this stage in the certification path 2906 validation, the depth of the tree is equal to the number of 2907 certificates in the chain that have been processed. If valid 2908 policies do not exist at this stage in the certification path 2909 validation, the tree is set to NULL. Once the tree is set to NULL, 2910 policy processing ceases. 2912 Each node in the valid_policy_tree includes four data objects: the 2913 valid policy, a set of associated policy qualifiers, a set of one 2914 or more expected policy values, and a criticality indicator. If 2915 the node is at depth x, the components of the node have the 2916 following semantics: 2918 (1) The valid_policy is a single policy OID representing a 2919 valid policy for the path of length x. 2921 (2) The qualifier_set is a set of policy qualifiers associated 2922 with the valid policy in certificate x. 2924 (3) The criticality_indicator indicates whether the certificate 2925 policy extension in certificate x was marked as critical. 2927 (4) The expected_policy_set contains one or more policy OIDs 2928 that would satisfy this policy in the certificate x+1. 2930 The initial value of the valid_policy_tree is a single node with 2931 valid_policy any-policy, an empty qualifier_set, an 2932 expected_policy_set with the single value any-policy, and a 2933 criticality_indicator of FALSE. This node is considered to be at 2934 depth zero. 2936 Figure 3 is a graphic representation of the initial state of the 2937 valid_policy_tree. Additional figures will use this format to 2938 describe changes in the valid_policy_tree during path processing. 2940 +----------------+ 2941 | any-policy | <---- valid_policy 2942 +----------------+ 2943 | {} | <---- qualifier_set 2944 +----------------+ 2945 | FALSE | <---- criticality_indicator 2946 +----------------+ 2947 | {any-policy} | <---- expected_policy_set 2948 +----------------+ 2950 Figure 3. Initial value of the valid_policy_tree state variable 2952 (b) permitted_subtrees: A set of root names for each name type 2953 (e.g., X.500 distinguished names, email addresses, or ip 2954 addresses) defining a set of subtrees within which all subject 2955 names in subsequent certificates in the certification path MUST 2956 fall. This variable includes a set for each name type: the 2957 initial value for the set for Distinguished Names is the set of 2958 all Distinguished names; the initial value for the set of RFC822 2959 names is the set of all RFC822 names, etc. 2961 (c) excluded_subtrees: A set of root names for each name type 2962 (e.g., X.500 distinguished names, email addresses, or ip 2963 addresses) defining a set of subtrees within which no subject name 2964 in subsequent certificates in the certification path may fall. 2965 This variable includes a set for each name type, and the initial 2966 value for each set is empty. 2968 (d) explicit_policy: an integer which indicates if a non-NULL 2969 valid_policy_tree is required. The integer indicates the number of 2970 non-self-issued certificates to be processed before this 2971 requirement is imposed. Once set, this variable may be decreased, 2972 but may not be increased. That is, if a certificate in the path 2973 requires a non-NULL valid_policy_tree, a later certificate can not 2974 remove this requirement. If initial-explicit-policy is set, then 2975 the initial value is 0, otherwise the initial value is n+1. 2977 (e) inhibit_any-policy: an integer which indicates whether the 2978 any-policy policy identifier is considered a match. The integer 2979 indicates the number of non-self-issued certificates to be 2980 processed before the any-policy OID, if asserted in a certificate, 2981 is ignored. Once set, this variable may be decreased, but may not 2982 be increased. That is, if a certificate in the path inhibits 2983 processing of any-policy, a later certificate can not permit it. 2984 If initial-any-policy-inhibit is set, then the initial value is 0, 2985 otherwise the initial value is n+1. 2987 (f) policy_mapping: an integer which indicates if policy mapping 2988 is permitted. The integer indicates the number of non-self-issued 2989 certificates to be processed before policy mapping is inhibited. 2990 Once set, this variable may be decreased, but may not be 2991 increased. That is, if a certificate in the path specifies policy 2992 mapping is not permitted, it can not be overridden by a later 2993 certificate. If initial-policy-mapping-inhibit is set, then the 2994 initial value is 0, otherwise the initial value is n+1. 2996 (g) working_public_key_algorithm: the digital signature algorithm 2997 used to verify the signature of a certificate. The 2998 working_public_key_algorithm is initialized from the trusted 2999 public key algorithm provided in the trust anchor information. 3001 (h) working_public_key: the public key used to verify the 3002 signature of a certificate. The working_public_key is initialized 3003 from the trusted public key provided in the trust anchor 3004 information. 3006 (i) working_public_key_parameters: parameters associated with the 3007 current public key, that may required to verify a signature 3008 (depending upon the algorithm). The working_public_key_parameters 3009 variable is initialized from the trusted public key parameters 3010 provided in the trust anchor information. 3012 (j) working_issuer_name: the issuer distinguished name expected 3013 in the next certificate in the chain. The working_issuer_name is 3014 initialized to the trusted issuer provided in the trust anchor 3015 information. 3017 (k) max_path_length: this integer is initialized to n, and is 3018 reset by the path length constraint field within the basic 3019 constraints extension of a CA certificate. 3021 Upon completion of the initialization steps, perform the basic 3022 certificate processing steps specified in 6.1.3. 3024 6.1.3 Basic Certificate Processing 3026 The basic path processing actions to be performed for certificate i 3027 are listed below. 3029 (a) Verify the basic certificate information. The certificate 3030 must satisfy each of the following: 3032 (1) The certificate was signed with the 3033 working_public_key_algorithm using the working_public_key and 3034 the working_public_key_parameters. 3036 (2) The certificate validity period includes time T. 3038 (3) At time T, the certificate is not revoked and is not on 3039 hold status. This may be determined by obtaining the 3040 appropriate CRL (see section 6.3), status information, or by 3041 out-of-band mechanisms. 3043 (4) The certificate issuer name is the working_issuer_name. 3045 (b) If certificate i is not self-issued, verify that the subject 3046 name is within one of the permitted_subtrees for X.500 3047 distinguished names, and verify that each of the alternative names 3048 in the subjectAltName extension (critical or non-critical) is 3049 within one of the permitted_subtrees for that name type. 3051 (c) If certificate i is not self-issued, verify that the subject 3052 name is not within one of the excluded_subtrees for X.500 3053 distinguished names, and verify that each of the alternative names 3054 in the subjectAltName extension (critical or non-critical) is not 3055 within one of the excluded_subtrees for that name type. 3057 (d) If the certificate policies extension is present in the 3058 certificiate and the valid_policy_tree is not NULL, process the 3059 policy information by performing the following steps in order: 3061 (1) For each policy P not equal to any-policy in the 3062 certificate policies extension, let P-OID denote the OID in 3063 policy P and P-Q denote the qualifier set for policy P. 3064 Perform the following steps in order: 3066 (i) If the valid_policy_tree includes a node of depth i-1 3067 where P-OID is in the expected_policy_set, create a child 3068 node as follows: set the valid_policy to OID- P; set the 3069 qualifier_set to P-Q, and set the expected_policy_set to {P- 3070 OID}. 3072 For example, consider a valid_policy_tree with a node of 3073 depth i-1 where the expected_policy_set is {Gold, White}. 3074 Assume the certificate policies Gold and Silver appear in 3075 the certificate policies extension of certificate i. The 3076 Gold policy is matched but the Silver policy is not. This 3077 rule will generate a child node of depth i for the Gold 3078 policy. The result is shown as Figure 4. 3080 |-----------------| 3081 | Red | 3082 |-----------------| 3083 | {} | 3084 |-----------------| node of depth i-1 3085 | FALSE | 3086 |-----------------| 3087 | {Gold, White} | 3088 |-----------------| 3089 | 3090 | 3091 | 3092 V 3093 |-----------------| 3094 | Gold | 3095 |-----------------| 3096 | {} | 3097 |-----------------| node of depth i 3098 | uninitialized | 3099 |-----------------| 3100 | {Gold} | 3101 |-----------------| 3103 Figure 4. Processing an exact match 3105 (ii) If there was no match in step (i) and the 3106 valid_policy_tree includes a node of depth i-1 with the 3107 valid policy any-policy, generate a child node with the 3108 following values: set the valid_policy to P-OID; set the 3109 qualifier_set to P-Q, and set the expected_policy_set to {P- 3110 OID}. 3112 For example, consider a valid_policy_tree with a node of 3113 depth i-1 where the valid_policy is any-policy. Assume the 3114 certificate policies Gold and Silver appear in the 3115 certificate policies extension of certificate i. The Gold 3116 policy does not have a qualifier, but the Silver policy has 3117 the qualifier Q-Silver. If Gold and Silver were not matched 3118 in (i) above, this rule will generate two child nodes of 3119 depth i, one for each policy. The result is shown as Figure 3120 5. 3122 |-----------------| 3123 | any-policy | 3124 |-----------------| 3125 | {} | 3126 |-----------------| node of depth i-1 3127 | FALSE | 3128 |-----------------| 3129 | {any-policy} | 3130 |-----------------| 3131 / \ 3132 / \ 3133 / \ 3134 / \ 3135 |-----------------| |-----------------| 3136 | Gold | | Silver | 3137 |-----------------| |-----------------| 3138 | {} | | {Q-Silver} | 3139 |-----------------| nodes of |-----------------| 3140 | uninitialized | depth i | uninitialized | 3141 |-----------------| |-----------------| 3142 | {Gold} | | {Silver} | 3143 |-----------------| |-----------------| 3145 Figure 5. Processing unmatched policies when a leaf node 3146 specifies any-policy 3148 (2) If the certificate policies extension includes the policy 3149 any-policy with the qualifier set AP-Q and inhibit_any-policy 3150 is greater than 0, then: 3152 For each node in the valid_policy_tree of depth i-1, for each 3153 value in the expected_policy_set (including any-policy) that 3154 does not appear in a child node, create a child node with the 3155 following values: set the valid_policy to the value from the 3156 expected_policy_set in the parent node; set the qualifier_set 3157 to AP-Q, and set the expected_policy_set to the value in the 3158 valid_policy from this node. 3160 For example, consider a valid_policy_tree with a node of depth 3161 i-1 where the expected_policy_set = {Gold, Silver}. Assume 3162 any-policy appears in the certificate policies extension of 3163 certificate i, but Gold and Silver do not. This rule will 3164 generate two child nodes of depth i, one for each policy. The 3165 result is shown below as Figure 6. 3167 |-----------------| 3168 | Red | 3169 |-----------------| 3170 | {} | 3171 |-----------------| node of depth i-1 3172 | FALSE | 3173 |-----------------| 3174 | {Gold, Silver} | 3175 |-----------------| 3176 / \ 3177 / \ 3178 / \ 3179 / \ 3180 |-----------------| |-----------------| 3181 | Gold | | Silver | 3182 |-----------------| |-----------------| 3183 | {} | | {} | 3184 |-----------------| nodes of |-----------------| 3185 | uninitialized | depth i | uninitialized | 3186 |-----------------| |-----------------| 3187 | {Gold} | | {Silver} | 3188 |-----------------| |-----------------| 3190 Figure 6. Processing unmatched policies when the certificate 3191 policies extension specifies any-policy 3193 (3) If there is a node in the valid_policy_tree of depth i-1 or 3194 less without any child nodes, delete that node. Repeat this 3195 step until there are no nodes of depth i-1 or less without 3196 children. 3198 For example, consider the valid_policy_tree shown in Figure 7 3199 below. The two nodes at depth i-1 that are marked with an 'X' 3200 have no children, and are deleted. Applying this rule to the 3201 resulting tree will cause the node at depth i-2 that is marked 3202 with an 'Y' to be deleted. The following application of the 3203 rule does not cause any nodes to be deleted, and this step is 3204 complete. 3206 +-----------+ 3207 | | node of depth i-3 3208 +-----------+ 3209 / | \ 3210 / | \ 3211 / | \ 3212 +-----------+ +-----------+ +-----------+ 3213 | | | | | Y | nodes of 3214 +-----------+ +-----------+ +-----------+ depth i-2 3215 / \ || || 3216 / \ || || 3217 / \ || || 3218 +-----------+ +-----------+ +-----------+ +-----------+ nodes of 3219 | | | X | | | | X | depth 3220 +-----------+ +-----------+ +-----------+ +-----------+ i-1 3221 | / | \ 3222 | / | \ 3223 | / | \ 3224 +-----------+ +-----------+ +-----------+ +-----------+ nodes of 3225 | | | | | | | | depth 3226 +-----------+ +-----------+ +-----------+ +-----------+ i 3228 Figure 7. Pruning the valid_policy_tree 3230 (4) If the certificate policies extension was marked as 3231 critical, set the criticality_indicator in all nodes of depth i 3232 to TRUE. If the certificate policies extension was not marked 3233 critical, set the criticality_indicator in all nodes of depth i 3234 to FALSE. 3236 (e) If the certificate policies extension is not present, set the 3237 valid_policy_tree to NULL. 3239 (f) verify that either explicit_policy is greater than 0 or the 3240 valid_policy_tree is not equal to NULL; 3242 If any of steps (a), (b), (c), or (f) fails, the procedure 3243 terminates, returning a failure indication and an appropriate reason. 3245 If i is not equal to n, continue by performing the preparatory steps 3246 listed in 6.1.4. If i is equal to n, perform the wrap-up steps 3247 listed in 6.1.5. 3249 6.1.4 Preparation for Certificate i+1 3251 To prepare for processing of certificate i+1, perform the following 3252 steps for certificate i: 3254 (a) If a policy mapping extension is present, verify that the 3255 special value any-policy does not appear as an issuerDomainPolicy 3256 or a subjectDomainPolicy. 3258 (b) If a policy mapping extension is present, then for each 3259 issuerDomainPolicy ID-P in the policy mapping extension: 3261 (1) If the policy_mapping variable is greater than 0, for each 3262 node in the valid_policy_tree of depth i where ID-P is the 3263 valid_policy, set expected_policy_set to the set of 3264 subjectDomainPolicy values that are specified as equivalent to 3265 ID-P by the policy mapping extension. 3267 If no node of depth i in the valid_policy_tree has a 3268 valid_policy of ID-P but there is a node of depth i with a 3269 valid_policy of any-policy, then generate a child node of the 3270 node of depth i-1 that has a valid_policy of any-policy as 3271 follows: 3273 (i) set the valid_policy to ID-P; 3275 (ii) set the qualifier_set to the qualifier set of the 3276 policy any-policy in the certificate policies extension of 3277 certificate i; 3279 (iii) set the criticality_indicator to the criticality of 3280 the certificate policies extension of certificate i; 3282 (iv) and set the expected_policy_set to the set of 3283 subjectDomainPolicy values that are specified as equivalent 3284 to ID-P by the policy mappings extension. 3286 (2) If the policy_mapping variable is equal to 0: 3288 (i) delete each node of depth i in the valid_policy_tree 3289 where ID-P is the valid_policy. 3291 (ii) If there is a node in the valid_policy_tree of depth 3292 i-1 or less without any child nodes, delete that node. 3293 Repeat this step until there are no nodes of depth i-1 or 3294 less without children. 3296 (c) Assign the certificate subject name to working_issuer_name. 3298 (d) Assign the certificate subjectPublicKey to working_public_key. 3300 (e) If the subjectPublicKeyInfo field of the certificate contains 3301 an algorithm field with non-null parameters, assign the parameters 3302 to the working_public_key_parameters variable. 3304 If the subjectPublicKeyInfo field of the certificate contains an 3305 algorithm field with null parameters or parameters are omitted, 3306 compare the certificate subjectPublicKey algorithm to the 3307 working_public_key_algorithm. If the certificate subjectPublicKey 3308 algorithm and the working_public_key_algorithm are different, set 3309 the working_public_key_parameters to null. 3311 (f) Assign the certificate subjectPublicKey algorithm to the 3312 working_public_key_algorithm variable. 3314 (g) If a name constraints extension is included in the 3315 certificate, modify the permitted_subtrees and excluded_subtrees 3316 state variables as follows: 3318 (1) If permittedSubtrees is present in the certificate, set the 3319 permitted_subtrees state variable to the intersection of its 3320 previous value and the value indicated in the extension field. 3321 If permittedSubtrees does not include a particular name type, 3322 the permitted_subtrees state variable is unchanged for that 3323 name type. 3325 (2) If excludedSubtrees is present in the certificate, set the 3326 excluded_subtrees state variable to the union of its previous 3327 value and the value indicated in the extension field. If 3328 excludedSubtrees does not include a particular name type, the 3329 excluded_subtrees state variable is unchanged for that name 3330 type. 3332 (h) If the issuer and subject names are not identical: 3334 (1) If explicit_policy is not 0, decrement explicit_policy by 3335 1. 3337 (2) If policy_mapping is not 0, decrement policy_mapping by 1. 3339 (3) If inhibit_any-policy is not 0, decrement inhibit_any- 3340 policy by 1. 3342 (i) If a policy constraints extension is included in the 3343 certificate, modify the explicit_policy and policy_mapping state 3344 variables as follows: 3346 (1) If requireExplicitPolicy is present and is less than 3347 explicit_policy, set explicit_policy to the value of 3348 requireExplicitPolicy. 3350 (2) If inhibitPolicyMapping is present and is less than 3351 policy_mapping, set policy_mapping to the value of 3352 inhibitPolicyMapping. 3354 (j) If the inhibitAnyPolicy extension is included in the 3355 certificate and is less than inhibit_any-policy, set inhibit_any- 3356 policy to the value of inhibitAnyPolicy. 3358 (k) Verify that the certificate is a CA certificate (as specified 3359 in a basicConstraints extension or as verified out-of-band). 3361 (l) If the certificate was not self-issued, verify that 3362 max_path_length is greater than zero and decrement max_path_length 3363 by 1. 3365 (m) If pathLengthConstraint is present in the certificate and is 3366 less than max_path_length, set max_path_length to the value of 3367 pathLengthConstraint. 3369 (n) If a key usage extension is present and marked critical, 3370 verify that the keyCertSign bit is set. 3372 (o) Recognize and process any other critical extension present in 3373 the certificate. 3375 If check (a), (k), (l), (n) or (o) fails, the procedure terminates, 3376 returning a failure indication and an appropriate reason. 3378 If (a), (k), (l), (n) and (o) have completed successfully, increment 3379 i and perform the basic certificate processing specified in 6.1.2. 3381 6.1.5 Wrap-up procedure 3383 To complete the processing of the end entity certificate, perform the 3384 following steps for certificate n: 3386 (a) If certificate n was not self-issued and explicit_policy is 3387 not 0, decrement explicit_policy by 1. 3389 (b) If a policy constraints extension is included in the 3390 certificate and requireExplicitPolicy is present and has a value 3391 of 0, set the explicit_policy state variable to 0. 3393 (c) Assign the certificate subjectPublicKey to working_public_key. 3395 (d) If the subjectPublicKeyInfo field of the certificate contains 3396 an algorithm field with non-null parameters, assign the parameters 3397 to the working_public_key_parameters variable. 3399 If the subjectPublicKeyInfo field of the certificate contains an 3400 algorithm field with null parameters or parameters are omitted, 3401 compare the certificate subjectPublicKey algorithm to the 3402 working_public_key_algorithm. If the certificate subjectPublicKey 3403 algorithm and the working_public_key_algorithm are different, set 3404 the working_public_key_parameters to null. 3406 (e) Assign the certificate subjectPublicKey algorithm to the 3407 working_public_key_algorithm variable. 3409 (f) Recognize and process any other critical extension present in 3410 the certificate n. 3412 (g) Calculate the intersection of the valid_policy_tree and the 3413 user-initial-policy-set, as follows: 3415 (i) If the valid_policy_tree is NULL, the intersection is NULL. 3417 (ii) If the valid_policy_tree is not NULL and the user-initial- 3418 policy-set is any-policy, the intersection is the entire 3419 valid_policy_tree. 3421 (iii) If the valid_policy_tree is not NULL and the user- 3422 initial-policy-set is not any-policy, calculate the 3423 intersection of the valid_policy_tree and the user-initial- 3424 policy-set as follows: 3426 1. Determine the set of policy nodes whose parent nodes have 3427 a valid_policy of any-policy. This is the 3428 valid_policy_node_set. 3430 2. If the valid_policy of any node in the 3431 valid_policy_node_set is not in the user-initial-policy-set 3432 and is not any-policy, delete this node and all its 3433 children. 3435 3. If there is a node in the valid_policy_tree of depth n-1 3436 or less without any child nodes, delete that node. Repeat 3437 this step until there are no nodes of depth n-1 or less 3438 without children. 3440 If either (1) the value of explicit_policy variable is greater than 3441 zero, or (2) the valid_policy_tree is not NULL, then path processing 3442 has succeeded. 3444 6.1.6 Outputs 3446 If path processing succeeds, the procedure terminates, returning a 3447 success indication together with final value of the 3448 valid_policy_tree, the working_public_key, the 3449 working_public_key_algorithm, and the working_public_key_parameters. 3451 6.2 Using the Path Validation Algorithm 3453 The path validation algorithm describes the process of validating a 3454 single certification path. While each path begins with a specific 3455 trust anchor, there is no requirement that all paths validated by a 3456 particular system share a single trust anchor. An implementation 3457 that supports multiple trust anchors may augment the algorithm 3458 prresented in section 6.1 to further limit the set of valid paths 3459 which begin with a particular trust anchor. For example, an 3460 implementation may specify name constraints that apply to a specific 3461 trust anchor. 3463 The selection of one or more trusted CAs is a local decision. A 3464 system may provide any one of its trusted CAs as the trust anchor for 3465 a particular path. The inputs to the path validation algorithm may 3466 be different for each path. The inputs used to process a path may 3467 reflect application-specific requirements or limitations in the trust 3468 accorded a particular trust anchor. For example, a trusted CA may 3469 only be trusted for a particular certificate policy. This 3470 restriction can be expressed through the inputs to the path 3471 validation procedure. 3473 It is also possible to specify an extended version of the above 3474 certification path processing procedure which results in default 3475 behavior identical to the rules of PEM [RFC 1422]. In this extended 3476 version, additional inputs to the procedure are a list of one or more 3477 Policy Certification Authorities (PCAs) names and an indicator of the 3478 position in the certification path where the PCA is expected. At the 3479 nominated PCA position, the CA name is compared against this list. 3480 If a recognized PCA name is found, then a constraint of 3481 SubordinateToCA is implicitly assumed for the remainder of the 3482 certification path and processing continues. If no valid PCA name is 3483 found, and if the certification path cannot be validated on the basis 3484 of identified policies, then the certification path is considered 3485 invalid. 3487 6.3 CRL Validation 3489 This section describes the steps necessary to determine if a 3490 certificate is revoked or on hold status when CRLs are the revocation 3491 mechanism used by the certificate issuer. Conforming implementations 3492 of this specification are not required to implement this algorithm, 3493 but MUST be functionally equivalent to the external behavior 3494 resulting from this procedure. Any algorithm may be used by a 3495 particular implementation so long as it derives the correct result. 3497 This algorithm defines a set of inputs, a set of state variables, and 3498 processing steps that are performed for each certificate in the path. 3500 6.3.1 Revocation Inputs 3502 To support revocation processing, the algorithm requires two inputs: 3504 (a) certificate: the algorithm requires the certificate serial 3505 number and issuer name to determine if a certificate is on a 3506 particular CRL. The basicConstraints extension is used to 3507 determine whether the supplied certificate is associated with a CA 3508 or an end-entity. If present, the algorithm may use the 3509 cRLDistributionsPoint and freshestCRL extensions to determine 3510 revocation status. 3512 (b) use-deltas: This boolean input determines if the delta needs 3513 to be checked if the CRL is still valid. 3515 Note that implementations supporting legacy PKIs, such as RFC 1422 3516 and X.509 version 1, will need an additional input indicating 3517 whether the supplied certificate is associated with a CA or an 3518 end-entity. 3520 6.3.2 Initialization and Revocation State Variables 3522 To support CRL processing, the algorithm requires the following state 3523 variables: 3525 (a) reasons_mask: This variable contains the set of revocation 3526 reasons supported by the CRLs and delta CRLs processed so far. 3527 The legal members of the set are the possible values for 3528 reasonflags: unspecified; keyCompromise; caCompromise; 3529 affiliationChanged; superseded; cessationOfOperation; and 3530 certificateHold. The special value all-reasons is used to denote 3531 the set of all legal members. This variable is initialized to the 3532 empty set. 3534 (b) cert_status: This variable contains the status of the 3535 certificate. Legal values are unspecified; keyCompromise; 3536 caCompromise; affiliationChanged; superseded; 3537 cessationOfOperation; and certificateHold, the special value 3538 UNREVOKED, or the special value UNDETERMINED. This variable is 3539 initialized to the special value UNREVOKED. 3541 (c) interim_reasons_mask: This contains the set of revocation 3542 reasons supported by the CRL or delta CRL currently being 3543 processed. 3545 Note: In some environments, it is not necessary to check all reason 3546 codes. For example, some envornments only are concerned with 3547 caCompromise and keyCompromise for CA certificates. This algorithnm 3548 checks all reason codes. Additional processing and state variables 3549 may be necessary to limit the checking to a subset of the reason 3550 codes. 3552 6.3.3 CRL Processing 3554 This algorithm begins by assuming the certificate is not revoked. 3555 The algorithm checks one or more CRLs until either the certificate 3556 status is determined to be revoked or sufficent CRLs have been 3557 checked to cover all reason codes. 3559 For each distribution point (DP) in the crl distribution points 3560 extension while ((reasons_mask is not all-reasons) and (cert_status 3561 is UNREVOKED)) 3563 (1) locate the corresponding CRL in CRL cache, and perform the 3564 following verifications: 3566 (a) compute the interim_reasons_mask for this CRL as follows: 3568 1. if the CRL includes reasons and the DP includes reasons, 3569 then set interim_reasons_mask to the intersection of of 3570 reasons in the DP and reasons in CRL reasons extension. 3572 2. if the CRL includes reasons but the DP omits reasons, 3573 then set interim_reasons_mask to the value of CRL reasons. 3575 3. if the CRL omits reasons but the DP includes reasons, 3576 then set interim_reasons_mask to the value of DP reasons. 3578 4. if the CRL omits reasons and the DP omits reasons, then 3579 set interim_reasons_mask to the special value all-reasons. 3581 Verify that interim_reasons_mask includes one or more reasons 3582 that is not included in the reasons_mask. 3584 (b) Verify the issuer of the CRL as follows: 3586 if the DP includes cRLIssuer, then verify that the CRL 3587 issuer matches cRLIssuer else verify that the CRL issuer 3588 matches the certificate issuer. 3590 (c) obtain and validate the certification path for the CRL 3591 issuer. 3593 (d) validate the signature on the CRL. 3595 (2) If each of the verifications (a) through (d) succeeds, then 3596 perform the following steps: 3598 (a) If the value of next update field is before the current- 3599 time, otain an appropriate delta CRL or discard the CRL. 3601 (b) If the user wants freshest available info AND the freshest 3602 CRL extension is present, check for a corresponding delta for 3603 this base. 3605 (c) If a delta was obtained in (a) or (b), verify that the 3606 delta CRL addresses the same set of certificates and the same 3607 set of reasons as the CRL. 3609 (d) Perform the checks in step 1 (b) and (c): 3611 1. obtain and validate the certification path for the delta 3612 issuer 3614 2. validate the signature on the delta CRL 3616 (e) If a delta CRL was obtained in (a) or (b), and the 3617 verifications (c) and (d) suceeded, combine the base and 3618 delta to form a complete CRL. 3620 (3) If steps and (1) and (2) succeed, then set reasons_mask to the 3621 union of reasons_mask and interim_reasons_mask 3623 (4) Search for the certificate on the CRL 3625 (a) search for the serial number on the CRL 3627 (b) if (a) succeeds, verify that (1) the CRL entry extension 3628 Certificate issuer is not present or (2) the issuer identified 3629 in the CRL entry extension Certificate issuer is the issuer of 3630 the certificate. 3632 (c) if (a) and (b) succeeded, set the cert_status variable as 3633 appropriate: 3635 1. if the reasons extension is present, set the cert_status 3636 variable to the value of the reasons extension 3638 2. if the reasons extension is not present, set the 3639 cert_status variable to the special value not-specified. 3641 if ((reasons_mask is all-reasons) OR (if cert_status is not 3642 UNREVOKED) return cert_status 3644 If all CRLs named in the crl distribution points extension have 3645 been exhausted, and the reasons_mask is not all-reasons and the 3646 cert_status is still UNREVOKED, the verifier must obtain 3647 additional CRLs. 3649 The verifier must repeat the process above with the additional 3650 CRLs not specified in a distribution point. 3652 If all CRLs are exhausted and the reasons_mask is not all-reasons 3653 return the cert_status UNDETERMINED. 3655 7 References 3657 [RFC 791] J. Postel, "Internet Protocol", September 1981. 3659 [RFC 822] D. Crocker, "Standard for the format of ARPA Internet text 3660 messages", August 1982. 3662 [RFC 1034] P.V. Mockapetris, "Domain names - concepts and 3663 facilities", November 1987. 3665 [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic 3666 Mail: Part II: Certificate-Based Key Management," RFC 3667 1422, BBN Communications, February 1993. 3669 [RFC 1423] Balenson, D., "Privacy Enhancement for Internet Electronic 3670 Mail: Part III: Algorithms, Modes, and Identifiers," 3671 RFC 1423, Trusted Information Systems, February 1993. 3673 [RFC 1510] Kohl, J., and C. Neuman, "The Kerberos Network 3674 Authentication Service (V5)," RFC 1510, September 1993. 3676 [RFC 1519] V. Fuller, T. Li, J. Yu, and K. Varadhan. "Classless 3677 Inter-Domain Routing (CIDR): an Address Assignment and 3678 Aggregation Strategy", September 1993. 3680 [RFC 1738] Berners-Lee, T., Masinter L., and M. McCahill. 3681 "Uniform Resource Locators (URL)", RFC 1738, December 1994. 3683 [RFC 1778] Howes, T., Kille S., Yeong, W. and C. Robbins. "The 3684 String Representation of Standard Attribute Syntaxes," 3685 RFC 1778, March 1995. 3687 [RFC 1883] S. Deering and R. Hinden. "Internet Protocol, Version 6 3688 (IPv6) Specification", December 1995. 3690 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 3691 Requirement Levels", March 1997. 3693 [RFC 2247] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. 3694 Sataluri. "Using Domains in LDAP/X.500 Distinguished Names", 3695 RFC 2247, January 1998. 3697 [RFC 2277] H. Alvestrand, "IETF Policy on Character Sets and 3698 Languages", January 1998. 3700 [RFC 2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646", 3701 January 1998. 3703 [RFC 2560] Myers, M., Ankney R., Malpani A., Galperin S., and 3704 C. Adams, "Online Certificate Status Protocal - OCSP", 3705 June 1999. 3707 [SDN.701] SDN.701, "Message Security Protocol 4.0", Revision A 3708 1997-02-06. 3710 [X.208] CCITT Recommendation X.208: Specification of Abstract 3711 Syntax Notation One (ASN.1), 1988. 3713 [X.501] ITU-T Recommendation X.501: Information 3714 Technology - Open Systems Interconnection - The 3715 Directory: Models, 1993. 3717 [X.509] ITU-T Recommendation X.509 (1997 E): Information 3718 Technology - Open Systems Interconnection - The 3719 Directory: Authentication Framework, June 1997. 3721 [X.520] ITU-T Recommendation X.520: Information 3722 Technology - Open Systems Interconnection - The 3723 Directory: Selected Attribute Types, 1993. 3725 [X9.55] ANSI X9.55-1995, Public Key Cryptography For The Financial 3726 Services Industry: Extensions To Public Key Certificates 3727 And Certificate Revocation Lists, 8 December, 1995. 3729 [PKINIT] Tung, B., Neuman C., Hur M., Medvinsky A., Medvinsky S., 3730 Wray J., and J. Trostle, "Public Key Cryptography for 3731 Initial Authentciaion in Kerberos," 3732 draft-ietf-cat-kerberos-pk-init-11.txt, March 15, 2000. 3734 [PKIX ALGS] Bassham, L., Housley, R., and W. Polk, "Internet X.509 3735 Public Key Infrastructure Representation of Public Keys 3736 and Digital Signatures," 3737 draft-ietf-pkix-ipki-pkalgs-00.txt, July 14, 2000. 3739 [PKIX TSA] Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 3740 Public Key Infrastructure Time Stamp Protocol," 3741 draft-ietf-pkix-time-stamp-12.txt, November, 2000. 3743 8 Intellectual Property Rights 3745 The IETF has been notified of intellectual property rights claimed in 3746 regard to some or all of the specification contained in this 3747 document. For more information consult the online list of claimed 3748 rights. 3750 The IETF takes no position regarding the validity or scope of any 3751 intellectual property or other rights that might be claimed to 3752 pertain to the implementation or use of the technology described in 3753 this document or the extent to which any license under such rights 3754 might or might not be available; neither does it represent that it 3755 has made any effort to identify any such rights. Information on the 3756 IETF's procedures with respect to rights in standards-track and 3757 standards-related documentation can be found in BCP-11. Copies of 3758 claims of rights made available for publication and any assurances of 3759 licenses to be made available, or the result of an attempt made to 3760 obtain a general license or permission for the use of such 3761 proprietary rights by implementors or users of this specification can 3762 be obtained from the IETF Secretariat. 3764 9 Security Considerations 3766 The majority of this specification is devoted to the format and 3767 content of certificates and CRLs. Since certificates and CRLs are 3768 digitally signed, no additional integrity service is necessary. 3769 Neither certificates nor CRLs need be kept secret, and unrestricted 3770 and anonymous access to certificates and CRLs has no security 3771 implications. 3773 However, security factors outside the scope of this specification 3774 will affect the assurance provided to certificate users. This 3775 section highlights critical issues that should be considered by 3776 implementors, administrators, and users. 3778 The procedures performed by CAs and RAs to validate the binding of 3779 the subject's identity of their public key greatly affect the 3780 assurance that should be placed in the certificate. Relying parties 3781 may wish to review the CA's certificate practice statement. This may 3782 be particularly important when issuing certificates to other CAs. 3784 The use of a single key pair for both signature and other purposes is 3785 strongly discouraged. Use of separate key pairs for signature and key 3786 management provides several benefits to the users. The ramifications 3787 associated with loss or disclosure of a signature key are different 3788 from loss or disclosure of a key management key. Using separate key 3789 pairs permits a balanced and flexible response. Similarly, different 3790 validity periods or key lengths for each key pair may be appropriate 3791 in some application environments. Unfortunately, some legacy 3792 applications (e.g., SSL) use a single key pair for signature and key 3793 management. 3795 The protection afforded private keys is a critical factor in 3796 maintaining security. On a small scale, failure of users to protect 3797 their private keys will permit an attacker to masquerade as them, or 3798 decrypt their personal information. On a larger scale, compromise of 3799 a CA's private signing key may have a catastrophic effect. If an 3800 attacker obtains the private key unnoticed, the attacker may issue 3801 bogus certificates and CRLs. Existence of bogus certificates and 3802 CRLs will undermine confidence in the system. If the compromise is 3803 detected, all certificates issued to the CA MUST be revoked, 3804 preventing services between its users and users of other CAs. 3805 Rebuilding after such a compromise will be problematic, so CAs are 3806 advised to implement a combination of strong technical measures 3807 (e.g., tamper-resistant cryptographic modules) and appropriate 3808 management procedures (e.g., separation of duties) to avoid such an 3809 incident. 3811 Loss of a CA's private signing key may also be problematic. The CA 3812 would not be able to produce CRLs or perform normal key rollover. 3813 CAs are advised to maintain secure backup for signing keys. The 3814 security of the key backup procedures is a critical factor in 3815 avoiding key compromise. 3817 The availability and freshness of revocation information will affect 3818 the degree of assurance that should be placed in a certificate. 3819 While certificates expire naturally, events may occur during its 3820 natural lifetime which negate the binding between the subject and 3821 public key. If revocation information is untimely or unavailable, 3822 the assurance associated with the binding is clearly reduced. 3823 Similarly, implementations of the Path Validation mechanism described 3824 in section 6 that omit revocation checking provide less assurance 3825 than those that support it. 3827 The path validation algorithm depends on the certain knowledge of the 3828 public keys (and other information) about one or more trusted CAs. 3829 The decision to trust a CA is an important decision as it ultimately 3830 determines the trust afforded a certificate. The authenticated 3831 distribution of trusted CA public keys (usually in the form of a 3832 "self-signed" certificate) is a security critical out of band process 3833 that is beyond the scope of this specification. 3835 In addition, where a key compromise or CA failure occurs for a 3836 trusted CA, the user will need to modify the information provided to 3837 the path validation routine. Selection of too many trusted CAs will 3838 make the trusted CA information difficult to maintain. On the other 3839 hand, selection of only one trusted CA may limit users to a closed 3840 community of users until a global PKI emerges. 3842 The quality of implementations that process certificates may also 3843 affect the degree of assurance provided. The path validation 3844 algorithm described in section 6 relies upon the integrity of the 3845 trusted CA information, and especially the integrity of the public 3846 keys associated with the trusted CAs. By substituting public keys 3847 for which an attacker has the private key, an attacker could trick 3848 the user into accepting false certificates. 3850 The binding between a key and certificate subject cannot be stronger 3851 than the cryptographic module implementation and algorithms used to 3852 generate the signature. Short key lengths or weak hash algorithms 3853 will limit the utility of a certificate. CAs are encouraged to note 3854 advances in cryptology so they can employ strong cryptographic 3855 techniques. In addition, CAs should decline to issue certificates to 3856 CAs or end entities that generate weak signatures. 3858 Inconsistent application of name comparison rules may result in 3859 acceptance of invalid X.509 certification paths, or rejection of 3860 valid ones. The X.500 series of specifications defines rules for 3861 comparing distinguished names require comparison of strings without 3862 regard to case, character set, multi-character white space substring, 3863 or leading and trailing white space. This specification relaxes 3864 these requirements, requiring support for binary comparison at a 3865 minimum. 3867 CAs MUST encode the distinguished name in the subject field of a CA 3868 certificate identically to the distinguished name in the issuer field 3869 in certificates issued by the latter CA. If CAs use different 3870 encodings, implementations of this specification may fail to 3871 recognize name chains for paths that include this certificate. As a 3872 consequence, valid paths could be rejected. 3874 In addition, name constraints for distinguished names MUST be stated 3875 identically to the encoding used in the subject field or 3876 subjectAltName extension. If not, (1) name constraints stated as 3877 excludedSubTrees will not match and invalid paths will be accepted 3878 and (2) name constraints expressed as permittedSubtrees will not 3879 match and valid paths will be rejected. To avoid acceptance of 3880 invalid paths, CAs should state name constraints for distinguished 3881 names as permittedSubtrees where ever possible. 3883 Appendix A. Psuedo-ASN.1 Structures and OIDs 3885 This section describes data objects used by conforming PKI components 3886 in an "ASN.1-like" syntax. This syntax is a hybrid of the 1988 and 3887 1993 ASN.1 syntaxes. The 1988 ASN.1 syntax is augmented with 1993 3888 UNIVERSAL Types UniversalString, BMPString and UTF8String. 3890 The ASN.1 syntax does not permit the inclusion of type statements in 3891 the ASN.1 module, and the 1993 ASN.1 standard does not permit use of 3892 the new UNIVERSAL types in modules using the 1988 syntax. As a 3893 result, this module does not conform to either version of the ASN.1 3894 standard. 3896 This appendix may be converted into 1988 ASN.1 by replacing the 3897 defintions for the UNIVERSAL Types with the 1988 catch-all "ANY". 3899 A.1 Explicitly Tagged Module, 1988 Syntax 3901 PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) 3902 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18)} 3904 DEFINITIONS EXPLICIT TAGS ::= 3906 BEGIN 3908 -- EXPORTS ALL -- 3910 -- IMPORTS NONE -- 3912 -- UNIVERSAL Types defined in '93 and '98 ASN.1 3913 -- but required by this specification 3915 UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING 3916 -- UniversalString is defined in ASN.1:1993 3918 BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING 3919 -- BMPString is the subtype of UniversalString and models 3920 -- the Basic Multilingual Plane of ISO/IEC/ITU 10646-1 3922 UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 3923 -- The content of this type conforms to RFC 2279. 3925 -- 3926 -- PKIX specific OIDs 3928 id-pkix OBJECT IDENTIFIER ::= 3929 { iso(1) identified-organization(3) dod(6) internet(1) 3930 security(5) mechanisms(5) pkix(7) } 3931 -- PKIX arcs 3933 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 3934 -- arc for private certificate extensions 3935 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 3936 -- arc for policy qualifier types 3937 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 3938 -- arc for extended key purpose OIDS 3939 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 3940 -- arc for access descriptors 3942 -- policyQualifierIds for Internet policy qualifiers 3944 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 3945 -- OID for CPS qualifier 3946 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 3947 -- OID for user notice qualifier 3949 -- access descriptor definitions 3951 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 3952 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 3953 id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 } 3954 id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 } 3956 -- attribute data types -- 3958 Attribute ::= SEQUENCE { 3959 type AttributeType, 3960 values SET OF AttributeValue 3961 -- at least one value is required -- } 3963 AttributeType ::= OBJECT IDENTIFIER 3965 AttributeValue ::= ANY 3967 AttributeTypeAndValue ::= SEQUENCE { 3968 type AttributeType, 3969 value AttributeValue } 3971 -- suggested naming attributes: Definition of the following 3972 -- information object set may be augmented to meet local 3973 -- requirements. Note that deleting members of the set may 3974 -- prevent interoperability with conforming implementations. 3975 -- presented in pairs: the AttributeType followed by the 3976 -- type definition for the corresponding AttributeValue 3977 --Arc for standard naming attributes 3978 id-at OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 4} 3980 -- Naming attributes of type X520name 3982 id-at-name AttributeType ::= {id-at 41} 3983 id-at-surname AttributeType ::= {id-at 4} 3984 id-at-givenName AttributeType ::= {id-at 42} 3985 id-at-initials AttributeType ::= {id-at 43} 3986 id-at-generationQualifier AttributeType ::= {id-at 44} 3988 X520name ::= CHOICE { 3989 teletexString TeletexString (SIZE (1..ub-name)), 3990 printableString PrintableString (SIZE (1..ub-name)), 3991 universalString UniversalString (SIZE (1..ub-name)), 3992 utf8String UTF8String (SIZE (1..ub-name)), 3993 bmpString BMPString (SIZE(1..ub-name)) } 3995 -- Naming attributes of type X520CommonName 3997 id-at-commonName AttributeType ::= {id-at 3} 3999 X520CommonName ::= CHOICE { 4000 teletexString TeletexString (SIZE (1..ub-common-name)), 4001 printableString PrintableString (SIZE (1..ub-common-name)), 4002 universalString UniversalString (SIZE (1..ub-common-name)), 4003 utf8String UTF8String (SIZE (1..ub-common-name)), 4004 bmpString BMPString (SIZE(1..ub-common-name)) } 4006 -- Naming attributes of type X520LocalityName 4008 id-at-localityName AttributeType ::= {id-at 7} 4010 X520LocalityName ::= CHOICE { 4011 teletexString TeletexString (SIZE (1..ub-locality-name)), 4012 printableString PrintableString (SIZE (1..ub-locality-name)), 4013 universalString UniversalString (SIZE (1..ub-locality-name)), 4014 utf8String UTF8String (SIZE (1..ub-locality-name)), 4015 bmpString BMPString (SIZE(1..ub-locality-name)) } 4017 -- Naming attributes of type X520StateOrProvinceName 4019 id-at-stateOrProvinceName AttributeType ::= {id-at 8} 4021 X520StateOrProvinceName ::= CHOICE { 4022 teletexString TeletexString (SIZE (1..ub-state-name)), 4023 printableString PrintableString (SIZE (1..ub-state-name)), 4024 universalString UniversalString (SIZE (1..ub-state-name)), 4025 utf8String UTF8String (SIZE (1..ub-state-name)), 4026 bmpString BMPString (SIZE(1..ub-state-name)) } 4028 -- Naming attributes of type X520OrganizationName 4030 id-at-organizationName AttributeType ::= {id-at 10} 4032 X520OrganizationName ::= CHOICE { 4033 teletexString TeletexString (SIZE (1..ub-organization-name)), 4034 printableString PrintableString (SIZE (1..ub-organization-name)), 4035 universalString UniversalString (SIZE (1..ub-organization-name)), 4036 utf8String UTF8String (SIZE (1..ub-organization-name)), 4037 bmpString BMPString (SIZE(1..ub-organization-name)) } 4039 -- Naming attributes of type X520OrganizationalUnitName 4041 id-at-organizationalUnitName AttributeType ::= {id-at 11} 4043 X520OrganizationalUnitName ::= CHOICE { 4044 teletexString TeletexString (SIZE (1..ub-organizational-unit-name)), 4045 printableString PrintableString 4046 (SIZE (1..ub-organizational-unit-name)), 4047 universalString UniversalString 4048 (SIZE (1..ub-organizational-unit-name)), 4049 utf8String UTF8String (SIZE (1..ub-organizational-unit-name)), 4050 bmpString BMPString (SIZE(1..ub-organizational-unit-name)) } 4052 -- Naming attributes of type X520Title 4054 id-at-title AttributeType ::= {id-at 12} 4056 X520Title ::= CHOICE { 4057 teletexString TeletexString (SIZE (1..ub-title)), 4058 printableString PrintableString (SIZE (1..ub-title)), 4059 universalString UniversalString (SIZE (1..ub-title)), 4060 utf8String UTF8String (SIZE (1..ub-title)), 4061 bmpString BMPString (SIZE(1..ub-title)) } 4063 -- Naming attributes of type X520dnQualifier 4065 id-at-dnQualifier AttributeType ::= {id-at 46} 4067 X520dnQualifier ::= PrintableString 4069 -- Naming attributes of type X520countryName 4071 id-at-countryName AttributeType ::= {id-at 6} 4072 X520countryName ::= PrintableString (SIZE (2)) -- IS 3166 codes 4074 -- Naming attributes of type X520SerialNumber 4076 id-at-serialNumber AttributeType ::= { id-at 5 } 4078 X520SerialNumber ::= PrintableString (SIZE (1..ub-serial-number)) 4080 -- Naming attributes of type DomainComponent (from RFC 2247) 4082 id-domainComponent OBJECT IDENTIFIER ::= 4083 { 0 9 2342 19200300 100 1 25 } 4085 DomainComponent ::= IA5String 4087 -- Legacy attributes 4089 pkcs-9 OBJECT IDENTIFIER ::= 4090 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 } 4092 id-emailAddress AttributeType ::= { pkcs-9 1 } 4094 EmailAddress ::= IA5String (SIZE (1..ub-emailaddress-length)) 4096 -- naming data types -- 4098 Name ::= CHOICE { -- only one possibility for now -- 4099 rdnSequence RDNSequence } 4101 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 4103 DistinguishedName ::= RDNSequence 4105 RelativeDistinguishedName ::= 4106 SET SIZE (1 .. MAX) OF AttributeTypeAndValue 4108 -- Directory string type -- 4110 DirectoryString ::= CHOICE { 4111 teletexString TeletexString (SIZE (1..MAX)), 4112 printableString PrintableString (SIZE (1..MAX)), 4113 universalString UniversalString (SIZE (1..MAX)), 4114 utf8String UTF8String (SIZE (1..MAX)), 4115 bmpString BMPString (SIZE(1..MAX)) } 4117 -- certificate and CRL specific structures begin here 4119 Certificate ::= SEQUENCE { 4120 tbsCertificate TBSCertificate, 4121 signatureAlgorithm AlgorithmIdentifier, 4122 signature BIT STRING } 4124 TBSCertificate ::= SEQUENCE { 4125 version [0] Version DEFAULT v1, 4126 serialNumber CertificateSerialNumber, 4127 signature AlgorithmIdentifier, 4128 issuer Name, 4129 validity Validity, 4130 subject Name, 4131 subjectPublicKeyInfo SubjectPublicKeyInfo, 4132 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 4133 -- If present, version MUST be v2 or v3 4134 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 4135 -- If present, version MUST be v2 or v3 4136 extensions [3] Extensions OPTIONAL 4137 -- If present, version MUST be v3 -- } 4139 Version ::= INTEGER { v1(0), v2(1), v3(2) } 4141 CertificateSerialNumber ::= INTEGER 4143 Validity ::= SEQUENCE { 4144 notBefore Time, 4145 notAfter Time } 4147 Time ::= CHOICE { 4148 utcTime UTCTime, 4149 generalTime GeneralizedTime } 4151 UniqueIdentifier ::= BIT STRING 4153 SubjectPublicKeyInfo ::= SEQUENCE { 4154 algorithm AlgorithmIdentifier, 4155 subjectPublicKey BIT STRING } 4157 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 4159 Extension ::= SEQUENCE { 4160 extnID OBJECT IDENTIFIER, 4161 critical BOOLEAN DEFAULT FALSE, 4162 extnValue OCTET STRING } 4164 -- CRL structures 4166 CertificateList ::= SEQUENCE { 4167 tbsCertList TBSCertList, 4168 signatureAlgorithm AlgorithmIdentifier, 4169 signature BIT STRING } 4171 TBSCertList ::= SEQUENCE { 4172 version Version OPTIONAL, 4173 -- if present, MUST be v2 4174 signature AlgorithmIdentifier, 4175 issuer Name, 4176 thisUpdate Time, 4177 nextUpdate Time OPTIONAL, 4178 revokedCertificates SEQUENCE OF SEQUENCE { 4179 userCertificate CertificateSerialNumber, 4180 revocationDate Time, 4181 crlEntryExtensions Extensions OPTIONAL 4182 -- if present, MUST be v2 4183 } OPTIONAL, 4184 crlExtensions [0] Extensions OPTIONAL 4185 -- if present, MUST be v2 -- } 4187 -- Version, Time, CertificateSerialNumber, and Extensions were 4188 -- defined earlier for use in the certificate structure 4190 AlgorithmIdentifier ::= SEQUENCE { 4191 algorithm OBJECT IDENTIFIER, 4192 parameters ANY DEFINED BY algorithm OPTIONAL } 4193 -- contains a value of the type 4194 -- registered for use with the 4195 -- algorithm object identifier value 4197 -- x400 address syntax starts here 4198 -- OR Names 4200 ORAddress ::= SEQUENCE { 4201 built-in-standard-attributes BuiltInStandardAttributes, 4202 built-in-domain-defined-attributes 4203 BuiltInDomainDefinedAttributes OPTIONAL, 4204 -- see also teletex-domain-defined-attributes 4205 extension-attributes ExtensionAttributes OPTIONAL } 4206 -- The OR-address is semantically absent from the OR-name if the 4207 -- built-in-standard-attribute sequence is empty and the 4208 -- built-in-domain-defined-attributes and extension-attributes are 4209 -- both omitted. 4211 -- Built-in Standard Attributes 4213 BuiltInStandardAttributes ::= SEQUENCE { 4214 country-name CountryName OPTIONAL, 4215 administration-domain-name AdministrationDomainName OPTIONAL, 4216 network-address [0] NetworkAddress OPTIONAL, 4217 -- see also extended-network-address 4218 terminal-identifier [1] TerminalIdentifier OPTIONAL, 4219 private-domain-name [2] PrivateDomainName OPTIONAL, 4220 organization-name [3] OrganizationName OPTIONAL, 4221 -- see also teletex-organization-name 4222 numeric-user-identifier [4] NumericUserIdentifier OPTIONAL, 4223 personal-name [5] PersonalName OPTIONAL, 4224 -- see also teletex-personal-name 4225 organizational-unit-names [6] OrganizationalUnitNames OPTIONAL 4226 -- see also teletex-organizational-unit-names -- } 4228 CountryName ::= [APPLICATION 1] CHOICE { 4229 x121-dcc-code NumericString 4230 (SIZE (ub-country-name-numeric-length)), 4231 iso-3166-alpha2-code PrintableString 4232 (SIZE (ub-country-name-alpha-length)) } 4234 AdministrationDomainName ::= [APPLICATION 2] CHOICE { 4235 numeric NumericString (SIZE (0..ub-domain-name-length)), 4236 printable PrintableString (SIZE (0..ub-domain-name-length)) } 4238 NetworkAddress ::= X121Address -- see also extended-network-address 4240 X121Address ::= NumericString (SIZE (1..ub-x121-address-length)) 4242 TerminalIdentifier ::= PrintableString (SIZE (1..ub-terminal-id-length)) 4244 PrivateDomainName ::= CHOICE { 4245 numeric NumericString (SIZE (1..ub-domain-name-length)), 4246 printable PrintableString (SIZE (1..ub-domain-name-length)) } 4248 OrganizationName ::= PrintableString 4249 (SIZE (1..ub-organization-name-length)) 4250 -- see also teletex-organization-name 4252 NumericUserIdentifier ::= NumericString 4253 (SIZE (1..ub-numeric-user-id-length)) 4255 PersonalName ::= SET { 4256 surname [0] PrintableString (SIZE (1..ub-surname-length)), 4257 given-name [1] PrintableString 4258 (SIZE (1..ub-given-name-length)) OPTIONAL, 4259 initials [2] PrintableString (SIZE (1..ub-initials-length)) OPTIONAL, 4260 generation-qualifier [3] PrintableString 4261 (SIZE (1..ub-generation-qualifier-length)) OPTIONAL } 4262 -- see also teletex-personal-name 4263 OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units) 4264 OF OrganizationalUnitName 4265 -- see also teletex-organizational-unit-names 4267 OrganizationalUnitName ::= PrintableString (SIZE 4268 (1..ub-organizational-unit-name-length)) 4270 -- Built-in Domain-defined Attributes 4272 BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE 4273 (1..ub-domain-defined-attributes) OF 4274 BuiltInDomainDefinedAttribute 4276 BuiltInDomainDefinedAttribute ::= SEQUENCE { 4277 type PrintableString (SIZE 4278 (1..ub-domain-defined-attribute-type-length)), 4279 value PrintableString (SIZE 4280 (1..ub-domain-defined-attribute-value-length))} 4282 -- Extension Attributes 4284 ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF 4285 ExtensionAttribute 4287 ExtensionAttribute ::= SEQUENCE { 4288 extension-attribute-type [0] INTEGER (0..ub-extension-attributes), 4289 extension-attribute-value [1] 4290 ANY DEFINED BY extension-attribute-type } 4292 -- Extension types and attribute values 4293 -- 4295 common-name INTEGER ::= 1 4297 CommonName ::= PrintableString (SIZE (1..ub-common-name-length)) 4299 teletex-common-name INTEGER ::= 2 4301 TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length)) 4303 teletex-organization-name INTEGER ::= 3 4305 TeletexOrganizationName ::= 4306 TeletexString (SIZE (1..ub-organization-name-length)) 4308 teletex-personal-name INTEGER ::= 4 4310 TeletexPersonalName ::= SET { 4311 surname [0] TeletexString (SIZE (1..ub-surname-length)), 4312 given-name [1] TeletexString 4313 (SIZE (1..ub-given-name-length)) OPTIONAL, 4314 initials [2] TeletexString (SIZE (1..ub-initials-length)) OPTIONAL, 4315 generation-qualifier [3] TeletexString (SIZE 4316 (1..ub-generation-qualifier-length)) OPTIONAL } 4318 teletex-organizational-unit-names INTEGER ::= 5 4320 TeletexOrganizationalUnitNames ::= SEQUENCE SIZE 4321 (1..ub-organizational-units) OF TeletexOrganizationalUnitName 4323 TeletexOrganizationalUnitName ::= TeletexString 4324 (SIZE (1..ub-organizational-unit-name-length)) 4326 pds-name INTEGER ::= 7 4328 PDSName ::= PrintableString (SIZE (1..ub-pds-name-length)) 4330 physical-delivery-country-name INTEGER ::= 8 4332 PhysicalDeliveryCountryName ::= CHOICE { 4333 x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)), 4334 iso-3166-alpha2-code PrintableString 4335 (SIZE (ub-country-name-alpha-length)) } 4337 postal-code INTEGER ::= 9 4339 PostalCode ::= CHOICE { 4340 numeric-code NumericString (SIZE (1..ub-postal-code-length)), 4341 printable-code PrintableString (SIZE (1..ub-postal-code-length)) } 4343 physical-delivery-office-name INTEGER ::= 10 4345 PhysicalDeliveryOfficeName ::= PDSParameter 4347 physical-delivery-office-number INTEGER ::= 11 4349 PhysicalDeliveryOfficeNumber ::= PDSParameter 4351 extension-OR-address-components INTEGER ::= 12 4353 ExtensionORAddressComponents ::= PDSParameter 4355 physical-delivery-personal-name INTEGER ::= 13 4357 PhysicalDeliveryPersonalName ::= PDSParameter 4358 physical-delivery-organization-name INTEGER ::= 14 4360 PhysicalDeliveryOrganizationName ::= PDSParameter 4362 extension-physical-delivery-address-components INTEGER ::= 15 4364 ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter 4366 unformatted-postal-address INTEGER ::= 16 4368 UnformattedPostalAddress ::= SET { 4369 printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) OF 4370 PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL, 4371 teletex-string TeletexString 4372 (SIZE (1..ub-unformatted-address-length)) OPTIONAL } 4374 street-address INTEGER ::= 17 4376 StreetAddress ::= PDSParameter 4378 post-office-box-address INTEGER ::= 18 4380 PostOfficeBoxAddress ::= PDSParameter 4382 poste-restante-address INTEGER ::= 19 4384 PosteRestanteAddress ::= PDSParameter 4386 unique-postal-name INTEGER ::= 20 4388 UniquePostalName ::= PDSParameter 4390 local-postal-attributes INTEGER ::= 21 4392 LocalPostalAttributes ::= PDSParameter 4394 PDSParameter ::= SET { 4395 printable-string PrintableString 4396 (SIZE(1..ub-pds-parameter-length)) OPTIONAL, 4397 teletex-string TeletexString 4398 (SIZE(1..ub-pds-parameter-length)) OPTIONAL } 4400 extended-network-address INTEGER ::= 22 4402 ExtendedNetworkAddress ::= CHOICE { 4403 e163-4-address SEQUENCE { 4404 number [0] NumericString (SIZE (1..ub-e163-4-number-length)), 4405 sub-address [1] NumericString 4406 (SIZE (1..ub-e163-4-sub-address-length)) OPTIONAL }, 4407 psap-address [0] PresentationAddress } 4409 PresentationAddress ::= SEQUENCE { 4410 pSelector [0] EXPLICIT OCTET STRING OPTIONAL, 4411 sSelector [1] EXPLICIT OCTET STRING OPTIONAL, 4412 tSelector [2] EXPLICIT OCTET STRING OPTIONAL, 4413 nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING } 4415 terminal-type INTEGER ::= 23 4417 TerminalType ::= INTEGER { 4418 telex (3), 4419 teletex (4), 4420 g3-facsimile (5), 4421 g4-facsimile (6), 4422 ia5-terminal (7), 4423 videotex (8) } (0..ub-integer-options) 4425 -- Extension Domain-defined Attributes 4427 teletex-domain-defined-attributes INTEGER ::= 6 4429 TeletexDomainDefinedAttributes ::= SEQUENCE SIZE 4430 (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute 4432 TeletexDomainDefinedAttribute ::= SEQUENCE { 4433 type TeletexString 4434 (SIZE (1..ub-domain-defined-attribute-type-length)), 4435 value TeletexString 4436 (SIZE (1..ub-domain-defined-attribute-value-length)) } 4438 -- specifications of Upper Bounds MUST be regarded as mandatory 4439 -- from Annex B of ITU-T X.411 Reference Definition of MTS Parameter 4440 -- Upper Bounds 4442 -- Upper Bounds 4443 ub-name INTEGER ::= 32768 4444 ub-common-name INTEGER ::= 64 4445 ub-locality-name INTEGER ::= 128 4446 ub-state-name INTEGER ::= 128 4447 ub-organization-name INTEGER ::= 64 4448 ub-organizational-unit-name INTEGER ::= 64 4449 ub-title INTEGER ::= 64 4450 ub-serial-number INTEGER ::= 64 4451 ub-match INTEGER ::= 128 4452 ub-emailaddress-length INTEGER ::= 128 4453 ub-common-name-length INTEGER ::= 64 4454 ub-country-name-alpha-length INTEGER ::= 2 4455 ub-country-name-numeric-length INTEGER ::= 3 4456 ub-domain-defined-attributes INTEGER ::= 4 4457 ub-domain-defined-attribute-type-length INTEGER ::= 8 4458 ub-domain-defined-attribute-value-length INTEGER ::= 128 4459 ub-domain-name-length INTEGER ::= 16 4460 ub-extension-attributes INTEGER ::= 256 4461 ub-e163-4-number-length INTEGER ::= 15 4462 ub-e163-4-sub-address-length INTEGER ::= 40 4463 ub-generation-qualifier-length INTEGER ::= 3 4464 ub-given-name-length INTEGER ::= 16 4465 ub-initials-length INTEGER ::= 5 4466 ub-integer-options INTEGER ::= 256 4467 ub-numeric-user-id-length INTEGER ::= 32 4468 ub-organization-name-length INTEGER ::= 64 4469 ub-organizational-unit-name-length INTEGER ::= 32 4470 ub-organizational-units INTEGER ::= 4 4471 ub-pds-name-length INTEGER ::= 16 4472 ub-pds-parameter-length INTEGER ::= 30 4473 ub-pds-physical-address-lines INTEGER ::= 6 4474 ub-postal-code-length INTEGER ::= 16 4475 ub-surname-length INTEGER ::= 40 4476 ub-terminal-id-length INTEGER ::= 24 4477 ub-unformatted-address-length INTEGER ::= 180 4478 ub-x121-address-length INTEGER ::= 16 4480 -- Note - upper bounds on string types, such as TeletexString, are 4481 -- measured in characters. Excepting PrintableString or IA5String, a 4482 -- significantly greater number of octets will be required to hold 4483 -- such a value. As a minimum, 16 octets, or twice the specified upper 4484 -- bound, whichever is the larger, should be allowed for TeletexString. 4485 -- For UTF8String or UniversalString at least four times the upper 4486 -- bound should be allowed. 4488 END 4489 A.2 Implicitly Tagged Module, 1988 Syntax 4491 PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) 4492 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19)} 4494 DEFINITIONS IMPLICIT TAGS ::= 4496 BEGIN 4498 -- EXPORTS ALL -- 4500 IMPORTS 4501 id-pe, id-kp, id-qt-unotice, id-qt-cps, id-ad, 4502 -- delete following line if "new" types are supported -- 4503 BMPString, UTF8String, -- end "new" types -- 4504 ORAddress, Name, RelativeDistinguishedName, 4505 CertificateSerialNumber, Attribute, DirectoryString 4506 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 4507 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 4508 id-mod(0) id-pkix1-explicit(18)}; 4510 -- ISO arc for standard certificate and CRL extensions 4512 id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 4514 -- authority key identifier OID and syntax 4516 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 4518 AuthorityKeyIdentifier ::= SEQUENCE { 4519 keyIdentifier [0] KeyIdentifier OPTIONAL, 4520 authorityCertIssuer [1] GeneralNames OPTIONAL, 4521 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 4522 -- authorityCertIssuer and authorityCertSerialNumber MUST both 4523 -- be present or both be absent 4525 KeyIdentifier ::= OCTET STRING 4527 -- subject key identifier OID and syntax 4529 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 4531 SubjectKeyIdentifier ::= KeyIdentifier 4533 -- key usage extension OID and syntax 4535 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 4536 KeyUsage ::= BIT STRING { 4537 digitalSignature (0), 4538 nonRepudiation (1), 4539 keyEncipherment (2), 4540 dataEncipherment (3), 4541 keyAgreement (4), 4542 keyCertSign (5), 4543 cRLSign (6), 4544 encipherOnly (7), 4545 decipherOnly (8) } 4547 -- private key usage period extension OID and syntax 4549 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 4551 PrivateKeyUsagePeriod ::= SEQUENCE { 4552 notBefore [0] GeneralizedTime OPTIONAL, 4553 notAfter [1] GeneralizedTime OPTIONAL } 4554 -- either notBefore or notAfter MUST be present 4556 -- certificate policies extension OID and syntax 4558 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 4560 anyPolicy OBJECT IDENTIFIER ::= {id-ce-certificatePolicies 0} 4562 CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 4564 PolicyInformation ::= SEQUENCE { 4565 policyIdentifier CertPolicyId, 4566 policyQualifiers SEQUENCE SIZE (1..MAX) OF 4567 PolicyQualifierInfo OPTIONAL } 4569 CertPolicyId ::= OBJECT IDENTIFIER 4571 PolicyQualifierInfo ::= SEQUENCE { 4572 policyQualifierId PolicyQualifierId, 4573 qualifier ANY DEFINED BY policyQualifierId } 4575 -- Implementations that recognize additional policy qualifiers MUST 4576 -- augment the following definition for PolicyQualifierId 4578 PolicyQualifierId ::= 4579 OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) 4581 -- CPS pointer qualifier 4583 CPSuri ::= IA5String 4584 -- user notice qualifier 4586 UserNotice ::= SEQUENCE { 4587 noticeRef NoticeReference OPTIONAL, 4588 explicitText DisplayText OPTIONAL} 4590 NoticeReference ::= SEQUENCE { 4591 organization DisplayText, 4592 noticeNumbers SEQUENCE OF INTEGER } 4594 DisplayText ::= CHOICE { 4595 ia5String IA5String (SIZE (1..200)), 4596 visibleString VisibleString (SIZE (1..200)), 4597 bmpString BMPString (SIZE (1..200)), 4598 utf8String UTF8String (SIZE (1..200)) } 4600 -- policy mapping extension OID and syntax 4602 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 4604 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 4605 issuerDomainPolicy CertPolicyId, 4606 subjectDomainPolicy CertPolicyId } 4608 -- subject alternative name extension OID and syntax 4610 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 4612 SubjectAltName ::= GeneralNames 4614 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 4616 GeneralName ::= CHOICE { 4617 otherName [0] AnotherName, 4618 rfc822Name [1] IA5String, 4619 dNSName [2] IA5String, 4620 x400Address [3] ORAddress, 4621 directoryName [4] Name, 4622 ediPartyName [5] EDIPartyName, 4623 uniformResourceIdentifier [6] IA5String, 4624 iPAddress [7] OCTET STRING, 4625 registeredID [8] OBJECT IDENTIFIER } 4627 -- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as 4628 -- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax 4630 AnotherName ::= SEQUENCE { 4631 type-id OBJECT IDENTIFIER, 4632 value [0] EXPLICIT ANY DEFINED BY type-id } 4634 EDIPartyName ::= SEQUENCE { 4635 nameAssigner [0] DirectoryString OPTIONAL, 4636 partyName [1] DirectoryString } 4638 -- issuer alternative name extension OID and syntax 4640 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 4642 IssuerAltName ::= GeneralNames 4644 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 4646 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 4648 -- basic constraints extension OID and syntax 4650 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 4652 BasicConstraints ::= SEQUENCE { 4653 cA BOOLEAN DEFAULT FALSE, 4654 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 4656 -- name constraints extension OID and syntax 4658 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 4660 NameConstraints ::= SEQUENCE { 4661 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 4662 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 4664 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 4666 GeneralSubtree ::= SEQUENCE { 4667 base GeneralName, 4668 minimum [0] BaseDistance DEFAULT 0, 4669 maximum [1] BaseDistance OPTIONAL } 4671 BaseDistance ::= INTEGER (0..MAX) 4673 -- policy constraints extension OID and syntax 4675 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } 4677 PolicyConstraints ::= SEQUENCE { 4678 requireExplicitPolicy [0] SkipCerts OPTIONAL, 4679 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 4681 SkipCerts ::= INTEGER (0..MAX) 4683 -- CRL distribution points extension OID and syntax 4685 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31} 4687 CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 4689 DistributionPoint ::= SEQUENCE { 4690 distributionPoint [0] DistributionPointName OPTIONAL, 4691 reasons [1] ReasonFlags OPTIONAL, 4692 cRLIssuer [2] GeneralNames OPTIONAL } 4694 DistributionPointName ::= CHOICE { 4695 fullName [0] GeneralNames, 4696 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 4698 ReasonFlags ::= BIT STRING { 4699 unused (0), 4700 keyCompromise (1), 4701 cACompromise (2), 4702 affiliationChanged (3), 4703 superseded (4), 4704 cessationOfOperation (5), 4705 certificateHold (6) } 4707 -- extended key usage extension OID and syntax 4709 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 4711 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 4713 KeyPurposeId ::= OBJECT IDENTIFIER 4715 -- extended key purpose OIDs 4716 id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } 4717 id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } 4718 id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } 4719 id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } 4720 id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 } 4721 id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 } 4722 id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 } 4723 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 4725 -- inhibit any policy OID and syntax 4727 id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 } 4728 InhibitAnyPolicy ::= SkipCerts 4730 -- freshest (delta-)CRL extension OID and syntax 4732 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } 4734 FreshestCRL ::= CRLDistributionPoints 4736 -- authority info access 4738 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 4740 AuthorityInfoAccessSyntax ::= 4741 SEQUENCE SIZE (1..MAX) OF AccessDescription 4743 AccessDescription ::= SEQUENCE { 4744 accessMethod OBJECT IDENTIFIER, 4745 accessLocation GeneralName } 4747 -- CRL number extension OID and syntax 4749 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 4751 CRLNumber ::= INTEGER (0..MAX) 4753 -- issuing distribution point extension OID and syntax 4755 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 4757 IssuingDistributionPoint ::= SEQUENCE { 4758 distributionPoint [0] DistributionPointName OPTIONAL, 4759 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 4760 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 4761 onlySomeReasons [3] ReasonFlags OPTIONAL, 4762 indirectCRL [4] BOOLEAN DEFAULT FALSE } 4764 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 4766 BaseCRLNumber ::= CRLNumber 4768 -- CRL reasons extension OID and syntax 4770 id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 } 4772 CRLReason ::= ENUMERATED { 4773 unspecified (0), 4774 keyCompromise (1), 4775 cACompromise (2), 4776 affiliationChanged (3), 4777 superseded (4), 4778 cessationOfOperation (5), 4779 certificateHold (6), 4780 removeFromCRL (8) } 4782 -- certificate issuer CRL entry extension OID and syntax 4784 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } 4786 CertificateIssuer ::= GeneralNames 4788 -- hold instruction extension OID and syntax 4790 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 4792 HoldInstructionCode ::= OBJECT IDENTIFIER 4794 -- ANSI x9 holdinstructions 4796 -- ANSI x9 arc holdinstruction arc 4797 holdInstruction OBJECT IDENTIFIER ::= 4798 {joint-iso-itu-t(2) member-body(2) us(840) x9cm(10040) 2} 4800 -- ANSI X9 holdinstructions referenced by this standard 4801 id-holdinstruction-none OBJECT IDENTIFIER ::= 4802 {holdInstruction 1} -- deprecated 4803 id-holdinstruction-callissuer OBJECT IDENTIFIER ::= 4804 {holdInstruction 2} 4805 id-holdinstruction-reject OBJECT IDENTIFIER ::= 4806 {holdInstruction 3} 4808 -- invalidity date CRL entry extension OID and syntax 4810 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 4812 InvalidityDate ::= GeneralizedTime 4814 END 4815 Appendix B. ASN.1 Notes 4817 CAs MUST force the serialNumber to be a non-negative integer, that 4818 is, the sign bit in the DER encoding of the INTEGER value MUST be 4819 zero - this can be done by adding a leading (leftmost) `00'H octet if 4820 necessary. This removes a potential ambiguity in mapping between a 4821 string of octets and an integer value. 4823 As noted in section 4.1.2.2, serial numbers can be expected to 4824 contain long integers. Certificate users MUST be able to handle 4825 serialNumber values up to 20 octets in length. Conformant CAs MUST 4826 NOT use serialNumber values longer than 20 octets. 4828 The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 4829 constructs. A valid ASN.1 sequence will have zero or more entries. 4830 The SIZE (1..MAX) construct constrains the sequence to have at least 4831 one entry. MAX indicates the upper bound is unspecified. 4832 Implementations are free to choose an upper bound that suits their 4833 environment. 4835 The construct "positiveInt ::= INTEGER (0..MAX)" defines positiveInt 4836 as a subtype of INTEGER containing integers greater than or equal to 4837 zero. The upper bound is unspecified. Implementations are free to 4838 select an upper bound that suits their environment. 4840 The character string type PrintableString supports a very basic Latin 4841 character set: the lower case letters 'a' through 'z', upper case 4842 letters 'A' through 'Z', the digits '0' through '9', eleven special 4843 characters ' = ( ) + , - . / : ? and space. 4845 The character string type TeletexString is a superset of 4846 PrintableString. TeletexString supports a fairly standard (ascii- 4847 like) Latin character set, Latin characters with non-spacing accents 4848 and Japanese characters. 4850 The character string type UniversalString supports any of the 4851 characters allowed by ISO 10646-1. ISO 10646 is the Universal 4852 multiple-octet coded Character Set (UCS). ISO 10646-1 specifes the 4853 architecture and the "basic multilingual plane" - a large standard 4854 character set which includes all major world character standards. 4856 The character string type UTF8String was introduced in the 1997 4857 version of ASN.1, and UTF8String was added to the list of choices for 4858 DirectoryString in the 2001 version of X.520. UTF8String is a 4859 universal type and has been assigned tag number 12. The content of 4860 UTF8String was defined by RFC 2044 and updated in RFC 2279, "UTF-8, a 4861 transformation format of ISO 10646." 4862 In anticipation of these changes, and in conformance with IETF Best 4863 Practices codified in RFC 2277, IETF Policy on Character Sets and 4864 Languages, this document includes UTF8String as a choice in 4865 DirectoryString and the CPS qualifier extensions. 4867 Implementers should note that the DER encoding of the SET OF values 4868 requires ordering of the encodings of the values. In particular, this 4869 issue arises with respect to distinguished names. 4871 Object Identifiers (OIDs) are used throught this specification to 4872 identify certificate policies, public key and signature algorithms, 4873 certificate extensions, etc. There is no maximum size for OIDs. 4874 This specification mandates support for OIDs which have arc elements 4875 with values that are less than 2^28, i.e. they MUST be between 0 and 4876 268,435,455 inclusive. This allows each arc element to be represented 4877 within a single 32 bit word. Implementations MUST also support OIDs 4878 where the length of the dotted decimal (see [LDAP], section 4.1.2) 4879 string representation can be up to 100 bytes (inclusive). 4880 Implementations MUST be able to handle OIDs with up to 20 elements 4881 (inclusive). CAs SHOULD NOT issue certificates which contain OIDs 4882 that breach these requirements. 4884 Appendix C. Examples 4886 This section contains four examples: three certificates and a CRL. 4887 The first two certificates and the CRL comprise a minimal 4888 certification path. 4890 Section C.1 contains an annotated hex dump of a "self-signed" 4891 certificate issued by a CA whose distinguished name is 4892 cn=us,o=gov,ou=nist. The certificate contains a DSA public key with 4893 parameters, and is signed by the corresponding DSA private key. 4895 Section C.2 contains an annotated hex dump of an end-entity 4896 certificate. The end entity certificate contains a DSA public key, 4897 and is signed by the private key corresponding to the "self-signed" 4898 certificate in section C.1. 4900 Section C.3 contains a dump of an end entity certificate which 4901 contains an RSA public key and is signed with RSA and MD5. This 4902 certificate is not part of the minimal certification path. 4904 Section C.4 contains an annotated hex dump of a CRL. The CRL is 4905 issued by the CA whose distinguished name is cn=us,o=gov,ou=nist and 4906 the list of revoked certificates includes the end entity certificate 4907 presented in C.2. 4909 The certificates were processed using Peter Gutman's dumpasn1 utility 4910 to generate the output. The source for the dumpasn1 utility is 4911 available at . The 4912 binaries for the certificates and CRLs are available at 4913 . 4915 C.1 Certificate 4917 This section contains an annotated hex dump of a 699 byte version 3 4918 certificate. The certificate contains the following information: 4919 (a) the serial number is 23 (17 hex); 4920 (b) the certificate is signed with DSA and the SHA-1 hash algorithm; 4921 (c) the issuer's distinguished name is OU=NIST; O=gov; C=US 4922 (d) and the subject's distinguished name is OU=NIST; O=gov; C=US 4923 (e) the certificate was issued on June 30, 1997 and will expire on 4924 December 31, 1997; 4925 (f) the certificate contains a 1024 bit DSA public key with 4926 parameters; 4927 (g) the certificate contains a subject key identifier extension; and 4928 (h) the certificate is a CA certificate (as indicated through the 4929 basic constraints extension.) 4931 0 30 701: SEQUENCE { 4932 4 30 637: SEQUENCE { 4933 8 A0 3: [0] { 4934 10 02 1: INTEGER 2 4935 : } 4936 13 02 1: INTEGER 23 4937 16 30 9: SEQUENCE { 4938 18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 4939 : } 4940 27 30 42: SEQUENCE { 4941 29 31 11: SET { 4942 31 30 9: SEQUENCE { 4943 33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 4944 38 13 2: PrintableString 'US' 4945 : } 4946 : } 4947 42 31 12: SET { 4948 44 30 10: SEQUENCE { 4949 46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 4950 51 13 3: PrintableString 'gov' 4951 : } 4952 : } 4953 56 31 13: SET { 4954 58 30 11: SEQUENCE { 4955 60 06 3: OBJECT IDENTIFIER 4956 organizationalUnitName (2 5 4 11) 4958 65 13 4: PrintableString 'NIST' 4959 : } 4960 : } 4961 : } 4962 71 30 30: SEQUENCE { 4963 73 17 13: UTCTime '970630000000Z' 4964 88 17 13: UTCTime '971231000000Z' 4965 : } 4966 103 30 42: SEQUENCE { 4967 105 31 11: SET { 4968 107 30 9: SEQUENCE { 4969 109 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 4970 114 13 2: PrintableString 'US' 4971 : } 4972 : } 4973 118 31 12: SET { 4974 120 30 10: SEQUENCE { 4975 122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 4976 127 13 3: PrintableString 'gov' 4977 : } 4978 : } 4979 132 31 13: SET { 4980 134 30 11: SEQUENCE { 4981 136 06 3: OBJECT IDENTIFIER 4982 organizationalUnitName (2 5 4 11) 4983 141 13 4: PrintableString 'NIST' 4984 : } 4985 : } 4986 : } 4987 147 30 440: SEQUENCE { 4988 151 30 300: SEQUENCE { 4989 155 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) 4990 164 30 287: SEQUENCE { 4991 168 02 129: INTEGER 4992 : 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC FB 95 4993 : 32 AC 01 12 33 B9 E0 1C AD 90 9B BC 48 54 9E F3 4994 : 94 77 3C 2C 71 35 55 E6 FE 4F 22 CB D5 D8 3E 89 4995 : 93 33 4D FC BD 4F 41 64 3E A2 98 70 EC 31 B4 50 4996 : DE EB F1 98 28 0A C9 3E 44 B3 FD 22 97 96 83 D0 4997 : 18 A3 E3 BD 35 5B FF EE A3 21 72 6A 7B 96 DA B9 4998 : 3F 1E 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A 4999 : FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48 63 FE 5000 : 43 5001 300 02 21: INTEGER 5002 : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA 55 F7 5003 : 7D 57 74 81 E5 5004 323 02 129: INTEGER 5005 : 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91 C0 8E 5006 : 47 F1 0A C3 01 47 C2 44 42 36 A9 92 81 DE 57 C5 5007 : E0 68 86 58 00 7B 1F F9 9B 77 A1 C5 10 A5 80 91 5008 : 78 51 51 3C F6 FC FC CC 46 C6 81 78 92 84 3D F4 5009 : 93 3D 0C 38 7E 1A 5B 99 4E AB 14 64 F6 0C 21 22 5010 : 4E 28 08 9C 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 5011 : 39 A2 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF 5012 : F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE 1E 57 5013 : 18 5014 : } 5015 : } 5016 455 03 133: BIT STRING 0 unused bits 5017 : 02 81 81 00 B5 9E 1F 49 04 47 D1 DB F5 3A DD CA 5018 : 04 75 E8 DD 75 F6 9B 8A B1 97 D6 59 69 82 D3 03 5019 : 4D FD 3B 36 5F 4A F2 D1 4E C1 07 F5 D1 2A D3 78 5020 : 77 63 56 EA 96 61 4D 42 0B 7A 1D FB AB 91 A4 CE 5021 : DE EF 77 C8 E5 EF 20 AE A6 28 48 AF BE 69 C3 6A 5022 : A5 30 F2 C2 B9 D9 82 2B 7D D9 C4 84 1F DE 0D E8 5023 : 54 D7 1B 99 2E B3 D0 88 F6 D6 63 9B A7 E2 0E 82 5024 : D4 3B 8A 68 1B 06 56 31 59 0B 49 EB 99 A5 D5 81 5025 : 41 7B C9 55 5026 : } 5027 591 A3 52: [3] { 5028 593 30 50: SEQUENCE { 5029 595 30 31: SEQUENCE { 5030 597 06 3: OBJECT IDENTIFIER 5031 subjectKeyIdentifier (2 5 29 14) 5032 602 04 24: OCTET STRING 5033 : 04 16 04 14 E7 26 C5 54 CD 5B A3 6F 35 68 95 AA 5034 : D5 FF 1C 21 E4 22 75 D6 5035 : } 5036 628 30 15: SEQUENCE { 5037 630 06 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19) 5038 635 01 1: BOOLEAN TRUE 5039 638 04 5: OCTET STRING 5040 : 30 03 01 01 FF 5041 : } 5042 : } 5043 : } 5044 : } 5045 645 30 9: SEQUENCE { 5046 647 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5047 : } 5048 656 03 47: BIT STRING 0 unused bits 5049 : 30 2C 02 14 6A F9 3F 72 30 7F 45 DC E5 50 C1 5E 5050 : 94 A0 6D C7 92 4C E5 E1 02 14 6F 61 B8 65 F7 AA 5051 : DF 46 1B F7 39 0D 0D 88 9E FE B6 83 F7 1A 5052 : } 5054 C.2 Certificate 5056 This section contains an annotated hex dump of a 730 byte version 3 5057 certificate. The certificate contains the following information: 5058 (a) the serial number is 18 (12 hex); 5059 (b) the certificate is signed with DSA and the SHA-1 hash algorithm; 5060 (c) the issuer's distinguished name is OU=nist; O=gov; C=US 5061 (d) and the subject's distinguished name is CN=Tim Polk; OU=nist; 5062 O=gov; C=US 5063 (e) the certificate was valid from July 30, 1997 through December 1, 5064 1997; 5065 (f) the certificate contains a 1024 bit DSA public key; 5066 (g) the certificate is an end entity certificate, as the basic 5067 constraints extension is not present; 5068 (h) the certificate contains an authority key identifier extension; 5069 and 5070 (i) the certificate includes one alternative name - an RFC 822 5071 address. 5073 0 30 734: SEQUENCE { 5074 4 30 669: SEQUENCE { 5075 8 A0 3: [0] { 5076 10 02 1: INTEGER 2 5077 : } 5078 13 02 1: INTEGER 18 5079 16 30 9: SEQUENCE { 5080 18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5081 : } 5082 27 30 42: SEQUENCE { 5083 29 31 11: SET { 5084 31 30 9: SEQUENCE { 5085 33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5086 38 13 2: PrintableString 'US' 5087 : } 5088 : } 5089 42 31 12: SET { 5090 44 30 10: SEQUENCE { 5091 46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5092 51 13 3: PrintableString 'gov' 5093 : } 5094 : } 5095 56 31 13: SET { 5096 58 30 11: SEQUENCE { 5097 60 06 3: OBJECT IDENTIFIER 5098 organizationalUnitName (2 5 4 11) 5099 65 13 4: PrintableString 'NIST' 5100 : } 5101 : } 5102 : } 5103 71 30 30: SEQUENCE { 5104 73 17 13: UTCTime '970730000000Z' 5105 88 17 13: UTCTime '971201000000Z' 5106 : } 5107 103 30 61: SEQUENCE { 5108 105 31 11: SET { 5109 107 30 9: SEQUENCE { 5110 109 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5111 114 13 2: PrintableString 'US' 5112 : } 5113 : } 5114 118 31 12: SET { 5115 120 30 10: SEQUENCE { 5116 122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5117 127 13 3: PrintableString 'gov' 5118 : } 5119 : } 5120 132 31 13: SET { 5121 134 30 11: SEQUENCE { 5122 136 06 3: OBJECT IDENTIFIER 5123 organizationalUnitName (2 5 4 11) 5124 141 13 4: PrintableString 'NIST' 5125 : } 5126 : } 5127 147 31 17: SET { 5128 149 30 15: SEQUENCE { 5129 151 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 5130 156 13 8: PrintableString 'Tim Polk' 5131 : } 5132 : } 5133 : } 5134 166 30 439: SEQUENCE { 5135 170 30 300: SEQUENCE { 5136 174 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) 5137 183 30 287: SEQUENCE { 5138 187 02 129: INTEGER 5139 : 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC FB 95 5140 : 32 AC 01 12 33 B9 E0 1C AD 90 9B BC 48 54 9E F3 5141 : 94 77 3C 2C 71 35 55 E6 FE 4F 22 CB D5 D8 3E 89 5142 : 93 33 4D FC BD 4F 41 64 3E A2 98 70 EC 31 B4 50 5143 : DE EB F1 98 28 0A C9 3E 44 B3 FD 22 97 96 83 D0 5144 : 18 A3 E3 BD 35 5B FF EE A3 21 72 6A 7B 96 DA B9 5145 : 3F 1E 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A 5146 : FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48 63 FE 5147 : 43 5148 319 02 21: INTEGER 5149 : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA 55 F7 5150 : 7D 57 74 81 E5 5151 342 02 129: INTEGER 5152 : 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91 C0 8E 5153 : 47 F1 0A C3 01 47 C2 44 42 36 A9 92 81 DE 57 C5 5154 : E0 68 86 58 00 7B 1F F9 9B 77 A1 C5 10 A5 80 91 5155 : 78 51 51 3C F6 FC FC CC 46 C6 81 78 92 84 3D F4 5156 : 93 3D 0C 38 7E 1A 5B 99 4E AB 14 64 F6 0C 21 22 5157 : 4E 28 08 9C 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 5158 : 39 A2 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF 5159 : F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE 1E 57 5160 : 18 5161 : } 5162 : } 5163 474 03 132: BIT STRING 0 unused bits 5164 : 02 81 80 30 B6 75 F7 7C 20 31 AE 38 BB 7E 0D 2B 5165 : AB A0 9C 4B DF 20 D5 24 13 3C CD 98 E5 5F 6C B7 5166 : C1 BA 4A BA A9 95 80 53 F0 0D 72 DC 33 37 F4 01 5167 : 0B F5 04 1F 9D 2E 1F 62 D8 84 3A 9B 25 09 5A 2D 5168 : C8 46 8E 2B D4 F5 0D 3B C7 2D C6 6C B9 98 C1 25 5169 : 3A 44 4E 8E CA 95 61 35 7C CE 15 31 5C 23 13 1E 5170 : A2 05 D1 7A 24 1C CB D3 72 09 90 FF 9B 9D 28 C0 5171 : A1 0A EC 46 9F 0D B8 D0 DC D0 18 A6 2B 5E F9 8F 5172 : B5 95 BE 5173 : } 5174 609 A3 66: [3] { 5175 611 30 64: SEQUENCE { 5176 613 30 25: SEQUENCE { 5177 615 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 5178 620 04 18: OCTET STRING 5179 : 30 10 81 0E 77 70 6F 6C 6B 40 6E 69 73 74 2E 67 5180 : 6F 76 5181 : } 5182 640 30 35: SEQUENCE { 5183 642 06 3: OBJECT IDENTIFIER 5184 authorityKeyIdentifier (2 5 29 35) 5185 647 04 28: OCTET STRING 5186 : 30 1A 80 18 04 16 04 14 E7 26 C5 54 CD 5B A3 6F 5187 : 35 68 95 AA D5 FF 1C 21 E4 22 75 D6 5188 : } 5189 : } 5190 : } 5191 : } 5192 677 30 9: SEQUENCE { 5193 679 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5194 : } 5195 688 03 48: BIT STRING 0 unused bits 5196 : 30 2D 02 14 37 FC 44 BF 7F 8D 18 1F 40 04 2F CF 5197 : EA CC 22 B2 16 01 FF 13 02 15 00 97 D0 24 96 0F 5198 : 64 8A C3 8D 41 B2 0E B9 26 D5 31 D1 A0 F1 BC 5199 : } 5201 C.3 End-Entity Certificate Using RSA 5203 This section contains an annotated hex dump of a 675 byte version 3 5204 certificate. The certificate contains the following information: 5205 (a) the serial number is 256; 5206 (b) the certificate is signed with RSA and the MD2 hash algorithm; 5207 (c) the issuer's distinguished name is OU=Dept. Arquitectura de 5208 Computadors; O=Universitat Politecnica de Catalunya; C=ES 5209 (d) and the subject's distinguished name is CN=Francisco Jordan; 5210 OU=Dept. Arquitectura de Computadors; O=Universitat Politecnica de 5211 Catalunya; C=ES 5212 (e) the certificate was issued on May 21, 1996 and expired on May 21, 5213 1997; 5214 (f) the certificate contains a 768 bit RSA public key; 5215 (g) the certificate is an end entity certificate (not a CA 5216 certificate); 5217 (h) the certificate includes an alternative subject name and an 5218 alternative issuer name - bothe are URLs; 5219 (i) the certificate include an authority key identifier and 5220 certificate policies extensions; and 5221 (j) the certificate includes a critical key usage extension 5222 specifying the public is intended for generation of digital 5223 signatures. 5225 0 30 654: SEQUENCE { 5226 4 30 503: SEQUENCE { 5227 8 A0 3: [0] { 5228 10 02 1: INTEGER 2 5229 : } 5230 13 02 2: INTEGER 256 5231 17 30 13: SEQUENCE { 5232 19 06 9: OBJECT IDENTIFIER 5233 : sha1withRSAEncryption (1 2 840 113549 1 1 5) 5234 30 05 0: NULL 5235 : } 5236 32 30 42: SEQUENCE { 5237 34 31 11: SET { 5238 36 30 9: SEQUENCE { 5239 38 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5240 43 13 2: PrintableString 'US' 5241 : } 5242 : } 5243 47 31 12: SET { 5244 49 30 10: SEQUENCE { 5245 51 06 3: OBJECT IDENTIFIER 5246 organizationalUnitName (2 5 4 11) 5247 56 13 3: PrintableString 'gov' 5248 : } 5249 : } 5250 61 31 13: SET { 5251 63 30 11: SEQUENCE { 5252 65 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5253 70 13 4: PrintableString 'NIST' 5254 : } 5255 : } 5256 : } 5257 76 30 30: SEQUENCE { 5258 78 17 13: UTCTime '960521095826Z' 5259 93 17 13: UTCTime '970521095826Z' 5260 : } 5261 108 30 61: SEQUENCE { 5262 110 31 11: SET { 5263 112 30 9: SEQUENCE { 5264 114 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5265 119 13 2: PrintableString 'US' 5266 : } 5267 : } 5268 123 31 12: SET { 5269 125 30 10: SEQUENCE { 5270 127 06 3: OBJECT IDENTIFIER 5271 organizationalUnitName (2 5 4 11) 5272 132 13 3: PrintableString 'gov' 5273 : } 5274 : } 5275 137 31 13: SET { 5276 139 30 11: SEQUENCE { 5277 141 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5278 146 13 4: PrintableString 'NIST' 5279 : } 5280 : } 5281 152 31 17: SET { 5282 154 30 15: SEQUENCE { 5283 156 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 5284 161 13 8: PrintableString 'Tim Polk' 5285 : } 5286 : } 5287 : } 5288 171 30 159: SEQUENCE { 5289 174 30 13: SEQUENCE { 5290 176 06 9: OBJECT IDENTIFIER 5291 rsaEncryption (1 2 840 113549 1 1 1) 5292 187 05 0: NULL 5293 : } 5295 189 03 141: BIT STRING 0 unused bits 5296 : 30 81 89 02 81 81 00 E1 CE 06 C9 D7 00 DF 65 27 5297 : 45 1E 63 6A 09 A0 A0 10 4B AF DF 9D 36 1D 44 1F 5298 : B7 07 5D 36 92 09 6A 1A 96 C7 4E D9 86 0D 0F 77 5299 : 94 F5 82 62 68 9A F2 D7 76 F5 9A 35 C7 B3 7F 4F 5300 : BE 64 CF A3 0C B3 84 32 80 F5 CA 77 29 C9 76 0B 5301 : 4C 38 19 EE 61 6F BA 68 E0 03 85 46 34 AB 84 64 5302 : 7F 43 69 02 C0 20 86 BD B1 D4 AD 21 A9 1A 8F CF 5303 : 96 83 86 92 57 5B 43 09 28 4C F2 5A 04 AD E5 DE 5304 : 9E 4F E8 38 3C F0 89 02 03 01 00 01 5305 : } 5306 333 A3 175: [3] { 5307 336 30 172: SEQUENCE { 5308 339 30 63: SEQUENCE { 5309 341 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 5310 346 04 56: OCTET STRING 5311 : 30 36 86 34 68 74 74 70 3A 2F 2F 77 77 77 2E 69 5312 : 74 6C 2E 6E 69 73 74 2E 67 6F 76 2F 64 69 76 38 5313 : 39 33 2F 73 74 61 66 66 2F 70 6F 6C 6B 2F 69 6E 5314 : 64 65 78 2E 68 74 6D 6C 5315 : } 5316 404 30 31: SEQUENCE { 5317 406 06 3: OBJECT IDENTIFIER issuerAltName (2 5 29 18) 5318 411 04 24: OCTET STRING 5319 : 30 16 86 14 68 74 74 70 3A 2F 2F 77 77 77 2E 6E 5320 : 69 73 74 2E 67 6F 76 2F 5321 : } 5322 437 30 31: SEQUENCE { 5323 439 06 3: OBJECT IDENTIFIER 5324 authorityKeyIdentifier (2 5 29 35) 5325 444 04 24: OCTET STRING 5326 : 30 16 80 14 30 12 80 10 0E 6B 3A BF 04 EA 04 C3 5327 : 0E 6B 3A BF 04 EA 04 C3 5328 : } 5329 470 30 23: SEQUENCE { 5330 472 06 3: OBJECT IDENTIFIER 5331 certificatePolicies (2 5 29 32) 5332 477 04 16: OCTET STRING 5333 : 30 0E 30 0C 06 0A 60 86 48 01 65 03 02 01 30 09 5334 : } 5335 495 30 14: SEQUENCE { 5336 497 06 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) 5337 502 01 1: BOOLEAN TRUE 5338 505 04 4: OCTET STRING 5339 : 03 02 07 80 5340 : } 5341 : } 5342 : } 5343 : } 5344 511 30 13: SEQUENCE { 5345 513 06 9: OBJECT IDENTIFIER 5346 : sha1withRSAEncryption (1 2 840 113549 1 1 5) 5347 524 05 0: NULL 5348 : } 5349 526 03 129: BIT STRING 0 unused bits 5350 : C1 25 6F AB 72 C0 5D DA E4 2F D5 E1 B0 25 D8 B4 5351 : F1 82 95 D6 0D A5 4E 4F A1 23 E1 13 A4 9C 3D C5 5352 : 7F FD 05 EC 75 06 30 66 97 75 A6 5D 8F 97 BA B4 5353 : EC A9 43 19 8D B7 54 FD E9 AD 43 B8 3C 8B D3 9E 5354 : C7 C7 27 E3 1A AD D3 79 AC 65 5A 52 78 C4 D0 43 5355 : 81 50 F7 8A BA E2 30 1A 6D D0 78 A0 4E AE 2E 79 5356 : 37 0C 93 05 5C D1 9C 1B B2 62 73 D1 EA 50 B7 84 5357 : 29 92 74 34 CF BA AA 2C 4D 43 59 EF 98 0C 41 6C 5358 : } 5360 C.4 Certificate Revocation List 5362 This section contains an annotated hex dump of a version 2 CRL with 5363 one extension (cRLNumber). The CRL was issued by OU=nist;O=gov;C=us 5364 on July 7, 1996; the next scheduled issuance was August 7, 1996. The 5365 CRL includes one revoked certificates: serial number 18 (12 hex). 5366 The CRL itself is number 18, and it was signed with DSA and SHA-1. 5368 0 30 203: SEQUENCE { 5369 3 30 140: SEQUENCE { 5370 6 02 1: INTEGER 1 5371 9 30 9: SEQUENCE { 5372 11 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5373 : } 5374 20 30 42: SEQUENCE { 5375 22 31 11: SET { 5376 24 30 9: SEQUENCE { 5377 26 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5378 31 13 2: PrintableString 'US' 5379 : } 5380 : } 5381 35 31 12: SET { 5382 37 30 10: SEQUENCE { 5383 39 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5384 44 13 3: PrintableString 'gov' 5385 : } 5386 : } 5387 49 31 13: SET { 5388 51 30 11: SEQUENCE { 5389 53 06 3: OBJECT IDENTIFIER 5390 organizationalUnitName (2 5 4 11) 5392 58 13 4: PrintableString 'NIST' 5393 : } 5394 : } 5395 : } 5396 64 17 13: UTCTime '970807000000Z' 5397 79 17 13: UTCTime '970907000000Z' 5398 94 30 34: SEQUENCE { 5399 96 30 32: SEQUENCE { 5400 98 02 1: INTEGER 18 5401 101 17 13: UTCTime '970731000000Z' 5402 116 30 12: SEQUENCE { 5403 118 30 10: SEQUENCE { 5404 120 06 3: OBJECT IDENTIFIER cRLReason (2 5 29 21) 5405 125 04 3: OCTET STRING 5406 : 0A 01 01 5407 : } 5408 : } 5409 : } 5410 : } 5411 130 A0 14: [0] { 5412 132 30 12: SEQUENCE { 5413 134 30 10: SEQUENCE { 5414 136 06 3: OBJECT IDENTIFIER cRLNumber (2 5 29 20) 5415 141 04 3: OCTET STRING 5416 : 02 01 12 5417 : } 5418 : } 5419 : } 5420 : } 5421 146 30 9: SEQUENCE { 5422 148 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5423 : } 5424 157 03 47: BIT STRING 0 unused bits 5425 : 30 2C 02 14 79 1F F6 93 0B 84 06 D6 A0 7C 8D 68 5426 : A7 52 2E 5F 3F 89 9B 4B 02 14 66 D4 B5 2A 68 36 5427 : 9B 72 88 58 E3 89 19 AD 81 89 2E 96 BB CC 5428 : } 5430 Appendix D. Author Addresses: 5432 Russell Housley 5433 RSA Laboratories 5434 918 Spring Knoll Drive 5435 Herndon, VA 20170 5436 USA 5437 rhousley@rsasecurity.com 5439 Warwick Ford 5440 VeriSign, Inc. 5441 One Alewife Center 5442 Cambridge, MA 02140 5443 USA 5444 wford@verisign.com 5446 Tim Polk 5447 NIST 5448 Building 820, Room 426 5449 Gaithersburg, MD 20899 5450 USA 5451 wpolk@nist.gov 5453 David Solo 5454 Citigroup 5455 909 Third Ave, 16th Floor 5456 New York, NY 10043 5457 USA 5458 dsolo@alum.mit.edu 5460 Appendix E. Full Copyright Statement 5462 Copyright (C) The Internet Society (date). All Rights Reserved. 5464 This document and translations of it may be copied and furnished to 5465 others, and derivative works that comment on or otherwise explain it 5466 or assist in its implementation may be prepared, copied, published 5467 and distributed, in whole or in part, without restriction of any 5468 kind, provided that the above copyright notice and this paragraph are 5469 included on all such copies and derivative works. In addition, the 5470 ASN.1 modules presented in Appendices A and B may be used in whole or 5471 in part without inclusion of the copyright notice. However, this 5472 document itself may not be modified in any way, such as by removing 5473 the copyright notice or references to the Internet Society or other 5474 Internet organizations, except as needed for the purpose of 5475 developing Internet standards in which case the procedures for 5476 copyrights defined in the Internet Standards process shall be 5477 followed, or as required to translate it into languages other than 5478 English. 5480 The limited permissions granted above are perpetual and will not be 5481 revoked by the Internet Society or its successors or assigns. This 5482 document and the information contained herein is provided on an "AS 5483 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 5484 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 5485 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 5486 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 5487 OR FITNESS FOR A PARTICULAR PURPOSE.