idnits 2.17.00 (12 Aug 2021) /tmp/idnits28243/draft-ietf-pkix-new-part1-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 115 longer pages, the longest (page 1) being 64 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 115 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 23 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 599 has weird spacing: '...issuing a cer...' == Line 609 has weird spacing: '...: This is th...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 14, 2000) is 7980 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 5204 -- Looks like a reference, but probably isn't: '1' on line 4553 -- Looks like a reference, but probably isn't: '2' on line 4554 -- Looks like a reference, but probably isn't: '3' on line 5099 == Missing Reference: 'ISO 8859-1' is mentioned on line 894, but not defined -- Looks like a reference, but probably isn't: '4' on line 4556 -- Looks like a reference, but probably isn't: '5' on line 4417 -- Looks like a reference, but probably isn't: '6' on line 4418 -- Looks like a reference, but probably isn't: '7' on line 4419 -- Looks like a reference, but probably isn't: '8' on line 4420 == Missing Reference: 'RFC1738' is mentioned on line 2421, but not defined ** Obsolete undefined reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) == Missing Reference: 'RFC1778' is mentioned on line 2421, but not defined ** Obsolete undefined reference: RFC 1778 (Obsoleted by RFC 3494) == Missing Reference: 'UNIVERSAL 28' is mentioned on line 3714, but not defined == Missing Reference: 'UNIVERSAL 30' is mentioned on line 3717, but not defined == Missing Reference: 'UNIVERSAL 12' is mentioned on line 3721, but not defined == Missing Reference: 'APPLICATION 1' is mentioned on line 4019, but not defined == Missing Reference: 'APPLICATION 2' is mentioned on line 4025, but not defined == Missing Reference: 'LDAP' is mentioned on line 4673, but not defined == Unused Reference: 'RFC 1423' is defined on line 3471, but no explicit reference was found in the text == Unused Reference: 'RFC 1778' is defined on line 3485, but no explicit reference was found in the text == Unused Reference: 'RFC 1883' is defined on line 3489, but no explicit reference was found in the text == Unused Reference: 'RFC 2119' is defined on line 3492, but no explicit reference was found in the text == Unused Reference: 'RFC 2277' is defined on line 3499, but no explicit reference was found in the text == Unused Reference: 'RFC 2279' is defined on line 3502, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Downref: Normative reference to an Historic RFC: RFC 1422 ** Downref: Normative reference to an Historic RFC: RFC 1423 ** Obsolete normative reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) ** Obsolete normative reference: RFC 1519 (Obsoleted by RFC 4632) ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 1778 (Obsoleted by RFC 3494) ** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) == Outdated reference: draft-ietf-cat-kerberos-pk-init has been published as RFC 4556 == Outdated reference: draft-ietf-pkix-ipki-pkalgs has been published as RFC 3279 Summary: 18 errors (**), 0 flaws (~~), 26 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group R. Housley (SPYRUS) 3 Internet Draft W. Ford (VeriSign) 4 W. Polk (NIST) 5 D. Solo (Citigroup) 6 expires in six months July 14, 2000 8 Internet X.509 Public Key Infrastructure 10 Certificate and CRL Profile 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 To view the entire list of current Internet-Drafts, please check the 34 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 35 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 36 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 37 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 39 Copyright (C) The Internet Society (1998). All Rights Reserved. 41 Abstract 43 This is the first draft of a specification based upon RFC 2459. When 44 complete, this specification will obsolete RFC 2459. This 45 specification includes numerous edits and clarifications. The most 46 notable departures from RFC 2459 are found in Section 6, Path 47 Validation. In RFC 2459, the reader was expected to augment the path 48 validation algorithm, which concentrated upon policy processing, with 49 information embedded in earlier sections. For example, parameter 50 inheritance is discussed in Section 7, Algorithm Support, and can 51 certainly affect the validity of a certification path. However, 52 parameter inheritance was omitted from the path validation algorithm 53 in RFC 2459. In this draft, the path validation algorithm has a 54 comprehensive and extremely detailed description. Details such as 55 parameter inheritance are covered thoroughly. In addition, this 56 draft anticipates certain corrections proposed in the X.509 standard 57 for the policy processing aspects of path validation. 59 A new section 6.3, CRL validation, has been added as well. This 60 section provides a supplement to the path validation algorithm that 61 determines if a particular CRL may be used to verify the status of a 62 particular certificate. (The basic path validation algorithm is, by 63 design, independent of the type and format of status information.) 65 This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use 66 in the Internet. An overview of the approach and model are provided 67 as an introduction. The X.509 v3 certificate format is described in 68 detail, with additional information regarding the format and 69 semantics of Internet name forms (e.g., IP addresses). Standard 70 certificate extensions are described and one new Internet-specific 71 extension is defined. A required set of certificate extensions is 72 specified. The X.509 v2 CRL format is described and a required 73 extension set is defined as well. An algorithm for X.509 certificate 74 path validation is described. Supplemental information is provided 75 describing the format of public keys and digital signatures in X.509 76 certificates for common Internet public key encryption algorithms 77 (i.e., RSA, DSA, and Diffie-Hellman). ASN.1 modules and examples are 78 provided in the appendices. 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in RFC 2119. 84 Please send comments on this document to the ietf-pkix@imc.org mail 85 list. 87 Table of Contents 89 1 Introduction ................................................ 6 90 2 Requirements and Assumptions ................................ 7 91 2.1 Communication and Topology ................................ 7 92 2.2 Acceptability Criteria .................................... 8 93 2.3 User Expectations ......................................... 8 94 2.4 Administrator Expectations ................................ 8 95 3 Overview of Approach ........................................ 8 96 3.1 X.509 Version 3 Certificate ............................... 10 97 3.2 Certification Paths and Trust ............................. 11 98 3.3 Revocation ................................................ 13 99 3.4 Operational Protocols ..................................... 14 100 3.5 Management Protocols ...................................... 14 101 4 Certificate and Certificate Extensions Profile .............. 15 102 4.1 Basic Certificate Fields .................................. 16 103 4.1.1 Certificate Fields ...................................... 17 104 4.1.1.1 tbsCertificate ........................................ 17 105 4.1.1.2 signatureAlgorithm .................................... 17 106 4.1.1.3 signatureValue ........................................ 18 107 4.1.2 TBSCertificate .......................................... 18 108 4.1.2.1 Version ............................................... 18 109 4.1.2.2 Serial number ......................................... 18 110 4.1.2.3 Signature ............................................. 19 111 4.1.2.4 Issuer ................................................ 19 112 4.1.2.5 Validity .............................................. 22 113 4.1.2.5.1 UTCTime ............................................. 23 114 4.1.2.5.2 GeneralizedTime ..................................... 23 115 4.1.2.6 Subject ............................................... 23 116 4.1.2.7 Subject Public Key Info ............................... 24 117 4.1.2.8 Unique Identifiers .................................... 25 118 4.1.2.9 Extensions ............................................. 25 119 4.2 Certificate Extensions .................................... 26 120 4.2.1 Standard Extensions ..................................... 26 121 4.2.1.1 Authority Key Identifier .............................. 26 122 4.2.1.2 Subject Key Identifier ................................ 27 123 4.2.1.3 Key Usage ............................................. 28 124 4.2.1.4 Private Key Usage Period .............................. 30 125 4.2.1.5 Certificate Policies .................................. 30 126 4.2.1.6 Policy Mappings ....................................... 33 127 4.2.1.7 Subject Alternative Name .............................. 33 128 4.2.1.8 Issuer Alternative Name ............................... 36 129 4.2.1.9 Subject Directory Attributes .......................... 36 130 4.2.1.10 Basic Constraints .................................... 36 131 4.2.1.11 Name Constraints ..................................... 37 132 4.2.1.12 Policy Constraints ................................... 39 133 4.2.1.13 Extended key usage field ............................. 40 134 4.2.1.14 CRL Distribution Points .............................. 41 135 4.2.1.15 Inhibit Any-Policy ................................... 42 136 4.2.1.16 Freshest CRL ......................................... 43 137 4.2.2 Internet Certificate Extensions ......................... 43 138 4.2.2.1 Authority Information Access .......................... 43 139 5 CRL and CRL Extensions Profile .............................. 45 140 5.1 CRL Fields ................................................ 45 141 5.1.1 CertificateList Fields .................................. 46 142 5.1.1.1 tbsCertList ........................................... 46 143 5.1.1.2 signatureAlgorithm .................................... 46 144 5.1.1.3 signatureValue ........................................ 47 145 5.1.2 Certificate List "To Be Signed" ......................... 47 146 5.1.2.1 Version ............................................... 47 147 5.1.2.2 Signature ............................................. 47 148 5.1.2.3 Issuer Name ........................................... 47 149 5.1.2.4 This Update ........................................... 48 150 5.1.2.5 Next Update ........................................... 48 151 5.1.2.6 Revoked Certificates .................................. 48 152 5.1.2.7 Extensions ............................................ 49 153 5.2 CRL Extensions ............................................ 49 154 5.2.1 Authority Key Identifier ................................ 49 155 5.2.2 Issuer Alternative Name ................................. 49 156 5.2.3 CRL Number .............................................. 50 157 5.2.4 Delta CRL Indicator ..................................... 50 158 5.2.5 Issuing Distribution Point .............................. 52 159 5.2.6 Freshest CRL ............................................ 53 160 5.3 CRL Entry Extensions ...................................... 53 161 5.3.1 Reason Code ............................................. 53 162 5.3.2 Hold Instruction Code ................................... 54 163 5.3.3 Invalidity Date ......................................... 54 164 5.3.4 Certificate Issuer ...................................... 55 165 6 Certificate Path Validation ................................. 55 166 6.1 Basic Path Validation ..................................... 56 167 6.1.1 Inputs ................................................... 58 168 6.1.2 Initialization ........................................... 59 169 6.1.3 Basic Certificate Processing ............................. 62 170 6.1.4 Preparation for Certificate i+1 .......................... 67 171 6.1.5 Wrap-up procedure ........................................ 70 172 6.1.6 Outputs .................................................. 71 173 6.2 Extending Path Validation ................................. 71 174 6.3 CRL Validation ............................................ 72 175 6.3.1 Revocation Inputs ....................................... 72 176 6.3.2 Initialization and Revocation State Variables ........... 72 177 6.3.3 CRL Processing .......................................... 73 178 7 References .................................................. 75 179 8 Intellectual Property Rights ................................ 77 180 9 Security Considerations ..................................... 77 181 Appendix A. ASN.1 Structures and OIDs ......................... 81 182 A.1 Explicitly Tagged Module, 1988 Syntax ...................... 81 183 A.2 Implicitly Tagged Module, 1988 Syntax ...................... 94 184 Appendix B. ASN.1 Notes ....................................... 101 185 Appendix C. Examples .......................................... 102 186 C.1 Certificate ............................................... 103 187 C.2 Certificate ............................................... 106 188 C.3 End-Entity Certificate Using RSA .......................... 109 189 C.4 Certificate Revocation List ............................... 112 190 Appendix D. Author Addresses .................................. 114 191 Appendix E. Full Copyright Statement .......................... 114 193 1 Introduction 195 This specification is one part of a family of standards for the X.509 196 Public Key Infrastructure (PKI) for the Internet. This specification 197 is a standalone document; implementations of this standard may 198 proceed independent from the other parts. 200 This specification profiles the format and semantics of certificates 201 and certificate revocation lists for the Internet PKI. Procedures 202 are described for processing of certification paths in the Internet 203 environment. Encoding rules are provided for popular cryptographic 204 algorithms. Finally, ASN.1 modules are provided in the appendices 205 for all data structures defined or referenced. 207 The specification describes the requirements which inspire the crea- 208 tion of this document and the assumptions which affect its scope in 209 Section 2. Section 3 presents an architectural model and describes 210 its relationship to previous IETF and ISO/IEC/ITU standards. In par- 211 ticular, this document's relationship with the IETF PEM specifica- 212 tions and the ISO/IEC/ITU X.509 documents are described. 214 The specification profiles the X.509 version 3 certificate in Section 215 4, and the X.509 version 2 certificate revocation list (CRL) in Sec- 216 tion 5. The profiles include the identification of ISO/IEC/ITU and 217 ANSI extensions which may be useful in the Internet PKI. The profiles 218 are presented in the 1988 Abstract Syntax Notation One (ASN.1) rather 219 than the 1994 syntax used in the ISO/IEC/ITU standards. 221 This specification also includes path validation procedures in Sec- 222 tion 6. These procedures are based upon the ISO/IEC/ITU definition, 223 but the presentation assumes one or more self-signed trusted CA cer- 224 tificates. Implementations are required to derive the same results 225 but are not required to use the specified procedures. 227 Procedures for identification and encoding of public key materials 228 and digital signatures are defined in [PKIX ALGS]. Implementations of 229 this specification are not required to use any particular crypto- 230 graphic algorithms. However, conforming implementations which use 231 the algorithms identified in [PKIX ALGS] are required to identify and 232 encode the public key materials and digital signatures as described 233 in that specification. 235 Finally, three appendices are provided to aid implementers. Appendix 236 A contains all ASN.1 structures defined or referenced within this 237 specification. As above, the material is presented in the 1988 238 Abstract Syntax Notation One (ASN.1) rather than the 1994 syntax. 239 Appendix B contains notes on less familiar features of the ASN.1 240 notation used within this specification. Appendix C contains 241 examples of a conforming certificate and a conforming CRL. 243 2 Requirements and Assumptions 245 The goal of this specification is to develop a profile to facilitate 246 the use of X.509 certificates within Internet applications for those 247 communities wishing to make use of X.509 technology. Such applica- 248 tions may include WWW, electronic mail, user authentication, and 249 IPsec. In order to relieve some of the obstacles to using X.509 cer- 250 tificates, this document defines a profile to promote the development 251 of certificate management systems; development of application tools; 252 and interoperability determined by policy. 254 Some communities will need to supplement, or possibly replace, this 255 profile in order to meet the requirements of specialized application 256 domains or environments with additional authorization, assurance, or 257 operational requirements. However, for basic applications, common 258 representations of frequently used attributes are defined so that 259 application developers can obtain necessary information without 260 regard to the issuer of a particular certificate or certificate revo- 261 cation list (CRL). 263 A certificate user should review the certificate policy generated by 264 the certification authority (CA) before relying on the authentication 265 or non-repudiation services associated with the public key in a par- 266 ticular certificate. To this end, this standard does not prescribe 267 legally binding rules or duties. 269 As supplemental authorization and attribute management tools emerge, 270 such as attribute certificates, it may be appropriate to limit the 271 authenticated attributes that are included in a certificate. These 272 other management tools may provide more appropriate methods of con- 273 veying many authenticated attributes. 275 2.1 Communication and Topology 277 The users of certificates will operate in a wide range of environ- 278 ments with respect to their communication topology, especially users 279 of secure electronic mail. This profile supports users without high 280 bandwidth, real-time IP connectivity, or high connection availabil- 281 ity. In addition, the profile allows for the presence of firewall or 282 other filtered communication. 284 This profile does not assume the deployment of an X.500 Directory 285 system. The profile does not prohibit the use of an X.500 Directory, 286 but other means of distributing certificates and certificate revoca- 287 tion lists (CRLs) may be used. 289 2.2 Acceptability Criteria 291 The goal of the Internet Public Key Infrastructure (PKI) is to meet 292 the needs of deterministic, automated identification, authentication, 293 access control, and authorization functions. Support for these ser- 294 vices determines the attributes contained in the certificate as well 295 as the ancillary control information in the certificate such as pol- 296 icy data and certification path constraints. 298 2.3 User Expectations 300 Users of the Internet PKI are people and processes who use client 301 software and are the subjects named in certificates. These uses 302 include readers and writers of electronic mail, the clients for WWW 303 browsers, WWW servers, and the key manager for IPsec within a router. 304 This profile recognizes the limitations of the platforms these users 305 employ and the limitations in sophistication and attentiveness of the 306 users themselves. This manifests itself in minimal user configura- 307 tion responsibility (e.g., trusted CA keys, rules), explicit platform 308 usage constraints within the certificate, certification path con- 309 straints which shield the user from many malicious actions, and 310 applications which sensibly automate validation functions. 312 2.4 Administrator Expectations 314 As with user expectations, the Internet PKI profile is structured to 315 support the individuals who generally operate CAs. Providing 316 administrators with unbounded choices increases the chances that a 317 subtle CA administrator mistake will result in broad compromise. 318 Also, unbounded choices greatly complicate the software that shall 319 process and validate the certificates created by the CA. 321 3 Overview of Approach 323 Following is a simplified view of the architectural model assumed by 324 the PKIX specifications. 326 +---+ 327 | C | +------------+ 328 | e | <-------------------->| End entity | 329 | r | Operational +------------+ 330 | t | transactions ^ 331 | | and management | Management 332 | / | transactions | transactions 333 | | | PKI users 334 | C | v 335 | R | -------------------+--+-----------+---------------- 336 | L | ^ ^ 337 | | | | PKI management 338 | | v | entities 339 | R | +------+ | 340 | e | <---------------------| RA | <---+ | 341 | p | Publish certificate +------+ | | 342 | o | | | 343 | s | | | 344 | I | v v 345 | t | +------------+ 346 | o | <------------------------------| CA | 347 | r | Publish certificate +------------+ 348 | y | Publish CRL ^ 349 | | | 350 +---+ Management | 351 transactions | 352 v 353 +------+ 354 | CA | 355 +------+ 357 Figure 1 - PKI Entities 359 The components in this model are: 361 end entity: user of PKI certificates and/or end user system that 362 is the subject of a certificate; 363 CA: certification authority; 364 RA: registration authority, i.e., an optional system to 365 which a CA delegates certain management functions; 366 repository: a system or collection of distributed systems that 367 store certificates and CRLs and serves as a means of 368 distributing these certificates and CRLs to end 369 entities. 371 3.1 X.509 Version 3 Certificate 373 Users of a public key require confidence that the associated private 374 key is owned by the correct remote subject (person or system) with 375 which an encryption or digital signature mechanism will be used. 376 This confidence is obtained through the use of public key certifi- 377 cates, which are data structures that bind public key values to sub- 378 jects. The binding is asserted by having a trusted CA digitally sign 379 each certificate. The CA may base this assertion upon technical means 380 (a.k.a., proof of posession through a challenge-response protocol), 381 presentation of the private key, or on an assertion by the subject. 382 A certificate has a limited valid lifetime which is indicated in its 383 signed contents. Because a certificate's signature and timeliness 384 can be independently checked by a certificate-using client, certifi- 385 cates can be distributed via untrusted communications and server sys- 386 tems, and can be cached in unsecured storage in certificate-using 387 systems. 389 ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8, which was 390 first published in 1988 as part of the X.500 Directory recommenda- 391 tions, defines a standard certificate format [X.509]. The certificate 392 format in the 1988 standard is called the version 1 (v1) format. 393 When X.500 was revised in 1993, two more fields were added, resulting 394 in the version 2 (v2) format. 396 The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993, 397 include specifications for a public key infrastructure based on X.509 398 v1 certificates [RFC 1422]. The experience gained in attempts to 399 deploy RFC 1422 made it clear that the v1 and v2 certificate formats 400 are deficient in several respects. Most importantly, more fields 401 were needed to carry information which PEM design and implementation 402 experience has proven necessary. In response to these new require- 403 ments, ISO/IEC/ITU and ANSI X9 developed the X.509 version 3 (v3) 404 certificate format. The v3 format extends the v2 format by adding 405 provision for additional extension fields. Particular extension 406 field types may be specified in standards or may be defined and 407 registered by any organization or community. In June 1996, standardi- 408 zation of the basic v3 format was completed [X.509]. 410 ISO/IEC/ITU and ANSI X9 have also developed standard extensions for 411 use in the v3 extensions field [X.509][X9.55]. These extensions can 412 convey such data as additional subject identification information, 413 key attribute information, policy information, and certification path 414 constraints. 416 However, the ISO/IEC/ITU and ANSI X9 standard extensions are very 417 broad in their applicability. In order to develop interoperable 418 implementations of X.509 v3 systems for Internet use, it is necessary 419 to specify a profile for use of the X.509 v3 extensions tailored for 420 the Internet. It is one goal of this document to specify a profile 421 for Internet WWW, electronic mail, and IPsec applications. Environ- 422 ments with additional requirements may build on this profile or may 423 replace it. 425 3.2 Certification Paths and Trust 427 A user of a security service requiring knowledge of a public key gen- 428 erally needs to obtain and validate a certificate containing the 429 required public key. If the public-key user does not already hold an 430 assured copy of the public key of the CA that signed the certificate, 431 the CA's name, and related information (such as the validity period 432 or name constraints), then it might need an additional certificate to 433 obtain that public key. In general, a chain of multiple certificates 434 may be needed, comprising a certificate of the public key owner (the 435 end entity) signed by one CA, and zero or more additional certifi- 436 cates of CAs signed by other CAs. Such chains, called certification 437 paths, are required because a public key user is only initialized 438 with a limited number of assured CA public keys. 440 There are different ways in which CAs might be configured in order 441 for public key users to be able to find certification paths. For 442 PEM, RFC 1422 defined a rigid hierarchical structure of CAs. There 443 are three types of PEM certification authority: 445 (a) Internet Policy Registration Authority (IPRA): This author- 446 ity, operated under the auspices of the Internet Society, acts as 447 the root of the PEM certification hierarchy at level 1. It issues 448 certificates only for the next level of authorities, PCAs. All 449 certification paths start with the IPRA. 451 (b) Policy Certification Authorities (PCAs): PCAs are at level 2 452 of the hierarchy, each PCA being certified by the IPRA. A PCA 453 shall establish and publish a statement of its policy with respect 454 to certifying users or subordinate certification authorities. 455 Distinct PCAs aim to satisfy different user needs. For example, 456 one PCA (an organizational PCA) might support the general elec- 457 tronic mail needs of commercial organizations, and another PCA (a 458 high-assurance PCA) might have a more stringent policy designed 459 for satisfying legally binding digital signature requirements. 461 (c) Certification Authorities (CAs): CAs are at level 3 of the 462 hierarchy and can also be at lower levels. Those at level 3 are 463 certified by PCAs. CAs represent, for example, particular organi- 464 zations, particular organizational units (e.g., departments, 465 groups, sections), or particular geographical areas. 467 RFC 1422 furthermore has a name subordination rule which requires 468 that a CA can only issue certificates for entities whose names are 469 subordinate (in the X.500 naming tree) to the name of the CA itself. 470 The trust associated with a PEM certification path is implied by the 471 PCA name. The name subordination rule ensures that CAs below the PCA 472 are sensibly constrained as to the set of subordinate entities they 473 can certify (e.g., a CA for an organization can only certify entities 474 in that organization's name tree). Certificate user systems are able 475 to mechanically check that the name subordination rule has been fol- 476 lowed. 478 The RFC 1422 uses the X.509 v1 certificate formats. The limitations 479 of X.509 v1 required imposition of several structural restrictions to 480 clearly associate policy information or restrict the utility of cer- 481 tificates. These restrictions included: 483 (a) a pure top-down hierarchy, with all certification paths start- 484 ing from IPRA; 486 (b) a naming subordination rule restricting the names of a CA's 487 subjects; and 489 (c) use of the PCA concept, which requires knowledge of individual 490 PCAs to be built into certificate chain verification logic. 491 Knowledge of individual PCAs was required to determine if a chain 492 could be accepted. 494 With X.509 v3, most of the requirements addressed by RFC 1422 can be 495 addressed using certificate extensions, without a need to restrict 496 the CA structures used. In particular, the certificate extensions 497 relating to certificate policies obviate the need for PCAs and the 498 constraint extensions obviate the need for the name subordination 499 rule. As a result, this document supports a more flexible architec- 500 ture, including: 502 (a) Certification paths may start with a public key of a CA in a 503 user's own domain, or with the public key of the top of a hierar- 504 chy. Starting with the public key of a CA in a user's own domain 505 has certain advantages. In some environments, the local domain is 506 the most trusted. 508 (b) Name constraints may be imposed through explicit inclusion of 509 a name constraints extension in a certificate, but are not 510 required. 512 (c) Policy extensions and policy mappings replace the PCA con- 513 cept, which permits a greater degree of automation. The applica- 514 tion can determine if the certification path is acceptable based 515 on the contents of the certificates instead of a priori knowledge 516 of PCAs. This permits automation of certificate chain processing. 518 3.3 Revocation 520 When a certificate is issued, it is expected to be in use for its 521 entire validity period. However, various circumstances may cause a 522 certificate to become invalid prior to the expiration of the validity 523 period. Such circumstances include change of name, change of associa- 524 tion between subject and CA (e.g., an employee terminates employment 525 with an organization), and compromise or suspected compromise of the 526 corresponding private key. Under such circumstances, the CA needs to 527 revoke the certificate. 529 X.509 defines one method of certificate revocation. This method 530 involves each CA periodically issuing a signed data structure called 531 a certificate revocation list (CRL). A CRL is a time stamped list 532 identifying revoked certificates which is signed by a CA and made 533 freely available in a public repository. Each revoked certificate is 534 identified in a CRL by its certificate serial number. When a 535 certificate-using system uses a certificate (e.g., for verifying a 536 remote user's digital signature), that system not only checks the 537 certificate signature and validity but also acquires a suitably- 538 recent CRL and checks that the certificate serial number is not on 539 that CRL. The meaning of "suitably-recent" may vary with local pol- 540 icy, but it usually means the most recently-issued CRL. A CA issues 541 a new CRL on a regular periodic basis (e.g., hourly, daily, or 542 weekly). An entry is added to the CRL as part of the next update 543 following notification of revocation. An entry may be removed from 544 the CRL after appearing on one regularly scheduled CRL issued beyond 545 the revoked certificate's validity period. 547 An advantage of this revocation method is that CRLs may be distri- 548 buted by exactly the same means as certificates themselves, namely, 549 via untrusted communications and server systems. 551 One limitation of the CRL revocation method, using untrusted communi- 552 cations and servers, is that the time granularity of revocation is 553 limited to the CRL issue period. For example, if a revocation is 554 reported now, that revocation will not be reliably notified to 555 certificate-using systems until the next periodic CRL is issued -- 556 this may be up to one hour, one day, or one week depending on the 557 frequency that the CA issues CRLs. 559 As with the X.509 v3 certificate format, in order to facilitate 560 interoperable implementations from multiple vendors, the X.509 v2 CRL 561 format needs to be profiled for Internet use. It is one goal of this 562 document to specify that profile. However, this profile does not 563 require CAs to issue CRLs. Message formats and protocols supporting 564 on-line revocation notification may be defined in other PKIX specifi- 565 cations. On-line methods of revocation notification may be applica- 566 ble in some environments as an alternative to the X.509 CRL. On-line 567 revocation checking may significantly reduce the latency between a 568 revocation report and the distribution of the information to relying 569 parties. Once the CA accepts the report as authentic and valid, any 570 query to the on-line service will correctly reflect the certificate 571 validation impacts of the revocation. However, these methods impose 572 new security requirements: the certificate validator needs to trust 573 the on-line validation service while the repository does not need to 574 be trusted. 576 3.4 Operational Protocols 578 Operational protocols are required to deliver certificates and CRLs 579 (or status information) to certificate using client systems. Provi- 580 sion is needed for a variety of different means of certificate and 581 CRL delivery, including distribution procedures based on LDAP, HTTP, 582 FTP, and X.500. Operational protocols supporting these functions are 583 defined in other PKIX specifications. These specifications may 584 include definitions of message formats and procedures for supporting 585 all of the above operational environments, including definitions of 586 or references to appropriate MIME content types. 588 3.5 Management Protocols 590 Management protocols are required to support on-line interactions 591 between PKI user and management entities. For example, a management 592 protocol might be used between a CA and a client system with which a 593 key pair is associated, or between two CAs which cross-certify each 594 other. The set of functions which potentially need to be supported 595 by management protocols include: 597 (a) registration: This is the process whereby a user first makes 598 itself known to a CA (directly, or through an RA), prior to that 599 CA issuing a certificate or certificates for that user. 601 (b) initialization: Before a client system can operate securely 602 it is necessary to install key materials which have the appropri- 603 ate relationship with keys stored elsewhere in the infrastructure. 604 For example, the client needs to be securely initialized with the 605 public key and other assured information of the trusted CA(s), to 606 be used in validating certificate paths. Furthermore, a client 607 typically needs to be initialized with its own key pair(s). 609 (c) certification: This is the process in which a CA issues a 610 certificate for a user's public key, and returns that certificate 611 to the user's client system and/or posts that certificate in a 612 repository. 614 (d) key pair recovery: As an option, user client key materials 615 (e.g., a user's private key used for encryption purposes) may be 616 backed up by a CA or a key backup system. If a user needs to 617 recover these backed up key materials (e.g., as a result of a for- 618 gotten password or a lost key chain file), an on-line protocol 619 exchange may be needed to support such recovery. 621 (e) key pair update: All key pairs need to be updated regularly, 622 i.e., replaced with a new key pair, and new certificates issued. 624 (f) revocation request: An authorized person advises a CA of an 625 abnormal situation requiring certificate revocation. 627 (g) cross-certification: Two CAs exchange information used in 628 establishing a cross-certificate. A cross-certificate is a certi- 629 ficate issued by one CA to another CA which contains a CA signa- 630 ture key used for issuing certificates. 632 Note that on-line protocols are not the only way of implementing the 633 above functions. For all functions there are off-line methods of 634 achieving the same result, and this specification does not mandate 635 use of on-line protocols. For example, when hardware tokens are 636 used, many of the functions may be achieved as part of the physical 637 token delivery. Furthermore, some of the above functions may be com- 638 bined into one protocol exchange. In particular, two or more of the 639 registration, initialization, and certification functions can be com- 640 bined into one protocol exchange. 642 The PKIX series of specifications may define a set of standard mes- 643 sage formats supporting the above functions in future specifications. 644 In that case, the protocols for conveying these messages in different 645 environments (e.g., on-line, file transfer, e-mail, and WWW) will 646 also be described in those specifications. 648 4 Certificate and Certificate Extensions Profile 650 This section presents a profile for public key certificates that will 651 foster interoperability and a reusable PKI. This section is based 652 upon the X.509 v3 certificate format and the standard certificate 653 extensions defined in [X.509]. The ISO/IEC/ITU documents use the 654 1993 version of ASN.1; while this document uses the 1988 ASN.1 syn- 655 tax, the encoded certificate and standard extensions are equivalent. 656 This section also defines private extensions required to support a 657 PKI for the Internet community. 659 Certificates may be used in a wide range of applications and environ- 660 ments covering a broad spectrum of interoperability goals and a 661 broader spectrum of operational and assurance requirements. The goal 662 of this document is to establish a common baseline for generic appli- 663 cations requiring broad interoperability and limited special purpose 664 requirements. In particular, the emphasis will be on supporting the 665 use of X.509 v3 certificates for informal Internet electronic mail, 666 IPsec, and WWW applications. 668 4.1 Basic Certificate Fields 670 The X.509 v3 certificate basic syntax is as follows. For signature 671 calculation, the certificate is encoded using the ASN.1 distinguished 672 encoding rules (DER) [X.208]. ASN.1 DER encoding is a tag, length, 673 value encoding system for each element. 675 Certificate ::= SEQUENCE { 676 tbsCertificate TBSCertificate, 677 signatureAlgorithm AlgorithmIdentifier, 678 signatureValue BIT STRING } 680 TBSCertificate ::= SEQUENCE { 681 version [0] EXPLICIT Version DEFAULT v1, 682 serialNumber CertificateSerialNumber, 683 signature AlgorithmIdentifier, 684 issuer Name, 685 validity Validity, 686 subject Name, 687 subjectPublicKeyInfo SubjectPublicKeyInfo, 688 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 689 -- If present, version shall be v2 or v3 690 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 691 -- If present, version shall be v2 or v3 692 extensions [3] EXPLICIT Extensions OPTIONAL 693 -- If present, version shall be v3 694 } 696 Version ::= INTEGER { v1(0), v2(1), v3(2) } 698 CertificateSerialNumber ::= INTEGER 700 Validity ::= SEQUENCE { 701 notBefore Time, 702 notAfter Time } 704 Time ::= CHOICE { 705 utcTime UTCTime, 706 generalTime GeneralizedTime } 708 UniqueIdentifier ::= BIT STRING 710 SubjectPublicKeyInfo ::= SEQUENCE { 711 algorithm AlgorithmIdentifier, 712 subjectPublicKey BIT STRING } 714 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 716 Extension ::= SEQUENCE { 717 extnID OBJECT IDENTIFIER, 718 critical BOOLEAN DEFAULT FALSE, 719 extnValue OCTET STRING } 721 The following items describe the X.509 v3 certificate for use in the 722 Internet. 724 4.1.1 Certificate Fields 726 The Certificate is a SEQUENCE of three required fields. The fields 727 are described in detail in the following subsections. 729 4.1.1.1 tbsCertificate 731 The field contains the names of the subject and issuer, a public key 732 associated with the subject, a validity period, and other associated 733 information. The fields are described in detail in section 4.1.2; 734 the tbscertificate may also include extensions which are described in 735 section 4.2. 737 4.1.1.2 signatureAlgorithm 739 The signatureAlgorithm field contains the identifier for the crypto- 740 graphic algorithm used by the CA to sign this certificate. [PKIX 741 ALGS] lists the supported signature algorithms. 743 An algorithm identifier is defined by the following ASN.1 structure: 745 AlgorithmIdentifier ::= SEQUENCE { 746 algorithm OBJECT IDENTIFIER, 747 parameters ANY DEFINED BY algorithm OPTIONAL } 749 The algorithm identifier is used to identify a cryptographic algo- 750 rithm. The OBJECT IDENTIFIER component identifies the algorithm 751 (such as DSA with SHA-1). The contents of the optional parameters 752 field will vary according to the algorithm identified. [PKIX ALGS] 753 lists the supported algorithms for this specification. 755 This field MUST contain the same algorithm identifier as the 756 signature field in the sequence tbsCertificate (see sec. 4.1.2.3). 758 4.1.1.3 signatureValue 760 The signatureValue field contains a digital signature computed upon 761 the ASN.1 DER encoded tbsCertificate. The ASN.1 DER encoded tbsCer- 762 tificate is used as the input to the signature function. This signa- 763 ture value is then ASN.1 encoded as a BIT STRING and included in the 764 Certificate's signature field. The details of this process are speci- 765 fied for each of the supported algorithms in [PKIX ALGS]. 767 By generating this signature, a CA certifies the validity of the 768 information in the tbsCertificate field. In particular, the CA cer- 769 tifies the binding between the public key material and the subject of 770 the certificate. 772 4.1.2 TBSCertificate 774 The sequence TBSCertificate contains information associated with the 775 subject of the certificate and the CA who issued it. Every TBSCerti- 776 ficate contains the names of the subject and issuer, a public key 777 associated with the subject, a validity period, a version number, and 778 a serial number; some may contain optional unique identifier fields. 779 The remainder of this section describes the syntax and semantics of 780 these fields. A TBSCertificate may also include extensions. Exten- 781 sions for the Internet PKI are described in Section 4.2. 783 4.1.2.1 Version 785 This field describes the version of the encoded certificate. When 786 extensions are used, as expected in this profile, use X.509 version 3 787 (value is 2). If no extensions are present, but a UniqueIdentifier 788 is present, use version 2 (value is 1). If only basic fields are 789 present, use version 1 (the value is omitted from the certificate as 790 the default value). 792 Implementations SHOULD be prepared to accept any version certificate. 793 At a minimum, conforming implementations MUST recognize version 3 794 certificates. 796 Generation of version 2 certificates is not expected by implementa- 797 tions based on this profile. 799 4.1.2.2 Serial number 801 The serial number is a positive integer assigned by the CA to each 802 certificate. It MUST be unique for each certificate issued by a 803 given CA (i.e., the issuer name and serial number identify a unique 804 certificate). 806 4.1.2.3 Signature 808 This field contains the algorithm identifier for the algorithm used 809 by the CA to sign the certificate. 811 This field MUST contain the same algorithm identifier as the signa- 812 tureAlgorithm field in the sequence Certificate (see sec. 4.1.1.2). 813 The contents of the optional parameters field will vary according to 814 the algorithm identified. [PKIX ALGS] lists the supported signature 815 algorithms. 817 4.1.2.4 Issuer 819 The issuer field identifies the entity who has signed and issued the 820 certificate. The issuer field MUST contain a non-empty distinguished 821 name (DN). The issuer field is defined as the X.501 type Name. 822 [X.501] Name is defined by the following ASN.1 structures: 824 Name ::= CHOICE { 825 RDNSequence } 827 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 829 RelativeDistinguishedName ::= 830 SET OF AttributeTypeAndValue 832 AttributeTypeAndValue ::= SEQUENCE { 833 type AttributeType, 834 value AttributeValue } 836 AttributeType ::= OBJECT IDENTIFIER 838 AttributeValue ::= ANY DEFINED BY AttributeType 840 DirectoryString ::= CHOICE { 841 teletexString TeletexString (SIZE (1..MAX)), 842 printableString PrintableString (SIZE (1..MAX)), 843 universalString UniversalString (SIZE (1..MAX)), 844 utf8String UTF8String (SIZE (1.. MAX)), 845 bmpString BMPString (SIZE (1..MAX)) } 847 The Name describes a hierarchical name composed of attributes, such 848 as country name, and corresponding values, such as US. The type of 849 the component AttributeValue is determined by the AttributeType; in 850 general it will be a DirectoryString. 852 The DirectoryString type is defined as a choice of PrintableString, 853 TeletexString, BMPString, UTF8String, and UniversalString. The 854 UTF8String encoding is the preferred encoding, and all certificates 855 issued after December 31, 2003 MUST use the UTF8String encoding of 856 DirectoryString (except as noted below). Until that date, conforming 857 CAs MUST choose from the following options when creating a dis- 858 tinguished name, including their own: 860 (a) if the character set is sufficient, the string MAY be 861 represented as a PrintableString; 863 (b) failing (a), if the BMPString character set is sufficient the 864 string MAY be represented as a BMPString; and 866 (c) failing (a) and (b), the string MUST be represented as a 867 UTF8String. If (a) or (b) is satisfied, the CA MAY still choose 868 to represent the string as a UTF8String. 870 Exceptions to the December 31, 2003 UTF8 encoding requirements are as 871 follows: 873 (a) CAs MAY issue "name rollover" certificates to support an ord- 874 erly migration to UTF8String encoding. Such certificates would 875 include the CA's UTF8String encoded name as issuer and and the old 876 name encoding as subject, or vice-versa. 878 (b) As stated in section 4.1.2.6, the subject field MUST be popu- 879 lated with a non-empty distinguished name matching the contents of 880 the issuer field in all certificates issued by the subject CA 881 regardless of encoding. 883 The TeletexString and UniversalString are included for backward com- 884 patibility, and should not be used for certificates for new subjects. 885 However, these types may be used in certificates where the name was 886 previously established. Certificate users SHOULD be prepared to 887 receive certificates with these types. 889 In addition, many legacy implementations support names encoded in the 890 ISO 8859-1 character set (Latin1String) but tag them as Teletex- 891 String. The Latin1String includes characters used in Western Euro- 892 pean countries which are not part of the TeletexString charcter set. 893 Implementations that process TeletexString SHOULD be prepared to han- 894 dle the entire ISO 8859-1 character set.[ISO 8859-1] 896 As noted above, distinguished names are composed of attributes. This 897 specification does not restrict the set of attribute types that may 898 appear in names. However, conforming implementations MUST be 899 prepared to receive certificates with issuer names containing the set 900 of attribute types defined below. This specification also recommends 901 support for additional attribute types. 903 Standard sets of attributes have been defined in the X.500 series of 904 specifications.[X.520] Implementations of this specification MUST be 905 prepared to receive the following standard attribute types in issuer 906 and subject (see 4.1.2.6) names: 908 * country, 909 * organization, 910 * organizational-unit, 911 * distinguished name qualifier, 912 * state or province name, 913 * common name (e.g., "Susan Housley"), and 914 * serial number. 916 In addition, implementations of this specification SHOULD be prepared 917 to receive the following standard attribute types in issuer and sub- 918 ject names: 920 * locality, 921 * title, 922 * surname, 923 * given name, 924 * initials, and 925 * generation qualifier (e.g., "Jr.", "3rd", or "IV"). 927 The syntax and associated object identifiers (OIDs) for these attri- 928 bute types are provided in the ASN.1 modules in Appendices A and B. 930 In addition, implementations of this specification MUST be prepared 931 to receive the domainComponent attribute, as defined in [RFC 2247]. 932 The Domain (Nameserver) System (DNS) provides a hierarchical resource 933 labeling system. This attribute provides is a convenient mechanism 934 for organizations that wish to use DNs that parallel their DNS names. 935 This is not a replacement for the dNSName component of the alterna- 936 tive name field. Implementations are not required to convert such 937 names into DNS names. The syntax and associated OID for this attri- 938 bute type is provided in the ASN.1 modules in Appendices A and B. 940 Certificate users MUST be prepared to process the issuer dis- 941 tinguished name and subject distinguished name (see sec. 4.1.2.6) 942 fields to perform name chaining for certification path validation 943 (see section 6). Name chaining is performed by matching the issuer 944 distinguished name in one certificate with the subject name in a CA 945 certificate. 947 This specification requires only a subset of the name comparison 948 functionality specified in the X.500 series of specifications. The 949 requirements for conforming implementations are as follows: 951 (a) attribute values encoded in different types (e.g., Printable- 952 String and BMPString) may be assumed to represent different 953 strings; 955 (b) attribute values in types other than PrintableString are case 956 sensitive (this permits matching of attribute values as binary 957 objects); 959 (c) attribute values in PrintableString are not case sensitive 960 (e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and 962 (d) attribute values in PrintableString are compared after remov- 963 ing leading and trailing white space and converting internal sub- 964 strings of one or more consecutive white space characters to a 965 single space. 967 These name comparison rules permit a certificate user to validate 968 certificates issued using languages or encodings unfamiliar to the 969 certificate user. 971 In addition, implementations of this specification MAY use these com- 972 parison rules to process unfamiliar attribute types for name chain- 973 ing. This allows implementations to process certificates with unfami- 974 liar attributes in the issuer name. 976 Note that the comparison rules defined in the X.500 series of specif- 977 ications indicate that the character sets used to encode data in dis- 978 tinguished names are irrelevant. The characters themselves are com- 979 pared without regard to encoding. Implementations of the profile are 980 permitted to use the comparison algorithm defined in the X.500 981 series. Such an implementation will recognize a superset of name 982 matches recognized by the algorithm specified above. 984 4.1.2.5 Validity 986 The certificate validity period is the time interval during which the 987 CA warrants that it will maintain information about the status of the 988 certificate. The field is represented as a SEQUENCE of two dates: 989 the date on which the certificate validity period begins (notBefore) 990 and the date on which the certificate validity period ends 991 (notAfter). Both notBefore and notAfter may be encoded as UTCTime or 992 GeneralizedTime. 994 CAs conforming to this profile MUST always encode certificate vali- 995 dity dates through the year 2049 as UTCTime; certificate validity 996 dates in 2050 or later MUST be encoded as GeneralizedTime. 998 The validity period for a certificate is the period of time from 999 notBefore through notAfter, inclusive. 1001 4.1.2.5.1 UTCTime 1003 The universal time type, UTCTime, is a standard ASN.1 type intended 1004 for representation of dates and time. UTCTime specifies the year 1005 through the two low order digits and time is specified to the preci- 1006 sion of one minute or one second. UTCTime includes either Z (for 1007 Zulu, or Greenwich Mean Time) or a time differential. 1009 For the purposes of this profile, UTCTime values MUST be expressed 1010 Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are 1011 YYMMDDHHMMSSZ), even where the number of seconds is zero. Conforming 1012 systems MUST interpret the year field (YY) as follows: 1014 Where YY is greater than or equal to 50, the year shall be inter- 1015 preted as 19YY; and 1017 Where YY is less than 50, the year shall be interpreted as 20YY. 1019 4.1.2.5.2 GeneralizedTime 1021 The generalized time type, GeneralizedTime, is a standard ASN.1 type 1022 for variable precision representation of time. Optionally, the Gen- 1023 eralizedTime field can include a representation of the time differen- 1024 tial between local and Greenwich Mean Time. 1026 For the purposes of this profile, GeneralizedTime values MUST be 1027 expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e., 1028 times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. 1029 GeneralizedTime values MUST NOT include fractional seconds. 1031 4.1.2.6 Subject 1033 The subject field identifies the entity associated with the public 1034 key stored in the subject public key field. The subject name may be 1035 carried in the subject field and/or the subjectAltName extension. If 1036 the subject is a CA (e.g., the basic constraints extension, as dis- 1037 cussed in 4.2.1.10, is present and the value of cA is TRUE,) then the 1038 subject field MUST be populated with a non-empty distinguished name 1039 matching the contents of the issuer field (see sec. 4.1.2.4) in all 1040 certificates issued by the subject CA. If subject naming information 1041 is present only in the subjectAltName extension (e.g., a key bound 1042 only to an email address or URI), then the subject name MUST be an 1043 empty sequence and the subjectAltName extension MUST be critical. 1045 Where it is non-empty, the subject field MUST contain an X.500 dis- 1046 tinguished name (DN). The DN MUST be unique for each subject entity 1047 certified by the one CA as defined by the issuer name field. A CA may 1048 issue more than one certificate with the same DN to the same subject 1049 entity. 1051 The subject name field is defined as the X.501 type Name. Implemen- 1052 tation requirements for this field are those defined for the issuer 1053 field (see sec. 4.1.2.4). When encoding attribute values of type 1054 DirectoryString, the encoding rules for the issuer field MUST be 1055 implemented. Implementations of this specification MUST be prepared 1056 to receive subject names containing the attribute types required for 1057 the issuer field. Implementations of this specification SHOULD be 1058 prepared to receive subject names containing the recommended attri- 1059 bute types for the issuer field. The syntax and associated object 1060 identifiers (OIDs) for these attribute types are provided in the 1061 ASN.1 modules in Appendices A and B. Implementations of this specif- 1062 ication MAY use these comparison rules to process unfamiliar attri- 1063 bute types (i.e., for name chaining). This allows implementations to 1064 process certificates with unfamiliar attributes in the subject name. 1066 In addition, legacy implementations exist where an RFC 822 name is 1067 embedded in the subject distinguished name as an EmailAddress attri- 1068 bute. The attribute value for EmailAddress is of type IA5String to 1069 permit inclusion of the character '@', which is not part of the 1070 PrintableString character set. EmailAddress attribute values are not 1071 case sensitive (e.g., "fanfeedback@redsox.com" is the same as 1072 "FANFEEDBACK@REDSOX.COM"). 1074 Conforming implementations generating new certificates with elec- 1075 tronic mail addresses MUST use the rfc822Name in the subject alterna- 1076 tive name field (see sec. 4.2.1.7) to describe such identities. 1077 Simultaneous inclusion of the EmailAddress attribute in the subject 1078 distinguished name to support legacy implementations is deprecated 1079 but permitted. 1081 4.1.2.7 Subject Public Key Info 1083 This field is used to carry the public key and identify the algorithm 1084 with which the key is used. The algorithm is identified using the 1085 AlgorithmIdentifier structure specified in section 4.1.1.2. The 1086 object identifiers for the supported algorithms and the methods for 1087 encoding the public key materials (public key and parameters) are 1088 specified in [PKIX ALGS]. 1090 4.1.2.8 Unique Identifiers 1092 These fields may only appear if the version is 2 or 3 (see sec. 1093 4.1.2.1). The subject and issuer unique identifiers are present in 1094 the certificate to handle the possibility of reuse of subject and/or 1095 issuer names over time. This profile recommends that names not be 1096 reused for different entities and that Internet certificates not make 1097 use of unique identifiers. CAs conforming to this profile SHOULD NOT 1098 generate certificates with unique identifiers. Applications conform- 1099 ing to this profile SHOULD be capable of parsing unique identifiers 1100 and making comparisons. 1102 4.1.2.9 Extensions 1104 This field may only appear if the version is 3 (see sec. 4.1.2.1). 1105 If present, this field is a SEQUENCE of one or more certificate 1106 extensions. The format and content of certificate extensions in the 1107 Internet PKI is defined in section 4.2. 1109 4.2 Standard Certificate Extensions 1111 The extensions defined for X.509 v3 certificates provide methods for 1112 associating additional attributes with users or public keys and for 1113 managing the certification hierarchy. The X.509 v3 certificate for- 1114 mat also allows communities to define private extensions to carry 1115 information unique to those communities. Each extension in a certi- 1116 ficate may be designated as critical or non-critical. A certificate 1117 using system MUST reject the certificate if it encounters a critical 1118 extension it does not recognize; however, a non-critical extension 1119 may be ignored if it is not recognized. The following sections 1120 present recommended extensions used within Internet certificates and 1121 standard locations for information. Communities may elect to use 1122 additional extensions; however, caution should be exercised in adopt- 1123 ing any critical extensions in certificates which might prevent use 1124 in a general context. 1126 Each extension includes an OID and an ASN.1 structure. When an 1127 extension appears in a certificate, the OID appears as the field 1128 extnID and the corresponding ASN.1 encoded structure is the value of 1129 the octet string extnValue. Only one instance of a particular exten- 1130 sion may appear in a particular certificate. For example, a certifi- 1131 cate may contain only one authority key identifier extension (see 1132 sec. 4.2.1.1). An extension includes the boolean critical, with a 1133 default value of FALSE. The text for each extension specifies the 1134 acceptable values for the critical field. 1136 Conforming CAs MUST support key identifiers (see sec. 4.2.1.1 and 1137 4.2.1.2), basic constraints (see sec. 4.2.1.10), key usage (see sec. 1139 4.2.1.3), and certificate policies (see sec. 4.2.1.5) extensions. If 1140 the CA issues certificates with an empty sequence for the subject 1141 field, the CA MUST support the subject alternative name extension 1142 (see sec. 4.2.1.7). Support for the remaining extensions is 1143 OPTIONAL. Conforming CAs may support extensions that are not identi- 1144 fied within this specification; certificate issuers are cautioned 1145 that marking such extensions as critical may inhibit interoperabil- 1146 ity. 1148 At a minimum, applications conforming to this profile MUST recognize 1149 the following extensions: key usage (see sec. 4.2.1.3), certificate 1150 policies (see sec. 4.2.1.5), the subject alternative name (see sec. 1151 4.2.1.7), basic constraints (see sec. 4.2.1.10), name constraints 1152 (see sec. 4.2.1.11), policy constraints (see sec. 4.2.1.12), and 1153 extended key usage (see sec. 4.2.1.13). 1155 In addition, this profile RECOMMENDS application support for the 1156 authority and subject key identifier (see sec. 4.2.1.1 and 4.2.1.2), 1157 and inhibit any-policy (see sec. 4.2.1.15) extensions. 1159 4.2.1 Standard Extensions 1161 This section identifies standard certificate extensions defined in 1162 [X.509] for use in the Internet PKI. Each extension is associated 1163 with an OID defined in [X.509]. These OIDs are members of the id-ce 1164 arc, which is defined by the following: 1166 id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 1168 4.2.1.1 Authority Key Identifier 1170 The authority key identifier extension provides a means of identify- 1171 ing the public key corresponding to the private key used to sign a 1172 certificate. This extension is used where an issuer has multiple 1173 signing keys (either due to multiple concurrent key pairs or due to 1174 changeover). The identification may be based on either the key iden- 1175 tifier (the subject key identifier in the issuer's certificate) or on 1176 the issuer name and serial number. 1178 The keyIdentifier field of the authorityKeyIdentifier extension MUST 1179 be included in all certificates generated by conforming CAs to facil- 1180 itate chain building. There is one exception; where a CA distributes 1181 its public key in the form of a "self-signed" certificate, the 1182 authority key identifier may be omitted. In this case, the subject 1183 and authority key identifiers would be identical. 1185 The value of the keyIdentifier field SHOULD be derived from the pub- 1186 lic key used to verify the certificate's signature or a method that 1187 generates unique values. Two common methods for generating key iden- 1188 tifiers from the public key are described in (sec. 4.2.1.2). One com- 1189 mon method for generating unique values is described in (sec. 1190 4.2.1.2). Where a key identifier has not been previously esta- 1191 blished, this specification recommends use of one of these methods 1192 for generating keyIdentifiers. 1194 This profile recommends support for the key identifier method by all 1195 certificate users. 1197 This extension MUST NOT be marked critical. 1199 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 1201 AuthorityKeyIdentifier ::= SEQUENCE { 1202 keyIdentifier [0] KeyIdentifier OPTIONAL, 1203 authorityCertIssuer [1] GeneralNames OPTIONAL, 1204 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 1206 KeyIdentifier ::= OCTET STRING 1208 4.2.1.2 Subject Key Identifier 1210 The subject key identifier extension provides a means of identifying 1211 certificates that contain a particular public key. 1213 To facilitate chain building, this extension MUST appear in all con- 1214 forming CA certificates, that is, all certificates including the 1215 basic constraints extension (see sec. 4.2.1.10) where the value of cA 1216 is TRUE. The value of the subject key identifier MUST be the value 1217 placed in the key identifier field of the Authority Key Identifier 1218 extension (see sec. 4.2.1.1) of certificates issued by the subject of 1219 this certificate. 1221 For CA certificates, subject key identifiers SHOULD be derived from 1222 the public key or a method that generates unique values. Two common 1223 methods for generating key identifiers from the public key are: 1225 (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the 1226 value of the BIT STRING subjectPublicKey (excluding the tag, 1227 length, and number of unused bits). 1229 (2) The keyIdentifier is composed of a four bit type field with 1230 the value 0100 followed by the least significant 60 bits of the 1231 SHA-1 hash of the value of the BIT STRING subjectPublicKey. 1233 One common method for generating unique values is a monotomically 1234 increasing sequence of integers. 1236 For end entity certificates, the subject key identifier extension 1237 provides a means for identifying certificates containing the particu- 1238 lar public key used in an application. Where an end entity has 1239 obtained multiple certificates, especially from multiple CAs, the 1240 subject key identifier provides a means to quickly identify the set 1241 of certificates containing a particular public key. To assist appli- 1242 cations in identificiation the appropriate end entity certificate, 1243 this extension SHOULD be included in all end entity certificates. 1245 For end entity certificates, subject key identifiers SHOULD be 1246 derived from the public key. Two common methods for generating key 1247 identifiers from the public key are identifed above. 1249 Where a key identifier has not been previously established, this 1250 specification recommends use of one of these methods for generating 1251 keyIdentifiers. 1253 This extension MUST NOT be marked critical. 1255 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 1257 SubjectKeyIdentifier ::= KeyIdentifier 1259 4.2.1.3 Key Usage 1261 The key usage extension defines the purpose (e.g., encipherment, sig- 1262 nature, certificate signing) of the key contained in the certificate. 1263 The usage restriction might be employed when a key that could be used 1264 for more than one operation is to be restricted. For example, when 1265 an RSA key should be used only for signing, the digitalSignature 1266 and/or nonRepudiation bits would be asserted. Likewise, when an RSA 1267 key should be used only for key management, the keyEncipherment bit 1268 would be asserted. When used, this extension SHOULD be marked criti- 1269 cal. 1271 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 1273 KeyUsage ::= BIT STRING { 1274 digitalSignature (0), 1275 nonRepudiation (1), 1276 keyEncipherment (2), 1277 dataEncipherment (3), 1278 keyAgreement (4), 1279 keyCertSign (5), 1280 cRLSign (6), 1281 encipherOnly (7), 1282 decipherOnly (8) } 1284 Bits in the KeyUsage type are used as follows: 1286 The digitalSignature bit is asserted when the subject public key 1287 is used with a digital signature mechanism to support security 1288 services other than non-repudiation (bit 1), certificate signing 1289 (bit 5), or revocation information signing (bit 6). Digital signa- 1290 ture mechanisms are often used for entity authentication and data 1291 origin authentication with integrity. 1293 The nonRepudiation bit is asserted when the subject public key is 1294 used to verify digital signatures used to provide a non- 1295 repudiation service which protects against the signing entity 1296 falsely denying some action, excluding certificate or CRL signing. 1297 In the case of later conflict, a reliable third party may deter- 1298 mine the authenticity of the signed data. 1300 Further distinctions between the digitalSignature and nonRepudia- 1301 tion bits may be provided in specific certificate policies. 1303 The keyEncipherment bit is asserted when the subject public key is 1304 used for key transport. For example, when an RSA key is to be 1305 used for key management, then this bit shall asserted. 1307 The dataEncipherment bit is asserted when the subject public key 1308 is used for enciphering user data, other than cryptographic keys. 1310 The keyAgreement bit is asserted when the subject public key is 1311 used for key agreement. For example, when a Diffie-Hellman key is 1312 to be used for key management, then this bit shall asserted. 1314 The keyCertSign bit is asserted when the subject public key is 1315 used for verifying a signature on certificates. This bit may only 1316 be asserted in CA certificates. If the keyCertSign bit is 1317 asserted, then the cA bit in the basic constraints extension (see 1318 4.2.1.10) MUST also be asserted. If the keyCertSign bit is not 1319 asserted, then the cA bit in the basic constraints extension MUST 1320 NOT be asserted. 1322 The cRLSign bit is asserted when the subject public key is used 1323 for verifying a signature on revocation information (e.g., a CRL). 1325 The meaning of the encipherOnly bit is undefined in the absence of 1326 the keyAgreement bit. When the encipherOnly bit is asserted and 1327 the keyAgreement bit is also set, the subject public key may be 1328 used only for enciphering data while performing key agreement. 1330 The meaning of the decipherOnly bit is undefined in the absence of 1331 the keyAgreement bit. When the decipherOnly bit is asserted and 1332 the keyAgreement bit is also set, the subject public key may be 1333 used only for deciphering data while performing key agreement. 1335 This profile does not restrict the combinations of bits that may be 1336 set in an instantiation of the keyUsage extension. However, 1337 appropriate values for keyUsage extensions for particular algorithms 1338 are specified in [PKIX ALGS]. 1340 4.2.1.4 Private Key Usage Period 1342 This profile recommends against the use of this extension. CAs con- 1343 forming to this profile MUST NOT generate certificates with critical 1344 private key usage period extensions. 1346 The private key usage period extension allows the certificate issuer 1347 to specify a different validity period for the private key than the 1348 certificate. This extension is intended for use with digital signa- 1349 ture keys. This extension consists of two optional components, 1350 notBefore and notAfter. The private key associated with the certifi- 1351 cate should not be used to sign objects before or after the times 1352 specified by the two components, respectively. CAs conforming to this 1353 profile MUST NOT generate certificates with private key usage period 1354 extensions unless at least one of the two components is present. 1356 Where used, notBefore and notAfter are represented as GeneralizedTime 1357 and MUST be specified and interpreted as defined in section 1358 4.1.2.5.2. 1360 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 1362 PrivateKeyUsagePeriod ::= SEQUENCE { 1363 notBefore [0] GeneralizedTime OPTIONAL, 1364 notAfter [1] GeneralizedTime OPTIONAL } 1366 4.2.1.5 Certificate Policies 1368 The certificate policies extension contains a sequence of one or more 1369 policy information terms, each of which consists of an object iden- 1370 tifier (OID) and optional qualifiers. Optional qualifiers, which may 1371 be present, are not expected to change the definition of the policy. 1373 In an end-entity certificate, these policy information terms indicate 1374 the policy under which the certificate has been issued and the pur- 1375 poses for which the certificate may be used. In a CA certificate, 1376 these policy information terms limit the set of policies for certifi- 1377 cation paths which include this certificate. When a CA does not wish 1378 to limit the set of policies for certification paths which include 1379 this certificate, they may assert the special policy anyPolicy, with 1380 a value of {2 5 29 32 0}. 1382 Applications with specific policy requirements are expected to have a 1383 list of those policies which they will accept and to compare the pol- 1384 icy OIDs in the certificate to that list. If this extension is crit- 1385 ical, the path validation software MUST be able to interpret this 1386 extension (including the optional qualifier), or MUST reject the cer- 1387 tificate. 1389 To promote interoperability, this profile RECOMMENDS that policy 1390 information terms consist of only an OID. Where an OID alone is 1391 insufficient, this profile strongly recommends that use of qualifiers 1392 be limited to those identified in this section. When qualifiers are 1393 used with the special policy anyPolicy, they MUST be limited to the 1394 qualifers identified in this section. 1396 This specification defines two policy qualifier types for use by cer- 1397 tificate policy writers and certificate issuers. The qualifier types 1398 are the CPS Pointer and User Notice qualifiers. 1400 The CPS Pointer qualifier contains a pointer to a Certification Prac- 1401 tice Statement (CPS) published by the CA. The pointer is in the form 1402 of a URI. 1404 User notice is intended for display to a relying party when a certi- 1405 ficate is used. The application software SHOULD display all user 1406 notices in all certificates of the certification path used, except 1407 that if a notice is duplicated only one copy need be displayed. To 1408 prevent such duplication, this qualifier SHOULD only be present in 1409 end-entity certificates and CA certificates issued to other organiza- 1410 tions. 1412 The user notice has two optional fields: the noticeRef field and the 1413 explicitText field. 1415 The noticeRef field, if used, names an organization and identi- 1416 fies, by number, a particular textual statement prepared by that 1417 organization. For example, it might identify the organization 1418 "CertsRUs" and notice number 1. In a typical implementation, the 1419 application software will have a notice file containing the 1420 current set of notices for CertsRUs; the application will extract 1421 the notice text from the file and display it. Messages may be 1422 multilingual, allowing the software to select the particular 1423 language message for its own environment. 1425 An explicitText field includes the textual statement directly in 1426 the certificate. The explicitText field is a string with a max- 1427 imum size of 200 characters. 1429 If both the noticeRef and explicitText options are included in the 1430 one qualifier and if the application software can locate the notice 1431 text indicated by the noticeRef option then that text should be 1432 displayed; otherwise, the explicitText string should be displayed. 1434 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 1436 anyPolicy OBJECT IDENTIFIER ::= {id-ce-certificate-policies 0} 1438 certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 1440 PolicyInformation ::= SEQUENCE { 1441 policyIdentifier CertPolicyId, 1442 policyQualifiers SEQUENCE SIZE (1..MAX) OF 1443 PolicyQualifierInfo OPTIONAL } 1445 CertPolicyId ::= OBJECT IDENTIFIER 1447 PolicyQualifierInfo ::= SEQUENCE { 1448 policyQualifierId PolicyQualifierId, 1449 qualifier ANY DEFINED BY policyQualifierId } 1451 -- policyQualifierIds for Internet policy qualifiers 1453 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 1454 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 1455 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 1457 PolicyQualifierId ::= 1458 OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) 1460 Qualifier ::= CHOICE { 1461 cPSuri CPSuri, 1462 userNotice UserNotice } 1464 CPSuri ::= IA5String 1466 UserNotice ::= SEQUENCE { 1467 noticeRef NoticeReference OPTIONAL, 1468 explicitText DisplayText OPTIONAL} 1470 NoticeReference ::= SEQUENCE { 1471 organization DisplayText, 1472 noticeNumbers SEQUENCE OF INTEGER } 1474 DisplayText ::= CHOICE { 1475 ia5String IA5String (SIZE (1..200)), 1476 visibleString VisibleString (SIZE (1..200)), 1477 bmpString BMPString (SIZE (1..200)), 1478 utf8String UTF8String (SIZE (1..200)) } 1480 4.2.1.6 Policy Mappings 1482 This extension is used in CA certificates. It lists one or more 1483 pairs of OIDs; each pair includes an issuerDomainPolicy and a sub- 1484 jectDomainPolicy. The pairing indicates the issuing CA considers its 1485 issuerDomainPolicy equivalent to the subject CA's subjectDomainPol- 1486 icy. 1488 The issuing CA's users may accept an issuerDomainPolicy for certain 1489 applications. The policy mapping tells the issuing CA's users which 1490 policies associated with the subject CA are comparable to the policy 1491 they accept. 1493 Policies should not be mapped either to or from the special value 1494 anyPolicy. (see 4.2.1.5 certificate policies). 1496 This extension may be supported by CAs and/or applications, and it 1497 MUST be non-critical. 1499 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 1501 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 1502 issuerDomainPolicy CertPolicyId, 1503 subjectDomainPolicy CertPolicyId } 1505 4.2.1.7 Subject Alternative Name 1507 The subject alternative names extension allows additional identities 1508 to be bound to the subject of the certificate. Defined options 1509 include an Internet electronic mail address, a DNS name, an IP 1510 address, and a uniform resource identifier (URI). Other options 1511 exist, including completely local definitions. Multiple name forms, 1512 and multiple instances of each name form, may be included. Whenever 1513 such identities are to be bound into a certificate, the subject 1514 alternative name (or issuer alternative name) extension MUST be used. 1516 Because the subject alternative name is considered to be definitively 1517 bound to the public key, all parts of the subject alternative name 1518 MUST be verified by the CA. 1520 Further, if the only subject identity included in the certificate is 1521 an alternative name form (e.g., an electronic mail address), then the 1522 subject distinguished name MUST be empty (an empty sequence), and the 1523 subjectAltName extension MUST be present. If the subject field con- 1524 tains an empty sequence, the subjectAltName extension MUST be marked 1525 critical. 1527 When the subjectAltName extension contains an Internet mail address, 1528 the address MUST be included as an rfc822Name. The format of an 1529 rfc822Name is an "addr-spec" as defined in RFC 822 [RFC 822]. An 1530 addr-spec has the form "local-part@domain". Note that an addr-spec 1531 has no phrase (such as a common name) before it, has no comment (text 1532 surrounded in parentheses) after it, and is not surrounded by "<" and 1533 ">". Note that while upper and lower case letters are allowed in an 1534 RFC 822 addr-spec, no significance is attached to the case. 1536 When the subjectAltName extension contains a iPAddress, the address 1537 MUST be stored in the octet string in "network byte order," as speci- 1538 fied in RFC 791 [RFC 791]. The least significant bit (LSB) of each 1539 octet is the LSB of the corresponding byte in the network address. 1540 For IP Version 4, as specified in RFC 791, the octet string MUST con- 1541 tain exactly four octets. For IP Version 6, as specified in RFC 1542 1883, the octet string MUST contain exactly sixteen octets [RFC 1543 1883]. 1545 When the subjectAltName extension contains a domain name service 1546 label, the domain name MUST be stored in the dNSName (an IA5String). 1547 The name MUST be in the "preferred name syntax," as specified by RFC 1548 1034 [RFC 1034]. Note that while upper and lower case letters are 1549 allowed in domain names, no signifigance is attached to the case. In 1550 addition, while the string " " is a legal domain name, subjectAltName 1551 extensions with a dNSName " " are not permitted. Finally, the use of 1552 the DNS representation for Internet mail addresses (wpolk.nist.gov 1553 instead of wpolk@nist.gov) is not permitted; such identities are to 1554 be encoded as rfc822Name. 1556 Note: work is currently underway to specify domain names in interna- 1557 tional character sets. This names will likely not be accomodated by 1558 IA5String. Once this work is complete, this profile will be 1559 revisited and the appropriate functionality will be added. 1561 When the subjectAltName extension contains a URI, the name MUST be 1562 stored in the uniformResourceIdentifier (an IA5String). The name MUST 1563 be a non-relative URL, and MUST follow the URL syntax and encoding 1564 rules specified in [RFC 1738]. The name must include both a scheme 1565 (e.g., "http" or "ftp") and a scheme-specific-part. The scheme- 1566 specific-part must include a fully qualified domain name or IP 1567 address as the host. 1569 As specified in [RFC 1738], the scheme name is not case-sensitive 1570 (e.g., "http" is equivalent to "HTTP"). The host part is also not 1571 case-sensitive, but other components of the scheme-specific-part may 1572 be case-sensitive. When comparing URIs, conforming implementations 1573 MUST compare the scheme and host without regard to case, but assume 1574 the remainder of the scheme-specific-part is case sensitive. 1576 When the subjectAltName extension contains a DN in the directoryName, 1577 the DN MUST be unique for each subject entity certified by the one CA 1578 as defined by the issuer name field. A CA may issue more than one 1579 certificate with the same DN to the same subject entity. 1581 The subjectAltName may carry additional name types through the use of 1582 the otherName field. The format and semantics of the name are indi- 1583 cated through the OBJECT IDENTIFIER in the type-id field. The name 1584 itself is conveyed as value field in otherName. For example, Ker- 1585 beros [RFC 1510] format names can be encoded into the otherName, 1586 using the krb5PrincipalName OID and the KerberosName syntax as 1587 defined in [PKINIT]. 1589 Subject alternative names may be constrained in the same manner as 1590 subject distinguished names using the name constraints extension as 1591 described in section 4.2.1.11. 1593 If the subjectAltName extension is present, the sequence MUST contain 1594 at least one entry. Unlike the subject field, conforming CAs MUST 1595 NOT issue certificates with subjectAltNames containing empty General- 1596 Name fields. For example, an rfc822Name is represented as an 1597 IA5String. While an empty string is a valid IA5String, such an 1598 rfc822Name is not permitted by this profile. The behavior of clients 1599 that encounter such a certificate when processing a certificication 1600 path is not defined by this profile. 1602 Finally, the semantics of subject alternative names that include 1603 wildcard characters (e.g., as a placeholder for a set of names) are 1604 not addressed by this specification. Applications with specific 1605 requirements may use such names but shall define the semantics. 1607 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 1609 SubjectAltName ::= GeneralNames 1611 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 1613 GeneralName ::= CHOICE { 1614 otherName [0] OtherName, 1615 rfc822Name [1] IA5String, 1616 dNSName [2] IA5String, 1617 x400Address [3] ORAddress, 1618 directoryName [4] Name, 1619 ediPartyName [5] EDIPartyName, 1620 uniformResourceIdentifier [6] IA5String, 1621 iPAddress [7] OCTET STRING, 1622 registeredID [8] OBJECT IDENTIFIER} 1624 OtherName ::= SEQUENCE { 1625 type-id OBJECT IDENTIFIER, 1626 value [0] EXPLICIT ANY DEFINED BY type-id } 1628 EDIPartyName ::= SEQUENCE { 1629 nameAssigner [0] DirectoryString OPTIONAL, 1630 partyName [1] DirectoryString } 1632 4.2.1.8 Issuer Alternative Names 1634 As with 4.2.1.7, this extension is used to associate Internet style 1635 identities with the certificate issuer. Issuer alternative names MUST 1636 be encoded as in 4.2.1.7. 1638 Where present, this extension SHOULD NOT be marked critical. 1640 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 1642 IssuerAltName ::= GeneralNames 1644 4.2.1.9 Subject Directory Attributes 1646 The subject directory attributes extension is not recommended as an 1647 essential part of this profile, but it may be used in local environ- 1648 ments. This extension MUST be non-critical. 1650 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 1652 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 1654 4.2.1.10 Basic Constraints 1656 The basic constraints extension identifies whether the subject of the 1657 certificate is a CA and how deep a certification path may exist 1658 through that CA. 1660 The cA bit indicates if the certified public key may be used to ver- 1661 ify signatures on other certificates. If the cA bit is asserted, then 1662 the keyCertSign bit in the key usage extension (see 4.2.1.3) MUST 1663 also be asserted. If the cA bit is not asserted, then the keyCertSign 1664 bit in the key usage extension MUST NOT be asserted. 1666 The pathLenConstraint field is meaningful only if cA is set to TRUE. 1667 In this case, it gives the maximum number of CA certificates that may 1668 follow this certificate in a certification path. (Note: One end- 1669 entity certificate will follow the final CA certificate in the path. 1670 The last certificate in a path is considered an end-entity certifi- 1671 cate, whether the subject of the certificate is a CA or not.) A 1672 pathLenConstrinat of zero indicates that only an end-entity certifi- 1673 cate may follow in the path. Where it appears, the pathLenConstraint 1674 field MUST be greater than or equal to zero. Where pathLenConstraint 1675 does not appear, there is no limit to the allowed length of the cer- 1676 tification path. 1678 This extension MUST appear as a critical extension in all CA certifi- 1679 cates. This extension MAY appear as a critical or non-critical 1680 extension in end entity certificates. 1682 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 1684 BasicConstraints ::= SEQUENCE { 1685 cA BOOLEAN DEFAULT FALSE, 1686 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 1688 4.2.1.11 Name Constraints 1690 The name constraints extension, which MUST be used only in a CA cer- 1691 tificate, indicates a name space within which all subject names in 1692 subsequent certificates in a certification path shall be located. 1693 Restrictions may apply to the subject distinguished name or subject 1694 alternative names. Restrictions apply only when the specified name 1695 form is present. If no name of the type is in the certificate, the 1696 certificate is acceptable. 1698 Name constraints are not applied to certificates whose issuer and 1699 subject are identical. (This could prevent CAs that utilize name 1700 constraints from issuing self-signed certificates to implement key 1701 rollover.) 1703 Restrictions are defined in terms of permitted or excluded name sub- 1704 trees. Any name matching a restriction in the excludedSubtrees field 1705 is invalid regardless of information appearing in the permittedSub- 1706 trees. This extension MUST be critical. 1708 Within this profile, the minimum and maximum fields are not used with 1709 any name forms, thus minimum is always zero, and maximum is always 1710 absent. 1712 For URIs, the constraint applies to the host part of the name. The 1713 constraint may specify a host or a domain. Examples would be 1714 "foo.bar.com"; and ".xyz.com". When the the constraint begins with 1715 a period, it may be expanded with one or more subdomains. That is, 1716 the constraint ".xyz.com" is satisfied by both abc.xyz.com and 1717 abc.def.xyz.com. However, the constraint ".xyz.com" is not satisfied 1718 by "xyz.com". When the constraint does not begin with a period, it 1719 specifies a host. 1721 A name constraint for Internat mail addresses may specify a particu- 1722 lar mailbox, all addresses at a particular host, or all mailboxes in 1723 a domain. To indicate a particular mailbox, the constraint is the 1724 complete mail address. For example, "root@xyz.com" indicates the 1725 root mailbox on the host "xyz.com". To indicate all Internet mail 1726 addresses on a particular host, the constraint is specified as the 1727 host name. For example, the constraint "xyz.com" is satisfied by any 1728 mail address at the host "xyz.com". To specify any address within a 1729 domain, the constraint is specified with a leading period (as with 1730 URIs). For example, ".xyz.com" indicates all the Internet mail 1731 addresses in the domain "xyz.com", but not Internet mail addresses on 1732 the host "xyz.com". 1734 DNS name restrictions are expressed as foo.bar.com. Any DNS name that 1735 can be constructed by simply adding to the left hand side of the name 1736 satisfies the name constraint. For example, www.foo.bar.com would 1737 satisfy the constraint but foo1.bar.com would not. 1739 Legacy implementations exist where an RFC 822 name is embedded in the 1740 subject distinguished name in an attribute of type EmailAddress (see 1741 sec. 4.1.2.6). When rfc822 names are constrained, but the certificate 1742 does not include a subject alternative name, the rfc822 name con- 1743 straint MUST be applied to the attribute of type EmailAddress in the 1744 subject distinguished name. The ASN.1 syntax for EmailAddress and 1745 the corresponding OID are supplied in Appendix A and B. 1747 Restrictions of the form directoryName MUST be applied to the subject 1748 field in the certificate and to the subjectAltName extensions of type 1749 directoryName. Restrictions of the form x400Address MUST be applied 1750 to subjectAltName extensions of type x400Address. 1752 When applying restrictions of the form directoryName, an implementa- 1753 tion MUST compare DN attributes. At a minimum, implementations MUST 1754 perform the DN comparison rules specified in Section 4.1.2.4. CAs 1755 issuing certificates with a restriction of the form directoryName 1756 SHOULD NOT rely on implementation of the full ISO DN name comparison 1757 algorithm. This implies name restrictions shall be stated identi- 1758 cally to the encoding used in the subject field or subjectAltName 1759 extension. 1761 The syntax of iPAddress MUST be as described in section 4.2.1.7 with 1762 the following additions specifically for Name Constraints. For IPv4 1763 addresses, the ipAddress field of generalName MUST contain eight (8) 1764 octets, encoded in the style of RFC 1519 (CIDR) to represent an 1765 address range.[RFC 1519] For IPv6 addresses, the ipAddress field 1766 MUST contain 32 octets similarly encoded. For example, a name con- 1767 straint for "class C" subnet 10.9.8.0 shall be represented as the 1768 octets 0A 09 08 00 FF FF FF 00, representing the CIDR notation 1769 10.9.8.0/255.255.255.0. 1771 The syntax and semantics for name constraints for otherName, ediPar- 1772 tyName, and registeredID are not defined by this specification. 1774 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 1776 NameConstraints ::= SEQUENCE { 1777 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 1778 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 1780 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 1782 GeneralSubtree ::= SEQUENCE { 1783 base GeneralName, 1784 minimum [0] BaseDistance DEFAULT 0, 1785 maximum [1] BaseDistance OPTIONAL } 1787 BaseDistance ::= INTEGER (0..MAX) 1789 4.2.1.12 Policy Constraints 1791 The policy constraints extension can be used in certificates issued 1792 to CAs. The policy constraints extension constrains path validation 1793 in two ways. It can be used to prohibit policy mapping or require 1794 that each certificate in a path contain an acceptable policy identif- 1795 ier. 1797 If the inhibitPolicyMapping field is present, the value indicates the 1798 number of additional certificates that may appear in the path before 1799 policy mapping is no longer permitted. For example, a value of one 1800 indicates that policy mapping may be processed in certificates issued 1801 by the subject of this certificate, but not in additional certifi- 1802 cates in the path. 1804 If the requireExplicitPolicy field is present, subsequent certifi- 1805 cates shall include an acceptable policy identifier. The value of 1806 requireExplicitPolicy indicates the number of additional certificates 1807 that may appear in the path before an explicit policy is required. 1808 An acceptable policy identifier is the identifier of a policy 1809 required by the user of the certification path or the identifier of a 1810 policy which has been declared equivalent through policy mapping. 1812 Conforming CAs MUST NOT issue certificates where policy constraints 1813 is a null sequence. That is, at least one of the inhibitPolicyMapping 1814 field or the requireExplicitPolicy field MUST be present. The 1815 behavior of clients that encounter a null policy constraints field is 1816 not addressed in this profile. 1818 This extension may be critical or non-critical. 1820 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } 1822 PolicyConstraints ::= SEQUENCE { 1823 requireExplicitPolicy [0] SkipCerts OPTIONAL, 1824 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 1826 SkipCerts ::= INTEGER (0..MAX) 1828 4.2.1.13 Extended key usage field 1830 This field indicates one or more purposes for which the certified 1831 public key may be used, in addition to or in place of the basic pur- 1832 poses indicated in the key usage extension field. This field is 1833 defined as follows: 1835 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 1837 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 1839 KeyPurposeId ::= OBJECT IDENTIFIER 1841 Key purposes may be defined by any organization with a need. Object 1842 identifiers used to identify key purposes shall be assigned in accor- 1843 dance with IANA or ITU-T Rec. X.660 | ISO/IEC/ITU 9834-1. 1845 This extension may, at the option of the certificate issuer, be 1846 either critical or non-critical. 1848 If the extension is flagged critical, then the certificate MUST be 1849 used only for one of the purposes indicated. 1851 If the extension is flagged non-critical, then it indicates the 1852 intended purpose or purposes of the key, and may be used in finding 1853 the correct key/certificate of an entity that has multiple 1854 keys/certificates. It is an advisory field and does not imply that 1855 usage of the key is restricted by the certification authority to the 1856 purpose indicated. Certificate using applications may nevertheless 1857 require that a particular purpose be indicated in order for the cer- 1858 tificate to be acceptable to that application. 1860 If a certificate contains both a critical key usage field and a crit- 1861 ical extended key usage field, then both fields MUST be processed 1862 independently and the certificate MUST only be used for a purpose 1863 consistent with both fields. If there is no purpose consistent with 1864 both fields, then the certificate MUST NOT be used for any purpose. 1866 The following key usage purposes are defined by this profile: 1868 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 1870 id-kp-serverAuth OBJECT IDENTIFIER ::= {id-kp 1} 1871 -- TLS Web server authentication 1872 -- Key usage bits that may be consistent: digitalSignature, 1873 -- keyEncipherment or keyAgreement 1874 -- 1875 id-kp-clientAuth OBJECT IDENTIFIER ::= {id-kp 2} 1876 -- TLS Web client authentication 1877 -- Key usage bits that may be consistent: digitalSignature and/or 1878 -- keyAgreement 1879 -- 1880 id-kp-codeSigning OBJECT IDENTIFIER ::= {id-kp 3} 1881 -- Signing of downloadable executable code 1882 -- Key usage bits that may be consistent: digitalSignature 1883 -- 1884 id-kp-emailProtection OBJECT IDENTIFIER ::= {id-kp 4} 1885 -- E-mail protection 1886 -- Key usage bits that may be consistent: digitalSignature, 1887 -- nonRepudiation, and/or (keyEncipherment 1888 -- or keyAgreement) 1889 -- 1890 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 1891 -- Binding the hash of an object to a time from an agreed-upon time 1892 -- source. Key usage bits that may be consistent: digitalSignature, 1893 -- nonRepudiation 1895 4.2.1.14 CRL Distribution Points 1897 The CRL distribution points extension identifies how CRL information 1898 is obtained. The extension SHOULD be non-critical, but this profile 1899 recommends support for this extension by CAs and applications. 1900 Further discussion of CRL management is contained in section 5. 1902 The cRLDistributionPoints extension is a SEQUENCE of Distribution- 1903 Point. A DistributionPoint consists of three fields, each of which 1904 is optional: the name of the DistributionPoint, ReasonsFlags, and the 1905 cRLIssuer. While each component is optional, a DistributionPoint 1906 MUST NOT consist of only the ReasonsFlags field. If the distribution- 1907 Point omits cRLIssuer, the CRL MUST be issued by the CA that issued 1908 the certificate. If the distributionPointName is absent, cRLIssuer 1909 MUST be present and include a Name corresponding to an X.500 or LDAP 1910 directory entry where the CRL is located. 1912 If the cRLDistributionPoints extension contains a Distribution- 1913 PointName of type URI, the following semantics MUST be assumed: the 1914 URI is a pointer to the current CRL for the associated reasons and 1915 will be issued by the associated cRLIssuer. The expected values for 1916 the URI are those defined in 4.2.1.7. Processing rules for other 1917 values are not defined by this specification. If the distribution- 1918 Point omits reasons, the CRL MUST include revocations for all rea- 1919 sons. 1921 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 } 1923 CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 1925 DistributionPoint ::= SEQUENCE { 1926 distributionPoint [0] DistributionPointName OPTIONAL, 1927 reasons [1] ReasonFlags OPTIONAL, 1928 cRLIssuer [2] GeneralNames OPTIONAL } 1930 DistributionPointName ::= CHOICE { 1931 fullName [0] GeneralNames, 1932 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 1934 ReasonFlags ::= BIT STRING { 1935 unused (0), 1936 keyCompromise (1), 1937 cACompromise (2), 1938 affiliationChanged (3), 1939 superseded (4), 1940 cessationOfOperation (5), 1941 certificateHold (6) } 1943 4.2.1.15 Inhibit Any-Policy 1945 The inhibit any-policy extension can be used in certificates issued 1946 to CAs. The inhibit any-policy indicates that the special any-policy 1947 OID, with the value {2 5 29 32 0}, is not considered an explicit 1948 match for other certificate policies. The value indicates the number 1949 of additional certificates that may appear in the path before any- 1950 policy is no longer permitted. For example, a value of one indicates 1951 that any-policy may be processed in certificates issued by the sub- 1952 ject of this certificate, but not in additional certificates in the 1953 path. 1955 This extension MUST be critical. 1957 id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 } 1959 InhibitAnyPolicy ::= SkipCerts 1961 SkipCerts ::= INTEGER (0..MAX) 1963 4.2.1.16 Freshest CRL (a.k.a. Delta CRL Distribution Point) 1965 The freshest CRL extension identifies how delta-CRL information is 1966 obtained. The extension MUST be non-critical. Further discussion of 1967 CRL management is contained in section 5. 1969 The same syntax is used for this extension and the cRLDistribution- 1970 Points extension, and is described in section 4.2.1.14. The same 1971 conventions apply to both extensions. 1973 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } 1975 FreshestCRL ::= CRLDistributionPoints 1977 4.2.2 Private Internet Extensions 1979 This section defines one new extension for use in the Internet Public 1980 Key Infrastructure. This extension may be used to direct applica- 1981 tions to identify an on-line validation service supporting the issu- 1982 ing CA. As the information may be available in multiple forms, each 1983 extension is a sequence of IA5String values, each of which represents 1984 a URI. The URI implicitly specifies the location and format of the 1985 information and the method for obtaining the information. 1987 An object identifier is defined for the private extension. The 1988 object identifier associated with the private extension is defined 1989 under the arc id-pe within the id-pkix name space. Any future exten- 1990 sions defined for the Internet PKI will also be defined under the arc 1991 id-pe. 1993 id-pkix OBJECT IDENTIFIER ::= 1994 { iso(1) identified-organization(3) dod(6) internet(1) 1995 security(5) mechanisms(5) pkix(7) } 1997 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 1999 4.2.2.1 Authority Information Access 2001 The authority information access extension indicates how to access CA 2002 information and services for the issuer of the certificate in which 2003 the extension appears. Information and services may include on-line 2004 validation services and CA policy data. (The location of CRLs is not 2005 specified in this extension; that information is provided by the 2006 cRLDistributionPoints extension.) This extension may be included in 2007 subject or CA certificates, and it MUST be non-critical. 2009 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 2011 AuthorityInfoAccessSyntax ::= 2012 SEQUENCE SIZE (1..MAX) OF AccessDescription 2014 AccessDescription ::= SEQUENCE { 2015 accessMethod OBJECT IDENTIFIER, 2016 accessLocation GeneralName } 2018 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 2020 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 2022 Each entry in the sequence AuthorityInfoAccessSyntax describes the 2023 format and location of additional information provided by the CA who 2024 issued the certificate in which this extension appears. The type and 2025 format of the information is specified by the accessMethod field; the 2026 accessLocation field specifies the location of the information. The 2027 retrieval mechanism may be implied by the accessMethod or specified 2028 by accessLocation. 2030 This profile defines one OID for accessMethod. The id-ad-caIssuers 2031 OID is used when the additional information lists CAs that have 2032 issued certificates superior to the CA that issued the certificate 2033 containing this extension. The referenced CA Issuers description is 2034 intended to aid certificate users in the selection of a certification 2035 path that terminates at a point trusted by the certificate user. 2037 When id-ad-caIssuers appears as accessInfoType, the accessLocation 2038 field describes the referenced description server and the access pro- 2039 tocol to obtain the referenced description. The accessLocation field 2040 is defined as a GeneralName, which can take several forms. Where the 2041 information is available via http, ftp, or ldap, accessLocation MUST 2042 be a uniformResourceIdentifier. Where the information is available 2043 via the directory access protocol (dap), accessLocation MUST be a 2044 directoryName. When the information is available via electronic mail, 2045 accessLocation MUST be an rfc822Name. The semantics of other name 2046 forms of accessLocation (when accessMethod is id-ad-caIssuers) are 2047 not defined by this specification. The information 2049 [RFC 2560] defines the access descriptor for the Online Certificate 2050 Status Protocol. Additional access descriptors may be defined in 2051 other PKIX specifications. 2053 5 CRL and CRL Extensions Profile 2055 As described above, one goal of this X.509 v2 CRL profile is to 2056 foster the creation of an interoperable and reusable Internet PKI. 2057 To achieve this goal, guidelines for the use of extensions are speci- 2058 fied, and some assumptions are made about the nature of information 2059 included in the CRL. 2061 CRLs may be used in a wide range of applications and environments 2062 covering a broad spectrum of interoperability goals and an even 2063 broader spectrum of operational and assurance requirements. This 2064 profile establishes a common baseline for generic applications 2065 requiring broad interoperability. The profile defines a baseline set 2066 of information that can be expected in every CRL. Also, the profile 2067 defines common locations within the CRL for frequently used attri- 2068 butes as well as common representations for these attributes. 2070 This profile does not define any private Internet CRL extensions or 2071 CRL entry extensions. 2073 Environments with additional or special purpose requirements may 2074 build on this profile or may replace it. 2076 Conforming CAs are not required to issue CRLs if other revocation or 2077 certificate status mechanisms are provided. Conforming CAs that 2078 issue CRLs MUST issue version 2 CRLs, and CAs MUST include the date 2079 by which the next CRL will be issued in the nextUpdate field (see 2080 sec. 5.1.2.5), the CRL number extension (see sec. 5.2.3) and the 2081 authority key identifier extension (see sec. 5.2.1). Conforming 2082 applications are required to process version 1 and 2 CRLs. 2084 5.1 CRL Fields 2086 The X.509 v2 CRL syntax is as follows. For signature calculation, 2087 the data that is to be signed is ASN.1 DER encoded. ASN.1 DER encod- 2088 ing is a tag, length, value encoding system for each element. 2090 CertificateList ::= SEQUENCE { 2091 tbsCertList TBSCertList, 2092 signatureAlgorithm AlgorithmIdentifier, 2093 signatureValue BIT STRING } 2095 TBSCertList ::= SEQUENCE { 2096 version Version OPTIONAL, 2097 -- if present, shall be v2 2098 signature AlgorithmIdentifier, 2099 issuer Name, 2100 thisUpdate Time, 2101 nextUpdate Time OPTIONAL, 2102 revokedCertificates SEQUENCE OF SEQUENCE { 2103 userCertificate CertificateSerialNumber, 2104 revocationDate Time, 2105 crlEntryExtensions Extensions OPTIONAL 2106 -- if present, shall be v2 2107 } OPTIONAL, 2108 crlExtensions [0] EXPLICIT Extensions OPTIONAL 2109 -- if present, shall be v2 2110 } 2112 -- Version, Time, CertificateSerialNumber, and Extensions 2113 -- are all defined in the ASN.1 in section 4.1 2115 -- AlgorithmIdentifier is defined in section 4.1.1.2 2117 The following items describe the use of the X.509 v2 CRL in the 2118 Internet PKI. 2120 5.1.1 CertificateList Fields 2122 The CertificateList is a SEQUENCE of three required fields. The 2123 fields are described in detail in the following subsections. 2125 5.1.1.1 tbsCertList 2127 The first field in the sequence is the tbsCertList. This field is 2128 itself a sequence containing the name of the issuer, issue date, 2129 issue date of the next list, the optional list of revoked certifi- 2130 cates, and optional CRL extensions. When there are no revoked certi- 2131 ficates, the revoked certificates list is absent. When one or more 2132 certificates are revoked, each entry on the revoked certificate list 2133 is defined by a sequence of user certificate serial number, revoca- 2134 tion date, and optional CRL entry extensions. 2136 5.1.1.2 signatureAlgorithm 2138 The signatureAlgorithm field contains the algorithm identifier for 2139 the algorithm used by the CA to sign the CertificateList. The field 2140 is of type AlgorithmIdentifier, which is defined in section 4.1.1.2. 2141 [PKIX ALGS] lists the supported algorithms for this specification. 2142 Conforming CAs MUST use the algorithm identifiers presented in [PKIX 2143 ALGS] when signing with a supported signature algorithm. 2145 This field MUST contain the same algorithm identifier as the signa- 2146 ture field in the sequence tbsCertList (see sec. 5.1.2.2). 2148 5.1.1.3 signatureValue 2150 The signatureValue field contains a digital signature computed upon 2151 the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded tbsCertList 2152 is used as the input to the signature function. This signature value 2153 is then ASN.1 encoded as a BIT STRING and included in the CRL's sig- 2154 natureValue field. The details of this process are specified for each 2155 of the supported algorithms in [PKIX ALGS]. 2157 5.1.2 Certificate List "To Be Signed" 2159 The certificate list to be signed, or TBSCertList, is a SEQUENCE of 2160 required and optional fields. The required fields identify the CRL 2161 issuer, the algorithm used to sign the CRL, the date and time the CRL 2162 was issued, and the date and time by which the CA will issue the next 2163 CRL. 2165 Optional fields include lists of revoked certificates and CRL exten- 2166 sions. The revoked certificate list is optional to support the case 2167 where a CA has not revoked any unexpired certificates that it has 2168 issued. The profile requires conforming CAs to use the CRL extension 2169 cRLNumber in all CRLs issued. 2171 5.1.2.1 Version 2173 This optional field describes the version of the encoded CRL. When 2174 extensions are used, as required by this profile, this field MUST be 2175 present and MUST specify version 2 (the integer value is 1). 2177 5.1.2.2 Signature 2179 This field contains the algorithm identifier for the algorithm used 2180 to sign the CRL. [PKIX ALGS] lists OIDs for the most popular signa- 2181 ture algorithms used in the Internet PKI. 2183 This field MUST contain the same algorithm identifier as the signa- 2184 tureAlgorithm field in the sequence CertificateList (see section 2185 5.1.1.2). 2187 5.1.2.3 Issuer Name 2189 The issuer name identifies the entity who has signed and issued the 2190 CRL. The issuer identity is carried in the issuer name field. Alter- 2191 native name forms may also appear in the issuerAltName extension (see 2192 sec. 5.2.2). The issuer name field MUST contain an X.500 dis- 2193 tinguished name (DN). The issuer name field is defined as the X.501 2194 type Name, and MUST follow the encoding rules for the issuer name 2195 field in the certificate (see sec. 4.1.2.4). 2197 5.1.2.4 This Update 2199 This field indicates the issue date of this CRL. ThisUpdate may be 2200 encoded as UTCTime or GeneralizedTime. 2202 CAs conforming to this profile that issue CRLs MUST encode thisUpdate 2203 as UTCTime for dates through the year 2049. CAs conforming to this 2204 profile that issue CRLs MUST encode thisUpdate as GeneralizedTime for 2205 dates in the year 2050 or later. 2207 Where encoded as UTCTime, thisUpdate MUST be specified and inter- 2208 preted as defined in section 4.1.2.5.1. Where encoded as General- 2209 izedTime, thisUpdate MUST be specified and interpreted as defined in 2210 section 4.1.2.5.2. 2212 5.1.2.5 Next Update 2214 This field indicates the date by which the next CRL will be issued. 2215 The next CRL could be issued before the indicated date, but it will 2216 not be issued any later than the indicated date. CAs SHOULD issue 2217 CRLs with a nextUpdate time equal to or later than all previous CRLs. 2218 nextUpdate may be encoded as UTCTime or GeneralizedTime. 2220 This profile requires inclusion of nextUpdate in all CRLs issued by 2221 conforming CAs. Note that the ASN.1 syntax of TBSCertList describes 2222 this field as OPTIONAL, which is consistent with the ASN.1 structure 2223 defined in [X.509]. The behavior of clients processing CRLs which 2224 omit nextUpdate is not specified by this profile. 2226 CAs conforming to this profile that issue CRLs MUST encode nextUpdate 2227 as UTCTime for dates through the year 2049. CAs conforming to this 2228 profile that issue CRLs MUST encode nextUpdate as GeneralizedTime for 2229 dates in the year 2050 or later. 2231 Where encoded as UTCTime, nextUpdate MUST be specified and inter- 2232 preted as defined in section 4.1.2.5.1. Where encoded as General- 2233 izedTime, nextUpdate MUST be specified and interpreted as defined in 2234 section 4.1.2.5.2. 2236 5.1.2.6 Revoked Certificates 2238 When there are no revoked certificates, the revoked certificates list 2239 is absent. Otherwise, revoked certificates are listed by their 2240 serial numbers. Certificates revoked by the CA are uniquely identi- 2241 fied by the certificate serial number. The date on which the revoca- 2242 tion occurred is specified. The time for revocationDate MUST be 2243 expressed as described in section 5.1.2.4. Additional information may 2244 be supplied in CRL entry extensions; CRL entry extensions are 2245 discussed in section 5.3. 2247 5.1.2.7 Extensions 2249 This field may only appear if the version is 2 (see sec. 5.1.2.1). 2250 If present, this field is a SEQUENCE of one or more CRL extensions. 2251 CRL extensions are discussed in section 5.2. 2253 5.2 CRL Extensions 2255 The extensions defined by ANSI X9 and ISO/IEC/ITU for X.509 v2 CRLs 2256 [X.509] [X9.55] provide methods for associating additional attributes 2257 with CRLs. The X.509 v2 CRL format also allows communities to define 2258 private extensions to carry information unique to those communities. 2259 Each extension in a CRL may be designated as critical or non- 2260 critical. A CRL validation MUST fail if it encounters a critical 2261 extension which it does not know how to process. However, an 2262 unrecognized non-critical extension may be ignored. The following 2263 subsections present those extensions used within Internet CRLs. Com- 2264 munities may elect to include extensions in CRLs which are not 2265 defined in this specification. However, caution should be exercised 2266 in adopting any critical extensions in CRLs which might be used in a 2267 general context. 2269 Conforming CAs that issue CRLs are required to include the authority 2270 key identifier (see sec. 5.2.1) and the CRL number (see sec. 5.2.3) 2271 extensions in all CRLs issued. 2273 5.2.1 Authority Key Identifier 2275 The authority key identifier extension provides a means of identify- 2276 ing the public key corresponding to the private key used to sign a 2277 CRL. The identification can be based on either the key identifier 2278 (the subject key identifier in the CRL signer's certificate) or on 2279 the issuer name and serial number. This extension is especially use- 2280 ful where an issuer has more than one signing key, either due to mul- 2281 tiple concurrent key pairs or due to changeover. 2283 Conforming CAs MUST use the key identifier method, and MUST include 2284 this extension in all CRLs issued. 2286 The syntax for this CRL extension is defined in section 4.2.1.1. 2288 5.2.2 Issuer Alternative Name 2290 The issuer alternative names extension allows additional identities 2291 to be associated with the issuer of the CRL. Defined options include 2292 an rfc822 name (electronic mail address), a DNS name, an IP address, 2293 and a URI. Multiple instances of a name and multiple name forms may 2294 be included. Whenever such identities are used, the issuer alterna- 2295 tive name extension MUST be used. 2297 The issuerAltName extension SHOULD NOT be marked critical. 2299 The OID and syntax for this CRL extension are defined in section 2300 4.2.1.8. 2302 5.2.3 CRL Number 2304 The CRL number is a non-critical CRL extension which conveys a mono- 2305 tonically increasing sequence number for each CRL issued by a CA. 2306 This extension allows users to easily determine when a particular CRL 2307 supersedes another CRL. CAs conforming to this profile MUST include 2308 this extension in all CRLs. 2310 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 2312 cRLNumber ::= INTEGER (0..MAX) 2314 5.2.4 Delta CRL Indicator 2316 The delta CRL indicator is a critical CRL extension that identifies a 2317 CRL as being a delta CRL. Delta CRLs contain updates to revocation 2318 information previously distributed, rather than all the information 2319 that would appear in a complete CRL. The use of delta CRLs can sig- 2320 nificantly reduce network load and processing time in some environ- 2321 ments. Delta CRLs are generally smaller than the CRLs they update, 2322 so applications that obtain delta CRLs consume less network bandwidth 2323 than applications that obtain the corresponding complete CRLs. 2324 Applications which store revocation information in a format other 2325 than the CRL structure can add new revocation information to the 2326 local database without reprocessing information. 2328 The delta CRL indicator extension contains a single value of type 2329 BaseCRLNumber. This value identifies the CRL number of the base CRL 2330 that was used as the foundation in the generation of this delta CRL. 2331 The referenced base CRL is a CRL that was explicitly issued as a CRL 2332 that is complete for a given scope (e.g., a set of revocation reasons 2333 or a particular distribution point.) The CRL containing the delta CRL 2334 indicator extension contains all updates to the certificate revoca- 2335 tion status for that same scope. The combination of a CRL containing 2336 the delta CRL indicator extension plus the CRL referenced in the 2337 BaseCRLNumber component of this extension is equivalent to a full 2338 CRL, for the applicable scope, at the time of publication of the 2339 delta CRL. 2341 When a conforming CA issues a delta CRL, the CA MUST also issue a CRL 2342 that is complete for the given scope. Both the delta CRL and the 2343 complete CRL MUST include the CRL number extension (see sec. 5.2.3). 2344 The CRL number extension in the delta CRL and the complete CRL MUST 2345 contain the same value. When a delta CRL is issued, it MUST cover 2346 the same set of reasons and same set of certificates that were 2347 covered by the base CRL it references. 2349 An application can construct a CRL that is complete for a given 2350 scope, at the current time, in either of the following ways: 2351 (a) by retrieving the current delta CRL for that scope, and com- 2352 bining it with an issued CRL that is complete for that scope and 2353 that has a cRLNumber greater than or equal to the cRLNumber of the 2354 base CRL referenced in the delta CRL; or 2355 (b) by retrieving the current delta CRL for that scope and combin- 2356 ing it with a locally constructed CRL whose cRLNumber is greater 2357 than or equal to the cRLNumber of the base CRL referenced in the 2358 current delta CRL. 2360 The constructed CRL has the CRL number specified in the CRL number 2361 extension found in the delta CRL used in its construction. 2363 CAs must ensure that application of a delta CRL to the referenced 2364 base revocation information accurately reflects the current status of 2365 revocation. If a CA supports the certificateHold revocation reason 2366 the following rules must be applied when generating delta CRLs: 2368 (a) If a certificate was listed as revoked with revocation reason 2369 certificateHold on a CRL (either a delta CRL or a CRL that is com- 2370 plete for a given scope), whose cRLNumber is n, and the hold is 2371 subsequently released, the certificate must be included in all 2372 delta CRLs issued after the hold is released where the cRLNumber 2373 of the referenced base CRL is less than or equal to n. The certi- 2374 ficate must be listed with revocation reason removeFromCRL unless 2375 the certificate is subsequently revoked again for one of the revo- 2376 cation reasons covered by the delta CRL, in which case the certi- 2377 ficate must be listed with the revocation reason appropriate for 2378 the subsequent revocation. 2380 (b) If the certificate was not removed from hold, but was per- 2381 manently revoked, then it must be listed on all subsequent delta 2382 CRLs where the cRLNumber of the referenced base CRL is less than 2383 the cRLNumber of the CRL (either a delta CRL or a CRL that is com- 2384 plete for the given scope) on which the permanent revocation 2385 notice first appeared. 2387 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 2388 deltaCRLIndicator EXTENSION ::= { 2389 SYNTAX BaseCRLNumber 2390 IDENTIFIED BY id-ce-deltaCRLIndicator } 2392 BaseCRLNumber ::= CRLNumber 2394 5.2.5 Issuing Distribution Point 2396 The issuing distribution point is a critical CRL extension that iden- 2397 tifies the CRL distribution point for a particular CRL, and it indi- 2398 cates whether the CRL covers revocation for end entity certificates 2399 only, CA certificates only, or a limited set of reason codes. 2400 Although the extension is critical, conforming implementations are 2401 not required to support this extension. 2403 The CRL is signed using the CA's private key. CRL Distribution 2404 Points do not have their own key pairs. If the CRL is stored in the 2405 X.500 Directory, it is stored in the Directory entry corresponding to 2406 the CRL distribution point, which may be different than the Directory 2407 entry of the CA. 2409 The reason codes associated with a distribution point shall be speci- 2410 fied in onlySomeReasons. If onlySomeReasons does not appear, the dis- 2411 tribution point shall contain revocations for all reason codes. CAs 2412 may use CRL distribution points to partition the CRL on the basis of 2413 compromise and routine revocation. In this case, the revocations 2414 with reason code keyCompromise (1) and cACompromise (2) appear in one 2415 distribution point, and the revocations with other reason codes 2416 appear in another distribution point. 2418 Where the issuingDistributionPoint extension contains a URL, the fol- 2419 lowing semantics MUST be assumed: the object is a pointer to the most 2420 current CRL issued by this CA. The URI schemes ftp, http, mailto 2421 [RFC1738] and ldap [RFC1778] are defined for this purpose. The URI 2422 MUST be an absolute, not relative, pathname and MUST specify the 2423 host. 2425 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 2427 issuingDistributionPoint ::= SEQUENCE { 2428 distributionPoint [0] DistributionPointName OPTIONAL, 2429 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 2430 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 2431 onlySomeReasons [3] ReasonFlags OPTIONAL, 2432 indirectCRL [4] BOOLEAN DEFAULT FALSE } 2434 5.2.6 Freshest CRL (a.k.a. Delta CRL Distribution Point) 2436 The freshest CRL extension identifies how delta-CRL information for 2437 this CRL is obtained. The extension MUST be non-critical. 2439 The same syntax is used for this extension as the cRLDistribution- 2440 Points certificate extension, and is described in section 4.2.1.14. 2441 The same conventions apply to both extensions. 2443 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } 2445 FreshestCRL ::= CRLDistributionPoints 2447 5.3 CRL Entry Extensions 2449 The CRL entry extensions already defined by ANSI X9 and ISO/IEC/ITU 2450 for X.509 v2 CRLs provide methods for associating additional attri- 2451 butes with CRL entries [X.509] [X9.55]. The X.509 v2 CRL format also 2452 allows communities to define private CRL entry extensions to carry 2453 information unique to those communities. Each extension in a CRL 2454 entry may be designated as critical or non-critical. A CRL valida- 2455 tion MUST fail if it encounters a critical CRL entry extension which 2456 it does not know how to process. However, an unrecognized non- 2457 critical CRL entry extension may be ignored. The following subsec- 2458 tions present recommended extensions used within Internet CRL entries 2459 and standard locations for information. Communities may elect to use 2460 additional CRL entry extensions; however, caution should be exercised 2461 in adopting any critical extensions in CRL entries which might be 2462 used in a general context. 2464 All CRL entry extensions used in this specification are non-critical. 2465 Support for these extensions is optional for conforming CAs and 2466 applications. However, CAs that issue CRLs SHOULD include reason 2467 codes (see sec. 5.3.1) and invalidity dates (see sec. 5.3.3) whenever 2468 this information is available. 2470 5.3.1 Reason Code 2472 The reasonCode is a non-critical CRL entry extension that identifies 2473 the reason for the certificate revocation. CAs are strongly 2474 encouraged to include meaningful reason codes in CRL entries; how- 2475 ever, the reason code CRL entry extension SHOULD be absent instead of 2476 using the unspecified (0) reasonCode value. 2478 id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 } 2480 -- reasonCode ::= { CRLReason } 2481 CRLReason ::= ENUMERATED { 2482 unspecified (0), 2483 keyCompromise (1), 2484 cACompromise (2), 2485 affiliationChanged (3), 2486 superseded (4), 2487 cessationOfOperation (5), 2488 certificateHold (6), 2489 removeFromCRL (8) } 2491 5.3.2 Hold Instruction Code 2493 The hold instruction code is a non-critical CRL entry extension that 2494 provides a registered instruction identifier which indicates the 2495 action to be taken after encountering a certificate that has been 2496 placed on hold. 2498 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 2500 holdInstructionCode ::= OBJECT IDENTIFIER 2502 The following instruction codes have been defined. Conforming appli- 2503 cations that process this extension MUST recognize the following 2504 instruction codes. 2506 holdInstruction OBJECT IDENTIFIER ::= 2507 { iso(1) member-body(2) us(840) x9-57(10040) 2 } 2509 id-holdinstruction-none OBJECT IDENTIFIER ::= {holdInstruction 1} 2510 id-holdinstruction-callissuer 2511 OBJECT IDENTIFIER ::= {holdInstruction 2} 2512 id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3} 2514 Conforming applications which encounter an id-holdinstruction- 2515 callissuer MUST call the certificate issuer or reject the certifi- 2516 cate. Conforming applications which encounter an id- 2517 holdinstruction-reject MUST reject the certificate. The hold instruc- 2518 tion id-holdinstruction-none is semantically equivalent to the 2519 absence of a holdInstructionCode, and its use is strongly deprecated 2520 for the Internet PKI. 2522 5.3.3 Invalidity Date 2524 The invalidity date is a non-critical CRL entry extension that pro- 2525 vides the date on which it is known or suspected that the private key 2526 was compromised or that the certificate otherwise became invalid. 2527 This date may be earlier than the revocation date in the CRL entry, 2528 which is the date at which the CA processed the revocation. When a 2529 revocation is first posted by a CA in a CRL, the invalidity date may 2530 precede the date of issue of earlier CRLs, but the revocation date 2531 SHOULD NOT precede the date of issue of earlier CRLs. Whenever this 2532 information is available, CAs are strongly encouraged to share it 2533 with CRL users. 2535 The GeneralizedTime values included in this field MUST be expressed 2536 in Greenwich Mean Time (Zulu), and MUST be specified and interpreted 2537 as defined in section 4.1.2.5.2. 2539 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 2541 invalidityDate ::= GeneralizedTime 2543 5.3.4 Certificate Issuer 2545 This CRL entry extension identifies the certificate issuer associated 2546 with an entry in an indirect CRL, i.e. a CRL that has the indirectCRL 2547 indicator set in its issuing distribution point extension. If this 2548 extension is not present on the first entry in an indirect CRL, the 2549 certificate issuer defaults to the CRL issuer. On subsequent entries 2550 in an indirect CRL, if this extension is not present, the certificate 2551 issuer for the entry is the same as that for the preceding entry. 2552 This field is defined as follows: 2554 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } 2556 certificateIssuer ::= GeneralNames 2558 If used by conforming CAs that issue CRLs, this extension is always 2559 critical. If an implementation ignored this extension it could not 2560 correctly attribute CRL entries to certificates. This specification 2561 RECOMMENDS that implementations recognize this extension. 2563 6 Certification Path Validation 2565 Certification path validation procedures for the Internet PKI are 2566 based on section 12.4.3 of [X.509]. Certification path processing 2567 verifies the binding between the subject distinguished name and/or 2568 subject alternative name and subject public key. The binding is lim- 2569 ited by constraints which are specified in the certificates which 2570 comprise the path. The basic constraints and policy constraints 2571 extensions allow the certification path processing logic to automate 2572 the decision making process. 2574 This section describes an algorithm for validating certification 2575 paths. Conforming implementations of this specification are not 2576 required to implement this algorithm, but MUST be functionally 2577 equivalent to the external behavior resulting from this procedure. 2578 Any algorithm may be used by a particular implementation so long as 2579 it derives the correct result. 2581 In section 6.1, the text describes basic path validation. This text 2582 assumes that all valid paths begin with certificates issued by a sin- 2583 gle "most-trusted CA". The algorithm requires the public key of the 2584 CA, the CA's name, the validity period of the public key, and any 2585 constraints upon the set of paths which may be validated using this 2586 key. 2588 The "most-trusted CA" is a matter of policy: it could be a root CA in 2589 a hierarchical PKI; the CA that issued the verifier's own 2590 certificate(s); or any other CA in a network PKI. The path valida- 2591 tion procedure is the same regardless of the choice of "most-trusted 2592 CA." 2594 section 6.2 describes extensions to the basic path validation algo- 2595 rithm. Two specific cases are discussed: the case where paths may 2596 begin with one of several trusted CAs; and where compatibility with 2597 the PEM architecture is required. 2599 6.1 Basic Path Validation 2601 This text describes an algorithm for X.509 path processing. A con- 2602 formant implementation MUST include an X.509 path processing pro- 2603 cedure that is functionally equivalent to the external behavior of 2604 this algorithm. 2606 This text assumes that there is a single trust anchor for certifica- 2607 tion path processing, which simplifies the description of the path 2608 processing procedure. This procedure can be extended to address mul- 2609 tiple trust anchors, as discussed further in Section 6.2. 2611 The primary goal of path validation is to verify the binding between 2612 a subject distinguished name or subject alternative name and subject 2613 public key, as represented in the end entity certificate, based on 2614 the public key of the trust anchor. This requires obtaining a 2615 sequence of certificates that support that binding. The procedure 2616 performed to obtain this sequence of certificates is outside the 2617 scope of this section. 2619 To meet this goal, the path validation process verifies, among other 2620 things, that a prospective certification path (a sequence of n certi- 2621 ficates) satisfies the following conditions: 2622 (i) for all x in {1, ..., n-1}, the subject of certificate x is 2623 the issuer of certificate x+1; 2624 (ii) certificate 1 is issued by the trust anchor; 2625 (iii) certificate n is the end entity certificate; and 2626 (iv) for all x in {1, ..., n}, the certificate was valid at the 2627 time in question. 2629 A particular certification path may not, however, be appropriate for 2630 all applications. The path validation process also determines the 2631 set of certificate policies that are valid for this path, based on 2632 the certificate policies extension, policy mapping extension, policy 2633 constraints extension, and inhibit any-policy extension. To achieve 2634 this, the path validation algorithm constructs a "valid policy tree." 2635 If the set of certificate policies that are valid for this path is 2636 not empty, then the result will be a valid policy tree of depth n, 2637 otherwise the result will be a NULL valid policy tree. 2639 This section presents the algorithm in four basic steps: (1) initial- 2640 ization, (2) basic certificate processing, (3) preparation for the 2641 next certificate, and (4) wrap-up. Steps (1) and (4) are performed 2642 exactly once. Step (2) is performed for all certificates in the 2643 path. Step (3) is performed for all certificates in the path except 2644 the final certificate. Figure 2 provides a high-level flowchart of 2645 this algorithm. 2647 +-------+ 2648 | START | 2649 +-------+ 2650 | 2651 V 2652 +----------------+ 2653 | Initialization | 2654 +----------------+ 2655 | 2656 +<--------------------+ 2657 | | 2658 V | 2659 +----------------+ | 2660 | Process Cert | | 2661 +----------------+ | 2662 | | 2663 V | 2664 +================+ | 2665 | IF Last Cert | | 2666 | in Path | | 2667 +================+ | 2668 | | | 2669 THEN | | ELSE | 2670 V V | 2671 +----------------+ +----------------+ | 2672 | Wrap up | | Prepare for | | 2673 +----------------+ | Next Cert | | 2674 | +----------------+ | 2675 V | | 2676 +-------+ +--------------+ 2677 | STOP | 2678 +-------+ 2680 Figure 2. Path Processing Flowchart 2682 6.1.1 Inputs 2684 This algorithm assumes the following seven inputs are provided to the 2685 path processing logic: 2687 (a) a prospective certification path of length n; 2689 (b) the time, T, for which the validity of the path should be 2690 determined. This may be the current date/time, or some point in 2691 the past. 2693 (c) user_initial_policy_set: A set of certificate policy identif- 2694 iers naming the policies that are acceptable to the certificate 2695 user. The user_initial_policy_set has the special value "any- 2696 policy" if the user is not concerned about certificate policy. 2698 (d) trust anchor information, describing a CA that serves as a 2699 trust anchor for the certification path. The trust anchor infor- 2700 mation includes: 2701 (1) the trusted issuer name, 2702 (2) optionally, the trusted issuer unique identifier, 2703 (3) the trusted public key algorithm, 2704 (4) the trusted public key, and 2705 (5) optionally, the trusted public key parameters associated 2706 with the public key. 2708 The trust anchor information may be provided to the path process- 2709 ing procedure in the form of a self-signed certificate. The 2710 trusted anchor information is trusted because it was delivered to 2711 the path processing procedure by some trustworthy "out-of-band" 2712 procedure. If the trusted public key algorithm requires parame- 2713 ters, then the parameters are provided along with the trusted pub- 2714 lic key. 2716 (e) initial-policy-mapping-inhibit, which indicates if policy map- 2717 ping is allowed in the certification path. 2719 (f) initial-explicit-policy, which indicates if the path must be 2720 valid for at least one of the certificate policies in the 2721 user_initial_policy_set. 2723 (g) initial-any-policy-inhibit, which indicates whether the any- 2724 policy OID should be processed if it is included in a certificate. 2726 6.1.2 Initialization 2728 The initialization phase establishes twelve state variables based 2729 upon the seven inputs: 2731 (a) valid_policy_tree: A tree of certificate policies with their 2732 optional qualifiers; each of the leaves of the tree represents a 2733 valid policy at this stage in the certification path validation. 2734 If valid policies exist at this stage in the certification path 2735 validation, the depth of the tree is equal to the number of certi- 2736 ficates in the chain that have been processed. If valid policies 2737 do not exist at this stage in the certification path validation, 2738 the tree is set to NULL. Once the tree is set to NULL, policy pro- 2739 cessing ceases. 2741 Each node in the valid_policy_tree includes four data objects: the 2742 valid policy, a set of associated policy qualifiers, a set of one 2743 or more expected policy values, and a criticality indicator. If 2744 the node is at depth x, the components of the node have the fol- 2745 lowing semantics: 2746 (i) The valid_policy is a single policy OID representing a 2747 valid policy for the path of length x. 2748 (ii) The qualifier_set is a set of policy qualifiers associated 2749 with the valid policy in certificate x. 2750 (iii) The criticality_indicator indicates whether the certifi- 2751 cate policy extension in certificate x was marked as critical. 2752 (iv) The expected_policy_set contains one or more policy OIDs 2753 that would satisfy this policy in the certificate x+1. 2755 The initial value of the valid_policy_tree is a single node with 2756 valid_policy "any-policy", an empty qualifier_set, an 2757 expected_policy_set with the single value "any-policy", and a 2758 criticality_indicator of FALSE. This node is considered to be at 2759 depth zero. 2761 Figure 3 is a graphic representation of the initial state of the 2762 valid_policy_tree. Additional figures will use this format to 2763 describe changes in the valid_policy_tree during path processing. 2765 +-----------------+ 2766 | "any-policy" | <---- valid_policy 2767 +-----------------+ 2768 | {} | <---- qualifier_set 2769 +-----------------+ 2770 | FALSE | <---- criticality_indicator 2771 +-----------------+ 2772 | {"any-policy"} | <---- expected_policy_set 2773 +-----------------+ 2775 Figure 3. Initial value of the valid_policy_tree state variable 2777 (b) permitted_subtrees: A set of root names for each name type 2778 (e.g., X.500 distinguished names, email addresses, or ip 2779 addresses) defining a set of subtrees within which all subject 2780 names in subsequent certificates in the certification path shall 2781 fall. This variable includes a set for each name type: the initial 2782 value for the set for Distinguished Names is the set of all Dis- 2783 tinguished names; the initial value for the set of RFC822 names is 2784 the set of all RFC822 names, etc. 2786 (c) excluded_subtrees: A set of root names for each name type 2787 (e.g., X.500 distinguished names, email addresses, or ip 2788 addresses) defining a set of subtrees within which no subject name 2789 in subsequent certificates in the certification path may fall. 2790 This variable includes a set for each name type, and the initial 2791 value for each set is "empty". 2793 (d) explicit_policy: an integer which indicates if a non-NULL 2794 valid_policy_tree is required. The integer indicates the number of 2795 non-self-issued certificates to be processed before this require- 2796 ment is imposed. Once set, this variable may be decreased, but may 2797 not be increased. That is, if a certificate in the path requires a 2798 non-NULL valid_policy_tree, a later certificate can not remove 2799 this requirement. If initial-explicit-policy is set, then the ini- 2800 tial value is 0, otherwise the initial value is n+1. 2802 (e) inhibit_any-policy: an integer which indicates whether the 2803 "any-policy" policy identifier is considered a match. The integer 2804 indicates the number of non-self-issued certificates to be pro- 2805 cessed before the "any-policy" OID, if asserted in a certificate, 2806 is ignored. Once set, this variable may be decreased, but may not 2807 be increased. That is, if a certificate in the path inhibits pro- 2808 cessing of "any-policy", a later certificate can not permit it. If 2809 initial-any-policy-inhibit is set, then the initial value is 0, 2810 otherwise the initial value is n+1. 2812 (f) policy_mapping: an integer which indicates if policy mapping 2813 is permitted. The integer indicates the number of non-self-issued 2814 certificates to be processed before policy mapping is inhibited. 2815 Once set, this variable may be decreased, but may not be 2816 increased. That is, if a certificate in the path specifies policy 2817 mapping is not permitted, it can not be overridden by a later cer- 2818 tificate. If initial-policy-mapping-inhibit is set, then the ini- 2819 tial value is 0, otherwise the initial value is n+1. 2821 (g) working_public_key_algorithm: the digital signature algorithm 2822 used to verify the signature of a certificate. The 2823 working_public_key_algorithm is initialized from the trusted pub- 2824 lic key algorithm provided in the trust anchor information. 2826 (h) working_public_key: the public key used to verify the signa- 2827 ture of a certificate. The working_public_key is initialized from 2828 the trusted public key provided in the trust anchor information. 2830 (i) working_public_key_parameters: parameters associated with the 2831 current public key, that may required to verify a signature 2832 (depending upon the algorithm). The working_public_key_parameters 2833 variable is initialized from the trusted public key parameters 2834 provided in the trust anchor information. 2836 (j) working_issuer_name: the issuer distinguished name expected 2837 in the next certificate in the chain. The working_issuer_name is 2838 initialized to the trusted issuer provided in the trust anchor 2839 information. 2841 (k) working_issuer_UID: a distinguished name may be associated 2842 with an optional unique identifier. The working_issuer_UID is the 2843 unique identifier that is expected in the next certificate, or the 2844 value NULL. The working_issuer_UID is initialized to the trusted 2845 issuer's unique identifier provided in the trust anchor informa- 2846 tion. 2848 (l) max_path_length: this integer is initialized to n, and is 2849 reset by the path length constraint field within the basic con- 2850 straints extension of a CA certificate. 2852 Upon completion of the initialization steps, perform the basic certi- 2853 ficate processing steps specified in 6.1.3. 2855 6.1.3 Basic Certificate Processing 2857 The basic path processing actions to be performed for certificate i 2858 are listed below. 2860 (a) Verify the basic certificate information. The certificate 2861 must satisfy each of the following: 2863 (1) The certificate was signed with the 2864 working_public_key_algorithm using the working_public_key and 2865 the working_public_key_parameters. 2867 (2) The certificate validity period includes time T. 2869 (3) At time T, the certificate is not revoked and is not on 2870 hold status. This may be determined by obtaining the appropri- 2871 ate CRL (see section 6.3), status information, or by out-of- 2872 band mechanisms. 2874 (4) The certificate issuer name is the working_issuer_name. 2876 (5) The certificate issuer unique identifier is the 2877 working_issuer_UID, meaning: 2878 (i) working_issuer_UID is non-null and matches the value in 2879 the issuerUID field, or 2880 (ii) working_issuer_UID is null and the issuerUID field is 2881 not present. 2883 (b) If certificate i is not self-issued, verify that the subject 2884 name is within one of the permitted_subtrees for X.500 dis- 2885 tinguished names, and verify that each of the alternative names in 2886 the subjectAltName extension (critical or non-critical) is within 2887 one of the permitted_subtrees for that name type. 2889 (c) If certificate i is not self-issued, verify that the subject 2890 name is not within one of the excluded_subtrees for X.500 dis- 2891 tinguished names, and verify that each of the alternative names in 2892 the subjectAltName extension (critical or non-critical) is not 2893 within one of the excluded_subtrees for that name type. 2895 (d) If the certificate policies extension is present in the certi- 2896 ficiate and the valid_policy_tree is not NULL, process the policy 2897 information by performing the following steps in order: 2899 (1) For each policy P not equal to "any-policy" in the certifi- 2900 cate policies extension, let P-OID denote the OID in policy P 2901 and P-Q denote the qualifier set for policy P. Perform the 2902 following steps in order: 2904 (i) If the valid_policy_tree includes a node of depth i-1 2905 where P-OID is in the expected_policy_set, create a child 2906 node as follows: set the valid_policy to OID- P; set the 2907 qualifier_set to P-Q, and set the expected_policy_set to 2908 {P-OID}. 2910 For example, consider a valid_policy_tree with a node of 2911 depth i-1 where the expected_policy_set is {Gold, White}. 2912 Assume the certificate policies Gold and Silver appear in 2913 the certificate policies extension of certificate i. The 2914 Gold policy is matched but the Silver policy is not. This 2915 rule will generate a child node of depth i for the Gold pol- 2916 icy. The result is shown as Figure 4. 2918 |-----------------| 2919 | Red | 2920 |-----------------| 2921 | {} | 2922 |-----------------| node of depth i-1 2923 | FALSE | 2924 |-----------------| 2925 | {Gold, White} | 2926 |-----------------| 2927 | 2928 | 2929 | 2930 V 2931 |-----------------| 2932 | Gold | 2933 |-----------------| 2934 | {} | 2935 |-----------------| node of depth i 2936 | uninitialized | 2937 |-----------------| 2938 | {Gold} | 2939 |-----------------| 2941 Figure 4. Processing an exact match 2943 (ii) If there was no match in step (i) and the 2944 valid_policy_tree includes a node of depth i-1 with the 2945 valid policy "any-policy", generate a child node with the 2946 following values: set the valid_policy to P-OID; set the 2947 qualifier_set to P-Q, and set the expected_policy_set to 2948 {P-OID}. 2950 For example, consider a valid_policy_tree with a node of 2951 depth i-1 where the valid_policy is "any-policy". Assume the 2952 certificate policies Gold and Silver appear in the certifi- 2953 cate policies extension of certificate i. The Gold policy 2954 does not have a qualifier, but the Silver policy has the 2955 qualifier Q-Silver. If Gold and Silver were not matched in 2956 (i) above, this rule will generate two child nodes of depth 2957 i, one for each policy. The result is shown as Figure 5. 2959 |-----------------| 2960 | "any-policy" | 2961 |-----------------| 2962 | {} | 2963 |-----------------| node of depth i-1 2964 | FALSE | 2965 |-----------------| 2966 | {"any-policy"} | 2967 |-----------------| 2968 / \ 2969 / \ 2970 / \ 2971 / \ 2972 |-----------------| |-----------------| 2973 | Gold | | Silver | 2974 |-----------------| |-----------------| 2975 | {} | | {Q-Silver} | 2976 |-----------------| nodes of |-----------------| 2977 | uninitialized | depth i | uninitialized | 2978 |-----------------| |-----------------| 2979 | {Gold} | | {Silver} | 2980 |-----------------| |-----------------| 2982 Figure 5. Processing unmatched policies when a leaf node 2983 specifies "any-policy" 2985 (2) If the certificate policies extension includes the pol- 2986 icy "any-policy" with the qualifier set AP-Q and 2987 inhibit_any-policy is greater than 0, then: 2989 For each node in the valid_policy_tree of depth i-1, for 2990 each value in the expected_policy_set (including "any- 2991 policy") that does not appear in a child node, create a 2992 child node with the following values: set the valid_policy 2993 to the value from the expected_policy_set in the parent 2994 node; set the qualifier_set to AP-Q, and set the 2995 expected_policy_set to the value in the valid_policy from 2996 this node. 2998 For example, consider a valid_policy_tree with a node of 2999 depth i-1 where the expected_policy_set = {Gold, Silver}. 3000 Assume "any-policy" appears in the certificate policies 3001 extension of certificate i, but Gold and Silver do not. 3002 This rule will generate two child nodes of depth i, one for 3003 each policy. The result is shown below as Figure 6. 3005 |-----------------| 3006 | Red | 3007 |-----------------| 3008 | {} | 3009 |-----------------| node of depth i-1 3010 | FALSE | 3011 |-----------------| 3012 | {Gold, Silver} | 3013 |-----------------| 3014 / \ 3015 / \ 3016 / \ 3017 / \ 3018 |-----------------| |-----------------| 3019 | Gold | | Silver | 3020 |-----------------| |-----------------| 3021 | {} | | {} | 3022 |-----------------| nodes of |-----------------| 3023 | uninitialized | depth i | uninitialized | 3024 |-----------------| |-----------------| 3025 | {Gold} | | {Silver} | 3026 |-----------------| |-----------------| 3028 Figure 6. Processing unmatched policies when the certificate 3029 policies extension specifies "any-policy" 3031 (3) If there is a node in the valid_policy_tree of depth i-1 3032 or less without any child nodes, delete that node. Repeat 3033 this step until there are no nodes of depth i-1 or less 3034 without children. 3036 For example, consider the valid_policy_tree shown in Figure 3037 7 below. The two nodes at depth i-1 that are marked with an 3038 to the resulting tree will cause the node at depth i-2 that 3039 is marked with an 'Y' to be deleted. The following applica- 3040 tion of the rule does not cause any nodes to be deleted, and 3041 this step is complete. 3043 +-----------+ 3044 | | node of depth i-3 3045 +-----------+ 3046 / | \ 3047 / | \ 3048 / | \ 3049 / | \ 3050 +-----------+ +-----------+ +-----------+ 3051 | | | | | Y | nodes of 3052 +-----------+ +-----------+ +-----------+ depth i-2 3053 / \ \ \ 3054 / \ \ \ 3055 +-----------+ +-----------+ +-----------+ +-----------+ nodes of 3056 | | | X | | | | X | depth 3057 +-----------+ +-----------+ +-----------+ +-----------+ i-1 3058 | / | \ 3059 | / | \ 3060 | / | \ 3061 +-----------+ +-----------+ +-----------+ +-----------+ nodes of 3062 | | | | | | | | depth 3063 +-----------+ +-----------+ +-----------+ +-----------+ i 3065 Figure 7. Pruning the valid_policy_tree 3067 (4) If the certificate policies extension was marked as criti- 3068 cal, set the criticality_indicator in all nodes of depth i to 3069 TRUE. If the certificate policies extension was not marked 3070 critical, set the criticality_indicator in all nodes of depth i 3071 to FALSE. 3073 (e) If the certificate policies extension is not present, set the 3074 valid_policy_tree to NULL. 3076 (f) verify that either explicit_policy is greater than 0 or the 3077 valid_policy_tree is not equal to NULL; 3079 If any of steps (a), (b), (c), or (f) fails, the procedure ter- 3080 minates, returning a failure indication and an appropriate reason. 3082 If i is not equal to n, continue by performing the preparatory steps 3083 listed in 6.1.4. If i is equal to n, perform the wrap-up steps 3084 listed in 6.1.5. 3086 6.1.4 Preparation for Certificate i+1 3088 To prepare for processing of certificate i+1, perform the following 3089 steps for certificate i: 3091 (a) If a policy mapping extension is present, verify that the spe- 3092 cial value "any-policy" does not appear as an issuerDomainPolicy 3093 or a subjectDomainPolicy. 3095 (b) If a policy mapping extension is present, then for each 3096 issuerDomainPolicy ID-P in the policy mapping extension: 3098 (1) If the policy_mapping variable is greater than 0, for each 3099 node in the valid_policy_tree of depth i where ID-P is the 3100 valid_policy, set expected_policy_set to the set of sub- 3101 jectDomainPolicy values that are specified as equivalent to 3102 ID-P by the policy mapping extension. 3104 (2) If the policy_mapping variable is equal to 0: 3106 (i) delete each node of depth i in the valid_policy_tree 3107 where ID-P is the valid_policy. 3108 (ii) If there is a node in the valid_policy_tree of depth 3109 i-1 or less without any child nodes, delete that node. 3110 Repeat this step until there are no nodes of depth i-1 or 3111 less without children. 3113 (c) Assign the certificate subject name to working_issuer_name. 3115 (d) Assign the certificate subjectPublicKey to working_public_key. 3117 (e) If the subjectPublicKeyInfo field of the certificate contains 3118 an algorithm field with non-null parameters, assign the parameters 3119 to the working_public_key_parameters variable. 3121 If the subjectPublicKeyInfo field of the certificate contains an 3122 algorithm field with null parameters or parameters are omitted, 3123 compare the certificate subjectPublicKey algorithm to the 3124 working_public_key_algorithm. If the certificate subjectPublicKey 3125 algorithm and the working_public_key_algorithm are different, set 3126 the working_public_key_parameters to null. 3128 (f) Assign the certificate subjectPublicKey algorithm to the 3129 working_public_key_algorithm variable. 3131 (g) If a name constraints extension is included in the certifi- 3132 cate, modify the permitted_subtrees and excluded_subtrees state 3133 variables as follows: 3135 (1) If permittedSubtrees is present in the certificate, set the 3136 permitted_subtrees state variable to the intersection of its 3137 previous value and the value indicated in the extension field. If 3138 permittedSubtrees does not include a particular name type, the 3139 permitted_subtrees state variable is unchanged for that name type. 3141 (2) If excludedSubtrees is present in the certificate, set the 3142 excluded_subtrees state variable to the union of its previous 3143 value and the value indicated in the extension field. If exclu- 3144 dedSubtrees does not include a particular name type, the 3145 excluded_subtrees state variable is unchanged for that name type. 3147 (h) If the issuer and subject names are not identical: 3149 (1) If explicit_policy is not 0, decrement explicit_policy by 3150 1. 3152 (2) If policy_mapping is not 0, decrement policy_mapping by 1. 3154 (3) If inhibit_any-policy is not 0, decrement inhibit_any- pol- 3155 icy by 1. 3157 (i) If a policy constraints extension is included in the certifi- 3158 cate, modify the explicit_policy and policy_mapping state vari- 3159 ables as follows: 3161 (1) If requireExplicitPolicy is present and is less than 3162 explicit_policy, set explicit_policy to the value of requireEx- 3163 plicitPolicy. 3165 (2) If inhibitPolicyMapping is present and is less than 3166 policy_mapping, set policy_mapping to the value of inhibitPoli- 3167 cyMapping. 3169 (j) If the inhibitAnyPolicy extension is included in the certifi- 3170 cate and is less than inhibit_any-policy, set inhibit_any- policy 3171 to the value of inhibitAnyPolicy. 3173 (k) Verify that the certificate is a CA certificate (as specified 3174 in a basicConstraints extension or as verified out-of-band). 3176 (l) If the certificate was not self-issued, verify that 3177 max_path_length is greater than zero and decrement max_path_length 3178 by 1. 3180 (m) If pathLengthConstraint is present in the certificate and is 3181 less than max_path_length, set max_path_length to the value of 3182 pathLengthConstraint. 3184 (n) If a key usage extension is present and marked critical, 3185 verify that the keyCertSign bit is set. 3187 (o) Recognize and process any other critical extension present in 3188 the certificate. 3190 If check (a), (k), (l), (n) or (o) fails, the procedure terminates, 3191 returning a failure indication and an appropriate reason. 3193 If (a), (k), (l), (n) and (o) have completed successfully, increment 3194 i and perform the basic certificate processing specified in 6.1.2. 3196 6.1.5 Wrap-up procedure 3198 To complete the processing of the end entity certificate, perform the 3199 following steps for certificate n: 3201 (a) If certificate n was not self-issued and explicit_policy is 3202 not 0, decrement explicit_policy by 1. 3204 (b) If a policy constraints extension is included in the certifi- 3205 cate and requireExplicitPolicy is present and has a value of 0, 3206 set the explicit_policy state variable to 0. 3208 (c) Assign the certificate subjectPublicKey to working_public_key. 3210 (d) If the subjectPublicKeyInfo field of the certificate contains 3211 an algorithm field with non-null parameters, assign the parameters 3212 to the working_public_key_parameters variable. 3214 If the subjectPublicKeyInfo field of the certificate contains an 3215 algorithm field with null parameters or parameters are omitted, 3216 compare the certificate subjectPublicKey algorithm to the 3217 working_public_key_algorithm. If the certificate subjectPublicKey 3218 algorithm and the working_public_key_algorithm are different, set 3219 the working_public_key_parameters to null. 3221 (e) Assign the certificate subjectPublicKey algorithm to the 3222 working_public_key_algorithm variable. 3224 (f) Recognize and process any other critical extension present in 3225 the certificate n. 3227 (g) Calculate the intersection of the valid_policy_tree and the 3228 user_initial_policy_set, as follows: 3230 (i) If the valid_policy_tree is NULL, the intersection is NULL. 3232 (ii) If the valid_policy_tree is not NULL and the 3233 user_initial_policy_set is "any-policy", the intersection is 3234 the entire valid_policy_tree. 3236 (iii) If the valid_policy_tree is not NULL and the 3237 user_initial_policy_set is not "any-policy", calculate the 3238 intersection of the valid_policy_tree and the 3239 user_initial_policy_set as follows: 3240 1. Determine the set of policy nodes whose parent nodes have 3241 a valid_policy of "any-policy". This is the 3242 valid_policy_node_set. 3243 2. If the valid_policy of any node in the 3244 valid_policy_node_set is not in the user_initial_policy_set 3245 and is not "any-policy", delete this node and all its chil- 3246 dren. 3247 3. If there is a node in the valid_policy_tree of depth n-1 3248 or less without any child nodes, delete that node. Repeat 3249 this step until there are no nodes of depth n-1 or less 3250 without children. 3252 Upon completion of all steps, path processing has succeeded if the 3253 value of explicit_policy variable is greater than zero, or the 3254 valid_policy_tree is not NULL. 3256 6.1.6 Outputs 3258 If path processing succeeds, the procedure terminates, returning a 3259 success indication together with final value of the 3260 valid_policy_tree, the working_public_key, the 3261 working_public_key_algorithm, and the working_public_key_parameters. 3263 6.2 Extending Path Validation 3265 The path validation algorithm presented in 6.1 is based on several 3266 simplifying assumptions (e.g., a single trusted CA that starts all 3267 valid paths). This algorithm may be extended for cases where the 3268 assumptions do not hold. 3270 This procedure may be extended for multiple trusted CAs by providing 3271 a set of self-signed certificates to the validation module. In this 3272 case, a valid path could begin with any one of the self-signed certi- 3273 ficates. Limitations in the trust paths for any particular key may 3274 be incorporated into the self-signed certificate's extensions. In 3275 this way, the self-signed certificates permit the path validation 3276 module to automatically incorporate local security policy and 3277 requirements. 3279 It is also possible to specify an extended version of the above cer- 3280 tification path processing procedure which results in default 3281 behavior identical to the rules of PEM [RFC 1422]. In this extended 3282 version, additional inputs to the procedure are a list of one or more 3283 Policy Certification Authorities (PCAs) names and an indicator of the 3284 position in the certification path where the PCA is expected. At the 3285 nominated PCA position, the CA name is compared against this list. 3286 If a recognized PCA name is found, then a constraint of Subordina- 3287 teToCA is implicitly assumed for the remainder of the certification 3288 path and processing continues. If no valid PCA name is found, and if 3289 the certification path cannot be validated on the basis of identified 3290 policies, then the certification path is considered invalid. 3292 6.3 CRL Validation 3294 This section describes the steps necessary to determine if a certifi- 3295 cate is revoked or on hold status when CRLs are the revocation 3296 mechanism used by the certificate issuer. Conforming implementations 3297 of this specification are not required to implement this algorithm, 3298 but MUST be functionally equivalent to the external behavior result- 3299 ing from this procedure. Any algorithm may be used by a particular 3300 implementation so long as it derives the correct result. 3302 This algorithm defines a set of inputs, a set of state variables, and 3303 processing steps that are performed for each certificate in the path. 3305 6.3.1 Revocation Inputs 3307 To support revocation processing, the algorithm requires two inputs: 3309 (a) certificate: the algorithm requires the certificate serial 3310 number and issuer name to determine if a certificate is on a par- 3311 ticular CRL. The basicConstraints extension is used to determine 3312 whether the supplied certificate is associated with a CA or an 3313 end-entity. If present, the algorithm may use the cRLDistribu- 3314 tionsPoint and freshestCRL extensions to determine revocation 3315 status. 3317 (b) use-deltas: This boolean input determines if the delta needs 3318 to be checked if the CRL is still valid 3320 Note that implementations supporting legacy PKIs, such as RFC 1422 3321 and X.509 version 1, will need an additional input indicating 3322 whether the supplied certificate is associated with a CA or an 3323 end-entity. 3325 6.3.2 Initialization and Revocation State Variables 3327 To support CRL processing, the algorithm requires the following state 3328 variables: 3330 (a) reasons_mask: This variable contains the set of revocation 3331 reasons supported by the CRLs and delta CRLs processed so far. The 3332 legal members of the set are the possible values for reasonflags: 3333 unspecified; keyCompromise; caCompromise; affiliationChanged; 3334 superseded; cessationOfOperation; and certificateHold. The spe- 3335 cial value "all-reasons" is used to denote the set of all legal 3336 members. This variable is initialized to the empty set. 3338 (b) cert_status: This variable contains the status of the certifi- 3339 cate. Legal values are unspecified; keyCompromise; caCompromise; 3340 affiliationChanged; superseded; cessationOfOperation; and certifi- 3341 cateHold, the special value "UNREVOKED", or the special value 3342 "UNDETERMINED". This variable is initialized to the special value 3343 "UNREVOKED". 3345 (c) interim_reasons_mask: This contains the set of revocation rea- 3346 sons supported by the CRL or delta CRL currently being processed. 3348 Note: In some environments, it is not necessary to check all reason 3349 codes. For example, some envornments only are concerned with 3350 caCompromise and keyCompromise for CA certificates. This algorithnm 3351 checks all reason codes. Additional processing and state variables 3352 may be necessary to limit the checking to a subset of the reason 3353 codes. 3355 6.3.3 CRL Processing 3357 This algorithm begins by assuming the certificate is not revoked. 3358 The algorithm checks one or more CRLs until either the certificate 3359 status is determined to be revoked or sufficent CRLs have been 3360 checked to cover all reason codes. 3362 For each distribution point (DP) in the crl distribution points 3363 extension while ((reasons_mask is not "all-reasons") and (cert_status 3364 is UNREVOKED)) 3366 (1) locate the corresponding CRL in CRL cache, and perform the 3367 following verifications: 3369 (a) compute the interim_reasons_mask for this CRL as follows: 3371 1. if the CRL includes reasons and the DP includes reasons, 3372 then set interim_reasons_mask to the intersection of of rea- 3373 sons in the DP and reasons in CRL reasons extension. 3375 2. if the CRL includes reasons but the DP omits reasons, 3376 then set interim_reasons_mask to the value of CRL reasons. 3378 3. if the CRL omits reasons but the DP includes reasons, 3379 then set interim_reasons_mask to the value of DP reasons. 3381 4. if the CRL omits reasons and the DP omits reasons, then 3382 set interim_reasons_mask to the special value "all-reasons". 3384 Verify that interim_reasons_mask includes one or more reasons 3385 that is not included in the reasons_mask. 3387 (b) Verify the issuer of the CRL as follows: 3389 if the DP includes cRLIssuer, then verify that the CRL 3390 issuer matches cRLIssuer else verify that the CRL issuer 3391 matches the certificate issuer. 3393 (c) obtain and validate the certification path for the CRL 3394 issuer. 3396 (d) validate the signature on the CRL. 3398 (2) If each of the verifications (a) through (d) succeeds, then 3399 perform the following steps: 3401 (a) If the value of next update field is before the current- 3402 time, otain an appropriate delta CRL or discard the CRL. 3404 (b) If the user wants freshest available info AND the freshest 3405 CRL extension is present, check for a corresponding delta for 3406 this base. 3408 (c) If a delta was obtained in (a) or (b), verify that the 3409 delta CRL addresses the same set of certificates and the same 3410 set of reasons as the CRL. 3412 (d) Perform the checks in step 1 (b) and (c): 3414 1. obtain and validate the certification path for the delta 3415 issuer 3417 2. validate the signature on the delta CRL 3419 (e) If a delta CRL was obtained in (a) or (b), and the 3420 verifications (c) and (d) suceeded, combine the base and 3421 delta to form a complete CRL. 3423 (3) If steps and (1) and (2) succeed, then set reasons_mask to the 3424 union of reasons_mask and interim_reasons_mask 3425 (4) Search for the certificate on the CRL 3427 (a) search for the serial number on the CRL 3429 (b) if (a) succeeds, verify that (1) the CRL entry extension 3430 Certificate issuer is not present or (2) the issuer identified 3431 in the CRL entry extension Certificate issuer is the issuer of 3432 the certificate. 3434 (c) if (a) and (b) succeeded, set the cert_status variable as 3435 appropriate: 3437 1. if the reasons extension is present, set the cert_status 3438 variable to the value of the reasons extension 3440 2. if the reasons extension is not present, set the 3441 cert_status variable to the special value "not specified" 3443 if ((reasons_mask is "all-reasons") OR (if cert_status is not 3444 UNREVOKED) return cert_status 3446 If all CRLs named in the crl distribution points extension have 3447 been exhausted, and the reasons_mask is not "all-reasons" and the 3448 cert_status is still UNREVOKED, the verifier must obtain addi- 3449 tional CRLs. If the 3451 The verifier must repeat the process above with the additional 3452 CRLs not specified in a distribution point. 3454 If all CRLs are exhausted and the reasons_mask is not "all rea- 3455 sons" return the cert_status UNDETERMINED. 3457 7 References 3459 [RFC 791] J. Postel, "Internet Protocol", September 1981. 3461 [RFC 822] D. Crocker, "Standard for the format of ARPA Internet text 3462 messages", August 1982. 3464 [RFC 1034] P.V. Mockapetris, "Domain names - concepts and 3465 facilities", November 1987. 3467 [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic 3468 Mail: Part II: Certificate-Based Key Management," RFC 3469 1422, BBN Communications, February 1993. 3471 [RFC 1423] Balenson, D., "Privacy Enhancement for Internet Electronic 3472 Mail: Part III: Algorithms, Modes, and Identifiers," 3473 RFC 1423, Trusted Information Systems, February 1993. 3475 [RFC 1510] Kohl, J., and C. Neuman, "The Kerberos Network 3476 Authentication Service (V5)," RFC 1510, September 1993. 3478 [RFC 1519] V. Fuller, T. Li, J. Yu, and K. Varadhan. "Classless 3479 Inter-Domain Routing (CIDR): an Address Assignment and 3480 Aggregation Strategy", September 1993. 3482 [RFC 1738] Berners-Lee, T., Masinter L., and M. McCahill. 3483 "Uniform Resource Locators (URL)", RFC 1738, December 1994. 3485 [RFC 1778] Howes, T., Kille S., Yeong, W. and C. Robbins. "The 3486 String Representation of Standard Attribute Syntaxes," 3487 RFC 1778, March 1995. 3489 [RFC 1883] S. Deering and R. Hinden. "Internet Protocol, Version 6 3490 (IPv6) Specification", December 1995. 3492 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 3493 Requirement Levels", March 1997. 3495 [RFC 2247] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. 3496 Sataluri. "Using Domains in LDAP/X.500 Distinguished Names", 3497 RFC 2247, January 1998. 3499 [RFC 2277] H. Alvestrand, "IETF Policy on Character Sets and 3500 Languages", January 1998. 3502 [RFC 2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646", 3503 January 1998. 3505 [RFC 2560] Myers, M., Ankney R., Malpani A., Galperin S., and 3506 C. Adams, "Online Certificate Status Protocal - OCSP", 3507 June 1999. 3509 [SDN.701] SDN.701, "Message Security Protocol 4.0", Revision A 3510 1997-02-06. 3512 [X.208] CCITT Recommendation X.208: Specification of Abstract 3513 Syntax Notation One (ASN.1), 1988. 3515 [X.501] ITU-T Recommendation X.501: Information 3516 Technology - Open Systems Interconnection - The 3517 Directory: Models, 1993. 3519 [X.509] ITU-T Recommendation X.509 (1997 E): Information 3520 Technology - Open Systems Interconnection - The 3521 Directory: Authentication Framework, June 1997. 3523 [X.520] ITU-T Recommendation X.520: Information 3524 Technology - Open Systems Interconnection - The 3525 Directory: Selected Attribute Types, 1993. 3527 [X9.55] ANSI X9.55-1995, Public Key Cryptography For The Financial 3528 Services Industry: Extensions To Public Key Certificates 3529 And Certificate Revocation Lists, 8 December, 1995. 3531 [PKINIT] Tung, B., Neuman C., Hur M., Medvinsky A., Medvinsky S., 3532 Wray J., and J. Trostle, "Public Key Cryptography for 3533 Initial Authentciaion in Kerberos," 3534 draft-ietf-cat-kerberos-pk-init-11.txt, March 15, 2000. 3536 [PKIX ALGS] Bassham, L., Housley, R., and W. Polk, "Internet X.509 3537 Public Key Infrastructure Representation of Public Keys 3538 and Digital Signatures," 3539 draft-ietf-pkix-ipki-pkalgs-00.txt, July 14, 2000. 3541 8 Intellectual Property Rights 3543 The IETF has been notified of intellectual property rights claimed in 3544 regard to some or all of the specification contained in this docu- 3545 ment. For more information consult the online list of claimed 3546 rights. 3548 The IETF takes no position regarding the validity or scope of any 3549 intellectual property or other rights that might be claimed to per- 3550 tain to the implementation or use of the technology described in this 3551 document or the extent to which any license under such rights might 3552 or might not be available; neither does it represent that it has made 3553 any effort to identify any such rights. Information on the IETF's 3554 procedures with respect to rights in standards-track and standards- 3555 related documentation can be found in BCP-11. Copies of claims of 3556 rights made available for publication and any assurances of licenses 3557 to be made available, or the result of an attempt made to obtain a 3558 general license or permission for the use of such proprietary rights 3559 by implementors or users of this specification can be obtained from 3560 the IETF Secretariat. 3562 9 Security Considerations 3564 The majority of this specification is devoted to the format and con- 3565 tent of certificates and CRLs. Since certificates and CRLs are digi- 3566 tally signed, no additional integrity service is necessary. Neither 3567 certificates nor CRLs need be kept secret, and unrestricted and 3568 anonymous access to certificates and CRLs has no security 3569 implications. 3571 However, security factors outside the scope of this specification 3572 will affect the assurance provided to certificate users. This sec- 3573 tion highlights critical issues that should be considered by imple- 3574 mentors, administrators, and users. 3576 The procedures performed by CAs and RAs to validate the binding of 3577 the subject's identity of their public key greatly affect the 3578 assurance that should be placed in the certificate. Relying parties 3579 may wish to review the CA's certificate practice statement. This may 3580 be particularly important when issuing certificates to other CAs. 3582 The use of a single key pair for both signature and other purposes is 3583 strongly discouraged. Use of separate key pairs for signature and key 3584 management provides several benefits to the users. The ramifications 3585 associated with loss or disclosure of a signature key are different 3586 from loss or disclosure of a key management key. Using separate key 3587 pairs permits a balanced and flexible response. Similarly, different 3588 validity periods or key lengths for each key pair may be appropriate 3589 in some application environments. Unfortunately, some legacy applica- 3590 tions (e.g., SSL) use a single key pair for signature and key manage- 3591 ment. 3593 The protection afforded private keys is a critical factor in main- 3594 taining security. On a small scale, failure of users to protect 3595 their private keys will permit an attacker to masquerade as them, or 3596 decrypt their personal information. On a larger scale, compromise of 3597 a CA's private signing key may have a catastrophic effect. If an 3598 attacker obtains the private key unnoticed, the attacker may issue 3599 bogus certificates and CRLs. Existence of bogus certificates and 3600 CRLs will undermine confidence in the system. If the compromise is 3601 detected, all certificates issued to the CA shall be revoked, 3602 preventing services between its users and users of other CAs. 3603 Rebuilding after such a compromise will be problematic, so CAs are 3604 advised to implement a combination of strong technical measures 3605 (e.g., tamper-resistant cryptographic modules) and appropriate 3606 management procedures (e.g., separation of duties) to avoid such an 3607 incident. 3609 Loss of a CA's private signing key may also be problematic. The CA 3610 would not be able to produce CRLs or perform normal key rollover. 3611 CAs are advised to maintain secure backup for signing keys. The 3612 security of the key backup procedures is a critical factor in avoid- 3613 ing key compromise. 3615 The availability and freshness of revocation information will affect 3616 the degree of assurance that should be placed in a certificate. 3618 While certificates expire naturally, events may occur during its 3619 natural lifetime which negate the binding between the subject and 3620 public key. If revocation information is untimely or unavailable, 3621 the assurance associated with the binding is clearly reduced. Simi- 3622 larly, implementations of the Path Validation mechanism described in 3623 section 6 that omit revocation checking provide less assurance than 3624 those that support it. 3626 The path validation algorithm depends on the certain knowledge of the 3627 public keys (and other information) about one or more trusted CAs. 3628 The decision to trust a CA is an important decision as it ultimately 3629 determines the trust afforded a certificate. The authenticated dis- 3630 tribution of trusted CA public keys (usually in the form of a "self- 3631 signed" certificate) is a security critical out of band process that 3632 is beyond the scope of this specification. 3634 In addition, where a key compromise or CA failure occurs for a 3635 trusted CA, the user will need to modify the information provided to 3636 the path validation routine. Selection of too many trusted CAs will 3637 make the trusted CA information difficult to maintain. On the other 3638 hand, selection of only one trusted CA may limit users to a closed 3639 community of users until a global PKI emerges. 3641 The quality of implementations that process certificates may also 3642 affect the degree of assurance provided. The path validation algo- 3643 rithm described in section 6 relies upon the integrity of the trusted 3644 CA information, and especially the integrity of the public keys asso- 3645 ciated with the trusted CAs. By substituting public keys for which 3646 an attacker has the private key, an attacker could trick the user 3647 into accepting false certificates. 3649 The binding between a key and certificate subject cannot be stronger 3650 than the cryptographic module implementation and algorithms used to 3651 generate the signature. Short key lengths or weak hash algorithms 3652 will limit the utility of a certificate. CAs are encouraged to note 3653 advances in cryptology so they can employ strong cryptographic tech- 3654 niques. In addition, CAs should decline to issue certificates to CAs 3655 or end entities that generate weak signatures. 3657 Inconsistent application of name comparison rules may result in 3658 acceptance of invalid X.509 certification paths, or rejection of 3659 valid ones. The X.500 series of specifications defines rules for 3660 comparing distinguished names require comparison of strings without 3661 regard to case, character set, multi-character white space substring, 3662 or leading and trailing white space. This specification relaxes 3663 these requirements, requiring support for binary comparison at a 3664 minimum. 3666 CAs shall encode the distinguished name in the subject field of a CA 3667 certificate identically to the distinguished name in the issuer field 3668 in certificates issued by the latter CA. If CAs use different encod- 3669 ings, implementations of this specification may fail to recognize 3670 name chains for paths that include this certificate. As a conse- 3671 quence, valid paths could be rejected. 3673 In addition, name constraints for distinguished names shall be stated 3674 identically to the encoding used in the subject field or subjectAlt- 3675 Name extension. If not, (1) name constraints stated as excludedSub- 3676 Trees will not match and invalid paths will be accepted and (2) name 3677 constraints expressed as permittedSubtrees will not match and valid 3678 paths will be rejected. To avoid acceptance of invalid paths, CAs 3679 should state name constraints for distinguished names as permit- 3680 tedSubtrees where ever possible. 3682 Appendix A. Psuedo-ASN.1 Structures and OIDs 3684 This section describes data objects used by conforming PKI components 3685 in an "ASN.1-like" syntax. This syntax is a hybrid of the 1988 and 3686 1993 ASN.1 syntaxes. The 1988 ASN.1 syntax is augmented with 1993 3687 UNIVERSAL Types UniversalString, BMPString and UTF8String. 3689 The ASN.1 syntax does not permit the inclusion of type statements in 3690 the ASN.1 module, and the 1993 ASN.1 standard does not permit use of 3691 the new UNIVERSAL types in modules using the 1988 syntax. As a 3692 result, this module does not conform to either version of the ASN.1 3693 standard. 3695 This appendix may be converted into 1988 ASN.1 by replacing the 3696 defintions for the UNIVERSAL Types with the 1988 catch-all "ANY". 3698 A.1 Explicitly Tagged Module, 1988 Syntax 3700 PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) 3701 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)} 3703 DEFINITIONS EXPLICIT TAGS ::= 3705 BEGIN 3707 -- EXPORTS ALL -- 3709 -- IMPORTS NONE -- 3711 -- UNIVERSAL Types defined in '93 and '98 ASN.1 3712 -- but required by this specification 3714 UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING 3715 -- UniversalString is defined in ASN.1:1993 3717 BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING 3718 -- BMPString is the subtype of UniversalString and models 3719 -- the Basic Multilingual Plane of ISO/IEC/ITU 10646-1 3721 UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 3722 -- The content of this type conforms to RFC 2279. 3724 -- 3725 -- PKIX specific OIDs 3727 id-pkix OBJECT IDENTIFIER ::= 3728 { iso(1) identified-organization(3) dod(6) internet(1) 3729 security(5) mechanisms(5) pkix(7) } 3730 -- PKIX arcs 3732 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 3733 -- arc for private certificate extensions 3734 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 3735 -- arc for policy qualifier types 3736 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 3737 -- arc for extended key purpose OIDS 3738 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 3739 -- arc for access descriptors 3741 -- policyQualifierIds for Internet policy qualifiers 3743 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 3744 -- OID for CPS qualifier 3745 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 3746 -- OID for user notice qualifier 3748 -- access descriptor definitions 3750 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 3751 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 3753 -- attribute data types -- 3755 Attribute ::= SEQUENCE { 3756 type AttributeType, 3757 values SET OF AttributeValue 3758 -- at least one value is required -- } 3760 AttributeType ::= OBJECT IDENTIFIER 3762 AttributeValue ::= ANY 3764 AttributeTypeAndValue ::= SEQUENCE { 3765 type AttributeType, 3766 value AttributeValue } 3768 -- suggested naming attributes: Definition of the following 3769 -- information object set may be augmented to meet local 3770 -- requirements. Note that deleting members of the set may 3771 -- prevent interoperability with conforming implementations. 3772 -- presented in pairs: the AttributeType followed by the 3773 -- type definition for the corresponding AttributeValue 3775 --Arc for standard naming attributes 3776 id-at OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 4} 3777 -- Attributes of type NameDirectoryString 3778 id-at-name AttributeType ::= {id-at 41} 3779 id-at-surname AttributeType ::= {id-at 4} 3780 id-at-givenName AttributeType ::= {id-at 42} 3781 id-at-initials AttributeType ::= {id-at 43} 3782 id-at-generationQualifier AttributeType ::= {id-at 44} 3784 X520name ::= CHOICE { 3785 teletexString TeletexString (SIZE (1..ub-name)), 3786 printableString PrintableString (SIZE (1..ub-name)), 3787 universalString UniversalString (SIZE (1..ub-name)), 3788 utf8String UTF8String (SIZE (1..ub-name)), 3789 bmpString BMPString (SIZE(1..ub-name)) } 3791 -- 3793 id-at-commonName AttributeType ::= {id-at 3} 3795 X520CommonName ::= CHOICE { 3796 teletexString TeletexString (SIZE (1..ub-common-name)), 3797 printableString PrintableString (SIZE (1..ub-common-name)), 3798 universalString UniversalString (SIZE (1..ub-common-name)), 3799 utf8String UTF8String (SIZE (1..ub-common-name)), 3800 bmpString BMPString (SIZE(1..ub-common-name)) } 3802 -- 3804 id-at-localityName AttributeType ::= {id-at 7} 3806 X520LocalityName ::= CHOICE { 3807 teletexString TeletexString (SIZE (1..ub-locality-name)), 3808 printableString PrintableString (SIZE (1..ub-locality-name)), 3809 universalString UniversalString (SIZE (1..ub-locality-name)), 3810 utf8String UTF8String (SIZE (1..ub-locality-name)), 3811 bmpString BMPString (SIZE(1..ub-locality-name)) } 3813 -- 3815 id-at-stateOrProvinceName AttributeType ::= {id-at 8} 3817 X520StateOrProvinceName ::= CHOICE { 3818 teletexString TeletexString (SIZE (1..ub-state-name)), 3819 printableString PrintableString (SIZE (1..ub-state-name)), 3820 universalString UniversalString (SIZE (1..ub-state-name)), 3821 utf8String UTF8String (SIZE (1..ub-state-name)), 3822 bmpString BMPString (SIZE(1..ub-state-name)) } 3824 -- 3826 id-at-organizationName AttributeType ::= {id-at 10} 3828 X520OrganizationName ::= CHOICE { 3829 teletexString TeletexString (SIZE (1..ub-organization-name)), 3830 printableString PrintableString (SIZE (1..ub-organization-name)), 3831 universalString UniversalString (SIZE (1..ub-organization-name)), 3832 utf8String UTF8String (SIZE (1..ub-organization-name)), 3833 bmpString BMPString (SIZE(1..ub-organization-name)) } 3835 -- 3837 id-at-organizationalUnitName AttributeType ::= {id-at 11} 3839 X520OrganizationalUnitName ::= CHOICE { 3840 teletexString TeletexString (SIZE (1..ub-organizational-unit-name)), 3841 printableString PrintableString 3842 (SIZE (1..ub-organizational-unit-name)), 3843 universalString UniversalString 3844 (SIZE (1..ub-organizational-unit-name)), 3845 utf8String UTF8String (SIZE (1..ub-organizational-unit-name)), 3846 bmpString BMPString (SIZE(1..ub-organizational-unit-name)) } 3848 -- 3850 id-at-title AttributeType ::= {id-at 12} 3852 X520Title ::= CHOICE { 3853 teletexString TeletexString (SIZE (1..ub-title)), 3854 printableString PrintableString (SIZE (1..ub-title)), 3855 universalString UniversalString (SIZE (1..ub-title)), 3856 utf8String UTF8String (SIZE (1..ub-title)), 3857 bmpString BMPString (SIZE(1..ub-title)) } 3859 -- 3861 id-at-dnQualifier AttributeType ::= {id-at 46} 3862 X520dnQualifier ::= PrintableString 3864 id-at-countryName AttributeType ::= {id-at 6} 3865 X520countryName ::= PrintableString (SIZE (2)) -- IS 3166 codes 3867 id-at-serialNumber AttributeType ::= { id-at 5 } 3868 X520SerialNumber PrintableString (SIZE (1..ub-serial-number)) 3870 -- domaincomponent and identifier from RFC 2247 3872 id-domainComponent OBJECT IDENTIFIER := 3873 { 0 9 2342 19200300 100 1 25 } 3875 id-domainComponent AttributeType ::= id-domainComponent 3876 domainComponent ::= IA5String 3878 -- Legacy attributes 3880 pkcs-9 OBJECT IDENTIFIER ::= 3881 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 } 3883 emailAddress AttributeType ::= { pkcs-9 1 } 3885 Pkcs9email ::= IA5String (SIZE (1..ub-emailaddress-length)) 3887 -- naming data types -- 3889 Name ::= CHOICE { -- only one possibility for now -- 3890 rdnSequence RDNSequence } 3892 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 3894 DistinguishedName ::= RDNSequence 3896 RelativeDistinguishedName ::= 3897 SET SIZE (1 .. MAX) OF AttributeTypeAndValue 3899 -- Directory string type -- 3901 DirectoryString ::= CHOICE { 3902 teletexString TeletexString (SIZE (1..MAX)), 3903 printableString PrintableString (SIZE (1..MAX)), 3904 universalString UniversalString (SIZE (1..MAX)), 3905 utf8String UTF8String (SIZE (1..MAX)), 3906 bmpString BMPString (SIZE(1..MAX)) } 3908 -- certificate and CRL specific structures begin here 3910 Certificate ::= SEQUENCE { 3911 tbsCertificate TBSCertificate, 3912 signatureAlgorithm AlgorithmIdentifier, 3913 signature BIT STRING } 3915 TBSCertificate ::= SEQUENCE { 3916 version [0] Version DEFAULT v1, 3917 serialNumber CertificateSerialNumber, 3918 signature AlgorithmIdentifier, 3919 issuer Name, 3920 validity Validity, 3921 subject Name, 3922 subjectPublicKeyInfo SubjectPublicKeyInfo, 3923 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 3924 -- If present, version shall be v2 or v3 3925 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 3926 -- If present, version shall be v2 or v3 3927 extensions [3] Extensions OPTIONAL 3928 -- If present, version shall be v3 -- } 3930 Version ::= INTEGER { v1(0), v2(1), v3(2) } 3932 CertificateSerialNumber ::= INTEGER 3934 Validity ::= SEQUENCE { 3935 notBefore Time, 3936 notAfter Time } 3938 Time ::= CHOICE { 3939 utcTime UTCTime, 3940 generalTime GeneralizedTime } 3942 UniqueIdentifier ::= BIT STRING 3944 SubjectPublicKeyInfo ::= SEQUENCE { 3945 algorithm AlgorithmIdentifier, 3946 subjectPublicKey BIT STRING } 3948 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 3950 Extension ::= SEQUENCE { 3951 extnID OBJECT IDENTIFIER, 3952 critical BOOLEAN DEFAULT FALSE, 3953 extnValue OCTET STRING } 3955 -- CRL structures 3957 CertificateList ::= SEQUENCE { 3958 tbsCertList TBSCertList, 3959 signatureAlgorithm AlgorithmIdentifier, 3960 signature BIT STRING } 3962 TBSCertList ::= SEQUENCE { 3963 version Version OPTIONAL, 3964 -- if present, shall be v2 3965 signature AlgorithmIdentifier, 3966 issuer Name, 3967 thisUpdate Time, 3968 nextUpdate Time OPTIONAL, 3969 revokedCertificates SEQUENCE OF SEQUENCE { 3970 userCertificate CertificateSerialNumber, 3971 revocationDate Time, 3972 crlEntryExtensions Extensions OPTIONAL 3973 -- if present, shall be v2 3974 } OPTIONAL, 3975 crlExtensions [0] Extensions OPTIONAL 3976 -- if present, shall be v2 -- } 3978 -- Version, Time, CertificateSerialNumber, and Extensions were 3979 -- defined earlier for use in the certificate structure 3981 AlgorithmIdentifier ::= SEQUENCE { 3982 algorithm OBJECT IDENTIFIER, 3983 parameters ANY DEFINED BY algorithm OPTIONAL } 3984 -- contains a value of the type 3985 -- registered for use with the 3986 -- algorithm object identifier value 3988 -- x400 address syntax starts here 3989 -- OR Names 3991 ORAddress ::= SEQUENCE { 3992 built-in-standard-attributes BuiltInStandardAttributes, 3993 built-in-domain-defined-attributes 3994 BuiltInDomainDefinedAttributes OPTIONAL, 3995 -- see also teletex-domain-defined-attributes 3996 extension-attributes ExtensionAttributes OPTIONAL } 3997 -- The OR-address is semantically absent from the OR-name if the 3998 -- built-in-standard-attribute sequence is empty and the 3999 -- built-in-domain-defined-attributes and extension-attributes are 4000 -- both omitted. 4002 -- Built-in Standard Attributes 4004 BuiltInStandardAttributes ::= SEQUENCE { 4005 country-name CountryName OPTIONAL, 4006 administration-domain-name AdministrationDomainName OPTIONAL, 4007 network-address [0] NetworkAddress OPTIONAL, 4008 -- see also extended-network-address 4009 terminal-identifier [1] TerminalIdentifier OPTIONAL, 4010 private-domain-name [2] PrivateDomainName OPTIONAL, 4011 organization-name [3] OrganizationName OPTIONAL, 4012 -- see also teletex-organization-name 4013 numeric-user-identifier [4] NumericUserIdentifier OPTIONAL, 4014 personal-name [5] PersonalName OPTIONAL, 4015 -- see also teletex-personal-name 4016 organizational-unit-names [6] OrganizationalUnitNames OPTIONAL 4017 -- see also teletex-organizational-unit-names -- } 4019 CountryName ::= [APPLICATION 1] CHOICE { 4020 x121-dcc-code NumericString 4021 (SIZE (ub-country-name-numeric-length)), 4022 iso-3166-alpha2-code PrintableString 4023 (SIZE (ub-country-name-alpha-length)) } 4025 AdministrationDomainName ::= [APPLICATION 2] CHOICE { 4026 numeric NumericString (SIZE (0..ub-domain-name-length)), 4027 printable PrintableString (SIZE (0..ub-domain-name-length)) } 4029 NetworkAddress ::= X121Address -- see also extended-network-address 4031 X121Address ::= NumericString (SIZE (1..ub-x121-address-length)) 4033 TerminalIdentifier ::= PrintableString (SIZE (1..ub-terminal-id-length)) 4035 PrivateDomainName ::= CHOICE { 4036 numeric NumericString (SIZE (1..ub-domain-name-length)), 4037 printable PrintableString (SIZE (1..ub-domain-name-length)) } 4039 OrganizationName ::= PrintableString 4040 (SIZE (1..ub-organization-name-length)) 4041 -- see also teletex-organization-name 4043 NumericUserIdentifier ::= NumericString 4044 (SIZE (1..ub-numeric-user-id-length)) 4046 PersonalName ::= SET { 4047 surname [0] PrintableString (SIZE (1..ub-surname-length)), 4048 given-name [1] PrintableString 4049 (SIZE (1..ub-given-name-length)) OPTIONAL, 4050 initials [2] PrintableString (SIZE (1..ub-initials-length)) OPTIONAL, 4051 generation-qualifier [3] PrintableString 4052 (SIZE (1..ub-generation-qualifier-length)) OPTIONAL } 4053 -- see also teletex-personal-name 4055 OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units) 4056 OF OrganizationalUnitName 4057 -- see also teletex-organizational-unit-names 4059 OrganizationalUnitName ::= PrintableString (SIZE 4060 (1..ub-organizational-unit-name-length)) 4062 -- Built-in Domain-defined Attributes 4063 BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE 4064 (1..ub-domain-defined-attributes) OF 4065 BuiltInDomainDefinedAttribute 4067 BuiltInDomainDefinedAttribute ::= SEQUENCE { 4068 type PrintableString (SIZE 4069 (1..ub-domain-defined-attribute-type-length)), 4070 value PrintableString (SIZE 4071 (1..ub-domain-defined-attribute-value-length))} 4073 -- Extension Attributes 4075 ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF 4076 ExtensionAttribute 4078 ExtensionAttribute ::= SEQUENCE { 4079 extension-attribute-type [0] INTEGER (0..ub-extension-attributes), 4080 extension-attribute-value [1] 4081 ANY DEFINED BY extension-attribute-type } 4083 -- Extension types and attribute values 4084 -- 4086 common-name INTEGER ::= 1 4088 CommonName ::= PrintableString (SIZE (1..ub-common-name-length)) 4090 teletex-common-name INTEGER ::= 2 4092 TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length)) 4094 teletex-organization-name INTEGER ::= 3 4096 TeletexOrganizationName ::= 4097 TeletexString (SIZE (1..ub-organization-name-length)) 4099 teletex-personal-name INTEGER ::= 4 4101 TeletexPersonalName ::= SET { 4102 surname [0] TeletexString (SIZE (1..ub-surname-length)), 4103 given-name [1] TeletexString 4104 (SIZE (1..ub-given-name-length)) OPTIONAL, 4105 initials [2] TeletexString (SIZE (1..ub-initials-length)) OPTIONAL, 4106 generation-qualifier [3] TeletexString (SIZE 4107 (1..ub-generation-qualifier-length)) OPTIONAL } 4109 teletex-organizational-unit-names INTEGER ::= 5 4110 TeletexOrganizationalUnitNames ::= SEQUENCE SIZE 4111 (1..ub-organizational-units) OF TeletexOrganizationalUnitName 4113 TeletexOrganizationalUnitName ::= TeletexString 4114 (SIZE (1..ub-organizational-unit-name-length)) 4116 pds-name INTEGER ::= 7 4118 PDSName ::= PrintableString (SIZE (1..ub-pds-name-length)) 4120 physical-delivery-country-name INTEGER ::= 8 4122 PhysicalDeliveryCountryName ::= CHOICE { 4123 x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)), 4124 iso-3166-alpha2-code PrintableString 4125 (SIZE (ub-country-name-alpha-length)) } 4127 postal-code INTEGER ::= 9 4129 PostalCode ::= CHOICE { 4130 numeric-code NumericString (SIZE (1..ub-postal-code-length)), 4131 printable-code PrintableString (SIZE (1..ub-postal-code-length)) } 4133 physical-delivery-office-name INTEGER ::= 10 4135 PhysicalDeliveryOfficeName ::= PDSParameter 4137 physical-delivery-office-number INTEGER ::= 11 4139 PhysicalDeliveryOfficeNumber ::= PDSParameter 4141 extension-OR-address-components INTEGER ::= 12 4143 ExtensionORAddressComponents ::= PDSParameter 4145 physical-delivery-personal-name INTEGER ::= 13 4147 PhysicalDeliveryPersonalName ::= PDSParameter 4149 physical-delivery-organization-name INTEGER ::= 14 4151 PhysicalDeliveryOrganizationName ::= PDSParameter 4153 extension-physical-delivery-address-components INTEGER ::= 15 4155 ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter 4157 unformatted-postal-address INTEGER ::= 16 4158 UnformattedPostalAddress ::= SET { 4159 printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) OF 4160 PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL, 4161 teletex-string TeletexString 4162 (SIZE (1..ub-unformatted-address-length)) OPTIONAL } 4164 street-address INTEGER ::= 17 4166 StreetAddress ::= PDSParameter 4168 post-office-box-address INTEGER ::= 18 4170 PostOfficeBoxAddress ::= PDSParameter 4172 poste-restante-address INTEGER ::= 19 4174 PosteRestanteAddress ::= PDSParameter 4176 unique-postal-name INTEGER ::= 20 4178 UniquePostalName ::= PDSParameter 4180 local-postal-attributes INTEGER ::= 21 4182 LocalPostalAttributes ::= PDSParameter 4184 PDSParameter ::= SET { 4185 printable-string PrintableString 4186 (SIZE(1..ub-pds-parameter-length)) OPTIONAL, 4187 teletex-string TeletexString 4188 (SIZE(1..ub-pds-parameter-length)) OPTIONAL } 4190 extended-network-address INTEGER ::= 22 4192 ExtendedNetworkAddress ::= CHOICE { 4193 e163-4-address SEQUENCE { 4194 number [0] NumericString (SIZE (1..ub-e163-4-number-length)), 4195 sub-address [1] NumericString 4196 (SIZE (1..ub-e163-4-sub-address-length)) OPTIONAL }, 4197 psap-address [0] PresentationAddress } 4199 PresentationAddress ::= SEQUENCE { 4200 pSelector [0] EXPLICIT OCTET STRING OPTIONAL, 4201 sSelector [1] EXPLICIT OCTET STRING OPTIONAL, 4202 tSelector [2] EXPLICIT OCTET STRING OPTIONAL, 4203 nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING } 4205 terminal-type INTEGER ::= 23 4206 TerminalType ::= INTEGER { 4207 telex (3), 4208 teletex (4), 4209 g3-facsimile (5), 4210 g4-facsimile (6), 4211 ia5-terminal (7), 4212 videotex (8) } (0..ub-integer-options) 4214 -- Extension Domain-defined Attributes 4216 teletex-domain-defined-attributes INTEGER ::= 6 4218 TeletexDomainDefinedAttributes ::= SEQUENCE SIZE 4219 (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute 4221 TeletexDomainDefinedAttribute ::= SEQUENCE { 4222 type TeletexString 4223 (SIZE (1..ub-domain-defined-attribute-type-length)), 4224 value TeletexString 4225 (SIZE (1..ub-domain-defined-attribute-value-length)) } 4227 -- specifications of Upper Bounds shall be regarded as mandatory 4228 -- from Annex B of ITU-T X.411 Reference Definition of MTS Parameter 4229 -- Upper Bounds 4231 -- Upper Bounds 4232 ub-name INTEGER ::= 32768 4233 ub-common-name INTEGER ::= 64 4234 ub-locality-name INTEGER ::= 128 4235 ub-state-name INTEGER ::= 128 4236 ub-organization-name INTEGER ::= 64 4237 ub-organizational-unit-name INTEGER ::= 64 4238 ub-title INTEGER ::= 64 4239 ub-serialNumber INTEGER ::= 64 4240 ub-match INTEGER ::= 128 4242 ub-emailaddress-length INTEGER ::= 128 4244 ub-common-name-length INTEGER ::= 64 4245 ub-country-name-alpha-length INTEGER ::= 2 4246 ub-country-name-numeric-length INTEGER ::= 3 4247 ub-domain-defined-attributes INTEGER ::= 4 4248 ub-domain-defined-attribute-type-length INTEGER ::= 8 4249 ub-domain-defined-attribute-value-length INTEGER ::= 128 4250 ub-domain-name-length INTEGER ::= 16 4251 ub-extension-attributes INTEGER ::= 256 4252 ub-e163-4-number-length INTEGER ::= 15 4253 ub-e163-4-sub-address-length INTEGER ::= 40 4254 ub-generation-qualifier-length INTEGER ::= 3 4255 ub-given-name-length INTEGER ::= 16 4256 ub-initials-length INTEGER ::= 5 4257 ub-integer-options INTEGER ::= 256 4258 ub-numeric-user-id-length INTEGER ::= 32 4259 ub-organization-name-length INTEGER ::= 64 4260 ub-organizational-unit-name-length INTEGER ::= 32 4261 ub-organizational-units INTEGER ::= 4 4262 ub-pds-name-length INTEGER ::= 16 4263 ub-pds-parameter-length INTEGER ::= 30 4264 ub-pds-physical-address-lines INTEGER ::= 6 4265 ub-postal-code-length INTEGER ::= 16 4266 ub-surname-length INTEGER ::= 40 4267 ub-terminal-id-length INTEGER ::= 24 4268 ub-unformatted-address-length INTEGER ::= 180 4269 ub-x121-address-length INTEGER ::= 16 4271 -- Note - upper bounds on string types, such as TeletexString, are 4272 -- measured in characters. Excepting PrintableString or IA5String, a 4273 -- significantly greater number of octets will be required to hold 4274 -- such a value. As a minimum, 16 octets, or twice the specified upper 4275 -- bound, whichever is the larger, should be allowed for TeletexString. 4276 -- For UTF8String or UniversalString at least four times the upper 4277 -- bound should be allowed. 4279 END 4280 A.2 Implicitly Tagged Module, 1988 Syntax 4282 PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) 4283 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)} 4285 DEFINITIONS IMPLICIT TAGS ::= 4287 BEGIN 4289 -- EXPORTS ALL -- 4291 IMPORTS 4292 id-pkix, id-pe, id-qt, id-kp, id-qt-unotice, id-qt-cps, 4293 id-ad, id-ad-ocsp, id-ad-caIssuers, 4294 -- delete following line if "new" types are supported -- 4295 BMPString, UniversalString, UTF8String, -- end "new" types 4296 ORAddress, Name, RelativeDistinguishedName, 4297 CertificateSerialNumber, 4298 CertificateList, AlgorithmIdentifier, ub-name, 4299 Attribute, DirectoryString 4300 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 4301 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 4302 id-mod(0) id-pkix1-explicit(1)}; 4304 -- ISO arc for standard certificate and CRL extensions 4306 id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 4308 -- authority key identifier OID and syntax 4310 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 4312 AuthorityKeyIdentifier ::= SEQUENCE { 4313 keyIdentifier [0] KeyIdentifier OPTIONAL, 4314 authorityCertIssuer [1] GeneralNames OPTIONAL, 4315 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 4316 -- authorityCertIssuer and authorityCertSerialNumber shall both 4317 -- be present or both be absent 4319 KeyIdentifier ::= OCTET STRING 4321 -- subject key identifier OID and syntax 4323 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 4325 SubjectKeyIdentifier ::= KeyIdentifier 4326 -- key usage extension OID and syntax 4328 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 4330 KeyUsage ::= BIT STRING { 4331 digitalSignature (0), 4332 nonRepudiation (1), 4333 keyEncipherment (2), 4334 dataEncipherment (3), 4335 keyAgreement (4), 4336 keyCertSign (5), 4337 cRLSign (6), 4338 encipherOnly (7), 4339 decipherOnly (8) } 4341 -- private key usage period extension OID and syntax 4343 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 4345 PrivateKeyUsagePeriod ::= SEQUENCE { 4346 notBefore [0] GeneralizedTime OPTIONAL, 4347 notAfter [1] GeneralizedTime OPTIONAL } 4348 -- either notBefore or notAfter shall be present 4350 -- certificate policies extension OID and syntax 4352 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 4354 anyPolicy OBJECT IDENTIFIER ::= {id-ce-certificate-policies 0} 4356 CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 4358 PolicyInformation ::= SEQUENCE { 4359 policyIdentifier CertPolicyId, 4360 policyQualifiers SEQUENCE SIZE (1..MAX) OF 4361 PolicyQualifierInfo OPTIONAL } 4363 CertPolicyId ::= OBJECT IDENTIFIER 4365 PolicyQualifierInfo ::= SEQUENCE { 4366 policyQualifierId PolicyQualifierId, 4367 qualifier ANY DEFINED BY policyQualifierId } 4369 -- Implementations that recognize additional policy qualifiers shall 4370 -- augment the following definition for PolicyQualifierId 4372 PolicyQualifierId ::= 4373 OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) 4375 -- CPS pointer qualifier 4377 CPSuri ::= IA5String 4379 -- user notice qualifier 4381 UserNotice ::= SEQUENCE { 4382 noticeRef NoticeReference OPTIONAL, 4383 explicitText DisplayText OPTIONAL} 4385 NoticeReference ::= SEQUENCE { 4386 organization DisplayText, 4387 noticeNumbers SEQUENCE OF INTEGER } 4389 DisplayText ::= CHOICE { 4390 ia5String IA5String (SIZE (1..200)), 4391 visibleString VisibleString (SIZE (1..200)), 4392 bmpString BMPString (SIZE (1..200)), 4393 utf8String UTF8String (SIZE (1..200)) } 4395 -- policy mapping extension OID and syntax 4397 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 4399 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 4400 issuerDomainPolicy CertPolicyId, 4401 subjectDomainPolicy CertPolicyId } 4403 -- subject alternative name extension OID and syntax 4405 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 4407 SubjectAltName ::= GeneralNames 4409 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 4411 GeneralName ::= CHOICE { 4412 otherName [0] AnotherName, 4413 rfc822Name [1] IA5String, 4414 dNSName [2] IA5String, 4415 x400Address [3] ORAddress, 4416 directoryName [4] Name, 4417 ediPartyName [5] EDIPartyName, 4418 uniformResourceIdentifier [6] IA5String, 4419 iPAddress [7] OCTET STRING, 4420 registeredID [8] OBJECT IDENTIFIER } 4422 -- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as 4423 -- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax 4425 AnotherName ::= SEQUENCE { 4426 type-id OBJECT IDENTIFIER, 4427 value [0] EXPLICIT ANY DEFINED BY type-id } 4429 EDIPartyName ::= SEQUENCE { 4430 nameAssigner [0] DirectoryString OPTIONAL, 4431 partyName [1] DirectoryString } 4433 -- issuer alternative name extension OID and syntax 4435 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 4437 IssuerAltName ::= GeneralNames 4439 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 4441 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 4443 -- basic constraints extension OID and syntax 4445 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 4447 BasicConstraints ::= SEQUENCE { 4448 cA BOOLEAN DEFAULT FALSE, 4449 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 4451 -- name constraints extension OID and syntax 4453 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 4455 NameConstraints ::= SEQUENCE { 4456 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 4457 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 4459 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 4461 GeneralSubtree ::= SEQUENCE { 4462 base GeneralName, 4463 minimum [0] BaseDistance DEFAULT 0, 4464 maximum [1] BaseDistance OPTIONAL } 4466 BaseDistance ::= INTEGER (0..MAX) 4468 -- policy constraints extension OID and syntax 4470 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } 4471 PolicyConstraints ::= SEQUENCE { 4472 requireExplicitPolicy [0] SkipCerts OPTIONAL, 4473 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 4475 SkipCerts ::= INTEGER (0..MAX) 4477 -- CRL distribution points extension OID and syntax 4479 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31} 4481 CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 4483 DistributionPoint ::= SEQUENCE { 4484 distributionPoint [0] DistributionPointName OPTIONAL, 4485 reasons [1] ReasonFlags OPTIONAL, 4486 cRLIssuer [2] GeneralNames OPTIONAL } 4488 DistributionPointName ::= CHOICE { 4489 fullName [0] GeneralNames, 4490 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 4492 ReasonFlags ::= BIT STRING { 4493 unused (0), 4494 keyCompromise (1), 4495 cACompromise (2), 4496 affiliationChanged (3), 4497 superseded (4), 4498 cessationOfOperation (5), 4499 certificateHold (6) } 4501 -- extended key usage extension OID and syntax 4503 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 4505 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 4507 KeyPurposeId ::= OBJECT IDENTIFIER 4509 -- extended key purpose OIDs 4510 id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } 4511 id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } 4512 id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } 4513 id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } 4514 id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 } 4515 id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 } 4516 id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 } 4517 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 4518 -- inhibit any policy OID and syntax 4520 id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 } 4522 InhibitAnyPolicy ::= SkipCerts 4524 -- freshest (delta-)CRL extension OID and syntax 4526 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } 4528 FreshestCRL ::= CRLDistributionPoints 4530 -- authority info access 4532 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 4534 AuthorityInfoAccessSyntax ::= 4535 SEQUENCE SIZE (1..MAX) OF AccessDescription 4537 AccessDescription ::= SEQUENCE { 4538 accessMethod OBJECT IDENTIFIER, 4539 accessLocation GeneralName } 4541 -- CRL number extension OID and syntax 4543 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 4545 CRLNumber ::= INTEGER (0..MAX) 4547 -- issuing distribution point extension OID and syntax 4549 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 4551 IssuingDistributionPoint ::= SEQUENCE { 4552 distributionPoint [0] DistributionPointName OPTIONAL, 4553 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 4554 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 4555 onlySomeReasons [3] ReasonFlags OPTIONAL, 4556 indirectCRL [4] BOOLEAN DEFAULT FALSE } 4558 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 4560 -- deltaCRLIndicator ::= BaseCRLNumber 4562 BaseCRLNumber ::= CRLNumber 4564 -- CRL reasons extension OID and syntax 4565 id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 } 4567 CRLReason ::= ENUMERATED { 4568 unspecified (0), 4569 keyCompromise (1), 4570 cACompromise (2), 4571 affiliationChanged (3), 4572 superseded (4), 4573 cessationOfOperation (5), 4574 certificateHold (6), 4575 removeFromCRL (8) } 4577 -- certificate issuer CRL entry extension OID and syntax 4579 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } 4581 CertificateIssuer ::= GeneralNames 4583 -- hold instruction extension OID and syntax 4585 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 4587 HoldInstructionCode ::= OBJECT IDENTIFIER 4589 -- ANSI x9 holdinstructions 4591 -- ANSI x9 arc holdinstruction arc 4592 holdInstruction OBJECT IDENTIFIER ::= 4593 {joint-iso-itu-t(2) member-body(2) us(840) x9cm(10040) 2} 4595 -- ANSI X9 holdinstructions referenced by this standard 4596 id-holdinstruction-none OBJECT IDENTIFIER ::= 4597 {holdInstruction 1} -- deprecated 4598 id-holdinstruction-callissuer OBJECT IDENTIFIER ::= 4599 {holdInstruction 2} 4600 id-holdinstruction-reject OBJECT IDENTIFIER ::= 4601 {holdInstruction 3} 4603 -- invalidity date CRL entry extension OID and syntax 4605 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 4607 InvalidityDate ::= GeneralizedTime 4609 END 4610 Appendix B. ASN.1 Notes 4612 CAs MUST force the serialNumber to be a positive integer, that is, 4613 the sign bit in the DER encoding of the INTEGER value MUST be zero - 4614 this can be done by adding a leading (leftmost) `00'H octet if neces- 4615 sary. This removes a potential ambiguity in mapping between a string 4616 of octets and an integer value. 4618 Given the uniqueness requirements above serial numbers can be 4619 expected to contain long integers. Certificate users MUST be able to 4620 handle serialNumber values longer than 32 bits. Conformant CAs MUST 4621 NOT use serialNumber values longer than 20 octets. 4623 The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 4624 constructs. A valid ASN.1 sequence will have zero or more entries. 4625 The SIZE (1..MAX) construct constrains the sequence to have at least 4626 one entry. MAX indicates the upper bound is unspecified. Implementa- 4627 tions are free to choose an upper bound that suits their environment. 4629 The construct "positiveInt ::= INTEGER (0..MAX)" defines positiveInt 4630 as a subtype of INTEGER containing integers greater than or equal to 4631 zero. The upper bound is unspecified. Implementations are free to 4632 select an upper bound that suits their environment. 4634 The character string type PrintableString supports a very basic Latin 4635 character set: the lower case letters 'a' through 'z', upper case 4636 letters 'A' through 'Z', the digits '0' through '9', eleven special 4637 characters ' " ( ) + , - . / : ? and space. 4639 The character string type TeletexString is a superset of Printable- 4640 String. TeletexString supports a fairly standard (ascii-like) Latin 4641 character set, Latin characters with non-spacing accents and Japanese 4642 characters. 4644 The character string type UniversalString supports any of the charac- 4645 ters allowed by ISO 10646-1. ISO 10646 is the Universal multiple- 4646 octet coded Character Set (UCS). ISO 10646-1 specifes the architec- 4647 ture and the "basic multilingual plane" - a large standard character 4648 set which includes all major world character standards. 4650 The character string type UTF8String will be introduced in the 1998 4651 version of ASN.1. UTF8String is a universal type and has been 4652 assigned tag number 12. The content of UTF8String was defined by RFC 4653 2044 and updated in RFC 2279, "UTF-8, a transformation Format of ISO 4654 10646." ISO is expected to formally add UTF8String to the list of 4655 choices for DirectoryString in 1998 as well. 4657 In anticipation of these changes, and in conformance with IETF Best 4658 Practices codified in RFC 2277, IETF Policy on Character Sets and 4659 Languages, this document includes UTF8String as a choice in Directo- 4660 ryString and the CPS qualifier extensions. 4662 Implementers should note that the DER encoding of the SET OF values 4663 requires ordering of the encodings of the values. In particular, this 4664 issue arises with respect to distinguished names. 4666 Object Identifiers (OIDs) are used throught this specification to 4667 identify certificate policies, public key and signature algorithms, 4668 certificate extensions, etc. There is no maximum size for OIDs. 4669 This specification mandates support for OIDs which have arc elements 4670 with values that are less than 2^28, i.e. they MUST be between 0 and 4671 268,435,455 inclusive. This allows each arc element to be represented 4672 within a single 32 bit word. Implementations MUST also support OIDs 4673 where the length of the dotted decimal (see [LDAP], section 4.1.2) 4674 string representation can be up to 100 bytes (inclusive). Implementa- 4675 tions MUST be able to handle OIDs with up to 20 elements (inclusive). 4676 CAs SHOULD NOT issue certificates which contain OIDs that breach 4677 these requirements. 4679 Appendix C. Examples 4681 This section contains four examples: three certificates and a CRL. 4682 The first two certificates and the CRL comprise a minimal certifica- 4683 tion path. 4685 Section C.1 contains an annotated hex dump of a "self-signed" certi- 4686 ficate issued by a CA whose distinguished name is 4687 cn=us,o=gov,ou=nist. The certificate contains a DSA public key with 4688 parameters, and is signed by the corresponding DSA private key. 4690 Section C.2 contains an annotated hex dump of an end-entity certifi- 4691 cate. The end entity certificate contains a DSA public key, and is 4692 signed by the private key corresponding to the "self-signed" certifi- 4693 cate in section C.1. 4695 Section C.3 contains a dump of an end entity certificate which con- 4696 tains an RSA public key and is signed with RSA and MD5. This certi- 4697 ficate is not part of the minimal certification path. 4699 Section C.4 contains an annotated hex dump of a CRL. The CRL is 4700 issued by the CA whose distinguished name is cn=us,o=gov,ou=nist and 4701 the list of revoked certificates includes the end entity certificate 4702 presented in C.2. 4704 The certificates were processed using Peter Gutman's dumpasn1 utility 4705 to generate the output. The source for the dumpasn1 utility is 4706 available at . The 4707 binaries for the certificates and CRLs are available at 4708 . 4710 C.1 Certificate 4712 This section contains an annotated hex dump of a 699 byte version 3 4713 certificate. The certificate contains the following information: 4714 (a) the serial number is 23 (17 hex); 4715 (b) the certificate is signed with DSA and the SHA-1 hash algorithm; 4716 (c) the issuer's distinguished name is OU=NIST; O=gov; C=US 4717 (d) and the subject's distinguished name is OU=NIST; O=gov; C=US 4718 (e) the certificate was issued on June 30, 1997 and will expire on 4719 December 31, 1997; 4720 (f) the certificate contains a 1024 bit DSA public key with parame- 4721 ters; 4722 (g) the certificate contains a subject key identifier extension; and 4723 (h) the certificate is a CA certificate (as indicated through the 4724 basic constraints extension.) 4726 0 30 701: SEQUENCE { 4727 4 30 637: SEQUENCE { 4728 8 A0 3: [0] { 4729 10 02 1: INTEGER 2 4730 : } 4731 13 02 1: INTEGER 23 4732 16 30 9: SEQUENCE { 4733 18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 4734 : } 4735 27 30 42: SEQUENCE { 4736 29 31 11: SET { 4737 31 30 9: SEQUENCE { 4738 33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 4739 38 13 2: PrintableString 'US' 4740 : } 4741 : } 4742 42 31 12: SET { 4743 44 30 10: SEQUENCE { 4744 46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 4745 51 13 3: PrintableString 'gov' 4746 : } 4747 : } 4748 56 31 13: SET { 4749 58 30 11: SEQUENCE { 4750 60 06 3: OBJECT IDENTIFIER 4751 organizationalUnitName (2 5 4 11) 4752 65 13 4: PrintableString 'NIST' 4753 : } 4754 : } 4755 : } 4756 71 30 30: SEQUENCE { 4757 73 17 13: UTCTime '970630000000Z' 4758 88 17 13: UTCTime '971231000000Z' 4759 : } 4760 103 30 42: SEQUENCE { 4761 105 31 11: SET { 4762 107 30 9: SEQUENCE { 4763 109 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 4764 114 13 2: PrintableString 'US' 4765 : } 4766 : } 4767 118 31 12: SET { 4768 120 30 10: SEQUENCE { 4769 122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 4770 127 13 3: PrintableString 'gov' 4771 : } 4772 : } 4773 132 31 13: SET { 4774 134 30 11: SEQUENCE { 4775 136 06 3: OBJECT IDENTIFIER 4776 organizationalUnitName (2 5 4 11) 4777 141 13 4: PrintableString 'NIST' 4778 : } 4779 : } 4780 : } 4781 147 30 440: SEQUENCE { 4782 151 30 300: SEQUENCE { 4783 155 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) 4784 164 30 287: SEQUENCE { 4785 168 02 129: INTEGER 4786 : 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC FB 95 4787 : 32 AC 01 12 33 B9 E0 1C AD 90 9B BC 48 54 9E F3 4788 : 94 77 3C 2C 71 35 55 E6 FE 4F 22 CB D5 D8 3E 89 4789 : 93 33 4D FC BD 4F 41 64 3E A2 98 70 EC 31 B4 50 4790 : DE EB F1 98 28 0A C9 3E 44 B3 FD 22 97 96 83 D0 4791 : 18 A3 E3 BD 35 5B FF EE A3 21 72 6A 7B 96 DA B9 4792 : 3F 1E 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A 4793 : FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48 63 FE 4794 : 43 4795 300 02 21: INTEGER 4796 : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA 55 F7 4797 : 7D 57 74 81 E5 4798 323 02 129: INTEGER 4799 : 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91 C0 8E 4800 : 47 F1 0A C3 01 47 C2 44 42 36 A9 92 81 DE 57 C5 4801 : E0 68 86 58 00 7B 1F F9 9B 77 A1 C5 10 A5 80 91 4802 : 78 51 51 3C F6 FC FC CC 46 C6 81 78 92 84 3D F4 4803 : 93 3D 0C 38 7E 1A 5B 99 4E AB 14 64 F6 0C 21 22 4804 : 4E 28 08 9C 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 4805 : 39 A2 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF 4806 : F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE 1E 57 4807 : 18 4808 : } 4809 : } 4810 455 03 133: BIT STRING 0 unused bits 4811 : 02 81 81 00 B5 9E 1F 49 04 47 D1 DB F5 3A DD CA 4812 : 04 75 E8 DD 75 F6 9B 8A B1 97 D6 59 69 82 D3 03 4813 : 4D FD 3B 36 5F 4A F2 D1 4E C1 07 F5 D1 2A D3 78 4814 : 77 63 56 EA 96 61 4D 42 0B 7A 1D FB AB 91 A4 CE 4815 : DE EF 77 C8 E5 EF 20 AE A6 28 48 AF BE 69 C3 6A 4816 : A5 30 F2 C2 B9 D9 82 2B 7D D9 C4 84 1F DE 0D E8 4817 : 54 D7 1B 99 2E B3 D0 88 F6 D6 63 9B A7 E2 0E 82 4818 : D4 3B 8A 68 1B 06 56 31 59 0B 49 EB 99 A5 D5 81 4819 : 41 7B C9 55 4820 : } 4821 591 A3 52: [3] { 4822 593 30 50: SEQUENCE { 4823 595 30 31: SEQUENCE { 4824 597 06 3: OBJECT IDENTIFIER 4825 subjectKeyIdentifier (2 5 29 14) 4826 602 04 24: OCTET STRING 4827 : 04 16 04 14 E7 26 C5 54 CD 5B A3 6F 35 68 95 AA 4828 : D5 FF 1C 21 E4 22 75 D6 4829 : } 4830 628 30 15: SEQUENCE { 4831 630 06 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19) 4832 635 01 1: BOOLEAN TRUE 4833 638 04 5: OCTET STRING 4834 : 30 03 01 01 FF 4835 : } 4836 : } 4837 : } 4838 : } 4839 645 30 9: SEQUENCE { 4840 647 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 4841 : } 4842 656 03 47: BIT STRING 0 unused bits 4843 : 30 2C 02 14 6A F9 3F 72 30 7F 45 DC E5 50 C1 5E 4844 : 94 A0 6D C7 92 4C E5 E1 02 14 6F 61 B8 65 F7 AA 4845 : DF 46 1B F7 39 0D 0D 88 9E FE B6 83 F7 1A 4846 : } 4848 C.2 Certificate 4850 This section contains an annotated hex dump of a 730 byte version 3 4851 certificate. The certificate contains the following information: 4852 (a) the serial number is 18 (12 hex); 4853 (b) the certificate is signed with DSA and the SHA-1 hash algorithm; 4854 (c) the issuer's distinguished name is OU=nist; O=gov; C=US 4855 (d) and the subject's distinguished name is CN=Tim Polk; OU=nist; 4856 O=gov; C=US 4857 (e) the certificate was valid from July 30, 1997 through December 1, 4858 1997; 4859 (f) the certificate contains a 1024 bit DSA public key; 4860 (g) the certificate is an end entity certificate, as the basic con- 4861 straints extension is not present; 4862 (h) the certificate contains an authority key identifier extension; 4863 and 4864 (i) the certificate includes one alternative name - an RFC 822 4865 address. 4867 0 30 734: SEQUENCE { 4868 4 30 669: SEQUENCE { 4869 8 A0 3: [0] { 4870 10 02 1: INTEGER 2 4871 : } 4872 13 02 1: INTEGER 18 4873 16 30 9: SEQUENCE { 4874 18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 4875 : } 4876 27 30 42: SEQUENCE { 4877 29 31 11: SET { 4878 31 30 9: SEQUENCE { 4879 33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 4880 38 13 2: PrintableString 'US' 4881 : } 4882 : } 4883 42 31 12: SET { 4884 44 30 10: SEQUENCE { 4885 46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 4886 51 13 3: PrintableString 'gov' 4887 : } 4888 : } 4889 56 31 13: SET { 4890 58 30 11: SEQUENCE { 4891 60 06 3: OBJECT IDENTIFIER 4892 organizationalUnitName (2 5 4 11) 4893 65 13 4: PrintableString 'NIST' 4894 : } 4895 : } 4896 : } 4897 71 30 30: SEQUENCE { 4898 73 17 13: UTCTime '970730000000Z' 4899 88 17 13: UTCTime '971201000000Z' 4900 : } 4901 103 30 61: SEQUENCE { 4902 105 31 11: SET { 4903 107 30 9: SEQUENCE { 4904 109 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 4905 114 13 2: PrintableString 'US' 4906 : } 4907 : } 4908 118 31 12: SET { 4909 120 30 10: SEQUENCE { 4910 122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 4911 127 13 3: PrintableString 'gov' 4912 : } 4913 : } 4914 132 31 13: SET { 4915 134 30 11: SEQUENCE { 4916 136 06 3: OBJECT IDENTIFIER 4917 organizationalUnitName (2 5 4 11) 4918 141 13 4: PrintableString 'NIST' 4919 : } 4920 : } 4921 147 31 17: SET { 4922 149 30 15: SEQUENCE { 4923 151 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 4924 156 13 8: PrintableString 'Tim Polk' 4925 : } 4926 : } 4927 : } 4928 166 30 439: SEQUENCE { 4929 170 30 300: SEQUENCE { 4930 174 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) 4931 183 30 287: SEQUENCE { 4932 187 02 129: INTEGER 4933 : 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC FB 95 4934 : 32 AC 01 12 33 B9 E0 1C AD 90 9B BC 48 54 9E F3 4935 : 94 77 3C 2C 71 35 55 E6 FE 4F 22 CB D5 D8 3E 89 4936 : 93 33 4D FC BD 4F 41 64 3E A2 98 70 EC 31 B4 50 4937 : DE EB F1 98 28 0A C9 3E 44 B3 FD 22 97 96 83 D0 4938 : 18 A3 E3 BD 35 5B FF EE A3 21 72 6A 7B 96 DA B9 4939 : 3F 1E 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A 4940 : FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48 63 FE 4941 : 43 4942 319 02 21: INTEGER 4943 : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA 55 F7 4944 : 7D 57 74 81 E5 4945 342 02 129: INTEGER 4946 : 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91 C0 8E 4947 : 47 F1 0A C3 01 47 C2 44 42 36 A9 92 81 DE 57 C5 4948 : E0 68 86 58 00 7B 1F F9 9B 77 A1 C5 10 A5 80 91 4949 : 78 51 51 3C F6 FC FC CC 46 C6 81 78 92 84 3D F4 4950 : 93 3D 0C 38 7E 1A 5B 99 4E AB 14 64 F6 0C 21 22 4951 : 4E 28 08 9C 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 4952 : 39 A2 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF 4953 : F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE 1E 57 4954 : 18 4955 : } 4956 : } 4957 474 03 132: BIT STRING 0 unused bits 4958 : 02 81 80 30 B6 75 F7 7C 20 31 AE 38 BB 7E 0D 2B 4959 : AB A0 9C 4B DF 20 D5 24 13 3C CD 98 E5 5F 6C B7 4960 : C1 BA 4A BA A9 95 80 53 F0 0D 72 DC 33 37 F4 01 4961 : 0B F5 04 1F 9D 2E 1F 62 D8 84 3A 9B 25 09 5A 2D 4962 : C8 46 8E 2B D4 F5 0D 3B C7 2D C6 6C B9 98 C1 25 4963 : 3A 44 4E 8E CA 95 61 35 7C CE 15 31 5C 23 13 1E 4964 : A2 05 D1 7A 24 1C CB D3 72 09 90 FF 9B 9D 28 C0 4965 : A1 0A EC 46 9F 0D B8 D0 DC D0 18 A6 2B 5E F9 8F 4966 : B5 95 BE 4967 : } 4968 609 A3 66: [3] { 4969 611 30 64: SEQUENCE { 4970 613 30 25: SEQUENCE { 4971 615 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 4972 620 04 18: OCTET STRING 4973 : 30 10 81 0E 77 70 6F 6C 6B 40 6E 69 73 74 2E 67 4974 : 6F 76 4975 : } 4976 640 30 35: SEQUENCE { 4977 642 06 3: OBJECT IDENTIFIER 4978 authorityKeyIdentifier (2 5 29 35) 4979 647 04 28: OCTET STRING 4980 : 30 1A 80 18 04 16 04 14 E7 26 C5 54 CD 5B A3 6F 4981 : 35 68 95 AA D5 FF 1C 21 E4 22 75 D6 4982 : } 4983 : } 4984 : } 4985 : } 4986 677 30 9: SEQUENCE { 4987 679 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 4988 : } 4989 688 03 48: BIT STRING 0 unused bits 4990 : 30 2D 02 14 37 FC 44 BF 7F 8D 18 1F 40 04 2F CF 4991 : EA CC 22 B2 16 01 FF 13 02 15 00 97 D0 24 96 0F 4992 : 64 8A C3 8D 41 B2 0E B9 26 D5 31 D1 A0 F1 BC 4993 : } 4995 C.3 End-Entity Certificate Using RSA 4997 This section contains an annotated hex dump of a 675 byte version 3 4998 certificate. The certificate contains the following information: 4999 (a) the serial number is 256; 5000 (b) the certificate is signed with RSA and the MD2 hash algorithm; 5001 (c) the issuer's distinguished name is OU=Dept. Arquitectura de Com- 5002 putadors; O=Universitat Politecnica de Catalunya; C=ES 5003 (d) and the subject's distinguished name is CN=Francisco Jordan; 5004 OU=Dept. Arquitectura de Computadors; O=Universitat Politecnica de 5005 Catalunya; C=ES 5006 (e) the certificate was issued on May 21, 1996 and expired on May 21, 5007 1997; 5008 (f) the certificate contains a 768 bit RSA public key; 5009 (g) the certificate is an end entity certificate (not a CA certifi- 5010 cate); 5011 (h) the certificate includes an alternative subject name and an 5012 alternative issuer name - bothe are URLs; 5013 (i) the certificate include an authority key identifier and certifi- 5014 cate policies extensions; and 5015 (j) the certificate includes a critical key usage extension specify- 5016 ing the public is intended for generation of digital signatures. 5018 0 30 654: SEQUENCE { 5019 4 30 503: SEQUENCE { 5020 8 A0 3: [0] { 5021 10 02 1: INTEGER 2 5022 : } 5023 13 02 2: INTEGER 256 5024 17 30 13: SEQUENCE { 5025 19 06 9: OBJECT IDENTIFIER 5026 : sha1withRSAEncryption (1 2 840 113549 1 1 5) 5027 30 05 0: NULL 5028 : } 5029 32 30 42: SEQUENCE { 5030 34 31 11: SET { 5031 36 30 9: SEQUENCE { 5032 38 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5033 43 13 2: PrintableString 'US' 5034 : } 5035 : } 5036 47 31 12: SET { 5037 49 30 10: SEQUENCE { 5038 51 06 3: OBJECT IDENTIFIER 5039 organizationalUnitName (2 5 4 11) 5041 56 13 3: PrintableString 'gov' 5042 : } 5043 : } 5044 61 31 13: SET { 5045 63 30 11: SEQUENCE { 5046 65 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5047 70 13 4: PrintableString 'NIST' 5048 : } 5049 : } 5050 : } 5051 76 30 30: SEQUENCE { 5052 78 17 13: UTCTime '960521095826Z' 5053 93 17 13: UTCTime '970521095826Z' 5054 : } 5055 108 30 61: SEQUENCE { 5056 110 31 11: SET { 5057 112 30 9: SEQUENCE { 5058 114 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5059 119 13 2: PrintableString 'US' 5060 : } 5061 : } 5062 123 31 12: SET { 5063 125 30 10: SEQUENCE { 5064 127 06 3: OBJECT IDENTIFIER 5065 organizationalUnitName (2 5 4 11) 5066 132 13 3: PrintableString 'gov' 5067 : } 5068 : } 5069 137 31 13: SET { 5070 139 30 11: SEQUENCE { 5071 141 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5072 146 13 4: PrintableString 'NIST' 5073 : } 5074 : } 5075 152 31 17: SET { 5076 154 30 15: SEQUENCE { 5077 156 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 5078 161 13 8: PrintableString 'Tim Polk' 5079 : } 5080 : } 5081 : } 5082 171 30 159: SEQUENCE { 5083 174 30 13: SEQUENCE { 5084 176 06 9: OBJECT IDENTIFIER 5085 rsaEncryption (1 2 840 113549 1 1 1) 5086 187 05 0: NULL 5087 : } 5088 189 03 141: BIT STRING 0 unused bits 5089 : 30 81 89 02 81 81 00 E1 CE 06 C9 D7 00 DF 65 27 5090 : 45 1E 63 6A 09 A0 A0 10 4B AF DF 9D 36 1D 44 1F 5091 : B7 07 5D 36 92 09 6A 1A 96 C7 4E D9 86 0D 0F 77 5092 : 94 F5 82 62 68 9A F2 D7 76 F5 9A 35 C7 B3 7F 4F 5093 : BE 64 CF A3 0C B3 84 32 80 F5 CA 77 29 C9 76 0B 5094 : 4C 38 19 EE 61 6F BA 68 E0 03 85 46 34 AB 84 64 5095 : 7F 43 69 02 C0 20 86 BD B1 D4 AD 21 A9 1A 8F CF 5096 : 96 83 86 92 57 5B 43 09 28 4C F2 5A 04 AD E5 DE 5097 : 9E 4F E8 38 3C F0 89 02 03 01 00 01 5098 : } 5099 333 A3 175: [3] { 5100 336 30 172: SEQUENCE { 5101 339 30 63: SEQUENCE { 5102 341 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 5103 346 04 56: OCTET STRING 5104 : 30 36 86 34 68 74 74 70 3A 2F 2F 77 77 77 2E 69 5105 : 74 6C 2E 6E 69 73 74 2E 67 6F 76 2F 64 69 76 38 5106 : 39 33 2F 73 74 61 66 66 2F 70 6F 6C 6B 2F 69 6E 5107 : 64 65 78 2E 68 74 6D 6C 5108 : } 5109 404 30 31: SEQUENCE { 5110 406 06 3: OBJECT IDENTIFIER issuerAltName (2 5 29 18) 5111 411 04 24: OCTET STRING 5112 : 30 16 86 14 68 74 74 70 3A 2F 2F 77 77 77 2E 6E 5113 : 69 73 74 2E 67 6F 76 2F 5114 : } 5115 437 30 31: SEQUENCE { 5116 439 06 3: OBJECT IDENTIFIER 5117 authorityKeyIdentifier (2 5 29 35) 5118 444 04 24: OCTET STRING 5119 : 30 16 80 14 30 12 80 10 0E 6B 3A BF 04 EA 04 C3 5120 : 0E 6B 3A BF 04 EA 04 C3 5121 : } 5122 470 30 23: SEQUENCE { 5123 472 06 3: OBJECT IDENTIFIER 5124 certificatePolicies (2 5 29 32) 5125 477 04 16: OCTET STRING 5126 : 30 0E 30 0C 06 0A 60 86 48 01 65 03 02 01 30 09 5127 : } 5128 495 30 14: SEQUENCE { 5129 497 06 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) 5130 502 01 1: BOOLEAN TRUE 5131 505 04 4: OCTET STRING 5132 : 03 02 07 80 5133 : } 5134 : } 5135 : } 5136 : } 5138 511 30 13: SEQUENCE { 5139 513 06 9: OBJECT IDENTIFIER 5140 : sha1withRSAEncryption (1 2 840 113549 1 1 5) 5141 524 05 0: NULL 5142 : } 5143 526 03 129: BIT STRING 0 unused bits 5144 : C1 25 6F AB 72 C0 5D DA E4 2F D5 E1 B0 25 D8 B4 5145 : F1 82 95 D6 0D A5 4E 4F A1 23 E1 13 A4 9C 3D C5 5146 : 7F FD 05 EC 75 06 30 66 97 75 A6 5D 8F 97 BA B4 5147 : EC A9 43 19 8D B7 54 FD E9 AD 43 B8 3C 8B D3 9E 5148 : C7 C7 27 E3 1A AD D3 79 AC 65 5A 52 78 C4 D0 43 5149 : 81 50 F7 8A BA E2 30 1A 6D D0 78 A0 4E AE 2E 79 5150 : 37 0C 93 05 5C D1 9C 1B B2 62 73 D1 EA 50 B7 84 5151 : 29 92 74 34 CF BA AA 2C 4D 43 59 EF 98 0C 41 6C 5152 : } 5154 C.4 Certificate Revocation List 5156 This section contains an annotated hex dump of a version 2 CRL with 5157 one extension (cRLNumber). The CRL was issued by OU=nist;O=gov;C=us 5158 on July 7, 1996; the next scheduled issuance was August 7, 1996. The 5159 CRL includes one revoked certificates: serial number 18 (12 hex). 5160 The CRL itself is number 18, and it was signed with DSA and SHA-1. 5162 0 30 203: SEQUENCE { 5163 3 30 140: SEQUENCE { 5164 6 02 1: INTEGER 1 5165 9 30 9: SEQUENCE { 5166 11 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5167 : } 5168 20 30 42: SEQUENCE { 5169 22 31 11: SET { 5170 24 30 9: SEQUENCE { 5171 26 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5172 31 13 2: PrintableString 'US' 5173 : } 5174 : } 5175 35 31 12: SET { 5176 37 30 10: SEQUENCE { 5177 39 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5178 44 13 3: PrintableString 'gov' 5179 : } 5180 : } 5181 49 31 13: SET { 5182 51 30 11: SEQUENCE { 5183 53 06 3: OBJECT IDENTIFIER 5184 organizationalUnitName (2 5 4 11) 5185 58 13 4: PrintableString 'NIST' 5186 : } 5187 : } 5188 : } 5189 64 17 13: UTCTime '970807000000Z' 5190 79 17 13: UTCTime '970907000000Z' 5191 94 30 34: SEQUENCE { 5192 96 30 32: SEQUENCE { 5193 98 02 1: INTEGER 18 5194 101 17 13: UTCTime '970731000000Z' 5195 116 30 12: SEQUENCE { 5196 118 30 10: SEQUENCE { 5197 120 06 3: OBJECT IDENTIFIER cRLReason (2 5 29 21) 5198 125 04 3: OCTET STRING 5199 : 0A 01 01 5200 : } 5201 : } 5202 : } 5203 : } 5204 130 A0 14: [0] { 5205 132 30 12: SEQUENCE { 5206 134 30 10: SEQUENCE { 5207 136 06 3: OBJECT IDENTIFIER cRLNumber (2 5 29 20) 5208 141 04 3: OCTET STRING 5209 : 02 01 12 5210 : } 5211 : } 5212 : } 5213 : } 5214 146 30 9: SEQUENCE { 5215 148 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5216 : } 5217 157 03 47: BIT STRING 0 unused bits 5218 : 30 2C 02 14 79 1F F6 93 0B 84 06 D6 A0 7C 8D 68 5219 : A7 52 2E 5F 3F 89 9B 4B 02 14 66 D4 B5 2A 68 36 5220 : 9B 72 88 58 E3 89 19 AD 81 89 2E 96 BB CC 5221 : } 5223 Appendix D. Author Addresses: 5225 Russell Housley 5226 SPYRUS 5227 381 Elden Street 5228 Suite 1120 5229 Herndon, VA 20170 5230 USA 5231 housley@spyrus.com 5233 Warwick Ford 5234 VeriSign, Inc. 5235 One Alewife Center 5236 Cambridge, MA 02140 5237 USA 5238 wford@verisign.com 5240 Tim Polk 5241 NIST 5242 Building 820, Room 426 5243 Gaithersburg, MD 20899 5244 USA 5245 wpolk@nist.gov 5247 David Solo 5248 Citicorp 5249 666 Fifth Ave, 3rd Floor 5250 New York, NY 10103 5251 USA 5252 david.solo@citicorp.com 5254 Appendix E. Full Copyright Statement 5256 Copyright (C) The Internet Society (date). All Rights Reserved. 5258 This document and translations of it may be copied and furnished to 5259 others, and derivative works that comment on or otherwise explain it 5260 or assist in its implementation may be prepared, copied, published 5261 and distributed, in whole or in part, without restriction of any 5262 kind, provided that the above copyright notice and this paragraph are 5263 included on all such copies and derivative works. In addition, the 5264 ASN.1 modules presented in Appendices A and B may be used in whole or 5265 in part without inclusion of the copyright notice. However, this 5266 document itself may not be modified in any way, such as by removing 5267 the copyright notice or references to the Internet Society or other 5268 Internet organizations, except as needed for the purpose of develop- 5269 ing Internet standards in which case the procedures for copyrights 5270 defined in the Internet Standards process shall be followed, or as 5271 required to translate it into languages other than English. 5273 The limited permissions granted above are perpetual and will not be 5274 revoked by the Internet Society or its successors or assigns. This 5275 document and the information contained herein is provided on an "AS 5276 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 5277 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 5278 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 5279 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 5280 OR FITNESS FOR A PARTICULAR PURPOSE.