idnits 2.17.00 (12 Aug 2021) /tmp/idnits18292/draft-ietf-pkix-new-part1-04.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 118 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 118 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 is 1 instance of too long lines in the document, the longest one being 62 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. == There is 5 instances of lines with non-RFC2606-compliant FQDNs in the document. == There is 24 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There is 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 608 has weird spacing: '...issuing a cer...' == Line 619 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 (January 2001) is 7795 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 5388 -- Looks like a reference, but probably isn't: '1' on line 4734 -- Looks like a reference, but probably isn't: '2' on line 4735 -- Looks like a reference, but probably isn't: '3' on line 5283 == Missing Reference: 'ISO 8859-1' is mentioned on line 914, but not defined -- Looks like a reference, but probably isn't: '4' on line 4737 -- Looks like a reference, but probably isn't: '5' on line 4598 -- Looks like a reference, but probably isn't: '6' on line 4599 -- Looks like a reference, but probably isn't: '7' on line 4600 -- Looks like a reference, but probably isn't: '8' on line 4601 == Missing Reference: 'RFC1738' is mentioned on line 2532, but not defined ** Obsolete undefined reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) == Missing Reference: 'RFC1778' is mentioned on line 2532, but not defined ** Obsolete undefined reference: RFC 1778 (Obsoleted by RFC 3494) == Missing Reference: 'UNIVERSAL 28' is mentioned on line 3891, but not defined == Missing Reference: 'UNIVERSAL 30' is mentioned on line 3894, but not defined == Missing Reference: 'UNIVERSAL 12' is mentioned on line 3898, but not defined == Missing Reference: 'APPLICATION 1' is mentioned on line 4197, but not defined == Missing Reference: 'APPLICATION 2' is mentioned on line 4203, but not defined == Missing Reference: 'LDAP' is mentioned on line 4855, but not defined == Unused Reference: 'RFC 1423' is defined on line 3644, but no explicit reference was found in the text == Unused Reference: 'RFC 1778' is defined on line 3658, but no explicit reference was found in the text == Unused Reference: 'RFC 1883' is defined on line 3662, but no explicit reference was found in the text == Unused Reference: 'RFC 2119' is defined on line 3665, but no explicit reference was found in the text == Unused Reference: 'RFC 2277' is defined on line 3673, but no explicit reference was found in the text == Unused Reference: 'RFC 2279' is defined on line 3676, but no explicit reference was found in the text == Unused Reference: 'PKIX TSA' is defined on line 3715, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Downref: Normative reference to an Historic RFC: RFC 1422 ** Downref: Normative reference to an Historic RFC: RFC 1423 ** Obsolete normative reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) ** Obsolete normative reference: RFC 1519 (Obsoleted by RFC 4632) ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 1778 (Obsoleted by RFC 3494) ** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) == Outdated reference: draft-ietf-cat-kerberos-pk-init has been published as RFC 4556 == Outdated reference: draft-ietf-pkix-ipki-pkalgs has been published as RFC 3279 == Outdated reference: draft-ietf-pkix-time-stamp has been published as RFC 3161 Summary: 20 errors (**), 0 flaws (~~), 28 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 January 2001 8 Internet X.509 Public Key Infrastructure 10 Certificate and CRL Profile 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/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 (2001). All Rights Reserved. 41 Abstract 43 This is the fourth draft of a specification based upon RFC 2459. 44 When complete, this specification will obsolete RFC 2459. This 45 specification includes minor edits and clarifications. The most 46 notable departures from RFC 2459 are found in Section 6, Path 47 Validation. In RFC 2459, the reader was expected to augment the path 48 validation algorithm, which concentrated upon policy processing, with 49 information embedded in 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 The most significant enhancement in draft four is a definition of the 66 term self-issued in section 6.1. Also, the certificate serial number 67 MUST be positive integers. This is not a new requirement, but the 68 text has been modified to use the term MUST. 70 This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use 71 in the Internet. An overview of the approach and model are provided 72 as an introduction. The X.509 v3 certificate format is described in 73 detail, with additional information regarding the format and 74 semantics of Internet name forms (e.g., IP addresses). Standard 75 certificate extensions are described and one new Internet-specific 76 extension is defined. A required set of certificate extensions is 77 specified. The X.509 v2 CRL format is described and a required 78 extension set is defined as well. An algorithm for X.509 certificate 79 path validation is described. Supplemental information is provided 80 describing the format of public keys and digital signatures in X.509 81 certificates for common Internet public key encryption algorithms 82 (i.e., RSA, DSA, and Diffie-Hellman). ASN.1 modules and examples are 83 provided in the appendices. 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC 2119. 89 Please send comments on this document to the ietf-pkix@imc.org mail 90 list. 92 TTTTaaaabbbblllleeee ooooffff CCCCoooonnnntttteeeennnnttttssss 94 1 Introduction ................................................ 6 95 2 Requirements and Assumptions ................................ 7 96 2.1 Communication and Topology ................................ 7 97 2.2 Acceptability Criteria .................................... 8 98 2.3 User Expectations ......................................... 8 99 2.4 Administrator Expectations ................................ 8 100 3 Overview of Approach ........................................ 8 101 3.1 X.509 Version 3 Certificate ............................... 10 102 3.2 Certification Paths and Trust ............................. 11 103 3.3 Revocation ................................................ 13 104 3.4 Operational Protocols ..................................... 14 105 3.5 Management Protocols ...................................... 14 106 4 Certificate and Certificate Extensions Profile .............. 15 107 4.1 Basic Certificate Fields .................................. 16 108 4.1.1 Certificate Fields ...................................... 17 109 4.1.1.1 tbsCertificate ........................................ 17 110 4.1.1.2 signatureAlgorithm .................................... 17 111 4.1.1.3 signatureValue ........................................ 18 112 4.1.2 TBSCertificate .......................................... 18 113 4.1.2.1 Version ............................................... 18 114 4.1.2.2 Serial number ......................................... 19 115 4.1.2.3 Signature ............................................. 19 116 4.1.2.4 Issuer ................................................ 19 117 4.1.2.5 Validity .............................................. 23 118 4.1.2.5.1 UTCTime ............................................. 23 119 4.1.2.5.2 GeneralizedTime ..................................... 23 120 4.1.2.6 Subject ............................................... 24 121 4.1.2.7 Subject Public Key Info ............................... 25 122 4.1.2.8 Unique Identifiers .................................... 25 123 4.1.2.9 Extensions ............................................. 25 124 4.2 Certificate Extensions .................................... 25 125 4.2.1 Standard Extensions ..................................... 26 126 4.2.1.1 Authority Key Identifier .............................. 27 127 4.2.1.2 Subject Key Identifier ................................ 27 128 4.2.1.3 Key Usage ............................................. 29 129 4.2.1.4 Private Key Usage Period .............................. 30 130 4.2.1.5 Certificate Policies .................................. 31 131 4.2.1.6 Policy Mappings ....................................... 33 132 4.2.1.7 Subject Alternative Name .............................. 34 133 4.2.1.8 Issuer Alternative Name ............................... 36 134 4.2.1.9 Subject Directory Attributes .......................... 37 135 4.2.1.10 Basic Constraints .................................... 37 136 4.2.1.11 Name Constraints ..................................... 38 137 4.2.1.12 Policy Constraints ................................... 40 138 4.2.1.13 Extended key usage field ............................. 41 139 4.2.1.14 CRL Distribution Points .............................. 42 140 4.2.1.15 Inhibit Any-Policy ................................... 43 141 4.2.1.16 Freshest CRL ......................................... 43 142 4.2.2 Internet Certificate Extensions ......................... 44 143 4.2.2.1 Authority Information Access .......................... 44 144 4.2.2.2 Subject Information Access ............................ 45 145 5 CRL and CRL Extensions Profile .............................. 47 146 5.1 CRL Fields ................................................ 47 147 5.1.1 CertificateList Fields .................................. 48 148 5.1.1.1 tbsCertList ........................................... 48 149 5.1.1.2 signatureAlgorithm .................................... 49 150 5.1.1.3 signatureValue ........................................ 49 151 5.1.2 Certificate List "To Be Signed" ......................... 49 152 5.1.2.1 Version ............................................... 49 153 5.1.2.2 Signature ............................................. 49 154 5.1.2.3 Issuer Name ........................................... 50 155 5.1.2.4 This Update ........................................... 50 156 5.1.2.5 Next Update ........................................... 50 157 5.1.2.6 Revoked Certificates .................................. 51 158 5.1.2.7 Extensions ............................................ 51 159 5.2 CRL Extensions ............................................ 51 160 5.2.1 Authority Key Identifier ................................ 51 161 5.2.2 Issuer Alternative Name ................................. 52 162 5.2.3 CRL Number .............................................. 52 163 5.2.4 Delta CRL Indicator ..................................... 52 164 5.2.5 Issuing Distribution Point .............................. 54 165 5.2.6 Freshest CRL ............................................ 55 166 5.3 CRL Entry Extensions ...................................... 55 167 5.3.1 Reason Code ............................................. 56 168 5.3.2 Hold Instruction Code ................................... 56 169 5.3.3 Invalidity Date ......................................... 57 170 5.3.4 Certificate Issuer ...................................... 57 171 6 Certificate Path Validation ................................. 58 172 6.1 Basic Path Validation ..................................... 58 173 6.1.1 Inputs ................................................... 61 174 6.1.2 Initialization ........................................... 62 175 6.1.3 Basic Certificate Processing ............................. 65 176 6.1.4 Preparation for Certificate i+1 .......................... 70 177 6.1.5 Wrap-up procedure ........................................ 73 178 6.1.6 Outputs .................................................. 74 179 6.2 Extending Path Validation ................................. 75 180 6.3 CRL Validation ............................................ 75 181 6.3.1 Revocation Inputs ....................................... 76 182 6.3.2 Initialization and Revocation State Variables ........... 76 183 6.3.3 CRL Processing .......................................... 77 184 7 References .................................................. 79 185 8 Intellectual Property Rights ................................ 81 186 9 Security Considerations ..................................... 81 187 Appendix A. ASN.1 Structures and OIDs ......................... 84 188 A.1 Explicitly Tagged Module, 1988 Syntax ...................... 84 189 A.2 Implicitly Tagged Module, 1988 Syntax ...................... 97 190 Appendix B. ASN.1 Notes ....................................... 104 191 Appendix C. Examples .......................................... 105 192 C.1 Certificate ............................................... 106 193 C.2 Certificate ............................................... 109 194 C.3 End-Entity Certificate Using RSA .......................... 112 195 C.4 Certificate Revocation List ............................... 115 196 Appendix D. Author Addresses .................................. 117 197 Appendix E. Full Copyright Statement .......................... 117 199 1 Introduction 201 This specification is one part of a family of standards for the X.509 202 Public Key Infrastructure (PKI) for the Internet. This specification 203 is a standalone document; implementations of this standard may 204 proceed independent from the other parts. 206 This specification profiles the format and semantics of certificates 207 and certificate revocation lists for the Internet PKI. Procedures 208 are described for processing of certification paths in the Internet 209 environment. Encoding rules are provided for popular cryptographic 210 algorithms. Finally, ASN.1 modules are provided in the appendices 211 for all data structures defined or referenced. 213 The specification describes the requirements which inspire the 214 creation of this document and the assumptions which affect its scope 215 in Section 2. Section 3 presents an architectural model and 216 describes its relationship to previous IETF and ISO/IEC/ITU 217 standards. In particular, this document's relationship with the IETF 218 PEM specifications and the ISO/IEC/ITU X.509 documents are described. 220 The specification profiles the X.509 version 3 certificate in Section 221 4, and the X.509 version 2 certificate revocation list (CRL) in 222 Section 5. The profiles include the identification of ISO/IEC/ITU 223 and ANSI extensions which may be useful in the Internet PKI. The 224 profiles are presented in the 1988 Abstract Syntax Notation One 225 (ASN.1) rather than the 1994 syntax used in the ISO/IEC/ITU 226 standards. 228 This specification also includes path validation procedures in 229 Section 6. These procedures are based upon the ISO/IEC/ITU 230 definition, but the presentation assumes one or more self-signed 231 trusted CA certificates. Implementations are required to derive the 232 same results but are not required to use the specified procedures. 234 Procedures for identification and encoding of public key materials 235 and digital signatures are defined in [PKIX ALGS]. Implementations of 236 this specification are not required to use any particular 237 cryptographic algorithms. However, conforming implementations which 238 use the algorithms identified in [PKIX ALGS] are required to identify 239 and encode the public key materials and digital signatures as 240 described in that specification. 242 Finally, three appendices are provided to aid implementers. Appendix 243 A contains all ASN.1 structures defined or referenced within this 244 specification. As above, the material is presented in the 1988 245 Abstract Syntax Notation One (ASN.1) rather than the 1994 syntax. 246 Appendix B contains notes on less familiar features of the ASN.1 247 notation used within this specification. Appendix C contains 248 examples of a conforming certificate and a conforming CRL. 250 2 Requirements and Assumptions 252 The goal of this specification is to develop a profile to facilitate 253 the use of X.509 certificates within Internet applications for those 254 communities wishing to make use of X.509 technology. Such 255 applications may include WWW, electronic mail, user authentication, 256 and IPsec. In order to relieve some of the obstacles to using X.509 257 certificates, this document defines a profile to promote the 258 development of certificate management systems; development of 259 application tools; and interoperability determined by policy. 261 Some communities will need to supplement, or possibly replace, this 262 profile in order to meet the requirements of specialized application 263 domains or environments with additional authorization, assurance, or 264 operational requirements. However, for basic applications, common 265 representations of frequently used attributes are defined so that 266 application developers can obtain necessary information without 267 regard to the issuer of a particular certificate or certificate 268 revocation list (CRL). 270 A certificate user should review the certificate policy generated by 271 the certification authority (CA) before relying on the authentication 272 or non-repudiation services associated with the public key in a 273 particular certificate. To this end, this standard does not 274 prescribe legally binding rules or duties. 276 As supplemental authorization and attribute management tools emerge, 277 such as attribute certificates, it may be appropriate to limit the 278 authenticated attributes that are included in a certificate. These 279 other management tools may provide more appropriate methods of 280 conveying many authenticated attributes. 282 2.1 Communication and Topology 284 The users of certificates will operate in a wide range of 285 environments with respect to their communication topology, especially 286 users of secure electronic mail. This profile supports users without 287 high bandwidth, real-time IP connectivity, or high connection 288 availability. In addition, the profile allows for the presence of 289 firewall or other filtered communication. 291 This profile does not assume the deployment of an X.500 Directory 292 system. The profile does not prohibit the use of an X.500 Directory, 293 but other means of distributing certificates and certificate 294 revocation lists (CRLs) may be used. 296 2.2 Acceptability Criteria 298 The goal of the Internet Public Key Infrastructure (PKI) is to meet 299 the needs of deterministic, automated identification, authentication, 300 access control, and authorization functions. Support for these 301 services determines the attributes contained in the certificate as 302 well as the ancillary control information in the certificate such as 303 policy data and certification path constraints. 305 2.3 User Expectations 307 Users of the Internet PKI are people and processes who use client 308 software and are the subjects named in certificates. These uses 309 include readers and writers of electronic mail, the clients for WWW 310 browsers, WWW servers, and the key manager for IPsec within a router. 311 This profile recognizes the limitations of the platforms these users 312 employ and the limitations in sophistication and attentiveness of the 313 users themselves. This manifests itself in minimal user 314 configuration responsibility (e.g., trusted CA keys, rules), explicit 315 platform usage constraints within the certificate, certification path 316 constraints which shield the user from many malicious actions, and 317 applications which sensibly automate validation functions. 319 2.4 Administrator Expectations 321 As with user expectations, the Internet PKI profile is structured to 322 support the individuals who generally operate CAs. Providing 323 administrators with unbounded choices increases the chances that a 324 subtle CA administrator mistake will result in broad compromise. 325 Also, unbounded choices greatly complicate the software that shall 326 process and validate the certificates created by the CA. 328 3 Overview of Approach 330 Following is a simplified view of the architectural model assumed by 331 the PKIX specifications. 333 +---+ 334 | C | +------------+ 335 | e | <-------------------->| End entity | 336 | r | Operational +------------+ 337 | t | transactions ^ 338 | | and management | Management 339 | / | transactions | transactions 340 | | | PKI users 341 | C | v 342 | R | -------------------+--+-----------+---------------- 343 | L | ^ ^ 344 | | | | PKI management 345 | | v | entities 346 | R | +------+ | 347 | e | <---------------------| RA | <---+ | 348 | p | Publish certificate +------+ | | 349 | o | | | 350 | s | | | 351 | I | v v 352 | t | +------------+ 353 | o | <------------------------------| CA | 354 | r | Publish certificate +------------+ 355 | y | Publish CRL ^ 356 | | | 357 +---+ Management | 358 transactions | 359 v 360 +------+ 361 | CA | 362 +------+ 364 Figure 1 - PKI Entities 366 The components in this model are: 368 end entity: user of PKI certificates and/or end user system that 369 is the subject of a certificate; 370 CA: certification authority; 371 RA: registration authority, i.e., an optional system to 372 which a CA delegates certain management functions; 373 repository: a system or collection of distributed systems that 374 store certificates and CRLs and serves as a means of 375 distributing these certificates and CRLs to end 376 entities. 378 3.1 X.509 Version 3 Certificate 380 Users of a public key require confidence that the associated private 381 key is owned by the correct remote subject (person or system) with 382 which an encryption or digital signature mechanism will be used. 383 This confidence is obtained through the use of public key 384 certificates, which are data structures that bind public key values 385 to subjects. The binding is asserted by having a trusted CA 386 digitally sign each certificate. The CA may base this assertion upon 387 technical means (a.k.a., proof of posession through a challenge- 388 response protocol), presentation of the private key, or on an 389 assertion by the subject. A certificate has a limited valid lifetime 390 which is indicated in its signed contents. Because a certificate's 391 signature and timeliness can be independently checked by a 392 certificate-using client, certificates can be distributed via 393 untrusted communications and server systems, and can be cached in 394 unsecured storage in certificate-using systems. 396 ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8, which was 397 first published in 1988 as part of the X.500 Directory 398 recommendations, defines a standard certificate format [X.509]. The 399 certificate format in the 1988 standard is called the version 1 (v1) 400 format. When X.500 was revised in 1993, two more fields were added, 401 resulting in the version 2 (v2) format. 403 The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993, 404 include specifications for a public key infrastructure based on X.509 405 v1 certificates [RFC 1422]. The experience gained in attempts to 406 deploy RFC 1422 made it clear that the v1 and v2 certificate formats 407 are deficient in several respects. Most importantly, more fields 408 were needed to carry information which PEM design and implementation 409 experience has proven necessary. In response to these new 410 requirements, ISO/IEC/ITU and ANSI X9 developed the X.509 version 3 411 (v3) certificate format. The v3 format extends the v2 format by 412 adding provision for additional extension fields. Particular 413 extension field types may be specified in standards or may be defined 414 and registered by any organization or community. In June 1996, 415 standardization of the basic v3 format was completed [X.509]. 417 ISO/IEC/ITU and ANSI X9 have also developed standard extensions for 418 use in the v3 extensions field [X.509][X9.55]. These extensions can 419 convey such data as additional subject identification information, 420 key attribute information, policy information, and certification path 421 constraints. 423 However, the ISO/IEC/ITU and ANSI X9 standard extensions are very 424 broad in their applicability. In order to develop interoperable 425 implementations of X.509 v3 systems for Internet use, it is necessary 426 to specify a profile for use of the X.509 v3 extensions tailored for 427 the Internet. It is one goal of this document to specify a profile 428 for Internet WWW, electronic mail, and IPsec applications. 429 Environments with additional requirements may build on this profile 430 or may replace it. 432 3.2 Certification Paths and Trust 434 A user of a security service requiring knowledge of a public key 435 generally needs to obtain and validate a certificate containing the 436 required public key. If the public-key user does not already hold an 437 assured copy of the public key of the CA that signed the certificate, 438 the CA's name, and related information (such as the validity period 439 or name constraints), then it might need an additional certificate to 440 obtain that public key. In general, a chain of multiple certificates 441 may be needed, comprising a certificate of the public key owner (the 442 end entity) signed by one CA, and zero or more additional 443 certificates of CAs signed by other CAs. Such chains, called 444 certification paths, are required because a public key user is only 445 initialized with a limited number of assured CA public keys. 447 There are different ways in which CAs might be configured in order 448 for public key users to be able to find certification paths. For 449 PEM, RFC 1422 defined a rigid hierarchical structure of CAs. There 450 are three types of PEM certification authority: 452 (a) Internet Policy Registration Authority (IPRA): This 453 authority, operated under the auspices of the Internet Society, 454 acts as the root of the PEM certification hierarchy at level 1. 455 It issues certificates only for the next level of authorities, 456 PCAs. All certification paths start with the IPRA. 458 (b) Policy Certification Authorities (PCAs): PCAs are at level 2 459 of the hierarchy, each PCA being certified by the IPRA. A PCA 460 shall establish and publish a statement of its policy with respect 461 to certifying users or subordinate certification authorities. 462 Distinct PCAs aim to satisfy different user needs. For example, 463 one PCA (an organizational PCA) might support the general 464 electronic mail needs of commercial organizations, and another PCA 465 (a high-assurance PCA) might have a more stringent policy designed 466 for satisfying legally binding digital signature requirements. 468 (c) Certification Authorities (CAs): CAs are at level 3 of the 469 hierarchy and can also be at lower levels. Those at level 3 are 470 certified by PCAs. CAs represent, for example, particular 471 organizations, particular organizational units (e.g., departments, 472 groups, sections), or particular geographical areas. 474 RFC 1422 furthermore has a name subordination rule which requires 475 that a CA can only issue certificates for entities whose names are 476 subordinate (in the X.500 naming tree) to the name of the CA itself. 477 The trust associated with a PEM certification path is implied by the 478 PCA name. The name subordination rule ensures that CAs below the PCA 479 are sensibly constrained as to the set of subordinate entities they 480 can certify (e.g., a CA for an organization can only certify entities 481 in that organization's name tree). Certificate user systems are able 482 to mechanically check that the name subordination rule has been 483 followed. 485 The RFC 1422 uses the X.509 v1 certificate formats. The limitations 486 of X.509 v1 required imposition of several structural restrictions to 487 clearly associate policy information or restrict the utility of 488 certificates. These restrictions included: 490 (a) a pure top-down hierarchy, with all certification paths 491 starting from IPRA; 493 (b) a naming subordination rule restricting the names of a CA's 494 subjects; and 496 (c) use of the PCA concept, which requires knowledge of individual 497 PCAs to be built into certificate chain verification logic. 498 Knowledge of individual PCAs was required to determine if a chain 499 could be accepted. 501 With X.509 v3, most of the requirements addressed by RFC 1422 can be 502 addressed using certificate extensions, without a need to restrict 503 the CA structures used. In particular, the certificate extensions 504 relating to certificate policies obviate the need for PCAs and the 505 constraint extensions obviate the need for the name subordination 506 rule. As a result, this document supports a more flexible 507 architecture, including: 509 (a) Certification paths may start with a public key of a CA in a 510 user's own domain, or with the public key of the top of a 511 hierarchy. Starting with the public key of a CA in a user's own 512 domain has certain advantages. In some environments, the local 513 domain is the most trusted. 515 (b) Name constraints may be imposed through explicit inclusion of 516 a name constraints extension in a certificate, but are not 517 required. 519 (c) Policy extensions and policy mappings replace the PCA 520 concept, which permits a greater degree of automation. The 521 application can determine if the certification path is acceptable 522 based on the contents of the certificates instead of a priori 523 knowledge of PCAs. This permits automation of certificate chain 524 processing. 526 3.3 Revocation 528 When a certificate is issued, it is expected to be in use for its 529 entire validity period. However, various circumstances may cause a 530 certificate to become invalid prior to the expiration of the validity 531 period. Such circumstances include change of name, change of 532 association between subject and CA (e.g., an employee terminates 533 employment with an organization), and compromise or suspected 534 compromise of the corresponding private key. Under such 535 circumstances, the CA needs to revoke the certificate. 537 X.509 defines one method of certificate revocation. This method 538 involves each CA periodically issuing a signed data structure called 539 a certificate revocation list (CRL). A CRL is a time stamped list 540 identifying revoked certificates which is signed by a CA and made 541 freely available in a public repository. Each revoked certificate is 542 identified in a CRL by its certificate serial number. When a 543 certificate-using system uses a certificate (e.g., for verifying a 544 remote user's digital signature), that system not only checks the 545 certificate signature and validity but also acquires a suitably- 546 recent CRL and checks that the certificate serial number is not on 547 that CRL. The meaning of "suitably-recent" may vary with local 548 policy, but it usually means the most recently-issued CRL. A CA 549 issues a new CRL on a regular periodic basis (e.g., hourly, daily, or 550 weekly). An entry is added to the CRL as part of the next update 551 following notification of revocation. An entry may be removed from 552 the CRL after appearing on one regularly scheduled CRL issued beyond 553 the revoked certificate's validity period. 555 An advantage of this revocation method is that CRLs may be 556 distributed by exactly the same means as certificates themselves, 557 namely, via untrusted communications and server systems. 559 One limitation of the CRL revocation method, using untrusted 560 communications and servers, is that the time granularity of 561 revocation is limited to the CRL issue period. For example, if a 562 revocation is reported now, that revocation will not be reliably 563 notified to certificate-using systems until the next periodic CRL is 564 issued -- this may be up to one hour, one day, or one week depending 565 on the frequency that the CA issues CRLs. 567 As with the X.509 v3 certificate format, in order to facilitate 568 interoperable implementations from multiple vendors, the X.509 v2 CRL 569 format needs to be profiled for Internet use. It is one goal of this 570 document to specify that profile. However, this profile does not 571 require CAs to issue CRLs. Message formats and protocols supporting 572 on-line revocation notification may be defined in other PKIX 573 specifications. On-line methods of revocation notification may be 574 applicable in some environments as an alternative to the X.509 CRL. 575 On-line revocation checking may significantly reduce the latency 576 between a revocation report and the distribution of the information 577 to relying parties. Once the CA accepts the report as authentic and 578 valid, any query to the on-line service will correctly reflect the 579 certificate validation impacts of the revocation. However, these 580 methods impose new security requirements: the certificate validator 581 needs to trust the on-line validation service while the repository 582 does not need to be trusted. 584 3.4 Operational Protocols 586 Operational protocols are required to deliver certificates and CRLs 587 (or status information) to certificate using client systems. 588 Provision is needed for a variety of different means of certificate 589 and CRL delivery, including distribution procedures based on LDAP, 590 HTTP, FTP, and X.500. Operational protocols supporting these 591 functions are defined in other PKIX specifications. These 592 specifications may include definitions of message formats and 593 procedures for supporting all of the above operational environments, 594 including definitions of or references to appropriate MIME content 595 types. 597 3.5 Management Protocols 599 Management protocols are required to support on-line interactions 600 between PKI user and management entities. For example, a management 601 protocol might be used between a CA and a client system with which a 602 key pair is associated, or between two CAs which cross-certify each 603 other. The set of functions which potentially need to be supported 604 by management protocols include: 606 (a) registration: This is the process whereby a user first makes 607 itself known to a CA (directly, or through an RA), prior to that 608 CA issuing a certificate or certificates for that user. 610 (b) initialization: Before a client system can operate securely 611 it is necessary to install key materials which have the 612 appropriate relationship with keys stored elsewhere in the 613 infrastructure. For example, the client needs to be securely 614 initialized with the public key and other assured information of 615 the trusted CA(s), to be used in validating certificate paths. 616 Furthermore, a client typically needs to be initialized with its 617 own key pair(s). 619 (c) certification: This is the process in which a CA issues a 620 certificate for a user's public key, and returns that certificate 621 to the user's client system and/or posts that certificate in a 622 repository. 624 (d) key pair recovery: As an option, user client key materials 625 (e.g., a user's private key used for encryption purposes) may be 626 backed up by a CA or a key backup system. If a user needs to 627 recover these backed up key materials (e.g., as a result of a 628 forgotten password or a lost key chain file), an on-line protocol 629 exchange may be needed to support such recovery. 631 (e) key pair update: All key pairs need to be updated regularly, 632 i.e., replaced with a new key pair, and new certificates issued. 634 (f) revocation request: An authorized person advises a CA of an 635 abnormal situation requiring certificate revocation. 637 (g) cross-certification: Two CAs exchange information used in 638 establishing a cross-certificate. A cross-certificate is a 639 certificate issued by one CA to another CA which contains a CA 640 signature key used for issuing certificates. 642 Note that on-line protocols are not the only way of implementing the 643 above functions. For all functions there are off-line methods of 644 achieving the same result, and this specification does not mandate 645 use of on-line protocols. For example, when hardware tokens are 646 used, many of the functions may be achieved as part of the physical 647 token delivery. Furthermore, some of the above functions may be 648 combined into one protocol exchange. In particular, two or more of 649 the registration, initialization, and certification functions can be 650 combined into one protocol exchange. 652 The PKIX series of specifications may define a set of standard 653 message formats supporting the above functions in future 654 specifications. In that case, the protocols for conveying these 655 messages in different environments (e.g., on-line, file transfer, e- 656 mail, and WWW) will also be described in those specifications. 658 4 Certificate and Certificate Extensions Profile 660 This section presents a profile for public key certificates that will 661 foster interoperability and a reusable PKI. This section is based 662 upon the X.509 v3 certificate format and the standard certificate 663 extensions defined in [X.509]. The ISO/IEC/ITU documents use the 664 1993 version of ASN.1; while this document uses the 1988 ASN.1 665 syntax, the encoded certificate and standard extensions are 666 equivalent. This section also defines private extensions required to 667 support a PKI for the Internet community. 669 Certificates may be used in a wide range of applications and 670 environments covering a broad spectrum of interoperability goals and 671 a broader spectrum of operational and assurance requirements. The 672 goal of this document is to establish a common baseline for generic 673 applications requiring broad interoperability and limited special 674 purpose requirements. In particular, the emphasis will be on 675 supporting the use of X.509 v3 certificates for informal Internet 676 electronic mail, IPsec, and WWW applications. 678 4.1 Basic Certificate Fields 680 The X.509 v3 certificate basic syntax is as follows. For signature 681 calculation, the certificate is encoded using the ASN.1 distinguished 682 encoding rules (DER) [X.208]. ASN.1 DER encoding is a tag, length, 683 value encoding system for each element. 685 Certificate ::= SEQUENCE { 686 tbsCertificate TBSCertificate, 687 signatureAlgorithm AlgorithmIdentifier, 688 signatureValue BIT STRING } 690 TBSCertificate ::= SEQUENCE { 691 version [0] EXPLICIT Version DEFAULT v1, 692 serialNumber CertificateSerialNumber, 693 signature AlgorithmIdentifier, 694 issuer Name, 695 validity Validity, 696 subject Name, 697 subjectPublicKeyInfo SubjectPublicKeyInfo, 698 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 699 -- If present, version shall be v2 or v3 700 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 701 -- If present, version shall be v2 or v3 702 extensions [3] EXPLICIT Extensions OPTIONAL 703 -- If present, version shall be v3 704 } 706 Version ::= INTEGER { v1(0), v2(1), v3(2) } 708 CertificateSerialNumber ::= INTEGER 710 Validity ::= SEQUENCE { 711 notBefore Time, 712 notAfter Time } 714 Time ::= CHOICE { 715 utcTime UTCTime, 716 generalTime GeneralizedTime } 718 UniqueIdentifier ::= BIT STRING 720 SubjectPublicKeyInfo ::= SEQUENCE { 721 algorithm AlgorithmIdentifier, 722 subjectPublicKey BIT STRING } 724 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 726 Extension ::= SEQUENCE { 727 extnID OBJECT IDENTIFIER, 728 critical BOOLEAN DEFAULT FALSE, 729 extnValue OCTET STRING } 731 The following items describe the X.509 v3 certificate for use in the 732 Internet. 734 4.1.1 Certificate Fields 736 The Certificate is a SEQUENCE of three required fields. The fields 737 are described in detail in the following subsections. 739 4.1.1.1 tbsCertificate 741 The field contains the names of the subject and issuer, a public key 742 associated with the subject, a validity period, and other associated 743 information. The fields are described in detail in section 4.1.2; 744 the tbscertificate may also include extensions which are described in 745 section 4.2. 747 4.1.1.2 signatureAlgorithm 749 The signatureAlgorithm field contains the identifier for the 750 cryptographic algorithm used by the CA to sign this certificate. 751 [PKIX ALGS] lists the supported signature algorithms. 753 An algorithm identifier is defined by the following ASN.1 structure: 755 AlgorithmIdentifier ::= SEQUENCE { 756 algorithm OBJECT IDENTIFIER, 757 parameters ANY DEFINED BY algorithm OPTIONAL } 759 The algorithm identifier is used to identify a cryptographic 760 algorithm. The OBJECT IDENTIFIER component identifies the algorithm 761 (such as DSA with SHA-1). The contents of the optional parameters 762 field will vary according to the algorithm identified. [PKIX ALGS] 763 lists the supported algorithms for this specification. 765 This field MUST contain the same algorithm identifier as the 766 signature field in the sequence tbsCertificate (see sec. 4.1.2.3). 768 4.1.1.3 signatureValue 770 The signatureValue field contains a digital signature computed upon 771 the ASN.1 DER encoded tbsCertificate. The ASN.1 DER encoded 772 tbsCertificate is used as the input to the signature function. This 773 signature value is then ASN.1 encoded as a BIT STRING and included in 774 the Certificate's signature field. The details of this process are 775 specified for each of the supported algorithms in [PKIX ALGS]. 777 By generating this signature, a CA certifies the validity of the 778 information in the tbsCertificate field. In particular, the CA 779 certifies the binding between the public key material and the subject 780 of the certificate. 782 4.1.2 TBSCertificate 784 The sequence TBSCertificate contains information associated with the 785 subject of the certificate and the CA who issued it. Every 786 TBSCertificate contains the names of the subject and issuer, a public 787 key associated with the subject, a validity period, a version number, 788 and a serial number; some may contain optional unique identifier 789 fields. The remainder of this section describes the syntax and 790 semantics of these fields. A TBSCertificate may also include 791 extensions. Extensions for the Internet PKI are described in Section 792 4.2. 794 4.1.2.1 Version 796 This field describes the version of the encoded certificate. When 797 extensions are used, as expected in this profile, use X.509 version 3 798 (value is 2). If no extensions are present, but a UniqueIdentifier 799 is present, use version 2 (value is 1). If only basic fields are 800 present, use version 1 (the value is omitted from the certificate as 801 the default value). 803 Implementations SHOULD be prepared to accept any version certificate. 804 At a minimum, conforming implementations MUST recognize version 3 805 certificates. 807 Generation of version 2 certificates is not expected by 808 implementations based on this profile. 810 4.1.2.2 Serial number 812 The serial number MUST be a positive integer assigned by the CA to 813 each certificate. It MUST be unique for each certificate issued by a 814 given CA (i.e., the issuer name and serial number identify a unique 815 certificate). CAs MUST force the serialNumber to be a non-negative 816 integer. 818 Given the uniqueness requirements above serial numbers can be 819 expected to contain long integers. Certificate users MUST be able to 820 handle serialNumber values up to 20 octets. Conformant CAs MUST NOT 821 use serialNumber values longer than 20 octets. 823 Note: Non-conforming CAs may issue certificates with serial numbers 824 that are negative, or zero. Certificate users SHOULD be prepared to 825 handle such certificates. 827 4.1.2.3 Signature 829 This field contains the algorithm identifier for the algorithm used 830 by the CA to sign the certificate. 832 This field MUST contain the same algorithm identifier as the 833 signatureAlgorithm field in the sequence Certificate (see sec. 834 4.1.1.2). The contents of the optional parameters field will vary 835 according to the algorithm identified. [PKIX ALGS] lists the 836 supported signature algorithms. 838 4.1.2.4 Issuer 840 The issuer field identifies the entity who has signed and issued the 841 certificate. The issuer field MUST contain a non-empty distinguished 842 name (DN). The issuer field is defined as the X.501 type Name. 843 [X.501] Name is defined by the following ASN.1 structures: 845 Name ::= CHOICE { 846 RDNSequence } 848 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 850 RelativeDistinguishedName ::= 851 SET OF AttributeTypeAndValue 853 AttributeTypeAndValue ::= SEQUENCE { 854 type AttributeType, 855 value AttributeValue } 857 AttributeType ::= OBJECT IDENTIFIER 858 AttributeValue ::= ANY DEFINED BY AttributeType 860 DirectoryString ::= CHOICE { 861 teletexString TeletexString (SIZE (1..MAX)), 862 printableString PrintableString (SIZE (1..MAX)), 863 universalString UniversalString (SIZE (1..MAX)), 864 utf8String UTF8String (SIZE (1.. MAX)), 865 bmpString BMPString (SIZE (1..MAX)) } 867 The Name describes a hierarchical name composed of attributes, such 868 as country name, and corresponding values, such as US. The type of 869 the component AttributeValue is determined by the AttributeType; in 870 general it will be a DirectoryString. 872 The DirectoryString type is defined as a choice of PrintableString, 873 TeletexString, BMPString, UTF8String, and UniversalString. The 874 UTF8String encoding is the preferred encoding, and all certificates 875 issued after December 31, 2003 MUST use the UTF8String encoding of 876 DirectoryString (except as noted below). Until that date, conforming 877 CAs MUST choose from the following options when creating a 878 distinguished name, including their own: 880 (a) if the character set is sufficient, the string MAY be 881 represented as a PrintableString; 883 (b) failing (a), if the BMPString character set is sufficient the 884 string MAY be represented as a BMPString; and 886 (c) failing (a) and (b), the string MUST be represented as a 887 UTF8String. If (a) or (b) is satisfied, the CA MAY still choose 888 to represent the string as a UTF8String. 890 Exceptions to the December 31, 2003 UTF8 encoding requirements are as 891 follows: 893 (a) CAs MAY issue "name rollover" certificates to support an 894 orderly migration to UTF8String encoding. Such certificates would 895 include the CA's UTF8String encoded name as issuer and and the old 896 name encoding as subject, or vice-versa. 898 (b) As stated in section 4.1.2.6, the subject field MUST be 899 populated with a non-empty distinguished name matching the 900 contents of the issuer field in all certificates issued by the 901 subject CA regardless of encoding. 903 The TeletexString and UniversalString are included for backward 904 compatibility, and should not be used for certificates for new 905 subjects. However, these types may be used in certificates where the 906 name was previously established. Certificate users SHOULD be 907 prepared to receive certificates with these types. 909 In addition, many legacy implementations support names encoded in the 910 ISO 8859-1 character set (Latin1String) but tag them as 911 TeletexString. The Latin1String includes characters used in Western 912 European countries which are not part of the TeletexString charcter 913 set. Implementations that process TeletexString SHOULD be prepared 914 to handle the entire ISO 8859-1 character set.[ISO 8859-1] 916 As noted above, distinguished names are composed of attributes. This 917 specification does not restrict the set of attribute types that may 918 appear in names. However, conforming implementations MUST be 919 prepared to receive certificates with issuer names containing the set 920 of attribute types defined below. This specification also recommends 921 support for additional attribute types. 923 Standard sets of attributes have been defined in the X.500 series of 924 specifications.[X.520] Implementations of this specification MUST be 925 prepared to receive the following standard attribute types in issuer 926 and subject (see 4.1.2.6) names: 928 * country, 929 * organization, 930 * organizational-unit, 931 * distinguished name qualifier, 932 * state or province name, 933 * common name (e.g., "Susan Housley"), and 934 * serial number. 936 In addition, implementations of this specification SHOULD be prepared 937 to receive the following standard attribute types in issuer and 938 subject names: 940 * locality, 941 * title, 942 * surname, 943 * given name, 944 * initials, 945 * pseudonym, and 946 * generation qualifier (e.g., "Jr.", "3rd", or "IV"). 948 The syntax and associated object identifiers (OIDs) for these 949 attribute types are provided in the ASN.1 modules in Appendices A and 950 B. 952 In addition, implementations of this specification MUST be prepared 953 to receive the domainComponent attribute, as defined in [RFC 2247]. 954 The Domain (Nameserver) System (DNS) provides a hierarchical resource 955 labeling system. This attribute provides is a convenient mechanism 956 for organizations that wish to use DNs that parallel their DNS names. 957 This is not a replacement for the dNSName component of the 958 alternative name field. Implementations are not required to convert 959 such names into DNS names. The syntax and associated OID for this 960 attribute type is provided in the ASN.1 modules in Appendices A and 961 B. 963 Certificate users MUST be prepared to process the issuer 964 distinguished name and subject distinguished name (see sec. 4.1.2.6) 965 fields to perform name chaining for certification path validation 966 (see section 6). Name chaining is performed by matching the issuer 967 distinguished name in one certificate with the subject name in a CA 968 certificate. 970 This specification requires only a subset of the name comparison 971 functionality specified in the X.500 series of specifications. The 972 requirements for conforming implementations are as follows: 974 (a) attribute values encoded in different types (e.g., 975 PrintableString and BMPString) may be assumed to represent 976 different strings; 978 (b) attribute values in types other than PrintableString are case 979 sensitive (this permits matching of attribute values as binary 980 objects); 982 (c) attribute values in PrintableString are not case sensitive 983 (e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and 985 (d) attribute values in PrintableString are compared after 986 removing leading and trailing white space and converting internal 987 substrings of one or more consecutive white space characters to a 988 single space. 990 These name comparison rules permit a certificate user to validate 991 certificates issued using languages or encodings unfamiliar to the 992 certificate user. 994 In addition, implementations of this specification MAY use these 995 comparison rules to process unfamiliar attribute types for name 996 chaining. This allows implementations to process certificates with 997 unfamiliar attributes in the issuer name. 999 Note that the comparison rules defined in the X.500 series of 1000 specifications indicate that the character sets used to encode data 1001 in distinguished names are irrelevant. The characters themselves are 1002 compared without regard to encoding. Implementations of the profile 1003 are permitted to use the comparison algorithm defined in the X.500 1004 series. Such an implementation will recognize a superset of name 1005 matches recognized by the algorithm specified above. 1007 4.1.2.5 Validity 1009 The certificate validity period is the time interval during which the 1010 CA warrants that it will maintain information about the status of the 1011 certificate. The field is represented as a SEQUENCE of two dates: 1012 the date on which the certificate validity period begins (notBefore) 1013 and the date on which the certificate validity period ends 1014 (notAfter). Both notBefore and notAfter may be encoded as UTCTime or 1015 GeneralizedTime. 1017 CAs conforming to this profile MUST always encode certificate 1018 validity dates through the year 2049 as UTCTime; certificate validity 1019 dates in 2050 or later MUST be encoded as GeneralizedTime. 1021 The validity period for a certificate is the period of time from 1022 notBefore through notAfter, inclusive. 1024 4.1.2.5.1 UTCTime 1026 The universal time type, UTCTime, is a standard ASN.1 type intended 1027 for representation of dates and time. UTCTime specifies the year 1028 through the two low order digits and time is specified to the 1029 precision of one minute or one second. UTCTime includes either Z 1030 (for Zulu, or Greenwich Mean Time) or a time differential. 1032 For the purposes of this profile, UTCTime values MUST be expressed 1033 Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are 1034 YYMMDDHHMMSSZ), even where the number of seconds is zero. Conforming 1035 systems MUST interpret the year field (YY) as follows: 1037 Where YY is greater than or equal to 50, the year shall be 1038 interpreted as 19YY; and 1040 Where YY is less than 50, the year shall be interpreted as 20YY. 1042 4.1.2.5.2 GeneralizedTime 1044 The generalized time type, GeneralizedTime, is a standard ASN.1 type 1045 for variable precision representation of time. Optionally, the 1046 GeneralizedTime field can include a representation of the time 1047 differential between local and Greenwich Mean Time. 1049 For the purposes of this profile, GeneralizedTime values MUST be 1050 expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e., 1051 times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. 1052 GeneralizedTime values MUST NOT include fractional seconds. 1054 4.1.2.6 Subject 1056 The subject field identifies the entity associated with the public 1057 key stored in the subject public key field. The subject name may be 1058 carried in the subject field and/or the subjectAltName extension. If 1059 the subject is a CA (e.g., the basic constraints extension, as 1060 discussed in 4.2.1.10, is present and the value of cA is TRUE,) then 1061 the subject field MUST be populated with a non-empty distinguished 1062 name matching the contents of the issuer field (see sec. 4.1.2.4) in 1063 all certificates issued by the subject CA. If subject naming 1064 information is present only in the subjectAltName extension (e.g., a 1065 key bound only to an email address or URI), then the subject name 1066 MUST be an empty sequence and the subjectAltName extension MUST be 1067 critical. 1069 Where it is non-empty, the subject field MUST contain an X.500 1070 distinguished name (DN). The DN MUST be unique for each subject 1071 entity certified by the one CA as defined by the issuer name field. A 1072 CA may issue more than one certificate with the same DN to the same 1073 subject entity. 1075 The subject name field is defined as the X.501 type Name. 1076 Implementation requirements for this field are those defined for the 1077 issuer field (see sec. 4.1.2.4). When encoding attribute values of 1078 type DirectoryString, the encoding rules for the issuer field MUST be 1079 implemented. Implementations of this specification MUST be prepared 1080 to receive subject names containing the attribute types required for 1081 the issuer field. Implementations of this specification SHOULD be 1082 prepared to receive subject names containing the recommended 1083 attribute types for the issuer field. The syntax and associated 1084 object identifiers (OIDs) for these attribute types are provided in 1085 the ASN.1 modules in Appendices A and B. Implementations of this 1086 specification MAY use these comparison rules to process unfamiliar 1087 attribute types (i.e., for name chaining). This allows 1088 implementations to process certificates with unfamiliar attributes in 1089 the subject name. 1091 In addition, legacy implementations exist where an RFC 822 name is 1092 embedded in the subject distinguished name as an EmailAddress 1093 attribute. The attribute value for EmailAddress is of type IA5String 1094 to permit inclusion of the character '@', which is not part of the 1095 PrintableString character set. EmailAddress attribute values are not 1096 case sensitive (e.g., "fanfeedback@redsox.com" is the same as 1097 "FANFEEDBACK@REDSOX.COM"). 1099 Conforming implementations generating new certificates with 1100 electronic mail addresses MUST use the rfc822Name in the subject 1101 alternative name field (see sec. 4.2.1.7) to describe such 1102 identities. Simultaneous inclusion of the EmailAddress attribute in 1103 the subject distinguished name to support legacy implementations is 1104 deprecated but permitted. 1106 4.1.2.7 Subject Public Key Info 1108 This field is used to carry the public key and identify the algorithm 1109 with which the key is used. The algorithm is identified using the 1110 AlgorithmIdentifier structure specified in section 4.1.1.2. The 1111 object identifiers for the supported algorithms and the methods for 1112 encoding the public key materials (public key and parameters) are 1113 specified in [PKIX ALGS]. 1115 4.1.2.8 Unique Identifiers 1117 These fields may only appear if the version is 2 or 3 (see sec. 1118 4.1.2.1). The subject and issuer unique identifiers are present in 1119 the certificate to handle the possibility of reuse of subject and/or 1120 issuer names over time. This profile recommends that names not be 1121 reused for different entities and that Internet certificates not make 1122 use of unique identifiers. CAs conforming to this profile SHOULD NOT 1123 generate certificates with unique identifiers. Applications 1124 conforming to this profile SHOULD be capable of parsing unique 1125 identifiers and making comparisons. 1127 4.1.2.9 Extensions 1129 This field may only appear if the version is 3 (see sec. 4.1.2.1). 1130 If present, this field is a SEQUENCE of one or more certificate 1131 extensions. The format and content of certificate extensions in the 1132 Internet PKI is defined in section 4.2. 1134 4.2 Standard Certificate Extensions 1136 The extensions defined for X.509 v3 certificates provide methods for 1137 associating additional attributes with users or public keys and for 1138 managing the certification hierarchy. The X.509 v3 certificate 1139 format also allows communities to define private extensions to carry 1140 information unique to those communities. Each extension in a 1141 certificate may be designated as critical or non-critical. A 1142 certificate using system MUST reject the certificate if it encounters 1143 a critical extension it does not recognize; however, a non-critical 1144 extension may be ignored if it is not recognized. The following 1145 sections present recommended extensions used within Internet 1146 certificates and standard locations for information. Communities may 1147 elect to use additional extensions; however, caution should be 1148 exercised in adopting any critical extensions in certificates which 1149 might prevent use in a general context. 1151 Each extension includes an OID and an ASN.1 structure. When an 1152 extension appears in a certificate, the OID appears as the field 1153 extnID and the corresponding ASN.1 encoded structure is the value of 1154 the octet string extnValue. Only one instance of a particular 1155 extension may appear in a particular certificate. For example, a 1156 certificate may contain only one authority key identifier extension 1157 (see sec. 4.2.1.1). An extension includes the boolean critical, with 1158 a default value of FALSE. The text for each extension specifies the 1159 acceptable values for the critical field. 1161 Conforming CAs MUST support key identifiers (see sec. 4.2.1.1 and 1162 4.2.1.2), basic constraints (see sec. 4.2.1.10), key usage (see sec. 1163 4.2.1.3), and certificate policies (see sec. 4.2.1.5) extensions. If 1164 the CA issues certificates with an empty sequence for the subject 1165 field, the CA MUST support the subject alternative name extension 1166 (see sec. 4.2.1.7). Support for the remaining extensions is 1167 OPTIONAL. Conforming CAs may support extensions that are not 1168 identified within this specification; certificate issuers are 1169 cautioned that marking such extensions as critical may inhibit 1170 interoperability. 1172 At a minimum, applications conforming to this profile MUST recognize 1173 the following extensions: key usage (see sec. 4.2.1.3), certificate 1174 policies (see sec. 4.2.1.5), the subject alternative name (see sec. 1175 4.2.1.7), basic constraints (see sec. 4.2.1.10), name constraints 1176 (see sec. 4.2.1.11), policy constraints (see sec. 4.2.1.12), extended 1177 key usage (see sec. 4.2.1.13), and inhibit any-policy (see sec. 1178 4.2.1.15). 1180 In addition, this profile RECOMMENDS application support for the 1181 authority and subject key identifier (see sec. 4.2.1.1 and 4.2.1.2), 1182 and policy mapping (see sec. 4.2.1.6) extensions. 1184 4.2.1 Standard Extensions 1186 This section identifies standard certificate extensions defined in 1187 [X.509] for use in the Internet PKI. Each extension is associated 1188 with an OID defined in [X.509]. These OIDs are members of the id-ce 1189 arc, which is defined by the following: 1191 id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 1193 4.2.1.1 Authority Key Identifier 1195 The authority key identifier extension provides a means of 1196 identifying the public key corresponding to the private key used to 1197 sign a certificate. This extension is used where an issuer has 1198 multiple signing keys (either due to multiple concurrent key pairs or 1199 due to changeover). The identification may be based on either the 1200 key identifier (the subject key identifier in the issuer's 1201 certificate) or on the issuer name and serial number. 1203 The keyIdentifier field of the authorityKeyIdentifier extension MUST 1204 be included in all certificates generated by conforming CAs to 1205 facilitate chain building. There is one exception; where a CA 1206 distributes its public key in the form of a "self-signed" 1207 certificate, the authority key identifier may be omitted. In this 1208 case, the subject and authority key identifiers would be identical. 1210 The value of the keyIdentifier field SHOULD be derived from the 1211 public key used to verify the certificate's signature or a method 1212 that generates unique values. Two common methods for generating key 1213 identifiers from the public key are described in (sec. 4.2.1.2). One 1214 common method for generating unique values is described in (sec. 1215 4.2.1.2). Where a key identifier has not been previously 1216 established, this specification recommends use of one of these 1217 methods for generating keyIdentifiers. 1219 This profile recommends support for the key identifier method by all 1220 certificate users. 1222 This extension MUST NOT be marked critical. 1224 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 1226 AuthorityKeyIdentifier ::= SEQUENCE { 1227 keyIdentifier [0] KeyIdentifier OPTIONAL, 1228 authorityCertIssuer [1] GeneralNames OPTIONAL, 1229 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 1231 KeyIdentifier ::= OCTET STRING 1233 4.2.1.2 Subject Key Identifier 1235 The subject key identifier extension provides a means of identifying 1236 certificates that contain a particular public key. 1238 To facilitate chain building, this extension MUST appear in all con- 1239 forming CA certificates, that is, all certificates including the 1240 basic constraints extension (see sec. 4.2.1.10) where the value of cA 1241 is TRUE. The value of the subject key identifier MUST be the value 1242 placed in the key identifier field of the Authority Key Identifier 1243 extension (see sec. 4.2.1.1) of certificates issued by the subject of 1244 this certificate. 1246 For CA certificates, subject key identifiers SHOULD be derived from 1247 the public key or a method that generates unique values. The key 1248 identifier is an explicit value placed in the certificate by the 1249 issuer, not a value generated by a certificate user. Two common 1250 methods for generating key identifiers from the public key are: 1252 (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the 1253 value of the BIT STRING subjectPublicKey (excluding the tag, 1254 length, and number of unused bits). 1256 (2) The keyIdentifier is composed of a four bit type field with 1257 the value 0100 followed by the least significant 60 bits of the 1258 SHA-1 hash of the value of the BIT STRING subjectPublicKey. 1260 One common method for generating unique values is a monotonically 1261 increasing sequence of integers. 1263 For end entity certificates, the subject key identifier extension 1264 provides a means for identifying certificates containing the 1265 particular public key used in an application. Where an end entity has 1266 obtained multiple certificates, especially from multiple CAs, the 1267 subject key identifier provides a means to quickly identify the set 1268 of certificates containing a particular public key. To assist 1269 applications in identifying the appropriate end entity certificate, 1270 this extension SHOULD be included in all end entity certificates. 1272 For end entity certificates, subject key identifiers SHOULD be 1273 derived from the public key. Two common methods for generating key 1274 identifiers from the public key are identifed above. 1276 Where a key identifier has not been previously established, this 1277 specification recommends use of one of these methods for generating 1278 keyIdentifiers. 1280 This extension MUST NOT be marked critical. 1282 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 1284 SubjectKeyIdentifier ::= KeyIdentifier 1286 4.2.1.3 Key Usage 1288 The key usage extension defines the purpose (e.g., encipherment, 1289 signature, certificate signing) of the key contained in the 1290 certificate. The usage restriction might be employed when a key that 1291 could be used for more than one operation is to be restricted. For 1292 example, when an RSA key should be used only for signing, the 1293 digitalSignature and/or nonRepudiation bits would be asserted. 1294 Likewise, when an RSA key should be used only for key management, the 1295 keyEncipherment bit would be asserted. When used, this extension 1296 SHOULD be marked critical. 1298 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 1300 KeyUsage ::= BIT STRING { 1301 digitalSignature (0), 1302 nonRepudiation (1), 1303 keyEncipherment (2), 1304 dataEncipherment (3), 1305 keyAgreement (4), 1306 keyCertSign (5), 1307 cRLSign (6), 1308 encipherOnly (7), 1309 decipherOnly (8) } 1311 Bits in the KeyUsage type are used as follows: 1313 The digitalSignature bit is asserted when the subject public key 1314 is used with a digital signature mechanism to support security 1315 services other than non-repudiation (bit 1), certificate signing 1316 (bit 5), or revocation information signing (bit 6). Digital 1317 signature mechanisms are often used for entity authentication and 1318 data origin authentication with integrity. 1320 The nonRepudiation bit is asserted when the subject public key is 1321 used to verify digital signatures used to provide a non- 1322 repudiation service which protects against the signing entity 1323 falsely denying some action, excluding certificate or CRL signing. 1324 In the case of later conflict, a reliable third party may 1325 determine the authenticity of the signed data. 1327 Further distinctions between the digitalSignature and 1328 nonRepudiation bits may be provided in specific certificate 1329 policies. 1331 The keyEncipherment bit is asserted when the subject public key is 1332 used for key transport. For example, when an RSA key is to be 1333 used for key management, then this bit shall asserted. 1335 The dataEncipherment bit is asserted when the subject public key 1336 is used for enciphering user data, other than cryptographic keys. 1338 The keyAgreement bit is asserted when the subject public key is 1339 used for key agreement. For example, when a Diffie-Hellman key is 1340 to be used for key management, then this bit shall asserted. 1342 The keyCertSign bit is asserted when the subject public key is 1343 used for verifying a signature on certificates. This bit may only 1344 be asserted in CA certificates. If the keyCertSign bit is 1345 asserted, then the cA bit in the basic constraints extension (see 1346 4.2.1.10) MUST also be asserted. If the keyCertSign bit is not 1347 asserted, then the cA bit in the basic constraints extension MUST 1348 NOT be asserted. 1350 The cRLSign bit is asserted when the subject public key is used 1351 for verifying a signature on revocation information (e.g., a CRL). 1353 The meaning of the encipherOnly bit is undefined in the absence of 1354 the keyAgreement bit. When the encipherOnly bit is asserted and 1355 the keyAgreement bit is also set, the subject public key may be 1356 used only for enciphering data while performing key agreement. 1358 The meaning of the decipherOnly bit is undefined in the absence of 1359 the keyAgreement bit. When the decipherOnly bit is asserted and 1360 the keyAgreement bit is also set, the subject public key may be 1361 used only for deciphering data while performing key agreement. 1363 This profile does not restrict the combinations of bits that may be 1364 set in an instantiation of the keyUsage extension. However, 1365 appropriate values for keyUsage extensions for particular algorithms 1366 are specified in [PKIX ALGS]. 1368 4.2.1.4 Private Key Usage Period 1370 This profile recommends against the use of this extension. CAs 1371 conforming to this profile MUST NOT generate certificates with 1372 critical private key usage period extensions. 1374 The private key usage period extension allows the certificate issuer 1375 to specify a different validity period for the private key than the 1376 certificate. This extension is intended for use with digital 1377 signature keys. This extension consists of two optional components, 1378 notBefore and notAfter. The private key associated with the 1379 certificate should not be used to sign objects before or after the 1380 times specified by the two components, respectively. CAs conforming 1381 to this profile MUST NOT generate certificates with private key usage 1382 period extensions unless at least one of the two components is 1383 present. 1385 Where used, notBefore and notAfter are represented as GeneralizedTime 1386 and MUST be specified and interpreted as defined in section 1387 4.1.2.5.2. 1389 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 1391 PrivateKeyUsagePeriod ::= SEQUENCE { 1392 notBefore [0] GeneralizedTime OPTIONAL, 1393 notAfter [1] GeneralizedTime OPTIONAL } 1395 4.2.1.5 Certificate Policies 1397 The certificate policies extension contains a sequence of one or more 1398 policy information terms, each of which consists of an object 1399 identifier (OID) and optional qualifiers. Optional qualifiers, which 1400 may be present, are not expected to change the definition of the 1401 policy. 1403 In an end-entity certificate, these policy information terms indicate 1404 the policy under which the certificate has been issued and the 1405 purposes for which the certificate may be used. In a CA certificate, 1406 these policy information terms limit the set of policies for 1407 certification paths which include this certificate. When a CA does 1408 not wish to limit the set of policies for certification paths which 1409 include this certificate, they may assert the special policy 1410 anyPolicy, with a value of {2 5 29 32 0}. 1412 Applications with specific policy requirements are expected to have a 1413 list of those policies which they will accept and to compare the 1414 policy OIDs in the certificate to that list. If this extension is 1415 critical, the path validation software MUST be able to interpret this 1416 extension (including the optional qualifier), or MUST reject the 1417 certificate. 1419 To promote interoperability, this profile RECOMMENDS that policy 1420 information terms consist of only an OID. Where an OID alone is 1421 insufficient, this profile strongly recommends that use of qualifiers 1422 be limited to those identified in this section. When qualifiers are 1423 used with the special policy anyPolicy, they MUST be limited to the 1424 qualifers identified in this section. 1426 This specification defines two policy qualifier types for use by 1427 certificate policy writers and certificate issuers. The qualifier 1428 types are the CPS Pointer and User Notice qualifiers. 1430 The CPS Pointer qualifier contains a pointer to a Certification 1431 Practice Statement (CPS) published by the CA. The pointer is in the 1432 form of a URI. Processing requirements for this qualifier are a 1433 local matter. No action is mandated by this specification regardless 1434 of the criticality value asserted for the extension. 1436 User notice is intended for display to a relying party when a 1437 certificate is used. The application software SHOULD display all 1438 user notices in all certificates of the certification path used, 1439 except that if a notice is duplicated only one copy need be 1440 displayed. To prevent such duplication, this qualifier SHOULD only 1441 be present in end-entity certificates and CA certificates issued to 1442 other organizations. 1444 The user notice has two optional fields: the noticeRef field and the 1445 explicitText field. 1447 The noticeRef field, if used, names an organization and 1448 identifies, by number, a particular textual statement prepared by 1449 that organization. For example, it might identify the 1450 organization "CertsRUs" and notice number 1. In a typical 1451 implementation, the application software will have a notice file 1452 containing the current set of notices for CertsRUs; the 1453 application will extract the notice text from the file and display 1454 it. Messages may be multilingual, allowing the software to select 1455 the particular language message for its own environment. 1457 An explicitText field includes the textual statement directly in 1458 the certificate. The explicitText field is a string with a 1459 maximum size of 200 characters. 1461 If both the noticeRef and explicitText options are included in the 1462 one qualifier and if the application software can locate the notice 1463 text indicated by the noticeRef option then that text should be 1464 displayed; otherwise, the explicitText string should be displayed. 1466 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 1468 anyPolicy OBJECT IDENTIFIER ::= {id-ce-certificate-policies 0} 1470 certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 1472 PolicyInformation ::= SEQUENCE { 1473 policyIdentifier CertPolicyId, 1474 policyQualifiers SEQUENCE SIZE (1..MAX) OF 1475 PolicyQualifierInfo OPTIONAL } 1477 CertPolicyId ::= OBJECT IDENTIFIER 1478 PolicyQualifierInfo ::= SEQUENCE { 1479 policyQualifierId PolicyQualifierId, 1480 qualifier ANY DEFINED BY policyQualifierId } 1482 -- policyQualifierIds for Internet policy qualifiers 1484 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 1485 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 1486 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 1488 PolicyQualifierId ::= 1489 OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) 1491 Qualifier ::= CHOICE { 1492 cPSuri CPSuri, 1493 userNotice UserNotice } 1495 CPSuri ::= IA5String 1497 UserNotice ::= SEQUENCE { 1498 noticeRef NoticeReference OPTIONAL, 1499 explicitText DisplayText OPTIONAL} 1501 NoticeReference ::= SEQUENCE { 1502 organization DisplayText, 1503 noticeNumbers SEQUENCE OF INTEGER } 1505 DisplayText ::= CHOICE { 1506 ia5String IA5String (SIZE (1..200)), 1507 visibleString VisibleString (SIZE (1..200)), 1508 bmpString BMPString (SIZE (1..200)), 1509 utf8String UTF8String (SIZE (1..200)) } 1511 4.2.1.6 Policy Mappings 1513 This extension is used in CA certificates. It lists one or more 1514 pairs of OIDs; each pair includes an issuerDomainPolicy and a 1515 subjectDomainPolicy. The pairing indicates the issuing CA considers 1516 its issuerDomainPolicy equivalent to the subject CA's 1517 subjectDomainPolicy. 1519 The issuing CA's users may accept an issuerDomainPolicy for certain 1520 applications. The policy mapping tells the issuing CA's users which 1521 policies associated with the subject CA are comparable to the policy 1522 they accept. 1524 Each issuerDomainPolicy named in the the policy mapping extension 1525 should also be asserted in a certificate policies extension in the 1526 same certificate. Policies should not be mapped either to or from 1527 the special value anyPolicy. (See 4.2.1.5 certificate policies). 1529 This extension may be supported by CAs and/or applications, and it 1530 MUST be non-critical. 1532 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 1534 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 1535 issuerDomainPolicy CertPolicyId, 1536 subjectDomainPolicy CertPolicyId } 1538 4.2.1.7 Subject Alternative Name 1540 The subject alternative names extension allows additional identities 1541 to be bound to the subject of the certificate. Defined options 1542 include an Internet electronic mail address, a DNS name, an IP 1543 address, and a uniform resource identifier (URI). Other options 1544 exist, including completely local definitions. Multiple name forms, 1545 and multiple instances of each name form, may be included. Whenever 1546 such identities are to be bound into a certificate, the subject 1547 alternative name (or issuer alternative name) extension MUST be used. 1549 Because the subject alternative name is considered to be definitively 1550 bound to the public key, all parts of the subject alternative name 1551 MUST be verified by the CA. 1553 Further, if the only subject identity included in the certificate is 1554 an alternative name form (e.g., an electronic mail address), then the 1555 subject distinguished name MUST be empty (an empty sequence), and the 1556 subjectAltName extension MUST be present. If the subject field 1557 contains an empty sequence, the subjectAltName extension MUST be 1558 marked critical. 1560 When the subjectAltName extension contains an Internet mail address, 1561 the address MUST be included as an rfc822Name. The format of an 1562 rfc822Name is an "addr-spec" as defined in RFC 822 [RFC 822]. An 1563 addr-spec has the form "local-part@domain". Note that an addr-spec 1564 has no phrase (such as a common name) before it, has no comment (text 1565 surrounded in parentheses) after it, and is not surrounded by "<" and 1566 ">". Note that while upper and lower case letters are allowed in an 1567 RFC 822 addr-spec, no significance is attached to the case. 1569 When the subjectAltName extension contains a iPAddress, the address 1570 MUST be stored in the octet string in "network byte order," as 1571 specified in RFC 791 [RFC 791]. The least significant bit (LSB) of 1572 each octet is the LSB of the corresponding byte in the network 1573 address. For IP Version 4, as specified in RFC 791, the octet string 1574 MUST contain exactly four octets. For IP Version 6, as specified in 1575 RFC 1883, the octet string MUST contain exactly sixteen octets [RFC 1576 1883]. 1578 When the subjectAltName extension contains a domain name service 1579 label, the domain name MUST be stored in the dNSName (an IA5String). 1580 The name MUST be in the "preferred name syntax," as specified by RFC 1581 1034 [RFC 1034]. Note that while upper and lower case letters are 1582 allowed in domain names, no signifigance is attached to the case. In 1583 addition, while the string " " is a legal domain name, subjectAltName 1584 extensions with a dNSName " " are not permitted. Finally, the use of 1585 the DNS representation for Internet mail addresses (wpolk.nist.gov 1586 instead of wpolk@nist.gov) MUST NOT be used; such identities are to 1587 be encoded as rfc822Name. 1589 Note: work is currently underway to specify domain names in 1590 international character sets. This names will likely not be 1591 accomodated by IA5String. Once this work is complete, this profile 1592 will be revisited and the appropriate functionality will be added. 1594 When the subjectAltName extension contains a URI, the name MUST be 1595 stored in the uniformResourceIdentifier (an IA5String). The name MUST 1596 be a non-relative URL, and MUST follow the URL syntax and encoding 1597 rules specified in [RFC 1738]. The name must include both a scheme 1598 (e.g., "http" or "ftp") and a scheme-specific-part. The scheme- 1599 specific-part must include a fully qualified domain name or IP 1600 address as the host. 1602 As specified in [RFC 1738], the scheme name is not case-sensitive 1603 (e.g., "http" is equivalent to "HTTP"). The host part is also not 1604 case-sensitive, but other components of the scheme-specific-part may 1605 be case-sensitive. When comparing URIs, conforming implementations 1606 MUST compare the scheme and host without regard to case, but assume 1607 the remainder of the scheme-specific-part is case sensitive. 1609 When the subjectAltName extension contains a DN in the directoryName, 1610 the DN MUST be unique for each subject entity certified by the one CA 1611 as defined by the issuer name field. A CA may issue more than one 1612 certificate with the same DN to the same subject entity. 1614 The subjectAltName may carry additional name types through the use of 1615 the otherName field. The format and semantics of the name are 1616 indicated through the OBJECT IDENTIFIER in the type-id field. The 1617 name itself is conveyed as value field in otherName. For example, 1618 Kerberos [RFC 1510] format names can be encoded into the otherName, 1619 using the krb5PrincipalName OID and the KerberosName syntax as 1620 defined in [PKINIT]. 1622 Subject alternative names may be constrained in the same manner as 1623 subject distinguished names using the name constraints extension as 1624 described in section 4.2.1.11. 1626 If the subjectAltName extension is present, the sequence MUST contain 1627 at least one entry. Unlike the subject field, conforming CAs MUST 1628 NOT issue certificates with subjectAltNames containing empty 1629 GeneralName fields. For example, an rfc822Name is represented as an 1630 IA5String. While an empty string is a valid IA5String, such an 1631 rfc822Name is not permitted by this profile. The behavior of clients 1632 that encounter such a certificate when processing a certificication 1633 path is not defined by this profile. 1635 Finally, the semantics of subject alternative names that include 1636 wildcard characters (e.g., as a placeholder for a set of names) are 1637 not addressed by this specification. Applications with specific 1638 requirements may use such names but shall define the semantics. 1640 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 1642 SubjectAltName ::= GeneralNames 1644 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 1646 GeneralName ::= CHOICE { 1647 otherName [0] OtherName, 1648 rfc822Name [1] IA5String, 1649 dNSName [2] IA5String, 1650 x400Address [3] ORAddress, 1651 directoryName [4] Name, 1652 ediPartyName [5] EDIPartyName, 1653 uniformResourceIdentifier [6] IA5String, 1654 iPAddress [7] OCTET STRING, 1655 registeredID [8] OBJECT IDENTIFIER} 1657 OtherName ::= SEQUENCE { 1658 type-id OBJECT IDENTIFIER, 1659 value [0] EXPLICIT ANY DEFINED BY type-id } 1661 EDIPartyName ::= SEQUENCE { 1662 nameAssigner [0] DirectoryString OPTIONAL, 1663 partyName [1] DirectoryString } 1665 4.2.1.8 Issuer Alternative Names 1667 As with 4.2.1.7, this extension is used to associate Internet style 1668 identities with the certificate issuer. Issuer alternative names MUST 1669 be encoded as in 4.2.1.7. 1671 Where present, this extension SHOULD NOT be marked critical. 1673 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 1675 IssuerAltName ::= GeneralNames 1677 4.2.1.9 Subject Directory Attributes 1679 The subject directory attributes extension is used to convey 1680 identification attributes (e.g.,nationality) of the subject. The 1681 extension is defined as a sequence of one or more attributes. This 1682 extension MUST be non-critical. 1684 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 1686 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 1688 4.2.1.10 Basic Constraints 1690 The basic constraints extension identifies whether the subject of the 1691 certificate is a CA and how deep a certification path may exist 1692 through that CA. 1694 The cA bit indicates if the certified public key may be used to 1695 verify signatures on other certificates. If the cA bit is asserted, 1696 then the keyCertSign bit in the key usage extension (see 4.2.1.3) 1697 MUST also be asserted. If the cA bit is not asserted, then the 1698 keyCertSign bit in the key usage extension MUST NOT be asserted. 1700 The pathLenConstraint field is meaningful only if cA is set to TRUE. 1701 In this case, it gives the maximum number of CA certificates that may 1702 follow this certificate in a certification path. (Note: One end- 1703 entity certificate will follow the final CA certificate in the path. 1704 The last certificate in a path is considered an end-entity 1705 certificate, whether the subject of the certificate is a CA or not.) 1706 A pathLenConstrinat of zero indicates that only an end-entity 1707 certificate may follow in the path. Where it appears, the 1708 pathLenConstraint field MUST be greater than or equal to zero. Where 1709 pathLenConstraint does not appear, there is no limit to the allowed 1710 length of the certification path. 1712 This extension MUST appear as a critical extension in all CA 1713 certificates. This extension MAY appear as a critical or non- 1714 critical extension in end entity certificates. 1716 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 1717 BasicConstraints ::= SEQUENCE { 1718 cA BOOLEAN DEFAULT FALSE, 1719 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 1721 4.2.1.11 Name Constraints 1723 The name constraints extension, which MUST be used only in a CA 1724 certificate, indicates a name space within which all subject names in 1725 subsequent certificates in a certification path shall be located. 1726 Restrictions may apply to the subject distinguished name or subject 1727 alternative names. Restrictions apply only when the specified name 1728 form is present. If no name of the type is in the certificate, the 1729 certificate is acceptable. 1731 Name constraints are not applied to certificates whose issuer and 1732 subject are identical. (This could prevent CAs that use name 1733 constraints from issuing self-signed certificates to implement key 1734 rollover.) 1736 Restrictions are defined in terms of permitted or excluded name 1737 subtrees. Any name matching a restriction in the excludedSubtrees 1738 field is invalid regardless of information appearing in the 1739 permittedSubtrees. This extension MUST be critical. 1741 Within this profile, the minimum and maximum fields are not used with 1742 any name forms, thus minimum is always zero, and maximum is always 1743 absent. 1745 For URIs, the constraint applies to the host part of the name. The 1746 constraint may specify a host or a domain. Examples would be 1747 "foo.bar.com"; and ".xyz.com". When the the constraint begins with 1748 a period, it may be expanded with one or more subdomains. That is, 1749 the constraint ".xyz.com" is satisfied by both abc.xyz.com and 1750 abc.def.xyz.com. However, the constraint ".xyz.com" is not satisfied 1751 by "xyz.com". When the constraint does not begin with a period, it 1752 specifies a host. 1754 A name constraint for Internet mail addresses may specify a 1755 particular mailbox, all addresses at a particular host, or all 1756 mailboxes in a domain. To indicate a particular mailbox, the 1757 constraint is the complete mail address. For example, "root@xyz.com" 1758 indicates the root mailbox on the host "xyz.com". To indicate all 1759 Internet mail addresses on a particular host, the constraint is 1760 specified as the host name. For example, the constraint "xyz.com" is 1761 satisfied by any mail address at the host "xyz.com". To specify any 1762 address within a domain, the constraint is specified with a leading 1763 period (as with URIs). For example, ".xyz.com" indicates all the 1764 Internet mail addresses in the domain "xyz.com", but not Internet 1765 mail addresses on the host "xyz.com". 1767 DNS name restrictions are expressed as foo.bar.com. Any DNS name that 1768 can be constructed by simply adding to the left hand side of the name 1769 satisfies the name constraint. For example, www.foo.bar.com would 1770 satisfy the constraint but foo1.bar.com would not. 1772 Legacy implementations exist where an RFC 822 name is embedded in the 1773 subject distinguished name in an attribute of type EmailAddress (see 1774 sec. 4.1.2.6). When rfc822 names are constrained, but the certificate 1775 does not include a subject alternative name, the rfc822 name 1776 constraint MUST be applied to the attribute of type EmailAddress in 1777 the subject distinguished name. The ASN.1 syntax for EmailAddress 1778 and the corresponding OID are supplied in Appendix A and B. 1780 Restrictions of the form directoryName MUST be applied to the subject 1781 field in the certificate and to the subjectAltName extensions of type 1782 directoryName. Restrictions of the form x400Address MUST be applied 1783 to subjectAltName extensions of type x400Address. 1785 When applying restrictions of the form directoryName, an 1786 implementation MUST compare DN attributes. At a minimum, 1787 implementations MUST perform the DN comparison rules specified in 1788 Section 4.1.2.4. CAs issuing certificates with a restriction of the 1789 form directoryName SHOULD NOT rely on implementation of the full ISO 1790 DN name comparison algorithm. This implies name restrictions shall 1791 be stated identically to the encoding used in the subject field or 1792 subjectAltName extension. 1794 The syntax of iPAddress MUST be as described in section 4.2.1.7 with 1795 the following additions specifically for Name Constraints. For IPv4 1796 addresses, the ipAddress field of generalName MUST contain eight (8) 1797 octets, encoded in the style of RFC 1519 (CIDR) to represent an 1798 address range.[RFC 1519] For IPv6 addresses, the ipAddress field 1799 MUST contain 32 octets similarly encoded. For example, a name 1800 constraint for "class C" subnet 10.9.8.0 shall be represented as the 1801 octets 0A 09 08 00 FF FF FF 00, representing the CIDR notation 1802 10.9.8.0/255.255.255.0. 1804 The syntax and semantics for name constraints for otherName, 1805 ediPartyName, and registeredID are not defined by this specification. 1807 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 1809 NameConstraints ::= SEQUENCE { 1810 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 1811 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 1813 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 1815 GeneralSubtree ::= SEQUENCE { 1816 base GeneralName, 1817 minimum [0] BaseDistance DEFAULT 0, 1818 maximum [1] BaseDistance OPTIONAL } 1820 BaseDistance ::= INTEGER (0..MAX) 1822 4.2.1.12 Policy Constraints 1824 The policy constraints extension can be used in certificates issued 1825 to CAs. The policy constraints extension constrains path validation 1826 in two ways. It can be used to prohibit policy mapping or require 1827 that each certificate in a path contain an acceptable policy 1828 identifier. 1830 If the inhibitPolicyMapping field is present, the value indicates the 1831 number of additional certificates that may appear in the path before 1832 policy mapping is no longer permitted. For example, a value of one 1833 indicates that policy mapping may be processed in certificates issued 1834 by the subject of this certificate, but not in additional 1835 certificates in the path. 1837 If the requireExplicitPolicy field is present, subsequent 1838 certificates shall include an acceptable policy identifier. The value 1839 of requireExplicitPolicy indicates the number of additional 1840 certificates that may appear in the path before an explicit policy is 1841 required. An acceptable policy identifier is the identifier of a 1842 policy required by the user of the certification path or the 1843 identifier of a policy which has been declared equivalent through 1844 policy mapping. 1846 Conforming CAs MUST NOT issue certificates where policy constraints 1847 is a null sequence. That is, at least one of the inhibitPolicyMapping 1848 field or the requireExplicitPolicy field MUST be present. The 1849 behavior of clients that encounter a null policy constraints field is 1850 not addressed in this profile. 1852 This extension may be critical or non-critical. 1854 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } 1856 PolicyConstraints ::= SEQUENCE { 1857 requireExplicitPolicy [0] SkipCerts OPTIONAL, 1858 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 1860 SkipCerts ::= INTEGER (0..MAX) 1862 4.2.1.13 Extended key usage field 1864 This field indicates one or more purposes for which the certified 1865 public key may be used, in addition to or in place of the basic 1866 purposes indicated in the key usage extension field. In general, 1867 this extension will appear only in end entity certificates. This 1868 field is defined as follows: 1870 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 1872 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 1874 KeyPurposeId ::= OBJECT IDENTIFIER 1876 Key purposes may be defined by any organization with a need. Object 1877 identifiers used to identify key purposes shall be assigned in 1878 accordance with IANA or ITU-T Rec. X.660 | ISO/IEC/ITU 9834-1. 1880 This extension may, at the option of the certificate issuer, be 1881 either critical or non-critical. 1883 If the extension is flagged critical, then the certificate MUST only 1884 be used for one of the purposes indicated. If multiple purposes are 1885 indicated the application need not recognize all purposes indicated, 1886 as long as the intended purpose is present and recognized. 1888 If the extension is flagged non-critical, then it indicates the 1889 intended purpose or purposes of the key, and may be used in finding 1890 the correct key/certificate of an entity that has multiple 1891 keys/certificates. It is an advisory field and does not imply that 1892 usage of the key is restricted by the certification authority to the 1893 purpose indicated. Certificate using applications may nevertheless 1894 require that a particular purpose be indicated in order for the 1895 certificate to be acceptable to that application. 1897 If a certificate contains both a critical key usage field and a 1898 critical extended key usage field, then both fields MUST be processed 1899 independently and the certificate MUST only be used for a purpose 1900 consistent with both fields. If there is no purpose consistent with 1901 both fields, then the certificate MUST NOT be used for any purpose. 1903 The following key usage purposes are defined by this profile: 1905 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 1907 id-kp-serverAuth OBJECT IDENTIFIER ::= {id-kp 1} 1908 -- TLS Web server authentication 1909 -- Key usage bits that may be consistent: digitalSignature, 1910 -- keyEncipherment or keyAgreement 1911 -- 1912 id-kp-clientAuth OBJECT IDENTIFIER ::= {id-kp 2} 1913 -- TLS Web client authentication 1914 -- Key usage bits that may be consistent: digitalSignature and/or 1915 -- keyAgreement 1916 -- 1917 id-kp-codeSigning OBJECT IDENTIFIER ::= {id-kp 3} 1918 -- Signing of downloadable executable code 1919 -- Key usage bits that may be consistent: digitalSignature 1920 -- 1921 id-kp-emailProtection OBJECT IDENTIFIER ::= {id-kp 4} 1922 -- E-mail protection 1923 -- Key usage bits that may be consistent: digitalSignature, 1924 -- nonRepudiation, and/or (keyEncipherment 1925 -- or keyAgreement) 1926 -- 1927 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 1928 -- Binding the hash of an object to a time from an agreed-upon time 1929 -- source. Key usage bits that may be consistent: digitalSignature, 1930 -- nonRepudiation 1932 4.2.1.14 CRL Distribution Points 1934 The CRL distribution points extension identifies how CRL information 1935 is obtained. The extension SHOULD be non-critical, but this profile 1936 recommends support for this extension by CAs and applications. 1937 Further discussion of CRL management is contained in section 5. 1939 The cRLDistributionPoints extension is a SEQUENCE of 1940 DistributionPoint. A DistributionPoint consists of three fields, 1941 each of which is optional: the name of the DistributionPoint, 1942 ReasonsFlags, and the cRLIssuer. While each component is optional, a 1943 DistributionPoint MUST NOT consist of only the ReasonsFlags field. If 1944 the distributionPoint omits cRLIssuer, the CRL MUST be issued by the 1945 CA that issued the certificate. If the distributionPointName is 1946 absent, cRLIssuer MUST be present and include a Name corresponding to 1947 an X.500 or LDAP directory entry where the CRL is located. 1949 If the cRLDistributionPoints extension contains a 1950 DistributionPointName of type URI, the following semantics MUST be 1951 assumed: the URI is a pointer to the current CRL for the associated 1952 reasons and will be issued by the associated cRLIssuer. The expected 1953 values for the URI are those defined in 4.2.1.7. Processing rules for 1954 other values are not defined by this specification. If the 1955 distributionPoint omits reasons, the CRL MUST include revocations for 1956 all reasons. 1958 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 } 1960 CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 1962 DistributionPoint ::= SEQUENCE { 1963 distributionPoint [0] DistributionPointName OPTIONAL, 1964 reasons [1] ReasonFlags OPTIONAL, 1965 cRLIssuer [2] GeneralNames OPTIONAL } 1967 DistributionPointName ::= CHOICE { 1968 fullName [0] GeneralNames, 1969 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 1971 ReasonFlags ::= BIT STRING { 1972 unused (0), 1973 keyCompromise (1), 1974 cACompromise (2), 1975 affiliationChanged (3), 1976 superseded (4), 1977 cessationOfOperation (5), 1978 certificateHold (6) } 1980 4.2.1.15 Inhibit Any-Policy 1982 The inhibit any-policy extension can be used in certificates issued 1983 to CAs. The inhibit any-policy indicates that the special any-policy 1984 OID, with the value {2 5 29 32 0}, is not considered an explicit 1985 match for other certificate policies. The value indicates the number 1986 of additional certificates that may appear in the path before any- 1987 policy is no longer permitted. For example, a value of one indicates 1988 that any-policy may be processed in certificates issued by the 1989 subject of this certificate, but not in additional certificates in 1990 the path. 1992 This extension MUST be critical. 1994 id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 } 1996 InhibitAnyPolicy ::= SkipCerts 1998 SkipCerts ::= INTEGER (0..MAX) 2000 4.2.1.16 Freshest CRL (a.k.a. Delta CRL Distribution Point) 2002 The freshest CRL extension identifies how delta-CRL information is 2003 obtained. The extension MUST be non-critical. Further discussion of 2004 CRL management is contained in section 5. 2006 The same syntax is used for this extension and the 2007 cRLDistributionPoints extension, and is described in section 2008 4.2.1.14. The same conventions apply to both extensions. 2010 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } 2012 FreshestCRL ::= CRLDistributionPoints 2014 4.2.2 Private Internet Extensions 2016 This section defines one new extension for use in the Internet Public 2017 Key Infrastructure. This extension may be used to direct 2018 applications to identify an on-line validation service supporting the 2019 issuing CA. As the information may be available in multiple forms, 2020 each extension is a sequence of IA5String values, each of which 2021 represents a URI. The URI implicitly specifies the location and 2022 format of the information and the method for obtaining the 2023 information. 2025 An object identifier is defined for the private extension. The 2026 object identifier associated with the private extension is defined 2027 under the arc id-pe within the id-pkix name space. Any future 2028 extensions defined for the Internet PKI will also be defined under 2029 the arc id-pe. 2031 id-pkix OBJECT IDENTIFIER ::= 2032 { iso(1) identified-organization(3) dod(6) internet(1) 2033 security(5) mechanisms(5) pkix(7) } 2035 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 2037 4.2.2.1 Authority Information Access 2039 The authority information access extension indicates how to access CA 2040 information and services for the issuer of the certificate in which 2041 the extension appears. Information and services may include on-line 2042 validation services and CA policy data. (The location of CRLs is not 2043 specified in this extension; that information is provided by the 2044 cRLDistributionPoints extension.) This extension may be included in 2045 subject or CA certificates, and it MUST be non-critical. 2047 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 2049 AuthorityInfoAccessSyntax ::= 2050 SEQUENCE SIZE (1..MAX) OF AccessDescription 2052 AccessDescription ::= SEQUENCE { 2053 accessMethod OBJECT IDENTIFIER, 2054 accessLocation GeneralName } 2056 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 2058 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 2060 Each entry in the sequence AuthorityInfoAccessSyntax describes the 2061 format and location of additional information provided by the CA who 2062 issued the certificate in which this extension appears. The type and 2063 format of the information is specified by the accessMethod field; the 2064 accessLocation field specifies the location of the information. The 2065 retrieval mechanism may be implied by the accessMethod or specified 2066 by accessLocation. 2068 This profile defines one OID for accessMethod. The id-ad-caIssuers 2069 OID is used when the additional information lists CAs that have 2070 issued certificates superior to the CA that issued the certificate 2071 containing this extension. The referenced CA Issuers description is 2072 intended to aid certificate users in the selection of a certification 2073 path that terminates at a point trusted by the certificate user. 2075 When id-ad-caIssuers appears as accessInfoType, the accessLocation 2076 field describes the referenced description server and the access 2077 protocol to obtain the referenced description. The accessLocation 2078 field is defined as a GeneralName, which can take several forms. 2079 Where the information is available via http, ftp, or ldap, 2080 accessLocation MUST be a uniformResourceIdentifier. Where the 2081 information is available via the directory access protocol (dap), 2082 accessLocation MUST be a directoryName. When the information is 2083 available via electronic mail, accessLocation MUST be an rfc822Name. 2084 The semantics of other name forms of accessLocation (when 2085 accessMethod is id-ad-caIssuers) are not defined by this 2086 specification. 2088 [RFC 2560] defines the access descriptor for the Online Certificate 2089 Status Protocol. When this access descriptor appears in the 2090 authority information access extension, this indicates the issuer 2091 provides revocation information for this certificate through the 2092 named OCSP service. Additional access descriptors may be defined in 2093 other PKIX specifications. 2095 4.2.2.2 Subject Information Access 2097 The subject information access extension indicates how to access 2098 information and services for the subject of the certificate in which 2099 the extension appears. When the subject is a CA, information and 2100 services may include certificate validation services and CA policy 2101 data. When the subject is an end entity, the information describes 2102 the type of services offered and how to access them. In this case, 2103 the contents of this extension are defined in the protocol 2104 specifications for the suported services. This extension may be 2105 included in subject or CA certificates, and it MUST be non-critical. 2107 id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 } 2109 SubjectInfoAccessSyntax ::= 2110 SEQUENCE SIZE (1..MAX) OF AccessDescription 2112 AccessDescription ::= SEQUENCE { 2113 accessMethod OBJECT IDENTIFIER, 2114 accessLocation GeneralName } 2116 Each entry in the sequence SubjectInfoAccessSyntax describes the 2117 format and location of additional information provided by the subject 2118 of the certificate in which this extension appears. The type and 2119 format of the information is specified by the accessMethod field; the 2120 accessLocation field specifies the location of the information. The 2121 retrieval mechanism may be implied by the accessMethod or specified 2122 by accessLocation. 2124 This profile defines one access method to be used when the subject is 2125 a CA, and one access method to be used when the subject is an end 2126 entity. Additional access methods may be defined in the future in 2127 the protocol specifications for other services. 2129 The id-ad-caRepository OID is used when the subject is a CA, and 2130 publishes its certificates and CRLs (if issued) in a repository. The 2131 accessLocation field is defined as a GeneralName, which can take 2132 several forms. Where the information is available via http, ftp, or 2133 ldap, accessLocation MUST be a uniformResourceIdentifier. Where the 2134 information is available via the directory access protocol (dap), 2135 accessLocation MUST be a directoryName. When the information is 2136 available via electronic mail, accessLocation MUST be an rfc822Name. 2137 The semantics of other name forms of of accessLocation (when 2138 accessMethod is id-ad-caRepository) are not defined by this 2139 specification. 2141 The id-ad-timeStamping OID is used when the subject offers 2142 timestamping services using the Time STamp Protocol defined in [PKIX 2143 TSA]. Where the timestamping services are available via http or ftp, 2144 accessLocation MUST be a uniformResourceIdentifier. Where the 2145 timestamping services are available via electronic mail, 2146 accessLocation MUST be an rfc822Name. Where timestamping services 2147 are available using TCP/IP, the dNSName and ipAddress name forms may 2148 be used. The semantics of other name forms of accessLocation (when 2149 accessMethod is id-ad-timeStamping) are not defined by this 2150 specification. 2152 Additional access descriptors may be defined in other PKIX 2153 specifications. 2155 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 2157 id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 } 2159 id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 } 2161 5 CRL and CRL Extensions Profile 2163 As described above, one goal of this X.509 v2 CRL profile is to 2164 foster the creation of an interoperable and reusable Internet PKI. 2165 To achieve this goal, guidelines for the use of extensions are 2166 specified, and some assumptions are made about the nature of 2167 information included in the CRL. 2169 CRLs may be used in a wide range of applications and environments 2170 covering a broad spectrum of interoperability goals and an even 2171 broader spectrum of operational and assurance requirements. This 2172 profile establishes a common baseline for generic applications 2173 requiring broad interoperability. The profile defines a baseline set 2174 of information that can be expected in every CRL. Also, the profile 2175 defines common locations within the CRL for frequently used 2176 attributes as well as common representations for these attributes. 2178 This profile does not define any private Internet CRL extensions or 2179 CRL entry extensions. 2181 Environments with additional or special purpose requirements may 2182 build on this profile or may replace it. 2184 Conforming CAs are not required to issue CRLs if other revocation or 2185 certificate status mechanisms are provided. Conforming CAs that 2186 issue CRLs MUST issue version 2 CRLs, and CAs MUST include the date 2187 by which the next CRL will be issued in the nextUpdate field (see 2188 sec. 5.1.2.5), the CRL number extension (see sec. 5.2.3) and the 2189 authority key identifier extension (see sec. 5.2.1). Conforming 2190 applications are required to process version 1 and 2 CRLs. 2192 5.1 CRL Fields 2194 The X.509 v2 CRL syntax is as follows. For signature calculation, 2195 the data that is to be signed is ASN.1 DER encoded. ASN.1 DER 2196 encoding is a tag, length, value encoding system for each element. 2198 CertificateList ::= SEQUENCE { 2199 tbsCertList TBSCertList, 2200 signatureAlgorithm AlgorithmIdentifier, 2201 signatureValue BIT STRING } 2203 TBSCertList ::= SEQUENCE { 2204 version Version OPTIONAL, 2205 -- if present, shall be v2 2206 signature AlgorithmIdentifier, 2207 issuer Name, 2208 thisUpdate Time, 2209 nextUpdate Time OPTIONAL, 2210 revokedCertificates SEQUENCE OF SEQUENCE { 2211 userCertificate CertificateSerialNumber, 2212 revocationDate Time, 2213 crlEntryExtensions Extensions OPTIONAL 2214 -- if present, shall be v2 2215 } OPTIONAL, 2216 crlExtensions [0] EXPLICIT Extensions OPTIONAL 2217 -- if present, shall be v2 2218 } 2220 -- Version, Time, CertificateSerialNumber, and Extensions 2221 -- are all defined in the ASN.1 in section 4.1 2223 -- AlgorithmIdentifier is defined in section 4.1.1.2 2225 The following items describe the use of the X.509 v2 CRL in the 2226 Internet PKI. 2228 5.1.1 CertificateList Fields 2230 The CertificateList is a SEQUENCE of three required fields. The 2231 fields are described in detail in the following subsections. 2233 5.1.1.1 tbsCertList 2235 The first field in the sequence is the tbsCertList. This field is 2236 itself a sequence containing the name of the issuer, issue date, 2237 issue date of the next list, the optional list of revoked 2238 certificates, and optional CRL extensions. When there are no revoked 2239 certificates, the revoked certificates list is absent. When one or 2240 more certificates are revoked, each entry on the revoked certificate 2241 list is defined by a sequence of user certificate serial number, 2242 revocation date, and optional CRL entry extensions. 2244 5.1.1.2 signatureAlgorithm 2246 The signatureAlgorithm field contains the algorithm identifier for 2247 the algorithm used by the CA to sign the CertificateList. The field 2248 is of type AlgorithmIdentifier, which is defined in section 4.1.1.2. 2249 [PKIX ALGS] lists the supported algorithms for this specification. 2250 Conforming CAs MUST use the algorithm identifiers presented in [PKIX 2251 ALGS] when signing with a supported signature algorithm. 2253 This field MUST contain the same algorithm identifier as the 2254 signature field in the sequence tbsCertList (see sec. 5.1.2.2). 2256 5.1.1.3 signatureValue 2258 The signatureValue field contains a digital signature computed upon 2259 the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded tbsCertList 2260 is used as the input to the signature function. This signature value 2261 is then ASN.1 encoded as a BIT STRING and included in the CRL's 2262 signatureValue field. The details of this process are specified for 2263 each of the supported algorithms in [PKIX ALGS]. 2265 5.1.2 Certificate List "To Be Signed" 2267 The certificate list to be signed, or TBSCertList, is a SEQUENCE of 2268 required and optional fields. The required fields identify the CRL 2269 issuer, the algorithm used to sign the CRL, the date and time the CRL 2270 was issued, and the date and time by which the CA will issue the next 2271 CRL. 2273 Optional fields include lists of revoked certificates and CRL 2274 extensions. The revoked certificate list is optional to support the 2275 case where a CA has not revoked any unexpired certificates that it 2276 has issued. The profile requires conforming CAs to use the CRL 2277 extension cRLNumber in all CRLs issued. 2279 5.1.2.1 Version 2281 This optional field describes the version of the encoded CRL. When 2282 extensions are used, as required by this profile, this field MUST be 2283 present and MUST specify version 2 (the integer value is 1). 2285 5.1.2.2 Signature 2287 This field contains the algorithm identifier for the algorithm used 2288 to sign the CRL. [PKIX ALGS] lists OIDs for the most popular 2289 signature algorithms used in the Internet PKI. 2291 This field MUST contain the same algorithm identifier as the 2292 signatureAlgorithm field in the sequence CertificateList (see section 2293 5.1.1.2). 2295 5.1.2.3 Issuer Name 2297 The issuer name identifies the entity who has signed and issued the 2298 CRL. The issuer identity is carried in the issuer name field. 2299 Alternative name forms may also appear in the issuerAltName extension 2300 (see sec. 5.2.2). The issuer name field MUST contain an X.500 2301 distinguished name (DN). The issuer name field is defined as the 2302 X.501 type Name, and MUST follow the encoding rules for the issuer 2303 name field in the certificate (see sec. 4.1.2.4). 2305 5.1.2.4 This Update 2307 This field indicates the issue date of this CRL. ThisUpdate may be 2308 encoded as UTCTime or GeneralizedTime. 2310 CAs conforming to this profile that issue CRLs MUST encode thisUpdate 2311 as UTCTime for dates through the year 2049. CAs conforming to this 2312 profile that issue CRLs MUST encode thisUpdate as GeneralizedTime for 2313 dates in the year 2050 or later. 2315 Where encoded as UTCTime, thisUpdate MUST be specified and 2316 interpreted as defined in section 4.1.2.5.1. Where encoded as 2317 GeneralizedTime, thisUpdate MUST be specified and interpreted as 2318 defined in section 4.1.2.5.2. 2320 5.1.2.5 Next Update 2322 This field indicates the date by which the next CRL will be issued. 2323 The next CRL could be issued before the indicated date, but it will 2324 not be issued any later than the indicated date. CAs SHOULD issue 2325 CRLs with a nextUpdate time equal to or later than all previous CRLs. 2326 nextUpdate may be encoded as UTCTime or GeneralizedTime. 2328 This profile requires inclusion of nextUpdate in all CRLs issued by 2329 conforming CAs. Note that the ASN.1 syntax of TBSCertList describes 2330 this field as OPTIONAL, which is consistent with the ASN.1 structure 2331 defined in [X.509]. The behavior of clients processing CRLs which 2332 omit nextUpdate is not specified by this profile. 2334 CAs conforming to this profile that issue CRLs MUST encode nextUpdate 2335 as UTCTime for dates through the year 2049. CAs conforming to this 2336 profile that issue CRLs MUST encode nextUpdate as GeneralizedTime for 2337 dates in the year 2050 or later. 2339 Where encoded as UTCTime, nextUpdate MUST be specified and 2340 interpreted as defined in section 4.1.2.5.1. Where encoded as 2341 GeneralizedTime, nextUpdate MUST be specified and interpreted as 2342 defined in section 4.1.2.5.2. 2344 5.1.2.6 Revoked Certificates 2346 When there are no revoked certificates, the revoked certificates list 2347 is absent. Otherwise, revoked certificates are listed by their 2348 serial numbers. Certificates revoked by the CA are uniquely 2349 identified by the certificate serial number. The date on which the 2350 revocation occurred is specified. The time for revocationDate MUST 2351 be expressed as described in section 5.1.2.4. Additional information 2352 may be supplied in CRL entry extensions; CRL entry extensions are 2353 discussed in section 5.3. 2355 5.1.2.7 Extensions 2357 This field may only appear if the version is 2 (see sec. 5.1.2.1). 2358 If present, this field is a SEQUENCE of one or more CRL extensions. 2359 CRL extensions are discussed in section 5.2. 2361 5.2 CRL Extensions 2363 The extensions defined by ANSI X9 and ISO/IEC/ITU for X.509 v2 CRLs 2364 [X.509] [X9.55] provide methods for associating additional attributes 2365 with CRLs. The X.509 v2 CRL format also allows communities to define 2366 private extensions to carry information unique to those communities. 2367 Each extension in a CRL may be designated as critical or non- 2368 critical. A CRL validation MUST fail if it encounters a critical 2369 extension which it does not know how to process. However, an 2370 unrecognized non-critical extension may be ignored. The following 2371 subsections present those extensions used within Internet CRLs. 2372 Communities may elect to include extensions in CRLs which are not 2373 defined in this specification. However, caution should be exercised 2374 in adopting any critical extensions in CRLs which might be used in a 2375 general context. 2377 Conforming CAs that issue CRLs are required to include the authority 2378 key identifier (see sec. 5.2.1) and the CRL number (see sec. 5.2.3) 2379 extensions in all CRLs issued. 2381 5.2.1 Authority Key Identifier 2383 The authority key identifier extension provides a means of 2384 identifying the public key corresponding to the private key used to 2385 sign a CRL. The identification can be based on either the key 2386 identifier (the subject key identifier in the CRL signer's 2387 certificate) or on the issuer name and serial number. This extension 2388 is especially useful where an issuer has more than one signing key, 2389 either due to multiple concurrent key pairs or due to changeover. 2391 Conforming CAs MUST use the key identifier method, and MUST include 2392 this extension in all CRLs issued. 2394 The syntax for this CRL extension is defined in section 4.2.1.1. 2396 5.2.2 Issuer Alternative Name 2398 The issuer alternative names extension allows additional identities 2399 to be associated with the issuer of the CRL. Defined options include 2400 an rfc822 name (electronic mail address), a DNS name, an IP address, 2401 and a URI. Multiple instances of a name and multiple name forms may 2402 be included. Whenever such identities are used, the issuer 2403 alternative name extension MUST be used. 2405 The issuerAltName extension SHOULD NOT be marked critical. 2407 The OID and syntax for this CRL extension are defined in section 2408 4.2.1.8. 2410 5.2.3 CRL Number 2412 The CRL number is a non-critical CRL extension which conveys a 2413 monotonically increasing sequence number for each CRL issued by a CA. 2414 This extension allows users to easily determine when a particular CRL 2415 supersedes another CRL. CAs conforming to this profile MUST include 2416 this extension in all CRLs. 2418 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 2420 cRLNumber ::= INTEGER (0..MAX) 2422 5.2.4 Delta CRL Indicator 2424 The delta CRL indicator is a critical CRL extension that identifies a 2425 CRL as being a delta CRL. Delta CRLs contain updates to revocation 2426 information previously distributed, rather than all the information 2427 that would appear in a complete CRL. The use of delta CRLs can 2428 significantly reduce network load and processing time in some 2429 environments. Delta CRLs are generally smaller than the CRLs they 2430 update, so applications that obtain delta CRLs consume less network 2431 bandwidth than applications that obtain the corresponding complete 2432 CRLs. Applications which store revocation information in a format 2433 other than the CRL structure can add new revocation information to 2434 the local database without reprocessing information. 2436 The delta CRL indicator extension contains a single value of type 2437 BaseCRLNumber. This value identifies the CRL number of the base CRL 2438 that was used as the foundation in the generation of this delta CRL. 2439 The referenced base CRL is a CRL that was explicitly issued as a CRL 2440 that is complete for a given scope (e.g., a set of revocation reasons 2441 or a particular distribution point.) The CRL containing the delta CRL 2442 indicator extension contains all updates to the certificate 2443 revocation status for that same scope. The combination of a CRL 2444 containing the delta CRL indicator extension plus the CRL referenced 2445 in the BaseCRLNumber component of this extension is equivalent to a 2446 full CRL, for the applicable scope, at the time of publication of the 2447 delta CRL. 2449 When a conforming CA issues a delta CRL, the CA MUST also issue a CRL 2450 that is complete for the given scope. Both the delta CRL and the 2451 complete CRL MUST include the CRL number extension (see sec. 5.2.3). 2452 The CRL number extension in the delta CRL and the complete CRL MUST 2453 contain the same value. When a delta CRL is issued, it MUST cover 2454 the same set of reasons and same set of certificates that were 2455 covered by the base CRL it references. 2457 An application can construct a CRL that is complete for a given 2458 scope, at the current time, in either of the following ways: 2460 (a) by retrieving the current delta CRL for that scope, and 2461 combining it with an issued CRL that is complete for that scope 2462 and that has a cRLNumber greater than or equal to the cRLNumber of 2463 the base CRL referenced in the delta CRL; or 2465 (b) by retrieving the current delta CRL for that scope and 2466 combining it with a locally constructed CRL whose cRLNumber is 2467 greater than or equal to the cRLNumber of the base CRL referenced 2468 in the current delta CRL. 2470 The constructed CRL has the CRL number specified in the CRL number 2471 extension found in the delta CRL used in its construction. 2473 CAs must ensure that application of a delta CRL to the referenced 2474 base revocation information accurately reflects the current status of 2475 revocation. If a CA supports the certificateHold revocation reason 2476 the following rules must be applied when generating delta CRLs: 2478 (a) If a certificate was listed as revoked with revocation reason 2479 certificateHold on a CRL (either a delta CRL or a CRL that is 2480 complete for a given scope), whose cRLNumber is n, and the hold is 2481 subsequently released, the certificate must be included in all 2482 delta CRLs issued after the hold is released where the cRLNumber 2483 of the referenced base CRL is less than or equal to n. The 2484 certificate must be listed with revocation reason removeFromCRL 2485 unless the certificate is subsequently revoked again for one of 2486 the revocation reasons covered by the delta CRL, in which case the 2487 certificate must be listed with the revocation reason appropriate 2488 for the subsequent revocation. 2490 (b) If the certificate was not removed from hold, but was 2491 permanently revoked, then it must be listed on all subsequent 2492 delta CRLs where the cRLNumber of the referenced base CRL is less 2493 than the cRLNumber of the CRL (either a delta CRL or a CRL that is 2494 complete for the given scope) on which the permanent revocation 2495 notice first appeared. 2497 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 2499 deltaCRLIndicator EXTENSION ::= { 2500 SYNTAX BaseCRLNumber 2501 IDENTIFIED BY id-ce-deltaCRLIndicator } 2503 BaseCRLNumber ::= CRLNumber 2505 5.2.5 Issuing Distribution Point 2507 The issuing distribution point is a critical CRL extension that 2508 identifies the CRL distribution point for a particular CRL, and it 2509 indicates whether the CRL covers revocation for end entity 2510 certificates only, CA certificates only, or a limited set of reason 2511 codes. Although the extension is critical, conforming 2512 implementations are not required to support this extension. 2514 The CRL is signed using the CA's private key. CRL Distribution 2515 Points do not have their own key pairs. If the CRL is stored in the 2516 X.500 Directory, it is stored in the Directory entry corresponding to 2517 the CRL distribution point, which may be different than the Directory 2518 entry of the CA. 2520 The reason codes associated with a distribution point shall be 2521 specified in onlySomeReasons. If onlySomeReasons does not appear, the 2522 distribution point shall contain revocations for all reason codes. 2523 CAs may use CRL distribution points to partition the CRL on the basis 2524 of compromise and routine revocation. In this case, the revocations 2525 with reason code keyCompromise (1) and cACompromise (2) appear in one 2526 distribution point, and the revocations with other reason codes 2527 appear in another distribution point. 2529 Where the issuingDistributionPoint extension contains a URL, the 2530 following semantics MUST be assumed: the object is a pointer to the 2531 most current CRL issued by this CA. The URI schemes ftp, http, 2532 mailto [RFC1738] and ldap [RFC1778] are defined for this purpose. 2533 The URI MUST be an absolute, not relative, pathname and MUST specify 2534 the host. 2536 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 2538 issuingDistributionPoint ::= SEQUENCE { 2539 distributionPoint [0] DistributionPointName OPTIONAL, 2540 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 2541 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 2542 onlySomeReasons [3] ReasonFlags OPTIONAL, 2543 indirectCRL [4] BOOLEAN DEFAULT FALSE } 2545 5.2.6 Freshest CRL (a.k.a. Delta CRL Distribution Point) 2547 The freshest CRL extension identifies how delta-CRL information for 2548 this CRL is obtained. The extension MUST be non-critical. 2550 The same syntax is used for this extension as the 2551 cRLDistributionPoints certificate extension, and is described in 2552 section 4.2.1.14. The same conventions apply to both extensions. 2554 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } 2556 FreshestCRL ::= CRLDistributionPoints 2558 5.3 CRL Entry Extensions 2560 The CRL entry extensions already defined by ANSI X9 and ISO/IEC/ITU 2561 for X.509 v2 CRLs provide methods for associating additional 2562 attributes with CRL entries [X.509] [X9.55]. The X.509 v2 CRL format 2563 also allows communities to define private CRL entry extensions to 2564 carry information unique to those communities. Each extension in a 2565 CRL entry may be designated as critical or non-critical. A CRL 2566 validation MUST fail if it encounters a critical CRL entry extension 2567 which it does not know how to process. However, an unrecognized 2568 non-critical CRL entry extension may be ignored. The following 2569 subsections present recommended extensions used within Internet CRL 2570 entries and standard locations for information. Communities may 2571 elect to use additional CRL entry extensions; however, caution should 2572 be exercised in adopting any critical extensions in CRL entries which 2573 might be used in a general context. 2575 All CRL entry extensions used in this specification are non-critical. 2576 Support for these extensions is optional for conforming CAs and 2577 applications. However, CAs that issue CRLs SHOULD include reason 2578 codes (see sec. 5.3.1) and invalidity dates (see sec. 5.3.3) whenever 2579 this information is available. 2581 5.3.1 Reason Code 2583 The reasonCode is a non-critical CRL entry extension that identifies 2584 the reason for the certificate revocation. CAs are strongly 2585 encouraged to include meaningful reason codes in CRL entries; 2586 however, the reason code CRL entry extension SHOULD be absent instead 2587 of using the unspecified (0) reasonCode value. 2589 id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 } 2591 -- reasonCode ::= { CRLReason } 2593 CRLReason ::= ENUMERATED { 2594 unspecified (0), 2595 keyCompromise (1), 2596 cACompromise (2), 2597 affiliationChanged (3), 2598 superseded (4), 2599 cessationOfOperation (5), 2600 certificateHold (6), 2601 removeFromCRL (8) } 2603 5.3.2 Hold Instruction Code 2605 The hold instruction code is a non-critical CRL entry extension that 2606 provides a registered instruction identifier which indicates the 2607 action to be taken after encountering a certificate that has been 2608 placed on hold. 2610 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 2612 holdInstructionCode ::= OBJECT IDENTIFIER 2614 The following instruction codes have been defined. Conforming 2615 applications that process this extension MUST recognize the following 2616 instruction codes. 2618 holdInstruction OBJECT IDENTIFIER ::= 2619 { iso(1) member-body(2) us(840) x9-57(10040) 2 } 2621 id-holdinstruction-none OBJECT IDENTIFIER ::= {holdInstruction 1} 2622 id-holdinstruction-callissuer 2623 OBJECT IDENTIFIER ::= {holdInstruction 2} 2624 id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3} 2626 Conforming applications which encounter an id-holdinstruction- 2627 callissuer MUST call the certificate issuer or reject the 2628 certificate. Conforming applications which encounter an id- 2629 holdinstruction-reject MUST reject the certificate. The hold 2630 instruction id-holdinstruction-none is semantically equivalent to the 2631 absence of a holdInstructionCode, and its use is strongly deprecated 2632 for the Internet PKI. 2634 5.3.3 Invalidity Date 2636 The invalidity date is a non-critical CRL entry extension that 2637 provides the date on which it is known or suspected that the private 2638 key was compromised or that the certificate otherwise became invalid. 2639 This date may be earlier than the revocation date in the CRL entry, 2640 which is the date at which the CA processed the revocation. When a 2641 revocation is first posted by a CA in a CRL, the invalidity date may 2642 precede the date of issue of earlier CRLs, but the revocation date 2643 SHOULD NOT precede the date of issue of earlier CRLs. Whenever this 2644 information is available, CAs are strongly encouraged to share it 2645 with CRL users. 2647 The GeneralizedTime values included in this field MUST be expressed 2648 in Greenwich Mean Time (Zulu), and MUST be specified and interpreted 2649 as defined in section 4.1.2.5.2. 2651 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 2653 invalidityDate ::= GeneralizedTime 2655 5.3.4 Certificate Issuer 2657 This CRL entry extension identifies the certificate issuer associated 2658 with an entry in an indirect CRL, i.e. a CRL that has the indirectCRL 2659 indicator set in its issuing distribution point extension. If this 2660 extension is not present on the first entry in an indirect CRL, the 2661 certificate issuer defaults to the CRL issuer. On subsequent entries 2662 in an indirect CRL, if this extension is not present, the certificate 2663 issuer for the entry is the same as that for the preceding entry. 2664 This field is defined as follows: 2666 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } 2668 certificateIssuer ::= GeneralNames 2670 If used by conforming CAs that issue CRLs, this extension MUST always 2671 be critical. If an implementation ignored this extension it could 2672 not correctly attribute CRL entries to certificates. This 2673 specification RECOMMENDS that implementations recognize this 2674 extension. 2676 6 Certification Path Validation 2678 Certification path validation procedures for the Internet PKI are 2679 based on the algorithm supplied in [X.509]. Certification path 2680 processing verifies the binding between the subject distinguished 2681 name and/or subject alternative name and subject public key. The 2682 binding is limited by constraints which are specified in the 2683 certificates which comprise the path and inputs which are specified 2684 by the relying party. The basic constraints and policy constraints 2685 extensions allow the certification path processing logic to automate 2686 the decision making process. 2688 This section describes an algorithm for validating certification 2689 paths. Conforming implementations of this specification are not 2690 required to implement this algorithm, but MUST provide functionality 2691 equivalent to the external behavior resulting from this procedure. 2692 Any algorithm may be used by a particular implementation so long as 2693 it derives the correct result. 2695 In section 6.1, the text describes basic path validation. Valid paths 2696 begin with certificates issued by a "most-trusted CA". The algorithm 2697 requires the public key of the CA, the CA's name, and any constraints 2698 upon the set of paths which may be validated using this key. 2700 The selection of a "most-trusted CA" is a matter of policy: it could 2701 be the top CA in a hierarchical PKI; the CA that issued the 2702 verifier's own certificate(s); or any other CA in a network PKI. The 2703 path validation procedure is the same regardless of the choice of 2704 "most-trusted CA." In addition, different applications may rely on 2705 different "most-trusted CA", or may accept paths that begin with any 2706 of a set of "most-trusted CAs." 2708 Section 6.2 describes methods for using the path validation algorithm 2709 in specific implementations. Two specific cases are discussed: the 2710 case where paths may begin with one of several trusted CAs; and where 2711 compatibility with the PEM architecture is required. 2713 Section 6.3 describes the steps necessary to determine if a 2714 certificate is revoked or on hold status when CRLs are the revocation 2715 mechanism used by the certificate issuer. 2717 6.1 Basic Path Validation 2719 This text describes an algorithm for X.509 path processing. A 2720 conformant implementation MUST include an X.509 path processing 2721 procedure that is functionally equivalent to the external behavior of 2722 this algorithm. However, some of the certificate fields processed in 2723 this algorithm are optional for compliant implementations. Clients 2724 that do not support these fields may omit the corresponding steps in 2725 the path validation algorithm. 2727 For example, clients are not required to support the policy mapping 2728 extension. Clients that do not support this extension may omit the 2729 path validation steps where policy mappings are processed. Note that 2730 clients MUST reject the certificate if it contains critical 2731 extensions that are not supported. 2733 This text describes the trust anchor as an input to the algorithm. 2734 There is no requirement that the same trust anchor be used to 2735 validate all certification paths. Different trust anchors may be 2736 used to validate different paths, as discussed further in Section 2737 6.2. 2739 The primary goal of path validation is to verify the binding between 2740 a subject distinguished name or subject alternative name and subject 2741 public key, as represented in the end entity certificate, based on 2742 the public key of the trust anchor. This requires obtaining a 2743 sequence of certificates that support that binding. The procedure 2744 performed to obtain this sequence of certificates is outside the 2745 scope of this section. 2747 To meet this goal, the path validation process verifies, among other 2748 things, that a prospective certification path (a sequence of n 2749 certificates) satisfies the following conditions: 2751 (a) for all x in {1, ..., n-1}, the subject of certificate x is 2752 the issuer of certificate x+1; 2754 (b) certificate 1 is issued by the trust anchor; 2756 (c) certificate n is the end entity certificate; and 2758 (d) for all x in {1, ..., n}, the certificate was valid at the 2759 time in question. 2761 A particular certification path may not, however, be appropriate for 2762 all applications. The path validation process also determines the 2763 set of certificate policies that are valid for this path, based on 2764 the certificate policies extension, policy mapping extension, policy 2765 constraints extension, and inhibit any-policy extension. To achieve 2766 this, the path validation algorithm constructs a valid policy tree. 2767 If the set of certificate policies that are valid for this path is 2768 not empty, then the result will be a valid policy tree of depth n, 2769 otherwise the result will be a NULL valid policy tree. 2771 A certificate is termed self-issued if the DNs that appear in the 2772 subject and issuer fields are identical and are not empty. In 2773 general, the issuer and subject of the certificates that make up a 2774 path are different for each certificate. However, a CA may issue a 2775 certificate to itself to support key rollover or changes in 2776 certificate policies. These self-issued certificates are not counted 2777 when evaluating path length or name constraints. 2779 This section presents the algorithm in four basic steps: (1) 2780 initialization, (2) basic certificate processing, (3) preparation for 2781 the next certificate, and (4) wrap-up. Steps (1) and (4) are 2782 performed exactly once. Step (2) is performed for all certificates 2783 in the path. Step (3) is performed for all certificates in the path 2784 except the final certificate. Figure 2 provides a high-level 2785 flowchart of this algorithm. 2787 +-------+ 2788 | START | 2789 +-------+ 2790 | 2791 V 2792 +----------------+ 2793 | Initialization | 2794 +----------------+ 2795 | 2796 +<--------------------+ 2797 | | 2798 V | 2799 +----------------+ | 2800 | Process Cert | | 2801 +----------------+ | 2802 | | 2803 V | 2804 +================+ | 2805 | IF Last Cert | | 2806 | in Path | | 2807 +================+ | 2808 | | | 2809 THEN | | ELSE | 2810 V V | 2811 +----------------+ +----------------+ | 2812 | Wrap up | | Prepare for | | 2813 +----------------+ | Next Cert | | 2814 | +----------------+ | 2815 V | | 2816 +-------+ +--------------+ 2817 | STOP | 2818 +-------+ 2820 Figure 2. Path Processing Flowchart 2822 6.1.1 Inputs 2824 This algorithm assumes the following seven inputs are provided to the 2825 path processing logic: 2827 (a) a prospective certification path of length n; 2829 (b) the time, T, for which the validity of the path should be 2830 determined. This may be the current date/time, or some point in 2831 the past. 2833 (c) user-initial-policy-set: A set of certificate policy 2834 identifiers naming the policies that are acceptable to the 2835 certificate user. The user-initial-policy-set contains the special 2836 value any-policy if the user is not concerned about certificate 2837 policy. 2839 (d) trust anchor information, describing a CA that serves as a 2840 trust anchor for the certification path. The trust anchor 2841 information includes: 2843 (1) the trusted issuer name, 2845 (2) the trusted public key algorithm, 2847 (3) the trusted public key, and 2849 (4) optionally, the trusted public key parameters associated 2850 with the public key. 2852 The trust anchor information may be provided to the path 2853 processing procedure in the form of a self-signed certificate. The 2854 trusted anchor information is trusted because it was delivered to 2855 the path processing procedure by some trustworthy out-of-band 2856 procedure. If the trusted public key algorithm requires 2857 parameters, then the parameters are provided along with the 2858 trusted public key. 2860 (e) initial-policy-mapping-inhibit, which indicates if policy 2861 mapping is allowed in the certification path. 2863 (f) initial-explicit-policy, which indicates if the path must be 2864 valid for at least one of the certificate policies in the user- 2865 initial-policy-set. 2867 (g) initial-any-policy-inhibit, which indicates whether the any- 2868 policy OID should be processed if it is included in a certificate. 2870 6.1.2 Initialization 2872 The initialization phase establishes eleven state variables based 2873 upon the seven inputs: 2875 (a) valid_policy_tree: A tree of certificate policies with their 2876 optional qualifiers; each of the leaves of the tree represents a 2877 valid policy at this stage in the certification path validation. 2878 If valid policies exist at this stage in the certification path 2879 validation, the depth of the tree is equal to the number of 2880 certificates in the chain that have been processed. If valid 2881 policies do not exist at this stage in the certification path 2882 validation, the tree is set to NULL. Once the tree is set to NULL, 2883 policy processing ceases. 2885 Each node in the valid_policy_tree includes four data objects: the 2886 valid policy, a set of associated policy qualifiers, a set of one 2887 or more expected policy values, and a criticality indicator. If 2888 the node is at depth x, the components of the node have the 2889 following semantics: 2891 (1) The valid_policy is a single policy OID representing a 2892 valid policy for the path of length x. 2894 (2) The qualifier_set is a set of policy qualifiers associated 2895 with the valid policy in certificate x. 2897 (3) The criticality_indicator indicates whether the certificate 2898 policy extension in certificate x was marked as critical. 2900 (4) The expected_policy_set contains one or more policy OIDs 2901 that would satisfy this policy in the certificate x+1. 2903 The initial value of the valid_policy_tree is a single node with 2904 valid_policy any-policy, an empty qualifier_set, an 2905 expected_policy_set with the single value any-policy, and a 2906 criticality_indicator of FALSE. This node is considered to be at 2907 depth zero. 2909 Figure 3 is a graphic representation of the initial state of the 2910 valid_policy_tree. Additional figures will use this format to 2911 describe changes in the valid_policy_tree during path processing. 2913 +----------------+ 2914 | any-policy | <---- valid_policy 2915 +----------------+ 2916 | {} | <---- qualifier_set 2917 +----------------+ 2918 | FALSE | <---- criticality_indicator 2919 +----------------+ 2920 | {any-policy} | <---- expected_policy_set 2921 +----------------+ 2923 Figure 3. Initial value of the valid_policy_tree state variable 2925 (b) permitted_subtrees: A set of root names for each name type 2926 (e.g., X.500 distinguished names, email addresses, or ip 2927 addresses) defining a set of subtrees within which all subject 2928 names in subsequent certificates in the certification path shall 2929 fall. This variable includes a set for each name type: the initial 2930 value for the set for Distinguished Names is the set of all 2931 Distinguished names; the initial value for the set of RFC822 names 2932 is the set of all RFC822 names, etc. 2934 (c) excluded_subtrees: A set of root names for each name type 2935 (e.g., X.500 distinguished names, email addresses, or ip 2936 addresses) defining a set of subtrees within which no subject name 2937 in subsequent certificates in the certification path may fall. 2938 This variable includes a set for each name type, and the initial 2939 value for each set is empty. 2941 (d) explicit_policy: an integer which indicates if a non-NULL 2942 valid_policy_tree is required. The integer indicates the number of 2943 non-self-issued certificates to be processed before this 2944 requirement is imposed. Once set, this variable may be decreased, 2945 but may not be increased. That is, if a certificate in the path 2946 requires a non-NULL valid_policy_tree, a later certificate can not 2947 remove this requirement. If initial-explicit-policy is set, then 2948 the initial value is 0, otherwise the initial value is n+1. 2950 (e) inhibit_any-policy: an integer which indicates whether the 2951 any-policy policy identifier is considered a match. The integer 2952 indicates the number of non-self-issued certificates to be 2953 processed before the any-policy OID, if asserted in a certificate, 2954 is ignored. Once set, this variable may be decreased, but may not 2955 be increased. That is, if a certificate in the path inhibits 2956 processing of any-policy, a later certificate can not permit it. 2957 If initial-any-policy-inhibit is set, then the initial value is 0, 2958 otherwise the initial value is n+1. 2960 (f) policy_mapping: an integer which indicates if policy mapping 2961 is permitted. The integer indicates the number of non-self-issued 2962 certificates to be processed before policy mapping is inhibited. 2963 Once set, this variable may be decreased, but may not be 2964 increased. That is, if a certificate in the path specifies policy 2965 mapping is not permitted, it can not be overridden by a later 2966 certificate. If initial-policy-mapping-inhibit is set, then the 2967 initial value is 0, otherwise the initial value is n+1. 2969 (g) working_public_key_algorithm: the digital signature algorithm 2970 used to verify the signature of a certificate. The 2971 working_public_key_algorithm is initialized from the trusted 2972 public key algorithm provided in the trust anchor information. 2974 (h) working_public_key: the public key used to verify the 2975 signature of a certificate. The working_public_key is initialized 2976 from the trusted public key provided in the trust anchor 2977 information. 2979 (i) working_public_key_parameters: parameters associated with the 2980 current public key, that may required to verify a signature 2981 (depending upon the algorithm). The working_public_key_parameters 2982 variable is initialized from the trusted public key parameters 2983 provided in the trust anchor information. 2985 (j) working_issuer_name: the issuer distinguished name expected 2986 in the next certificate in the chain. The working_issuer_name is 2987 initialized to the trusted issuer provided in the trust anchor 2988 information. 2990 (k) max_path_length: this integer is initialized to n, and is 2991 reset by the path length constraint field within the basic 2992 constraints extension of a CA certificate. 2994 Upon completion of the initialization steps, perform the basic 2995 certificate processing steps specified in 6.1.3. 2997 6.1.3 Basic Certificate Processing 2999 The basic path processing actions to be performed for certificate i 3000 are listed below. 3002 (a) Verify the basic certificate information. The certificate 3003 must satisfy each of the following: 3005 (1) The certificate was signed with the 3006 working_public_key_algorithm using the working_public_key and 3007 the working_public_key_parameters. 3009 (2) The certificate validity period includes time T. 3011 (3) At time T, the certificate is not revoked and is not on 3012 hold status. This may be determined by obtaining the 3013 appropriate CRL (see section 6.3), status information, or by 3014 out-of-band mechanisms. 3016 (4) The certificate issuer name is the working_issuer_name. 3018 (5) The certificate issuer unique identifier is the 3019 working_issuer_UID, meaning: 3021 (i) working_issuer_UID is non-null and matches the value in 3022 the issuerUID field, or 3024 (ii) working_issuer_UID is null and the issuerUID field is 3025 not present. 3027 (b) If certificate i is not self-issued, verify that the subject 3028 name is within one of the permitted_subtrees for X.500 3029 distinguished names, and verify that each of the alternative names 3030 in the subjectAltName extension (critical or non-critical) is 3031 within one of the permitted_subtrees for that name type. 3033 (c) If certificate i is not self-issued, verify that the subject 3034 name is not within one of the excluded_subtrees for X.500 3035 distinguished names, and verify that each of the alternative names 3036 in the subjectAltName extension (critical or non-critical) is not 3037 within one of the excluded_subtrees for that name type. 3039 (d) If the certificate policies extension is present in the 3040 certificiate and the valid_policy_tree is not NULL, process the 3041 policy information by performing the following steps in order: 3043 (1) For each policy P not equal to any-policy in the 3044 certificate policies extension, let P-OID denote the OID in 3045 policy P and P-Q denote the qualifier set for policy P. 3046 Perform the following steps in order: 3048 (i) If the valid_policy_tree includes a node of depth i-1 3049 where P-OID is in the expected_policy_set, create a child 3050 node as follows: set the valid_policy to OID- P; set the 3051 qualifier_set to P-Q, and set the expected_policy_set to 3052 {P-OID}. 3054 For example, consider a valid_policy_tree with a node of 3055 depth i-1 where the expected_policy_set is {Gold, White}. 3056 Assume the certificate policies Gold and Silver appear in 3057 the certificate policies extension of certificate i. The 3058 Gold policy is matched but the Silver policy is not. This 3059 rule will generate a child node of depth i for the Gold 3060 policy. The result is shown as Figure 4. 3062 |-----------------| 3063 | Red | 3064 |-----------------| 3065 | {} | 3066 |-----------------| node of depth i-1 3067 | FALSE | 3068 |-----------------| 3069 | {Gold, White} | 3070 |-----------------| 3071 | 3072 | 3073 | 3074 V 3075 |-----------------| 3076 | Gold | 3077 |-----------------| 3078 | {} | 3079 |-----------------| node of depth i 3080 | uninitialized | 3081 |-----------------| 3082 | {Gold} | 3083 |-----------------| 3085 Figure 4. Processing an exact match 3087 (ii) If there was no match in step (i) and the 3088 valid_policy_tree includes a node of depth i-1 with the 3089 valid policy any-policy, generate a child node with the 3090 following values: set the valid_policy to P-OID; set the 3091 qualifier_set to P-Q, and set the expected_policy_set to 3092 {P-OID}. 3094 For example, consider a valid_policy_tree with a node of 3095 depth i-1 where the valid_policy is any-policy. Assume the 3096 certificate policies Gold and Silver appear in the 3097 certificate policies extension of certificate i. The Gold 3098 policy does not have a qualifier, but the Silver policy has 3099 the qualifier Q-Silver. If Gold and Silver were not matched 3100 in (i) above, this rule will generate two child nodes of 3101 depth i, one for each policy. The result is shown as Figure 3102 5. 3104 |-----------------| 3105 | any-policy | 3106 |-----------------| 3107 | {} | 3108 |-----------------| node of depth i-1 3109 | FALSE | 3110 |-----------------| 3111 | {any-policy} | 3112 |-----------------| 3113 / \ 3114 / \ 3115 / \ 3116 / \ 3117 |-----------------| |-----------------| 3118 | Gold | | Silver | 3119 |-----------------| |-----------------| 3120 | {} | | {Q-Silver} | 3121 |-----------------| nodes of |-----------------| 3122 | uninitialized | depth i | uninitialized | 3123 |-----------------| |-----------------| 3124 | {Gold} | | {Silver} | 3125 |-----------------| |-----------------| 3127 Figure 5. Processing unmatched policies when a leaf node 3128 specifies any-policy 3130 (2) If the certificate policies extension includes the policy 3131 any-policy with the qualifier set AP-Q and inhibit_any-policy 3132 is greater than 0, then: 3134 For each node in the valid_policy_tree of depth i-1, for each 3135 value in the expected_policy_set (including any-policy) that 3136 does not appear in a child node, create a child node with the 3137 following values: set the valid_policy to the value from the 3138 expected_policy_set in the parent node; set the qualifier_set 3139 to AP-Q, and set the expected_policy_set to the value in the 3140 valid_policy from this node. 3142 For example, consider a valid_policy_tree with a node of depth 3143 i-1 where the expected_policy_set = {Gold, Silver}. Assume 3144 any-policy appears in the certificate policies extension of 3145 certificate i, but Gold and Silver do not. This rule will 3146 generate two child nodes of depth i, one for each policy. The 3147 result is shown below as Figure 6. 3149 |-----------------| 3150 | Red | 3151 |-----------------| 3152 | {} | 3153 |-----------------| node of depth i-1 3154 | FALSE | 3155 |-----------------| 3156 | {Gold, Silver} | 3157 |-----------------| 3158 / \ 3159 / \ 3160 / \ 3161 / \ 3162 |-----------------| |-----------------| 3163 | Gold | | Silver | 3164 |-----------------| |-----------------| 3165 | {} | | {} | 3166 |-----------------| nodes of |-----------------| 3167 | uninitialized | depth i | uninitialized | 3168 |-----------------| |-----------------| 3169 | {Gold} | | {Silver} | 3170 |-----------------| |-----------------| 3172 Figure 6. Processing unmatched policies when the certificate 3173 policies extension specifies any-policy 3175 (3) If there is a node in the valid_policy_tree of depth i-1 or 3176 less without any child nodes, delete that node. Repeat this 3177 step until there are no nodes of depth i-1 or less without 3178 children. 3180 For example, consider the valid_policy_tree shown in Figure 7 3181 below. The two nodes at depth i-1 that are marked with an to 3182 the resulting tree will cause the node at depth i-2 that is 3183 marked with an 'Y' to be deleted. The following application of 3184 the rule does not cause any nodes to be deleted, and this step 3185 is complete. 3187 +-----------+ 3188 | | node of depth i-3 3189 +-----------+ 3190 / | \ 3191 / | \ 3192 / | \ 3193 +-----------+ +-----------+ +-----------+ 3194 | | | | | Y | nodes of 3195 +-----------+ +-----------+ +-----------+ depth i-2 3196 / \ || || 3197 / \ || || 3198 / \ || || 3199 +-----------+ +-----------+ +-----------+ +-----------+ nodes of 3200 | | | X | | | | X | depth 3201 +-----------+ +-----------+ +-----------+ +-----------+ i-1 3202 | / | \ 3203 | / | \ 3204 | / | \ 3205 +-----------+ +-----------+ +-----------+ +-----------+ nodes of 3206 | | | | | | | | depth 3207 +-----------+ +-----------+ +-----------+ +-----------+ i 3209 Figure 7. Pruning the valid_policy_tree 3211 (4) If the certificate policies extension was marked as 3212 critical, set the criticality_indicator in all nodes of depth i 3213 to TRUE. If the certificate policies extension was not marked 3214 critical, set the criticality_indicator in all nodes of depth i 3215 to FALSE. 3217 (e) If the certificate policies extension is not present, set the 3218 valid_policy_tree to NULL. 3220 (f) verify that either explicit_policy is greater than 0 or the 3221 valid_policy_tree is not equal to NULL; 3223 If any of steps (a), (b), (c), or (f) fails, the procedure 3224 terminates, returning a failure indication and an appropriate reason. 3226 If i is not equal to n, continue by performing the preparatory steps 3227 listed in 6.1.4. If i is equal to n, perform the wrap-up steps 3228 listed in 6.1.5. 3230 6.1.4 Preparation for Certificate i+1 3232 To prepare for processing of certificate i+1, perform the following 3233 steps for certificate i: 3235 (a) If a policy mapping extension is present, verify that the 3236 special value any-policy does not appear as an issuerDomainPolicy 3237 or a subjectDomainPolicy. 3239 (b) If a policy mapping extension is present, then for each 3240 issuerDomainPolicy ID-P in the policy mapping extension: 3242 (1) If the policy_mapping variable is greater than 0, for each 3243 node in the valid_policy_tree of depth i where ID-P is the 3244 valid_policy, set expected_policy_set to the set of 3245 subjectDomainPolicy values that are specified as equivalent to 3246 ID-P by the policy mapping extension. 3248 If no node of depth i in the valid_policy_tree has a 3249 valid_policy of ID-P but there is a node of depth i with a 3250 valid_policy of any-policy, then generate a child node of the 3251 node of depth i-1 that has a valid_policy of any-policy as 3252 follows: 3254 (i) set the valid_policy to ID-P; 3256 (ii) set the qualifier_set to the qualifier set of the 3257 policy any-policy in the certificate policies extension of 3258 certificate i; 3260 (iii) set the criticality_indicator to the criticality of 3261 the certificate policies extension of certificate i; 3263 (iv) and set the expected_policy_set to the set of 3264 subjectDomainPolicy values that are specified as equivalent 3265 to ID-P by the policy mappings extension. 3267 (2) If the policy_mapping variable is equal to 0: 3269 (i) delete each node of depth i in the valid_policy_tree 3270 where ID-P is the valid_policy. 3272 (ii) If there is a node in the valid_policy_tree of depth 3273 i-1 or less without any child nodes, delete that node. 3274 Repeat this step until there are no nodes of depth i-1 or 3275 less without children. 3277 (c) Assign the certificate subject name to working_issuer_name. 3279 (d) Assign the certificate subjectPublicKey to working_public_key. 3281 (e) If the subjectPublicKeyInfo field of the certificate contains 3282 an algorithm field with non-null parameters, assign the parameters 3283 to the working_public_key_parameters variable. 3285 If the subjectPublicKeyInfo field of the certificate contains an 3286 algorithm field with null parameters or parameters are omitted, 3287 compare the certificate subjectPublicKey algorithm to the 3288 working_public_key_algorithm. If the certificate subjectPublicKey 3289 algorithm and the working_public_key_algorithm are different, set 3290 the working_public_key_parameters to null. 3292 (f) Assign the certificate subjectPublicKey algorithm to the 3293 working_public_key_algorithm variable. 3295 (g) If a name constraints extension is included in the 3296 certificate, modify the permitted_subtrees and excluded_subtrees 3297 state variables as follows: 3299 (1) If permittedSubtrees is present in the certificate, set the 3300 permitted_subtrees state variable to the intersection of its 3301 previous value and the value indicated in the extension field. 3302 If permittedSubtrees does not include a particular name type, 3303 the permitted_subtrees state variable is unchanged for that 3304 name type. 3306 (2) If excludedSubtrees is present in the certificate, set the 3307 excluded_subtrees state variable to the union of its previous 3308 value and the value indicated in the extension field. If 3309 excludedSubtrees does not include a particular name type, the 3310 excluded_subtrees state variable is unchanged for that name 3311 type. 3313 (h) If the issuer and subject names are not identical: 3315 (1) If explicit_policy is not 0, decrement explicit_policy by 3316 1. 3318 (2) If policy_mapping is not 0, decrement policy_mapping by 1. 3320 (3) If inhibit_any-policy is not 0, decrement inhibit_any- 3321 policy by 1. 3323 (i) If a policy constraints extension is included in the 3324 certificate, modify the explicit_policy and policy_mapping state 3325 variables as follows: 3327 (1) If requireExplicitPolicy is present and is less than 3328 explicit_policy, set explicit_policy to the value of 3329 requireExplicitPolicy. 3331 (2) If inhibitPolicyMapping is present and is less than 3332 policy_mapping, set policy_mapping to the value of 3333 inhibitPolicyMapping. 3335 (j) If the inhibitAnyPolicy extension is included in the 3336 certificate and is less than inhibit_any-policy, set inhibit_any- 3337 policy to the value of inhibitAnyPolicy. 3339 (k) Verify that the certificate is a CA certificate (as specified 3340 in a basicConstraints extension or as verified out-of-band). 3342 (l) If the certificate was not self-issued, verify that 3343 max_path_length is greater than zero and decrement max_path_length 3344 by 1. 3346 (m) If pathLengthConstraint is present in the certificate and is 3347 less than max_path_length, set max_path_length to the value of 3348 pathLengthConstraint. 3350 (n) If a key usage extension is present and marked critical, 3351 verify that the keyCertSign bit is set. 3353 (o) Recognize and process any other critical extension present in 3354 the certificate. 3356 If check (a), (k), (l), (n) or (o) fails, the procedure terminates, 3357 returning a failure indication and an appropriate reason. 3359 If (a), (k), (l), (n) and (o) have completed successfully, increment 3360 i and perform the basic certificate processing specified in 6.1.2. 3362 6.1.5 Wrap-up procedure 3364 To complete the processing of the end entity certificate, perform the 3365 following steps for certificate n: 3367 (a) If certificate n was not self-issued and explicit_policy is 3368 not 0, decrement explicit_policy by 1. 3370 (b) If a policy constraints extension is included in the 3371 certificate and requireExplicitPolicy is present and has a value 3372 of 0, set the explicit_policy state variable to 0. 3374 (c) Assign the certificate subjectPublicKey to working_public_key. 3376 (d) If the subjectPublicKeyInfo field of the certificate contains 3377 an algorithm field with non-null parameters, assign the parameters 3378 to the working_public_key_parameters variable. 3380 If the subjectPublicKeyInfo field of the certificate contains an 3381 algorithm field with null parameters or parameters are omitted, 3382 compare the certificate subjectPublicKey algorithm to the 3383 working_public_key_algorithm. If the certificate subjectPublicKey 3384 algorithm and the working_public_key_algorithm are different, set 3385 the working_public_key_parameters to null. 3387 (e) Assign the certificate subjectPublicKey algorithm to the 3388 working_public_key_algorithm variable. 3390 (f) Recognize and process any other critical extension present in 3391 the certificate n. 3393 (g) Calculate the intersection of the valid_policy_tree and the 3394 user-initial-policy-set, as follows: 3396 (i) If the valid_policy_tree is NULL, the intersection is NULL. 3398 (ii) If the valid_policy_tree is not NULL and the user- 3399 initial-policy-set is any-policy, the intersection is the 3400 entire valid_policy_tree. 3402 (iii) If the valid_policy_tree is not NULL and the user- 3403 initial-policy-set is not any-policy, calculate the 3404 intersection of the valid_policy_tree and the user-initial- 3405 policy-set as follows: 3407 1. Determine the set of policy nodes whose parent nodes have 3408 a valid_policy of any-policy. This is the 3409 valid_policy_node_set. 3411 2. If the valid_policy of any node in the 3412 valid_policy_node_set is not in the user-initial-policy-set 3413 and is not any-policy, delete this node and all its 3414 children. 3416 3. If there is a node in the valid_policy_tree of depth n-1 3417 or less without any child nodes, delete that node. Repeat 3418 this step until there are no nodes of depth n-1 or less 3419 without children. 3421 Upon completion of all steps, path processing has succeeded if the 3422 value of explicit_policy variable is greater than zero, or the 3423 valid_policy_tree is not NULL. 3425 6.1.6 Outputs 3427 If path processing succeeds, the procedure terminates, returning a 3428 success indication together with final value of the 3429 valid_policy_tree, the working_public_key, the 3430 working_public_key_algorithm, and the working_public_key_parameters. 3432 6.2 Using the Path Validation Algorithm 3434 The path validation algorithm describes the process of validating a 3435 single certification path. While each path begins with a specific 3436 trust anchor, there is no requirement that all paths validated by a 3437 particular system share a single trust anchor. 3439 The selection of one or more trusted CAs is a local decision. A 3440 system may provide any one of its trusted CAs as the trust anchor for 3441 a particular path. The inputs to the path validation algorithm may 3442 be different for each path. The inputs used to process a path may 3443 reflect application-specific requirements or limitations in the trust 3444 accorded a particular trust anchor. For example, a trusted CA may 3445 only be trusted for a particular certificate policy. This 3446 restriction can be expressed through the inputs to the path 3447 validation procedure. 3449 It is also possible to specify an extended version of the above 3450 certification path processing procedure which results in default 3451 behavior identical to the rules of PEM [RFC 1422]. In this extended 3452 version, additional inputs to the procedure are a list of one or more 3453 Policy Certification Authorities (PCAs) names and an indicator of the 3454 position in the certification path where the PCA is expected. At the 3455 nominated PCA position, the CA name is compared against this list. 3456 If a recognized PCA name is found, then a constraint of 3457 SubordinateToCA is implicitly assumed for the remainder of the 3458 certification path and processing continues. If no valid PCA name is 3459 found, and if the certification path cannot be validated on the basis 3460 of identified policies, then the certification path is considered 3461 invalid. 3463 6.3 CRL Validation 3465 This section describes the steps necessary to determine if a 3466 certificate is revoked or on hold status when CRLs are the revocation 3467 mechanism used by the certificate issuer. Conforming implementations 3468 of this specification are not required to implement this algorithm, 3469 but MUST be functionally equivalent to the external behavior 3470 resulting from this procedure. Any algorithm may be used by a 3471 particular implementation so long as it derives the correct result. 3473 This algorithm defines a set of inputs, a set of state variables, and 3474 processing steps that are performed for each certificate in the path. 3476 6.3.1 Revocation Inputs 3478 To support revocation processing, the algorithm requires two inputs: 3480 (a) certificate: the algorithm requires the certificate serial 3481 number and issuer name to determine if a certificate is on a 3482 particular CRL. The basicConstraints extension is used to 3483 determine whether the supplied certificate is associated with a CA 3484 or an end-entity. If present, the algorithm may use the 3485 cRLDistributionsPoint and freshestCRL extensions to determine 3486 revocation status. 3488 (b) use-deltas: This boolean input determines if the delta needs 3489 to be checked if the CRL is still valid. 3491 Note that implementations supporting legacy PKIs, such as RFC 1422 3492 and X.509 version 1, will need an additional input indicating 3493 whether the supplied certificate is associated with a CA or an 3494 end-entity. 3496 6.3.2 Initialization and Revocation State Variables 3498 To support CRL processing, the algorithm requires the following state 3499 variables: 3501 (a) reasons_mask: This variable contains the set of revocation 3502 reasons supported by the CRLs and delta CRLs processed so far. The 3503 legal members of the set are the possible values for reasonflags: 3504 unspecified; keyCompromise; caCompromise; affiliationChanged; 3505 superseded; cessationOfOperation; and certificateHold. The 3506 special value all-reasons is used to denote the set of all legal 3507 members. This variable is initialized to the empty set. 3509 (b) cert_status: This variable contains the status of the 3510 certificate. Legal values are unspecified; keyCompromise; 3511 caCompromise; affiliationChanged; superseded; 3512 cessationOfOperation; and certificateHold, the special value 3513 UNREVOKED, or the special value UNDETERMINED. This variable is 3514 initialized to the special value UNREVOKED. 3516 (c) interim_reasons_mask: This contains the set of revocation 3517 reasons supported by the CRL or delta CRL currently being 3518 processed. 3520 Note: In some environments, it is not necessary to check all reason 3521 codes. For example, some envornments only are concerned with 3522 caCompromise and keyCompromise for CA certificates. This algorithnm 3523 checks all reason codes. Additional processing and state variables 3524 may be necessary to limit the checking to a subset of the reason 3525 codes. 3527 6.3.3 CRL Processing 3529 This algorithm begins by assuming the certificate is not revoked. 3530 The algorithm checks one or more CRLs until either the certificate 3531 status is determined to be revoked or sufficent CRLs have been 3532 checked to cover all reason codes. 3534 For each distribution point (DP) in the crl distribution points 3535 extension while ((reasons_mask is not all-reasons) and (cert_status 3536 is UNREVOKED)) 3538 (1) locate the corresponding CRL in CRL cache, and perform the 3539 following verifications: 3541 (a) compute the interim_reasons_mask for this CRL as follows: 3543 1. if the CRL includes reasons and the DP includes reasons, 3544 then set interim_reasons_mask to the intersection of of 3545 reasons in the DP and reasons in CRL reasons extension. 3547 2. if the CRL includes reasons but the DP omits reasons, 3548 then set interim_reasons_mask to the value of CRL reasons. 3550 3. if the CRL omits reasons but the DP includes reasons, 3551 then set interim_reasons_mask to the value of DP reasons. 3553 4. if the CRL omits reasons and the DP omits reasons, then 3554 set interim_reasons_mask to the special value all-reasons. 3556 Verify that interim_reasons_mask includes one or more reasons 3557 that is not included in the reasons_mask. 3559 (b) Verify the issuer of the CRL as follows: 3561 if the DP includes cRLIssuer, then verify that the CRL 3562 issuer matches cRLIssuer else verify that the CRL issuer 3563 matches the certificate issuer. 3565 (c) obtain and validate the certification path for the CRL 3566 issuer. 3568 (d) validate the signature on the CRL. 3570 (2) If each of the verifications (a) through (d) succeeds, then 3571 perform the following steps: 3573 (a) If the value of next update field is before the current- 3574 time, otain an appropriate delta CRL or discard the CRL. 3576 (b) If the user wants freshest available info AND the freshest 3577 CRL extension is present, check for a corresponding delta for 3578 this base. 3580 (c) If a delta was obtained in (a) or (b), verify that the 3581 delta CRL addresses the same set of certificates and the same 3582 set of reasons as the CRL. 3584 (d) Perform the checks in step 1 (b) and (c): 3586 1. obtain and validate the certification path for the delta 3587 issuer 3589 2. validate the signature on the delta CRL 3591 (e) If a delta CRL was obtained in (a) or (b), and the 3592 verifications (c) and (d) suceeded, combine the base and 3593 delta to form a complete CRL. 3595 (3) If steps and (1) and (2) succeed, then set reasons_mask to the 3596 union of reasons_mask and interim_reasons_mask 3598 (4) Search for the certificate on the CRL 3600 (a) search for the serial number on the CRL 3602 (b) if (a) succeeds, verify that (1) the CRL entry extension 3603 Certificate issuer is not present or (2) the issuer identified 3604 in the CRL entry extension Certificate issuer is the issuer of 3605 the certificate. 3607 (c) if (a) and (b) succeeded, set the cert_status variable as 3608 appropriate: 3610 1. if the reasons extension is present, set the cert_status 3611 variable to the value of the reasons extension 3613 2. if the reasons extension is not present, set the 3614 cert_status variable to the special value not-specified. 3616 if ((reasons_mask is all-reasons) OR (if cert_status is not 3617 UNREVOKED) return cert_status 3619 If all CRLs named in the crl distribution points extension have 3620 been exhausted, and the reasons_mask is not all-reasons and the 3621 cert_status is still UNREVOKED, the verifier must obtain 3622 additional CRLs. 3624 The verifier must repeat the process above with the additional 3625 CRLs not specified in a distribution point. 3627 If all CRLs are exhausted and the reasons_mask is not all-reasons 3628 return the cert_status UNDETERMINED. 3630 7 References 3632 [RFC 791] J. Postel, "Internet Protocol", September 1981. 3634 [RFC 822] D. Crocker, "Standard for the format of ARPA Internet text 3635 messages", August 1982. 3637 [RFC 1034] P.V. Mockapetris, "Domain names - concepts and 3638 facilities", November 1987. 3640 [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic 3641 Mail: Part II: Certificate-Based Key Management," RFC 3642 1422, BBN Communications, February 1993. 3644 [RFC 1423] Balenson, D., "Privacy Enhancement for Internet Electronic 3645 Mail: Part III: Algorithms, Modes, and Identifiers," 3646 RFC 1423, Trusted Information Systems, February 1993. 3648 [RFC 1510] Kohl, J., and C. Neuman, "The Kerberos Network 3649 Authentication Service (V5)," RFC 1510, September 1993. 3651 [RFC 1519] V. Fuller, T. Li, J. Yu, and K. Varadhan. "Classless 3652 Inter-Domain Routing (CIDR): an Address Assignment and 3653 Aggregation Strategy", September 1993. 3655 [RFC 1738] Berners-Lee, T., Masinter L., and M. McCahill. 3656 "Uniform Resource Locators (URL)", RFC 1738, December 1994. 3658 [RFC 1778] Howes, T., Kille S., Yeong, W. and C. Robbins. "The 3659 String Representation of Standard Attribute Syntaxes," 3660 RFC 1778, March 1995. 3662 [RFC 1883] S. Deering and R. Hinden. "Internet Protocol, Version 6 3663 (IPv6) Specification", December 1995. 3665 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 3666 Requirement Levels", March 1997. 3668 [RFC 2247] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. 3670 Sataluri. "Using Domains in LDAP/X.500 Distinguished Names", 3671 RFC 2247, January 1998. 3673 [RFC 2277] H. Alvestrand, "IETF Policy on Character Sets and 3674 Languages", January 1998. 3676 [RFC 2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646", 3677 January 1998. 3679 [RFC 2560] Myers, M., Ankney R., Malpani A., Galperin S., and 3680 C. Adams, "Online Certificate Status Protocal - OCSP", 3681 June 1999. 3683 [SDN.701] SDN.701, "Message Security Protocol 4.0", Revision A 3684 1997-02-06. 3686 [X.208] CCITT Recommendation X.208: Specification of Abstract 3687 Syntax Notation One (ASN.1), 1988. 3689 [X.501] ITU-T Recommendation X.501: Information 3690 Technology - Open Systems Interconnection - The 3691 Directory: Models, 1993. 3693 [X.509] ITU-T Recommendation X.509 (1997 E): Information 3694 Technology - Open Systems Interconnection - The 3695 Directory: Authentication Framework, June 1997. 3697 [X.520] ITU-T Recommendation X.520: Information 3698 Technology - Open Systems Interconnection - The 3699 Directory: Selected Attribute Types, 1993. 3701 [X9.55] ANSI X9.55-1995, Public Key Cryptography For The Financial 3702 Services Industry: Extensions To Public Key Certificates 3703 And Certificate Revocation Lists, 8 December, 1995. 3705 [PKINIT] Tung, B., Neuman C., Hur M., Medvinsky A., Medvinsky S., 3706 Wray J., and J. Trostle, "Public Key Cryptography for 3707 Initial Authentciaion in Kerberos," 3708 draft-ietf-cat-kerberos-pk-init-11.txt, March 15, 2000. 3710 [PKIX ALGS] Bassham, L., Housley, R., and W. Polk, "Internet X.509 3711 Public Key Infrastructure Representation of Public Keys 3712 and Digital Signatures," 3713 draft-ietf-pkix-ipki-pkalgs-00.txt, July 14, 2000. 3715 [PKIX TSA] Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 3716 Public Key Infrastructure Time Stamp Protocol," 3717 draft-ietf-pkix-time-stamp-12.txt, November, 2000. 3719 8 Intellectual Property Rights 3721 The IETF has been notified of intellectual property rights claimed in 3722 regard to some or all of the specification contained in this 3723 document. For more information consult the online list of claimed 3724 rights. 3726 The IETF takes no position regarding the validity or scope of any 3727 intellectual property or other rights that might be claimed to 3728 pertain to the implementation or use of the technology described in 3729 this document or the extent to which any license under such rights 3730 might or might not be available; neither does it represent that it 3731 has made any effort to identify any such rights. Information on the 3732 IETF's procedures with respect to rights in standards-track and 3733 standards-related documentation can be found in BCP-11. Copies of 3734 claims of rights made available for publication and any assurances of 3735 licenses to be made available, or the result of an attempt made to 3736 obtain a general license or permission for the use of such 3737 proprietary rights by implementors or users of this specification can 3738 be obtained from the IETF Secretariat. 3740 9 Security Considerations 3742 The majority of this specification is devoted to the format and 3743 content of certificates and CRLs. Since certificates and CRLs are 3744 digitally signed, no additional integrity service is necessary. 3745 Neither certificates nor CRLs need be kept secret, and unrestricted 3746 and anonymous access to certificates and CRLs has no security 3747 implications. 3749 However, security factors outside the scope of this specification 3750 will affect the assurance provided to certificate users. This 3751 section highlights critical issues that should be considered by 3752 implementors, administrators, and users. 3754 The procedures performed by CAs and RAs to validate the binding of 3755 the subject's identity of their public key greatly affect the 3756 assurance that should be placed in the certificate. Relying parties 3757 may wish to review the CA's certificate practice statement. This may 3758 be particularly important when issuing certificates to other CAs. 3760 The use of a single key pair for both signature and other purposes is 3761 strongly discouraged. Use of separate key pairs for signature and key 3762 management provides several benefits to the users. The ramifications 3763 associated with loss or disclosure of a signature key are different 3764 from loss or disclosure of a key management key. Using separate key 3765 pairs permits a balanced and flexible response. Similarly, different 3766 validity periods or key lengths for each key pair may be appropriate 3767 in some application environments. Unfortunately, some legacy 3768 applications (e.g., SSL) use a single key pair for signature and key 3769 management. 3771 The protection afforded private keys is a critical factor in 3772 maintaining security. On a small scale, failure of users to protect 3773 their private keys will permit an attacker to masquerade as them, or 3774 decrypt their personal information. On a larger scale, compromise of 3775 a CA's private signing key may have a catastrophic effect. If an 3776 attacker obtains the private key unnoticed, the attacker may issue 3777 bogus certificates and CRLs. Existence of bogus certificates and 3778 CRLs will undermine confidence in the system. If the compromise is 3779 detected, all certificates issued to the CA shall be revoked, 3780 preventing services between its users and users of other CAs. 3781 Rebuilding after such a compromise will be problematic, so CAs are 3782 advised to implement a combination of strong technical measures 3783 (e.g., tamper-resistant cryptographic modules) and appropriate 3784 management procedures (e.g., separation of duties) to avoid such an 3785 incident. 3787 Loss of a CA's private signing key may also be problematic. The CA 3788 would not be able to produce CRLs or perform normal key rollover. 3789 CAs are advised to maintain secure backup for signing keys. The 3790 security of the key backup procedures is a critical factor in 3791 avoiding key compromise. 3793 The availability and freshness of revocation information will affect 3794 the degree of assurance that should be placed in a certificate. 3795 While certificates expire naturally, events may occur during its 3796 natural lifetime which negate the binding between the subject and 3797 public key. If revocation information is untimely or unavailable, 3798 the assurance associated with the binding is clearly reduced. 3799 Similarly, implementations of the Path Validation mechanism described 3800 in section 6 that omit revocation checking provide less assurance 3801 than those that support it. 3803 The path validation algorithm depends on the certain knowledge of the 3804 public keys (and other information) about one or more trusted CAs. 3805 The decision to trust a CA is an important decision as it ultimately 3806 determines the trust afforded a certificate. The authenticated 3807 distribution of trusted CA public keys (usually in the form of a 3808 "self-signed" certificate) is a security critical out of band process 3809 that is beyond the scope of this specification. 3811 In addition, where a key compromise or CA failure occurs for a 3812 trusted CA, the user will need to modify the information provided to 3813 the path validation routine. Selection of too many trusted CAs will 3814 make the trusted CA information difficult to maintain. On the other 3815 hand, selection of only one trusted CA may limit users to a closed 3816 community of users until a global PKI emerges. 3818 The quality of implementations that process certificates may also 3819 affect the degree of assurance provided. The path validation 3820 algorithm described in section 6 relies upon the integrity of the 3821 trusted CA information, and especially the integrity of the public 3822 keys associated with the trusted CAs. By substituting public keys 3823 for which an attacker has the private key, an attacker could trick 3824 the user into accepting false certificates. 3826 The binding between a key and certificate subject cannot be stronger 3827 than the cryptographic module implementation and algorithms used to 3828 generate the signature. Short key lengths or weak hash algorithms 3829 will limit the utility of a certificate. CAs are encouraged to note 3830 advances in cryptology so they can employ strong cryptographic 3831 techniques. In addition, CAs should decline to issue certificates to 3832 CAs or end entities that generate weak signatures. 3834 Inconsistent application of name comparison rules may result in 3835 acceptance of invalid X.509 certification paths, or rejection of 3836 valid ones. The X.500 series of specifications defines rules for 3837 comparing distinguished names require comparison of strings without 3838 regard to case, character set, multi-character white space substring, 3839 or leading and trailing white space. This specification relaxes 3840 these requirements, requiring support for binary comparison at a 3841 minimum. 3843 CAs shall encode the distinguished name in the subject field of a CA 3844 certificate identically to the distinguished name in the issuer field 3845 in certificates issued by the latter CA. If CAs use different 3846 encodings, implementations of this specification may fail to 3847 recognize name chains for paths that include this certificate. As a 3848 consequence, valid paths could be rejected. 3850 In addition, name constraints for distinguished names shall be stated 3851 identically to the encoding used in the subject field or 3852 subjectAltName extension. If not, (1) name constraints stated as 3853 excludedSubTrees will not match and invalid paths will be accepted 3854 and (2) name constraints expressed as permittedSubtrees will not 3855 match and valid paths will be rejected. To avoid acceptance of 3856 invalid paths, CAs should state name constraints for distinguished 3857 names as permittedSubtrees where ever possible. 3859 Appendix A. Psuedo-ASN.1 Structures and OIDs 3861 This section describes data objects used by conforming PKI components 3862 in an "ASN.1-like" syntax. This syntax is a hybrid of the 1988 and 3863 1993 ASN.1 syntaxes. The 1988 ASN.1 syntax is augmented with 1993 3864 UNIVERSAL Types UniversalString, BMPString and UTF8String. 3866 The ASN.1 syntax does not permit the inclusion of type statements in 3867 the ASN.1 module, and the 1993 ASN.1 standard does not permit use of 3868 the new UNIVERSAL types in modules using the 1988 syntax. As a 3869 result, this module does not conform to either version of the ASN.1 3870 standard. 3872 This appendix may be converted into 1988 ASN.1 by replacing the 3873 defintions for the UNIVERSAL Types with the 1988 catch-all "ANY". 3875 A.1 Explicitly Tagged Module, 1988 Syntax 3877 PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) 3878 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)} 3880 DEFINITIONS EXPLICIT TAGS ::= 3882 BEGIN 3884 -- EXPORTS ALL -- 3886 -- IMPORTS NONE -- 3888 -- UNIVERSAL Types defined in '93 and '98 ASN.1 3889 -- but required by this specification 3891 UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING 3892 -- UniversalString is defined in ASN.1:1993 3894 BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING 3895 -- BMPString is the subtype of UniversalString and models 3896 -- the Basic Multilingual Plane of ISO/IEC/ITU 10646-1 3898 UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 3899 -- The content of this type conforms to RFC 2279. 3901 -- 3902 -- PKIX specific OIDs 3904 id-pkix OBJECT IDENTIFIER ::= 3905 { iso(1) identified-organization(3) dod(6) internet(1) 3906 security(5) mechanisms(5) pkix(7) } 3907 -- PKIX arcs 3909 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 3910 -- arc for private certificate extensions 3911 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 3912 -- arc for policy qualifier types 3913 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 3914 -- arc for extended key purpose OIDS 3915 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 3916 -- arc for access descriptors 3918 -- policyQualifierIds for Internet policy qualifiers 3920 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 3921 -- OID for CPS qualifier 3922 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 3923 -- OID for user notice qualifier 3925 -- access descriptor definitions 3927 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 3928 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 3929 id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 } 3930 id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 } 3932 -- attribute data types -- 3934 Attribute ::= SEQUENCE { 3935 type AttributeType, 3936 values SET OF AttributeValue 3937 -- at least one value is required -- } 3939 AttributeType ::= OBJECT IDENTIFIER 3941 AttributeValue ::= ANY 3943 AttributeTypeAndValue ::= SEQUENCE { 3944 type AttributeType, 3945 value AttributeValue } 3947 -- suggested naming attributes: Definition of the following 3948 -- information object set may be augmented to meet local 3949 -- requirements. Note that deleting members of the set may 3950 -- prevent interoperability with conforming implementations. 3951 -- presented in pairs: the AttributeType followed by the 3952 -- type definition for the corresponding AttributeValue 3953 --Arc for standard naming attributes 3954 id-at OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 4} 3956 -- Attributes of type NameDirectoryString 3957 id-at-name AttributeType ::= {id-at 41} 3958 id-at-surname AttributeType ::= {id-at 4} 3959 id-at-givenName AttributeType ::= {id-at 42} 3960 id-at-initials AttributeType ::= {id-at 43} 3961 id-at-generationQualifier AttributeType ::= {id-at 44} 3963 X520name ::= CHOICE { 3964 teletexString TeletexString (SIZE (1..ub-name)), 3965 printableString PrintableString (SIZE (1..ub-name)), 3966 universalString UniversalString (SIZE (1..ub-name)), 3967 utf8String UTF8String (SIZE (1..ub-name)), 3968 bmpString BMPString (SIZE(1..ub-name)) } 3970 -- 3972 id-at-commonName AttributeType ::= {id-at 3} 3974 X520CommonName ::= CHOICE { 3975 teletexString TeletexString (SIZE (1..ub-common-name)), 3976 printableString PrintableString (SIZE (1..ub-common-name)), 3977 universalString UniversalString (SIZE (1..ub-common-name)), 3978 utf8String UTF8String (SIZE (1..ub-common-name)), 3979 bmpString BMPString (SIZE(1..ub-common-name)) } 3981 -- 3983 id-at-localityName AttributeType ::= {id-at 7} 3985 X520LocalityName ::= CHOICE { 3986 teletexString TeletexString (SIZE (1..ub-locality-name)), 3987 printableString PrintableString (SIZE (1..ub-locality-name)), 3988 universalString UniversalString (SIZE (1..ub-locality-name)), 3989 utf8String UTF8String (SIZE (1..ub-locality-name)), 3990 bmpString BMPString (SIZE(1..ub-locality-name)) } 3992 -- 3994 id-at-stateOrProvinceName AttributeType ::= {id-at 8} 3996 X520StateOrProvinceName ::= CHOICE { 3997 teletexString TeletexString (SIZE (1..ub-state-name)), 3998 printableString PrintableString (SIZE (1..ub-state-name)), 3999 universalString UniversalString (SIZE (1..ub-state-name)), 4000 utf8String UTF8String (SIZE (1..ub-state-name)), 4001 bmpString BMPString (SIZE(1..ub-state-name)) } 4003 -- 4005 id-at-organizationName AttributeType ::= {id-at 10} 4007 X520OrganizationName ::= CHOICE { 4008 teletexString TeletexString (SIZE (1..ub-organization-name)), 4009 printableString PrintableString (SIZE (1..ub-organization-name)), 4010 universalString UniversalString (SIZE (1..ub-organization-name)), 4011 utf8String UTF8String (SIZE (1..ub-organization-name)), 4012 bmpString BMPString (SIZE(1..ub-organization-name)) } 4014 -- 4016 id-at-organizationalUnitName AttributeType ::= {id-at 11} 4018 X520OrganizationalUnitName ::= CHOICE { 4019 teletexString TeletexString (SIZE (1..ub-organizational-unit-name)), 4020 printableString PrintableString 4021 (SIZE (1..ub-organizational-unit-name)), 4022 universalString UniversalString 4023 (SIZE (1..ub-organizational-unit-name)), 4024 utf8String UTF8String (SIZE (1..ub-organizational-unit-name)), 4025 bmpString BMPString (SIZE(1..ub-organizational-unit-name)) } 4027 -- 4029 id-at-title AttributeType ::= {id-at 12} 4031 X520Title ::= CHOICE { 4032 teletexString TeletexString (SIZE (1..ub-title)), 4033 printableString PrintableString (SIZE (1..ub-title)), 4034 universalString UniversalString (SIZE (1..ub-title)), 4035 utf8String UTF8String (SIZE (1..ub-title)), 4036 bmpString BMPString (SIZE(1..ub-title)) } 4038 -- 4040 id-at-dnQualifier AttributeType ::= {id-at 46} 4041 X520dnQualifier ::= PrintableString 4043 id-at-countryName AttributeType ::= {id-at 6} 4044 X520countryName ::= PrintableString (SIZE (2)) -- IS 3166 codes 4046 id-at-serialNumber AttributeType ::= { id-at 5 } 4047 X520SerialNumber PrintableString (SIZE (1..ub-serial-number)) 4048 -- domaincomponent and identifier from RFC 2247 4050 id-domainComponent OBJECT IDENTIFIER ::= 4051 { 0 9 2342 19200300 100 1 25 } 4053 id-domainComponent AttributeType ::= id-domainComponent 4054 domainComponent ::= IA5String 4056 -- Legacy attributes 4058 pkcs-9 OBJECT IDENTIFIER ::= 4059 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 } 4061 emailAddress AttributeType ::= { pkcs-9 1 } 4063 Pkcs9email ::= IA5String (SIZE (1..ub-emailaddress-length)) 4065 -- naming data types -- 4067 Name ::= CHOICE { -- only one possibility for now -- 4068 rdnSequence RDNSequence } 4070 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 4072 DistinguishedName ::= RDNSequence 4074 RelativeDistinguishedName ::= 4075 SET SIZE (1 .. MAX) OF AttributeTypeAndValue 4077 -- Directory string type -- 4079 DirectoryString ::= CHOICE { 4080 teletexString TeletexString (SIZE (1..MAX)), 4081 printableString PrintableString (SIZE (1..MAX)), 4082 universalString UniversalString (SIZE (1..MAX)), 4083 utf8String UTF8String (SIZE (1..MAX)), 4084 bmpString BMPString (SIZE(1..MAX)) } 4086 -- certificate and CRL specific structures begin here 4088 Certificate ::= SEQUENCE { 4089 tbsCertificate TBSCertificate, 4090 signatureAlgorithm AlgorithmIdentifier, 4091 signature BIT STRING } 4093 TBSCertificate ::= SEQUENCE { 4094 version [0] Version DEFAULT v1, 4095 serialNumber CertificateSerialNumber, 4096 signature AlgorithmIdentifier, 4097 issuer Name, 4098 validity Validity, 4099 subject Name, 4100 subjectPublicKeyInfo SubjectPublicKeyInfo, 4101 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 4102 -- If present, version shall be v2 or v3 4103 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 4104 -- If present, version shall be v2 or v3 4105 extensions [3] Extensions OPTIONAL 4106 -- If present, version shall be v3 -- } 4108 Version ::= INTEGER { v1(0), v2(1), v3(2) } 4110 CertificateSerialNumber ::= INTEGER 4112 Validity ::= SEQUENCE { 4113 notBefore Time, 4114 notAfter Time } 4116 Time ::= CHOICE { 4117 utcTime UTCTime, 4118 generalTime GeneralizedTime } 4120 UniqueIdentifier ::= BIT STRING 4122 SubjectPublicKeyInfo ::= SEQUENCE { 4123 algorithm AlgorithmIdentifier, 4124 subjectPublicKey BIT STRING } 4126 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 4128 Extension ::= SEQUENCE { 4129 extnID OBJECT IDENTIFIER, 4130 critical BOOLEAN DEFAULT FALSE, 4131 extnValue OCTET STRING } 4133 -- CRL structures 4135 CertificateList ::= SEQUENCE { 4136 tbsCertList TBSCertList, 4137 signatureAlgorithm AlgorithmIdentifier, 4138 signature BIT STRING } 4140 TBSCertList ::= SEQUENCE { 4141 version Version OPTIONAL, 4142 -- if present, shall be v2 4143 signature AlgorithmIdentifier, 4144 issuer Name, 4145 thisUpdate Time, 4146 nextUpdate Time OPTIONAL, 4147 revokedCertificates SEQUENCE OF SEQUENCE { 4148 userCertificate CertificateSerialNumber, 4149 revocationDate Time, 4150 crlEntryExtensions Extensions OPTIONAL 4151 -- if present, shall be v2 4152 } OPTIONAL, 4153 crlExtensions [0] Extensions OPTIONAL 4154 -- if present, shall be v2 -- } 4156 -- Version, Time, CertificateSerialNumber, and Extensions were 4157 -- defined earlier for use in the certificate structure 4159 AlgorithmIdentifier ::= SEQUENCE { 4160 algorithm OBJECT IDENTIFIER, 4161 parameters ANY DEFINED BY algorithm OPTIONAL } 4162 -- contains a value of the type 4163 -- registered for use with the 4164 -- algorithm object identifier value 4166 -- x400 address syntax starts here 4167 -- OR Names 4169 ORAddress ::= SEQUENCE { 4170 built-in-standard-attributes BuiltInStandardAttributes, 4171 built-in-domain-defined-attributes 4172 BuiltInDomainDefinedAttributes OPTIONAL, 4173 -- see also teletex-domain-defined-attributes 4174 extension-attributes ExtensionAttributes OPTIONAL } 4175 -- The OR-address is semantically absent from the OR-name if the 4176 -- built-in-standard-attribute sequence is empty and the 4177 -- built-in-domain-defined-attributes and extension-attributes are 4178 -- both omitted. 4180 -- Built-in Standard Attributes 4182 BuiltInStandardAttributes ::= SEQUENCE { 4183 country-name CountryName OPTIONAL, 4184 administration-domain-name AdministrationDomainName OPTIONAL, 4185 network-address [0] NetworkAddress OPTIONAL, 4186 -- see also extended-network-address 4187 terminal-identifier [1] TerminalIdentifier OPTIONAL, 4188 private-domain-name [2] PrivateDomainName OPTIONAL, 4189 organization-name [3] OrganizationName OPTIONAL, 4190 -- see also teletex-organization-name 4191 numeric-user-identifier [4] NumericUserIdentifier OPTIONAL, 4192 personal-name [5] PersonalName OPTIONAL, 4193 -- see also teletex-personal-name 4194 organizational-unit-names [6] OrganizationalUnitNames OPTIONAL 4195 -- see also teletex-organizational-unit-names -- } 4197 CountryName ::= [APPLICATION 1] CHOICE { 4198 x121-dcc-code NumericString 4199 (SIZE (ub-country-name-numeric-length)), 4200 iso-3166-alpha2-code PrintableString 4201 (SIZE (ub-country-name-alpha-length)) } 4203 AdministrationDomainName ::= [APPLICATION 2] CHOICE { 4204 numeric NumericString (SIZE (0..ub-domain-name-length)), 4205 printable PrintableString (SIZE (0..ub-domain-name-length)) } 4207 NetworkAddress ::= X121Address -- see also extended-network-address 4209 X121Address ::= NumericString (SIZE (1..ub-x121-address-length)) 4211 TerminalIdentifier ::= PrintableString (SIZE (1..ub-terminal-id-length)) 4213 PrivateDomainName ::= CHOICE { 4214 numeric NumericString (SIZE (1..ub-domain-name-length)), 4215 printable PrintableString (SIZE (1..ub-domain-name-length)) } 4217 OrganizationName ::= PrintableString 4218 (SIZE (1..ub-organization-name-length)) 4219 -- see also teletex-organization-name 4221 NumericUserIdentifier ::= NumericString 4222 (SIZE (1..ub-numeric-user-id-length)) 4224 PersonalName ::= SET { 4225 surname [0] PrintableString (SIZE (1..ub-surname-length)), 4226 given-name [1] PrintableString 4227 (SIZE (1..ub-given-name-length)) OPTIONAL, 4228 initials [2] PrintableString (SIZE (1..ub-initials-length)) OPTIONAL, 4229 generation-qualifier [3] PrintableString 4230 (SIZE (1..ub-generation-qualifier-length)) OPTIONAL } 4231 -- see also teletex-personal-name 4233 OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units) 4234 OF OrganizationalUnitName 4235 -- see also teletex-organizational-unit-names 4237 OrganizationalUnitName ::= PrintableString (SIZE 4238 (1..ub-organizational-unit-name-length)) 4240 -- Built-in Domain-defined Attributes 4242 BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE 4243 (1..ub-domain-defined-attributes) OF 4244 BuiltInDomainDefinedAttribute 4246 BuiltInDomainDefinedAttribute ::= SEQUENCE { 4247 type PrintableString (SIZE 4248 (1..ub-domain-defined-attribute-type-length)), 4249 value PrintableString (SIZE 4250 (1..ub-domain-defined-attribute-value-length))} 4252 -- Extension Attributes 4254 ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF 4255 ExtensionAttribute 4257 ExtensionAttribute ::= SEQUENCE { 4258 extension-attribute-type [0] INTEGER (0..ub-extension-attributes), 4259 extension-attribute-value [1] 4260 ANY DEFINED BY extension-attribute-type } 4262 -- Extension types and attribute values 4263 -- 4265 common-name INTEGER ::= 1 4267 CommonName ::= PrintableString (SIZE (1..ub-common-name-length)) 4269 teletex-common-name INTEGER ::= 2 4271 TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length)) 4273 teletex-organization-name INTEGER ::= 3 4275 TeletexOrganizationName ::= 4276 TeletexString (SIZE (1..ub-organization-name-length)) 4278 teletex-personal-name INTEGER ::= 4 4280 TeletexPersonalName ::= SET { 4281 surname [0] TeletexString (SIZE (1..ub-surname-length)), 4282 given-name [1] TeletexString 4283 (SIZE (1..ub-given-name-length)) OPTIONAL, 4284 initials [2] TeletexString (SIZE (1..ub-initials-length)) OPTIONAL, 4285 generation-qualifier [3] TeletexString (SIZE 4286 (1..ub-generation-qualifier-length)) OPTIONAL } 4288 teletex-organizational-unit-names INTEGER ::= 5 4290 TeletexOrganizationalUnitNames ::= SEQUENCE SIZE 4291 (1..ub-organizational-units) OF TeletexOrganizationalUnitName 4293 TeletexOrganizationalUnitName ::= TeletexString 4294 (SIZE (1..ub-organizational-unit-name-length)) 4296 pds-name INTEGER ::= 7 4298 PDSName ::= PrintableString (SIZE (1..ub-pds-name-length)) 4300 physical-delivery-country-name INTEGER ::= 8 4302 PhysicalDeliveryCountryName ::= CHOICE { 4303 x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)), 4304 iso-3166-alpha2-code PrintableString 4305 (SIZE (ub-country-name-alpha-length)) } 4307 postal-code INTEGER ::= 9 4309 PostalCode ::= CHOICE { 4310 numeric-code NumericString (SIZE (1..ub-postal-code-length)), 4311 printable-code PrintableString (SIZE (1..ub-postal-code-length)) } 4313 physical-delivery-office-name INTEGER ::= 10 4315 PhysicalDeliveryOfficeName ::= PDSParameter 4317 physical-delivery-office-number INTEGER ::= 11 4319 PhysicalDeliveryOfficeNumber ::= PDSParameter 4321 extension-OR-address-components INTEGER ::= 12 4323 ExtensionORAddressComponents ::= PDSParameter 4325 physical-delivery-personal-name INTEGER ::= 13 4327 PhysicalDeliveryPersonalName ::= PDSParameter 4329 physical-delivery-organization-name INTEGER ::= 14 4331 PhysicalDeliveryOrganizationName ::= PDSParameter 4333 extension-physical-delivery-address-components INTEGER ::= 15 4335 ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter 4336 unformatted-postal-address INTEGER ::= 16 4338 UnformattedPostalAddress ::= SET { 4339 printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) OF 4340 PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL, 4341 teletex-string TeletexString 4342 (SIZE (1..ub-unformatted-address-length)) OPTIONAL } 4344 street-address INTEGER ::= 17 4346 StreetAddress ::= PDSParameter 4348 post-office-box-address INTEGER ::= 18 4350 PostOfficeBoxAddress ::= PDSParameter 4352 poste-restante-address INTEGER ::= 19 4354 PosteRestanteAddress ::= PDSParameter 4356 unique-postal-name INTEGER ::= 20 4358 UniquePostalName ::= PDSParameter 4360 local-postal-attributes INTEGER ::= 21 4362 LocalPostalAttributes ::= PDSParameter 4364 PDSParameter ::= SET { 4365 printable-string PrintableString 4366 (SIZE(1..ub-pds-parameter-length)) OPTIONAL, 4367 teletex-string TeletexString 4368 (SIZE(1..ub-pds-parameter-length)) OPTIONAL } 4370 extended-network-address INTEGER ::= 22 4372 ExtendedNetworkAddress ::= CHOICE { 4373 e163-4-address SEQUENCE { 4374 number [0] NumericString (SIZE (1..ub-e163-4-number-length)), 4375 sub-address [1] NumericString 4376 (SIZE (1..ub-e163-4-sub-address-length)) OPTIONAL }, 4377 psap-address [0] PresentationAddress } 4379 PresentationAddress ::= SEQUENCE { 4380 pSelector [0] EXPLICIT OCTET STRING OPTIONAL, 4381 sSelector [1] EXPLICIT OCTET STRING OPTIONAL, 4382 tSelector [2] EXPLICIT OCTET STRING OPTIONAL, 4383 nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING } 4385 terminal-type INTEGER ::= 23 4387 TerminalType ::= INTEGER { 4388 telex (3), 4389 teletex (4), 4390 g3-facsimile (5), 4391 g4-facsimile (6), 4392 ia5-terminal (7), 4393 videotex (8) } (0..ub-integer-options) 4395 -- Extension Domain-defined Attributes 4397 teletex-domain-defined-attributes INTEGER ::= 6 4399 TeletexDomainDefinedAttributes ::= SEQUENCE SIZE 4400 (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute 4402 TeletexDomainDefinedAttribute ::= SEQUENCE { 4403 type TeletexString 4404 (SIZE (1..ub-domain-defined-attribute-type-length)), 4405 value TeletexString 4406 (SIZE (1..ub-domain-defined-attribute-value-length)) } 4408 -- specifications of Upper Bounds shall be regarded as mandatory 4409 -- from Annex B of ITU-T X.411 Reference Definition of MTS Parameter 4410 -- Upper Bounds 4412 -- Upper Bounds 4413 ub-name INTEGER ::= 32768 4414 ub-common-name INTEGER ::= 64 4415 ub-locality-name INTEGER ::= 128 4416 ub-state-name INTEGER ::= 128 4417 ub-organization-name INTEGER ::= 64 4418 ub-organizational-unit-name INTEGER ::= 64 4419 ub-title INTEGER ::= 64 4420 ub-serialNumber INTEGER ::= 64 4421 ub-match INTEGER ::= 128 4423 ub-emailaddress-length INTEGER ::= 128 4425 ub-common-name-length INTEGER ::= 64 4426 ub-country-name-alpha-length INTEGER ::= 2 4427 ub-country-name-numeric-length INTEGER ::= 3 4428 ub-domain-defined-attributes INTEGER ::= 4 4429 ub-domain-defined-attribute-type-length INTEGER ::= 8 4430 ub-domain-defined-attribute-value-length INTEGER ::= 128 4431 ub-domain-name-length INTEGER ::= 16 4432 ub-extension-attributes INTEGER ::= 256 4433 ub-e163-4-number-length INTEGER ::= 15 4434 ub-e163-4-sub-address-length INTEGER ::= 40 4435 ub-generation-qualifier-length INTEGER ::= 3 4436 ub-given-name-length INTEGER ::= 16 4437 ub-initials-length INTEGER ::= 5 4438 ub-integer-options INTEGER ::= 256 4439 ub-numeric-user-id-length INTEGER ::= 32 4440 ub-organization-name-length INTEGER ::= 64 4441 ub-organizational-unit-name-length INTEGER ::= 32 4442 ub-organizational-units INTEGER ::= 4 4443 ub-pds-name-length INTEGER ::= 16 4444 ub-pds-parameter-length INTEGER ::= 30 4445 ub-pds-physical-address-lines INTEGER ::= 6 4446 ub-postal-code-length INTEGER ::= 16 4447 ub-surname-length INTEGER ::= 40 4448 ub-terminal-id-length INTEGER ::= 24 4449 ub-unformatted-address-length INTEGER ::= 180 4450 ub-x121-address-length INTEGER ::= 16 4452 -- Note - upper bounds on string types, such as TeletexString, are 4453 -- measured in characters. Excepting PrintableString or IA5String, a 4454 -- significantly greater number of octets will be required to hold 4455 -- such a value. As a minimum, 16 octets, or twice the specified upper 4456 -- bound, whichever is the larger, should be allowed for TeletexString. 4457 -- For UTF8String or UniversalString at least four times the upper 4458 -- bound should be allowed. 4460 END 4461 A.2 Implicitly Tagged Module, 1988 Syntax 4463 PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) 4464 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)} 4466 DEFINITIONS IMPLICIT TAGS ::= 4468 BEGIN 4470 -- EXPORTS ALL -- 4472 IMPORTS 4473 id-pkix, id-pe, id-qt, id-kp, id-qt-unotice, id-qt-cps, 4474 id-ad, id-ad-ocsp, id-ad-caIssuers, 4475 -- delete following line if "new" types are supported -- 4476 BMPString, UniversalString, UTF8String, -- end "new" types 4477 ORAddress, Name, RelativeDistinguishedName, 4478 CertificateSerialNumber, 4479 CertificateList, AlgorithmIdentifier, ub-name, 4480 Attribute, DirectoryString 4481 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 4482 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 4483 id-mod(0) id-pkix1-explicit(1)}; 4485 -- ISO arc for standard certificate and CRL extensions 4487 id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 4489 -- authority key identifier OID and syntax 4491 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 4493 AuthorityKeyIdentifier ::= SEQUENCE { 4494 keyIdentifier [0] KeyIdentifier OPTIONAL, 4495 authorityCertIssuer [1] GeneralNames OPTIONAL, 4496 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 4497 -- authorityCertIssuer and authorityCertSerialNumber shall both 4498 -- be present or both be absent 4500 KeyIdentifier ::= OCTET STRING 4502 -- subject key identifier OID and syntax 4504 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 4506 SubjectKeyIdentifier ::= KeyIdentifier 4507 -- key usage extension OID and syntax 4509 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 4511 KeyUsage ::= BIT STRING { 4512 digitalSignature (0), 4513 nonRepudiation (1), 4514 keyEncipherment (2), 4515 dataEncipherment (3), 4516 keyAgreement (4), 4517 keyCertSign (5), 4518 cRLSign (6), 4519 encipherOnly (7), 4520 decipherOnly (8) } 4522 -- private key usage period extension OID and syntax 4524 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 4526 PrivateKeyUsagePeriod ::= SEQUENCE { 4527 notBefore [0] GeneralizedTime OPTIONAL, 4528 notAfter [1] GeneralizedTime OPTIONAL } 4529 -- either notBefore or notAfter shall be present 4531 -- certificate policies extension OID and syntax 4533 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 4535 anyPolicy OBJECT IDENTIFIER ::= {id-ce-certificate-policies 0} 4537 CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 4539 PolicyInformation ::= SEQUENCE { 4540 policyIdentifier CertPolicyId, 4541 policyQualifiers SEQUENCE SIZE (1..MAX) OF 4542 PolicyQualifierInfo OPTIONAL } 4544 CertPolicyId ::= OBJECT IDENTIFIER 4546 PolicyQualifierInfo ::= SEQUENCE { 4547 policyQualifierId PolicyQualifierId, 4548 qualifier ANY DEFINED BY policyQualifierId } 4550 -- Implementations that recognize additional policy qualifiers shall 4551 -- augment the following definition for PolicyQualifierId 4553 PolicyQualifierId ::= 4554 OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) 4556 -- CPS pointer qualifier 4558 CPSuri ::= IA5String 4560 -- user notice qualifier 4562 UserNotice ::= SEQUENCE { 4563 noticeRef NoticeReference OPTIONAL, 4564 explicitText DisplayText OPTIONAL} 4566 NoticeReference ::= SEQUENCE { 4567 organization DisplayText, 4568 noticeNumbers SEQUENCE OF INTEGER } 4570 DisplayText ::= CHOICE { 4571 ia5String IA5String (SIZE (1..200)), 4572 visibleString VisibleString (SIZE (1..200)), 4573 bmpString BMPString (SIZE (1..200)), 4574 utf8String UTF8String (SIZE (1..200)) } 4576 -- policy mapping extension OID and syntax 4578 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 4580 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 4581 issuerDomainPolicy CertPolicyId, 4582 subjectDomainPolicy CertPolicyId } 4584 -- subject alternative name extension OID and syntax 4586 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 4588 SubjectAltName ::= GeneralNames 4590 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 4592 GeneralName ::= CHOICE { 4593 otherName [0] AnotherName, 4594 rfc822Name [1] IA5String, 4595 dNSName [2] IA5String, 4596 x400Address [3] ORAddress, 4597 directoryName [4] Name, 4598 ediPartyName [5] EDIPartyName, 4599 uniformResourceIdentifier [6] IA5String, 4600 iPAddress [7] OCTET STRING, 4601 registeredID [8] OBJECT IDENTIFIER } 4603 -- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as 4604 -- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax 4606 AnotherName ::= SEQUENCE { 4607 type-id OBJECT IDENTIFIER, 4608 value [0] EXPLICIT ANY DEFINED BY type-id } 4610 EDIPartyName ::= SEQUENCE { 4611 nameAssigner [0] DirectoryString OPTIONAL, 4612 partyName [1] DirectoryString } 4614 -- issuer alternative name extension OID and syntax 4616 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 4618 IssuerAltName ::= GeneralNames 4620 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 4622 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 4624 -- basic constraints extension OID and syntax 4626 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 4628 BasicConstraints ::= SEQUENCE { 4629 cA BOOLEAN DEFAULT FALSE, 4630 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 4632 -- name constraints extension OID and syntax 4634 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 4636 NameConstraints ::= SEQUENCE { 4637 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 4638 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 4640 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 4642 GeneralSubtree ::= SEQUENCE { 4643 base GeneralName, 4644 minimum [0] BaseDistance DEFAULT 0, 4645 maximum [1] BaseDistance OPTIONAL } 4647 BaseDistance ::= INTEGER (0..MAX) 4649 -- policy constraints extension OID and syntax 4651 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } 4652 PolicyConstraints ::= SEQUENCE { 4653 requireExplicitPolicy [0] SkipCerts OPTIONAL, 4654 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 4656 SkipCerts ::= INTEGER (0..MAX) 4658 -- CRL distribution points extension OID and syntax 4660 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31} 4662 CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 4664 DistributionPoint ::= SEQUENCE { 4665 distributionPoint [0] DistributionPointName OPTIONAL, 4666 reasons [1] ReasonFlags OPTIONAL, 4667 cRLIssuer [2] GeneralNames OPTIONAL } 4669 DistributionPointName ::= CHOICE { 4670 fullName [0] GeneralNames, 4671 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 4673 ReasonFlags ::= BIT STRING { 4674 unused (0), 4675 keyCompromise (1), 4676 cACompromise (2), 4677 affiliationChanged (3), 4678 superseded (4), 4679 cessationOfOperation (5), 4680 certificateHold (6) } 4682 -- extended key usage extension OID and syntax 4684 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 4686 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 4688 KeyPurposeId ::= OBJECT IDENTIFIER 4690 -- extended key purpose OIDs 4691 id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } 4692 id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } 4693 id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } 4694 id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } 4695 id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 } 4696 id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 } 4697 id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 } 4698 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 4699 -- inhibit any policy OID and syntax 4701 id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 } 4703 InhibitAnyPolicy ::= SkipCerts 4705 -- freshest (delta-)CRL extension OID and syntax 4707 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } 4709 FreshestCRL ::= CRLDistributionPoints 4711 -- authority info access 4713 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 4715 AuthorityInfoAccessSyntax ::= 4716 SEQUENCE SIZE (1..MAX) OF AccessDescription 4718 AccessDescription ::= SEQUENCE { 4719 accessMethod OBJECT IDENTIFIER, 4720 accessLocation GeneralName } 4722 -- CRL number extension OID and syntax 4724 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 4726 CRLNumber ::= INTEGER (0..MAX) 4728 -- issuing distribution point extension OID and syntax 4730 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 4732 IssuingDistributionPoint ::= SEQUENCE { 4733 distributionPoint [0] DistributionPointName OPTIONAL, 4734 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 4735 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 4736 onlySomeReasons [3] ReasonFlags OPTIONAL, 4737 indirectCRL [4] BOOLEAN DEFAULT FALSE } 4739 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 4741 -- deltaCRLIndicator ::= BaseCRLNumber 4743 BaseCRLNumber ::= CRLNumber 4745 -- CRL reasons extension OID and syntax 4746 id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 } 4748 CRLReason ::= ENUMERATED { 4749 unspecified (0), 4750 keyCompromise (1), 4751 cACompromise (2), 4752 affiliationChanged (3), 4753 superseded (4), 4754 cessationOfOperation (5), 4755 certificateHold (6), 4756 removeFromCRL (8) } 4758 -- certificate issuer CRL entry extension OID and syntax 4760 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } 4762 CertificateIssuer ::= GeneralNames 4764 -- hold instruction extension OID and syntax 4766 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 4768 HoldInstructionCode ::= OBJECT IDENTIFIER 4770 -- ANSI x9 holdinstructions 4772 -- ANSI x9 arc holdinstruction arc 4773 holdInstruction OBJECT IDENTIFIER ::= 4774 {joint-iso-itu-t(2) member-body(2) us(840) x9cm(10040) 2} 4776 -- ANSI X9 holdinstructions referenced by this standard 4777 id-holdinstruction-none OBJECT IDENTIFIER ::= 4778 {holdInstruction 1} -- deprecated 4779 id-holdinstruction-callissuer OBJECT IDENTIFIER ::= 4780 {holdInstruction 2} 4781 id-holdinstruction-reject OBJECT IDENTIFIER ::= 4782 {holdInstruction 3} 4784 -- invalidity date CRL entry extension OID and syntax 4786 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 4788 InvalidityDate ::= GeneralizedTime 4790 END 4791 Appendix B. ASN.1 Notes 4793 CAs MUST force the serialNumber to be a non-negative integer, that 4794 is, the sign bit in the DER encoding of the INTEGER value MUST be 4795 zero - this can be done by adding a leading (leftmost) `00'H octet if 4796 necessary. This removes a potential ambiguity in mapping between a 4797 string of octets and an integer value. 4799 As noted in section 4.1.2.2, serial numbers can be expected to 4800 contain long integers. Certificate users MUST be able to handle 4801 serialNumber values up to 20 octets in length. Conformant CAs MUST 4802 NOT use serialNumber values longer than 20 octets. 4804 The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 4805 constructs. A valid ASN.1 sequence will have zero or more entries. 4806 The SIZE (1..MAX) construct constrains the sequence to have at least 4807 one entry. MAX indicates the upper bound is unspecified. 4808 Implementations are free to choose an upper bound that suits their 4809 environment. 4811 The construct "positiveInt ::= INTEGER (0..MAX)" defines positiveInt 4812 as a subtype of INTEGER containing integers greater than or equal to 4813 zero. The upper bound is unspecified. Implementations are free to 4814 select an upper bound that suits their environment. 4816 The character string type PrintableString supports a very basic Latin 4817 character set: the lower case letters 'a' through 'z', upper case 4818 letters 'A' through 'Z', the digits '0' through '9', eleven special 4819 characters ' " ( ) + , - . / : ? and space. 4821 The character string type TeletexString is a superset of 4822 PrintableString. TeletexString supports a fairly standard (ascii- 4823 like) Latin character set, Latin characters with non-spacing accents 4824 and Japanese characters. 4826 The character string type UniversalString supports any of the 4827 characters allowed by ISO 10646-1. ISO 10646 is the Universal 4828 multiple-octet coded Character Set (UCS). ISO 10646-1 specifes the 4829 architecture and the "basic multilingual plane" - a large standard 4830 character set which includes all major world character standards. 4832 The character string type UTF8String will be introduced in the 1998 4833 version of ASN.1. UTF8String is a universal type and has been 4834 assigned tag number 12. The content of UTF8String was defined by RFC 4835 2044 and updated in RFC 2279, "UTF-8, a transformation Format of ISO 4836 10646." ISO is expected to formally add UTF8String to the list of 4837 choices for DirectoryString in 1998 as well. 4839 In anticipation of these changes, and in conformance with IETF Best 4840 Practices codified in RFC 2277, IETF Policy on Character Sets and 4841 Languages, this document includes UTF8String as a choice in 4842 DirectoryString and the CPS qualifier extensions. 4844 Implementers should note that the DER encoding of the SET OF values 4845 requires ordering of the encodings of the values. In particular, this 4846 issue arises with respect to distinguished names. 4848 Object Identifiers (OIDs) are used throught this specification to 4849 identify certificate policies, public key and signature algorithms, 4850 certificate extensions, etc. There is no maximum size for OIDs. 4851 This specification mandates support for OIDs which have arc elements 4852 with values that are less than 2^28, i.e. they MUST be between 0 and 4853 268,435,455 inclusive. This allows each arc element to be represented 4854 within a single 32 bit word. Implementations MUST also support OIDs 4855 where the length of the dotted decimal (see [LDAP], section 4.1.2) 4856 string representation can be up to 100 bytes (inclusive). 4857 Implementations MUST be able to handle OIDs with up to 20 elements 4858 (inclusive). CAs SHOULD NOT issue certificates which contain OIDs 4859 that breach these requirements. 4861 Appendix C. Examples 4863 This section contains four examples: three certificates and a CRL. 4864 The first two certificates and the CRL comprise a minimal 4865 certification path. 4867 Section C.1 contains an annotated hex dump of a "self-signed" 4868 certificate issued by a CA whose distinguished name is 4869 cn=us,o=gov,ou=nist. The certificate contains a DSA public key with 4870 parameters, and is signed by the corresponding DSA private key. 4872 Section C.2 contains an annotated hex dump of an end-entity 4873 certificate. The end entity certificate contains a DSA public key, 4874 and is signed by the private key corresponding to the "self-signed" 4875 certificate in section C.1. 4877 Section C.3 contains a dump of an end entity certificate which 4878 contains an RSA public key and is signed with RSA and MD5. This 4879 certificate is not part of the minimal certification path. 4881 Section C.4 contains an annotated hex dump of a CRL. The CRL is 4882 issued by the CA whose distinguished name is cn=us,o=gov,ou=nist and 4883 the list of revoked certificates includes the end entity certificate 4884 presented in C.2. 4886 The certificates were processed using Peter Gutman's dumpasn1 utility 4887 to generate the output. The source for the dumpasn1 utility is 4888 available at . The 4889 binaries for the certificates and CRLs are available at 4890 . 4892 C.1 Certificate 4894 This section contains an annotated hex dump of a 699 byte version 3 4895 certificate. The certificate contains the following information: 4896 (a) the serial number is 23 (17 hex); 4897 (b) the certificate is signed with DSA and the SHA-1 hash algorithm; 4898 (c) the issuer's distinguished name is OU=NIST; O=gov; C=US 4899 (d) and the subject's distinguished name is OU=NIST; O=gov; C=US 4900 (e) the certificate was issued on June 30, 1997 and will expire on 4901 December 31, 1997; 4902 (f) the certificate contains a 1024 bit DSA public key with 4903 parameters; 4904 (g) the certificate contains a subject key identifier extension; and 4905 (h) the certificate is a CA certificate (as indicated through the 4906 basic constraints extension.) 4908 0 30 701: SEQUENCE { 4909 4 30 637: SEQUENCE { 4910 8 A0 3: [0] { 4911 10 02 1: INTEGER 2 4912 : } 4913 13 02 1: INTEGER 23 4914 16 30 9: SEQUENCE { 4915 18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 4916 : } 4917 27 30 42: SEQUENCE { 4918 29 31 11: SET { 4919 31 30 9: SEQUENCE { 4920 33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 4921 38 13 2: PrintableString 'US' 4922 : } 4923 : } 4924 42 31 12: SET { 4925 44 30 10: SEQUENCE { 4926 46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 4927 51 13 3: PrintableString 'gov' 4928 : } 4929 : } 4930 56 31 13: SET { 4931 58 30 11: SEQUENCE { 4932 60 06 3: OBJECT IDENTIFIER 4933 organizationalUnitName (2 5 4 11) 4935 65 13 4: PrintableString 'NIST' 4936 : } 4937 : } 4938 : } 4939 71 30 30: SEQUENCE { 4940 73 17 13: UTCTime '970630000000Z' 4941 88 17 13: UTCTime '971231000000Z' 4942 : } 4943 103 30 42: SEQUENCE { 4944 105 31 11: SET { 4945 107 30 9: SEQUENCE { 4946 109 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 4947 114 13 2: PrintableString 'US' 4948 : } 4949 : } 4950 118 31 12: SET { 4951 120 30 10: SEQUENCE { 4952 122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 4953 127 13 3: PrintableString 'gov' 4954 : } 4955 : } 4956 132 31 13: SET { 4957 134 30 11: SEQUENCE { 4958 136 06 3: OBJECT IDENTIFIER 4959 organizationalUnitName (2 5 4 11) 4960 141 13 4: PrintableString 'NIST' 4961 : } 4962 : } 4963 : } 4964 147 30 440: SEQUENCE { 4965 151 30 300: SEQUENCE { 4966 155 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) 4967 164 30 287: SEQUENCE { 4968 168 02 129: INTEGER 4969 : 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC FB 95 4970 : 32 AC 01 12 33 B9 E0 1C AD 90 9B BC 48 54 9E F3 4971 : 94 77 3C 2C 71 35 55 E6 FE 4F 22 CB D5 D8 3E 89 4972 : 93 33 4D FC BD 4F 41 64 3E A2 98 70 EC 31 B4 50 4973 : DE EB F1 98 28 0A C9 3E 44 B3 FD 22 97 96 83 D0 4974 : 18 A3 E3 BD 35 5B FF EE A3 21 72 6A 7B 96 DA B9 4975 : 3F 1E 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A 4976 : FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48 63 FE 4977 : 43 4978 300 02 21: INTEGER 4979 : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA 55 F7 4980 : 7D 57 74 81 E5 4981 323 02 129: INTEGER 4982 : 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91 C0 8E 4983 : 47 F1 0A C3 01 47 C2 44 42 36 A9 92 81 DE 57 C5 4984 : E0 68 86 58 00 7B 1F F9 9B 77 A1 C5 10 A5 80 91 4985 : 78 51 51 3C F6 FC FC CC 46 C6 81 78 92 84 3D F4 4986 : 93 3D 0C 38 7E 1A 5B 99 4E AB 14 64 F6 0C 21 22 4987 : 4E 28 08 9C 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 4988 : 39 A2 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF 4989 : F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE 1E 57 4990 : 18 4991 : } 4992 : } 4993 455 03 133: BIT STRING 0 unused bits 4994 : 02 81 81 00 B5 9E 1F 49 04 47 D1 DB F5 3A DD CA 4995 : 04 75 E8 DD 75 F6 9B 8A B1 97 D6 59 69 82 D3 03 4996 : 4D FD 3B 36 5F 4A F2 D1 4E C1 07 F5 D1 2A D3 78 4997 : 77 63 56 EA 96 61 4D 42 0B 7A 1D FB AB 91 A4 CE 4998 : DE EF 77 C8 E5 EF 20 AE A6 28 48 AF BE 69 C3 6A 4999 : A5 30 F2 C2 B9 D9 82 2B 7D D9 C4 84 1F DE 0D E8 5000 : 54 D7 1B 99 2E B3 D0 88 F6 D6 63 9B A7 E2 0E 82 5001 : D4 3B 8A 68 1B 06 56 31 59 0B 49 EB 99 A5 D5 81 5002 : 41 7B C9 55 5003 : } 5004 591 A3 52: [3] { 5005 593 30 50: SEQUENCE { 5006 595 30 31: SEQUENCE { 5007 597 06 3: OBJECT IDENTIFIER 5008 subjectKeyIdentifier (2 5 29 14) 5009 602 04 24: OCTET STRING 5010 : 04 16 04 14 E7 26 C5 54 CD 5B A3 6F 35 68 95 AA 5011 : D5 FF 1C 21 E4 22 75 D6 5012 : } 5013 628 30 15: SEQUENCE { 5014 630 06 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19) 5015 635 01 1: BOOLEAN TRUE 5016 638 04 5: OCTET STRING 5017 : 30 03 01 01 FF 5018 : } 5019 : } 5020 : } 5021 : } 5022 645 30 9: SEQUENCE { 5023 647 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5024 : } 5025 656 03 47: BIT STRING 0 unused bits 5026 : 30 2C 02 14 6A F9 3F 72 30 7F 45 DC E5 50 C1 5E 5027 : 94 A0 6D C7 92 4C E5 E1 02 14 6F 61 B8 65 F7 AA 5028 : DF 46 1B F7 39 0D 0D 88 9E FE B6 83 F7 1A 5029 : } 5031 C.2 Certificate 5033 This section contains an annotated hex dump of a 730 byte version 3 5034 certificate. The certificate contains the following information: 5035 (a) the serial number is 18 (12 hex); 5036 (b) the certificate is signed with DSA and the SHA-1 hash algorithm; 5037 (c) the issuer's distinguished name is OU=nist; O=gov; C=US 5038 (d) and the subject's distinguished name is CN=Tim Polk; OU=nist; 5039 O=gov; C=US 5040 (e) the certificate was valid from July 30, 1997 through December 1, 5041 1997; 5042 (f) the certificate contains a 1024 bit DSA public key; 5043 (g) the certificate is an end entity certificate, as the basic 5044 constraints extension is not present; 5045 (h) the certificate contains an authority key identifier extension; 5046 and 5047 (i) the certificate includes one alternative name - an RFC 822 5048 address. 5050 0 30 734: SEQUENCE { 5051 4 30 669: SEQUENCE { 5052 8 A0 3: [0] { 5053 10 02 1: INTEGER 2 5054 : } 5055 13 02 1: INTEGER 18 5056 16 30 9: SEQUENCE { 5057 18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5058 : } 5059 27 30 42: SEQUENCE { 5060 29 31 11: SET { 5061 31 30 9: SEQUENCE { 5062 33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5063 38 13 2: PrintableString 'US' 5064 : } 5065 : } 5066 42 31 12: SET { 5067 44 30 10: SEQUENCE { 5068 46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5069 51 13 3: PrintableString 'gov' 5070 : } 5071 : } 5072 56 31 13: SET { 5073 58 30 11: SEQUENCE { 5074 60 06 3: OBJECT IDENTIFIER 5075 organizationalUnitName (2 5 4 11) 5076 65 13 4: PrintableString 'NIST' 5077 : } 5078 : } 5079 : } 5080 71 30 30: SEQUENCE { 5081 73 17 13: UTCTime '970730000000Z' 5082 88 17 13: UTCTime '971201000000Z' 5083 : } 5084 103 30 61: SEQUENCE { 5085 105 31 11: SET { 5086 107 30 9: SEQUENCE { 5087 109 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5088 114 13 2: PrintableString 'US' 5089 : } 5090 : } 5091 118 31 12: SET { 5092 120 30 10: SEQUENCE { 5093 122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5094 127 13 3: PrintableString 'gov' 5095 : } 5096 : } 5097 132 31 13: SET { 5098 134 30 11: SEQUENCE { 5099 136 06 3: OBJECT IDENTIFIER 5100 organizationalUnitName (2 5 4 11) 5101 141 13 4: PrintableString 'NIST' 5102 : } 5103 : } 5104 147 31 17: SET { 5105 149 30 15: SEQUENCE { 5106 151 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 5107 156 13 8: PrintableString 'Tim Polk' 5108 : } 5109 : } 5110 : } 5111 166 30 439: SEQUENCE { 5112 170 30 300: SEQUENCE { 5113 174 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) 5114 183 30 287: SEQUENCE { 5115 187 02 129: INTEGER 5116 : 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC FB 95 5117 : 32 AC 01 12 33 B9 E0 1C AD 90 9B BC 48 54 9E F3 5118 : 94 77 3C 2C 71 35 55 E6 FE 4F 22 CB D5 D8 3E 89 5119 : 93 33 4D FC BD 4F 41 64 3E A2 98 70 EC 31 B4 50 5120 : DE EB F1 98 28 0A C9 3E 44 B3 FD 22 97 96 83 D0 5121 : 18 A3 E3 BD 35 5B FF EE A3 21 72 6A 7B 96 DA B9 5122 : 3F 1E 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A 5123 : FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48 63 FE 5124 : 43 5125 319 02 21: INTEGER 5126 : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA 55 F7 5127 : 7D 57 74 81 E5 5128 342 02 129: INTEGER 5129 : 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91 C0 8E 5130 : 47 F1 0A C3 01 47 C2 44 42 36 A9 92 81 DE 57 C5 5131 : E0 68 86 58 00 7B 1F F9 9B 77 A1 C5 10 A5 80 91 5132 : 78 51 51 3C F6 FC FC CC 46 C6 81 78 92 84 3D F4 5133 : 93 3D 0C 38 7E 1A 5B 99 4E AB 14 64 F6 0C 21 22 5134 : 4E 28 08 9C 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 5135 : 39 A2 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF 5136 : F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE 1E 57 5137 : 18 5138 : } 5139 : } 5140 474 03 132: BIT STRING 0 unused bits 5141 : 02 81 80 30 B6 75 F7 7C 20 31 AE 38 BB 7E 0D 2B 5142 : AB A0 9C 4B DF 20 D5 24 13 3C CD 98 E5 5F 6C B7 5143 : C1 BA 4A BA A9 95 80 53 F0 0D 72 DC 33 37 F4 01 5144 : 0B F5 04 1F 9D 2E 1F 62 D8 84 3A 9B 25 09 5A 2D 5145 : C8 46 8E 2B D4 F5 0D 3B C7 2D C6 6C B9 98 C1 25 5146 : 3A 44 4E 8E CA 95 61 35 7C CE 15 31 5C 23 13 1E 5147 : A2 05 D1 7A 24 1C CB D3 72 09 90 FF 9B 9D 28 C0 5148 : A1 0A EC 46 9F 0D B8 D0 DC D0 18 A6 2B 5E F9 8F 5149 : B5 95 BE 5150 : } 5151 609 A3 66: [3] { 5152 611 30 64: SEQUENCE { 5153 613 30 25: SEQUENCE { 5154 615 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 5155 620 04 18: OCTET STRING 5156 : 30 10 81 0E 77 70 6F 6C 6B 40 6E 69 73 74 2E 67 5157 : 6F 76 5158 : } 5159 640 30 35: SEQUENCE { 5160 642 06 3: OBJECT IDENTIFIER 5161 authorityKeyIdentifier (2 5 29 35) 5162 647 04 28: OCTET STRING 5163 : 30 1A 80 18 04 16 04 14 E7 26 C5 54 CD 5B A3 6F 5164 : 35 68 95 AA D5 FF 1C 21 E4 22 75 D6 5165 : } 5166 : } 5167 : } 5168 : } 5169 677 30 9: SEQUENCE { 5170 679 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5171 : } 5172 688 03 48: BIT STRING 0 unused bits 5173 : 30 2D 02 14 37 FC 44 BF 7F 8D 18 1F 40 04 2F CF 5174 : EA CC 22 B2 16 01 FF 13 02 15 00 97 D0 24 96 0F 5175 : 64 8A C3 8D 41 B2 0E B9 26 D5 31 D1 A0 F1 BC 5176 : } 5178 C.3 End-Entity Certificate Using RSA 5180 This section contains an annotated hex dump of a 675 byte version 3 5181 certificate. The certificate contains the following information: 5182 (a) the serial number is 256; 5183 (b) the certificate is signed with RSA and the MD2 hash algorithm; 5184 (c) the issuer's distinguished name is OU=Dept. Arquitectura de 5185 Computadors; O=Universitat Politecnica de Catalunya; C=ES 5186 (d) and the subject's distinguished name is CN=Francisco Jordan; 5187 OU=Dept. Arquitectura de Computadors; O=Universitat Politecnica de 5188 Catalunya; C=ES 5189 (e) the certificate was issued on May 21, 1996 and expired on May 21, 5190 1997; 5191 (f) the certificate contains a 768 bit RSA public key; 5192 (g) the certificate is an end entity certificate (not a CA 5193 certificate); 5194 (h) the certificate includes an alternative subject name and an 5195 alternative issuer name - bothe are URLs; 5196 (i) the certificate include an authority key identifier and 5197 certificate policies extensions; and 5198 (j) the certificate includes a critical key usage extension 5199 specifying the public is intended for generation of digital 5200 signatures. 5202 0 30 654: SEQUENCE { 5203 4 30 503: SEQUENCE { 5204 8 A0 3: [0] { 5205 10 02 1: INTEGER 2 5206 : } 5207 13 02 2: INTEGER 256 5208 17 30 13: SEQUENCE { 5209 19 06 9: OBJECT IDENTIFIER 5210 : sha1withRSAEncryption (1 2 840 113549 1 1 5) 5211 30 05 0: NULL 5212 : } 5213 32 30 42: SEQUENCE { 5214 34 31 11: SET { 5215 36 30 9: SEQUENCE { 5216 38 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5217 43 13 2: PrintableString 'US' 5218 : } 5219 : } 5220 47 31 12: SET { 5221 49 30 10: SEQUENCE { 5222 51 06 3: OBJECT IDENTIFIER 5223 organizationalUnitName (2 5 4 11) 5224 56 13 3: PrintableString 'gov' 5225 : } 5226 : } 5227 61 31 13: SET { 5228 63 30 11: SEQUENCE { 5229 65 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5230 70 13 4: PrintableString 'NIST' 5231 : } 5232 : } 5233 : } 5234 76 30 30: SEQUENCE { 5235 78 17 13: UTCTime '960521095826Z' 5236 93 17 13: UTCTime '970521095826Z' 5237 : } 5238 108 30 61: SEQUENCE { 5239 110 31 11: SET { 5240 112 30 9: SEQUENCE { 5241 114 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5242 119 13 2: PrintableString 'US' 5243 : } 5244 : } 5245 123 31 12: SET { 5246 125 30 10: SEQUENCE { 5247 127 06 3: OBJECT IDENTIFIER 5248 organizationalUnitName (2 5 4 11) 5249 132 13 3: PrintableString 'gov' 5250 : } 5251 : } 5252 137 31 13: SET { 5253 139 30 11: SEQUENCE { 5254 141 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5255 146 13 4: PrintableString 'NIST' 5256 : } 5257 : } 5258 152 31 17: SET { 5259 154 30 15: SEQUENCE { 5260 156 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 5261 161 13 8: PrintableString 'Tim Polk' 5262 : } 5263 : } 5264 : } 5265 171 30 159: SEQUENCE { 5266 174 30 13: SEQUENCE { 5267 176 06 9: OBJECT IDENTIFIER 5268 rsaEncryption (1 2 840 113549 1 1 1) 5269 187 05 0: NULL 5270 : } 5272 189 03 141: BIT STRING 0 unused bits 5273 : 30 81 89 02 81 81 00 E1 CE 06 C9 D7 00 DF 65 27 5274 : 45 1E 63 6A 09 A0 A0 10 4B AF DF 9D 36 1D 44 1F 5275 : B7 07 5D 36 92 09 6A 1A 96 C7 4E D9 86 0D 0F 77 5276 : 94 F5 82 62 68 9A F2 D7 76 F5 9A 35 C7 B3 7F 4F 5277 : BE 64 CF A3 0C B3 84 32 80 F5 CA 77 29 C9 76 0B 5278 : 4C 38 19 EE 61 6F BA 68 E0 03 85 46 34 AB 84 64 5279 : 7F 43 69 02 C0 20 86 BD B1 D4 AD 21 A9 1A 8F CF 5280 : 96 83 86 92 57 5B 43 09 28 4C F2 5A 04 AD E5 DE 5281 : 9E 4F E8 38 3C F0 89 02 03 01 00 01 5282 : } 5283 333 A3 175: [3] { 5284 336 30 172: SEQUENCE { 5285 339 30 63: SEQUENCE { 5286 341 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 5287 346 04 56: OCTET STRING 5288 : 30 36 86 34 68 74 74 70 3A 2F 2F 77 77 77 2E 69 5289 : 74 6C 2E 6E 69 73 74 2E 67 6F 76 2F 64 69 76 38 5290 : 39 33 2F 73 74 61 66 66 2F 70 6F 6C 6B 2F 69 6E 5291 : 64 65 78 2E 68 74 6D 6C 5292 : } 5293 404 30 31: SEQUENCE { 5294 406 06 3: OBJECT IDENTIFIER issuerAltName (2 5 29 18) 5295 411 04 24: OCTET STRING 5296 : 30 16 86 14 68 74 74 70 3A 2F 2F 77 77 77 2E 6E 5297 : 69 73 74 2E 67 6F 76 2F 5298 : } 5299 437 30 31: SEQUENCE { 5300 439 06 3: OBJECT IDENTIFIER 5301 authorityKeyIdentifier (2 5 29 35) 5302 444 04 24: OCTET STRING 5303 : 30 16 80 14 30 12 80 10 0E 6B 3A BF 04 EA 04 C3 5304 : 0E 6B 3A BF 04 EA 04 C3 5305 : } 5306 470 30 23: SEQUENCE { 5307 472 06 3: OBJECT IDENTIFIER 5308 certificatePolicies (2 5 29 32) 5309 477 04 16: OCTET STRING 5310 : 30 0E 30 0C 06 0A 60 86 48 01 65 03 02 01 30 09 5311 : } 5312 495 30 14: SEQUENCE { 5313 497 06 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) 5314 502 01 1: BOOLEAN TRUE 5315 505 04 4: OCTET STRING 5316 : 03 02 07 80 5317 : } 5318 : } 5319 : } 5320 : } 5321 511 30 13: SEQUENCE { 5322 513 06 9: OBJECT IDENTIFIER 5323 : sha1withRSAEncryption (1 2 840 113549 1 1 5) 5324 524 05 0: NULL 5325 : } 5326 526 03 129: BIT STRING 0 unused bits 5327 : C1 25 6F AB 72 C0 5D DA E4 2F D5 E1 B0 25 D8 B4 5328 : F1 82 95 D6 0D A5 4E 4F A1 23 E1 13 A4 9C 3D C5 5329 : 7F FD 05 EC 75 06 30 66 97 75 A6 5D 8F 97 BA B4 5330 : EC A9 43 19 8D B7 54 FD E9 AD 43 B8 3C 8B D3 9E 5331 : C7 C7 27 E3 1A AD D3 79 AC 65 5A 52 78 C4 D0 43 5332 : 81 50 F7 8A BA E2 30 1A 6D D0 78 A0 4E AE 2E 79 5333 : 37 0C 93 05 5C D1 9C 1B B2 62 73 D1 EA 50 B7 84 5334 : 29 92 74 34 CF BA AA 2C 4D 43 59 EF 98 0C 41 6C 5335 : } 5337 C.4 Certificate Revocation List 5339 This section contains an annotated hex dump of a version 2 CRL with 5340 one extension (cRLNumber). The CRL was issued by OU=nist;O=gov;C=us 5341 on July 7, 1996; the next scheduled issuance was August 7, 1996. The 5342 CRL includes one revoked certificates: serial number 18 (12 hex). 5343 The CRL itself is number 18, and it was signed with DSA and SHA-1. 5345 0 30 203: SEQUENCE { 5346 3 30 140: SEQUENCE { 5347 6 02 1: INTEGER 1 5348 9 30 9: SEQUENCE { 5349 11 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5350 : } 5351 20 30 42: SEQUENCE { 5352 22 31 11: SET { 5353 24 30 9: SEQUENCE { 5354 26 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5355 31 13 2: PrintableString 'US' 5356 : } 5357 : } 5358 35 31 12: SET { 5359 37 30 10: SEQUENCE { 5360 39 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5361 44 13 3: PrintableString 'gov' 5362 : } 5363 : } 5364 49 31 13: SET { 5365 51 30 11: SEQUENCE { 5366 53 06 3: OBJECT IDENTIFIER 5367 organizationalUnitName (2 5 4 11) 5369 58 13 4: PrintableString 'NIST' 5370 : } 5371 : } 5372 : } 5373 64 17 13: UTCTime '970807000000Z' 5374 79 17 13: UTCTime '970907000000Z' 5375 94 30 34: SEQUENCE { 5376 96 30 32: SEQUENCE { 5377 98 02 1: INTEGER 18 5378 101 17 13: UTCTime '970731000000Z' 5379 116 30 12: SEQUENCE { 5380 118 30 10: SEQUENCE { 5381 120 06 3: OBJECT IDENTIFIER cRLReason (2 5 29 21) 5382 125 04 3: OCTET STRING 5383 : 0A 01 01 5384 : } 5385 : } 5386 : } 5387 : } 5388 130 A0 14: [0] { 5389 132 30 12: SEQUENCE { 5390 134 30 10: SEQUENCE { 5391 136 06 3: OBJECT IDENTIFIER cRLNumber (2 5 29 20) 5392 141 04 3: OCTET STRING 5393 : 02 01 12 5394 : } 5395 : } 5396 : } 5397 : } 5398 146 30 9: SEQUENCE { 5399 148 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5400 : } 5401 157 03 47: BIT STRING 0 unused bits 5402 : 30 2C 02 14 79 1F F6 93 0B 84 06 D6 A0 7C 8D 68 5403 : A7 52 2E 5F 3F 89 9B 4B 02 14 66 D4 B5 2A 68 36 5404 : 9B 72 88 58 E3 89 19 AD 81 89 2E 96 BB CC 5405 : } 5407 Appendix D. Author Addresses: 5409 Russell Housley 5410 SPYRUS 5411 381 Elden Street 5412 Suite 1120 5413 Herndon, VA 20170 5414 USA 5415 housley@spyrus.com 5417 Warwick Ford 5418 VeriSign, Inc. 5419 One Alewife Center 5420 Cambridge, MA 02140 5421 USA 5422 wford@verisign.com 5424 Tim Polk 5425 NIST 5426 Building 820, Room 426 5427 Gaithersburg, MD 20899 5428 USA 5429 wpolk@nist.gov 5431 David Solo 5432 Citicorp 5433 666 Fifth Ave, 3rd Floor 5434 New York, NY 10103 5435 USA 5436 david.solo@citicorp.com 5438 Appendix E. Full Copyright Statement 5440 Copyright (C) The Internet Society (date). All Rights Reserved. 5442 This document and translations of it may be copied and furnished to 5443 others, and derivative works that comment on or otherwise explain it 5444 or assist in its implementation may be prepared, copied, published 5445 and distributed, in whole or in part, without restriction of any 5446 kind, provided that the above copyright notice and this paragraph are 5447 included on all such copies and derivative works. In addition, the 5448 ASN.1 modules presented in Appendices A and B may be used in whole or 5449 in part without inclusion of the copyright notice. However, this 5450 document itself may not be modified in any way, such as by removing 5451 the copyright notice or references to the Internet Society or other 5452 Internet organizations, except as needed for the purpose of 5453 developing Internet standards in which case the procedures for 5454 copyrights defined in the Internet Standards process shall be 5455 followed, or as required to translate it into languages other than 5456 English. 5458 The limited permissions granted above are perpetual and will not be 5459 revoked by the Internet Society or its successors or assigns. This 5460 document and the information contained herein is provided on an "AS 5461 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 5462 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 5463 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 5464 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 5465 OR FITNESS FOR A PARTICULAR PURPOSE.