idnits 2.17.1 draft-ietf-pkix-rfc3280bis-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 25. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 6929. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4827. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4834. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4840. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? -- The draft header indicates that this document obsoletes RFC4630, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC4325, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC3280, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (February 4, 2008) is 5920 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 6884 -- Looks like a reference, but probably isn't: '1' on line 6567 -- Looks like a reference, but probably isn't: '2' on line 6066 -- Looks like a reference, but probably isn't: '3' on line 6745 -- Looks like a reference, but probably isn't: '4' on line 6068 -- Looks like a reference, but probably isn't: '5' on line 6069 -- Looks like a reference, but probably isn't: '6' on line 6761 -- Looks like a reference, but probably isn't: '7' on line 5919 -- Looks like a reference, but probably isn't: '8' on line 5920 == Missing Reference: 'UNIVERSAL 28' is mentioned on line 5148, but not defined == Missing Reference: 'UNIVERSAL 30' is mentioned on line 5151, but not defined == Missing Reference: 'UNIVERSAL 12' is mentioned on line 5155, but not defined == Missing Reference: 'APPLICATION 1' is mentioned on line 5512, but not defined == Missing Reference: 'APPLICATION 2' is mentioned on line 5518, but not defined ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2797 (Obsoleted by RFC 5272) ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 3454 (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 2459 (Obsoleted by RFC 3280) -- Obsolete informational reference (is this intentional?): RFC 2560 (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 3280 (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 4325 (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 4630 (Obsoleted by RFC 5280) Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 25 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Cooper 3 Internet-Draft NIST 4 Obsoletes: 3280, 4325, 4630 (if approved) S. Santesson 5 Expires: August 2008 Microsoft 6 S. Farrell 7 Trinity College Dublin 8 S. Boeyen 9 Entrust 10 R. Housley 11 Vigil Security 12 W. Polk 13 NIST 14 February 4, 2008 16 Internet X.509 Public Key Infrastructure 17 Certificate and Certificate Revocation List (CRL) Profile 18 draft-ietf-pkix-rfc3280bis-11.txt 20 Status of this Memo 22 By submitting this Internet-Draft, each author represents that any 23 applicable patent or other IPR claims of which he or she is aware 24 have been or will be disclosed, and any of which he or she becomes 25 aware will be disclosed, in accordance with Section 6 of BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 Copyright Notice 45 Copyright (C) The IETF Trust (2008). 47 Abstract 49 This memo profiles the X.509 v3 certificate and X.509 v2 certificate 50 revocation list (CRL) for use in the Internet. An overview of this 51 approach and model are provided as an introduction. The X.509 v3 52 certificate format is described in detail, with additional 53 information regarding the format and semantics of Internet name 54 forms. Standard certificate extensions are described and two 55 Internet-specific extensions are defined. A set of required 56 certificate extensions is specified. The X.509 v2 CRL format is 57 described in detail along with standard and Internet-specific 58 extensions. An algorithm for X.509 certification path validation is 59 described. An ASN.1 module and examples are provided in the 60 appendices. 62 Table of Contents 64 1 Introduction . . . . . . . . . . . . . . . . . . . . . . 4 65 2 Requirements and Assumptions . . . . . . . . . . . . . . 6 66 2.1 Communication and Topology . . . . . . . . . . . . . . 7 67 2.2 Acceptability Criteria . . . . . . . . . . . . . . . . 7 68 2.3 User Expectations . . . . . . . . . . . . . . . . . . . 8 69 2.4 Administrator Expectations . . . . . . . . . . . . . . 8 70 3 Overview of Approach . . . . . . . . . . . . . . . . . . 8 71 3.1 X.509 Version 3 Certificate . . . . . . . . . . . . . . 9 72 3.2 Certification Paths and Trust . . . . . . . . . . . . . 11 73 3.3 Revocation . . . . . . . . . . . . . . . . . . . . . . 13 74 3.4 Operational Protocols . . . . . . . . . . . . . . . . . 14 75 3.5 Management Protocols . . . . . . . . . . . . . . . . . 14 76 4 Certificate and Certificate Extensions Profile . . . . . 16 77 4.1 Basic Certificate Fields . . . . . . . . . . . . . . . 16 78 4.1.1 Certificate Fields . . . . . . . . . . . . . . . . . 17 79 4.1.1.1 tbsCertificate . . . . . . . . . . . . . . . . . . 17 80 4.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . 18 81 4.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . 18 82 4.1.2 TBSCertificate . . . . . . . . . . . . . . . . . . . 18 83 4.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . 19 84 4.1.2.2 Serial number . . . . . . . . . . . . . . . . . . . 19 85 4.1.2.3 Signature . . . . . . . . . . . . . . . . . . . . . 19 86 4.1.2.4 Issuer . . . . . . . . . . . . . . . . . . . . . . 20 87 4.1.2.5 Validity . . . . . . . . . . . . . . . . . . . . . 22 88 4.1.2.5.1 UTCTime . . . . . . . . . . . . . . . . . . . . . 23 89 4.1.2.5.2 GeneralizedTime . . . . . . . . . . . . . . . . . 23 90 4.1.2.6 Subject . . . . . . . . . . . . . . . . . . . . . . 23 91 4.1.2.7 Subject Public Key Info . . . . . . . . . . . . . . 25 92 4.1.2.8 Unique Identifiers . . . . . . . . . . . . . . . . 25 93 4.1.2.9 Extensions . . . . . . . . . . . . . . . . . . . . 25 94 4.2 Certificate Extensions . . . . . . . . . . . . . . . . 26 95 4.2.1 Standard Extensions . . . . . . . . . . . . . . . . . 27 96 4.2.1.1 Authority Key Identifier . . . . . . . . . . . . . 27 97 4.2.1.2 Subject Key Identifier . . . . . . . . . . . . . . 28 98 4.2.1.3 Key Usage . . . . . . . . . . . . . . . . . . . . . 29 99 4.2.1.4 Certificate Policies . . . . . . . . . . . . . . . 31 100 4.2.1.5 Policy Mappings . . . . . . . . . . . . . . . . . . 34 101 4.2.1.6 Subject Alternative Name . . . . . . . . . . . . . 35 102 4.2.1.7 Issuer Alternative Name . . . . . . . . . . . . . . 38 103 4.2.1.8 Subject Directory Attributes . . . . . . . . . . . 38 104 4.2.1.9 Basic Constraints . . . . . . . . . . . . . . . . . 38 105 4.2.1.10 Name Constraints . . . . . . . . . . . . . . . . . 39 106 4.2.1.11 Policy Constraints . . . . . . . . . . . . . . . . 42 107 4.2.1.12 Extended Key Usage . . . . . . . . . . . . . . . . 43 108 4.2.1.13 CRL Distribution Points . . . . . . . . . . . . . 45 109 4.2.1.14 Inhibit anyPolicy . . . . . . . . . . . . . . . . 47 110 4.2.1.15 Freshest CRL . . . . . . . . . . . . . . . . . . . 47 111 4.2.2 Private Internet Extensions . . . . . . . . . . . . . 48 112 4.2.2.1 Authority Information Access . . . . . . . . . . . 48 113 4.2.2.2 Subject Information Access . . . . . . . . . . . . 51 114 5 CRL and CRL Extensions Profile . . . . . . . . . . . . . 53 115 5.1 CRL Fields . . . . . . . . . . . . . . . . . . . . . . 54 116 5.1.1 CertificateList Fields . . . . . . . . . . . . . . . 55 117 5.1.1.1 tbsCertList . . . . . . . . . . . . . . . . . . . . 55 118 5.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . 56 119 5.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . 56 120 5.1.2 Certificate List "To Be Signed" . . . . . . . . . . . 56 121 5.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . 57 122 5.1.2.2 Signature . . . . . . . . . . . . . . . . . . . . . 57 123 5.1.2.3 Issuer Name . . . . . . . . . . . . . . . . . . . . 57 124 5.1.2.4 This Update . . . . . . . . . . . . . . . . . . . . 57 125 5.1.2.5 Next Update . . . . . . . . . . . . . . . . . . . . 58 126 5.1.2.6 Revoked Certificates . . . . . . . . . . . . . . . 58 127 5.1.2.7 Extensions . . . . . . . . . . . . . . . . . . . . 58 128 5.2 CRL Extensions . . . . . . . . . . . . . . . . . . . . 59 129 5.2.1 Authority Key Identifier . . . . . . . . . . . . . . 59 130 5.2.2 Issuer Alternative Name . . . . . . . . . . . . . . . 59 131 5.2.3 CRL Number . . . . . . . . . . . . . . . . . . . . . 60 132 5.2.4 Delta CRL Indicator . . . . . . . . . . . . . . . . . 60 133 5.2.5 Issuing Distribution Point . . . . . . . . . . . . . 63 134 5.2.6 Freshest CRL . . . . . . . . . . . . . . . . . . . . 65 135 5.2.7 Authority Information Access . . . . . . . . . . . . 66 136 5.3 CRL Entry Extensions . . . . . . . . . . . . . . . . . 67 137 5.3.1 Reason Code . . . . . . . . . . . . . . . . . . . . . 68 138 5.3.2 Invalidity Date . . . . . . . . . . . . . . . . . . . 68 139 5.3.3 Certificate Issuer . . . . . . . . . . . . . . . . . 69 140 6 Certification Path Validation . . . . . . . . . . . . . . 69 141 6.1 Basic Path Validation . . . . . . . . . . . . . . . . . 70 142 6.1.1 Inputs . . . . . . . . . . . . . . . . . . . . . . . 73 143 6.1.2 Initialization . . . . . . . . . . . . . . . . . . . 75 144 6.1.3 Basic Certificate Processing . . . . . . . . . . . . 77 145 6.1.4 Preparation for Certificate i+1 . . . . . . . . . . . 82 146 6.1.5 Wrap-up procedure . . . . . . . . . . . . . . . . . . 85 147 6.1.6 Outputs . . . . . . . . . . . . . . . . . . . . . . . 87 148 6.2 Using the Path Validation Algorithm . . . . . . . . . . 87 149 6.3 CRL Validation . . . . . . . . . . . . . . . . . . . . 88 150 6.3.1 Revocation Inputs . . . . . . . . . . . . . . . . . . 88 151 6.3.2 Initialization and Revocation State Variables . . . . 88 152 6.3.3 CRL Processing . . . . . . . . . . . . . . . . . . . 89 153 7 Processing Rules for Internationalized Names . . . . . . 92 154 7.1 Internationalized Names in Distinguished Names . . . . 93 155 7.2 Internationalized Domain Names in GeneralName . . . . . 94 156 7.3 Internationalized Domain Names in Distinguished Names . 95 157 7.4 Internationalized Resource Identifiers . . . . . . . . 95 158 7.5 Internationalized Electronic Mail Addresses . . . . . . 97 159 8 References . . . . . . . . . . . . . . . . . . . . . . . 97 160 9 Intellectual Property Rights . . . . . . . . . . . . . . 102 161 10 Security Considerations . . . . . . . . . . . . . . . . 102 162 11 IANA Considerations . . . . . . . . . . . . . . . . . . 107 163 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . 107 164 13 Acknowledgments . . . . . . . . . . . . . . . . . . . . 108 165 Appendix A. Pseudo-ASN.1 Structures and OIDs . . . . . . . 108 166 A.1 Explicitly Tagged Module, 1988 Syntax . . . . . . . . . 108 167 A.2 Implicitly Tagged Module, 1988 Syntax . . . . . . . . . 122 168 Appendix B. ASN.1 Notes . . . . . . . . . . . . . . . . . . 129 169 Appendix C. Examples . . . . . . . . . . . . . . . . . . . 132 170 C.1 RSA Self-Signed Certificate . . . . . . . . . . . . . . 133 171 C.2 End Entity Certificate Using RSA . . . . . . . . . . . 136 172 C.3 End Entity Certificate Using DSA . . . . . . . . . . . 139 173 C.4 Certificate Revocation List . . . . . . . . . . . . . . 143 174 Full Copyright Statement . . . . . . . . . . . . . . . . . . 145 176 1 Introduction 178 This specification is one part of a family of standards for the X.509 179 Public Key Infrastructure (PKI) for the Internet. 181 This specification profiles the format and semantics of certificates 182 and certificate revocation lists (CRLs) for the Internet PKI. 183 Procedures are described for processing of certification paths in the 184 Internet environment. Finally, ASN.1 modules are provided in the 185 appendices for all data structures defined or referenced. 187 Section 2 describes Internet PKI requirements, and the assumptions 188 that affect the scope of this document. Section 3 presents an 189 architectural model and describes its relationship to previous IETF 190 and ISO/IEC/ITU-T standards. In particular, this document's 191 relationship with the IETF PEM specifications and the ISO/IEC/ITU-T 192 X.509 documents are described. 194 Section 4 profiles the X.509 version 3 certificate, and section 5 195 profiles the X.509 version 2 CRL. The profiles include the 196 identification of ISO/IEC/ITU-T and ANSI extensions which may be 197 useful in the Internet PKI. The profiles are presented in the 1988 198 Abstract Syntax Notation One (ASN.1) rather than the 1997 ASN.1 199 syntax used in the most recent ISO/IEC/ITU-T standards. 201 Section 6 includes certification path validation procedures. These 202 procedures are based upon the ISO/IEC/ITU-T definition. 203 Implementations are REQUIRED to derive the same results but are not 204 required to use the specified procedures. 206 Procedures for identification and encoding of public key materials 207 and digital signatures are defined in [RFC 3279], [RFC 4055], and 208 [RFC 4491]. Implementations of this specification are not required 209 to use any particular cryptographic algorithms. However, conforming 210 implementations that use the algorithms identified in [RFC 3279], 211 [RFC 4055], and [RFC 4491] MUST identify and encode the public key 212 materials and digital signatures as described in those 213 specifications. 215 Finally, three appendices are provided to aid implementers. Appendix 216 A contains all ASN.1 structures defined or referenced within this 217 specification. As above, the material is presented in the 1988 218 ASN.1. Appendix B contains notes on less familiar features of the 219 ASN.1 notation used within this specification. Appendix C contains 220 examples of conforming certificates and a conforming CRL. 222 This specification obsoletes [RFC 3280]. Differences from RFC 3280 223 are summarized below: 225 * Enhanced support for internationalized names is specified in 226 section 7, with rules for encoding and comparing internationalized 227 domain names, IRIs, and distinguished names. These rules are 228 aligned with comparison rules established in current RFCs, 229 including [RFC 3490], [RFC 3987], and [RFC 4518]. 231 * Sections 4.1.2.4 and 4.1.2.6 incorporate the conditions for 232 continued use of legacy text encoding schemes that were specified 233 in [RFC 4630]. Where in use by an established PKI, transition to 234 UTF8String could cause denial of service based on name chaining 235 failures or incorrect processing of name constraints. 237 * Section 4.2.1.4 in RFC 3280, which specified the 238 privateKeyUsagePeriod certificate extension but deprecated its 239 use, was removed. Use of this ISO standard extension is neither 240 deprecated nor recommended for use in the Internet PKI. 242 * Section 4.2.1.5 recommends marking the policy mappings extension 243 as critical. RFC 3280 required that the policy mappings extension 244 be marked as non-critical. 246 * Section 4.2.1.11 requires marking the policy constraints 247 extension as critical. RFC 3280 permitted the policy constraints 248 extension to be marked as critical or non-critical. 250 * The Authority Information Access (AIA) CRL extension, as 251 specified in [RFC 4325], was added as section 5.2.7. 253 * Sections 5.2 and 5.3 clarify the rules for handling unrecognized 254 CRL extensions and CRL entry extensions, respectively. 256 * Section 5.3.2 in RFC 3280, which specified the 257 holdInstructionCode CRL entry extension, was removed. 259 * The path validation algorithm specified in section 6 no longer 260 tracks the criticality of the certificate policies extensions in a 261 chain of certificates. In RFC 3280, this information was returned 262 to a relying party. 264 * The Security Considerations section addresses the risk of 265 circular dependencies arising from the use of https or similar 266 schemes in the CRL distribution points, authority information 267 access, or subject information access extensions. 269 * The Security Considerations section addresses risks associated 270 with name ambiguity. 272 * The Security Considerations section references RFC 4210 for 273 procedures to signal changes in CA operations. 275 The ASN.1 modules in appendix A are unchanged from RFC 3280, except 276 that ub-emailaddress-length was changed from 128 to 255 in order to 277 align with PKCS #9 [RFC 2985]. 279 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 280 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 281 document are to be interpreted as described in [RFC 2119]. 283 2 Requirements and Assumptions 285 The goal of this specification is to develop a profile to facilitate 286 the use of X.509 certificates within Internet applications for those 287 communities wishing to make use of X.509 technology. Such 288 applications may include WWW, electronic mail, user authentication, 289 and IPsec. In order to relieve some of the obstacles to using X.509 290 certificates, this document defines a profile to promote the 291 development of certificate management systems; development of 292 application tools; and interoperability determined by policy. 294 Some communities will need to supplement, or possibly replace, this 295 profile in order to meet the requirements of specialized application 296 domains or environments with additional authorization, assurance, or 297 operational requirements. However, for basic applications, common 298 representations of frequently used attributes are defined so that 299 application developers can obtain necessary information without 300 regard to the issuer of a particular certificate or certificate 301 revocation list (CRL). 303 A certificate user should review the certificate policy generated by 304 the certification authority (CA) before relying on the authentication 305 or non-repudiation services associated with the public key in a 306 particular certificate. To this end, this standard does not 307 prescribe legally binding rules or duties. 309 As supplemental authorization and attribute management tools emerge, 310 such as attribute certificates, it may be appropriate to limit the 311 authenticated attributes that are included in a certificate. These 312 other management tools may provide more appropriate methods of 313 conveying many authenticated attributes. 315 2.1 Communication and Topology 317 The users of certificates will operate in a wide range of 318 environments with respect to their communication topology, especially 319 users of secure electronic mail. This profile supports users without 320 high bandwidth, real-time IP connectivity, or high connection 321 availability. In addition, the profile allows for the presence of 322 firewall or other filtered communication. 324 This profile does not assume the deployment of an X.500 directory 325 system [X.500] or a Lightweight Directory Access Protocol (LDAP) 326 directory system [RFC 4510]. The profile does not prohibit the use 327 of an X.500 directory or a LDAP directory; however, any means of 328 distributing certificates and certificate revocation lists (CRLs) may 329 be used. 331 2.2 Acceptability Criteria 333 The goal of the Internet Public Key Infrastructure (PKI) is to meet 334 the needs of deterministic, automated identification, authentication, 335 access control, and authorization functions. Support for these 336 services determines the attributes contained in the certificate as 337 well as the ancillary control information in the certificate such as 338 policy data and certification path constraints. 340 2.3 User Expectations 342 Users of the Internet PKI are people and processes who use client 343 software and are the subjects named in certificates. These uses 344 include readers and writers of electronic mail, the clients for WWW 345 browsers, WWW servers, and the key manager for IPsec within a router. 346 This profile recognizes the limitations of the platforms these users 347 employ and the limitations in sophistication and attentiveness of the 348 users themselves. This manifests itself in minimal user 349 configuration responsibility (e.g., trusted CA keys, rules), explicit 350 platform usage constraints within the certificate, certification path 351 constraints that shield the user from many malicious actions, and 352 applications that sensibly automate validation functions. 354 2.4 Administrator Expectations 356 As with user expectations, the Internet PKI profile is structured to 357 support the individuals who generally operate CAs. Providing 358 administrators with unbounded choices increases the chances that a 359 subtle CA administrator mistake will result in broad compromise. 360 Also, unbounded choices greatly complicate the software that process 361 and validate the certificates created by the CA. 363 3 Overview of Approach 365 Following is a simplified view of the architectural model assumed by 366 the PKIX specifications. 368 The components in this model are: 370 end entity: user of PKI certificates and/or end user system that is 371 the subject of a certificate; 373 CA: certification authority; 375 RA: registration authority, i.e., an optional system to which 376 a CA delegates certain management functions; 378 CRL issuer: a system that generates and signs CRLs; 380 repository: a system or collection of distributed systems that stores 381 certificates and CRLs and serves as a means of 382 distributing these certificates and CRLs to end entities. 384 CAs are responsible for indicating the revocation status of the 385 certificates that they issue. Revocation status information may be 386 provided using the Online Certificate Status Protocol (OCSP) 387 [RFC 2560], certificate revocation lists (CRLs), or some other 388 mechanism. In general, when revocation status information is 389 provided using CRLs, the CA is also the CRL issuer. However, a CA 390 may delegate the responsibility for issuing CRLs to a different 391 entity. 393 Note that an Attribute Authority (AA) might also choose to delegate 394 the publication of CRLs to a CRL issuer. 396 +---+ 397 | C | +------------+ 398 | e | <-------------------->| End entity | 399 | r | Operational +------------+ 400 | t | transactions ^ 401 | i | and management | Management 402 | f | transactions | transactions PKI 403 | i | | users 404 | c | v 405 | a | ======================= +--+------------+ ============== 406 | t | ^ ^ 407 | e | | | PKI 408 | | v | management 409 | & | +------+ | entities 410 | | <---------------------| RA |<----+ | 411 | C | Publish certificate +------+ | | 412 | R | | | 413 | L | | | 414 | | v v 415 | R | +------------+ 416 | e | <------------------------------| CA | 417 | p | Publish certificate +------------+ 418 | o | Publish CRL ^ ^ 419 | s | | | Management 420 | i | +------------+ | | transactions 421 | t | <--------------| CRL Issuer |<----+ | 422 | o | Publish CRL +------------+ v 423 | r | +------+ 424 | y | | CA | 425 +---+ +------+ 427 Figure 1 - PKI Entities 429 3.1 X.509 Version 3 Certificate 431 Users of a public key require confidence that the associated private 432 key is owned by the correct remote subject (person or system) with 433 which an encryption or digital signature mechanism will be used. 435 This confidence is obtained through the use of public key 436 certificates, which are data structures that bind public key values 437 to subjects. The binding is asserted by having a trusted CA 438 digitally sign each certificate. The CA may base this assertion upon 439 technical means (a.k.a., proof of possession through a challenge- 440 response protocol), presentation of the private key, or on an 441 assertion by the subject. A certificate has a limited valid 442 lifetime, which is indicated in its signed contents. Because a 443 certificate's signature and timeliness can be independently checked 444 by a certificate-using client, certificates can be distributed via 445 untrusted communications and server systems, and can be cached in 446 unsecured storage in certificate-using systems. 448 ITU-T X.509 (formerly CCITT X.509) or ISO/IEC 9594-8, which was first 449 published in 1988 as part of the X.500 directory recommendations, 450 defines a standard certificate format [X.509]. The certificate 451 format in the 1988 standard is called the version 1 (v1) format. 452 When X.500 was revised in 1993, two more fields were added, resulting 453 in the version 2 (v2) format. 455 The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993, 456 include specifications for a public key infrastructure based on X.509 457 v1 certificates [RFC 1422]. The experience gained in attempts to 458 deploy RFC 1422 made it clear that the v1 and v2 certificate formats 459 were deficient in several respects. Most importantly, more fields 460 were needed to carry information that PEM design and implementation 461 experience had proven necessary. In response to these new 462 requirements, ISO/IEC, ITU-T and ANSI X9 developed the X.509 version 463 3 (v3) certificate format. The v3 format extends the v2 format by 464 adding provision for additional extension fields. Particular 465 extension field types may be specified in standards or may be defined 466 and registered by any organization or community. In June 1996, 467 standardization of the basic v3 format was completed [X.509]. 469 ISO/IEC, ITU-T, and ANSI X9 have also developed standard extensions 470 for use in the v3 extensions field [X.509][X9.55]. These extensions 471 can convey such data as additional subject identification 472 information, key attribute information, policy information, and 473 certification path constraints. 475 However, the ISO/IEC, ITU-T, and ANSI X9 standard extensions are very 476 broad in their applicability. In order to develop interoperable 477 implementations of X.509 v3 systems for Internet use, it is necessary 478 to specify a profile for use of the X.509 v3 extensions tailored for 479 the Internet. It is one goal of this document to specify a profile 480 for Internet WWW, electronic mail, and IPsec applications. 481 Environments with additional requirements may build on this profile 482 or may replace it. 484 3.2 Certification Paths and Trust 486 A user of a security service requiring knowledge of a public key 487 generally needs to obtain and validate a certificate containing the 488 required public key. If the public key user does not already hold an 489 assured copy of the public key of the CA that signed the certificate, 490 the CA's name, and related information (such as the validity period 491 or name constraints), then it might need an additional certificate to 492 obtain that public key. In general, a chain of multiple certificates 493 may be needed, comprising a certificate of the public key owner (the 494 end entity) signed by one CA, and zero or more additional 495 certificates of CAs signed by other CAs. Such chains, called 496 certification paths, are required because a public key user is only 497 initialized with a limited number of assured CA public keys. 499 There are different ways in which CAs might be configured in order 500 for public key users to be able to find certification paths. For 501 PEM, RFC 1422 defined a rigid hierarchical structure of CAs. There 502 are three types of PEM certification authority: 504 (a) Internet Policy Registration Authority (IPRA): This 505 authority, operated under the auspices of the Internet Society, 506 acts as the root of the PEM certification hierarchy at level 1. 507 It issues certificates only for the next level of authorities, 508 PCAs. All certification paths start with the IPRA. 510 (b) Policy Certification Authorities (PCAs): PCAs are at level 2 511 of the hierarchy, each PCA being certified by the IPRA. A PCA 512 shall establish and publish a statement of its policy with respect 513 to certifying users or subordinate certification authorities. 514 Distinct PCAs aim to satisfy different user needs. For example, 515 one PCA (an organizational PCA) might support the general 516 electronic mail needs of commercial organizations, and another PCA 517 (a high-assurance PCA) might have a more stringent policy designed 518 for satisfying legally binding digital signature requirements. 520 (c) Certification Authorities (CAs): CAs are at level 3 of the 521 hierarchy and can also be at lower levels. Those at level 3 are 522 certified by PCAs. CAs represent, for example, particular 523 organizations, particular organizational units (e.g., departments, 524 groups, sections), or particular geographical areas. 526 RFC 1422 furthermore has a name subordination rule, which requires 527 that a CA can only issue certificates for entities whose names are 528 subordinate (in the X.500 naming tree) to the name of the CA itself. 529 The trust associated with a PEM certification path is implied by the 530 PCA name. The name subordination rule ensures that CAs below the PCA 531 are sensibly constrained as to the set of subordinate entities they 532 can certify (e.g., a CA for an organization can only certify entities 533 in that organization's name tree). Certificate user systems are able 534 to mechanically check that the name subordination rule has been 535 followed. 537 The RFC 1422 uses the X.509 v1 certificate format. The limitations 538 of X.509 v1 required imposition of several structural restrictions to 539 clearly associate policy information or restrict the utility of 540 certificates. These restrictions included: 542 (a) a pure top-down hierarchy, with all certification paths 543 starting from IPRA; 545 (b) a naming subordination rule restricting the names of a CA's 546 subjects; and 548 (c) use of the PCA concept, which requires knowledge of 549 individual PCAs to be built into certificate chain verification 550 logic. Knowledge of individual PCAs was required to determine if 551 a chain could be accepted. 553 With X.509 v3, most of the requirements addressed by RFC 1422 can be 554 addressed using certificate extensions, without a need to restrict 555 the CA structures used. In particular, the certificate extensions 556 relating to certificate policies obviate the need for PCAs and the 557 constraint extensions obviate the need for the name subordination 558 rule. As a result, this document supports a more flexible 559 architecture, including: 561 (a) Certification paths start with a public key of a CA in a 562 user's own domain, or with the public key of the top of a 563 hierarchy. Starting with the public key of a CA in a user's own 564 domain has certain advantages. In some environments, the local 565 domain is the most trusted. 567 (b) Name constraints may be imposed through explicit inclusion of 568 a name constraints extension in a certificate, but are not 569 required. 571 (c) Policy extensions and policy mappings replace the PCA 572 concept, which permits a greater degree of automation. The 573 application can determine if the certification path is acceptable 574 based on the contents of the certificates instead of a priori 575 knowledge of PCAs. This permits automation of certification path 576 processing. 578 X.509 v3 also includes an extension that identifies the subject of a 579 certificate as being either a CA or an end entity, reducing the 580 reliance on out-of-band information demanded in PEM. 582 This specification covers two classes of certificates: CA 583 certificates and end entity certificates. CA certificates may be 584 further divided into three classes: cross-certificates; self-issued 585 certificates; and self-signed certificates. Cross-certificates are 586 CA certificates in which the issuer and subject are different 587 entities. Cross-certificates describe a trust relationship between 588 the two CAs. Self-issued certificates are CA certificates in which 589 the issuer and subject are the same entity. Self-issued certificates 590 are generated to support changes in policy or operations. Self- 591 signed certificates are self-issued certificates where the digital 592 signature may be verified by the public key bound into the 593 certificate. Self-signed certificates are used to convey a public 594 key for use to begin certification paths. End entity certificates 595 are issued to subjects that are not authorized to issue certificates. 597 3.3 Revocation 599 When a certificate is issued, it is expected to be in use for its 600 entire validity period. However, various circumstances may cause a 601 certificate to become invalid prior to the expiration of the validity 602 period. Such circumstances include change of name, change of 603 association between subject and CA (e.g., an employee terminates 604 employment with an organization), and compromise or suspected 605 compromise of the corresponding private key. Under such 606 circumstances, the CA needs to revoke the certificate. 608 X.509 defines one method of certificate revocation. This method 609 involves each CA periodically issuing a signed data structure called 610 a certificate revocation list (CRL). A CRL is a time stamped list 611 identifying revoked certificates that is signed by a CA or CRL issuer 612 and made freely available in a public repository. Each revoked 613 certificate is identified in a CRL by its certificate serial number. 614 When a certificate-using system uses a certificate (e.g., for 615 verifying a remote user's digital signature), that system not only 616 checks the certificate signature and validity but also acquires a 617 suitably recent CRL and checks that the certificate serial number is 618 not on that CRL. The meaning of "suitably recent" may vary with 619 local policy, but it usually means the most recently issued CRL. A 620 new CRL is issued on a regular periodic basis (e.g., hourly, daily, 621 or weekly). An entry is added to the CRL as part of the next update 622 following notification of revocation. An entry MUST NOT be removed 623 from the CRL until it appears on one regularly scheduled CRL issued 624 beyond the revoked certificate's validity period. 626 An advantage of this revocation method is that CRLs may be 627 distributed by exactly the same means as certificates themselves, 628 namely, via untrusted servers and untrusted communications. 630 One limitation of the CRL revocation method, using untrusted 631 communications and servers, is that the time granularity of 632 revocation is limited to the CRL issue period. For example, if a 633 revocation is reported now, that revocation will not be reliably 634 notified to certificate-using systems until all currently issued CRLs 635 are scheduled to be updated -- this may be up to one hour, one day, 636 or one week depending on the frequency that CRLs are issued. 638 As with the X.509 v3 certificate format, in order to facilitate 639 interoperable implementations from multiple vendors, the X.509 v2 CRL 640 format needs to be profiled for Internet use. It is one goal of this 641 document to specify that profile. However, this profile does not 642 require the issuance of CRLs. Message formats and protocols 643 supporting on-line revocation notification are defined in other PKIX 644 specifications. On-line methods of revocation notification may be 645 applicable in some environments as an alternative to the X.509 CRL. 646 On-line revocation checking may significantly reduce the latency 647 between a revocation report and the distribution of the information 648 to relying parties. Once the CA accepts a revocation report as 649 authentic and valid, any query to the on-line service will correctly 650 reflect the certificate validation impacts of the revocation. 651 However, these methods impose new security requirements: the 652 certificate validator needs to trust the on-line validation service 653 while the repository does not need to be trusted. 655 3.4 Operational Protocols 657 Operational protocols are required to deliver certificates and CRLs 658 (or status information) to certificate using client systems. 659 Provisions are needed for a variety of different means of certificate 660 and CRL delivery, including distribution procedures based on LDAP, 661 HTTP, FTP, and X.500. Operational protocols supporting these 662 functions are defined in other PKIX specifications. These 663 specifications may include definitions of message formats and 664 procedures for supporting all of the above operational environments, 665 including definitions of or references to appropriate MIME content 666 types. 668 3.5 Management Protocols 670 Management protocols are required to support on-line interactions 671 between PKI user and management entities. For example, a management 672 protocol might be used between a CA and a client system with which a 673 key pair is associated, or between two CAs that cross-certify each 674 other. The set of functions that potentially need to be supported by 675 management protocols include: 677 (a) registration: This is the process whereby a user first makes 678 itself known to a CA (directly, or through an RA), prior to that 679 CA issuing a certificate or certificates for that user. 681 (b) initialization: Before a client system can operate securely 682 it is necessary to install key materials that have the appropriate 683 relationship with keys stored elsewhere in the infrastructure. 684 For example, the client needs to be securely initialized with the 685 public key and other assured information of the trusted CA(s), to 686 be used in validating certificate paths. 688 Furthermore, a client typically needs to be initialized with its 689 own key pair(s). 691 (c) certification: This is the process in which a CA issues a 692 certificate for a user's public key, and returns that certificate 693 to the user's client system and/or posts that certificate in a 694 repository. 696 (d) key pair recovery: As an option, user client key materials 697 (e.g., a user's private key used for encryption purposes) may be 698 backed up by a CA or a key backup system. If a user needs to 699 recover these backed up key materials (e.g., as a result of a 700 forgotten password or a lost key chain file), an on-line protocol 701 exchange may be needed to support such recovery. 703 (e) key pair update: All key pairs need to be updated regularly, 704 i.e., replaced with a new key pair, and new certificates issued. 706 (f) revocation request: An authorized person advises a CA of an 707 abnormal situation requiring certificate revocation. 709 (g) cross-certification: Two CAs exchange information used in 710 establishing a cross-certificate. A cross-certificate is a 711 certificate issued by one CA to another CA that contains a CA 712 signature key used for issuing certificates. 714 Note that on-line protocols are not the only way of implementing the 715 above functions. For all functions there are off-line methods of 716 achieving the same result, and this specification does not mandate 717 use of on-line protocols. For example, when hardware tokens are 718 used, many of the functions may be achieved as part of the physical 719 token delivery. Furthermore, some of the above functions may be 720 combined into one protocol exchange. In particular, two or more of 721 the registration, initialization, and certification functions can be 722 combined into one protocol exchange. 724 The PKIX series of specifications defines a set of standard message 725 formats supporting the above functions. The protocols for conveying 726 these messages in different environments (e.g., email, file transfer, 727 and WWW) are described in those specifications. 729 4 Certificate and Certificate Extensions Profile 731 This section presents a profile for public key certificates that will 732 foster interoperability and a reusable PKI. This section is based 733 upon the X.509 v3 certificate format and the standard certificate 734 extensions defined in [X.509]. The ISO/IEC and ITU-T documents use 735 the 1997 version of ASN.1; while this document uses the 1988 ASN.1 736 syntax, the encoded certificate and standard extensions are 737 equivalent. This section also defines private extensions required to 738 support a PKI for the Internet community. 740 Certificates may be used in a wide range of applications and 741 environments covering a broad spectrum of interoperability goals and 742 a broader spectrum of operational and assurance requirements. The 743 goal of this document is to establish a common baseline for generic 744 applications requiring broad interoperability and limited special 745 purpose requirements. In particular, the emphasis will be on 746 supporting the use of X.509 v3 certificates for informal Internet 747 electronic mail, IPsec, and WWW applications. 749 4.1 Basic Certificate Fields 751 The X.509 v3 certificate basic syntax is as follows. For signature 752 calculation, the data that is to be signed is encoded using the ASN.1 753 distinguished encoding rules (DER) [X.690]. ASN.1 DER encoding is a 754 tag, length, value encoding system for each element. 756 Certificate ::= SEQUENCE { 757 tbsCertificate TBSCertificate, 758 signatureAlgorithm AlgorithmIdentifier, 759 signatureValue BIT STRING } 761 TBSCertificate ::= SEQUENCE { 762 version [0] EXPLICIT Version DEFAULT v1, 763 serialNumber CertificateSerialNumber, 764 signature AlgorithmIdentifier, 765 issuer Name, 766 validity Validity, 767 subject Name, 768 subjectPublicKeyInfo SubjectPublicKeyInfo, 769 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 770 -- If present, version MUST be v2 or v3 771 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 772 -- If present, version MUST be v2 or v3 774 extensions [3] EXPLICIT Extensions OPTIONAL 775 -- If present, version MUST be v3 776 } 778 Version ::= INTEGER { v1(0), v2(1), v3(2) } 780 CertificateSerialNumber ::= INTEGER 782 Validity ::= SEQUENCE { 783 notBefore Time, 784 notAfter Time } 786 Time ::= CHOICE { 787 utcTime UTCTime, 788 generalTime GeneralizedTime } 790 UniqueIdentifier ::= BIT STRING 792 SubjectPublicKeyInfo ::= SEQUENCE { 793 algorithm AlgorithmIdentifier, 794 subjectPublicKey BIT STRING } 796 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 798 Extension ::= SEQUENCE { 799 extnID OBJECT IDENTIFIER, 800 critical BOOLEAN DEFAULT FALSE, 801 extnValue OCTET STRING 802 -- contains the DER encoding of an ASN.1 value 803 -- corresponding to the extension type identified 804 -- by extnID 805 } 807 The following items describe the X.509 v3 certificate for use in the 808 Internet. 810 4.1.1 Certificate Fields 812 The Certificate is a SEQUENCE of three required fields. The fields 813 are described in detail in the following subsections. 815 4.1.1.1 tbsCertificate 817 The field contains the names of the subject and issuer, a public key 818 associated with the subject, a validity period, and other associated 819 information. The fields are described in detail in section 4.1.2; 820 the tbsCertificate usually includes extensions, which are described 821 in section 4.2. 823 4.1.1.2 signatureAlgorithm 825 The signatureAlgorithm field contains the identifier for the 826 cryptographic algorithm used by the CA to sign this certificate. 827 [RFC 3279], [RFC 4055], and [RFC 4491] list supported signature 828 algorithms, but other signature algorithms MAY also be supported. 830 An algorithm identifier is defined by the following ASN.1 structure: 832 AlgorithmIdentifier ::= SEQUENCE { 833 algorithm OBJECT IDENTIFIER, 834 parameters ANY DEFINED BY algorithm OPTIONAL } 836 The algorithm identifier is used to identify a cryptographic 837 algorithm. The OBJECT IDENTIFIER component identifies the algorithm 838 (such as DSA with SHA-1). The contents of the optional parameters 839 field will vary according to the algorithm identified. 841 This field MUST contain the same algorithm identifier as the 842 signature field in the sequence tbsCertificate (section 4.1.2.3). 844 4.1.1.3 signatureValue 846 The signatureValue field contains a digital signature computed upon 847 the ASN.1 DER encoded tbsCertificate. The ASN.1 DER encoded 848 tbsCertificate is used as the input to the signature function. This 849 signature value is encoded as a BIT STRING and included in the 850 signature field. The details of this process are specified for each 851 of the algorithms listed in [RFC 3279], [RFC 4055], and [RFC 4491]. 853 By generating this signature, a CA certifies the validity of the 854 information in the tbsCertificate field. In particular, the CA 855 certifies the binding between the public key material and the subject 856 of the certificate. 858 4.1.2 TBSCertificate 860 The sequence TBSCertificate contains information associated with the 861 subject of the certificate and the CA that issued it. Every 862 TBSCertificate contains the names of the subject and issuer, a public 863 key associated with the subject, a validity period, a version number, 864 and a serial number; some MAY contain optional unique identifier 865 fields. The remainder of this section describes the syntax and 866 semantics of these fields. A TBSCertificate usually includes 867 extensions. Extensions for the Internet PKI are described in section 868 4.2. 870 4.1.2.1 Version 872 This field describes the version of the encoded certificate. When 873 extensions are used, as expected in this profile, version MUST be 3 874 (value is 2). If no extensions are present, but a UniqueIdentifier 875 is present, the version SHOULD be 2 (value is 1); however version MAY 876 be 3. If only basic fields are present, the version SHOULD be 1 (the 877 value is omitted from the certificate as the default value); however 878 the version MAY be 2 or 3. 880 Implementations SHOULD be prepared to accept any version certificate. 881 At a minimum, conforming implementations MUST recognize version 3 882 certificates. 884 Generation of version 2 certificates is not expected by 885 implementations based on this profile. 887 4.1.2.2 Serial number 889 The serial number MUST be a positive integer assigned by the CA to 890 each certificate. It MUST be unique for each certificate issued by a 891 given CA (i.e., the issuer name and serial number identify a unique 892 certificate). CAs MUST force the serialNumber to be a non-negative 893 integer. 895 Given the uniqueness requirements above, serial numbers can be 896 expected to contain long integers. Certificate users MUST be able to 897 handle serialNumber values up to 20 octets. Conforming CAs MUST NOT 898 use serialNumber values longer than 20 octets. 900 Note: Non-conforming CAs may issue certificates with serial numbers 901 that are negative, or zero. Certificate users SHOULD be prepared to 902 gracefully handle such certificates. 904 4.1.2.3 Signature 906 This field contains the algorithm identifier for the algorithm used 907 by the CA to sign the certificate. 909 This field MUST contain the same algorithm identifier as the 910 signatureAlgorithm field in the sequence Certificate (section 911 4.1.1.2). The contents of the optional parameters field will vary 912 according to the algorithm identified. [RFC 3279], [RFC 4055], and 913 [RFC 4491] list supported signature algorithms, but other signature 914 algorithms MAY also be supported. 916 4.1.2.4 Issuer 918 The issuer field identifies the entity that has signed and issued the 919 certificate. The issuer field MUST contain a non-empty distinguished 920 name (DN). The issuer field is defined as the X.501 type Name 921 [X.501]. Name is defined by the following ASN.1 structures: 923 Name ::= CHOICE { -- only one possibility for now -- 924 rdnSequence RDNSequence } 926 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 928 RelativeDistinguishedName ::= 929 SET SIZE (1..MAX) OF AttributeTypeAndValue 931 AttributeTypeAndValue ::= SEQUENCE { 932 type AttributeType, 933 value AttributeValue } 935 AttributeType ::= OBJECT IDENTIFIER 937 AttributeValue ::= ANY -- DEFINED BY AttributeType 939 DirectoryString ::= CHOICE { 940 teletexString TeletexString (SIZE (1..MAX)), 941 printableString PrintableString (SIZE (1..MAX)), 942 universalString UniversalString (SIZE (1..MAX)), 943 utf8String UTF8String (SIZE (1..MAX)), 944 bmpString BMPString (SIZE (1..MAX)) } 946 The Name describes a hierarchical name composed of attributes, such 947 as country name, and corresponding values, such as US. The type of 948 the component AttributeValue is determined by the AttributeType; in 949 general it will be a DirectoryString. 951 The DirectoryString type is defined as a choice of PrintableString, 952 TeletexString, BMPString, UTF8String, and UniversalString. CAs 953 conforming to this profile MUST use either the PrintableString or 954 UTF8String encoding of DirectoryString, with two exceptions. When 955 CAs have previously issued certificates with issuer fields with 956 attributes encoded using TeletexString, BMPString, or 957 UniversalString, then the CA MAY continue to use these encodings of 958 the DirectoryString to preserve backward compatibility. Also, new 959 CAs that are added to a domain where existing CAs issue certificates 960 with issuer fields with attributes encoded using TeletexString, 961 BMPString, or UniversalString MAY encode attributes that they share 962 with the existing CAs using the same encodings as the existing CAs 963 use. 965 As noted above, distinguished names are composed of attributes. This 966 specification does not restrict the set of attribute types that may 967 appear in names. However, conforming implementations MUST be 968 prepared to receive certificates with issuer names containing the set 969 of attribute types defined below. This specification RECOMMENDS 970 support for additional attribute types. 972 Standard sets of attributes have been defined in the X.500 series of 973 specifications [X.520]. Implementations of this specification MUST 974 be prepared to receive the following standard attribute types in 975 issuer and subject (section 4.1.2.6) names: 977 * country, 978 * organization, 979 * organizational unit, 980 * distinguished name qualifier, 981 * state or province name, 982 * common name (e.g., "Susan Housley"), and 983 * serial number. 985 In addition, implementations of this specification SHOULD be prepared 986 to receive the following standard attribute types in issuer and 987 subject names: 989 * locality, 990 * title, 991 * surname, 992 * given name, 993 * initials, 994 * pseudonym, and 995 * generation qualifier (e.g., "Jr.", "3rd", or "IV"). 997 The syntax and associated object identifiers (OIDs) for these 998 attribute types are provided in the ASN.1 modules in appendix A. 1000 In addition, implementations of this specification MUST be prepared 1001 to receive the domainComponent attribute, as defined in [RFC 4519]. 1002 The Domain Name System (DNS) provides a hierarchical resource 1003 labeling system. This attribute provides a convenient mechanism for 1004 organizations that wish to use DNs that parallel their DNS names. 1005 This is not a replacement for the dNSName component of the 1006 alternative name extensions. Implementations are not required to 1007 convert such names into DNS names. The syntax and associated OID for 1008 this attribute type are provided in the ASN.1 modules in appendix A. 1009 Rules for encoding internationalized domain names for use with the 1010 domainComponent attribute type are specified in section 7.3. 1012 Certificate users MUST be prepared to process the issuer 1013 distinguished name and subject distinguished name (section 4.1.2.6) 1014 fields to perform name chaining for certification path validation 1015 (section 6). Name chaining is performed by matching the issuer 1016 distinguished name in one certificate with the subject name in a CA 1017 certificate. Rules for comparing distinguished names are specified 1018 in section 7.1. If the names in the issuer and subject field in a 1019 certificate match according to the rules specified in section 7.1 1020 then the certificate is self-issued. 1022 4.1.2.5 Validity 1024 The certificate validity period is the time interval during which the 1025 CA warrants that it will maintain information about the status of the 1026 certificate. The field is represented as a SEQUENCE of two dates: 1027 the date on which the certificate validity period begins (notBefore) 1028 and the date on which the certificate validity period ends 1029 (notAfter). Both notBefore and notAfter may be encoded as UTCTime or 1030 GeneralizedTime. 1032 CAs conforming to this profile MUST always encode certificate 1033 validity dates through the year 2049 as UTCTime; certificate validity 1034 dates in 2050 or later MUST be encoded as GeneralizedTime. 1035 Conforming applications MUST be able to process validity dates that 1036 are encoded in either UTCTime or GeneralizedTime. 1038 The validity period for a certificate is the period of time from 1039 notBefore through notAfter, inclusive. 1041 In some situations, devices are given certificates for which no good 1042 expiration date can be assigned. For example, a device could be 1043 issued a certificate that binds its model and serial number to its 1044 public key; such a certificate is intended to be used for the entire 1045 lifetime of the device. 1047 To indicate that a certificate has no well defined expiration date, 1048 the notAfter SHOULD be assigned the GeneralizedTime value of 1049 99991231235959Z. 1051 When the issuer is not be able to maintain status information until 1052 the notAfter date (including when the notAfter date is 1053 99991231235959Z), the issuer MUST ensure that no valid certification 1054 path exists for the certificate after maintenance of status 1055 information is terminated. This may be accomplished by expiration or 1056 revocation of all CA certificates containing the public key used to 1057 verify the signature on the certificate and discontinuing use of the 1058 public key used to verify the signature on the certificate as a trust 1059 anchor. 1061 4.1.2.5.1 UTCTime 1063 The universal time type, UTCTime, is a standard ASN.1 type intended 1064 for representation of dates and time. UTCTime specifies the year 1065 through the two low order digits and time is specified to the 1066 precision of one minute or one second. UTCTime includes either Z 1067 (for Zulu, or Greenwich Mean Time) or a time differential. 1069 For the purposes of this profile, UTCTime values MUST be expressed in 1070 Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are 1071 YYMMDDHHMMSSZ), even where the number of seconds is zero. Conforming 1072 systems MUST interpret the year field (YY) as follows: 1074 Where YY is greater than or equal to 50, the year SHALL be 1075 interpreted as 19YY; and 1077 Where YY is less than 50, the year SHALL be interpreted as 20YY. 1079 4.1.2.5.2 GeneralizedTime 1081 The generalized time type, GeneralizedTime, is a standard ASN.1 type 1082 for variable precision representation of time. Optionally, the 1083 GeneralizedTime field can include a representation of the time 1084 differential between local and Greenwich Mean Time. 1086 For the purposes of this profile, GeneralizedTime values MUST be 1087 expressed in Greenwich Mean Time (Zulu) and MUST include seconds 1088 (i.e., times are YYYYMMDDHHMMSSZ), even where the number of seconds 1089 is zero. GeneralizedTime values MUST NOT include fractional seconds. 1091 4.1.2.6 Subject 1093 The subject field identifies the entity associated with the public 1094 key stored in the subject public key field. The subject name MAY be 1095 carried in the subject field and/or the subjectAltName extension. If 1096 the subject is a CA (e.g., the basic constraints extension, as 1097 discussed in section 4.2.1.9, is present and the value of cA is 1098 TRUE), then the subject field MUST be populated with a non-empty 1099 distinguished name matching the contents of the issuer field (section 1100 4.1.2.4) in all certificates issued by the subject CA. If the 1101 subject is a CRL issuer (e.g., the key usage extension, as discussed 1102 in section 4.2.1.3, is present and the value of cRLSign is TRUE) then 1103 the subject field MUST be populated with a non-empty distinguished 1104 name matching the contents of the issuer field (section 5.1.2.3) in 1105 all CRLs issued by the subject CRL issuer. If subject naming 1106 information is present only in the subjectAltName extension (e.g., a 1107 key bound only to an email address or URI), then the subject name 1108 MUST be an empty sequence and the subjectAltName extension MUST be 1109 critical. 1111 Where it is non-empty, the subject field MUST contain an X.500 1112 distinguished name (DN). The DN MUST be unique for each subject 1113 entity certified by the one CA as defined by the issuer name field. 1114 A CA MAY issue more than one certificate with the same DN to the same 1115 subject entity. 1117 The subject name field is defined as the X.501 type Name. 1118 Implementation requirements for this field are those defined for the 1119 issuer field (section 4.1.2.4). Implementations of this 1120 specification MUST be prepared to receive subject names containing 1121 the attribute types required for the issuer field. Implementations 1122 of this specification SHOULD be prepared to receive subject names 1123 containing the recommended attribute types for the issuer field. The 1124 syntax and associated object identifiers (OIDs) for these attribute 1125 types are provided in the ASN.1 modules in appendix A. 1126 Implementations of this specification MAY use the comparison rules in 1127 section 7.1 to process unfamiliar attribute types (i.e., for name 1128 chaining) whose attribute values use one of the encoding options from 1129 DirectoryString. Binary comparison should be used when unfamiliar 1130 attribute types include attribute values with encoding options other 1131 than those found in DirectoryString. This allows implementations to 1132 process certificates with unfamiliar attributes in the subject name. 1134 When encoding attribute values of type DirectoryString, conforming 1135 CAs MUST use PrintableString or UTF8String encoding, except that: 1137 (a) When the subject of the certificate is a CA the subject field 1138 MUST be encoded in the same way as it is encoded in the issuer 1139 field (section 4.1.2.4) in all certificates issued by the subject 1140 CA. Thus, if the subject CA encodes attributes in the issuer 1141 fields of certificates that it issues using the TeletexString, 1142 BMPString, or UniversalString encodings, then the subject field of 1143 certificates issued to that CA MUST use the same encoding. 1145 (b) When the subject of the certificate is a CRL issuer the 1146 subject field MUST be encoded in the same way as it is encoded in 1147 the issuer field (section 5.1.2.3) in all CRLs issued by the 1148 subject CRL issuer. 1150 (c) TeletexString, BMPString, and UniversalString are included 1151 for backward compatibility, and SHOULD NOT be used for 1152 certificates for new subjects. However, these types MAY be used 1153 in certificates where the name was previously established, 1154 including cases in which a new certificate is being issued to an 1155 existing subject or a certificate is being issued to a new subject 1156 where the attributes being encoded have been previously 1157 established in certificates issued to other subjects. Certificate 1158 users SHOULD be prepared to receive certificates with these types. 1160 Legacy implementations exist where an electronic mail address is 1161 embedded in the subject distinguished name as an emailAddress 1162 attribute [RFC 2985]. The attribute value for emailAddress is of 1163 type IA5String to permit inclusion of the character '@', which is not 1164 part of the PrintableString character set. emailAddress attribute 1165 values are not case-sensitive (e.g., "subscriber@example.com" is the 1166 same as "SUBSCRIBER@EXAMPLE.COM"). 1168 Conforming implementations generating new certificates with 1169 electronic mail addresses MUST use the rfc822Name in the subject 1170 alternative name extension (section 4.2.1.6) to describe such 1171 identities. Simultaneous inclusion of the emailAddress attribute in 1172 the subject distinguished name to support legacy implementations is 1173 deprecated but permitted. 1175 4.1.2.7 Subject Public Key Info 1177 This field is used to carry the public key and identify the algorithm 1178 with which the key is used (e.g., RSA, DSA, or Diffie-Hellman). The 1179 algorithm is identified using the AlgorithmIdentifier structure 1180 specified in section 4.1.1.2. The object identifiers for the 1181 supported algorithms and the methods for encoding the public key 1182 materials (public key and parameters) are specified in [RFC 3279], 1183 [RFC 4055], and [RFC 4491]. 1185 4.1.2.8 Unique Identifiers 1187 These fields MUST only appear if the version is 2 or 3 (section 1188 4.1.2.1). These fields MUST NOT appear if the version is 1. The 1189 subject and issuer unique identifiers are present in the certificate 1190 to handle the possibility of reuse of subject and/or issuer names 1191 over time. This profile RECOMMENDS that names not be reused for 1192 different entities and that Internet certificates not make use of 1193 unique identifiers. CAs conforming to this profile MUST NOT generate 1194 certificates with unique identifiers. Applications conforming to 1195 this profile SHOULD be capable of parsing certificates that include 1196 unique identifiers, but there are no processing requirements 1197 associated with the unique identifiers. 1199 4.1.2.9 Extensions 1201 This field MUST only appear if the version is 3 (section 4.1.2.1). 1202 If present, this field is a SEQUENCE of one or more certificate 1203 extensions. The format and content of certificate extensions in the 1204 Internet PKI are defined in section 4.2. 1206 4.2 Certificate Extensions 1208 The extensions defined for X.509 v3 certificates provide methods for 1209 associating additional attributes with users or public keys and for 1210 managing relationships between CAs. The X.509 v3 certificate format 1211 also allows communities to define private extensions to carry 1212 information unique to those communities. Each extension in a 1213 certificate is designated as either critical or non-critical. A 1214 certificate using system MUST reject the certificate if it encounters 1215 a critical extension it does not recognize or a critical extension 1216 that contains information that it cannot process. A non-critical 1217 extension MAY be ignored if it is not recognized, but MUST be 1218 processed if it is recognized. The following sections present 1219 recommended extensions used within Internet certificates and standard 1220 locations for information. Communities may elect to use additional 1221 extensions; however, caution ought to be exercised in adopting any 1222 critical extensions in certificates that might prevent use in a 1223 general context. 1225 Each extension includes an OID and an ASN.1 structure. When an 1226 extension appears in a certificate, the OID appears as the field 1227 extnID and the corresponding ASN.1 DER encoded structure is the value 1228 of the octet string extnValue. A certificate MUST NOT include more 1229 than one instance of a particular extension. For example, a 1230 certificate may contain only one authority key identifier extension 1231 (section 4.2.1.1). An extension includes the boolean critical, with 1232 a default value of FALSE. The text for each extension specifies the 1233 acceptable values for the critical field for CAs conforming to this 1234 profile. 1236 Conforming CAs MUST support key identifiers (sections 4.2.1.1 and 1237 4.2.1.2), basic constraints (section 4.2.1.9), key usage (section 1238 4.2.1.3), and certificate policies (section 4.2.1.4) extensions. If 1239 the CA issues certificates with an empty sequence for the subject 1240 field, the CA MUST support the subject alternative name extension 1241 (section 4.2.1.6). Support for the remaining extensions is OPTIONAL. 1242 Conforming CAs MAY support extensions that are not identified within 1243 this specification; certificate issuers are cautioned that marking 1244 such extensions as critical may inhibit interoperability. 1246 At a minimum, applications conforming to this profile MUST recognize 1247 the following extensions: key usage (section 4.2.1.3), certificate 1248 policies (section 4.2.1.4), the subject alternative name (section 1249 4.2.1.6), basic constraints (section 4.2.1.9), name constraints 1250 (section 4.2.1.10), policy constraints (section 4.2.1.11), extended 1251 key usage (section 4.2.1.12), and inhibit anyPolicy (section 1252 4.2.1.14). 1254 In addition, applications conforming to this profile SHOULD recognize 1255 the authority and subject key identifier (sections 4.2.1.1 and 1256 4.2.1.2), and policy mappings (section 4.2.1.5) extensions. 1258 4.2.1 Standard Extensions 1260 This section identifies standard certificate extensions defined in 1261 [X.509] for use in the Internet PKI. Each extension is associated 1262 with an OID defined in [X.509]. These OIDs are members of the id-ce 1263 arc, which is defined by the following: 1265 id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 } 1267 4.2.1.1 Authority Key Identifier 1269 The authority key identifier extension provides a means of 1270 identifying the public key corresponding to the private key used to 1271 sign a certificate. This extension is used where an issuer has 1272 multiple signing keys (either due to multiple concurrent key pairs or 1273 due to changeover). The identification MAY be based on either the 1274 key identifier (the subject key identifier in the issuer's 1275 certificate) or on the issuer name and serial number. 1277 The keyIdentifier field of the authorityKeyIdentifier extension MUST 1278 be included in all certificates generated by conforming CAs to 1279 facilitate certification path construction. There is one exception; 1280 where a CA distributes its public key in the form of a "self-signed" 1281 certificate, the authority key identifier MAY be omitted. The 1282 signature on a self-signed certificate is generated with the private 1283 key associated with the certificate's subject public key. (This 1284 proves that the issuer possesses both the public and private keys.) 1285 In this case, the subject and authority key identifiers would be 1286 identical, but only the subject key identifier is needed for 1287 certification path building. 1289 The value of the keyIdentifier field SHOULD be derived from the 1290 public key used to verify the certificate's signature or a method 1291 that generates unique values. Two common methods for generating key 1292 identifiers from the public key are described in section 4.2.1.2. 1293 Where a key identifier has not been previously established, this 1294 specification RECOMMENDS use of one of these methods for generating 1295 keyIdentifiers or use of a similar method that uses a different hash 1296 algorithm. Where a key identifier has been previously established, 1297 the CA SHOULD use the previously established identifier. 1299 This profile RECOMMENDS support for the key identifier method by all 1300 certificate users. 1302 Conforming CAs MUST mark this extension non-critical. 1304 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 1306 AuthorityKeyIdentifier ::= SEQUENCE { 1307 keyIdentifier [0] KeyIdentifier OPTIONAL, 1308 authorityCertIssuer [1] GeneralNames OPTIONAL, 1309 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 1311 KeyIdentifier ::= OCTET STRING 1313 4.2.1.2 Subject Key Identifier 1315 The subject key identifier extension provides a means of identifying 1316 certificates that contain a particular public key. 1318 To facilitate certification path construction, this extension MUST 1319 appear in all conforming CA certificates, that is, all certificates 1320 including the basic constraints extension (section 4.2.1.9) where the 1321 value of cA is TRUE. In conforming CA certificates, the value of the 1322 subject key identifier MUST be the value placed in the key identifier 1323 field of the Authority Key Identifier extension (section 4.2.1.1) of 1324 certificates issued by the subject of this certificate. Applications 1325 are not required to verify that key identifiers match when performing 1326 certification path validation. 1328 For CA certificates, subject key identifiers SHOULD be derived from 1329 the public key or a method that generates unique values. Two common 1330 methods for generating key identifiers from the public key are: 1332 (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the 1333 value of the BIT STRING subjectPublicKey (excluding the tag, 1334 length, and number of unused bits). 1336 (2) The keyIdentifier is composed of a four bit type field with 1337 the value 0100 followed by the least significant 60 bits of the 1338 SHA-1 hash of the value of the BIT STRING subjectPublicKey 1339 (excluding the tag, length, and number of unused bits). 1341 Other methods of generating unique numbers are also acceptable. 1343 For end entity certificates, the subject key identifier extension 1344 provides a means for identifying certificates containing the 1345 particular public key used in an application. Where an end entity 1346 has obtained multiple certificates, especially from multiple CAs, the 1347 subject key identifier provides a means to quickly identify the set 1348 of certificates containing a particular public key. To assist 1349 applications in identifying the appropriate end entity certificate, 1350 this extension SHOULD be included in all end entity certificates. 1352 For end entity certificates, subject key identifiers SHOULD be 1353 derived from the public key. Two common methods for generating key 1354 identifiers from the public key are identified above. 1356 Where a key identifier has not been previously established, this 1357 specification RECOMMENDS use of one of these methods for generating 1358 keyIdentifiers or use of a similar method that uses a different hash 1359 algorithm. Where a key identifier has been previously established, 1360 the CA SHOULD use the previously established identifier. 1362 Conforming CAs MUST mark this extension non-critical. 1364 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 1366 SubjectKeyIdentifier ::= KeyIdentifier 1368 4.2.1.3 Key Usage 1370 The key usage extension defines the purpose (e.g., encipherment, 1371 signature, certificate signing) of the key contained in the 1372 certificate. The usage restriction might be employed when a key that 1373 could be used for more than one operation is to be restricted. For 1374 example, when an RSA key should be used only to verify signatures on 1375 objects other than public key certificates and CRLs, the 1376 digitalSignature and/or nonRepudiation bits would be asserted. 1377 Likewise, when an RSA key should be used only for key management, the 1378 keyEncipherment bit would be asserted. 1380 Conforming CAs MUST include this extension in certificates that 1381 contain public keys that are used to validate digital signatures on 1382 other public key certificates or CRLs. When present, conforming CAs 1383 SHOULD mark this extension as critical. 1385 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 1387 KeyUsage ::= BIT STRING { 1388 digitalSignature (0), 1389 nonRepudiation (1), -- recent editions of X.509 have 1390 -- renamed this bit to contentCommitment 1391 keyEncipherment (2), 1392 dataEncipherment (3), 1393 keyAgreement (4), 1394 keyCertSign (5), 1395 cRLSign (6), 1396 encipherOnly (7), 1397 decipherOnly (8) } 1399 Bits in the KeyUsage type are used as follows: 1401 The digitalSignature bit is asserted when the subject public key 1402 is used for verifying digital signatures, other than signatures on 1403 certificates (bit 5) and CRLs (bit 6), such as those used in an 1404 entity authentication service, a data origin authentication 1405 service, and/or an integrity service. 1407 The nonRepudiation bit is asserted when the subject public key is 1408 used to verify digital signatures, other than signatures on 1409 certificates (bit 5) and CRLs (bit 6), used to provide a non- 1410 repudiation service that protects against the signing entity 1411 falsely denying some action. In the case of later conflict, a 1412 reliable third party may determine the authenticity of the signed 1413 data. (Note that recent editions of X.509 have renamed the 1414 nonRepudiation bit to contentCommitment.) 1416 The keyEncipherment bit is asserted when the subject public key is 1417 used for enciphering private or secret keys, i.e., for key 1418 transport. For example, this bit shall be set when an RSA public 1419 key is to be used for encrypting a symmetric content-decryption 1420 key or an asymmetric private key. 1422 The dataEncipherment bit is asserted when the subject public key 1423 is used for directly enciphering raw user data without the use of 1424 an intermediate symmetric cipher. Note that the use of this bit 1425 is extremely uncommon; almost all applications use key transport 1426 or key agreement to establish a symmetric key. 1428 The keyAgreement bit is asserted when the subject public key is 1429 used for key agreement. For example, when a Diffie-Hellman key is 1430 to be used for key management, then this bit is set. 1432 The keyCertSign bit is asserted when the subject public key is 1433 used for verifying signatures on public key certificates. If the 1434 keyCertSign bit is asserted, then the cA bit in the basic 1435 constraints extension (section 4.2.1.9) MUST also be asserted. 1437 The cRLSign bit is asserted when the subject public key is used 1438 for verifying signatures on certificate revocation lists (e.g., 1439 CRLs, delta CRLs, or ARLs). 1441 The meaning of the encipherOnly bit is undefined in the absence of 1442 the keyAgreement bit. When the encipherOnly bit is asserted and 1443 the keyAgreement bit is also set, the subject public key may be 1444 used only for enciphering data while performing key agreement. 1446 The meaning of the decipherOnly bit is undefined in the absence of 1447 the keyAgreement bit. When the decipherOnly bit is asserted and 1448 the keyAgreement bit is also set, the subject public key may be 1449 used only for deciphering data while performing key agreement. 1451 If the keyUsage extension is present, then the subject public key 1452 MUST NOT be used to verify signatures on certificates or CRLs unless 1453 the corresponding keyCertSign or cRLSign bit is set. If the subject 1454 public key is only to be used for verifying signatures on 1455 certificates and/or CRLs, then the digitalSignature and 1456 nonRepudiation bits SHOULD NOT be set. However, the digitalSignature 1457 and/or nonRepudiation bits MAY be set in addition to the keyCertSign 1458 and/or cRLSign bits if the subject public key is to be used to verify 1459 signatures on certificates and/or CRLs as well as other objects. 1461 Combining the nonRepudiation bit in the keyUsage certificate 1462 extension with other keyUsage bits may have security implications 1463 depending on the context in which the certificate is to be used. 1464 Further distinctions between the digitalSignature and nonRepudiation 1465 bits may be provided in specific certificate policies. 1467 This profile does not restrict the combinations of bits that may be 1468 set in an instantiation of the keyUsage extension. However, 1469 appropriate values for keyUsage extensions for particular algorithms 1470 are specified in [RFC 3279], [RFC 4055], and [RFC 4491]. When the 1471 keyUsage extension appears in a certificate, at least one of the bits 1472 MUST be set to 1. 1474 4.2.1.4 Certificate Policies 1476 The certificate policies extension contains a sequence of one or more 1477 policy information terms, each of which consists of an object 1478 identifier (OID) and optional qualifiers. Optional qualifiers, which 1479 MAY be present, are not expected to change the definition of the 1480 policy. A certificate policy OID MUST NOT appear more than once in a 1481 certificate policies extension. 1483 In an end entity certificate, these policy information terms indicate 1484 the policy under which the certificate has been issued and the 1485 purposes for which the certificate may be used. In a CA certificate, 1486 these policy information terms limit the set of policies for 1487 certification paths that include this certificate. When a CA does 1488 not wish to limit the set of policies for certification paths that 1489 include this certificate, it MAY assert the special policy anyPolicy, 1490 with a value of { 2 5 29 32 0 }. 1492 Applications with specific policy requirements are expected to have a 1493 list of those policies that they will accept and to compare the 1494 policy OIDs in the certificate to that list. If this extension is 1495 critical, the path validation software MUST be able to interpret this 1496 extension (including the optional qualifier), or MUST reject the 1497 certificate. 1499 To promote interoperability, this profile RECOMMENDS that policy 1500 information terms consist of only an OID. Where an OID alone is 1501 insufficient, this profile strongly recommends that use of qualifiers 1502 be limited to those identified in this section. When qualifiers are 1503 used with the special policy anyPolicy, they MUST be limited to the 1504 qualifiers identified in this section. Only those qualifiers 1505 returned as a result of path validation are considered. 1507 This specification defines two policy qualifier types for use by 1508 certificate policy writers and certificate issuers. The qualifier 1509 types are the CPS Pointer and User Notice qualifiers. 1511 The CPS Pointer qualifier contains a pointer to a Certification 1512 Practice Statement (CPS) published by the CA. The pointer is in the 1513 form of a URI. Processing requirements for this qualifier are a 1514 local matter. No action is mandated by this specification regardless 1515 of the criticality value asserted for the extension. 1517 User notice is intended for display to a relying party when a 1518 certificate is used. Only user notices returned as a result of path 1519 validation are intended for display to the user. If a notice is 1520 duplicated only one copy need be displayed. To prevent such 1521 duplication, this qualifier SHOULD only be present in end entity 1522 certificates and CA certificates issued to other organizations. 1524 The user notice has two optional fields: the noticeRef field and the 1525 explicitText field. Conforming CAs SHOULD NOT use the noticeRef 1526 option. 1528 The noticeRef field, if used, names an organization and 1529 identifies, by number, a particular textual statement prepared by 1530 that organization. For example, it might identify the 1531 organization "CertsRUs" and notice number 1. In a typical 1532 implementation, the application software will have a notice file 1533 containing the current set of notices for CertsRUs; the 1534 application will extract the notice text from the file and display 1535 it. Messages MAY be multilingual, allowing the software to select 1536 the particular language message for its own environment. 1538 An explicitText field includes the textual statement directly in 1539 the certificate. The explicitText field is a string with a 1540 maximum size of 200 characters. Conforming CAs SHOULD use the 1541 UTF8String encoding for explicitText, but MAY use IA5String. 1543 Conforming CAs MUST NOT encode explicitText as VisibleString or 1544 BMPString. The explicitText string SHOULD NOT include any control 1545 characters (e.g., U+0000 to U+001F and U+007F to U+009F). When 1546 the UTF8String encoding is used, all character sequences SHOULD be 1547 normalized according to Unicode normalization form C (NFC) [NFC]. 1549 If both the noticeRef and explicitText options are included in the 1550 one qualifier and if the application software can locate the notice 1551 text indicated by the noticeRef option, then that text SHOULD be 1552 displayed; otherwise, the explicitText string SHOULD be displayed. 1554 Note: While the explicitText has a maximum size of 200 characters, 1555 some non-conforming CAs exceed this limit. Therefore, certificate 1556 users SHOULD gracefully handle explicitText with more than 200 1557 characters. 1559 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 1561 anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificate-policies 0 } 1563 certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 1565 PolicyInformation ::= SEQUENCE { 1566 policyIdentifier CertPolicyId, 1567 policyQualifiers SEQUENCE SIZE (1..MAX) OF 1568 PolicyQualifierInfo OPTIONAL } 1570 CertPolicyId ::= OBJECT IDENTIFIER 1572 PolicyQualifierInfo ::= SEQUENCE { 1573 policyQualifierId PolicyQualifierId, 1574 qualifier ANY DEFINED BY policyQualifierId } 1576 -- policyQualifierIds for Internet policy qualifiers 1578 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 1579 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 1580 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 1582 PolicyQualifierId ::= OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) 1584 Qualifier ::= CHOICE { 1585 cPSuri CPSuri, 1586 userNotice UserNotice } 1588 CPSuri ::= IA5String 1589 UserNotice ::= SEQUENCE { 1590 noticeRef NoticeReference OPTIONAL, 1591 explicitText DisplayText OPTIONAL } 1593 NoticeReference ::= SEQUENCE { 1594 organization DisplayText, 1595 noticeNumbers SEQUENCE OF INTEGER } 1597 DisplayText ::= CHOICE { 1598 ia5String IA5String (SIZE (1..200)), 1599 visibleString VisibleString (SIZE (1..200)), 1600 bmpString BMPString (SIZE (1..200)), 1601 utf8String UTF8String (SIZE (1..200)) } 1603 4.2.1.5 Policy Mappings 1605 This extension is used in CA certificates. It lists one or more 1606 pairs of OIDs; each pair includes an issuerDomainPolicy and a 1607 subjectDomainPolicy. The pairing indicates the issuing CA considers 1608 its issuerDomainPolicy equivalent to the subject CA's 1609 subjectDomainPolicy. 1611 The issuing CA's users might accept an issuerDomainPolicy for certain 1612 applications. The policy mapping defines the list of policies 1613 associated with the subject CA that may be accepted as comparable to 1614 the issuerDomainPolicy. 1616 Each issuerDomainPolicy named in the policy mappings extension SHOULD 1617 also be asserted in a certificate policies extension in the same 1618 certificate. Policies MUST NOT be mapped either to or from the 1619 special value anyPolicy (section 4.2.1.4). 1621 In general, certificate policies that appear in the 1622 issuerDomainPolicy field of the policy mappings extension are not 1623 considered acceptable policies for inclusion in subsequent 1624 certificates in the certification path. In some circumstances, a CA 1625 may wish to map from one policy (p1) to another (p2), but still wants 1626 the issuerDomainPolicy (p1) to be considered acceptable for inclusion 1627 in subsequent certificates. This may occur, for example, if the CA 1628 is in the process of transitioning from the use of policy p1 to the 1629 use of policy p2 and has valid certificates that were issued under 1630 each of the policies. A CA may indicate this by including two policy 1631 mappings in the CA certificates that it issues. Each policy mapping 1632 would have an issuerDomainPolicy of p1; one policy mapping would have 1633 a subjectDomainPolicy of p1 and the other would have a 1634 subjectDomainPolicy of p2. 1636 This extension MAY be supported by CAs and/or applications. 1637 Conforming CAs SHOULD mark this extension critical. 1639 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 1641 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 1642 issuerDomainPolicy CertPolicyId, 1643 subjectDomainPolicy CertPolicyId } 1645 4.2.1.6 Subject Alternative Name 1647 The subject alternative name extension allows identities to be bound 1648 to the subject of the certificate. These identities may be included 1649 in addition to or in place of the identity in the subject field of 1650 the certificate. Defined options include an Internet electronic mail 1651 address, a DNS name, an IP address, and a uniform resource identifier 1652 (URI). Other options exist, including completely local definitions. 1653 Multiple name forms, and multiple instances of each name form, MAY be 1654 included. Whenever such identities are to be bound into a 1655 certificate, the subject alternative name (or issuer alternative 1656 name) extension MUST be used; however, a DNS name MAY also be 1657 represented in the subject field using the domainComponent attribute 1658 as described in section 4.1.2.4. Note that where such names are 1659 represented in the subject field implementations are not required to 1660 convert them into DNS names. 1662 Because the subject alternative name is considered to be definitively 1663 bound to the public key, all parts of the subject alternative name 1664 MUST be verified by the CA. 1666 Further, if the only subject identity included in the certificate is 1667 an alternative name form (e.g., an electronic mail address), then the 1668 subject distinguished name MUST be empty (an empty sequence), and the 1669 subjectAltName extension MUST be present. If the subject field 1670 contains an empty sequence, then the issuing CA MUST include a 1671 subjectAltName extension that is marked as critical. When including 1672 the subjectAltName extension in a certificate that has a non-empty 1673 subject distinguished name, conforming CAs SHOULD mark the 1674 subjectAltName extension as non-critical. 1676 When the subjectAltName extension contains an Internet mail address, 1677 the address MUST be stored in the rfc822Name. The format of an 1678 rfc822Name is a "Mailbox" as defined in section 4.1.2 of [RFC 2821]. 1679 A Mailbox has the form "Local-part@Domain". Note that a Mailbox has 1680 no phrase (such as a common name) before it, has no comment (text 1681 surrounded in parentheses) after it, and is not surrounded by "<" and 1682 ">". Rules for encoding Internet mail addresses that include 1683 internationalized domain names are specified in section 7.5. 1685 When the subjectAltName extension contains a iPAddress, the address 1686 MUST be stored in the octet string in "network byte order," as 1687 specified in [RFC 791]. The least significant bit (LSB) of each 1688 octet is the LSB of the corresponding byte in the network address. 1689 For IP Version 4, as specified in RFC 791, the octet string MUST 1690 contain exactly four octets. For IP Version 6, as specified in 1691 [RFC 2460], the octet string MUST contain exactly sixteen octets. 1693 When the subjectAltName extension contains a domain name system 1694 label, the domain name MUST be stored in the dNSName (an IA5String). 1695 The name MUST be in the "preferred name syntax," as specified by 1696 section 3.5 of [RFC 1034] and as modified by section 2.1 of 1697 [RFC 1123]. Note that while upper and lower case letters are allowed 1698 in domain names, no significance is attached to the case. In 1699 addition, while the string " " is a legal domain name, subjectAltName 1700 extensions with a dNSName of " " MUST NOT be used. Finally, the use 1701 of the DNS representation for Internet mail addresses 1702 (subscriber.example.com instead of subscriber@example.com) MUST NOT 1703 be used; such identities are to be encoded as rfc822Name. Rules for 1704 encoding internationalized domain names are specified in section 7.2. 1706 When the subjectAltName extension contains a URI, the name MUST be 1707 stored in the uniformResourceIdentifier (an IA5String). The name 1708 MUST NOT be a relative URI, and it MUST follow the URI syntax and 1709 encoding rules specified in [RFC 3986]. The name MUST include both a 1710 scheme (e.g., "http" or "ftp") and a scheme-specific-part. URIs that 1711 include an authority ([RFC 3986], section 3.2) MUST include a fully 1712 qualified domain name or IP address as the host. Rules for encoding 1713 internationalized resource identifiers (IRIs) are specified in 1714 section 7.4. 1716 As specified in [RFC 3986], the scheme name is not case-sensitive 1717 (e.g., "http" is equivalent to "HTTP"). The host part, if present, 1718 is also not case-sensitive, but other components of the scheme- 1719 specific-part may be case-sensitive. Rules for comparing URIs are 1720 specified in section 7.4. 1722 When the subjectAltName extension contains a DN in the directoryName, 1723 the encoding rules are the same as those specified for the issuer 1724 field in section 4.1.2.4. The DN MUST be unique for each subject 1725 entity certified by the one CA as defined by the issuer name field. 1726 A CA MAY issue more than one certificate with the same DN to the same 1727 subject entity. 1729 The subjectAltName MAY carry additional name types through the use of 1730 the otherName field. The format and semantics of the name are 1731 indicated through the OBJECT IDENTIFIER in the type-id field. The 1732 name itself is conveyed as value field in otherName. For example, 1733 Kerberos [RFC 4120] format names can be encoded into the otherName, 1734 using using a Kerberos 5 principal name OID and a SEQUENCE of the 1735 Realm and the PrincipalName. 1737 Subject alternative names MAY be constrained in the same manner as 1738 subject distinguished names using the name constraints extension as 1739 described in section 4.2.1.10. 1741 If the subjectAltName extension is present, the sequence MUST contain 1742 at least one entry. Unlike the subject field, conforming CAs MUST 1743 NOT issue certificates with subjectAltNames containing empty 1744 GeneralName fields. For example, an rfc822Name is represented as an 1745 IA5String. While an empty string is a valid IA5String, such an 1746 rfc822Name is not permitted by this profile. The behavior of clients 1747 that encounter such a certificate when processing a certification 1748 path is not defined by this profile. 1750 Finally, the semantics of subject alternative names that include 1751 wildcard characters (e.g., as a placeholder for a set of names) are 1752 not addressed by this specification. Applications with specific 1753 requirements MAY use such names, but they must define the semantics. 1755 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 1757 SubjectAltName ::= GeneralNames 1759 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 1761 GeneralName ::= CHOICE { 1762 otherName [0] OtherName, 1763 rfc822Name [1] IA5String, 1764 dNSName [2] IA5String, 1765 x400Address [3] ORAddress, 1766 directoryName [4] Name, 1767 ediPartyName [5] EDIPartyName, 1768 uniformResourceIdentifier [6] IA5String, 1769 iPAddress [7] OCTET STRING, 1770 registeredID [8] OBJECT IDENTIFIER } 1772 OtherName ::= SEQUENCE { 1773 type-id OBJECT IDENTIFIER, 1774 value [0] EXPLICIT ANY DEFINED BY type-id } 1776 EDIPartyName ::= SEQUENCE { 1777 nameAssigner [0] DirectoryString OPTIONAL, 1778 partyName [1] DirectoryString } 1780 4.2.1.7 Issuer Alternative Name 1782 As with 4.2.1.6, this extension is used to associate Internet style 1783 identities with the certificate issuer. Issuer alternative name MUST 1784 be encoded as in 4.2.1.6. Issuer alternative names are not processed 1785 as part of the certification path validation algorithm in section 6. 1786 (That is, issuer alternative names are not used in name chaining and 1787 name constraints are not enforced.) 1789 Where present, conforming CAs SHOULD mark this extension non- 1790 critical. 1792 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 1794 IssuerAltName ::= GeneralNames 1796 4.2.1.8 Subject Directory Attributes 1798 The subject directory attributes extension is used to convey 1799 identification attributes (e.g., nationality) of the subject. The 1800 extension is defined as a sequence of one or more attributes. 1801 Conforming CAs MUST mark this extension non-critical. 1803 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 1805 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 1807 4.2.1.9 Basic Constraints 1809 The basic constraints extension identifies whether the subject of the 1810 certificate is a CA and the maximum depth of valid certification 1811 paths that include this certificate. 1813 The cA boolean indicates whether the certified public key may be used 1814 to verify certificate signatures. If the cA boolean is not asserted, 1815 then the keyCertSign bit in the key usage extension MUST NOT be 1816 asserted. If the basic constraints extension is not present in a 1817 version 3 certificate, or the extension is present but the cA boolean 1818 is not asserted, then the certified public key MUST NOT be used to 1819 verify certificate signatures. 1821 The pathLenConstraint field is meaningful only if the cA boolean is 1822 asserted and the key usage extension, if present, asserts the 1823 keyCertSign bit (section 4.2.1.3). In this case, it gives the 1824 maximum number of non-self-issued intermediate certificates that may 1825 follow this certificate in a valid certification path. (Note: The 1826 last certificate in the certification path is not an intermediate 1827 certificate, and is not included in this limit. Usually, the last 1828 certificate is an end entity certificate, but it can be a CA 1829 certificate.) A pathLenConstraint of zero indicates that no non- 1830 self-issued intermediate CA certificates may follow in a valid 1831 certification path. Where it appears, the pathLenConstraint field 1832 MUST be greater than or equal to zero. Where pathLenConstraint does 1833 not appear, no limit is imposed. 1835 Conforming CAs MUST include this extension in all CA certificates 1836 that contain public keys used to validate digital signatures on 1837 certificates and MUST mark the extension as critical in such 1838 certificates. This extension MAY appear as a critical or non- 1839 critical extension in CA certificates that contain public keys used 1840 exclusively for purposes other than validating digital signatures on 1841 certificates. Such CA certificates include ones that contain public 1842 keys used exclusively for validating digital signatures on CRLs and 1843 ones that contain key management public keys used with certificate 1844 enrollment protocols. This extension MAY appear as a critical or 1845 non-critical extension in end entity certificates. 1847 CAs MUST NOT include the pathLenConstraint field unless the cA 1848 boolean is asserted and the key usage extension asserts the 1849 keyCertSign bit. 1851 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 1853 BasicConstraints ::= SEQUENCE { 1854 cA BOOLEAN DEFAULT FALSE, 1855 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 1857 4.2.1.10 Name Constraints 1859 The name constraints extension, which MUST be used only in a CA 1860 certificate, indicates a name space within which all subject names in 1861 subsequent certificates in a certification path MUST be located. 1862 Restrictions apply to the subject distinguished name and apply to 1863 subject alternative names. Restrictions apply only when the 1864 specified name form is present. If no name of the type is in the 1865 certificate, the certificate is acceptable. 1867 Name constraints are not applied to self-issued certificates (unless 1868 the certificate is the final certificate in the path). (This could 1869 prevent CAs that use name constraints from employing self-issued 1870 certificates to implement key rollover.) 1872 Restrictions are defined in terms of permitted or excluded name 1873 subtrees. Any name matching a restriction in the excludedSubtrees 1874 field is invalid regardless of information appearing in the 1875 permittedSubtrees. Conforming CAs MUST mark this extension as 1876 critical and SHOULD NOT impose name constraints on the x400Address, 1877 ediPartyName, or registeredID name forms. Conforming CAs MUST NOT 1878 issue certificates where name constraints is an empty sequence. That 1879 is, either the permittedSubtrees field or the excludedSubtrees MUST 1880 be present. 1882 Applications conforming to this profile MUST be able to process name 1883 constraints that are imposed on the directoryName name form and 1884 SHOULD be able to process name constraints that are imposed on the 1885 rfc822Name, uniformResourceIdentifier, dNSName, and iPAddress name 1886 forms. If a name constraints extension that is marked critical 1887 imposes constraints on a particular name form, and an instance of 1888 that name form appears in the subject field or subjectAltName 1889 extension of a subsequent certificate, then the application MUST 1890 either process the constraint or reject the certificate. 1892 Within this profile, the minimum and maximum fields are not used with 1893 any name forms, thus minimum MUST be zero, and maximum MUST be 1894 absent. However, if an application encounters a critical name 1895 constraints extension that specifies other values for minimum or 1896 maximum for a name form that appears in a subsequent certificate, the 1897 application MUST either process these fields or reject the 1898 certificate. 1900 For URIs, the constraint applies to the host part of the name. The 1901 constraint MUST be specified as a fully qualified domain name and MAY 1902 specify a host or a domain. Examples would be "host.example.com" and 1903 ".example.com". When the the constraint begins with a period, it MAY 1904 be expanded with one or more subdomains. That is, the constraint 1905 ".example.com" is satisfied by both host.example.com and 1906 my.host.example.com. However, the constraint ".example.com" is not 1907 satisfied by "example.com". When the constraint does not begin with 1908 a period, it specifies a host. If a constraint is applied to the 1909 uniformResourceIdentifier name form and a subsequent certificate 1910 includes a subjectAltName extension with a uniformResourceIdentifier 1911 that does not include an authority component with a host name 1912 specified as a fully qualified domain name (e.g., if the URI either 1913 does not include an authority component or includes an authority 1914 component in which the host name is specified as an IP address), then 1915 the application MUST reject the certificate. 1917 A name constraint for Internet mail addresses MAY specify a 1918 particular mailbox, all addresses at a particular host, or all 1919 mailboxes in a domain. To indicate a particular mailbox, the 1920 constraint is the complete mail address. For example, 1921 "root@example.com" indicates the root mailbox on the host 1922 "example.com". To indicate all Internet mail addresses on a 1923 particular host, the constraint is specified as the host name. For 1924 example, the constraint "example.com" is satisfied by any mail 1925 address at the host "example.com". To specify any address within a 1926 domain, the constraint is specified with a leading period (as with 1927 URIs). For example, ".example.com" indicates all the Internet mail 1928 addresses in the domain "example.com", but not Internet mail 1929 addresses on the host "example.com". 1931 DNS name restrictions are expressed as host.example.com. Any DNS 1932 name that can be constructed by simply adding zero or more subdomains 1933 to the left hand side of the name satisfies the name constraint. For 1934 example, www.host.example.com would satisfy the constraint but 1935 host1.example.com would not. 1937 Legacy implementations exist where an electronic mail address is 1938 embedded in the subject distinguished name in an attribute of type 1939 emailAddress (section 4.1.2.6). When constraints are imposed on the 1940 rfc822Name name form, but the certificate does not include a subject 1941 alternative name, the rfc822Name constraint MUST be applied to the 1942 attribute of type emailAddress in the subject distinguished name. 1943 The ASN.1 syntax for emailAddress and the corresponding OID are 1944 supplied in appendix A. 1946 Restrictions of the form directoryName MUST be applied to the subject 1947 field in the certificate (when the certificate includes a non-empty 1948 subject field) and to any names of type directoryName in the 1949 subjectAltName extension. Restrictions of the form x400Address MUST 1950 be applied to any names of type x400Address in the subjectAltName 1951 extension. 1953 When applying restrictions of the form directoryName, an 1954 implementation MUST compare DN attributes. At a minimum, 1955 implementations MUST perform the DN comparison rules specified in 1956 section 7.1. CAs issuing certificates with a restriction of the form 1957 directoryName SHOULD NOT rely on implementation of the full ISO DN 1958 name comparison algorithm. This implies name restrictions MUST be 1959 stated identically to the encoding used in the subject field or 1960 subjectAltName extension. 1962 The syntax of iPAddress MUST be as described in section 4.2.1.6 with 1963 the following additions specifically for name constraints. For IPv4 1964 addresses, the iPAddress field of GeneralName MUST contain eight (8) 1965 octets, encoded in the style of RFC 4632 (CIDR) to represent an 1966 address range [RFC 4632]. For IPv6 addresses, the iPAddress field 1967 MUST contain 32 octets similarly encoded. For example, a name 1968 constraint for "class C" subnet 192.0.2.0 is represented as the 1969 octets C0 00 02 00 FF FF FF 00, representing the CIDR notation 1970 192.0.2.0/24 (mask 255.255.255.0). 1972 Additional rules for encoding and processing name constraints are 1973 specified in section 7. 1975 The syntax and semantics for name constraints for otherName, 1976 ediPartyName, and registeredID are not defined by this specification, 1977 however syntax and semantics for name constraints for other name 1978 forms may be specified in other documents. 1980 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 1982 NameConstraints ::= SEQUENCE { 1983 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 1984 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 1986 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 1988 GeneralSubtree ::= SEQUENCE { 1989 base GeneralName, 1990 minimum [0] BaseDistance DEFAULT 0, 1991 maximum [1] BaseDistance OPTIONAL } 1993 BaseDistance ::= INTEGER (0..MAX) 1995 4.2.1.11 Policy Constraints 1997 The policy constraints extension can be used in certificates issued 1998 to CAs. The policy constraints extension constrains path validation 1999 in two ways. It can be used to prohibit policy mapping or require 2000 that each certificate in a path contain an acceptable policy 2001 identifier. 2003 If the inhibitPolicyMapping field is present, the value indicates the 2004 number of additional certificates that may appear in the path before 2005 policy mapping is no longer permitted. For example, a value of one 2006 indicates that policy mapping may be processed in certificates issued 2007 by the subject of this certificate, but not in additional 2008 certificates in the path. 2010 If the requireExplicitPolicy field is present, the value of 2011 requireExplicitPolicy indicates the number of additional certificates 2012 that may appear in the path before an explicit policy is required for 2013 the entire path. When an explicit policy is required, it is 2014 necessary for all certificates in the path to contain an acceptable 2015 policy identifier in the certificate policies extension. An 2016 acceptable policy identifier is the identifier of a policy required 2017 by the user of the certification path or the identifier of a policy 2018 that has been declared equivalent through policy mapping. 2020 Conforming applications MUST be able to process the 2021 requireExplicitPolicy field and SHOULD be able to process the 2022 inhibitPolicyMapping field. Applications that support the 2023 inhibitPolicyMapping field MUST also implement support for the 2024 policyMappings extension. If the policyConstraints extension is 2025 marked critical and the inhibitPolicyMapping field is present, 2026 applications that do not implement support for the 2027 inhibitPolicyMapping field MUST reject the certificate. 2029 Conforming CAs MUST NOT issue certificates where policy constraints 2030 is an empty sequence. That is, either the inhibitPolicyMapping field 2031 or the requireExplicitPolicy field MUST be present. The behavior of 2032 clients that encounter an empty policy constraints field is not 2033 addressed in this profile. 2035 Conforming CAs MUST mark this extension as critical. 2037 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } 2039 PolicyConstraints ::= SEQUENCE { 2040 requireExplicitPolicy [0] SkipCerts OPTIONAL, 2041 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 2043 SkipCerts ::= INTEGER (0..MAX) 2045 4.2.1.12 Extended Key Usage 2047 This extension indicates one or more purposes for which the certified 2048 public key may be used, in addition to or in place of the basic 2049 purposes indicated in the key usage extension. In general, this 2050 extension will appear only in end entity certificates. This 2051 extension is defined as follows: 2053 id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 } 2055 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 2057 KeyPurposeId ::= OBJECT IDENTIFIER 2059 Key purposes may be defined by any organization with a need. Object 2060 identifiers used to identify key purposes MUST be assigned in 2061 accordance with IANA or ITU-T Recommendation X.660 [X.660]. 2063 This extension MAY, at the option of the certificate issuer, be 2064 either critical or non-critical. 2066 If the extension is present, then the certificate MUST only be used 2067 for one of the purposes indicated. If multiple purposes are 2068 indicated the application need not recognize all purposes indicated, 2069 as long as the intended purpose is present. Certificate using 2070 applications MAY require that the extended key usage extension be 2071 present and that a particular purpose be indicated in order for the 2072 certificate to be acceptable to that application. 2074 If a CA includes extended key usages to satisfy such applications, 2075 but does not wish to restrict usages of the key, the CA can include 2076 the special KeyPurposeId anyExtendedKeyUsage in addition to the 2077 particular key purposes required by the applications. Conforming CAs 2078 SHOULD NOT mark this extension as critical if the anyExtendedKeyUsage 2079 KeyPurposeId is present. Applications that require the presence of a 2080 particular purpose MAY reject certificates that include the 2081 anyExtendedKeyUsage OID but not the particular OID expected for the 2082 application. 2084 If a certificate contains both a key usage extension and an extended 2085 key usage extension, then both extensions MUST be processed 2086 independently and the certificate MUST only be used for a purpose 2087 consistent with both extensions. If there is no purpose consistent 2088 with both extensions, then the certificate MUST NOT be used for any 2089 purpose. 2091 The following key usage purposes are defined: 2093 anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 } 2095 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 2097 id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } 2098 -- TLS WWW server authentication 2099 -- Key usage bits that may be consistent: digitalSignature, 2100 -- keyEncipherment or keyAgreement 2102 id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } 2103 -- TLS WWW client authentication 2104 -- Key usage bits that may be consistent: digitalSignature 2105 -- and/or keyAgreement 2107 id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } 2108 -- Signing of downloadable executable code 2109 -- Key usage bits that may be consistent: digitalSignature 2111 id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } 2112 -- Email protection 2113 -- Key usage bits that may be consistent: digitalSignature, 2114 -- nonRepudiation, and/or (keyEncipherment or keyAgreement) 2115 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 2116 -- Binding the hash of an object to a time 2117 -- Key usage bits that may be consistent: digitalSignature 2118 -- and/or nonRepudiation 2120 id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 } 2121 -- Signing OCSP responses 2122 -- Key usage bits that may be consistent: digitalSignature 2123 -- and/or nonRepudiation 2125 4.2.1.13 CRL Distribution Points 2127 The CRL distribution points extension identifies how CRL information 2128 is obtained. The extension SHOULD be non-critical, but this profile 2129 RECOMMENDS support for this extension by CAs and applications. 2130 Further discussion of CRL management is contained in section 5. 2132 The cRLDistributionPoints extension is a SEQUENCE of 2133 DistributionPoint. A DistributionPoint consists of three fields, 2134 each of which is optional: distributionPoint, reasons, and cRLIssuer. 2135 While each of these fields is optional, a DistributionPoint MUST NOT 2136 consist of only the reasons field; either distributionPoint or 2137 cRLIssuer MUST be present. If the certificate issuer is not the CRL 2138 issuer, then the cRLIssuer field MUST be present and contain the Name 2139 of the CRL issuer. If the certificate issuer is also the CRL issuer, 2140 then conforming CAs MUST omit the cRLIssuer field and MUST include 2141 the distributionPoint field. 2143 When the distributionPoint field is present, it contains either a 2144 SEQUENCE of general names or a single value, nameRelativeToCRLIssuer. 2145 If the DistributionPointName contains multiple values, each name 2146 describes a different mechanism to obtain the same CRL. For example, 2147 the same CRL could be available for retrieval through both LDAP and 2148 HTTP. 2150 If the distributionPoint field contains a directoryName, the entry 2151 for that directoryName contains the current CRL for the associated 2152 reasons and the CRL is issued by the associated cRLIssuer. The CRL 2153 may be stored in either the certificateRevocationList or 2154 authorityRevocationList attribute. The CRL is to be obtained by the 2155 application from whatever directory server is locally configured. 2156 The protocol the application uses to access the directory (e.g., DAP 2157 or LDAP) is a local matter. 2159 If the DistributionPointName contains a general name of type URI, the 2160 following semantics MUST be assumed: the URI is a pointer to the 2161 current CRL for the associated reasons and will be issued by the 2162 associated cRLIssuer. When the HTTP or FTP URI scheme is used, the 2163 URI MUST point to a single DER encoded CRL as specified in 2164 [RFC 2585]. HTTP server implementations accessed via the URI SHOULD 2165 specify the media type application/pkix-crl in the content-type 2166 header field of the response. When the LDAP URI scheme [RFC 4516] is 2167 used, the URI MUST include a field containing the distinguished 2168 name of the entry holding the CRL, MUST include a single 2169 that contains an appropriate attribute description for the attribute 2170 that holds the CRL [RFC 4523], and SHOULD include a 2171 (e.g., ). Omitting the (e.g., 2173 ) has 2174 the effect of relying on whatever a priori knowledge the client might 2175 have to contact an appropriate server. When present, 2176 DistributionPointName SHOULD include at least one LDAP or HTTP URI. 2178 If the DistributionPointName contains the single value 2179 nameRelativeToCRLIssuer, the value provides a distinguished name 2180 fragment. The fragment is appended to the X.500 distinguished name 2181 of the CRL issuer to obtain the distribution point name. If the 2182 cRLIssuer field in the DistributionPoint is present, then the name 2183 fragment is appended to the distinguished name that it contains; 2184 otherwise, the name fragment is appended to the certificate issuer 2185 distinguished name. Conforming CAs SHOULD NOT use 2186 nameRelativeToCRLIssuer to specify distribution point names. The 2187 DistributionPointName MUST NOT use the nameRelativeToCRLIssuer 2188 alternative when cRLIssuer contains more than one distinguished name. 2190 If the DistributionPoint omits the reasons field, the CRL MUST 2191 include revocation information for all reasons. This profile 2192 RECOMMENDS against segmenting CRLs by reason code. When a conforming 2193 CA includes a cRLDistributionPoints extension in a certificate, it 2194 MUST include at least one DistributionPoint that points to a CRL that 2195 covers the certificate for all reasons. 2197 The cRLIssuer identifies the entity that signs and issues the CRL. 2198 If present, the cRLIssuer MUST only contain the distinguished name 2199 (DN) from the issuer field of the CRL to which the DistributionPoint 2200 is pointing. The encoding of the name in the cRLIssuer field MUST be 2201 exactly the same as the encoding in issuer field of the CRL. If the 2202 cRLIssuer field is included and the DN in that field does not 2203 correspond to an X.500 or LDAP directory entry where CRL is located, 2204 then conforming CAs MUST include the distributionPoint field. 2206 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 } 2208 CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 2209 DistributionPoint ::= SEQUENCE { 2210 distributionPoint [0] DistributionPointName OPTIONAL, 2211 reasons [1] ReasonFlags OPTIONAL, 2212 cRLIssuer [2] GeneralNames OPTIONAL } 2214 DistributionPointName ::= CHOICE { 2215 fullName [0] GeneralNames, 2216 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 2218 ReasonFlags ::= BIT STRING { 2219 unused (0), 2220 keyCompromise (1), 2221 cACompromise (2), 2222 affiliationChanged (3), 2223 superseded (4), 2224 cessationOfOperation (5), 2225 certificateHold (6), 2226 privilegeWithdrawn (7), 2227 aACompromise (8) } 2229 4.2.1.14 Inhibit anyPolicy 2231 The inhibit anyPolicy extension can be used in certificates issued to 2232 CAs. The inhibit anyPolicy extension indicates that the special 2233 anyPolicy OID, with the value { 2 5 29 32 0 }, is not considered an 2234 explicit match for other certificate policies except when it appears 2235 in an intermediate self-issued CA certificate. The value indicates 2236 the number of additional non-self-issued certificates that may appear 2237 in the path before anyPolicy is no longer permitted. For example, a 2238 value of one indicates that anyPolicy may be processed in 2239 certificates issued by the subject of this certificate, but not in 2240 additional certificates in the path. 2242 Conforming CAs MUST mark this extension as critical. 2244 id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 } 2246 InhibitAnyPolicy ::= SkipCerts 2248 SkipCerts ::= INTEGER (0..MAX) 2250 4.2.1.15 Freshest CRL (a.k.a. Delta CRL Distribution Point) 2252 The freshest CRL extension identifies how delta CRL information is 2253 obtained. The extension MUST be marked as non-critical by conforming 2254 CAs. Further discussion of CRL management is contained in section 5. 2256 The same syntax is used for this extension and the 2257 cRLDistributionPoints extension, and is described in section 2258 4.2.1.13. The same conventions apply to both extensions. 2260 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } 2262 FreshestCRL ::= CRLDistributionPoints 2264 4.2.2 Private Internet Extensions 2266 This section defines two extensions for use in the Internet Public 2267 Key Infrastructure. These extensions may be used to direct 2268 applications to on-line information about the issuer or the subject. 2269 Each extension contains a sequence of access methods and access 2270 locations. The access method is an object identifier that indicates 2271 the type of information that is available. The access location is a 2272 GeneralName that implicitly specifies the location and format of the 2273 information and the method for obtaining the information. 2275 Object identifiers are defined for the private extensions. The 2276 object identifiers associated with the private extensions are defined 2277 under the arc id-pe within the arc id-pkix. Any future extensions 2278 defined for the Internet PKI are also expected to be defined under 2279 the arc id-pe. 2281 id-pkix OBJECT IDENTIFIER ::= 2282 { iso(1) identified-organization(3) dod(6) internet(1) 2283 security(5) mechanisms(5) pkix(7) } 2285 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 2287 4.2.2.1 Authority Information Access 2289 The authority information access extension indicates how to access 2290 information and services for the issuer of the certificate in which 2291 the extension appears. Information and services may include on-line 2292 validation services and CA policy data. (The location of CRLs is not 2293 specified in this extension; that information is provided by the 2294 cRLDistributionPoints extension.) This extension may be included in 2295 end entity or CA certificates. Conforming CAs MUST mark this 2296 extension as non-critical. 2298 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 2300 AuthorityInfoAccessSyntax ::= 2301 SEQUENCE SIZE (1..MAX) OF AccessDescription 2303 AccessDescription ::= SEQUENCE { 2304 accessMethod OBJECT IDENTIFIER, 2305 accessLocation GeneralName } 2307 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 2309 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 2311 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 2313 Each entry in the sequence AuthorityInfoAccessSyntax describes the 2314 format and location of additional information provided by the issuer 2315 of the certificate in which this extension appears. The type and 2316 format of the information is specified by the accessMethod field; the 2317 accessLocation field specifies the location of the information. The 2318 retrieval mechanism may be implied by the accessMethod or specified 2319 by accessLocation. 2321 This profile defines two accessMethod OIDs: id-ad-caIssuers and 2322 id-ad-ocsp. 2324 In a public key certificate, the id-ad-caIssuers OID is used when the 2325 additional information lists certificates that were issued to the CA 2326 that issued the certificate containing this extension. The 2327 referenced CA issuers description is intended to aid certificate 2328 users in the selection of a certification path that terminates at a 2329 point trusted by the certificate user. 2331 When id-ad-caIssuers appears as accessMethod, the accessLocation 2332 field describes the referenced description server and the access 2333 protocol to obtain the referenced description. The accessLocation 2334 field is defined as a GeneralName, which can take several forms. 2336 When the accessLocation is a directoryName, the information is to be 2337 obtained by the application from whatever directory server is locally 2338 configured. The entry for the directoryName contains CA certificates 2339 in the crossCertificatePair and/or cACertificate attributes as 2340 specified in [RFC 4523]. The protocol that application uses to 2341 access the directory (e.g., DAP or LDAP) is a local matter. 2343 Where the information is available via LDAP, the accessLocation 2344 SHOULD be a uniformResourceIdentifier. The LDAP URI [RFC 4516] MUST 2345 include a field containing the distinguished name of the entry 2346 holding the certificates, MUST include an field that 2347 lists appropriate attribute descriptions for the attributes that hold 2348 the DER encoded certificates or cross-certificate pairs [RFC 4523], 2349 and SHOULD include a (e.g., ). 2352 Omitting the (e.g., ) has the effect of relying on whatever a priori 2354 knowledge the client might have to contact an appropriate server. 2356 Where the information is available via HTTP or FTP, accessLocation 2357 MUST be a uniformResourceIdentifier and the URI MUST point to either 2358 a single DER encoded certificate as specified in [RFC 2585] or a 2359 collection of certificates in a BER or DER encoded "certs-only" CMS 2360 message as specified in [RFC 2797]. 2362 Conforming applications that support HTTP or FTP for accessing 2363 certificates MUST be able to accept individual DER encoded 2364 certificates and SHOULD be able to accept "certs-only" CMS messages. 2366 HTTP server implementations accessed via the URI SHOULD specify the 2367 media type application/pkix-cert [RFC 2585] in the content-type 2368 header field of the response for a single DER encoded certificate and 2369 SHOULD specify the media type application/pkcs7-mime [RFC 2797] in 2370 the content-type header field of the response for "certs-only" CMS 2371 messages. For FTP, the name of a file that contains a single DER 2372 encoded certificate SHOULD have a suffix of ".cer" [RFC 2585] and the 2373 name of a file that contains a "certs-only" CMS message SHOULD have a 2374 suffix of ".p7c" [RFC 2797]. Consuming clients may use the media 2375 type or file extension as a hint to the content, but should not 2376 depend solely on the presence of the correct media type or file 2377 extension in the server response. 2379 The semantics of other id-ad-caIssuers accessLocation name forms are 2380 not defined. 2382 An authorityInfoAccess extension may include multiple instances of 2383 the id-ad-caIssuers accessMethod. The different instances may 2384 specify different methods for accessing the same information or may 2385 point to different information. When the id-ad-caIssuers 2386 accessMethod is used, at least one instance SHOULD specify an 2387 accessLocation that is an HTTP [RFC 2616] or LDAP [RFC 4516] URI. 2389 The id-ad-ocsp OID is used when revocation information for the 2390 certificate containing this extension is available using the Online 2391 Certificate Status Protocol (OCSP) [RFC 2560]. 2393 When id-ad-ocsp appears as accessMethod, the accessLocation field is 2394 the location of the OCSP responder, using the conventions defined in 2395 [RFC 2560]. 2397 Additional access descriptors may be defined in other PKIX 2398 specifications. 2400 4.2.2.2 Subject Information Access 2402 The subject information access extension indicates how to access 2403 information and services for the subject of the certificate in which 2404 the extension appears. When the subject is a CA, information and 2405 services may include certificate validation services and CA policy 2406 data. When the subject is an end entity, the information describes 2407 the type of services offered and how to access them. In this case, 2408 the contents of this extension are defined in the protocol 2409 specifications for the supported services. This extension may be 2410 included in end entity or CA certificates. Conforming CAs MUST mark 2411 this extension as non-critical. 2413 id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 } 2415 SubjectInfoAccessSyntax ::= 2416 SEQUENCE SIZE (1..MAX) OF AccessDescription 2418 AccessDescription ::= SEQUENCE { 2419 accessMethod OBJECT IDENTIFIER, 2420 accessLocation GeneralName } 2422 Each entry in the sequence SubjectInfoAccessSyntax describes the 2423 format and location of additional information provided by the subject 2424 of the certificate in which this extension appears. The type and 2425 format of the information is specified by the accessMethod field; the 2426 accessLocation field specifies the location of the information. The 2427 retrieval mechanism may be implied by the accessMethod or specified 2428 by accessLocation. 2430 This profile defines one access method to be used when the subject is 2431 a CA and one access method to be used when the subject is an end 2432 entity. Additional access methods may be defined in the future in 2433 the protocol specifications for other services. 2435 The id-ad-caRepository OID is used when the subject is a CA that 2436 publishes certificates it issues in a repository. The accessLocation 2437 field is defined as a GeneralName, which can take several forms. 2439 When the accessLocation is a directoryName, the information is to be 2440 obtained by the application from whatever directory server is locally 2441 configured. When the extension is used to point to CA certificates, 2442 the entry for the directoryName contains CA certificates in the 2443 crossCertificatePair and/or cACertificate attributes as specified in 2444 [RFC 4523]. The protocol the application uses to access the 2445 directory (e.g., DAP or LDAP) is a local matter. 2447 Where the information is available via LDAP, the accessLocation 2448 SHOULD be a uniformResourceIdentifier. The LDAP URI [RFC 4516] MUST 2449 include a field containing the distinguished name of the entry 2450 holding the certificates, MUST include an field that 2451 lists appropriate attribute descriptions for the attributes that hold 2452 the DER encoded certificates or cross-certificate pairs [RFC 4523], 2453 and SHOULD include a (e.g., ). 2455 Omitting the (e.g., ) has the effect of relying on whatever a priori 2457 knowledge the client might have to contact an appropriate server. 2459 Where the information is available via HTTP or FTP, accessLocation 2460 MUST be a uniformResourceIdentifier and the URI MUST point to either 2461 a single DER encoded certificate as specified in [RFC 2585] or a 2462 collection of certificates in a BER or DER encoded "certs-only" CMS 2463 message as specified in [RFC 2797]. 2465 Conforming applications that support HTTP or FTP for accessing 2466 certificates MUST be able to accept individual DER encoded 2467 certificates and SHOULD be able to accept "certs-only" CMS messages. 2469 HTTP server implementations accessed via the URI SHOULD specify the 2470 media type application/pkix-cert [RFC 2585] in the content-type 2471 header field of the response for a single DER encoded certificate and 2472 SHOULD specify the media type application/pkcs7-mime [RFC 2797] in 2473 the content-type header field of the response for "certs-only" CMS 2474 messages. For FTP, the name of a file that contains a single DER 2475 encoded certificate SHOULD have a suffix of ".cer" [RFC 2585] and the 2476 name of a file that contains a "certs-only" CMS message SHOULD have a 2477 suffix of ".p7c" [RFC 2797]. Consuming clients may use the media 2478 type or file extension as a hint to the content, but should not 2479 depend solely on the presence of the correct media type or file 2480 extension in the server response. 2482 The semantics of other id-ad-caRepository accessLocation name forms 2483 are not defined. 2485 A subjectInfoAccess extension may include multiple instances of the 2486 id-ad-caRepository accessMethod. The different instances may specify 2487 different methods for accessing the same information or may point to 2488 different information. When the id-ad-caRepository accessMethod is 2489 used, at least one instance SHOULD specify an accessLocation that is 2490 an HTTP [RFC 2616] or LDAP [RFC 4516] URI. 2492 The id-ad-timeStamping OID is used when the subject offers 2493 timestamping services using the Time Stamp Protocol defined in 2494 [RFC 3161]. Where the timestamping services are available via HTTP 2495 or FTP, accessLocation MUST be a uniformResourceIdentifier. Where 2496 the timestamping services are available via electronic mail, 2497 accessLocation MUST be an rfc822Name. Where timestamping services 2498 are available using TCP/IP, the dNSName or iPAddress name forms may 2499 be used. The semantics of other name forms of accessLocation (when 2500 accessMethod is id-ad-timeStamping) are not defined by this 2501 specification. 2503 Additional access descriptors may be defined in other PKIX 2504 specifications. 2506 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 2508 id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 } 2510 id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 } 2512 5 CRL and CRL Extensions Profile 2514 As discussed above, one goal of this X.509 v2 CRL profile is to 2515 foster the creation of an interoperable and reusable Internet PKI. 2516 To achieve this goal, guidelines for the use of extensions are 2517 specified, and some assumptions are made about the nature of 2518 information included in the CRL. 2520 CRLs may be used in a wide range of applications and environments 2521 covering a broad spectrum of interoperability goals and an even 2522 broader spectrum of operational and assurance requirements. This 2523 profile establishes a common baseline for generic applications 2524 requiring broad interoperability. The profile defines a set of 2525 information that can be expected in every CRL. Also, the profile 2526 defines common locations within the CRL for frequently used 2527 attributes as well as common representations for these attributes. 2529 CRL issuers issue CRLs. The CRL issuer is either the CA or an entity 2530 that has been authorized by the CA to issue CRLs. CAs publish CRLs 2531 to provide status information about the certificates they issued. 2532 However, a CA may delegate this responsibility to another trusted 2533 authority. 2535 Each CRL has a particular scope. The CRL scope is the set of 2536 certificates that could appear on a given CRL. For example, the 2537 scope could be "all certificates issued by CA X", "all CA 2538 certificates issued by CA X", "all certificates issued by CA X that 2539 have been revoked for reasons of key compromise and CA compromise", 2540 or could be a set of certificates based on arbitrary local 2541 information, such as "all certificates issued to the NIST employees 2542 located in Boulder". 2544 A complete CRL lists all unexpired certificates, within its scope, 2545 that have been revoked for one of the revocation reasons covered by 2546 the CRL scope. A full and complete CRL lists all unexpired 2547 certificates issued by a CA that have been revoked for any reason. 2548 (Note that since CAs and CRL issuers are identified by name, the 2549 scope of a CRL is not affected by the key used to sign the CRL or the 2550 key(s) used to sign certificates.) 2552 If the scope of the CRL includes one or more certificates issued by 2553 an entity other than the CRL issuer, then it is an indirect CRL. The 2554 scope of an indirect CRL may be limited to certificates issued by a 2555 single CA or may include certificates issued by multiple CAs. If the 2556 issuer of the indirect CRL is a CA, then the scope of the indirect 2557 CRL MAY also include certificates issued by the issuer of the CRL. 2559 The CRL issuer MAY also generate delta CRLs. A delta CRL only lists 2560 those certificates, within its scope, whose revocation status has 2561 changed since the issuance of a referenced complete CRL. The 2562 referenced complete CRL is referred to as a base CRL. The scope of a 2563 delta CRL MUST be the same as the base CRL that it references. 2565 This profile defines one private Internet CRL extension but does not 2566 define any private CRL entry extensions. 2568 Environments with additional or special purpose requirements may 2569 build on this profile or may replace it. 2571 Conforming CAs are not required to issue CRLs if other revocation or 2572 certificate status mechanisms are provided. When CRLs are issued, 2573 the CRLs MUST be version 2 CRLs, include the date by which the next 2574 CRL will be issued in the nextUpdate field (section 5.1.2.5), include 2575 the CRL number extension (section 5.2.3), and include the authority 2576 key identifier extension (section 5.2.1). Conforming applications 2577 that support CRLs are REQUIRED to process both version 1 and version 2578 2 complete CRLs that provide revocation information for all 2579 certificates issued by one CA. Conforming applications are not 2580 required to support processing of delta CRLs, indirect CRLs, or CRLs 2581 with a scope other than all certificates issued by one CA. 2583 5.1 CRL Fields 2585 The X.509 v2 CRL syntax is as follows. For signature calculation, 2586 the data that is to be signed is ASN.1 DER encoded. ASN.1 DER 2587 encoding is a tag, length, value encoding system for each element. 2589 CertificateList ::= SEQUENCE { 2590 tbsCertList TBSCertList, 2591 signatureAlgorithm AlgorithmIdentifier, 2592 signatureValue BIT STRING } 2594 TBSCertList ::= SEQUENCE { 2595 version Version OPTIONAL, 2596 -- if present, MUST be v2 2597 signature AlgorithmIdentifier, 2598 issuer Name, 2599 thisUpdate Time, 2600 nextUpdate Time OPTIONAL, 2601 revokedCertificates SEQUENCE OF SEQUENCE { 2602 userCertificate CertificateSerialNumber, 2603 revocationDate Time, 2604 crlEntryExtensions Extensions OPTIONAL 2605 -- if present, MUST be v2 2606 } OPTIONAL, 2607 crlExtensions [0] EXPLICIT Extensions OPTIONAL 2608 -- if present, MUST be v2 2609 } 2611 -- Version, Time, CertificateSerialNumber, and Extensions 2612 -- are all defined in the ASN.1 in section 4.1 2614 -- AlgorithmIdentifier is defined in section 4.1.1.2 2616 The following items describe the use of the X.509 v2 CRL in the 2617 Internet PKI. 2619 5.1.1 CertificateList Fields 2621 The CertificateList is a SEQUENCE of three required fields. The 2622 fields are described in detail in the following subsections. 2624 5.1.1.1 tbsCertList 2626 The first field in the sequence is the tbsCertList. This field is 2627 itself a sequence containing the name of the issuer, issue date, 2628 issue date of the next list, the optional list of revoked 2629 certificates, and optional CRL extensions. When there are no revoked 2630 certificates, the revoked certificates list is absent. When one or 2631 more certificates are revoked, each entry on the revoked certificate 2632 list is defined by a sequence of user certificate serial number, 2633 revocation date, and optional CRL entry extensions. 2635 5.1.1.2 signatureAlgorithm 2637 The signatureAlgorithm field contains the algorithm identifier for 2638 the algorithm used by the CRL issuer to sign the CertificateList. 2639 The field is of type AlgorithmIdentifier, which is defined in section 2640 4.1.1.2. [RFC 3279], [RFC 4055], and [RFC 4491] list supported 2641 algorithms for this specification, but other signature algorithms MAY 2642 also be supported. 2644 This field MUST contain the same algorithm identifier as the 2645 signature field in the sequence tbsCertList (section 5.1.2.2). 2647 5.1.1.3 signatureValue 2649 The signatureValue field contains a digital signature computed upon 2650 the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded tbsCertList 2651 is used as the input to the signature function. This signature value 2652 is encoded as a BIT STRING and included in the CRL signatureValue 2653 field. The details of this process are specified for each of the 2654 supported algorithms in [RFC 3279], [RFC 4055], and [RFC 4491]. 2656 CAs that are also CRL issuers MAY use one private key to digitally 2657 sign certificates and CRLs, or MAY use separate private keys to 2658 digitally sign certificates and CRLs. When separate private keys are 2659 employed, each of the public keys associated with these private keys 2660 is placed in a separate certificate, one with the keyCertSign bit set 2661 in the key usage extension, and one with the cRLSign bit set in the 2662 key usage extension (section 4.2.1.3). When separate private keys 2663 are employed, certificates issued by the CA contain one authority key 2664 identifier, and the corresponding CRLs contain a different authority 2665 key identifier. The use of separate CA certificates for validation 2666 of certificate signatures and CRL signatures can offer improved 2667 security characteristics; however, it imposes a burden on 2668 applications, and it might limit interoperability. Many applications 2669 construct a certification path, and then validate the certification 2670 path (section 6). CRL checking in turn requires a separate 2671 certification path to be constructed and validated for the CA's CRL 2672 signature validation certificate. Applications that perform CRL 2673 checking MUST support certification path validation when certificates 2674 and CRLs are digitally signed with the same CA private key. These 2675 applications SHOULD support certification path validation when 2676 certificates and CRLs are digitally signed with different CA private 2677 keys. 2679 5.1.2 Certificate List "To Be Signed" 2681 The certificate list to be signed, or TBSCertList, is a sequence of 2682 required and optional fields. The required fields identify the CRL 2683 issuer, the algorithm used to sign the CRL, and the date and time the 2684 CRL was issued. 2686 Optional fields include the date and time by which the CRL issuer 2687 will issue the next CRL, lists of revoked certificates, and CRL 2688 extensions. The revoked certificate list is optional to support the 2689 case where a CA has not revoked any unexpired certificates that it 2690 has issued. This profile requires conforming CRL issuers to include 2691 the nextUpdate field and the CRL number and authority key identifier 2692 CRL extensions in all CRLs issued. 2694 5.1.2.1 Version 2696 This optional field describes the version of the encoded CRL. When 2697 extensions are used, as required by this profile, this field MUST be 2698 present and MUST specify version 2 (the integer value is 1). 2700 5.1.2.2 Signature 2702 This field contains the algorithm identifier for the algorithm used 2703 to sign the CRL. [RFC 3279], [RFC 4055], and [RFC 4491] list OIDs 2704 for the most popular signature algorithms used in the Internet PKI. 2706 This field MUST contain the same algorithm identifier as the 2707 signatureAlgorithm field in the sequence CertificateList (section 2708 5.1.1.2). 2710 5.1.2.3 Issuer Name 2712 The issuer name identifies the entity that has signed and issued the 2713 CRL. The issuer identity is carried in the issuer name field. 2714 Alternative name forms may also appear in the issuerAltName extension 2715 (section 5.2.2). The issuer name field MUST contain a non-empty 2716 X.500 distinguished name (DN). The issuer name field is defined as 2717 the X.501 type Name, and MUST follow the encoding rules for the 2718 issuer name field in the certificate (section 4.1.2.4). 2720 5.1.2.4 This Update 2722 This field indicates the issue date of this CRL. thisUpdate may be 2723 encoded as UTCTime or GeneralizedTime. 2725 CRL issuers conforming to this profile MUST encode thisUpdate as 2726 UTCTime for dates through the year 2049. CRL issuers conforming to 2727 this profile MUST encode thisUpdate as GeneralizedTime for dates in 2728 the year 2050 or later. Conforming applications MUST be able to 2729 process dates that are encoded in either UTCTime or GeneralizedTime. 2731 Where encoded as UTCTime, thisUpdate MUST be specified and 2732 interpreted as defined in section 4.1.2.5.1. Where encoded as 2733 GeneralizedTime, thisUpdate MUST be specified and interpreted as 2734 defined in section 4.1.2.5.2. 2736 5.1.2.5 Next Update 2738 This field indicates the date by which the next CRL will be issued. 2739 The next CRL could be issued before the indicated date, but it will 2740 not be issued any later than the indicated date. CRL issuers SHOULD 2741 issue CRLs with a nextUpdate time equal to or later than all previous 2742 CRLs. nextUpdate may be encoded as UTCTime or GeneralizedTime. 2744 Conforming CRL issuers MUST include the nextUpdate field in all CRLs. 2745 Note that the ASN.1 syntax of TBSCertList describes this field as 2746 OPTIONAL, which is consistent with the ASN.1 structure defined in 2747 [X.509]. The behavior of clients processing CRLs that omit 2748 nextUpdate is not specified by this profile. 2750 CRL issuers conforming to this profile MUST encode nextUpdate as 2751 UTCTime for dates through the year 2049. CRL issuers conforming to 2752 this profile MUST encode nextUpdate as GeneralizedTime for dates in 2753 the year 2050 or later. Conforming applications MUST be able to 2754 process dates that are encoded in either UTCTime or GeneralizedTime. 2756 Where encoded as UTCTime, nextUpdate MUST be specified and 2757 interpreted as defined in section 4.1.2.5.1. Where encoded as 2758 GeneralizedTime, nextUpdate MUST be specified and interpreted as 2759 defined in section 4.1.2.5.2. 2761 5.1.2.6 Revoked Certificates 2763 When there are no revoked certificates, the revoked certificates list 2764 MUST be absent. Otherwise, revoked certificates are listed by their 2765 serial numbers. Certificates revoked by the CA are uniquely 2766 identified by the certificate serial number. The date on which the 2767 revocation occurred is specified. The time for revocationDate MUST 2768 be expressed as described in section 5.1.2.4. Additional information 2769 may be supplied in CRL entry extensions; CRL entry extensions are 2770 discussed in section 5.3. 2772 5.1.2.7 Extensions 2774 This field may only appear if the version is 2 (section 5.1.2.1). If 2775 present, this field is a sequence of one or more CRL extensions. CRL 2776 extensions are discussed in section 5.2. 2778 5.2 CRL Extensions 2780 The extensions defined by ANSI X9, ISO/IEC, and ITU-T for X.509 v2 2781 CRLs [X.509] [X9.55] provide methods for associating additional 2782 attributes with CRLs. The X.509 v2 CRL format also allows 2783 communities to define private extensions to carry information unique 2784 to those communities. Each extension in a CRL may be designated as 2785 critical or non-critical. If a CRL contains a critical extension 2786 that the application cannot process then the application MUST NOT use 2787 that CRL to determine the status of certificates. However, 2788 applications may ignore unrecognized non-critical extensions. The 2789 following subsections present those extensions used within Internet 2790 CRLs. Communities may elect to include extensions in CRLs that are 2791 not defined in this specification. However, caution should be 2792 exercised in adopting any critical extensions in CRLs that might be 2793 used in a general context. 2795 Conforming CRL issuers are REQUIRED to include the authority key 2796 identifier (section 5.2.1) and the CRL number (section 5.2.3) 2797 extensions in all CRLs issued. 2799 5.2.1 Authority Key Identifier 2801 The authority key identifier extension provides a means of 2802 identifying the public key corresponding to the private key used to 2803 sign a CRL. The identification can be based on either the key 2804 identifier (the subject key identifier in the CRL signer's 2805 certificate) or on the issuer name and serial number. This extension 2806 is especially useful where an issuer has more than one signing key, 2807 either due to multiple concurrent key pairs or due to changeover. 2809 Conforming CRL issuers MUST use the key identifier method, and MUST 2810 include this extension in all CRLs issued. 2812 The syntax for this CRL extension is defined in section 4.2.1.1. 2814 5.2.2 Issuer Alternative Name 2816 The issuer alternative name extension allows additional identities to 2817 be associated with the issuer of the CRL. Defined options include an 2818 electronic mail address (rfc822Name), a DNS name, an IP address, and 2819 a URI. Multiple instances of a name form and multiple name forms may 2820 be included. Whenever such identities are used, the issuer 2821 alternative name extension MUST be used; however, a DNS name MAY be 2822 represented in the issuer field using the domainComponent attribute 2823 as described in section 4.1.2.4. 2825 Conforming CRL issuers SHOULD mark the issuerAltName extension non- 2826 critical. 2828 The OID and syntax for this CRL extension are defined in section 2829 4.2.1.7. 2831 5.2.3 CRL Number 2833 The CRL number is a non-critical CRL extension that conveys a 2834 monotonically increasing sequence number for a given CRL scope and 2835 CRL issuer. This extension allows users to easily determine when a 2836 particular CRL supersedes another CRL. CRL numbers also support the 2837 identification of complementary complete CRLs and delta CRLs. CRL 2838 issuers conforming to this profile MUST include this extension in all 2839 CRLs and MUST mark this extension non-critical. 2841 If a CRL issuer generates delta CRLs in addition to complete CRLs for 2842 a given scope, the complete CRLs and delta CRLs MUST share one 2843 numbering sequence. If a delta CRL and a complete CRL that cover the 2844 same scope are issued at the same time, they MUST have the same CRL 2845 number and provide the same revocation information. That is, the 2846 combination of the delta CRL and an acceptable complete CRL MUST 2847 provide the same revocation information as the simultaneously issued 2848 complete CRL. 2850 If a CRL issuer generates two CRLs (two complete CRLs, two delta 2851 CRLs, or a complete CRL and a delta CRL) for the same scope at 2852 different times, the two CRLs MUST NOT have the same CRL number. 2853 That is, if the this update field (section 5.1.2.4) in the two CRLs 2854 are not identical, the CRL numbers MUST be different. 2856 Given the requirements above, CRL numbers can be expected to contain 2857 long integers. CRL verifiers MUST be able to handle CRLNumber values 2858 up to 20 octets. Conforming CRL issuers MUST NOT use CRLNumber 2859 values longer than 20 octets. 2861 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 2863 CRLNumber ::= INTEGER (0..MAX) 2865 5.2.4 Delta CRL Indicator 2867 The delta CRL indicator is a critical CRL extension that identifies a 2868 CRL as being a delta CRL. Delta CRLs contain updates to revocation 2869 information previously distributed, rather than all the information 2870 that would appear in a complete CRL. The use of delta CRLs can 2871 significantly reduce network load and processing time in some 2872 environments. Delta CRLs are generally smaller than the CRLs they 2873 update, so applications that obtain delta CRLs consume less network 2874 bandwidth than applications that obtain the corresponding complete 2875 CRLs. Applications that store revocation information in a format 2876 other than the CRL structure can add new revocation information to 2877 the local database without reprocessing information. 2879 The delta CRL indicator extension contains the single value of type 2880 BaseCRLNumber. The CRL number identifies the CRL, complete for a 2881 given scope, that was used as the starting point in the generation of 2882 this delta CRL. A conforming CRL issuer MUST publish the referenced 2883 base CRL as a complete CRL. The delta CRL contains all updates to 2884 the revocation status for that same scope. The combination of a 2885 delta CRL plus the referenced base CRL is equivalent to a complete 2886 CRL, for the applicable scope, at the time of publication of the 2887 delta CRL. 2889 When a conforming CRL issuer generates a delta CRL, the delta CRL 2890 MUST include a critical delta CRL indicator extension. 2892 When a delta CRL is issued, it MUST cover the same set of reasons and 2893 the same set of certificates that were covered by the base CRL it 2894 references. That is, the scope of the delta CRL MUST be the same as 2895 the scope of the complete CRL referenced as the base. The referenced 2896 base CRL and the delta CRL MUST omit the issuing distribution point 2897 extension or contain identical issuing distribution point extensions. 2898 Further, the CRL issuer MUST use the same private key to sign the 2899 delta CRL and any complete CRL that it can be used to update. 2901 An application that supports delta CRLs can construct a CRL that is 2902 complete for a given scope by combining a delta CRL for that scope 2903 with either an issued CRL that is complete for that scope or a 2904 locally constructed CRL that is complete for that scope. 2906 When a delta CRL is combined with a complete CRL or a locally 2907 constructed CRL, the resulting locally constructed CRL has the CRL 2908 number specified in the CRL number extension found in the delta CRL 2909 used in its construction. In addition, the resulting locally 2910 constructed CRL has the thisUpdate and nextUpdate times specified in 2911 the corresponding fields of the delta CRL used in its construction. 2912 In addition, the locally constructed CRL inherits the issuing 2913 distribution point from the delta CRL. 2915 A complete CRL and a delta CRL MAY be combined if the following four 2916 conditions are satisfied: 2918 (a) The complete CRL and delta CRL have the same issuer. 2920 (b) The complete CRL and delta CRL have the same scope. The two 2921 CRLs have the same scope if either of the following conditions are 2922 met: 2924 (1) The issuingDistributionPoint extension is omitted from 2925 both the complete CRL and the delta CRL. 2927 (2) The issuingDistributionPoint extension is present in both 2928 the complete CRL and the delta CRL, and the values for each of 2929 the fields in the extensions are the same in both CRLs. 2931 (c) The CRL number of the complete CRL is equal to or greater 2932 than the BaseCRLNumber specified in the delta CRL. That is, the 2933 complete CRL contains (at a minimum) all the revocation 2934 information held by the referenced base CRL. 2936 (d) The CRL number of the complete CRL is less than the CRL 2937 number of the delta CRL. That is, the delta CRL follows the 2938 complete CRL in the numbering sequence. 2940 CRL issuers MUST ensure that the combination of a delta CRL and any 2941 appropriate complete CRL accurately reflects the current revocation 2942 status. The CRL issuer MUST include an entry in the delta CRL for 2943 each certificate within the scope of the delta CRL whose status has 2944 changed since the generation of the referenced base CRL: 2946 (a) If the certificate is revoked for a reason included in the 2947 scope of the CRL, list the certificate as revoked. 2949 (b) If the certificate is valid and was listed on the referenced 2950 base CRL or any subsequent CRL with reason code certificateHold, 2951 and the reason code certificateHold is included in the scope of 2952 the CRL, list the certificate with the reason code removeFromCRL. 2954 (c) If the certificate is revoked for a reason outside the scope 2955 of the CRL, but the certificate was listed on the referenced base 2956 CRL or any subsequent CRL with a reason code included in the scope 2957 of this CRL, list the certificate as revoked but omit the reason 2958 code. 2960 (d) If the certificate is revoked for a reason outside the scope 2961 of the CRL and the certificate was neither listed on the 2962 referenced base CRL nor any subsequent CRL with a reason code 2963 included in the scope of this CRL, do not list the certificate on 2964 this CRL. 2966 The status of a certificate is considered to have changed if it is 2967 revoked (for any revocation reason, including certificateHold), 2968 released from hold, or if its revocation reason changes. 2970 It is appropriate to list a certificate with reason code 2971 removeFromCRL on a delta CRL even if the certificate was not on hold 2972 in the referenced base CRL. If the certificate was placed on hold in 2973 any CRL issued after the base but before this delta CRL and then 2974 released from hold, it MUST be listed on the delta CRL with 2975 revocation reason removeFromCRL. 2977 A CRL issuer MAY optionally list a certificate on a delta CRL with 2978 reason code removeFromCRL if the notAfter time specified in the 2979 certificate precedes the thisUpdate time specified in the delta CRL 2980 and the certificate was listed on the referenced base CRL or in any 2981 CRL issued after the base but before this delta CRL. 2983 If a certificate revocation notice first appears on a delta CRL, then 2984 it is possible for the certificate validity period to expire before 2985 the next complete CRL for the same scope is issued. In this case, 2986 the revocation notice MUST be included in all subsequent delta CRLs 2987 until the revocation notice is included on at least one explicitly 2988 issued complete CRL for this scope. 2990 An application that supports delta CRLs MUST be able to construct a 2991 current complete CRL by combining a previously issued complete CRL 2992 and the most current delta CRL. An application that supports delta 2993 CRLs MAY also be able to construct a current complete CRL by 2994 combining a previously locally constructed complete CRL and the 2995 current delta CRL. A delta CRL is considered to be the current one 2996 if the current time is between the times contained in the thisUpdate 2997 and nextUpdate fields. Under some circumstances, the CRL issuer may 2998 publish one or more delta CRLs before the time indicated by the 2999 nextUpdate field. If more than one current delta CRL for a given 3000 scope is encountered, the application SHOULD consider the one with 3001 the latest value in thisUpdate to be the most current one. 3003 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 3005 BaseCRLNumber ::= CRLNumber 3007 5.2.5 Issuing Distribution Point 3009 The issuing distribution point is a critical CRL extension that 3010 identifies the CRL distribution point and scope for a particular CRL, 3011 and it indicates whether the CRL covers revocation for end entity 3012 certificates only, CA certificates only, attribute certificates only, 3013 or a limited set of reason codes. Although the extension is 3014 critical, conforming implementations are not required to support this 3015 extension. However, implementations that do not support this 3016 extension MUST either treat the status of any certificate not listed 3017 on this CRL as unknown or locate another CRL that does not contain 3018 any unrecognized critical extensions. 3020 The CRL is signed using the CRL issuer's private key. CRL 3021 Distribution Points do not have their own key pairs. If the CRL is 3022 stored in the X.500 directory, it is stored in the directory entry 3023 corresponding to the CRL distribution point, which may be different 3024 than the directory entry of the CRL issuer. 3026 The reason codes associated with a distribution point MUST be 3027 specified in onlySomeReasons. If onlySomeReasons does not appear, 3028 the distribution point MUST contain revocations for all reason codes. 3029 CAs may use CRL distribution points to partition the CRL on the basis 3030 of compromise and routine revocation. In this case, the revocations 3031 with reason code keyCompromise (1), cACompromise (2), and 3032 aACompromise (8) appear in one distribution point, and the 3033 revocations with other reason codes appear in another distribution 3034 point. 3036 If a CRL includes an issuingDistributionPoint extension with 3037 onlySomeReasons present, then every certificate in the scope of the 3038 CRL that is revoked MUST be assigned a revocation reason other than 3039 unspecified. The assigned revocation reason is used to determine on 3040 which CRL(s) to list the revoked certificate, however, there is no 3041 requirement to include the reasonCode CRL entry extension in the 3042 corresponding CRL entry. 3044 The syntax and semantics for the distributionPoint field are the same 3045 as for the distributionPoint field in the cRLDistributionPoints 3046 extension (section 4.2.1.13). If the distributionPoint field is 3047 present, then it MUST include at least one of names from the 3048 corresponding distributionPoint field of the cRLDistributionPoints 3049 extension of every certificate that is within the scope of this CRL. 3050 The identical encoding MUST be used in the distributionPoint fields 3051 of the certificate and the CRL. 3053 If the distributionPoint field is absent, the CRL MUST contain 3054 entries for all revoked unexpired certificates issued by the CRL 3055 issuer, if any, within the scope of the CRL. 3057 If the scope of the CRL only includes certificates issued by the CRL 3058 issuer then the indirectCRL boolean MUST be set to FALSE. Otherwise, 3059 if the scope of the CRL includes certificates issued by one or more 3060 authorities other than the CRL issuer, the indirectCRL boolean MUST 3061 be set to TRUE. The authority responsible for each entry is 3062 indicated by the certificate issuer CRL entry extension (section 3063 5.3.3). 3065 If the scope of the CRL only includes end entity public key 3066 certificates then onlyContainsUserCerts MUST be set to TRUE. If the 3067 scope of the CRL only includes CA certificates then 3068 onlyContainsCACerts MUST be set to TRUE. If either 3069 onlyContainsUserCerts or onlyContainsCACerts is set to TRUE then the 3070 scope of the CRL MUST NOT include any version 1 or version 2 3071 certificates. Conforming CRLs issuers MUST set the 3072 onlyContainsAttributeCerts boolean to FALSE. 3074 Conforming CRLs issuers MUST NOT issue CRLs where the DER encoding of 3075 the issuing distribution point extension is an empty sequence. That 3076 is, if onlyContainsUserCerts, onlyContainsCACerts, indirectCRL, and 3077 onlyContainsAttributeCerts are all FALSE then either the 3078 distributionPoint field or the onlySomeReasons field MUST be present. 3080 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 3082 IssuingDistributionPoint ::= SEQUENCE { 3083 distributionPoint [0] DistributionPointName OPTIONAL, 3084 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 3085 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 3086 onlySomeReasons [3] ReasonFlags OPTIONAL, 3087 indirectCRL [4] BOOLEAN DEFAULT FALSE, 3088 onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE } 3090 -- at most one of onlyContainsUserCerts, onlyContainsCACerts, 3091 -- and onlyContainsAttributeCerts may be set to TRUE. 3093 5.2.6 Freshest CRL (a.k.a. Delta CRL Distribution Point) 3095 The freshest CRL extension identifies how delta CRL information for 3096 this complete CRL is obtained. Conforming CRL issuers MUST mark this 3097 extension non-critical. This extension MUST NOT appear in delta 3098 CRLs. 3100 The same syntax is used for this extension as the 3101 cRLDistributionPoints certificate extension, and is described in 3102 section 4.2.1.13. However, only the distribution point field is 3103 meaningful in this context. The reasons and cRLIssuer fields MUST be 3104 omitted from this CRL extension. 3106 Each distribution point name provides the location at which a delta 3107 CRL for this complete CRL can be found. The scope of these delta 3108 CRLs MUST be the same as the scope of this complete CRL. The 3109 contents of this CRL extension are only used to locate delta CRLs; 3110 the contents are not used to validate the CRL or the referenced delta 3111 CRLs. The encoding conventions defined for distribution points in 3112 section 4.2.1.13 apply to this extension. 3114 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } 3116 FreshestCRL ::= CRLDistributionPoints 3118 5.2.7 Authority Information Access 3120 This section defines the use of the Authority Information Access 3121 extension in a CRL. The syntax and semantics defined in section 3122 4.2.2.1 for the certificate extension are also used for the CRL 3123 extension. 3125 This CRL extension MUST be marked non-critical. 3127 When present in a CRL, this extension MUST include at least one 3128 AccessDescription specifying id-ad-caIssuers as the accessMethod. 3129 The id-ad-caIssuers OID is used when the information that is 3130 available lists certificates that can be used to verify the signature 3131 on the CRL (i.e., certificates that have a subject name that matches 3132 the issuer name on the CRL and that have a subject public key that 3133 corresponds to the private key used to sign the CRL). Access method 3134 types other than id-ad-caIssuers MUST NOT be included. At least one 3135 instance of AccessDescription SHOULD specify an accessLocation that 3136 is an HTTP [RFC 2616] or LDAP [RFC 4516] URI. 3138 Where the information is available via HTTP or FTP, accessLocation 3139 MUST be a uniformResourceIdentifier and the URI MUST point to either 3140 a single DER encoded certificate as specified in [RFC 2585] or a 3141 collection of certificates in a BER or DER encoded "certs-only" CMS 3142 message as specified in [RFC 2797]. 3144 Conforming applications that support HTTP or FTP for accessing 3145 certificates MUST be able to accept individual DER encoded 3146 certificates and SHOULD be able to accept "certs-only" CMS messages. 3148 HTTP server implementations accessed via the URI SHOULD specify the 3149 media type application/pkix-cert [RFC 2585] in the content-type 3150 header field of the response for a single DER encoded certificate and 3151 SHOULD specify the media type application/pkcs7-mime [RFC 2797] in 3152 the content-type header field of the response for "certs-only" CMS 3153 messages. For FTP, the name of a file that contains a single DER 3154 encoded certificate SHOULD have a suffix of ".cer" [RFC 2585] and the 3155 name of a file that contains a "certs-only" CMS message SHOULD have a 3156 suffix of ".p7c" [RFC 2797]. Consuming clients may use the media 3157 type or file extension as a hint to the content, but should not 3158 depend solely on the presence of the correct media type or file 3159 extension in the server response. 3161 When the accessLocation is a directoryName, the information is to be 3162 obtained by the application from whatever directory server is locally 3163 configured. When one CA public key is used to validate signatures on 3164 certificates and CRLs, the desired CA certificate is stored in the 3165 crossCertificatePair and/or cACertificate attributes as specified in 3166 [RFC 4523]. When different public keys are used to validate 3167 signatures on certificates and CRLs, the desired certificate is 3168 stored in the userCertificate attribute as specified in [RFC 4523]. 3169 Thus, implementations that support the directoryName form of 3170 accessLocation MUST be prepared to find the needed certificate in any 3171 of these three attributes. The protocol that an application uses to 3172 access the directory (e.g., DAP or LDAP) is a local matter. 3174 Where the information is available via LDAP, the accessLocation 3175 SHOULD be a uniformResourceIdentifier. The LDAP URI [RFC 4516] MUST 3176 include a field containing the distinguished name of the entry 3177 holding the certificates, MUST include an field that 3178 lists appropriate attribute descriptions for the attributes that hold 3179 the DER encoded certificates or cross-certificate pairs [RFC 4523], 3180 and SHOULD include a (e.g., ). 3182 Omitting the (e.g., ) has the effect of relying on whatever a priori 3184 knowledge the client might have to contact an appropriate server. 3186 5.3 CRL Entry Extensions 3188 The CRL entry extensions defined by ISO/IEC, ITU-T, and ANSI X9 for 3189 X.509 v2 CRLs provide methods for associating additional attributes 3190 with CRL entries [X.509] [X9.55]. The X.509 v2 CRL format also 3191 allows communities to define private CRL entry extensions to carry 3192 information unique to those communities. Each extension in a CRL 3193 entry may be designated as critical or non-critical. If a CRL 3194 contains a critical CRL entry extension that the application cannot 3195 process then the application MUST NOT use that CRL to determine the 3196 status of any certificates. However, applications may ignore 3197 unrecognized non-critical CRL entry extensions. 3199 The following subsections present recommended extensions used within 3200 Internet CRL entries and standard locations for information. 3201 Communities may elect to use additional CRL entry extensions; 3202 however, caution should be exercised in adopting any critical CRL 3203 entry extensions in CRLs that might be used in a general context. 3205 Support for the CRL entry extensions defined in this specification is 3206 optional for conforming CRL issuers and applications. However, CRL 3207 issuers SHOULD include reason codes (section 5.3.1) and invalidity 3208 dates (section 5.3.2) whenever this information is available. 3210 5.3.1 Reason Code 3212 The reasonCode is a non-critical CRL entry extension that identifies 3213 the reason for the certificate revocation. CRL issuers are strongly 3214 encouraged to include meaningful reason codes in CRL entries; 3215 however, the reason code CRL entry extension SHOULD be absent instead 3216 of using the unspecified (0) reasonCode value. 3218 The removeFromCRL (8) reasonCode value may only appear in delta CRLs 3219 and indicates that a certificate is to be removed from a CRL because 3220 either the certificate expired or was removed from hold. All other 3221 reason codes may appear in any CRL and indicate that the specified 3222 certificate should be considered revoked. 3224 id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 } 3226 -- reasonCode ::= { CRLReason } 3228 CRLReason ::= ENUMERATED { 3229 unspecified (0), 3230 keyCompromise (1), 3231 cACompromise (2), 3232 affiliationChanged (3), 3233 superseded (4), 3234 cessationOfOperation (5), 3235 certificateHold (6), 3236 -- value 7 is not used 3237 removeFromCRL (8), 3238 privilegeWithdrawn (9), 3239 aACompromise (10) } 3241 5.3.2 Invalidity Date 3243 The invalidity date is a non-critical CRL entry extension that 3244 provides the date on which it is known or suspected that the private 3245 key was compromised or that the certificate otherwise became invalid. 3246 This date may be earlier than the revocation date in the CRL entry, 3247 which is the date at which the CA processed the revocation. When a 3248 revocation is first posted by a CRL issuer in a CRL, the invalidity 3249 date may precede the date of issue of earlier CRLs, but the 3250 revocation date SHOULD NOT precede the date of issue of earlier CRLs. 3251 Whenever this information is available, CRL issuers are strongly 3252 encouraged to share it with CRL users. 3254 The GeneralizedTime values included in this field MUST be expressed 3255 in Greenwich Mean Time (Zulu), and MUST be specified and interpreted 3256 as defined in section 4.1.2.5.2. 3258 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 3260 InvalidityDate ::= GeneralizedTime 3262 5.3.3 Certificate Issuer 3264 This CRL entry extension identifies the certificate issuer associated 3265 with an entry in an indirect CRL, that is, a CRL that has the 3266 indirectCRL indicator set in its issuing distribution point 3267 extension. When present, the certificate issuer CRL entry extension 3268 includes one or more names from the issuer field and/or issuer 3269 alternative name extension of the certificate that corresponds to the 3270 CRL entry. If this extension is not present on the first entry in an 3271 indirect CRL, the certificate issuer defaults to the CRL issuer. On 3272 subsequent entries in an indirect CRL, if this extension is not 3273 present, the certificate issuer for the entry is the same as that for 3274 the preceding entry. This field is defined as follows: 3276 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } 3278 CertificateIssuer ::= GeneralNames 3280 Conforming CRL issuers MUST include in this extension the 3281 distinguished name (DN) from the issuer field of the certificate that 3282 corresponds to this CRL entry. The encoding of the DN MUST be 3283 identical to the encoding used in the certificate. 3285 CRL issuers MUST mark this extension as critical since an 3286 implementation that ignored this extension could not correctly 3287 attribute CRL entries to certificates. This specification RECOMMENDS 3288 that implementations recognize this extension. 3290 6 Certification Path Validation 3292 Certification path validation procedures for the Internet PKI are 3293 based on the algorithm supplied in [X.509]. Certification path 3294 processing verifies the binding between the subject distinguished 3295 name and/or subject alternative name and subject public key. The 3296 binding is limited by constraints that are specified in the 3297 certificates that comprise the path and inputs that are specified by 3298 the relying party. The basic constraints and policy constraints 3299 extensions allow the certification path processing logic to automate 3300 the decision making process. 3302 This section describes an algorithm for validating certification 3303 paths. Conforming implementations of this specification are not 3304 required to implement this algorithm, but MUST provide functionality 3305 equivalent to the external behavior resulting from this procedure. 3307 Any algorithm may be used by a particular implementation so long as 3308 it derives the correct result. 3310 In section 6.1, the text describes basic path validation. Valid 3311 paths begin with certificates issued by a trust anchor. The 3312 algorithm requires the public key of the CA, the CA's name, and any 3313 constraints upon the set of paths that may be validated using this 3314 key. 3316 The selection of a trust anchor is a matter of policy: it could be 3317 the top CA in a hierarchical PKI; the CA that issued the verifier's 3318 own certificate(s); or any other CA in a network PKI. The path 3319 validation procedure is the same regardless of the choice of trust 3320 anchor. In addition, different applications may rely on different 3321 trust anchors, or may accept paths that begin with any of a set of 3322 trust anchors. 3324 Section 6.2 describes methods for using the path validation algorithm 3325 in specific implementations. 3327 Section 6.3 describes the steps necessary to determine if a 3328 certificate is revoked when CRLs are the revocation mechanism used by 3329 the certificate issuer. 3331 6.1 Basic Path Validation 3333 This text describes an algorithm for X.509 path processing. A 3334 conforming implementation MUST include an X.509 path processing 3335 procedure that is functionally equivalent to the external behavior of 3336 this algorithm. However, support for some of the certificate 3337 extensions processed in this algorithm are OPTIONAL for compliant 3338 implementations. Clients that do not support these extensions MAY 3339 omit the corresponding steps in the path validation algorithm. 3341 For example, clients are not required to support the policy mappings 3342 extension. Clients that do not support this extension MAY omit the 3343 path validation steps where policy mappings are processed. Note that 3344 clients MUST reject the certificate if it contains an unsupported 3345 critical extension. 3347 While the certificate and CRL profiles specified in sections 4 and 5 3348 of this document specify values for certificate and CRL fields and 3349 extensions that are considered to be appropriate for the Internet 3350 PKI, the algorithm presented in this section is not limited to 3351 accepting certificates and CRLs that conform to these profiles. 3352 Therefore, the algorithm only includes checks to verify that the 3353 certification path is valid according to X.509 and does not include 3354 checks to verify that the certificates and CRLs conform to this 3355 profile. While the algorithm could be extended to include checks for 3356 conformance to the profiles in sections 4 and 5, this profile 3357 RECOMMENDS against including such checks. 3359 The algorithm presented in this section validates the certificate 3360 with respect to the current date and time. A conforming 3361 implementation MAY also support validation with respect to some point 3362 in the past. Note that mechanisms are not available for validating a 3363 certificate with respect to a time outside the certificate validity 3364 period. 3366 The trust anchor is an input to the algorithm. There is no 3367 requirement that the same trust anchor be used to validate all 3368 certification paths. Different trust anchors MAY be used to validate 3369 different paths, as discussed further in section 6.2. 3371 The primary goal of path validation is to verify the binding between 3372 a subject distinguished name or a subject alternative name and 3373 subject public key, as represented in the target certificate, based 3374 on the public key of the trust anchor. In most cases the target 3375 certificate will be an end entity certificate, but the target 3376 certificate may be a CA certificate as long as the subject public key 3377 is to be used for a purpose other than verifying the signature on a 3378 public key certificate. Verifying the binding between the name and 3379 subject public key requires obtaining a sequence of certificates that 3380 support that binding. The procedure performed to obtain this 3381 sequence of certificates is outside the scope of this specification. 3383 To meet this goal, the path validation process verifies, among other 3384 things, that a prospective certification path (a sequence of n 3385 certificates) satisfies the following conditions: 3387 (a) for all x in {1, ..., n-1}, the subject of certificate x is 3388 the issuer of certificate x+1; 3390 (b) certificate 1 is issued by the trust anchor; 3392 (c) certificate n is the certificate to be validated (i.e., the 3393 target certificate); and 3395 (d) for all x in {1, ..., n}, the certificate was valid at the 3396 time in question. 3398 A certificate MUST NOT appear more than once in a prospective 3399 certification path. 3401 When the trust anchor is provided in the form of a self-signed 3402 certificate, this self-signed certificate is not included as part of 3403 the prospective certification path. Information about trust anchors 3404 are provided as inputs to the certification path validation algorithm 3405 (section 6.1.1). 3407 A particular certification path may not, however, be appropriate for 3408 all applications. Therefore, an application MAY augment this 3409 algorithm to further limit the set of valid paths. The path 3410 validation process also determines the set of certificate policies 3411 that are valid for this path, based on the certificate policies 3412 extension, policy mappings extension, policy constraints extension, 3413 and inhibit anyPolicy extension. To achieve this, the path 3414 validation algorithm constructs a valid policy tree. If the set of 3415 certificate policies that are valid for this path is not empty, then 3416 the result will be a valid policy tree of depth n, otherwise the 3417 result will be a null valid policy tree. 3419 A certificate is self-issued if the same DN appears in the subject 3420 and issuer fields (the two DNs are the same if they match according 3421 to the rules specified in section 7.1). In general, the issuer and 3422 subject of the certificates that make up a path are different for 3423 each certificate. However, a CA may issue a certificate to itself to 3424 support key rollover or changes in certificate policies. These self- 3425 issued certificates are not counted when evaluating path length or 3426 name constraints. 3428 This section presents the algorithm in four basic steps: (1) 3429 initialization, (2) basic certificate processing, (3) preparation for 3430 the next certificate, and (4) wrap-up. Steps (1) and (4) are 3431 performed exactly once. Step (2) is performed for all certificates 3432 in the path. Step (3) is performed for all certificates in the path 3433 except the final certificate. Figure 2 provides a high-level 3434 flowchart of this algorithm. 3436 +-------+ 3437 | START | 3438 +-------+ 3439 | 3440 V 3441 +----------------+ 3442 | Initialization | 3443 +----------------+ 3444 | 3445 +<--------------------+ 3446 | | 3447 V | 3448 +----------------+ | 3449 | Process Cert | | 3450 +----------------+ | 3451 | | 3452 V | 3453 +================+ | 3454 | IF Last Cert | | 3455 | in Path | | 3456 +================+ | 3457 | | | 3458 THEN | | ELSE | 3459 V V | 3460 +----------------+ +----------------+ | 3461 | Wrap up | | Prepare for | | 3462 +----------------+ | Next Cert | | 3463 | +----------------+ | 3464 V | | 3465 +-------+ +--------------+ 3466 | STOP | 3467 +-------+ 3469 Figure 2. Certification Path Processing Flowchart 3471 6.1.1 Inputs 3473 This algorithm assumes the following nine inputs are provided to the 3474 path processing logic: 3476 (a) a prospective certification path of length n. 3478 (b) the current date/time. 3480 (c) user-initial-policy-set: A set of certificate policy 3481 identifiers naming the policies that are acceptable to the 3482 certificate user. The user-initial-policy-set contains the 3483 special value any-policy if the user is not concerned about 3484 certificate policy. 3486 (d) trust anchor information, describing a CA that serves as a 3487 trust anchor for the certification path. The trust anchor 3488 information includes: 3490 (1) the trusted issuer name, 3492 (2) the trusted public key algorithm, 3494 (3) the trusted public key, and 3496 (4) optionally, the trusted public key parameters associated 3497 with the public key. 3499 The trust anchor information may be provided to the path 3500 processing procedure in the form of a self-signed certificate. 3501 When the trust anchor information is provided in the form of a 3502 certificate, the name in the subject field is used as the trusted 3503 issuer name and the contents of the subjectPublicKeyInfo field is 3504 used as the source of the trusted public key algorithm and the 3505 trusted public key. The trust anchor information is trusted 3506 because it was delivered to the path processing procedure by some 3507 trustworthy out-of-band procedure. If the trusted public key 3508 algorithm requires parameters, then the parameters are provided 3509 along with the trusted public key. 3511 (e) initial-policy-mapping-inhibit, which indicates if policy 3512 mapping is allowed in the certification path. 3514 (f) initial-explicit-policy, which indicates if the path must be 3515 valid for at least one of the certificate policies in the user- 3516 initial-policy-set. 3518 (g) initial-any-policy-inhibit, which indicates whether the 3519 anyPolicy OID should be processed if it is included in a 3520 certificate. 3522 (h) initial-permitted-subtrees, which indicates for each name type 3523 (e.g., X.500 distinguished names, email addresses, or IP 3524 addresses) a set of subtrees within which all subject names in 3525 every certificate in the certification path MUST fall. The 3526 initial-permitted-subtrees input includes a set for each name 3527 type. For each name type, the set may consist of a single subtree 3528 that includes all names of that name type or one or more subtrees 3529 that each specifies a subset of the names of that name type, or 3530 the set may be empty. If the set for a name type is empty, then 3531 the certificaton path will be considered invalid if any 3532 certificate in the certification path includes a name of that name 3533 type. 3535 (i) initial-excluded-subtrees, which indicates for each name type 3536 (e.g., X.500 distinguished names, email addresses, or IP 3537 addresses) a set of subtrees within which no subject name in any 3538 certificate in the certification path may fall. The initial- 3539 excluded-subtrees input includes a set for each name type. For 3540 each name type, the set may be empty or may consist of one or more 3541 subtrees that each specifies a subset of the names of that name 3542 type. If the set for a name type is empty, then no names of that 3543 name type are excluded. 3545 Conforming implementations are not required to support the setting of 3546 all of these inputs. For example, a conforming implementation may be 3547 designed to validate all certification paths using a value of FALSE 3548 for initial-any-policy-inhibit. 3550 6.1.2 Initialization 3552 This initialization phase establishes eleven state variables based 3553 upon the nine inputs: 3555 (a) valid_policy_tree: A tree of certificate policies with their 3556 optional qualifiers; each of the leaves of the tree represents a 3557 valid policy at this stage in the certification path validation. 3558 If valid policies exist at this stage in the certification path 3559 validation, the depth of the tree is equal to the number of 3560 certificates in the chain that have been processed. If valid 3561 policies do not exist at this stage in the certification path 3562 validation, the tree is set to NULL. Once the tree is set to 3563 NULL, policy processing ceases. 3565 Each node in the valid_policy_tree includes three data objects: 3566 the valid policy, a set of associated policy qualifiers, and a set 3567 of one or more expected policy values. If the node is at depth x, 3568 the components of the node have the following semantics: 3570 (1) The valid_policy is a single policy OID representing a 3571 valid policy for the path of length x. 3573 (2) The qualifier_set is a set of policy qualifiers associated 3574 with the valid policy in certificate x. 3576 (3) The expected_policy_set contains one or more policy OIDs 3577 that would satisfy this policy in the certificate x+1. 3579 The initial value of the valid_policy_tree is a single node with 3580 valid_policy anyPolicy, an empty qualifier_set, and an 3581 expected_policy_set with the single value anyPolicy. This node is 3582 considered to be at depth zero. 3584 Figure 3 is a graphic representation of the initial state of the 3585 valid_policy_tree. Additional figures will use this format to 3586 describe changes in the valid_policy_tree during path processing. 3588 +----------------+ 3589 | anyPolicy | <---- valid_policy 3590 +----------------+ 3591 | {} | <---- qualifier_set 3592 +----------------+ 3593 | {anyPolicy} | <---- expected_policy_set 3594 +----------------+ 3596 Figure 3. Initial value of the valid_policy_tree state variable 3598 (b) permitted_subtrees: A set of root names for each name type 3599 (e.g., X.500 distinguished names, email addresses, or IP 3600 addresses) defining a set of subtrees within which all subject 3601 names in subsequent certificates in the certification path MUST 3602 fall. This variable includes a set for each name type, and the 3603 initial value is initial-permitted-subtrees. 3605 (c) excluded_subtrees: A set of root names for each name type 3606 (e.g., X.500 distinguished names, email addresses, or IP 3607 addresses) defining a set of subtrees within which no subject name 3608 in subsequent certificates in the certification path may fall. 3609 This variable includes a set for each name type, and the initial 3610 value is initial-excluded-subtrees. 3612 (d) explicit_policy: an integer that indicates if a non-NULL 3613 valid_policy_tree is required. The integer indicates the number 3614 of non-self-issued certificates to be processed before this 3615 requirement is imposed. Once set, this variable may be decreased, 3616 but may not be increased. That is, if a certificate in the path 3617 requires a non-NULL valid_policy_tree, a later certificate cannot 3618 remove this requirement. If initial-explicit-policy is set, then 3619 the initial value is 0, otherwise the initial value is n+1. 3621 (e) inhibit_anyPolicy: an integer that indicates whether the 3622 anyPolicy policy identifier is considered a match. The integer 3623 indicates the number of non-self-issued certificates to be 3624 processed before the anyPolicy OID, if asserted in a certificate 3625 other than an intermediate self-issued certificate, is ignored. 3626 Once set, this variable may be decreased, but may not be 3627 increased. That is, if a certificate in the path inhibits 3628 processing of anyPolicy, a later certificate cannot permit it. If 3629 initial-any-policy-inhibit is set, then the initial value is 0, 3630 otherwise the initial value is n+1. 3632 (f) policy_mapping: an integer that indicates if policy mapping 3633 is permitted. The integer indicates the number of non-self-issued 3634 certificates to be processed before policy mapping is inhibited. 3635 Once set, this variable may be decreased, but may not be 3636 increased. That is, if a certificate in the path specifies policy 3637 mapping is not permitted, it cannot be overridden by a later 3638 certificate. If initial-policy-mapping-inhibit is set, then the 3639 initial value is 0, otherwise the initial value is n+1. 3641 (g) working_public_key_algorithm: the digital signature 3642 algorithm used to verify the signature of a certificate. The 3643 working_public_key_algorithm is initialized from the trusted 3644 public key algorithm provided in the trust anchor information. 3646 (h) working_public_key: the public key used to verify the 3647 signature of a certificate. The working_public_key is initialized 3648 from the trusted public key provided in the trust anchor 3649 information. 3651 (i) working_public_key_parameters: parameters associated with 3652 the current public key, that may be required to verify a signature 3653 (depending upon the algorithm). The working_public_key_parameters 3654 variable is initialized from the trusted public key parameters 3655 provided in the trust anchor information. 3657 (j) working_issuer_name: the issuer distinguished name expected 3658 in the next certificate in the chain. The working_issuer_name is 3659 initialized to the trusted issuer name provided in the trust 3660 anchor information. 3662 (k) max_path_length: this integer is initialized to n, is 3663 decremented for each non-self-issued certificate in the path, and 3664 may be reduced to the value in the path length constraint field 3665 within the basic constraints extension of a CA certificate. 3667 Upon completion of the initialization steps, perform the basic 3668 certificate processing steps specified in 6.1.3. 3670 6.1.3 Basic Certificate Processing 3672 The basic path processing actions to be performed for certificate i 3673 (for all i in [1..n]) are listed below. 3675 (a) Verify the basic certificate information. The certificate 3676 MUST satisfy each of the following: 3678 (1) The signature on the certificate can be verified using 3679 working_public_key_algorithm, the working_public_key, and the 3680 working_public_key_parameters. 3682 (2) The certificate validity period includes the current time. 3684 (3) At the current time, the certificate is not revoked. This 3685 may be determined by obtaining the appropriate CRL (section 3686 6.3), status information, or by out-of-band mechanisms. 3688 (4) The certificate issuer name is the working_issuer_name. 3690 (b) If certificate i is self-issued and it is not the final 3691 certificate in the path, skip this step for certificate i. 3692 Otherwise, verify that the subject name is within one of the 3693 permitted_subtrees for X.500 distinguished names, and verify that 3694 each of the alternative names in the subjectAltName extension 3695 (critical or non-critical) is within one of the permitted_subtrees 3696 for that name type. 3698 (c) If certificate i is self-issued and it is not the final 3699 certificate in the path, skip this step for certificate i. 3700 Otherwise, verify that the subject name is not within any of the 3701 excluded_subtrees for X.500 distinguished names, and verify that 3702 each of the alternative names in the subjectAltName extension 3703 (critical or non-critical) is not within any of the 3704 excluded_subtrees for that name type. 3706 (d) If the certificate policies extension is present in the 3707 certificate and the valid_policy_tree is not NULL, process the 3708 policy information by performing the following steps in order: 3710 (1) For each policy P not equal to anyPolicy in the 3711 certificate policies extension, let P-OID denote the OID for 3712 policy P and P-Q denote the qualifier set for policy P. 3713 Perform the following steps in order: 3715 (i) For each node of depth i-1 in the valid_policy_tree 3716 where P-OID is in the expected_policy_set, create a child 3717 node as follows: set the valid_policy to P-OID; set the 3718 qualifier_set to P-Q, and set the expected_policy_set to 3719 {P-OID}. 3721 For example, consider a valid_policy_tree with a node of 3722 depth i-1 where the expected_policy_set is {Gold, White}. 3723 Assume the certificate policies Gold and Silver appear in 3724 the certificate policies extension of certificate i. The 3725 Gold policy is matched but the Silver policy is not. This 3726 rule will generate a child node of depth i for the Gold 3727 policy. The result is shown as Figure 4. 3729 +-----------------+ 3730 | Red | 3731 +-----------------+ 3732 | {} | 3733 +-----------------+ node of depth i-1 3734 | {Gold, White} | 3735 +-----------------+ 3736 | 3737 | 3738 | 3739 V 3740 +-----------------+ 3741 | Gold | 3742 +-----------------+ 3743 | {} | 3744 +-----------------+ node of depth i 3745 | {Gold} | 3746 +-----------------+ 3748 Figure 4. Processing an exact match 3750 (ii) If there was no match in step (i) and the 3751 valid_policy_tree includes a node of depth i-1 with the 3752 valid_policy anyPolicy, generate a child node with the 3753 following values: set the valid_policy to P-OID; set the 3754 qualifier_set to P-Q, and set the expected_policy_set to 3755 {P-OID}. 3757 For example, consider a valid_policy_tree with a node of 3758 depth i-1 where the valid_policy is anyPolicy. Assume the 3759 certificate policies Gold and Silver appear in the 3760 certificate policies extension of certificate i. The Gold 3761 policy does not have a qualifier, but the Silver policy has 3762 the qualifier Q-Silver. If Gold and Silver were not matched 3763 in (i) above, this rule will generate two child nodes of 3764 depth i, one for each policy. The result is shown as Figure 3765 5. 3767 +-----------------+ 3768 | anyPolicy | 3769 +-----------------+ 3770 | {} | 3771 +-----------------+ node of depth i-1 3772 | {anyPolicy} | 3773 +-----------------+ 3774 / \ 3775 / \ 3776 / \ 3777 / \ 3778 +-----------------+ +-----------------+ 3779 | Gold | | Silver | 3780 +-----------------+ +-----------------+ 3781 | {} | | {Q-Silver} | 3782 +-----------------+ nodes of +-----------------+ 3783 | {Gold} | depth i | {Silver} | 3784 +-----------------+ +-----------------+ 3786 Figure 5. Processing unmatched policies when a leaf node 3787 specifies anyPolicy 3789 (2) If the certificate policies extension includes the policy 3790 anyPolicy with the qualifier set AP-Q and either (a) 3791 inhibit_anyPolicy is greater than 0 or (b) i. 4707 [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic 4708 Mail: Part II: Certificate-Based Key Management," RFC 4709 1422, February 1993. 4711 [RFC 2277] Alvestrand, H., "IETF Policy on Character Sets and 4712 Languages", BCP 18, RFC 2277, January 1998. 4714 [RFC 2459] Housley, R., W. Ford, W. Polk and D. Solo, "Internet 4715 X.509 Public Key Infrastructure: Certificate and CRL 4716 Profile", RFC 2459, January 1999. 4718 [RFC 2560] Myers, M., R. Ankney, A. Malpani, S. Galperin and C. 4719 Adams, "Online Certificate Status Protocol - OCSP", June 4720 1999. 4722 [RFC 2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 4723 Classes and Attribute Types Version 2.0", RFC 2985, 4724 November 2000. 4726 [RFC 3161] Adams, C., P. Cain, D. Pinkas and R. Zuccherato, 4727 "Internet X.509 Public Key Infrastructure Time-Stamp 4728 Protocol (TSP)", RFC 3161, August 2001. 4730 [RFC 3279] Bassham, L., W. Polk and R. Housley, "Algorithms and 4731 Identifiers for the Internet X.509 Public Key 4732 Infrastructure Certificate and Certificate Revocation 4733 Lists (CRL) Profile", RFC 3279, April 2002. 4735 [RFC 3280] Housley, R., W. Polk, W. Ford and D. Solo, "Internet 4736 X.509 Public Key Infrastructure: Certificate and 4737 Certificate Revocation List (CRL) Profile", RFC 3280, 4738 April 2002. 4740 [RFC 4055] Schaad, J., B. Kaliski and R. Housley, "Additional 4741 Algorithms and Identifiers for RSA Cryptography for use 4742 in the Internet X.509 Public Key Infrastructure 4743 Certificate and Certificate Revocation List (CRL) 4744 Profile", RFC 4055, June 2005. 4746 [RFC 4120] Neuman, C., T. Yu, S. Hartman and K. Raeburn, "The 4747 Kerberos Network Authentication Service (V5)," RFC 4120, 4748 July 2005. 4750 [RFC 4210] Adams, C., S. Farrell, T. Kause and T. Mononen, "Internet 4751 X.509 Public Key Infrastructure Certificate Management 4752 Protocol (CMP)", RFC 4210, September 2005. 4754 [RFC 4325] Santesson, S. and R. Housley, "Internet X.509 Public Key 4755 Infrastructure Authority Information Access Certificate 4756 Revocation List (CRL) Extension", RFC 4325, December 4757 2005. 4759 [RFC 4491] Leontiev, S., Ed., and D. Shefanovski, Ed., "Using the 4760 GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 4761 Algorithms with the Internet X.509 Public Key 4762 Infrastructure Certificate and CRL Profile", RFC 4491, 4763 May 2006. 4765 [RFC 4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 4766 (LDAP): Technical Specification Road Map", RFC 4510, June 4767 2006. 4769 [RFC 4512] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 4770 (LDAP): Directory Information Models", RFC 4512, June 4771 2006. 4773 [RFC 4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 4774 (LDAP): String Representation of Distinguished Names", 4775 RFC 4514, June 2006. 4777 [RFC 4519] Sciberras, A., Ed., "Lightweight Directory Access 4778 Protocol (LDAP): Schema for User Applications", RFC 4519, 4779 June 2006. 4781 [RFC 4630] Housley, R. and S. Santesson, "Update to DirectoryString 4782 Processing in the Internet X.509 Public Key 4783 Infrastructure Certificate and Certificate Revocation 4784 List (CRL) Profile", RFC 4630, August 2006. 4786 [X.500] ITU-T Recommendation X.500 (2005) | ISO/IEC 9594-1:2005, 4787 Information technology - Open Systems Interconnection - 4788 The Directory: Overview of concepts, models and services. 4790 [X.501] ITU-T Recommendation X.501 (2005) | ISO/IEC 9594-2:2005, 4791 Information technology - Open Systems Interconnection - 4792 The Directory: Models. 4794 [X.509] ITU-T Recommendation X.509 (2005) | ISO/IEC 9594-8:2005, 4795 Information technology - Open Systems Interconnection - 4796 The Directory: Public-key and attribute certificate 4797 frameworks. 4799 [X.520] ITU-T Recommendation X.520 (2005) | ISO/IEC 9594-6:2005, 4800 Information technology - Open Systems Interconnection - 4801 The Directory: Selected attribute types. 4803 [X.660] ITU-T Recommendation X.660 (2004) | ISO/IEC 9834-1:2005, 4804 Information technology - Open Systems Interconnection - 4805 Procedures for the operation of OSI Registration 4806 Authorities: General procedures, and top arcs of the 4807 ASN.1 Object Identifier tree. 4809 [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002, 4810 Information technology - Abstract Syntax Notation One 4811 (ASN.1): Parameterization of ASN.1 specifications. 4813 [X9.55] ANSI X9.55-1997, Public Key Cryptography for the 4814 Financial Services Industry: Extensions to Public Key 4815 Certificates and Certificate Revocation Lists, January 4816 1997. 4818 9 Intellectual Property Rights 4820 The IETF takes no position regarding the validity or scope of any 4821 Intellectual Property Rights or other rights that might be claimed to 4822 pertain to the implementation or use of the technology described in 4823 this document or the extent to which any license under such rights 4824 might or might not be available; nor does it represent that it has 4825 made any independent effort to identify any such rights. Information 4826 on the procedures with respect to rights in RFC documents can be 4827 found in BCP 78 and BCP 79. 4829 Copies of IPR disclosures made to the IETF Secretariat and any 4830 assurances of licenses to be made available, or the result of an 4831 attempt made to obtain a general license or permission for the use of 4832 such proprietary rights by implementers or users of this 4833 specification can be obtained from the IETF on-line IPR repository at 4834 http://www.ietf.org/ipr. 4836 The IETF invites any interested party to bring to its attention any 4837 copyrights, patents or patent applications, or other proprietary 4838 rights that may cover technology that may be required to implement 4839 this standard. Please address the information to the IETF at 4840 ietf-ipr@ietf.org. 4842 10 Security Considerations 4844 The majority of this specification is devoted to the format and 4845 content of certificates and CRLs. Since certificates and CRLs are 4846 digitally signed, no additional integrity service is necessary. 4847 Neither certificates nor CRLs need be kept secret, and unrestricted 4848 and anonymous access to certificates and CRLs has no security 4849 implications. 4851 However, security factors outside the scope of this specification 4852 will affect the assurance provided to certificate users. This 4853 section highlights critical issues to be considered by implementers, 4854 administrators, and users. 4856 The procedures performed by CAs and RAs to validate the binding of 4857 the subject's identity to their public key greatly affect the 4858 assurance that ought to be placed in the certificate. Relying 4859 parties might wish to review the CA's certification practice 4860 statement. This is particularly important when issuing certificates 4861 to other CAs. 4863 The use of a single key pair for both signature and other purposes is 4864 strongly discouraged. Use of separate key pairs for signature and 4865 key management provides several benefits to the users. The 4866 ramifications associated with loss or disclosure of a signature key 4867 are different from loss or disclosure of a key management key. Using 4868 separate key pairs permits a balanced and flexible response. 4869 Similarly, different validity periods or key lengths for each key 4870 pair may be appropriate in some application environments. 4871 Unfortunately, some legacy applications (e.g., SSL) use a single key 4872 pair for signature and key management. 4874 The protection afforded private keys is a critical security factor. 4875 On a small scale, failure of users to protect their private keys will 4876 permit an attacker to masquerade as them, or decrypt their personal 4877 information. On a larger scale, compromise of a CA's private signing 4878 key may have a catastrophic effect. If an attacker obtains the 4879 private key unnoticed, the attacker may issue bogus certificates and 4880 CRLs. Existence of bogus certificates and CRLs will undermine 4881 confidence in the system. If such a compromise is detected, all 4882 certificates issued to the compromised CA MUST be revoked, preventing 4883 services between its users and users of other CAs. Rebuilding after 4884 such a compromise will be problematic, so CAs are advised to 4885 implement a combination of strong technical measures (e.g., tamper- 4886 resistant cryptographic modules) and appropriate management 4887 procedures (e.g., separation of duties) to avoid such an incident. 4889 Loss of a CA's private signing key may also be problematic. The CA 4890 would not be able to produce CRLs or perform normal key rollover. 4891 CAs SHOULD maintain secure backup for signing keys. The security of 4892 the key backup procedures is a critical factor in avoiding key 4893 compromise. 4895 The availability and freshness of revocation information affects the 4896 degree of assurance that ought to be placed in a certificate. While 4897 certificates expire naturally, events may occur during its natural 4898 lifetime that negate the binding between the subject and public key. 4899 If revocation information is untimely or unavailable, the assurance 4900 associated with the binding is clearly reduced. Relying parties 4901 might not be able to process every critical extension that can appear 4902 in a CRL. CAs SHOULD take extra care when making revocation 4903 information available only through CRLs that contain critical 4904 extensions, particularly if support for those extensions is not 4905 mandated by this profile. For example, if revocation information is 4906 supplied using a combination of delta CRLs and full CRLs, and the 4907 delta CRLs are issued more frequently than the full CRLs, then 4908 relying parties that cannot handle the critical extensions related to 4909 delta CRL processing will not be able to obtain the most recent 4910 revocation information. Alternatively, if a full CRL is issued 4911 whenever a delta CRL is issued, then timely revocation information 4912 will be available to all relying parties. Similarly, implementations 4913 of the certification path validation mechanism described in section 6 4914 that omit revocation checking provide less assurance than those that 4915 support it. 4917 The certification path validation algorithm depends on the certain 4918 knowledge of the public keys (and other information) about one or 4919 more trusted CAs. The decision to trust a CA is an important 4920 decision as it ultimately determines the trust afforded a 4921 certificate. The authenticated distribution of trusted CA public 4922 keys (usually in the form of a "self-signed" certificate) is a 4923 security critical out-of-band process that is beyond the scope of 4924 this specification. 4926 In addition, where a key compromise or CA failure occurs for a 4927 trusted CA, the user will need to modify the information provided to 4928 the path validation routine. Selection of too many trusted CAs makes 4929 the trusted CA information difficult to maintain. On the other hand, 4930 selection of only one trusted CA could limit users to a closed 4931 community of users. 4933 The quality of implementations that process certificates also affects 4934 the degree of assurance provided. The path validation algorithm 4935 described in section 6 relies upon the integrity of the trusted CA 4936 information, and especially the integrity of the public keys 4937 associated with the trusted CAs. By substituting public keys for 4938 which an attacker has the private key, an attacker could trick the 4939 user into accepting false certificates. 4941 The binding between a key and certificate subject cannot be stronger 4942 than the cryptographic module implementation and algorithms used to 4943 generate the signature. Short key lengths or weak hash algorithms 4944 will limit the utility of a certificate. CAs are encouraged to note 4945 advances in cryptology so they can employ strong cryptographic 4946 techniques. In addition, CAs SHOULD decline to issue certificates to 4947 CAs or end entities that generate weak signatures. 4949 Inconsistent application of name comparison rules can result in 4950 acceptance of invalid X.509 certification paths, or rejection of 4951 valid ones. The X.500 series of specifications defines rules for 4952 comparing distinguished names that require comparison of strings 4953 without regard to case, character set, multi-character white space 4954 substring, or leading and trailing white space. This specification 4955 relaxes these requirements, requiring support for binary comparison 4956 at a minimum. 4958 CAs MUST encode the distinguished name in the subject field of a CA 4959 certificate identically to the distinguished name in the issuer field 4960 in certificates issued by that CA. If CAs use different encodings, 4961 implementations might fail to recognize name chains for paths that 4962 include this certificate. As a consequence, valid paths could be 4963 rejected. 4965 In addition, name constraints for distinguished names MUST be stated 4966 identically to the encoding used in the subject field or 4967 subjectAltName extension. If not, then name constraints stated as 4968 excludedSubtrees will not match and invalid paths will be accepted 4969 and name constraints expressed as permittedSubtrees will not match 4970 and valid paths will be rejected. To avoid acceptance of invalid 4971 paths, CAs SHOULD state name constraints for distinguished names as 4972 permittedSubtrees wherever possible. 4974 In general, using the nameConstraints extension to constrain one name 4975 form (e.g. DNS names) offers no protection against use of other name 4976 forms (e.g. electronic mail addresses). 4978 While X.509 mandates that names be unambiguous, there is a risk that 4979 two unrelated authorities will issue certificates and/or CRLs under 4980 the same issuer name. As a means of reducing problems and security 4981 issues related to issuer name collisions, CA and CRL issuer names 4982 SHOULD be formed in a way that reduces the likelihood of name 4983 collisions. Implementers should take into account the possible 4984 existence of multiple unrelated CAs and CRL issuers with the same 4985 name. At a minimum, implementations validating CRLs MUST ensure that 4986 the certification path of a certificate and the CRL issuer 4987 certification path used to validate the certificate terminate at the 4988 same trust anchor. 4990 While the local-part of an electronic mail address is case-sensitive 4991 [RFC 2821], emailAddress attribute values are not case-sensitive 4992 [RFC 2985]. As a result, there is a risk that two different email 4993 addresses will be treated as the same address when the matching rule 4994 for the emailAddress attribute is used, if the email server exploits 4995 the case sensitivity of mailbox local-parts. Implementers should not 4996 include an email address in the emailAddress attribute if the email 4997 server that hosts the email address treats the local-part of email 4998 addresses as case-sensitive. 5000 Implementers should be aware of risks involved if the CRL 5001 distribution points or authority information access extensions of 5002 corrupted certificates or CRLs contain links to malicious code. 5003 Implementers should always take the steps of validating the retrieved 5004 data to ensure that the data is properly formed. 5006 When certificates include a cRLDistributionPoints extension with an 5007 https URI or similar scheme, circular dependencies can be introduced. 5008 The relying party is forced to perform an additional path validation 5009 in order to obtain the CRL required to complete the initial path 5010 validation! Circular conditions can also be created with an https 5011 URI (or similar scheme) in the authorityInfoAccess or 5012 subjectInfoAccess extensions. At worst, this situation can create 5013 unresolvable dependencies. 5015 CAs SHOULD NOT include URIs that specify https, ldaps, or similar 5016 schemes in extensions. CAs that include an https URI in one of these 5017 extensions MUST ensure that the server's certificate can be validated 5018 without using the information that is pointed to by the URI. Relying 5019 parties that choose to validate the server's certificate when 5020 obtaining information pointed to by an https URI in the 5021 cRLDistributionPoints, authorityInfoAccess, or subjectInfoAccess 5022 extensions MUST be prepared for the possibility that this will result 5023 in unbounded recursion. 5025 Self-issued certificates provide CAs with one automated mechanism to 5026 indicate changes in the CA's operations. In particular, self-issued 5027 certificates may be used to implement a graceful change-over from one 5028 non-compromised CA key pair to the next. Detailed procedures for "CA 5029 key update" are specified in [RFC 4210], where the CA protects its 5030 new public key using its previous private key and vice versa using 5031 two self-issued certificates. Conforming client implementations will 5032 process the self-issued certificate and determine whether 5033 certificates issued under the new key may be trusted. Self-issued 5034 certificates MAY be used to support other changes in CA operations, 5035 such as additions to the CA's policy set, using similar procedures. 5037 Some legacy implementations support names encoded in the ISO 8859-1 5038 character set (Latin1String) [ISO 8859] but tag them as 5039 TeletexString. TeletexString encodes a larger character set than ISO 5040 8859-1, but it encodes some characters differently. The name 5041 comparison rules specified in section 7.1 assume that TeletexStrings 5042 are encoded as described the ASN.1 standard. When comparing names 5043 encoded using the Latin1String character set false positives and 5044 negatives are possible. 5046 When strings are mapped from internal representations to visual 5047 representations, sometimes two different strings will have the same 5048 or similar visual representations. This can happen for many 5049 different reasons, including use of similar glyphs and use of 5050 composed characters (such as e + ' equaling U+00E9, the Korean 5051 composed characters, and vowels above consonant clusters in certain 5052 languages). As a result of this situation, people doing visual 5053 comparisons between two different names may think they are the same 5054 when in fact they are not. Also, people may mistake one string for 5055 another. Issuers of certificates and relying parties both need to be 5056 aware of this situation. 5058 11 IANA Considerations 5060 Extensions in certificates and CRLs are identified using object 5061 identifiers. The objects are defined in an arc delegated by IANA to 5062 the PKIX Working Group. No further action by IANA is necessary for 5063 this document or any anticipated updates. 5065 12 Authors' Addresses 5067 David Cooper 5068 National Institute of Standards and Technology 5069 100 Bureau Drive, Mail Stop 8930 5070 Gaithersburg, MD 20899-8930 5071 USA 5072 EMail: david.cooper@nist.gov 5074 Stefan Santesson 5075 Microsoft 5076 Tuborg Boulevard 12 5077 2900 Hellerup 5078 Denmark 5079 EMail: stefans@microsoft.com 5081 Stephen Farrell 5082 Distributed Systems Group 5083 Computer Science Department 5084 Trinity College Dublin 5085 Ireland 5086 EMail: stephen.farrell@cs.tcd.ie 5088 Sharon Boeyen 5089 Entrust 5090 1000 Innovation Drive 5091 Ottawa, Ontario 5092 Canada K2K 3E7 5093 EMail: sharon.boeyen@entrust.com 5095 Russell Housley 5096 Vigil Security, LLC 5097 918 Spring Knoll Drive 5098 Herndon, VA 20170 5099 USA 5100 EMail: housley@vigilsec.com 5101 Tim Polk 5102 National Institute of Standards and Technology 5103 100 Bureau Drive, Mail Stop 8930 5104 Gaithersburg, MD 20899-8930 5105 USA 5106 EMail: wpolk@nist.gov 5108 13 Acknowledgments 5110 Warwick Ford also participated in the 3280bis design team meetings 5111 that directed development of this draft. The design team's efforts 5112 were guided by contributions from Matt Crawford, Tom Gindin, Steve 5113 Hanna, Stephen Henson, Paul Hoffman, Takashi Ito, Denis Pinkas, and 5114 Wen-Cheng Wang. 5116 Appendix A. Pseudo-ASN.1 Structures and OIDs 5118 This section describes data objects used by conforming PKI components 5119 in an "ASN.1-like" syntax. This syntax is a hybrid of the 1988 and 5120 1993 ASN.1 syntaxes. The 1988 ASN.1 syntax is augmented with 1993 5121 UNIVERSAL Types UniversalString, BMPString and UTF8String. 5123 The ASN.1 syntax does not permit the inclusion of type statements in 5124 the ASN.1 module, and the 1993 ASN.1 standard does not permit use of 5125 the new UNIVERSAL types in modules using the 1988 syntax. As a 5126 result, this module does not conform to either version of the ASN.1 5127 standard. 5129 This appendix may be converted into 1988 ASN.1 by replacing the 5130 definitions for the UNIVERSAL Types with the 1988 catch-all "ANY". 5132 A.1 Explicitly Tagged Module, 1988 Syntax 5134 PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) 5135 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) } 5137 DEFINITIONS EXPLICIT TAGS ::= 5139 BEGIN 5141 -- EXPORTS ALL -- 5143 -- IMPORTS NONE -- 5145 -- UNIVERSAL Types defined in 1993 and 1998 ASN.1 5146 -- and required by this specification 5148 UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING 5149 -- UniversalString is defined in ASN.1:1993 5151 BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING 5152 -- BMPString is the subtype of UniversalString and models 5153 -- the Basic Multilingual Plane of ISO/IEC 10646 5155 UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 5156 -- The content of this type conforms to RFC 3629. 5158 -- PKIX specific OIDs 5160 id-pkix OBJECT IDENTIFIER ::= 5161 { iso(1) identified-organization(3) dod(6) internet(1) 5162 security(5) mechanisms(5) pkix(7) } 5164 -- PKIX arcs 5166 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 5167 -- arc for private certificate extensions 5168 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 5169 -- arc for policy qualifier types 5170 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 5171 -- arc for extended key purpose OIDS 5172 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 5173 -- arc for access descriptors 5175 -- policyQualifierIds for Internet policy qualifiers 5177 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 5178 -- OID for CPS qualifier 5179 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 5180 -- OID for user notice qualifier 5182 -- access descriptor definitions 5184 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 5185 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 5186 id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 } 5187 id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 } 5189 -- attribute data types 5191 Attribute ::= SEQUENCE { 5192 type AttributeType, 5193 values SET OF AttributeValue } 5194 -- at least one value is required 5196 AttributeType ::= OBJECT IDENTIFIER 5197 AttributeValue ::= ANY -- DEFINED BY AttributeType 5199 AttributeTypeAndValue ::= SEQUENCE { 5200 type AttributeType, 5201 value AttributeValue } 5203 -- suggested naming attributes: Definition of the following 5204 -- information object set may be augmented to meet local 5205 -- requirements. Note that deleting members of the set may 5206 -- prevent interoperability with conforming implementations. 5207 -- presented in pairs: the AttributeType followed by the 5208 -- type definition for the corresponding AttributeValue 5209 --Arc for standard naming attributes 5210 id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 } 5212 -- Naming attributes of type X520name 5214 id-at-name AttributeType ::= { id-at 41 } 5215 id-at-surname AttributeType ::= { id-at 4 } 5216 id-at-givenName AttributeType ::= { id-at 42 } 5217 id-at-initials AttributeType ::= { id-at 43 } 5218 id-at-generationQualifier AttributeType ::= { id-at 44 } 5220 -- Naming attributes of type X520Name: 5221 -- X520name ::= DirectoryString (SIZE (1..ub-name)) 5222 -- 5223 -- Expanded to avoid parameterized type: 5224 X520name ::= CHOICE { 5225 teletexString TeletexString (SIZE (1..ub-name)), 5226 printableString PrintableString (SIZE (1..ub-name)), 5227 universalString UniversalString (SIZE (1..ub-name)), 5228 utf8String UTF8String (SIZE (1..ub-name)), 5229 bmpString BMPString (SIZE (1..ub-name)) } 5231 -- Naming attributes of type X520CommonName 5233 id-at-commonName AttributeType ::= { id-at 3 } 5235 -- Naming attributes of type X520CommonName: 5236 -- X520CommonName ::= DirectoryName (SIZE (1..ub-common-name)) 5237 -- 5238 -- Expanded to avoid parameterized type: 5239 X520CommonName ::= CHOICE { 5240 teletexString TeletexString (SIZE (1..ub-common-name)), 5241 printableString PrintableString (SIZE (1..ub-common-name)), 5242 universalString UniversalString (SIZE (1..ub-common-name)), 5243 utf8String UTF8String (SIZE (1..ub-common-name)), 5244 bmpString BMPString (SIZE (1..ub-common-name)) } 5246 -- Naming attributes of type X520LocalityName 5248 id-at-localityName AttributeType ::= { id-at 7 } 5250 -- Naming attributes of type X520LocalityName: 5251 -- X520LocalityName ::= DirectoryName (SIZE (1..ub-locality-name)) 5252 -- 5253 -- Expanded to avoid parameterized type: 5254 X520LocalityName ::= CHOICE { 5255 teletexString TeletexString (SIZE (1..ub-locality-name)), 5256 printableString PrintableString (SIZE (1..ub-locality-name)), 5257 universalString UniversalString (SIZE (1..ub-locality-name)), 5258 utf8String UTF8String (SIZE (1..ub-locality-name)), 5259 bmpString BMPString (SIZE (1..ub-locality-name)) } 5261 -- Naming attributes of type X520StateOrProvinceName 5263 id-at-stateOrProvinceName AttributeType ::= { id-at 8 } 5265 -- Naming attributes of type X520StateOrProvinceName: 5266 -- X520StateOrProvinceName ::= DirectoryName (SIZE (1..ub-state-name)) 5267 -- 5268 -- Expanded to avoid parameterized type: 5269 X520StateOrProvinceName ::= CHOICE { 5270 teletexString TeletexString (SIZE (1..ub-state-name)), 5271 printableString PrintableString (SIZE (1..ub-state-name)), 5272 universalString UniversalString (SIZE (1..ub-state-name)), 5273 utf8String UTF8String (SIZE (1..ub-state-name)), 5274 bmpString BMPString (SIZE (1..ub-state-name)) } 5276 -- Naming attributes of type X520OrganizationName 5278 id-at-organizationName AttributeType ::= { id-at 10 } 5280 -- Naming attributes of type X520OrganizationName: 5281 -- X520OrganizationName ::= 5282 -- DirectoryName (SIZE (1..ub-organization-name)) 5283 -- 5284 -- Expanded to avoid parameterized type: 5285 X520OrganizationName ::= CHOICE { 5286 teletexString TeletexString 5287 (SIZE (1..ub-organization-name)), 5288 printableString PrintableString 5289 (SIZE (1..ub-organization-name)), 5290 universalString UniversalString 5291 (SIZE (1..ub-organization-name)), 5292 utf8String UTF8String 5293 (SIZE (1..ub-organization-name)), 5295 bmpString BMPString 5296 (SIZE (1..ub-organization-name)) } 5298 -- Naming attributes of type X520OrganizationalUnitName 5300 id-at-organizationalUnitName AttributeType ::= { id-at 11 } 5302 -- Naming attributes of type X520OrganizationalUnitName: 5303 -- X520OrganizationalUnitName ::= 5304 -- DirectoryName (SIZE (1..ub-organizational-unit-name)) 5305 -- 5306 -- Expanded to avoid parameterized type: 5307 X520OrganizationalUnitName ::= CHOICE { 5308 teletexString TeletexString 5309 (SIZE (1..ub-organizational-unit-name)), 5310 printableString PrintableString 5311 (SIZE (1..ub-organizational-unit-name)), 5312 universalString UniversalString 5313 (SIZE (1..ub-organizational-unit-name)), 5314 utf8String UTF8String 5315 (SIZE (1..ub-organizational-unit-name)), 5316 bmpString BMPString 5317 (SIZE (1..ub-organizational-unit-name)) } 5319 -- Naming attributes of type X520Title 5321 id-at-title AttributeType ::= { id-at 12 } 5323 -- Naming attributes of type X520Title: 5324 -- X520Title ::= DirectoryName (SIZE (1..ub-title)) 5325 -- 5326 -- Expanded to avoid parameterized type: 5327 X520Title ::= CHOICE { 5328 teletexString TeletexString (SIZE (1..ub-title)), 5329 printableString PrintableString (SIZE (1..ub-title)), 5330 universalString UniversalString (SIZE (1..ub-title)), 5331 utf8String UTF8String (SIZE (1..ub-title)), 5332 bmpString BMPString (SIZE (1..ub-title)) } 5334 -- Naming attributes of type X520dnQualifier 5336 id-at-dnQualifier AttributeType ::= { id-at 46 } 5338 X520dnQualifier ::= PrintableString 5340 -- Naming attributes of type X520countryName (digraph from IS 3166) 5342 id-at-countryName AttributeType ::= { id-at 6 } 5343 X520countryName ::= PrintableString (SIZE (2)) 5345 -- Naming attributes of type X520SerialNumber 5347 id-at-serialNumber AttributeType ::= { id-at 5 } 5349 X520SerialNumber ::= PrintableString (SIZE (1..ub-serial-number)) 5351 -- Naming attributes of type X520Pseudonym 5353 id-at-pseudonym AttributeType ::= { id-at 65 } 5355 -- Naming attributes of type X520Pseudonym: 5356 -- X520Pseudonym ::= DirectoryName (SIZE (1..ub-pseudonym)) 5357 -- 5358 -- Expanded to avoid parameterized type: 5359 X520Pseudonym ::= CHOICE { 5360 teletexString TeletexString (SIZE (1..ub-pseudonym)), 5361 printableString PrintableString (SIZE (1..ub-pseudonym)), 5362 universalString UniversalString (SIZE (1..ub-pseudonym)), 5363 utf8String UTF8String (SIZE (1..ub-pseudonym)), 5364 bmpString BMPString (SIZE (1..ub-pseudonym)) } 5366 -- Naming attributes of type DomainComponent (from RFC 4519) 5368 id-domainComponent AttributeType ::= { 0 9 2342 19200300 100 1 25 } 5370 DomainComponent ::= IA5String 5372 -- Legacy attributes 5374 pkcs-9 OBJECT IDENTIFIER ::= 5375 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 } 5377 id-emailAddress AttributeType ::= { pkcs-9 1 } 5379 EmailAddress ::= IA5String (SIZE (1..ub-emailaddress-length)) 5381 -- naming data types -- 5383 Name ::= CHOICE { -- only one possibility for now -- 5384 rdnSequence RDNSequence } 5386 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 5388 DistinguishedName ::= RDNSequence 5390 RelativeDistinguishedName ::= SET SIZE (1..MAX) OF AttributeTypeAndValue 5391 -- Directory string type -- 5393 DirectoryString ::= CHOICE { 5394 teletexString TeletexString (SIZE (1..MAX)), 5395 printableString PrintableString (SIZE (1..MAX)), 5396 universalString UniversalString (SIZE (1..MAX)), 5397 utf8String UTF8String (SIZE (1..MAX)), 5398 bmpString BMPString (SIZE (1..MAX)) } 5400 -- certificate and CRL specific structures begin here 5402 Certificate ::= SEQUENCE { 5403 tbsCertificate TBSCertificate, 5404 signatureAlgorithm AlgorithmIdentifier, 5405 signature BIT STRING } 5407 TBSCertificate ::= SEQUENCE { 5408 version [0] Version DEFAULT v1, 5409 serialNumber CertificateSerialNumber, 5410 signature AlgorithmIdentifier, 5411 issuer Name, 5412 validity Validity, 5413 subject Name, 5414 subjectPublicKeyInfo SubjectPublicKeyInfo, 5415 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 5416 -- If present, version MUST be v2 or v3 5417 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 5418 -- If present, version MUST be v2 or v3 5419 extensions [3] Extensions OPTIONAL 5420 -- If present, version MUST be v3 -- } 5422 Version ::= INTEGER { v1(0), v2(1), v3(2) } 5424 CertificateSerialNumber ::= INTEGER 5426 Validity ::= SEQUENCE { 5427 notBefore Time, 5428 notAfter Time } 5430 Time ::= CHOICE { 5431 utcTime UTCTime, 5432 generalTime GeneralizedTime } 5434 UniqueIdentifier ::= BIT STRING 5436 SubjectPublicKeyInfo ::= SEQUENCE { 5437 algorithm AlgorithmIdentifier, 5438 subjectPublicKey BIT STRING } 5440 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 5442 Extension ::= SEQUENCE { 5443 extnID OBJECT IDENTIFIER, 5444 critical BOOLEAN DEFAULT FALSE, 5445 extnValue OCTET STRING 5446 -- contains the DER encoding of an ASN.1 value 5447 -- corresponding to the extension type identified 5448 -- by extnID 5449 } 5451 -- CRL structures 5453 CertificateList ::= SEQUENCE { 5454 tbsCertList TBSCertList, 5455 signatureAlgorithm AlgorithmIdentifier, 5456 signature BIT STRING } 5458 TBSCertList ::= SEQUENCE { 5459 version Version OPTIONAL, 5460 -- if present, MUST be v2 5461 signature AlgorithmIdentifier, 5462 issuer Name, 5463 thisUpdate Time, 5464 nextUpdate Time OPTIONAL, 5465 revokedCertificates SEQUENCE OF SEQUENCE { 5466 userCertificate CertificateSerialNumber, 5467 revocationDate Time, 5468 crlEntryExtensions Extensions OPTIONAL 5469 -- if present, MUST be v2 5470 } OPTIONAL, 5471 crlExtensions [0] Extensions OPTIONAL } 5472 -- if present, MUST be v2 5474 -- Version, Time, CertificateSerialNumber, and Extensions were 5475 -- defined earlier for use in the certificate structure 5477 AlgorithmIdentifier ::= SEQUENCE { 5478 algorithm OBJECT IDENTIFIER, 5479 parameters ANY DEFINED BY algorithm OPTIONAL } 5480 -- contains a value of the type 5481 -- registered for use with the 5482 -- algorithm object identifier value 5484 -- X.400 address syntax starts here 5486 ORAddress ::= SEQUENCE { 5487 built-in-standard-attributes BuiltInStandardAttributes, 5488 built-in-domain-defined-attributes 5489 BuiltInDomainDefinedAttributes OPTIONAL, 5490 -- see also teletex-domain-defined-attributes 5491 extension-attributes ExtensionAttributes OPTIONAL } 5493 -- Built-in Standard Attributes 5495 BuiltInStandardAttributes ::= SEQUENCE { 5496 country-name CountryName OPTIONAL, 5497 administration-domain-name AdministrationDomainName OPTIONAL, 5498 network-address [0] IMPLICIT NetworkAddress OPTIONAL, 5499 -- see also extended-network-address 5500 terminal-identifier [1] IMPLICIT TerminalIdentifier OPTIONAL, 5501 private-domain-name [2] PrivateDomainName OPTIONAL, 5502 organization-name [3] IMPLICIT OrganizationName OPTIONAL, 5503 -- see also teletex-organization-name 5504 numeric-user-identifier [4] IMPLICIT NumericUserIdentifier 5505 OPTIONAL, 5506 personal-name [5] IMPLICIT PersonalName OPTIONAL, 5507 -- see also teletex-personal-name 5508 organizational-unit-names [6] IMPLICIT OrganizationalUnitNames 5509 OPTIONAL } 5510 -- see also teletex-organizational-unit-names 5512 CountryName ::= [APPLICATION 1] CHOICE { 5513 x121-dcc-code NumericString 5514 (SIZE (ub-country-name-numeric-length)), 5515 iso-3166-alpha2-code PrintableString 5516 (SIZE (ub-country-name-alpha-length)) } 5518 AdministrationDomainName ::= [APPLICATION 2] CHOICE { 5519 numeric NumericString (SIZE (0..ub-domain-name-length)), 5520 printable PrintableString (SIZE (0..ub-domain-name-length)) } 5522 NetworkAddress ::= X121Address -- see also extended-network-address 5524 X121Address ::= NumericString (SIZE (1..ub-x121-address-length)) 5526 TerminalIdentifier ::= PrintableString (SIZE (1..ub-terminal-id-length)) 5528 PrivateDomainName ::= CHOICE { 5529 numeric NumericString (SIZE (1..ub-domain-name-length)), 5530 printable PrintableString (SIZE (1..ub-domain-name-length)) } 5532 OrganizationName ::= PrintableString 5533 (SIZE (1..ub-organization-name-length)) 5534 -- see also teletex-organization-name 5536 NumericUserIdentifier ::= NumericString 5537 (SIZE (1..ub-numeric-user-id-length)) 5539 PersonalName ::= SET { 5540 surname [0] IMPLICIT PrintableString 5541 (SIZE (1..ub-surname-length)), 5542 given-name [1] IMPLICIT PrintableString 5543 (SIZE (1..ub-given-name-length)) OPTIONAL, 5544 initials [2] IMPLICIT PrintableString 5545 (SIZE (1..ub-initials-length)) OPTIONAL, 5546 generation-qualifier [3] IMPLICIT PrintableString 5547 (SIZE (1..ub-generation-qualifier-length)) 5548 OPTIONAL } 5549 -- see also teletex-personal-name 5551 OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units) 5552 OF OrganizationalUnitName 5553 -- see also teletex-organizational-unit-names 5555 OrganizationalUnitName ::= PrintableString (SIZE 5556 (1..ub-organizational-unit-name-length)) 5558 -- Built-in Domain-defined Attributes 5560 BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE 5561 (1..ub-domain-defined-attributes) OF 5562 BuiltInDomainDefinedAttribute 5564 BuiltInDomainDefinedAttribute ::= SEQUENCE { 5565 type PrintableString (SIZE 5566 (1..ub-domain-defined-attribute-type-length)), 5567 value PrintableString (SIZE 5568 (1..ub-domain-defined-attribute-value-length)) } 5570 -- Extension Attributes 5572 ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF 5573 ExtensionAttribute 5575 ExtensionAttribute ::= SEQUENCE { 5576 extension-attribute-type [0] IMPLICIT INTEGER 5577 (0..ub-extension-attributes), 5578 extension-attribute-value [1] 5579 ANY DEFINED BY extension-attribute-type } 5581 -- Extension types and attribute values 5583 common-name INTEGER ::= 1 5584 CommonName ::= PrintableString (SIZE (1..ub-common-name-length)) 5586 teletex-common-name INTEGER ::= 2 5588 TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length)) 5590 teletex-organization-name INTEGER ::= 3 5592 TeletexOrganizationName ::= 5593 TeletexString (SIZE (1..ub-organization-name-length)) 5595 teletex-personal-name INTEGER ::= 4 5597 TeletexPersonalName ::= SET { 5598 surname [0] IMPLICIT TeletexString 5599 (SIZE (1..ub-surname-length)), 5600 given-name [1] IMPLICIT TeletexString 5601 (SIZE (1..ub-given-name-length)) OPTIONAL, 5602 initials [2] IMPLICIT TeletexString 5603 (SIZE (1..ub-initials-length)) OPTIONAL, 5604 generation-qualifier [3] IMPLICIT TeletexString 5605 (SIZE (1..ub-generation-qualifier-length)) 5606 OPTIONAL } 5608 teletex-organizational-unit-names INTEGER ::= 5 5610 TeletexOrganizationalUnitNames ::= SEQUENCE SIZE 5611 (1..ub-organizational-units) OF TeletexOrganizationalUnitName 5613 TeletexOrganizationalUnitName ::= TeletexString 5614 (SIZE (1..ub-organizational-unit-name-length)) 5616 pds-name INTEGER ::= 7 5618 PDSName ::= PrintableString (SIZE (1..ub-pds-name-length)) 5620 physical-delivery-country-name INTEGER ::= 8 5622 PhysicalDeliveryCountryName ::= CHOICE { 5623 x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)), 5624 iso-3166-alpha2-code PrintableString 5625 (SIZE (ub-country-name-alpha-length)) } 5627 postal-code INTEGER ::= 9 5629 PostalCode ::= CHOICE { 5630 numeric-code NumericString (SIZE (1..ub-postal-code-length)), 5631 printable-code PrintableString (SIZE (1..ub-postal-code-length)) } 5633 physical-delivery-office-name INTEGER ::= 10 5635 PhysicalDeliveryOfficeName ::= PDSParameter 5637 physical-delivery-office-number INTEGER ::= 11 5639 PhysicalDeliveryOfficeNumber ::= PDSParameter 5641 extension-OR-address-components INTEGER ::= 12 5643 ExtensionORAddressComponents ::= PDSParameter 5645 physical-delivery-personal-name INTEGER ::= 13 5647 PhysicalDeliveryPersonalName ::= PDSParameter 5649 physical-delivery-organization-name INTEGER ::= 14 5651 PhysicalDeliveryOrganizationName ::= PDSParameter 5653 extension-physical-delivery-address-components INTEGER ::= 15 5655 ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter 5657 unformatted-postal-address INTEGER ::= 16 5659 UnformattedPostalAddress ::= SET { 5660 printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) 5661 OF PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL, 5662 teletex-string TeletexString 5663 (SIZE (1..ub-unformatted-address-length)) OPTIONAL } 5665 street-address INTEGER ::= 17 5667 StreetAddress ::= PDSParameter 5669 post-office-box-address INTEGER ::= 18 5671 PostOfficeBoxAddress ::= PDSParameter 5673 poste-restante-address INTEGER ::= 19 5675 PosteRestanteAddress ::= PDSParameter 5677 unique-postal-name INTEGER ::= 20 5679 UniquePostalName ::= PDSParameter 5680 local-postal-attributes INTEGER ::= 21 5682 LocalPostalAttributes ::= PDSParameter 5684 PDSParameter ::= SET { 5685 printable-string PrintableString 5686 (SIZE(1..ub-pds-parameter-length)) OPTIONAL, 5687 teletex-string TeletexString 5688 (SIZE(1..ub-pds-parameter-length)) OPTIONAL } 5690 extended-network-address INTEGER ::= 22 5692 ExtendedNetworkAddress ::= CHOICE { 5693 e163-4-address SEQUENCE { 5694 number [0] IMPLICIT NumericString 5695 (SIZE (1..ub-e163-4-number-length)), 5696 sub-address [1] IMPLICIT NumericString 5697 (SIZE (1..ub-e163-4-sub-address-length)) 5698 OPTIONAL }, 5699 psap-address [0] IMPLICIT PresentationAddress } 5701 PresentationAddress ::= SEQUENCE { 5702 pSelector [0] EXPLICIT OCTET STRING OPTIONAL, 5703 sSelector [1] EXPLICIT OCTET STRING OPTIONAL, 5704 tSelector [2] EXPLICIT OCTET STRING OPTIONAL, 5705 nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING } 5707 terminal-type INTEGER ::= 23 5709 TerminalType ::= INTEGER { 5710 telex (3), 5711 teletex (4), 5712 g3-facsimile (5), 5713 g4-facsimile (6), 5714 ia5-terminal (7), 5715 videotex (8) } (0..ub-integer-options) 5717 -- Extension Domain-defined Attributes 5719 teletex-domain-defined-attributes INTEGER ::= 6 5721 TeletexDomainDefinedAttributes ::= SEQUENCE SIZE 5722 (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute 5724 TeletexDomainDefinedAttribute ::= SEQUENCE { 5725 type TeletexString 5726 (SIZE (1..ub-domain-defined-attribute-type-length)), 5727 value TeletexString 5728 (SIZE (1..ub-domain-defined-attribute-value-length)) } 5730 -- specifications of Upper Bounds MUST be regarded as mandatory 5731 -- from Annex B of ITU-T X.411 Reference Definition of MTS Parameter 5732 -- Upper Bounds 5734 -- Upper Bounds 5735 ub-name INTEGER ::= 32768 5736 ub-common-name INTEGER ::= 64 5737 ub-locality-name INTEGER ::= 128 5738 ub-state-name INTEGER ::= 128 5739 ub-organization-name INTEGER ::= 64 5740 ub-organizational-unit-name INTEGER ::= 64 5741 ub-title INTEGER ::= 64 5742 ub-serial-number INTEGER ::= 64 5743 ub-match INTEGER ::= 128 5744 ub-emailaddress-length INTEGER ::= 255 5745 ub-common-name-length INTEGER ::= 64 5746 ub-country-name-alpha-length INTEGER ::= 2 5747 ub-country-name-numeric-length INTEGER ::= 3 5748 ub-domain-defined-attributes INTEGER ::= 4 5749 ub-domain-defined-attribute-type-length INTEGER ::= 8 5750 ub-domain-defined-attribute-value-length INTEGER ::= 128 5751 ub-domain-name-length INTEGER ::= 16 5752 ub-extension-attributes INTEGER ::= 256 5753 ub-e163-4-number-length INTEGER ::= 15 5754 ub-e163-4-sub-address-length INTEGER ::= 40 5755 ub-generation-qualifier-length INTEGER ::= 3 5756 ub-given-name-length INTEGER ::= 16 5757 ub-initials-length INTEGER ::= 5 5758 ub-integer-options INTEGER ::= 256 5759 ub-numeric-user-id-length INTEGER ::= 32 5760 ub-organization-name-length INTEGER ::= 64 5761 ub-organizational-unit-name-length INTEGER ::= 32 5762 ub-organizational-units INTEGER ::= 4 5763 ub-pds-name-length INTEGER ::= 16 5764 ub-pds-parameter-length INTEGER ::= 30 5765 ub-pds-physical-address-lines INTEGER ::= 6 5766 ub-postal-code-length INTEGER ::= 16 5767 ub-pseudonym INTEGER ::= 128 5768 ub-surname-length INTEGER ::= 40 5769 ub-terminal-id-length INTEGER ::= 24 5770 ub-unformatted-address-length INTEGER ::= 180 5771 ub-x121-address-length INTEGER ::= 16 5773 -- Note - upper bounds on string types, such as TeletexString, are 5774 -- measured in characters. Excepting PrintableString or IA5String, a 5775 -- significantly greater number of octets will be required to hold 5776 -- such a value. As a minimum, 16 octets, or twice the specified 5777 -- upper bound, whichever is the larger, should be allowed for 5778 -- TeletexString. For UTF8String or UniversalString at least four 5779 -- times the upper bound should be allowed. 5781 END 5783 A.2 Implicitly Tagged Module, 1988 Syntax 5785 PKIX1Implicit88 { iso(1) identified-organization(3) dod(6) internet(1) 5786 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19) } 5788 DEFINITIONS IMPLICIT TAGS ::= 5790 BEGIN 5792 -- EXPORTS ALL -- 5794 IMPORTS 5795 id-pe, id-kp, id-qt-unotice, id-qt-cps, 5796 -- delete following line if "new" types are supported -- 5797 BMPString, UTF8String, -- end "new" types -- 5798 ORAddress, Name, RelativeDistinguishedName, 5799 CertificateSerialNumber, Attribute, DirectoryString 5800 FROM PKIX1Explicit88 { iso(1) identified-organization(3) 5801 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 5802 id-mod(0) id-pkix1-explicit(18) }; 5804 -- ISO arc for standard certificate and CRL extensions 5806 id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 5808 -- authority key identifier OID and syntax 5810 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 5812 AuthorityKeyIdentifier ::= SEQUENCE { 5813 keyIdentifier [0] KeyIdentifier OPTIONAL, 5814 authorityCertIssuer [1] GeneralNames OPTIONAL, 5815 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 5816 -- authorityCertIssuer and authorityCertSerialNumber MUST both 5817 -- be present or both be absent 5819 KeyIdentifier ::= OCTET STRING 5821 -- subject key identifier OID and syntax 5822 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 5824 SubjectKeyIdentifier ::= KeyIdentifier 5826 -- key usage extension OID and syntax 5828 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 5830 KeyUsage ::= BIT STRING { 5831 digitalSignature (0), 5832 nonRepudiation (1), -- recent editions of X.509 have 5833 -- renamed this bit to contentCommitment 5834 keyEncipherment (2), 5835 dataEncipherment (3), 5836 keyAgreement (4), 5837 keyCertSign (5), 5838 cRLSign (6), 5839 encipherOnly (7), 5840 decipherOnly (8) } 5842 -- private key usage period extension OID and syntax 5844 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 5846 PrivateKeyUsagePeriod ::= SEQUENCE { 5847 notBefore [0] GeneralizedTime OPTIONAL, 5848 notAfter [1] GeneralizedTime OPTIONAL } 5849 -- either notBefore or notAfter MUST be present 5851 -- certificate policies extension OID and syntax 5853 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 5855 anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 } 5857 CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 5859 PolicyInformation ::= SEQUENCE { 5860 policyIdentifier CertPolicyId, 5861 policyQualifiers SEQUENCE SIZE (1..MAX) OF 5862 PolicyQualifierInfo OPTIONAL } 5864 CertPolicyId ::= OBJECT IDENTIFIER 5866 PolicyQualifierInfo ::= SEQUENCE { 5867 policyQualifierId PolicyQualifierId, 5868 qualifier ANY DEFINED BY policyQualifierId } 5870 -- Implementations that recognize additional policy qualifiers MUST 5871 -- augment the following definition for PolicyQualifierId 5873 PolicyQualifierId ::= OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) 5875 -- CPS pointer qualifier 5877 CPSuri ::= IA5String 5879 -- user notice qualifier 5881 UserNotice ::= SEQUENCE { 5882 noticeRef NoticeReference OPTIONAL, 5883 explicitText DisplayText OPTIONAL } 5885 NoticeReference ::= SEQUENCE { 5886 organization DisplayText, 5887 noticeNumbers SEQUENCE OF INTEGER } 5889 DisplayText ::= CHOICE { 5890 ia5String IA5String (SIZE (1..200)), 5891 visibleString VisibleString (SIZE (1..200)), 5892 bmpString BMPString (SIZE (1..200)), 5893 utf8String UTF8String (SIZE (1..200)) } 5895 -- policy mapping extension OID and syntax 5897 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 5899 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 5900 issuerDomainPolicy CertPolicyId, 5901 subjectDomainPolicy CertPolicyId } 5903 -- subject alternative name extension OID and syntax 5905 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 5907 SubjectAltName ::= GeneralNames 5909 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 5911 GeneralName ::= CHOICE { 5912 otherName [0] AnotherName, 5913 rfc822Name [1] IA5String, 5914 dNSName [2] IA5String, 5915 x400Address [3] ORAddress, 5916 directoryName [4] Name, 5917 ediPartyName [5] EDIPartyName, 5918 uniformResourceIdentifier [6] IA5String, 5919 iPAddress [7] OCTET STRING, 5920 registeredID [8] OBJECT IDENTIFIER } 5922 -- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as 5923 -- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax 5925 AnotherName ::= SEQUENCE { 5926 type-id OBJECT IDENTIFIER, 5927 value [0] EXPLICIT ANY DEFINED BY type-id } 5929 EDIPartyName ::= SEQUENCE { 5930 nameAssigner [0] DirectoryString OPTIONAL, 5931 partyName [1] DirectoryString } 5933 -- issuer alternative name extension OID and syntax 5935 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 5937 IssuerAltName ::= GeneralNames 5939 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 5941 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 5943 -- basic constraints extension OID and syntax 5945 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 5947 BasicConstraints ::= SEQUENCE { 5948 cA BOOLEAN DEFAULT FALSE, 5949 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 5951 -- name constraints extension OID and syntax 5953 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 5955 NameConstraints ::= SEQUENCE { 5956 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 5957 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 5959 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 5961 GeneralSubtree ::= SEQUENCE { 5962 base GeneralName, 5963 minimum [0] BaseDistance DEFAULT 0, 5964 maximum [1] BaseDistance OPTIONAL } 5966 BaseDistance ::= INTEGER (0..MAX) 5968 -- policy constraints extension OID and syntax 5970 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } 5972 PolicyConstraints ::= SEQUENCE { 5973 requireExplicitPolicy [0] SkipCerts OPTIONAL, 5974 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 5976 SkipCerts ::= INTEGER (0..MAX) 5978 -- CRL distribution points extension OID and syntax 5980 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31} 5982 CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 5984 DistributionPoint ::= SEQUENCE { 5985 distributionPoint [0] DistributionPointName OPTIONAL, 5986 reasons [1] ReasonFlags OPTIONAL, 5987 cRLIssuer [2] GeneralNames OPTIONAL } 5989 DistributionPointName ::= CHOICE { 5990 fullName [0] GeneralNames, 5991 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 5993 ReasonFlags ::= BIT STRING { 5994 unused (0), 5995 keyCompromise (1), 5996 cACompromise (2), 5997 affiliationChanged (3), 5998 superseded (4), 5999 cessationOfOperation (5), 6000 certificateHold (6), 6001 privilegeWithdrawn (7), 6002 aACompromise (8) } 6004 -- extended key usage extension OID and syntax 6006 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 6008 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 6010 KeyPurposeId ::= OBJECT IDENTIFIER 6012 -- permit unspecified key uses 6013 anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 } 6015 -- extended key purpose OIDs 6017 id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } 6018 id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } 6019 id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } 6020 id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } 6021 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 6022 id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 } 6024 -- inhibit any policy OID and syntax 6026 id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 } 6028 InhibitAnyPolicy ::= SkipCerts 6030 -- freshest (delta)CRL extension OID and syntax 6032 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } 6034 FreshestCRL ::= CRLDistributionPoints 6036 -- authority info access 6038 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 6040 AuthorityInfoAccessSyntax ::= 6041 SEQUENCE SIZE (1..MAX) OF AccessDescription 6043 AccessDescription ::= SEQUENCE { 6044 accessMethod OBJECT IDENTIFIER, 6045 accessLocation GeneralName } 6047 -- subject info access 6049 id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 } 6051 SubjectInfoAccessSyntax ::= 6052 SEQUENCE SIZE (1..MAX) OF AccessDescription 6054 -- CRL number extension OID and syntax 6056 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 6058 CRLNumber ::= INTEGER (0..MAX) 6060 -- issuing distribution point extension OID and syntax 6061 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 6063 IssuingDistributionPoint ::= SEQUENCE { 6064 distributionPoint [0] DistributionPointName OPTIONAL, 6065 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 6066 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 6067 onlySomeReasons [3] ReasonFlags OPTIONAL, 6068 indirectCRL [4] BOOLEAN DEFAULT FALSE, 6069 onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE } 6070 -- at most one of onlyContainsUserCerts, onlyContainsCACerts, 6071 -- and onlyContainsAttributeCerts may be set to TRUE. 6073 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 6075 BaseCRLNumber ::= CRLNumber 6077 -- reason code extension OID and syntax 6079 id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 } 6081 CRLReason ::= ENUMERATED { 6082 unspecified (0), 6083 keyCompromise (1), 6084 cACompromise (2), 6085 affiliationChanged (3), 6086 superseded (4), 6087 cessationOfOperation (5), 6088 certificateHold (6), 6089 removeFromCRL (8), 6090 privilegeWithdrawn (9), 6091 aACompromise (10) } 6093 -- certificate issuer CRL entry extension OID and syntax 6095 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } 6097 CertificateIssuer ::= GeneralNames 6099 -- hold instruction extension OID and syntax 6101 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 6103 HoldInstructionCode ::= OBJECT IDENTIFIER 6105 -- ANSI x9 arc holdinstruction arc 6107 holdInstruction OBJECT IDENTIFIER ::= 6108 {joint-iso-itu-t(2) member-body(2) us(840) x9cm(10040) 2} 6110 -- ANSI X9 holdinstructions 6112 id-holdinstruction-none OBJECT IDENTIFIER ::= 6113 {holdInstruction 1} -- deprecated 6115 id-holdinstruction-callissuer OBJECT IDENTIFIER ::= {holdInstruction 2} 6117 id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3} 6119 -- invalidity date CRL entry extension OID and syntax 6121 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 6123 InvalidityDate ::= GeneralizedTime 6125 END 6127 Appendix B. ASN.1 Notes 6129 CAs MUST force the serialNumber to be a non-negative integer, that 6130 is, the sign bit in the DER encoding of the INTEGER value MUST be 6131 zero - this can be done by adding a leading (leftmost) `00'H octet if 6132 necessary. This removes a potential ambiguity in mapping between a 6133 string of octets and an integer value. 6135 As noted in section 4.1.2.2, serial numbers can be expected to 6136 contain long integers. Certificate users MUST be able to handle 6137 serialNumber values up to 20 octets in length. Conforming CAs MUST 6138 NOT use serialNumber values longer than 20 octets. 6140 As noted in section 5.2.3, CRL numbers can be expected to contain 6141 long integers. CRL validators MUST be able to handle cRLNumber 6142 values up to 20 octets in length. Conforming CRL issuers MUST NOT 6143 use cRLNumber values longer than 20 octets. 6145 The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 6146 constructs. A valid ASN.1 sequence will have zero or more entries. 6147 The SIZE (1..MAX) construct constrains the sequence to have at least 6148 one entry. MAX indicates the upper bound is unspecified. 6149 Implementations are free to choose an upper bound that suits their 6150 environment. 6152 The character string type PrintableString supports a very basic Latin 6153 character set: the lower case letters 'a' through 'z', upper case 6154 letters 'A' through 'Z', the digits '0' through '9', eleven special 6155 characters ' = ( ) + , - . / : ? and space. 6157 Implementers should note that the at sign ('@') and underscore ('_') 6158 characters are not supported by the ASN.1 type PrintableString. 6159 These characters often appear in Internet addresses. Such addresses 6160 MUST be encoded using an ASN.1 type that supports them. They are 6161 usually encoded as IA5String in either the emailAddress attribute 6162 within a distinguished name or the rfc822Name field of GeneralName. 6163 Conforming implementations MUST NOT encode strings that include 6164 either the at sign or underscore character as PrintableString. 6166 The character string type TeletexString is a superset of 6167 PrintableString. TeletexString supports a fairly standard (ASCII- 6168 like) Latin character set, Latin characters with non-spacing accents 6169 and Japanese characters. 6171 Named bit lists are BIT STRINGs where the values have been assigned 6172 names. This specification makes use of named bit lists in the 6173 definitions for the key usage, CRL distribution points and freshest 6174 CRL certificate extensions, as well as the freshest CRL and issuing 6175 distribution point CRL extensions. When DER encoding a named bit 6176 list, trailing zeros MUST be omitted. That is, the encoded value 6177 ends with the last named bit that is set to one. 6179 The character string type UniversalString supports any of the 6180 characters allowed by [ISO 10646]. ISO 10646 is the Universal 6181 multiple-octet coded Character Set (UCS). 6183 The character string type UTF8String was introduced in the 1997 6184 version of ASN.1, and UTF8String was added to the list of choices for 6185 DirectoryString in the 2001 version of [X.520]. UTF8String is a 6186 universal type and has been assigned tag number 12. The content of 6187 UTF8String was defined by RFC 2044 and updated in RFC 2279, which was 6188 updated in [RFC 3629]. 6190 In anticipation of these changes, and in conformance with IETF Best 6191 Practices codified in [RFC 2277], IETF Policy on Character Sets and 6192 Languages, this document includes UTF8String as a choice in 6193 DirectoryString and in the userNotice certificate policy qualifier. 6195 For many of the attribute types defined in [X.520], the 6196 AttributeValue uses the DirectoryString type. Of the attributes 6197 specified in appendix A, the name, surname, givenName, initials, 6198 generationQualifier, commonName, localityName, stateOrProvinceName, 6199 organizationName, organizationalUnitName, title, and pseudonym 6200 attributes all use the DirectoryString type. X.520 uses a 6201 parameterized type definition [X.683] of DirectoryString to specify 6202 the syntax for each of these attributes. The parameter is used to 6203 indicate the maximum string length allowed for the attribute. In 6204 appendix A, in order to avoid the use of parameterized type 6205 definitions, the DirectoryString type written in its expanded form 6206 for the definition of each of these attribute types. So, the ASN.1 6207 in appendix A describes the syntax for each of these attributes as 6208 being a CHOICE of TeletexString, PrintableString, UniversalString, 6209 UTF8String, and BMPString, with the appropriate constraints on the 6210 string length applied to each of the types in the CHOICE, rather than 6211 using the ASN.1 type DirectoryString to describe the syntax. 6213 Implementers should note that the DER encoding of the SET OF values 6214 requires ordering of the encodings of the values. In particular, 6215 this issue arises with respect to distinguished names. 6217 Implementers should note that the DER encoding of SET or SEQUENCE 6218 components whose value is the DEFAULT omit the component from the 6219 encoded certificate or CRL. For example, a BasicConstraints 6220 extension whose cA value is FALSE would omit the cA boolean from the 6221 encoded certificate. 6223 Object Identifiers (OIDs) are used throughout this specification to 6224 identify certificate policies, public key and signature algorithms, 6225 certificate extensions, etc. There is no maximum size for OIDs. 6226 This specification mandates support for OIDs that have arc elements 6227 with values that are less than 2^28, that is, they MUST be between 0 6228 and 268,435,455, inclusive. This allows each arc element to be 6229 represented within a single 32 bit word. Implementations MUST also 6230 support OIDs where the length of the dotted decimal (see [RFC 4512], 6231 section 1.4) string representation can be up to 100 bytes 6232 (inclusive). Implementations MUST be able to handle OIDs with up to 6233 20 elements (inclusive). CAs SHOULD NOT issue certificates that 6234 contain OIDs that exceed these requirements. Likewise, CRL issuers 6235 SHOULD NOT issue CRLs that contain OIDs that exceed these 6236 requirements. 6238 The content specific rules for encoding GeneralName field values in 6239 the nameConstraints extension differ from rules that apply in other 6240 extensions. In all other certificate, CRL, and CRL entry extensions 6241 specified in this document the encoding rules conform to the rules 6242 for the underlying type. For example, values in the 6243 uniformResourceIdentifier field must contain a valid URI as specified 6244 in [RFC 3986]. The content specific rules for encoding values in the 6245 nameConstraints extension are specified in section 4.2.1.10, and 6246 these rules may not conform to the rules for the underlying type. 6247 For example, when the uniformResourceIdentifier field appears in a 6248 nameConstraints extension, it must hold a DNS name (e.g., 6249 "host.example.com" or ".example.com") rather than a URI. 6251 Implementors are warned that the X.500 standards community has 6252 developed a series of extensibility rules. These rules determine 6253 when an ASN.1 definition can be changed without assigning a new 6254 object identifier (OID). For example, at least two extension 6255 definitions included in [RFC 2459], the predecessor to this profile 6256 document, have different ASN.1 definitions in this specification, but 6257 the same OID is used. If unknown elements appear within an 6258 extension, and the extension is not marked critical, those unknown 6259 elements ought to be ignored, as follows: 6261 (a) ignore all unknown bit name assignments within a bit string; 6263 (b) ignore all unknown named numbers in an ENUMERATED type or 6264 INTEGER type that is being used in the enumerated style, provided 6265 the number occurs as an optional element of a SET or SEQUENCE; and 6267 (c) ignore all unknown elements in SETs, at the end of SEQUENCEs, 6268 or in CHOICEs where the CHOICE is itself an optional element of a 6269 SET or SEQUENCE. 6271 If an extension containing unexpected values is marked critical, the 6272 implementation MUST reject the certificate or CRL containing the 6273 unrecognized extension. 6275 Appendix C. Examples 6277 This section contains four examples: three certificates and a CRL. 6278 The first two certificates and the CRL comprise a minimal 6279 certification path. 6281 Section C.1 contains an annotated hex dump of a "self-signed" 6282 certificate issued by a CA whose distinguished name is 6283 cn=Example CA,dc=example,dc=com. The certificate contains an RSA 6284 public key, and is signed by the corresponding RSA private key. 6286 Section C.2 contains an annotated hex dump of an end entity 6287 certificate. The end entity certificate contains an RSA public key, 6288 and is signed by the private key corresponding to the "self-signed" 6289 certificate in section C.1. 6291 Section C.3 contains an annotated hex dump of an end entity 6292 certificate that contains a DSA public key with parameters, and is 6293 signed with DSA and SHA-1. This certificate is not part of the 6294 minimal certification path. 6296 Section C.4 contains an annotated hex dump of a CRL. The CRL is 6297 issued by the CA whose distinguished name is 6298 cn=Example CA,dc=example,dc=com and the list of revoked certificates 6299 includes the end entity certificate presented in C.2. 6301 The certificates were processed using Peter Gutmann's dumpasn1 6302 utility to generate the output. The source for the dumpasn1 utility 6303 is available at . 6304 The binaries for the certificates and CRLs are available at 6305 http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/pkixtools. 6307 In places in this appendix where a distinguished name is specified 6308 using a string representation, the strings are formatted using the 6309 rules specified in [RFC 4514]. 6311 C.1 RSA Self-Signed Certificate 6313 This section contains an annotated hex dump of a 578 byte version 3 6314 certificate. The certificate contains the following information: 6316 (a) the serial number is 17; 6317 (b) the certificate is signed with RSA and the SHA-1 hash algorithm; 6318 (c) the issuer's distinguished name is 6319 cn=Example CA,dc=example,dc=com; 6320 (d) the subject's distinguished name is 6321 cn=Example CA,dc=example,dc=com; 6322 (e) the certificate was issued on April 30, 2004 and expired on 6323 April 30, 2005; 6324 (f) the certificate contains a 1024 bit RSA public key; 6325 (g) the certificate contains a subject key identifier extension 6326 generated using method (1) of section 4.2.1.2; and 6327 (h) the certificate is a CA certificate (as indicated through the 6328 basic constraints extension.) 6330 0 574: SEQUENCE { 6331 4 423: SEQUENCE { 6332 8 3: [0] { 6333 10 1: INTEGER 2 6334 : } 6335 13 1: INTEGER 17 6336 16 13: SEQUENCE { 6337 18 9: OBJECT IDENTIFIER 6338 : sha1withRSAEncryption (1 2 840 113549 1 1 5) 6339 29 0: NULL 6340 : } 6341 31 67: SEQUENCE { 6342 33 19: SET { 6343 35 17: SEQUENCE { 6344 37 10: OBJECT IDENTIFIER 6345 : domainComponent (0 9 2342 19200300 100 1 25) 6346 49 3: IA5String 'com' 6347 : } 6348 : } 6350 54 23: SET { 6351 56 21: SEQUENCE { 6352 58 10: OBJECT IDENTIFIER 6353 : domainComponent (0 9 2342 19200300 100 1 25) 6354 70 7: IA5String 'example' 6355 : } 6356 : } 6357 79 19: SET { 6358 81 17: SEQUENCE { 6359 83 3: OBJECT IDENTIFIER commonName (2 5 4 3) 6360 88 10: PrintableString 'Example CA' 6361 : } 6362 : } 6363 : } 6364 100 30: SEQUENCE { 6365 102 13: UTCTime 30/04/2004 14:25:34 GMT 6366 117 13: UTCTime 30/04/2005 14:25:34 GMT 6367 : } 6368 132 67: SEQUENCE { 6369 134 19: SET { 6370 136 17: SEQUENCE { 6371 138 10: OBJECT IDENTIFIER 6372 : domainComponent (0 9 2342 19200300 100 1 25) 6373 150 3: IA5String 'com' 6374 : } 6375 : } 6376 155 23: SET { 6377 157 21: SEQUENCE { 6378 159 10: OBJECT IDENTIFIER 6379 : domainComponent (0 9 2342 19200300 100 1 25) 6380 171 7: IA5String 'example' 6381 : } 6382 : } 6383 180 19: SET { 6384 182 17: SEQUENCE { 6385 184 3: OBJECT IDENTIFIER commonName (2 5 4 3) 6386 189 10: PrintableString 'Example CA' 6387 : } 6388 : } 6389 : } 6390 201 159: SEQUENCE { 6391 204 13: SEQUENCE { 6392 206 9: OBJECT IDENTIFIER 6393 : rsaEncryption (1 2 840 113549 1 1 1) 6394 217 0: NULL 6395 : } 6396 219 141: BIT STRING, encapsulates { 6397 223 137: SEQUENCE { 6398 226 129: INTEGER 6399 : 00 C2 D7 97 6D 28 70 AA 5B CF 23 2E 80 70 39 EE 6400 : DB 6F D5 2D D5 6A 4F 7A 34 2D F9 22 72 47 70 1D 6401 : EF 80 E9 CA 30 8C 00 C4 9A 6E 5B 45 B4 6E A5 E6 6402 : 6C 94 0D FA 91 E9 40 FC 25 9D C7 B7 68 19 56 8F 6403 : 11 70 6A D7 F1 C9 11 4F 3A 7E 3F 99 8D 6E 76 A5 6404 : 74 5F 5E A4 55 53 E5 C7 68 36 53 C7 1D 3B 12 A6 6405 : 85 FE BD 6E A1 CA DF 35 50 AC 08 D7 B9 B4 7E 5C 6406 : FE E2 A3 2C D1 23 84 AA 98 C0 9B 66 18 9A 68 47 6407 : E9 6408 358 3: INTEGER 65537 6409 : } 6410 : } 6411 : } 6412 363 66: [3] { 6413 365 64: SEQUENCE { 6414 367 29: SEQUENCE { 6415 369 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14) 6416 374 22: OCTET STRING, encapsulates { 6417 376 20: OCTET STRING 6418 : 08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E 70 6A 4A 6419 : 20 84 2C 32 6420 : } 6421 : } 6422 398 14: SEQUENCE { 6423 400 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) 6424 405 1: BOOLEAN TRUE 6425 408 4: OCTET STRING, encapsulates { 6426 410 2: BIT STRING 1 unused bits 6427 : '0000011'B 6428 : } 6429 : } 6430 414 15: SEQUENCE { 6431 416 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19) 6432 421 1: BOOLEAN TRUE 6433 424 5: OCTET STRING, encapsulates { 6434 426 3: SEQUENCE { 6435 428 1: BOOLEAN TRUE 6436 : } 6437 : } 6438 : } 6439 : } 6440 : } 6441 : } 6442 431 13: SEQUENCE { 6443 433 9: OBJECT IDENTIFIER 6444 : sha1withRSAEncryption (1 2 840 113549 1 1 5) 6445 444 0: NULL 6446 : } 6447 446 129: BIT STRING 6448 : 6C F8 02 74 A6 61 E2 64 04 A6 54 0C 6C 72 13 AD 6449 : 3C 47 FB F6 65 13 A9 85 90 33 EA 76 A3 26 D9 FC 6450 : D1 0E 15 5F 28 B7 EF 93 BF 3C F3 E2 3E 7C B9 52 6451 : FC 16 6E 29 AA E1 F4 7A 6F D5 7F EF B3 95 CA F3 6452 : 66 88 83 4E A1 35 45 84 CB BC 9B B8 C8 AD C5 5E 6453 : 46 D9 0B 0E 8D 80 E1 33 2B DC BE 2B 92 7E 4A 43 6454 : A9 6A EF 8A 63 61 B3 6E 47 38 BE E8 0D A3 67 5D 6455 : F3 FA 91 81 3C 92 BB C5 5F 25 25 EB 7C E7 D8 A1 6456 : } 6458 C.2 End Entity Certificate Using RSA 6460 This section contains an annotated hex dump of a 629 byte version 3 6461 certificate. The certificate contains the following information: 6463 (a) the serial number is 18; 6464 (b) the certificate is signed with RSA and the SHA-1 hash algorithm; 6465 (c) the issuer's distinguished name is 6466 cn=Example CA,dc=example,dc=com; 6467 (d) the subject's distinguished name is 6468 cn=End Entity,dc=example,dc=com; 6469 (e) the certificate was valid from September 15, 2004 through March 6470 15, 2005; 6471 (f) the certificate contains a 1024 bit RSA public key; 6472 (g) the certificate is an end entity certificate, as the basic 6473 constraints extension is not present; 6474 (h) the certificate contains an authority key identifier extension 6475 matching the subject key identifier of the certificate in 6476 appendix C.1; and 6477 (i) the certificate includes one alternative name - an electronic 6478 mail address (rfc822Name) of "end.entity@example.com". 6480 0 625: SEQUENCE { 6481 4 474: SEQUENCE { 6482 8 3: [0] { 6483 10 1: INTEGER 2 6484 : } 6485 13 1: INTEGER 18 6486 16 13: SEQUENCE { 6487 18 9: OBJECT IDENTIFIER 6488 : sha1withRSAEncryption (1 2 840 113549 1 1 5) 6489 29 0: NULL 6490 : } 6491 31 67: SEQUENCE { 6492 33 19: SET { 6493 35 17: SEQUENCE { 6494 37 10: OBJECT IDENTIFIER 6495 : domainComponent (0 9 2342 19200300 100 1 25) 6496 49 3: IA5String 'com' 6497 : } 6498 : } 6499 54 23: SET { 6500 56 21: SEQUENCE { 6501 58 10: OBJECT IDENTIFIER 6502 : domainComponent (0 9 2342 19200300 100 1 25) 6503 70 7: IA5String 'example' 6504 : } 6505 : } 6506 79 19: SET { 6507 81 17: SEQUENCE { 6508 83 3: OBJECT IDENTIFIER commonName (2 5 4 3) 6509 88 10: PrintableString 'Example CA' 6510 : } 6511 : } 6512 : } 6513 100 30: SEQUENCE { 6514 102 13: UTCTime 15/09/2004 11:48:21 GMT 6515 117 13: UTCTime 15/03/2005 11:48:21 GMT 6516 : } 6517 132 67: SEQUENCE { 6518 134 19: SET { 6519 136 17: SEQUENCE { 6520 138 10: OBJECT IDENTIFIER 6521 : domainComponent (0 9 2342 19200300 100 1 25) 6522 150 3: IA5String 'com' 6523 : } 6524 : } 6525 155 23: SET { 6526 157 21: SEQUENCE { 6527 159 10: OBJECT IDENTIFIER 6528 : domainComponent (0 9 2342 19200300 100 1 25) 6529 171 7: IA5String 'example' 6530 : } 6531 : } 6532 180 19: SET { 6533 182 17: SEQUENCE { 6534 184 3: OBJECT IDENTIFIER commonName (2 5 4 3) 6535 189 10: PrintableString 'End Entity' 6536 : } 6537 : } 6538 : } 6539 201 159: SEQUENCE { 6540 204 13: SEQUENCE { 6541 206 9: OBJECT IDENTIFIER 6542 : rsaEncryption (1 2 840 113549 1 1 1) 6543 217 0: NULL 6544 : } 6545 219 141: BIT STRING, encapsulates { 6546 223 137: SEQUENCE { 6547 226 129: INTEGER 6548 : 00 E1 6A E4 03 30 97 02 3C F4 10 F3 B5 1E 4D 7F 6549 : 14 7B F6 F5 D0 78 E9 A4 8A F0 A3 75 EC ED B6 56 6550 : 96 7F 88 99 85 9A F2 3E 68 77 87 EB 9E D1 9F C0 6551 : B4 17 DC AB 89 23 A4 1D 7E 16 23 4C 4F A8 4D F5 6552 : 31 B8 7C AA E3 1A 49 09 F4 4B 26 DB 27 67 30 82 6553 : 12 01 4A E9 1A B6 C1 0C 53 8B 6C FC 2F 7A 43 EC 6554 : 33 36 7E 32 B2 7B D5 AA CF 01 14 C6 12 EC 13 F2 6555 : 2D 14 7A 8B 21 58 14 13 4C 46 A3 9A F2 16 95 FF 6556 : 23 6557 358 3: INTEGER 65537 6558 : } 6559 : } 6560 : } 6561 363 117: [3] { 6562 365 115: SEQUENCE { 6563 367 33: SEQUENCE { 6564 369 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 6565 374 26: OCTET STRING, encapsulates { 6566 376 24: SEQUENCE { 6567 378 22: [1] 'end.entity@example.com' 6568 : } 6569 : } 6570 : } 6571 402 29: SEQUENCE { 6572 404 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14) 6573 409 22: OCTET STRING, encapsulates { 6574 411 20: OCTET STRING 6575 : 17 7B 92 30 FF 44 D6 66 E1 90 10 22 6C 16 4F C0 6576 : 8E 41 DD 6D 6577 : } 6578 : } 6579 433 31: SEQUENCE { 6580 435 3: OBJECT IDENTIFIER 6581 : authorityKeyIdentifier (2 5 29 35) 6582 440 24: OCTET STRING, encapsulates { 6583 442 22: SEQUENCE { 6584 444 20: [0] 6585 : 08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E 70 6A 6586 : 4A 20 84 2C 32 6587 : } 6588 : } 6589 : } 6591 466 14: SEQUENCE { 6592 468 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) 6593 473 1: BOOLEAN TRUE 6594 476 4: OCTET STRING, encapsulates { 6595 478 2: BIT STRING 6 unused bits 6596 : '11'B 6597 : } 6598 : } 6599 : } 6600 : } 6601 : } 6602 482 13: SEQUENCE { 6603 484 9: OBJECT IDENTIFIER 6604 : sha1withRSAEncryption (1 2 840 113549 1 1 5) 6605 495 0: NULL 6606 : } 6607 497 129: BIT STRING 6608 : 00 20 28 34 5B 68 32 01 BB 0A 36 0E AD 71 C5 95 6609 : 1A E1 04 CF AE AD C7 62 14 A4 1B 36 31 C0 E2 0C 6610 : 3D D9 1E C0 00 DC 10 A0 BA 85 6F 41 CB 62 7A B7 6611 : 4C 63 81 26 5E D2 80 45 5E 33 E7 70 45 3B 39 3B 6612 : 26 4A 9C 3B F2 26 36 69 08 79 BB FB 96 43 77 4B 6613 : 61 8B A1 AB 91 64 E0 F3 37 61 3C 1A A3 A4 C9 8A 6614 : B2 BF 73 D4 4D E4 58 E4 62 EA BC 20 74 92 86 0E 6615 : CE 84 60 76 E9 73 BB C7 85 D3 91 45 EA 62 5D CD 6616 : } 6618 C.3 End Entity Certificate Using DSA 6620 This section contains an annotated hex dump of a 914 byte version 3 6621 certificate. The certificate contains the following information: 6623 (a) the serial number is 256; 6624 (b) the certificate is signed with DSA and the SHA-1 hash algorithm; 6625 (c) the issuer's distinguished name is 6626 cn=Example DSA CA,dc=example,dc=com; 6627 (d) the subject's distinguished name is 6628 cn=DSA End Entity,dc=example,dc=com; 6629 (e) the certificate was issued on May 2, 2004 and expired on 6630 May 2, 2005; 6631 (f) the certificate contains a 1024 bit DSA public key with 6632 parameters; 6633 (g) the certificate is an end entity certificate (not a CA 6634 certificate); 6635 (h) the certificate includes a subject alternative name of 6636 "" and an 6637 issuer alternative name of "" - both are 6638 URLs; 6640 (i) the certificate includes an authority key identifier extension 6641 and a certificate policies extension specifying the policy OID 6642 2.16.840.1.101.3.2.1.48.9; and 6643 (j) the certificate includes a critical key usage extension 6644 specifying that the public key is intended for verification of 6645 digital signatures. 6647 0 910: SEQUENCE { 6648 4 846: SEQUENCE { 6649 8 3: [0] { 6650 10 1: INTEGER 2 6651 : } 6652 13 2: INTEGER 256 6653 17 9: SEQUENCE { 6654 19 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 6655 : } 6656 28 71: SEQUENCE { 6657 30 19: SET { 6658 32 17: SEQUENCE { 6659 34 10: OBJECT IDENTIFIER 6660 : domainComponent (0 9 2342 19200300 100 1 25) 6661 46 3: IA5String 'com' 6662 : } 6663 : } 6664 51 23: SET { 6665 53 21: SEQUENCE { 6666 55 10: OBJECT IDENTIFIER 6667 : domainComponent (0 9 2342 19200300 100 1 25) 6668 67 7: IA5String 'example' 6669 : } 6670 : } 6671 76 23: SET { 6672 78 21: SEQUENCE { 6673 80 3: OBJECT IDENTIFIER commonName (2 5 4 3) 6674 85 14: PrintableString 'Example DSA CA' 6675 : } 6676 : } 6677 : } 6678 101 30: SEQUENCE { 6679 103 13: UTCTime 02/05/2004 16:47:38 GMT 6680 118 13: UTCTime 02/05/2005 16:47:38 GMT 6681 : } 6682 133 71: SEQUENCE { 6683 135 19: SET { 6684 137 17: SEQUENCE { 6685 139 10: OBJECT IDENTIFIER 6686 : domainComponent (0 9 2342 19200300 100 1 25) 6687 151 3: IA5String 'com' 6688 : } 6689 : } 6690 156 23: SET { 6691 158 21: SEQUENCE { 6692 160 10: OBJECT IDENTIFIER 6693 : domainComponent (0 9 2342 19200300 100 1 25) 6694 172 7: IA5String 'example' 6695 : } 6696 : } 6697 181 23: SET { 6698 183 21: SEQUENCE { 6699 185 3: OBJECT IDENTIFIER commonName (2 5 4 3) 6700 190 14: PrintableString 'DSA End Entity' 6701 : } 6702 : } 6703 : } 6704 206 439: SEQUENCE { 6705 210 300: SEQUENCE { 6706 214 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) 6707 223 287: SEQUENCE { 6708 227 129: INTEGER 6709 : 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC FB 95 6710 : 32 AC 01 12 33 B9 E0 1C AD 90 9B BC 48 54 9E F3 6711 : 94 77 3C 2C 71 35 55 E6 FE 4F 22 CB D5 D8 3E 89 6712 : 93 33 4D FC BD 4F 41 64 3E A2 98 70 EC 31 B4 50 6713 : DE EB F1 98 28 0A C9 3E 44 B3 FD 22 97 96 83 D0 6714 : 18 A3 E3 BD 35 5B FF EE A3 21 72 6A 7B 96 DA B9 6715 : 3F 1E 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A 6716 : FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48 63 FE 6717 : 43 6718 359 21: INTEGER 6719 : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA 55 F7 6720 : 7D 57 74 81 E5 6721 382 129: INTEGER 6722 : 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91 C0 8E 6723 : 47 F1 0A C3 01 47 C2 44 42 36 A9 92 81 DE 57 C5 6724 : E0 68 86 58 00 7B 1F F9 9B 77 A1 C5 10 A5 80 91 6725 : 78 51 51 3C F6 FC FC CC 46 C6 81 78 92 84 3D F4 6726 : 93 3D 0C 38 7E 1A 5B 99 4E AB 14 64 F6 0C 21 22 6727 : 4E 28 08 9C 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 6728 : 39 A2 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF 6729 : F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE 1E 57 6730 : 18 6731 : } 6732 : } 6733 514 132: BIT STRING, encapsulates { 6734 518 128: INTEGER 6735 : 30 B6 75 F7 7C 20 31 AE 38 BB 7E 0D 2B AB A0 9C 6736 : 4B DF 20 D5 24 13 3C CD 98 E5 5F 6C B7 C1 BA 4A 6737 : BA A9 95 80 53 F0 0D 72 DC 33 37 F4 01 0B F5 04 6738 : 1F 9D 2E 1F 62 D8 84 3A 9B 25 09 5A 2D C8 46 8E 6739 : 2B D4 F5 0D 3B C7 2D C6 6C B9 98 C1 25 3A 44 4E 6740 : 8E CA 95 61 35 7C CE 15 31 5C 23 13 1E A2 05 D1 6741 : 7A 24 1C CB D3 72 09 90 FF 9B 9D 28 C0 A1 0A EC 6742 : 46 9F 0D B8 D0 DC D0 18 A6 2B 5E F9 8F B5 95 BE 6743 : } 6744 : } 6745 649 202: [3] { 6746 652 199: SEQUENCE { 6747 655 57: SEQUENCE { 6748 657 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 6749 662 50: OCTET STRING, encapsulates { 6750 664 48: SEQUENCE { 6751 666 46: [6] 6752 : 'http://www.example.com/users/DSAendentity.' 6753 : 'html' 6754 : } 6755 : } 6756 : } 6757 714 33: SEQUENCE { 6758 716 3: OBJECT IDENTIFIER issuerAltName (2 5 29 18) 6759 721 26: OCTET STRING, encapsulates { 6760 723 24: SEQUENCE { 6761 725 22: [6] 'http://www.example.com' 6762 : } 6763 : } 6764 : } 6765 749 29: SEQUENCE { 6766 751 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14) 6767 756 22: OCTET STRING, encapsulates { 6768 758 20: OCTET STRING 6769 : DD 25 66 96 43 AB 78 11 43 44 FE 95 16 F9 D9 B6 6770 : B7 02 66 8D 6771 : } 6772 : } 6773 780 31: SEQUENCE { 6774 782 3: OBJECT IDENTIFIER 6775 : authorityKeyIdentifier (2 5 29 35) 6776 787 24: OCTET STRING, encapsulates { 6777 789 22: SEQUENCE { 6778 791 20: [0] 6779 : 86 CA A5 22 81 62 EF AD 0A 89 BC AD 72 41 2C 6780 : 29 49 F4 86 56 6781 : } 6782 : } 6783 : } 6785 813 23: SEQUENCE { 6786 815 3: OBJECT IDENTIFIER certificatePolicies (2 5 29 32) 6787 820 16: OCTET STRING, encapsulates { 6788 822 14: SEQUENCE { 6789 824 12: SEQUENCE { 6790 826 10: OBJECT IDENTIFIER '2 16 840 1 101 3 2 1 48 9' 6791 : } 6792 : } 6793 : } 6794 : } 6795 838 14: SEQUENCE { 6796 840 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) 6797 845 1: BOOLEAN TRUE 6798 848 4: OCTET STRING, encapsulates { 6799 850 2: BIT STRING 7 unused bits 6800 : '1'B (bit 0) 6801 : } 6802 : } 6803 : } 6804 : } 6805 : } 6806 854 9: SEQUENCE { 6807 856 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 6808 : } 6809 865 47: BIT STRING, encapsulates { 6810 868 44: SEQUENCE { 6811 870 20: INTEGER 6812 : 65 57 07 34 DD DC CA CC 5E F4 02 F4 56 42 2C 5E 6813 : E1 B3 3B 80 6814 892 20: INTEGER 6815 : 60 F4 31 17 CA F4 CF FF EE F4 08 A7 D9 B2 61 BE 6816 : B1 C3 DA BF 6817 : } 6818 : } 6819 : } 6821 C.4 Certificate Revocation List 6823 This section contains an annotated hex dump of a version 2 CRL with 6824 two extensions (cRLNumber and authorityKeyIdentifier). The CRL was 6825 issued by cn=Example CA,dc=example,dc=com on February 5, 2005; the 6826 next scheduled issuance was February 6, 2005. The CRL includes one 6827 revoked certificate: serial number 18, which was revoked on November 6828 19, 2004 due to keyCompromise. The CRL itself is number 12, and it 6829 was signed with RSA and SHA-1. 6831 0 352: SEQUENCE { 6832 4 202: SEQUENCE { 6833 7 1: INTEGER 1 6834 10 13: SEQUENCE { 6835 12 9: OBJECT IDENTIFIER 6836 : sha1withRSAEncryption (1 2 840 113549 1 1 5) 6837 23 0: NULL 6838 : } 6839 25 67: SEQUENCE { 6840 27 19: SET { 6841 29 17: SEQUENCE { 6842 31 10: OBJECT IDENTIFIER 6843 : domainComponent (0 9 2342 19200300 100 1 25) 6844 43 3: IA5String 'com' 6845 : } 6846 : } 6847 48 23: SET { 6848 50 21: SEQUENCE { 6849 52 10: OBJECT IDENTIFIER 6850 : domainComponent (0 9 2342 19200300 100 1 25) 6851 64 7: IA5String 'example' 6852 : } 6853 : } 6854 73 19: SET { 6855 75 17: SEQUENCE { 6856 77 3: OBJECT IDENTIFIER commonName (2 5 4 3) 6857 82 10: PrintableString 'Example CA' 6858 : } 6859 : } 6860 : } 6861 94 13: UTCTime 05/02/2005 12:00:00 GMT 6862 109 13: UTCTime 06/02/2005 12:00:00 GMT 6863 124 34: SEQUENCE { 6864 126 32: SEQUENCE { 6865 128 1: INTEGER 18 6866 131 13: UTCTime 19/11/2004 15:57:03 GMT 6867 146 12: SEQUENCE { 6868 148 10: SEQUENCE { 6869 150 3: OBJECT IDENTIFIER cRLReason (2 5 29 21) 6870 155 3: OCTET STRING, encapsulates { 6871 157 1: ENUMERATED 1 6872 : } 6873 : } 6874 : } 6875 : } 6876 : } 6877 160 47: [0] { 6878 162 45: SEQUENCE { 6879 164 31: SEQUENCE { 6880 166 3: OBJECT IDENTIFIER 6881 : authorityKeyIdentifier (2 5 29 35) 6882 171 24: OCTET STRING, encapsulates { 6883 173 22: SEQUENCE { 6884 175 20: [0] 6885 : 08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E 70 6A 6886 : 4A 20 84 2C 32 6887 : } 6888 : } 6889 : } 6890 197 10: SEQUENCE { 6891 199 3: OBJECT IDENTIFIER cRLNumber (2 5 29 20) 6892 204 3: OCTET STRING, encapsulates { 6893 206 1: INTEGER 12 6894 : } 6895 : } 6896 : } 6897 : } 6898 : } 6899 209 13: SEQUENCE { 6900 211 9: OBJECT IDENTIFIER 6901 : sha1withRSAEncryption (1 2 840 113549 1 1 5) 6902 222 0: NULL 6903 : } 6904 224 129: BIT STRING 6905 : 22 DC 18 7D F7 08 CE CC 75 D0 D0 6A 9B AD 10 F4 6906 : 76 23 B4 81 6E B5 6D BE 0E FB 15 14 6C C8 17 6D 6907 : 1F EE 90 17 A2 6F 60 E4 BD AA 8C 55 DE 8E 84 6F 6908 : 92 F8 9F 10 12 27 AF 4A D4 2F 85 E2 36 44 7D AA 6909 : A3 4C 25 38 15 FF 00 FD 3E 7E EE 3D 26 12 EB D8 6910 : E7 2B 62 E2 2B C3 46 80 EF 78 82 D1 15 C6 D0 9C 6911 : 72 6A CB CE 7A ED 67 99 8B 6E 70 81 7D 43 42 74 6912 : C1 A6 AF C1 55 17 A2 33 4C D6 06 98 2B A4 FC 2E 6913 : } 6915 Full Copyright Statement 6917 Copyright (C) The IETF Trust (2008). 6919 This document is subject to the rights, licenses and restrictions 6920 contained in BCP 78, and except as set forth therein, the authors 6921 retain all their rights. 6923 This document and the information contained herein are provided on an 6924 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 6925 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 6926 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 6927 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 6928 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 6929 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 6931 This document and translations of it may be copied and furnished to 6932 others, and derivative works that comment on or otherwise explain it 6933 or assist in its implementation may be prepared, copied, published 6934 and distributed, in whole or in part, without restriction of any 6935 kind, provided that the above copyright notice and this paragraph are 6936 included on all such copies and derivative works. In addition, the 6937 ASN.1 modules presented may be used in whole or in part without 6938 inclusion of the copyright notice. However, this document itself may 6939 not be modified in any way, such as by removing the copyright notice 6940 or references to the Internet Society or other Internet 6941 organizations, except as needed for the purpose of developing 6942 Internet standards in which case the procedures for copyrights 6943 defined in the Internet Standards process shall be followed, or as 6944 required to translate it into languages other than English.