idnits 2.17.00 (12 Aug 2021) /tmp/idnits40378/draft-ietf-pkix-new-part1-05.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 119 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 119 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 24 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The first octets (the first characters of the first line) of this draft are 'PK', which can make Internet Explorer erroneously think that it is a zip file. It is recommended that you change this, for instance by inserting a blank line before the line starting with 'PK'. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 610 has weird spacing: '...issuing a cer...' == Line 621 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 (March 2001) is 7736 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 5381 -- Looks like a reference, but probably isn't: '1' on line 4727 -- Looks like a reference, but probably isn't: '2' on line 4728 -- Looks like a reference, but probably isn't: '3' on line 5276 == Missing Reference: 'ISO 8859-1' is mentioned on line 916, but not defined -- Looks like a reference, but probably isn't: '4' on line 4730 -- Looks like a reference, but probably isn't: '5' on line 4591 -- Looks like a reference, but probably isn't: '6' on line 4592 -- Looks like a reference, but probably isn't: '7' on line 4593 -- Looks like a reference, but probably isn't: '8' on line 4594 == Missing Reference: 'RFC1738' is mentioned on line 2533, but not defined ** Obsolete undefined reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) == Missing Reference: 'RFC1778' is mentioned on line 2533, but not defined ** Obsolete undefined reference: RFC 1778 (Obsoleted by RFC 3494) == Missing Reference: 'UNIVERSAL 28' is mentioned on line 3888, but not defined == Missing Reference: 'UNIVERSAL 30' is mentioned on line 3891, but not defined == Missing Reference: 'UNIVERSAL 12' is mentioned on line 3895, but not defined == Missing Reference: 'APPLICATION 1' is mentioned on line 4193, but not defined == Missing Reference: 'APPLICATION 2' is mentioned on line 4199, but not defined == Missing Reference: 'LDAP' is mentioned on line 4848, but not defined == Unused Reference: 'RFC 1423' is defined on line 3642, but no explicit reference was found in the text == Unused Reference: 'RFC 1778' is defined on line 3656, but no explicit reference was found in the text == Unused Reference: 'RFC 1883' is defined on line 3660, but no explicit reference was found in the text == Unused Reference: 'RFC 2119' is defined on line 3663, but no explicit reference was found in the text == Unused Reference: 'RFC 2277' is defined on line 3670, but no explicit reference was found in the text == Unused Reference: 'RFC 2279' is defined on line 3673, but no explicit reference was found in the text == Unused Reference: 'PKIX TSA' is defined on line 3712, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Downref: Normative reference to an Historic RFC: RFC 1422 ** Downref: Normative reference to an Historic RFC: RFC 1423 ** Obsolete normative reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) ** Obsolete normative reference: RFC 1519 (Obsoleted by RFC 4632) ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 1778 (Obsoleted by RFC 3494) ** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) == Outdated reference: draft-ietf-cat-kerberos-pk-init has been published as RFC 4556 == Outdated reference: draft-ietf-pkix-ipki-pkalgs has been published as RFC 3279 == Outdated reference: draft-ietf-pkix-time-stamp has been published as RFC 3161 Summary: 18 errors (**), 0 flaws (~~), 28 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PKIX Working Group R. Housley (SPYRUS) 2 Internet Draft W. Ford (VeriSign) 3 W. Polk (NIST) 4 D. Solo (Citigroup) 5 expires in six months March 2001 7 Internet X.509 Public Key Infrastructure 9 Certificate and CRL Profile 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 To view the entire list of current Internet-Drafts, please check the 33 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 34 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 35 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 36 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 38 Copyright (C) The Internet Society (2001). All Rights Reserved. 40 Abstract 42 This is the fifth draft of a specification based upon RFC 2459. When 43 complete, this specification will obsolete RFC 2459. This 44 specification includes minor edits and clarifications. The most 45 notable departures from RFC 2459 are found in Section 6, Path 46 Validation. In RFC 2459, the reader was expected to augment the path 47 validation algorithm, which concentrated upon policy processing, with 48 information embedded in earlier sections. For example, parameter 49 inheritance is discussed in Section 7, Algorithm Support, and can 50 certainly affect the validity of a certification path. However, 51 parameter inheritance was omitted from the path validation algorithm 52 in RFC 2459. In this draft, the path validation algorithm has a 53 comprehensive and extremely detailed description. Details such as 54 parameter inheritance are covered thoroughly. In addition, this 55 draft anticipates certain corrections proposed in the X.509 standard 56 for the policy processing aspects of path validation. 58 A new section 6.3, CRL validation, has been added as well. This 59 section provides a supplement to the path validation algorithm that 60 determines if a particular CRL may be used to verify the status of a 61 particular certificate. (The basic path validation algorithm is, by 62 design, independent of the type and format of status information.) 64 The most significant enhancement in draft five is a refinement of the 65 processing rules for path length constraints when applied to CA 66 certificates. This draft also completes the removal of processing 67 rules for unique identifiers. This was generally performed in the 68 fourth draft, but some details were overlooked. This draft also 69 incorporates significant corrections to the ASN.1 modules in the 70 appendices. 72 This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use 73 in the Internet. An overview of the approach and model are provided 74 as an introduction. The X.509 v3 certificate format is described in 75 detail, with additional information regarding the format and 76 semantics of Internet name forms (e.g., IP addresses). Standard 77 certificate extensions are described and one new Internet-specific 78 extension is defined. A required set of certificate extensions is 79 specified. The X.509 v2 CRL format is described and a required 80 extension set is defined as well. An algorithm for X.509 certificate 81 path validation is described. Supplemental information is provided 82 describing the format of public keys and digital signatures in X.509 83 certificates for common Internet public key encryption algorithms 84 (i.e., RSA, DSA, and Diffie-Hellman). ASN.1 modules and examples are 85 provided in the appendices. 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119. 91 Please send comments on this document to the ietf-pkix@imc.org mail 92 list. 94 Table of Contents 96 1 Introduction ................................................ 6 97 2 Requirements and Assumptions ................................ 7 98 2.1 Communication and Topology ................................ 7 99 2.2 Acceptability Criteria .................................... 8 100 2.3 User Expectations ......................................... 8 101 2.4 Administrator Expectations ................................ 8 102 3 Overview of Approach ........................................ 8 103 3.1 X.509 Version 3 Certificate ............................... 10 104 3.2 Certification Paths and Trust ............................. 11 105 3.3 Revocation ................................................ 13 106 3.4 Operational Protocols ..................................... 14 107 3.5 Management Protocols ...................................... 14 108 4 Certificate and Certificate Extensions Profile .............. 15 109 4.1 Basic Certificate Fields .................................. 16 110 4.1.1 Certificate Fields ...................................... 17 111 4.1.1.1 tbsCertificate ........................................ 17 112 4.1.1.2 signatureAlgorithm .................................... 17 113 4.1.1.3 signatureValue ........................................ 18 114 4.1.2 TBSCertificate .......................................... 18 115 4.1.2.1 Version ............................................... 18 116 4.1.2.2 Serial number ......................................... 19 117 4.1.2.3 Signature ............................................. 19 118 4.1.2.4 Issuer ................................................ 19 119 4.1.2.5 Validity .............................................. 23 120 4.1.2.5.1 UTCTime ............................................. 23 121 4.1.2.5.2 GeneralizedTime ..................................... 23 122 4.1.2.6 Subject ............................................... 24 123 4.1.2.7 Subject Public Key Info ............................... 25 124 4.1.2.8 Unique Identifiers .................................... 25 125 4.1.2.9 Extensions ............................................. 25 126 4.2 Certificate Extensions .................................... 25 127 4.2.1 Standard Extensions ..................................... 26 128 4.2.1.1 Authority Key Identifier .............................. 27 129 4.2.1.2 Subject Key Identifier ................................ 27 130 4.2.1.3 Key Usage ............................................. 29 131 4.2.1.4 Private Key Usage Period .............................. 30 132 4.2.1.5 Certificate Policies .................................. 31 133 4.2.1.6 Policy Mappings ....................................... 33 134 4.2.1.7 Subject Alternative Name .............................. 34 135 4.2.1.8 Issuer Alternative Name ............................... 36 136 4.2.1.9 Subject Directory Attributes .......................... 37 137 4.2.1.10 Basic Constraints .................................... 37 138 4.2.1.11 Name Constraints ..................................... 38 139 4.2.1.12 Policy Constraints ................................... 40 140 4.2.1.13 Extended key usage field ............................. 41 141 4.2.1.14 CRL Distribution Points .............................. 42 142 4.2.1.15 Inhibit Any-Policy ................................... 43 143 4.2.1.16 Freshest CRL ......................................... 43 144 4.2.2 Internet Certificate Extensions ......................... 44 145 4.2.2.1 Authority Information Access .......................... 44 146 4.2.2.2 Subject Information Access ............................ 45 147 5 CRL and CRL Extensions Profile .............................. 47 148 5.1 CRL Fields ................................................ 47 149 5.1.1 CertificateList Fields .................................. 48 150 5.1.1.1 tbsCertList ........................................... 48 151 5.1.1.2 signatureAlgorithm .................................... 49 152 5.1.1.3 signatureValue ........................................ 49 153 5.1.2 Certificate List "To Be Signed" ......................... 49 154 5.1.2.1 Version ............................................... 49 155 5.1.2.2 Signature ............................................. 49 156 5.1.2.3 Issuer Name ........................................... 50 157 5.1.2.4 This Update ........................................... 50 158 5.1.2.5 Next Update ........................................... 50 159 5.1.2.6 Revoked Certificates .................................. 51 160 5.1.2.7 Extensions ............................................ 51 161 5.2 CRL Extensions ............................................ 51 162 5.2.1 Authority Key Identifier ................................ 51 163 5.2.2 Issuer Alternative Name ................................. 52 164 5.2.3 CRL Number .............................................. 52 165 5.2.4 Delta CRL Indicator ..................................... 52 166 5.2.5 Issuing Distribution Point .............................. 54 167 5.2.6 Freshest CRL ............................................ 55 168 5.3 CRL Entry Extensions ...................................... 55 169 5.3.1 Reason Code ............................................. 56 170 5.3.2 Hold Instruction Code ................................... 56 171 5.3.3 Invalidity Date ......................................... 57 172 5.3.4 Certificate Issuer ...................................... 57 173 6 Certificate Path Validation ................................. 58 174 6.1 Basic Path Validation ..................................... 58 175 6.1.1 Inputs ................................................... 61 176 6.1.2 Initialization ........................................... 62 177 6.1.3 Basic Certificate Processing ............................. 65 178 6.1.4 Preparation for Certificate i+1 .......................... 70 179 6.1.5 Wrap-up procedure ........................................ 73 180 6.1.6 Outputs .................................................. 74 181 6.2 Extending Path Validation ................................. 75 182 6.3 CRL Validation ............................................ 75 183 6.3.1 Revocation Inputs ....................................... 76 184 6.3.2 Initialization and Revocation State Variables ........... 76 185 6.3.3 CRL Processing .......................................... 77 186 7 References .................................................. 79 187 8 Intellectual Property Rights ................................ 81 188 9 Security Considerations ..................................... 81 189 Appendix A. ASN.1 Structures and OIDs ......................... 85 190 A.1 Explicitly Tagged Module, 1988 Syntax ...................... 85 191 A.2 Implicitly Tagged Module, 1988 Syntax ...................... 98 192 Appendix B. ASN.1 Notes ....................................... 105 193 Appendix C. Examples .......................................... 106 194 C.1 Certificate ............................................... 107 195 C.2 Certificate ............................................... 110 196 C.3 End-Entity Certificate Using RSA .......................... 113 197 C.4 Certificate Revocation List ............................... 116 198 Appendix D. Author Addresses .................................. 118 199 Appendix E. Full Copyright Statement .......................... 118 201 1 Introduction 203 This specification is one part of a family of standards for the X.509 204 Public Key Infrastructure (PKI) for the Internet. This specification 205 is a standalone document; implementations of this standard may 206 proceed independent from the other parts. 208 This specification profiles the format and semantics of certificates 209 and certificate revocation lists for the Internet PKI. Procedures 210 are described for processing of certification paths in the Internet 211 environment. Encoding rules are provided for popular cryptographic 212 algorithms. Finally, ASN.1 modules are provided in the appendices 213 for all data structures defined or referenced. 215 The specification describes the requirements which inspire the 216 creation of this document and the assumptions which affect its scope 217 in Section 2. Section 3 presents an architectural model and 218 describes its relationship to previous IETF and ISO/IEC/ITU 219 standards. In particular, this document's relationship with the IETF 220 PEM specifications and the ISO/IEC/ITU X.509 documents are described. 222 The specification profiles the X.509 version 3 certificate in Section 223 4, and the X.509 version 2 certificate revocation list (CRL) in 224 Section 5. The profiles include the identification of ISO/IEC/ITU 225 and ANSI extensions which may be useful in the Internet PKI. The 226 profiles are presented in the 1988 Abstract Syntax Notation One 227 (ASN.1) rather than the 1994 syntax used in the ISO/IEC/ITU 228 standards. 230 This specification also includes path validation procedures in 231 Section 6. These procedures are based upon the ISO/IEC/ITU 232 definition, but the presentation assumes one or more self-signed 233 trusted CA certificates. Implementations are required to derive the 234 same results but are not required to use the specified procedures. 236 Procedures for identification and encoding of public key materials 237 and digital signatures are defined in [PKIX ALGS]. Implementations of 238 this specification are not required to use any particular 239 cryptographic algorithms. However, conforming implementations which 240 use the algorithms identified in [PKIX ALGS] are required to identify 241 and encode the public key materials and digital signatures as 242 described in that specification. 244 Finally, three appendices are provided to aid implementers. Appendix 245 A contains all ASN.1 structures defined or referenced within this 246 specification. As above, the material is presented in the 1988 247 Abstract Syntax Notation One (ASN.1) rather than the 1994 syntax. 248 Appendix B contains notes on less familiar features of the ASN.1 249 notation used within this specification. Appendix C contains 250 examples of a conforming certificate and a conforming CRL. 252 2 Requirements and Assumptions 254 The goal of this specification is to develop a profile to facilitate 255 the use of X.509 certificates within Internet applications for those 256 communities wishing to make use of X.509 technology. Such 257 applications may include WWW, electronic mail, user authentication, 258 and IPsec. In order to relieve some of the obstacles to using X.509 259 certificates, this document defines a profile to promote the 260 development of certificate management systems; development of 261 application tools; and interoperability determined by policy. 263 Some communities will need to supplement, or possibly replace, this 264 profile in order to meet the requirements of specialized application 265 domains or environments with additional authorization, assurance, or 266 operational requirements. However, for basic applications, common 267 representations of frequently used attributes are defined so that 268 application developers can obtain necessary information without 269 regard to the issuer of a particular certificate or certificate 270 revocation list (CRL). 272 A certificate user should review the certificate policy generated by 273 the certification authority (CA) before relying on the authentication 274 or non-repudiation services associated with the public key in a 275 particular certificate. To this end, this standard does not 276 prescribe legally binding rules or duties. 278 As supplemental authorization and attribute management tools emerge, 279 such as attribute certificates, it may be appropriate to limit the 280 authenticated attributes that are included in a certificate. These 281 other management tools may provide more appropriate methods of 282 conveying many authenticated attributes. 284 2.1 Communication and Topology 286 The users of certificates will operate in a wide range of 287 environments with respect to their communication topology, especially 288 users of secure electronic mail. This profile supports users without 289 high bandwidth, real-time IP connectivity, or high connection 290 availability. In addition, the profile allows for the presence of 291 firewall or other filtered communication. 293 This profile does not assume the deployment of an X.500 Directory 294 system. The profile does not prohibit the use of an X.500 Directory, 295 but other means of distributing certificates and certificate 296 revocation lists (CRLs) may be used. 298 2.2 Acceptability Criteria 300 The goal of the Internet Public Key Infrastructure (PKI) is to meet 301 the needs of deterministic, automated identification, authentication, 302 access control, and authorization functions. Support for these 303 services determines the attributes contained in the certificate as 304 well as the ancillary control information in the certificate such as 305 policy data and certification path constraints. 307 2.3 User Expectations 309 Users of the Internet PKI are people and processes who use client 310 software and are the subjects named in certificates. These uses 311 include readers and writers of electronic mail, the clients for WWW 312 browsers, WWW servers, and the key manager for IPsec within a router. 313 This profile recognizes the limitations of the platforms these users 314 employ and the limitations in sophistication and attentiveness of the 315 users themselves. This manifests itself in minimal user 316 configuration responsibility (e.g., trusted CA keys, rules), explicit 317 platform usage constraints within the certificate, certification path 318 constraints which shield the user from many malicious actions, and 319 applications which sensibly automate validation functions. 321 2.4 Administrator Expectations 323 As with user expectations, the Internet PKI profile is structured to 324 support the individuals who generally operate CAs. Providing 325 administrators with unbounded choices increases the chances that a 326 subtle CA administrator mistake will result in broad compromise. 327 Also, unbounded choices greatly complicate the software that shall 328 process and validate the certificates created by the CA. 330 3 Overview of Approach 332 Following is a simplified view of the architectural model assumed by 333 the PKIX specifications. 335 +---+ 336 | C | +------------+ 337 | e | <-------------------->| End entity | 338 | r | Operational +------------+ 339 | t | transactions ^ 340 | | and management | Management 341 | / | transactions | transactions 342 | | | PKI users 343 | C | v 344 | R | -------------------+--+-----------+---------------- 345 | L | ^ ^ 346 | | | | PKI management 347 | | v | entities 348 | R | +------+ | 349 | e | <---------------------| RA | <---+ | 350 | p | Publish certificate +------+ | | 351 | o | | | 352 | s | | | 353 | I | v v 354 | t | +------------+ 355 | o | <------------------------------| CA | 356 | r | Publish certificate +------------+ 357 | y | Publish CRL ^ 358 | | | 359 +---+ Management | 360 transactions | 361 v 362 +------+ 363 | CA | 364 +------+ 366 Figure 1 - PKI Entities 368 The components in this model are: 370 end entity: user of PKI certificates and/or end user system that 371 is the subject of a certificate; 372 CA: certification authority; 373 RA: registration authority, i.e., an optional system to 374 which a CA delegates certain management functions; 375 repository: a system or collection of distributed systems that 376 store certificates and CRLs and serves as a means of 377 distributing these certificates and CRLs to end 378 entities. 380 3.1 X.509 Version 3 Certificate 382 Users of a public key require confidence that the associated private 383 key is owned by the correct remote subject (person or system) with 384 which an encryption or digital signature mechanism will be used. 385 This confidence is obtained through the use of public key 386 certificates, which are data structures that bind public key values 387 to subjects. The binding is asserted by having a trusted CA 388 digitally sign each certificate. The CA may base this assertion upon 389 technical means (a.k.a., proof of posession through a challenge- 390 response protocol), presentation of the private key, or on an 391 assertion by the subject. A certificate has a limited valid lifetime 392 which is indicated in its signed contents. Because a certificate's 393 signature and timeliness can be independently checked by a 394 certificate-using client, certificates can be distributed via 395 untrusted communications and server systems, and can be cached in 396 unsecured storage in certificate-using systems. 398 ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8, which was 399 first published in 1988 as part of the X.500 Directory 400 recommendations, defines a standard certificate format [X.509]. The 401 certificate format in the 1988 standard is called the version 1 (v1) 402 format. When X.500 was revised in 1993, two more fields were added, 403 resulting in the version 2 (v2) format. 405 The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993, 406 include specifications for a public key infrastructure based on X.509 407 v1 certificates [RFC 1422]. The experience gained in attempts to 408 deploy RFC 1422 made it clear that the v1 and v2 certificate formats 409 are deficient in several respects. Most importantly, more fields 410 were needed to carry information which PEM design and implementation 411 experience has proven necessary. In response to these new 412 requirements, ISO/IEC/ITU and ANSI X9 developed the X.509 version 3 413 (v3) certificate format. The v3 format extends the v2 format by 414 adding provision for additional extension fields. Particular 415 extension field types may be specified in standards or may be defined 416 and registered by any organization or community. In June 1996, 417 standardization of the basic v3 format was completed [X.509]. 419 ISO/IEC/ITU and ANSI X9 have also developed standard extensions for 420 use in the v3 extensions field [X.509][X9.55]. These extensions can 421 convey such data as additional subject identification information, 422 key attribute information, policy information, and certification path 423 constraints. 425 However, the ISO/IEC/ITU and ANSI X9 standard extensions are very 426 broad in their applicability. In order to develop interoperable 427 implementations of X.509 v3 systems for Internet use, it is necessary 428 to specify a profile for use of the X.509 v3 extensions tailored for 429 the Internet. It is one goal of this document to specify a profile 430 for Internet WWW, electronic mail, and IPsec applications. 431 Environments with additional requirements may build on this profile 432 or may replace it. 434 3.2 Certification Paths and Trust 436 A user of a security service requiring knowledge of a public key 437 generally needs to obtain and validate a certificate containing the 438 required public key. If the public-key user does not already hold an 439 assured copy of the public key of the CA that signed the certificate, 440 the CA's name, and related information (such as the validity period 441 or name constraints), then it might need an additional certificate to 442 obtain that public key. In general, a chain of multiple certificates 443 may be needed, comprising a certificate of the public key owner (the 444 end entity) signed by one CA, and zero or more additional 445 certificates of CAs signed by other CAs. Such chains, called 446 certification paths, are required because a public key user is only 447 initialized with a limited number of assured CA public keys. 449 There are different ways in which CAs might be configured in order 450 for public key users to be able to find certification paths. For 451 PEM, RFC 1422 defined a rigid hierarchical structure of CAs. There 452 are three types of PEM certification authority: 454 (a) Internet Policy Registration Authority (IPRA): This 455 authority, operated under the auspices of the Internet Society, 456 acts as the root of the PEM certification hierarchy at level 1. 457 It issues certificates only for the next level of authorities, 458 PCAs. All certification paths start with the IPRA. 460 (b) Policy Certification Authorities (PCAs): PCAs are at level 2 461 of the hierarchy, each PCA being certified by the IPRA. A PCA 462 shall establish and publish a statement of its policy with respect 463 to certifying users or subordinate certification authorities. 464 Distinct PCAs aim to satisfy different user needs. For example, 465 one PCA (an organizational PCA) might support the general 466 electronic mail needs of commercial organizations, and another PCA 467 (a high-assurance PCA) might have a more stringent policy designed 468 for satisfying legally binding digital signature requirements. 470 (c) Certification Authorities (CAs): CAs are at level 3 of the 471 hierarchy and can also be at lower levels. Those at level 3 are 472 certified by PCAs. CAs represent, for example, particular 473 organizations, particular organizational units (e.g., departments, 474 groups, sections), or particular geographical areas. 476 RFC 1422 furthermore has a name subordination rule which requires 477 that a CA can only issue certificates for entities whose names are 478 subordinate (in the X.500 naming tree) to the name of the CA itself. 479 The trust associated with a PEM certification path is implied by the 480 PCA name. The name subordination rule ensures that CAs below the PCA 481 are sensibly constrained as to the set of subordinate entities they 482 can certify (e.g., a CA for an organization can only certify entities 483 in that organization's name tree). Certificate user systems are able 484 to mechanically check that the name subordination rule has been 485 followed. 487 The RFC 1422 uses the X.509 v1 certificate formats. The limitations 488 of X.509 v1 required imposition of several structural restrictions to 489 clearly associate policy information or restrict the utility of 490 certificates. These restrictions included: 492 (a) a pure top-down hierarchy, with all certification paths 493 starting from IPRA; 495 (b) a naming subordination rule restricting the names of a CA's 496 subjects; and 498 (c) use of the PCA concept, which requires knowledge of individual 499 PCAs to be built into certificate chain verification logic. 500 Knowledge of individual PCAs was required to determine if a chain 501 could be accepted. 503 With X.509 v3, most of the requirements addressed by RFC 1422 can be 504 addressed using certificate extensions, without a need to restrict 505 the CA structures used. In particular, the certificate extensions 506 relating to certificate policies obviate the need for PCAs and the 507 constraint extensions obviate the need for the name subordination 508 rule. As a result, this document supports a more flexible 509 architecture, including: 511 (a) Certification paths may start with a public key of a CA in a 512 user's own domain, or with the public key of the top of a 513 hierarchy. Starting with the public key of a CA in a user's own 514 domain has certain advantages. In some environments, the local 515 domain is the most trusted. 517 (b) Name constraints may be imposed through explicit inclusion of 518 a name constraints extension in a certificate, but are not 519 required. 521 (c) Policy extensions and policy mappings replace the PCA 522 concept, which permits a greater degree of automation. The 523 application can determine if the certification path is acceptable 524 based on the contents of the certificates instead of a priori 525 knowledge of PCAs. This permits automation of certificate chain 526 processing. 528 3.3 Revocation 530 When a certificate is issued, it is expected to be in use for its 531 entire validity period. However, various circumstances may cause a 532 certificate to become invalid prior to the expiration of the validity 533 period. Such circumstances include change of name, change of 534 association between subject and CA (e.g., an employee terminates 535 employment with an organization), and compromise or suspected 536 compromise of the corresponding private key. Under such 537 circumstances, the CA needs to revoke the certificate. 539 X.509 defines one method of certificate revocation. This method 540 involves each CA periodically issuing a signed data structure called 541 a certificate revocation list (CRL). A CRL is a time stamped list 542 identifying revoked certificates which is signed by a CA and made 543 freely available in a public repository. Each revoked certificate is 544 identified in a CRL by its certificate serial number. When a 545 certificate-using system uses a certificate (e.g., for verifying a 546 remote user's digital signature), that system not only checks the 547 certificate signature and validity but also acquires a suitably- 548 recent CRL and checks that the certificate serial number is not on 549 that CRL. The meaning of "suitably-recent" may vary with local 550 policy, but it usually means the most recently-issued CRL. A CA 551 issues a new CRL on a regular periodic basis (e.g., hourly, daily, or 552 weekly). An entry is added to the CRL as part of the next update 553 following notification of revocation. An entry may be removed from 554 the CRL after appearing on one regularly scheduled CRL issued beyond 555 the revoked certificate's validity period. 557 An advantage of this revocation method is that CRLs may be 558 distributed by exactly the same means as certificates themselves, 559 namely, via untrusted communications and server systems. 561 One limitation of the CRL revocation method, using untrusted 562 communications and servers, is that the time granularity of 563 revocation is limited to the CRL issue period. For example, if a 564 revocation is reported now, that revocation will not be reliably 565 notified to certificate-using systems until all currently issued CRLs 566 are updated -- this may be up to one hour, one day, or one week 567 depending on the frequency that the CA issues CRLs. 569 As with the X.509 v3 certificate format, in order to facilitate 570 interoperable implementations from multiple vendors, the X.509 v2 CRL 571 format needs to be profiled for Internet use. It is one goal of this 572 document to specify that profile. However, this profile does not 573 require CAs to issue CRLs. Message formats and protocols supporting 574 on-line revocation notification may be defined in other PKIX 575 specifications. On-line methods of revocation notification may be 576 applicable in some environments as an alternative to the X.509 CRL. 577 On-line revocation checking may significantly reduce the latency 578 between a revocation report and the distribution of the information 579 to relying parties. Once the CA accepts the report as authentic and 580 valid, any query to the on-line service will correctly reflect the 581 certificate validation impacts of the revocation. However, these 582 methods impose new security requirements: the certificate validator 583 needs to trust the on-line validation service while the repository 584 does not need to be trusted. 586 3.4 Operational Protocols 588 Operational protocols are required to deliver certificates and CRLs 589 (or status information) to certificate using client systems. 590 Provision is needed for a variety of different means of certificate 591 and CRL delivery, including distribution procedures based on LDAP, 592 HTTP, FTP, and X.500. Operational protocols supporting these 593 functions are defined in other PKIX specifications. These 594 specifications may include definitions of message formats and 595 procedures for supporting all of the above operational environments, 596 including definitions of or references to appropriate MIME content 597 types. 599 3.5 Management Protocols 601 Management protocols are required to support on-line interactions 602 between PKI user and management entities. For example, a management 603 protocol might be used between a CA and a client system with which a 604 key pair is associated, or between two CAs which cross-certify each 605 other. The set of functions which potentially need to be supported 606 by management protocols include: 608 (a) registration: This is the process whereby a user first makes 609 itself known to a CA (directly, or through an RA), prior to that 610 CA issuing a certificate or certificates for that user. 612 (b) initialization: Before a client system can operate securely 613 it is necessary to install key materials which have the 614 appropriate relationship with keys stored elsewhere in the 615 infrastructure. For example, the client needs to be securely 616 initialized with the public key and other assured information of 617 the trusted CA(s), to be used in validating certificate paths. 618 Furthermore, a client typically needs to be initialized with its 619 own key pair(s). 621 (c) certification: This is the process in which a CA issues a 622 certificate for a user's public key, and returns that certificate 623 to the user's client system and/or posts that certificate in a 624 repository. 626 (d) key pair recovery: As an option, user client key materials 627 (e.g., a user's private key used for encryption purposes) may be 628 backed up by a CA or a key backup system. If a user needs to 629 recover these backed up key materials (e.g., as a result of a 630 forgotten password or a lost key chain file), an on-line protocol 631 exchange may be needed to support such recovery. 633 (e) key pair update: All key pairs need to be updated regularly, 634 i.e., replaced with a new key pair, and new certificates issued. 636 (f) revocation request: An authorized person advises a CA of an 637 abnormal situation requiring certificate revocation. 639 (g) cross-certification: Two CAs exchange information used in 640 establishing a cross-certificate. A cross-certificate is a 641 certificate issued by one CA to another CA which contains a CA 642 signature key used for issuing certificates. 644 Note that on-line protocols are not the only way of implementing the 645 above functions. For all functions there are off-line methods of 646 achieving the same result, and this specification does not mandate 647 use of on-line protocols. For example, when hardware tokens are 648 used, many of the functions may be achieved as part of the physical 649 token delivery. Furthermore, some of the above functions may be 650 combined into one protocol exchange. In particular, two or more of 651 the registration, initialization, and certification functions can be 652 combined into one protocol exchange. 654 The PKIX series of specifications may define a set of standard 655 message formats supporting the above functions in future 656 specifications. In that case, the protocols for conveying these 657 messages in different environments (e.g., on-line, file transfer, e- 658 mail, and WWW) will also be described in those specifications. 660 4 Certificate and Certificate Extensions Profile 662 This section presents a profile for public key certificates that will 663 foster interoperability and a reusable PKI. This section is based 664 upon the X.509 v3 certificate format and the standard certificate 665 extensions defined in [X.509]. The ISO/IEC/ITU documents use the 666 1993 version of ASN.1; while this document uses the 1988 ASN.1 667 syntax, the encoded certificate and standard extensions are 668 equivalent. This section also defines private extensions required to 669 support a PKI for the Internet community. 671 Certificates may be used in a wide range of applications and 672 environments covering a broad spectrum of interoperability goals and 673 a broader spectrum of operational and assurance requirements. The 674 goal of this document is to establish a common baseline for generic 675 applications requiring broad interoperability and limited special 676 purpose requirements. In particular, the emphasis will be on 677 supporting the use of X.509 v3 certificates for informal Internet 678 electronic mail, IPsec, and WWW applications. 680 4.1 Basic Certificate Fields 682 The X.509 v3 certificate basic syntax is as follows. For signature 683 calculation, the certificate is encoded using the ASN.1 distinguished 684 encoding rules (DER) [X.208]. ASN.1 DER encoding is a tag, length, 685 value encoding system for each element. 687 Certificate ::= SEQUENCE { 688 tbsCertificate TBSCertificate, 689 signatureAlgorithm AlgorithmIdentifier, 690 signatureValue BIT STRING } 692 TBSCertificate ::= SEQUENCE { 693 version [0] EXPLICIT Version DEFAULT v1, 694 serialNumber CertificateSerialNumber, 695 signature AlgorithmIdentifier, 696 issuer Name, 697 validity Validity, 698 subject Name, 699 subjectPublicKeyInfo SubjectPublicKeyInfo, 700 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 701 -- If present, version shall be v2 or v3 702 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 703 -- If present, version shall be v2 or v3 704 extensions [3] EXPLICIT Extensions OPTIONAL 705 -- If present, version shall be v3 706 } 708 Version ::= INTEGER { v1(0), v2(1), v3(2) } 710 CertificateSerialNumber ::= INTEGER 712 Validity ::= SEQUENCE { 713 notBefore Time, 714 notAfter Time } 716 Time ::= CHOICE { 717 utcTime UTCTime, 718 generalTime GeneralizedTime } 720 UniqueIdentifier ::= BIT STRING 722 SubjectPublicKeyInfo ::= SEQUENCE { 723 algorithm AlgorithmIdentifier, 724 subjectPublicKey BIT STRING } 726 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 728 Extension ::= SEQUENCE { 729 extnID OBJECT IDENTIFIER, 730 critical BOOLEAN DEFAULT FALSE, 731 extnValue OCTET STRING } 733 The following items describe the X.509 v3 certificate for use in the 734 Internet. 736 4.1.1 Certificate Fields 738 The Certificate is a SEQUENCE of three required fields. The fields 739 are described in detail in the following subsections. 741 4.1.1.1 tbsCertificate 743 The field contains the names of the subject and issuer, a public key 744 associated with the subject, a validity period, and other associated 745 information. The fields are described in detail in section 4.1.2; 746 the tbscertificate may also include extensions which are described in 747 section 4.2. 749 4.1.1.2 signatureAlgorithm 751 The signatureAlgorithm field contains the identifier for the 752 cryptographic algorithm used by the CA to sign this certificate. 753 [PKIX ALGS] lists the supported signature algorithms. 755 An algorithm identifier is defined by the following ASN.1 structure: 757 AlgorithmIdentifier ::= SEQUENCE { 758 algorithm OBJECT IDENTIFIER, 759 parameters ANY DEFINED BY algorithm OPTIONAL } 761 The algorithm identifier is used to identify a cryptographic 762 algorithm. The OBJECT IDENTIFIER component identifies the algorithm 763 (such as DSA with SHA-1). The contents of the optional parameters 764 field will vary according to the algorithm identified. [PKIX ALGS] 765 lists the supported algorithms for this specification. 767 This field MUST contain the same algorithm identifier as the 768 signature field in the sequence tbsCertificate (see sec. 4.1.2.3). 770 4.1.1.3 signatureValue 772 The signatureValue field contains a digital signature computed upon 773 the ASN.1 DER encoded tbsCertificate. The ASN.1 DER encoded 774 tbsCertificate is used as the input to the signature function. This 775 signature value is then ASN.1 encoded as a BIT STRING and included in 776 the Certificate's signature field. The details of this process are 777 specified for each of the supported algorithms in [PKIX ALGS]. 779 By generating this signature, a CA certifies the validity of the 780 information in the tbsCertificate field. In particular, the CA 781 certifies the binding between the public key material and the subject 782 of the certificate. 784 4.1.2 TBSCertificate 786 The sequence TBSCertificate contains information associated with the 787 subject of the certificate and the CA who issued it. Every 788 TBSCertificate contains the names of the subject and issuer, a public 789 key associated with the subject, a validity period, a version number, 790 and a serial number; some may contain optional unique identifier 791 fields. The remainder of this section describes the syntax and 792 semantics of these fields. A TBSCertificate may also include 793 extensions. Extensions for the Internet PKI are described in Section 794 4.2. 796 4.1.2.1 Version 798 This field describes the version of the encoded certificate. When 799 extensions are used, as expected in this profile, use X.509 version 3 800 (value is 2). If no extensions are present, but a UniqueIdentifier 801 is present, use version 2 (value is 1). If only basic fields are 802 present, use version 1 (the value is omitted from the certificate as 803 the default value). 805 Implementations SHOULD be prepared to accept any version certificate. 806 At a minimum, conforming implementations MUST recognize version 3 807 certificates. 809 Generation of version 2 certificates is not expected by 810 implementations based on this profile. 812 4.1.2.2 Serial number 814 The serial number MUST be a positive integer assigned by the CA to 815 each certificate. It MUST be unique for each certificate issued by a 816 given CA (i.e., the issuer name and serial number identify a unique 817 certificate). CAs MUST force the serialNumber to be a non-negative 818 integer. 820 Given the uniqueness requirements above serial numbers can be 821 expected to contain long integers. Certificate users MUST be able to 822 handle serialNumber values up to 20 octets. Conformant CAs MUST NOT 823 use serialNumber values longer than 20 octets. 825 Note: Non-conforming CAs may issue certificates with serial numbers 826 that are negative, or zero. Certificate users SHOULD be prepared to 827 handle such certificates. 829 4.1.2.3 Signature 831 This field contains the algorithm identifier for the algorithm used 832 by the CA to sign the certificate. 834 This field MUST contain the same algorithm identifier as the 835 signatureAlgorithm field in the sequence Certificate (see sec. 836 4.1.1.2). The contents of the optional parameters field will vary 837 according to the algorithm identified. [PKIX ALGS] lists the 838 supported signature algorithms. 840 4.1.2.4 Issuer 842 The issuer field identifies the entity who has signed and issued the 843 certificate. The issuer field MUST contain a non-empty distinguished 844 name (DN). The issuer field is defined as the X.501 type Name. 845 [X.501] Name is defined by the following ASN.1 structures: 847 Name ::= CHOICE { 848 RDNSequence } 850 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 852 RelativeDistinguishedName ::= 853 SET OF AttributeTypeAndValue 855 AttributeTypeAndValue ::= SEQUENCE { 856 type AttributeType, 857 value AttributeValue } 859 AttributeType ::= OBJECT IDENTIFIER 860 AttributeValue ::= ANY DEFINED BY AttributeType 862 DirectoryString ::= CHOICE { 863 teletexString TeletexString (SIZE (1..MAX)), 864 printableString PrintableString (SIZE (1..MAX)), 865 universalString UniversalString (SIZE (1..MAX)), 866 utf8String UTF8String (SIZE (1.. MAX)), 867 bmpString BMPString (SIZE (1..MAX)) } 869 The Name describes a hierarchical name composed of attributes, such 870 as country name, and corresponding values, such as US. The type of 871 the component AttributeValue is determined by the AttributeType; in 872 general it will be a DirectoryString. 874 The DirectoryString type is defined as a choice of PrintableString, 875 TeletexString, BMPString, UTF8String, and UniversalString. The 876 UTF8String encoding is the preferred encoding, and all certificates 877 issued after December 31, 2003 MUST use the UTF8String encoding of 878 DirectoryString (except as noted below). Until that date, conforming 879 CAs MUST choose from the following options when creating a 880 distinguished name, including their own: 882 (a) if the character set is sufficient, the string MAY be 883 represented as a PrintableString; 885 (b) failing (a), if the BMPString character set is sufficient the 886 string MAY be represented as a BMPString; and 888 (c) failing (a) and (b), the string MUST be represented as a 889 UTF8String. If (a) or (b) is satisfied, the CA MAY still choose 890 to represent the string as a UTF8String. 892 Exceptions to the December 31, 2003 UTF8 encoding requirements are as 893 follows: 895 (a) CAs MAY issue "name rollover" certificates to support an 896 orderly migration to UTF8String encoding. Such certificates would 897 include the CA's UTF8String encoded name as issuer and and the old 898 name encoding as subject, or vice-versa. 900 (b) As stated in section 4.1.2.6, the subject field MUST be 901 populated with a non-empty distinguished name matching the 902 contents of the issuer field in all certificates issued by the 903 subject CA regardless of encoding. 905 The TeletexString and UniversalString are included for backward 906 compatibility, and should not be used for certificates for new 907 subjects. However, these types may be used in certificates where the 908 name was previously established. Certificate users SHOULD be 909 prepared to receive certificates with these types. 911 In addition, many legacy implementations support names encoded in the 912 ISO 8859-1 character set (Latin1String) but tag them as 913 TeletexString. The Latin1String includes characters used in Western 914 European countries which are not part of the TeletexString charcter 915 set. Implementations that process TeletexString SHOULD be prepared 916 to handle the entire ISO 8859-1 character set.[ISO 8859-1] 918 As noted above, distinguished names are composed of attributes. This 919 specification does not restrict the set of attribute types that may 920 appear in names. However, conforming implementations MUST be 921 prepared to receive certificates with issuer names containing the set 922 of attribute types defined below. This specification also recommends 923 support for additional attribute types. 925 Standard sets of attributes have been defined in the X.500 series of 926 specifications.[X.520] Implementations of this specification MUST be 927 prepared to receive the following standard attribute types in issuer 928 and subject (see 4.1.2.6) names: 930 * country, 931 * organization, 932 * organizational-unit, 933 * distinguished name qualifier, 934 * state or province name, 935 * common name (e.g., "Susan Housley"), and 936 * serial number. 938 In addition, implementations of this specification SHOULD be prepared 939 to receive the following standard attribute types in issuer and 940 subject names: 942 * locality, 943 * title, 944 * surname, 945 * given name, 946 * initials, 947 * pseudonym, and 948 * generation qualifier (e.g., "Jr.", "3rd", or "IV"). 950 The syntax and associated object identifiers (OIDs) for these 951 attribute types are provided in the ASN.1 modules in Appendices A and 952 B. 954 In addition, implementations of this specification MUST be prepared 955 to receive the domainComponent attribute, as defined in [RFC 2247]. 956 The Domain (Nameserver) System (DNS) provides a hierarchical resource 957 labeling system. This attribute provides is a convenient mechanism 958 for organizations that wish to use DNs that parallel their DNS names. 959 This is not a replacement for the dNSName component of the 960 alternative name field. Implementations are not required to convert 961 such names into DNS names. The syntax and associated OID for this 962 attribute type is provided in the ASN.1 modules in Appendices A and 963 B. 965 Certificate users MUST be prepared to process the issuer 966 distinguished name and subject distinguished name (see sec. 4.1.2.6) 967 fields to perform name chaining for certification path validation 968 (see section 6). Name chaining is performed by matching the issuer 969 distinguished name in one certificate with the subject name in a CA 970 certificate. 972 This specification requires only a subset of the name comparison 973 functionality specified in the X.500 series of specifications. The 974 requirements for conforming implementations are as follows: 976 (a) attribute values encoded in different types (e.g., 977 PrintableString and BMPString) may be assumed to represent 978 different strings; 980 (b) attribute values in types other than PrintableString are case 981 sensitive (this permits matching of attribute values as binary 982 objects); 984 (c) attribute values in PrintableString are not case sensitive 985 (e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and 987 (d) attribute values in PrintableString are compared after 988 removing leading and trailing white space and converting internal 989 substrings of one or more consecutive white space characters to a 990 single space. 992 These name comparison rules permit a certificate user to validate 993 certificates issued using languages or encodings unfamiliar to the 994 certificate user. 996 In addition, implementations of this specification MAY use these 997 comparison rules to process unfamiliar attribute types for name 998 chaining. This allows implementations to process certificates with 999 unfamiliar attributes in the issuer name. 1001 Note that the comparison rules defined in the X.500 series of 1002 specifications indicate that the character sets used to encode data 1003 in distinguished names are irrelevant. The characters themselves are 1004 compared without regard to encoding. Implementations of the profile 1005 are permitted to use the comparison algorithm defined in the X.500 1006 series. Such an implementation will recognize a superset of name 1007 matches recognized by the algorithm specified above. 1009 4.1.2.5 Validity 1011 The certificate validity period is the time interval during which the 1012 CA warrants that it will maintain information about the status of the 1013 certificate. The field is represented as a SEQUENCE of two dates: 1014 the date on which the certificate validity period begins (notBefore) 1015 and the date on which the certificate validity period ends 1016 (notAfter). Both notBefore and notAfter may be encoded as UTCTime or 1017 GeneralizedTime. 1019 CAs conforming to this profile MUST always encode certificate 1020 validity dates through the year 2049 as UTCTime; certificate validity 1021 dates in 2050 or later MUST be encoded as GeneralizedTime. 1023 The validity period for a certificate is the period of time from 1024 notBefore through notAfter, inclusive. 1026 4.1.2.5.1 UTCTime 1028 The universal time type, UTCTime, is a standard ASN.1 type intended 1029 for representation of dates and time. UTCTime specifies the year 1030 through the two low order digits and time is specified to the 1031 precision of one minute or one second. UTCTime includes either Z 1032 (for Zulu, or Greenwich Mean Time) or a time differential. 1034 For the purposes of this profile, UTCTime values MUST be expressed 1035 Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are 1036 YYMMDDHHMMSSZ), even where the number of seconds is zero. Conforming 1037 systems MUST interpret the year field (YY) as follows: 1039 Where YY is greater than or equal to 50, the year shall be 1040 interpreted as 19YY; and 1042 Where YY is less than 50, the year shall be interpreted as 20YY. 1044 4.1.2.5.2 GeneralizedTime 1046 The generalized time type, GeneralizedTime, is a standard ASN.1 type 1047 for variable precision representation of time. Optionally, the 1048 GeneralizedTime field can include a representation of the time 1049 differential between local and Greenwich Mean Time. 1051 For the purposes of this profile, GeneralizedTime values MUST be 1052 expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e., 1053 times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. 1054 GeneralizedTime values MUST NOT include fractional seconds. 1056 4.1.2.6 Subject 1058 The subject field identifies the entity associated with the public 1059 key stored in the subject public key field. The subject name may be 1060 carried in the subject field and/or the subjectAltName extension. If 1061 the subject is a CA (e.g., the basic constraints extension, as 1062 discussed in 4.2.1.10, is present and the value of cA is TRUE,) then 1063 the subject field MUST be populated with a non-empty distinguished 1064 name matching the contents of the issuer field (see sec. 4.1.2.4) in 1065 all certificates issued by the subject CA. If subject naming 1066 information is present only in the subjectAltName extension (e.g., a 1067 key bound only to an email address or URI), then the subject name 1068 MUST be an empty sequence and the subjectAltName extension MUST be 1069 critical. 1071 Where it is non-empty, the subject field MUST contain an X.500 1072 distinguished name (DN). The DN MUST be unique for each subject 1073 entity certified by the one CA as defined by the issuer name field. A 1074 CA may issue more than one certificate with the same DN to the same 1075 subject entity. 1077 The subject name field is defined as the X.501 type Name. 1078 Implementation requirements for this field are those defined for the 1079 issuer field (see sec. 4.1.2.4). When encoding attribute values of 1080 type DirectoryString, the encoding rules for the issuer field MUST be 1081 implemented. Implementations of this specification MUST be prepared 1082 to receive subject names containing the attribute types required for 1083 the issuer field. Implementations of this specification SHOULD be 1084 prepared to receive subject names containing the recommended 1085 attribute types for the issuer field. The syntax and associated 1086 object identifiers (OIDs) for these attribute types are provided in 1087 the ASN.1 modules in Appendices A and B. Implementations of this 1088 specification MAY use these comparison rules to process unfamiliar 1089 attribute types (i.e., for name chaining). This allows 1090 implementations to process certificates with unfamiliar attributes in 1091 the subject name. 1093 In addition, legacy implementations exist where an RFC 822 name is 1094 embedded in the subject distinguished name as an EmailAddress 1095 attribute. The attribute value for EmailAddress is of type IA5String 1096 to permit inclusion of the character '@', which is not part of the 1097 PrintableString character set. EmailAddress attribute values are not 1098 case sensitive (e.g., "fanfeedback@redsox.com" is the same as 1099 "FANFEEDBACK@REDSOX.COM"). 1101 Conforming implementations generating new certificates with 1102 electronic mail addresses MUST use the rfc822Name in the subject 1103 alternative name field (see sec. 4.2.1.7) to describe such 1104 identities. Simultaneous inclusion of the EmailAddress attribute in 1105 the subject distinguished name to support legacy implementations is 1106 deprecated but permitted. 1108 4.1.2.7 Subject Public Key Info 1110 This field is used to carry the public key and identify the algorithm 1111 with which the key is used. The algorithm is identified using the 1112 AlgorithmIdentifier structure specified in section 4.1.1.2. The 1113 object identifiers for the supported algorithms and the methods for 1114 encoding the public key materials (public key and parameters) are 1115 specified in [PKIX ALGS]. 1117 4.1.2.8 Unique Identifiers 1119 These fields may only appear if the version is 2 or 3 (see sec. 1120 4.1.2.1). The subject and issuer unique identifiers are present in 1121 the certificate to handle the possibility of reuse of subject and/or 1122 issuer names over time. This profile recommends that names not be 1123 reused for different entities and that Internet certificates not make 1124 use of unique identifiers. CAs conforming to this profile SHOULD NOT 1125 generate certificates with unique identifiers. Applications 1126 conforming to this profile SHOULD be capable of parsing unique 1127 identifiers and making comparisons. 1129 4.1.2.9 Extensions 1131 This field may only appear if the version is 3 (see sec. 4.1.2.1). 1132 If present, this field is a SEQUENCE of one or more certificate 1133 extensions. The format and content of certificate extensions in the 1134 Internet PKI is defined in section 4.2. 1136 4.2 Standard Certificate Extensions 1138 The extensions defined for X.509 v3 certificates provide methods for 1139 associating additional attributes with users or public keys and for 1140 managing the certification hierarchy. The X.509 v3 certificate 1141 format also allows communities to define private extensions to carry 1142 information unique to those communities. Each extension in a 1143 certificate may be designated as critical or non-critical. A 1144 certificate using system MUST reject the certificate if it encounters 1145 a critical extension it does not recognize; however, a non-critical 1146 extension may be ignored if it is not recognized. The following 1147 sections present recommended extensions used within Internet 1148 certificates and standard locations for information. Communities may 1149 elect to use additional extensions; however, caution should be 1150 exercised in adopting any critical extensions in certificates which 1151 might prevent use in a general context. 1153 Each extension includes an OID and an ASN.1 structure. When an 1154 extension appears in a certificate, the OID appears as the field 1155 extnID and the corresponding ASN.1 encoded structure is the value of 1156 the octet string extnValue. Only one instance of a particular 1157 extension may appear in a particular certificate. For example, a 1158 certificate may contain only one authority key identifier extension 1159 (see sec. 4.2.1.1). An extension includes the boolean critical, with 1160 a default value of FALSE. The text for each extension specifies the 1161 acceptable values for the critical field. 1163 Conforming CAs MUST support key identifiers (see sec. 4.2.1.1 and 1164 4.2.1.2), basic constraints (see sec. 4.2.1.10), key usage (see sec. 1165 4.2.1.3), and certificate policies (see sec. 4.2.1.5) extensions. If 1166 the CA issues certificates with an empty sequence for the subject 1167 field, the CA MUST support the subject alternative name extension 1168 (see sec. 4.2.1.7). Support for the remaining extensions is 1169 OPTIONAL. Conforming CAs may support extensions that are not 1170 identified within this specification; certificate issuers are 1171 cautioned that marking such extensions as critical may inhibit 1172 interoperability. 1174 At a minimum, applications conforming to this profile MUST recognize 1175 the following extensions: key usage (see sec. 4.2.1.3), certificate 1176 policies (see sec. 4.2.1.5), the subject alternative name (see sec. 1177 4.2.1.7), basic constraints (see sec. 4.2.1.10), name constraints 1178 (see sec. 4.2.1.11), policy constraints (see sec. 4.2.1.12), extended 1179 key usage (see sec. 4.2.1.13), and inhibit any-policy (see sec. 1180 4.2.1.15). 1182 In addition, this profile RECOMMENDS application support for the 1183 authority and subject key identifier (see sec. 4.2.1.1 and 4.2.1.2), 1184 and policy mapping (see sec. 4.2.1.6) extensions. 1186 4.2.1 Standard Extensions 1188 This section identifies standard certificate extensions defined in 1189 [X.509] for use in the Internet PKI. Each extension is associated 1190 with an OID defined in [X.509]. These OIDs are members of the id-ce 1191 arc, which is defined by the following: 1193 id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 1195 4.2.1.1 Authority Key Identifier 1197 The authority key identifier extension provides a means of 1198 identifying the public key corresponding to the private key used to 1199 sign a certificate. This extension is used where an issuer has 1200 multiple signing keys (either due to multiple concurrent key pairs or 1201 due to changeover). The identification may be based on either the 1202 key identifier (the subject key identifier in the issuer's 1203 certificate) or on the issuer name and serial number. 1205 The keyIdentifier field of the authorityKeyIdentifier extension MUST 1206 be included in all certificates generated by conforming CAs to 1207 facilitate chain building. There is one exception; where a CA 1208 distributes its public key in the form of a "self-signed" 1209 certificate, the authority key identifier may be omitted. In this 1210 case, the subject and authority key identifiers would be identical. 1212 The value of the keyIdentifier field SHOULD be derived from the 1213 public key used to verify the certificate's signature or a method 1214 that generates unique values. Two common methods for generating key 1215 identifiers from the public key are described in (sec. 4.2.1.2). One 1216 common method for generating unique values is described in (sec. 1217 4.2.1.2). Where a key identifier has not been previously 1218 established, this specification recommends use of one of these 1219 methods for generating keyIdentifiers. 1221 This profile recommends support for the key identifier method by all 1222 certificate users. 1224 This extension MUST NOT be marked critical. 1226 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 1228 AuthorityKeyIdentifier ::= SEQUENCE { 1229 keyIdentifier [0] KeyIdentifier OPTIONAL, 1230 authorityCertIssuer [1] GeneralNames OPTIONAL, 1231 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 1233 KeyIdentifier ::= OCTET STRING 1235 4.2.1.2 Subject Key Identifier 1237 The subject key identifier extension provides a means of identifying 1238 certificates that contain a particular public key. 1240 To facilitate chain building, this extension MUST appear in all con- 1241 forming CA certificates, that is, all certificates including the 1242 basic constraints extension (see sec. 4.2.1.10) where the value of cA 1243 is TRUE. The value of the subject key identifier MUST be the value 1244 placed in the key identifier field of the Authority Key Identifier 1245 extension (see sec. 4.2.1.1) of certificates issued by the subject of 1246 this certificate. 1248 For CA certificates, subject key identifiers SHOULD be derived from 1249 the public key or a method that generates unique values. The key 1250 identifier is an explicit value placed in the certificate by the 1251 issuer, not a value generated by a certificate user. Two common 1252 methods for generating key identifiers from the public key are: 1254 (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the 1255 value of the BIT STRING subjectPublicKey (excluding the tag, 1256 length, and number of unused bits). 1258 (2) The keyIdentifier is composed of a four bit type field with 1259 the value 0100 followed by the least significant 60 bits of the 1260 SHA-1 hash of the value of the BIT STRING subjectPublicKey. 1262 One common method for generating unique values is a monotonically 1263 increasing sequence of integers. 1265 For end entity certificates, the subject key identifier extension 1266 provides a means for identifying certificates containing the 1267 particular public key used in an application. Where an end entity has 1268 obtained multiple certificates, especially from multiple CAs, the 1269 subject key identifier provides a means to quickly identify the set 1270 of certificates containing a particular public key. To assist 1271 applications in identifying the appropriate end entity certificate, 1272 this extension SHOULD be included in all end entity certificates. 1274 For end entity certificates, subject key identifiers SHOULD be 1275 derived from the public key. Two common methods for generating key 1276 identifiers from the public key are identifed above. 1278 Where a key identifier has not been previously established, this 1279 specification recommends use of one of these methods for generating 1280 keyIdentifiers. 1282 This extension MUST NOT be marked critical. 1284 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 1286 SubjectKeyIdentifier ::= KeyIdentifier 1288 4.2.1.3 Key Usage 1290 The key usage extension defines the purpose (e.g., encipherment, 1291 signature, certificate signing) of the key contained in the 1292 certificate. The usage restriction might be employed when a key that 1293 could be used for more than one operation is to be restricted. For 1294 example, when an RSA key should be used only for signing, the 1295 digitalSignature and/or nonRepudiation bits would be asserted. 1296 Likewise, when an RSA key should be used only for key management, the 1297 keyEncipherment bit would be asserted. When used, this extension 1298 SHOULD be marked critical. 1300 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 1302 KeyUsage ::= BIT STRING { 1303 digitalSignature (0), 1304 nonRepudiation (1), 1305 keyEncipherment (2), 1306 dataEncipherment (3), 1307 keyAgreement (4), 1308 keyCertSign (5), 1309 cRLSign (6), 1310 encipherOnly (7), 1311 decipherOnly (8) } 1313 Bits in the KeyUsage type are used as follows: 1315 The digitalSignature bit is asserted when the subject public key 1316 is used with a digital signature mechanism to support security 1317 services other than non-repudiation (bit 1), certificate signing 1318 (bit 5), or revocation information signing (bit 6). Digital 1319 signature mechanisms are often used for entity authentication and 1320 data origin authentication with integrity. 1322 The nonRepudiation bit is asserted when the subject public key is 1323 used to verify digital signatures used to provide a non- 1324 repudiation service which protects against the signing entity 1325 falsely denying some action, excluding certificate or CRL signing. 1326 In the case of later conflict, a reliable third party may 1327 determine the authenticity of the signed data. 1329 Further distinctions between the digitalSignature and 1330 nonRepudiation bits may be provided in specific certificate 1331 policies. 1333 The keyEncipherment bit is asserted when the subject public key is 1334 used for key transport. For example, when an RSA key is to be 1335 used for key management, then this bit shall asserted. 1337 The dataEncipherment bit is asserted when the subject public key 1338 is used for enciphering user data, other than cryptographic keys. 1340 The keyAgreement bit is asserted when the subject public key is 1341 used for key agreement. For example, when a Diffie-Hellman key is 1342 to be used for key management, then this bit shall asserted. 1344 The keyCertSign bit is asserted when the subject public key is 1345 used for verifying a signature on certificates. This bit may only 1346 be asserted in CA certificates. If the keyCertSign bit is 1347 asserted, then the cA bit in the basic constraints extension (see 1348 4.2.1.10) MUST also be asserted. If the keyCertSign bit is not 1349 asserted, then the cA bit in the basic constraints extension MUST 1350 NOT be asserted. 1352 The cRLSign bit is asserted when the subject public key is used 1353 for verifying a signature on revocation information (e.g., a CRL). 1355 The meaning of the encipherOnly bit is undefined in the absence of 1356 the keyAgreement bit. When the encipherOnly bit is asserted and 1357 the keyAgreement bit is also set, the subject public key may be 1358 used only for enciphering data while performing key agreement. 1360 The meaning of the decipherOnly bit is undefined in the absence of 1361 the keyAgreement bit. When the decipherOnly bit is asserted and 1362 the keyAgreement bit is also set, the subject public key may be 1363 used only for deciphering data while performing key agreement. 1365 This profile does not restrict the combinations of bits that may be 1366 set in an instantiation of the keyUsage extension. However, 1367 appropriate values for keyUsage extensions for particular algorithms 1368 are specified in [PKIX ALGS]. 1370 4.2.1.4 Private Key Usage Period 1372 This profile recommends against the use of this extension. CAs 1373 conforming to this profile MUST NOT generate certificates with 1374 critical private key usage period extensions. 1376 The private key usage period extension allows the certificate issuer 1377 to specify a different validity period for the private key than the 1378 certificate. This extension is intended for use with digital 1379 signature keys. This extension consists of two optional components, 1380 notBefore and notAfter. The private key associated with the 1381 certificate should not be used to sign objects before or after the 1382 times specified by the two components, respectively. CAs conforming 1383 to this profile MUST NOT generate certificates with private key usage 1384 period extensions unless at least one of the two components is 1385 present. 1387 Where used, notBefore and notAfter are represented as GeneralizedTime 1388 and MUST be specified and interpreted as defined in section 1389 4.1.2.5.2. 1391 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 1393 PrivateKeyUsagePeriod ::= SEQUENCE { 1394 notBefore [0] GeneralizedTime OPTIONAL, 1395 notAfter [1] GeneralizedTime OPTIONAL } 1397 4.2.1.5 Certificate Policies 1399 The certificate policies extension contains a sequence of one or more 1400 policy information terms, each of which consists of an object 1401 identifier (OID) and optional qualifiers. Optional qualifiers, which 1402 may be present, are not expected to change the definition of the 1403 policy. 1405 In an end-entity certificate, these policy information terms indicate 1406 the policy under which the certificate has been issued and the 1407 purposes for which the certificate may be used. In a CA certificate, 1408 these policy information terms limit the set of policies for 1409 certification paths which include this certificate. When a CA does 1410 not wish to limit the set of policies for certification paths which 1411 include this certificate, they may assert the special policy 1412 anyPolicy, with a value of {2 5 29 32 0}. 1414 Applications with specific policy requirements are expected to have a 1415 list of those policies which they will accept and to compare the 1416 policy OIDs in the certificate to that list. If this extension is 1417 critical, the path validation software MUST be able to interpret this 1418 extension (including the optional qualifier), or MUST reject the 1419 certificate. 1421 To promote interoperability, this profile RECOMMENDS that policy 1422 information terms consist of only an OID. Where an OID alone is 1423 insufficient, this profile strongly recommends that use of qualifiers 1424 be limited to those identified in this section. When qualifiers are 1425 used with the special policy anyPolicy, they MUST be limited to the 1426 qualifers identified in this section. 1428 This specification defines two policy qualifier types for use by 1429 certificate policy writers and certificate issuers. The qualifier 1430 types are the CPS Pointer and User Notice qualifiers. 1432 The CPS Pointer qualifier contains a pointer to a Certification 1433 Practice Statement (CPS) published by the CA. The pointer is in the 1434 form of a URI. Processing requirements for this qualifier are a 1435 local matter. No action is mandated by this specification regardless 1436 of the criticality value asserted for the extension. 1438 User notice is intended for display to a relying party when a 1439 certificate is used. The application software SHOULD display all 1440 user notices in all certificates of the certification path used, 1441 except that if a notice is duplicated only one copy need be 1442 displayed. To prevent such duplication, this qualifier SHOULD only 1443 be present in end-entity certificates and CA certificates issued to 1444 other organizations. 1446 The user notice has two optional fields: the noticeRef field and the 1447 explicitText field. 1449 The noticeRef field, if used, names an organization and 1450 identifies, by number, a particular textual statement prepared by 1451 that organization. For example, it might identify the 1452 organization "CertsRUs" and notice number 1. In a typical 1453 implementation, the application software will have a notice file 1454 containing the current set of notices for CertsRUs; the 1455 application will extract the notice text from the file and display 1456 it. Messages may be multilingual, allowing the software to select 1457 the particular language message for its own environment. 1459 An explicitText field includes the textual statement directly in 1460 the certificate. The explicitText field is a string with a 1461 maximum size of 200 characters. 1463 If both the noticeRef and explicitText options are included in the 1464 one qualifier and if the application software can locate the notice 1465 text indicated by the noticeRef option then that text should be 1466 displayed; otherwise, the explicitText string should be displayed. 1468 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 1470 anyPolicy OBJECT IDENTIFIER ::= {id-ce-certificate-policies 0} 1472 certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 1474 PolicyInformation ::= SEQUENCE { 1475 policyIdentifier CertPolicyId, 1476 policyQualifiers SEQUENCE SIZE (1..MAX) OF 1477 PolicyQualifierInfo OPTIONAL } 1479 CertPolicyId ::= OBJECT IDENTIFIER 1480 PolicyQualifierInfo ::= SEQUENCE { 1481 policyQualifierId PolicyQualifierId, 1482 qualifier ANY DEFINED BY policyQualifierId } 1484 -- policyQualifierIds for Internet policy qualifiers 1486 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 1487 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 1488 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 1490 PolicyQualifierId ::= 1491 OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) 1493 Qualifier ::= CHOICE { 1494 cPSuri CPSuri, 1495 userNotice UserNotice } 1497 CPSuri ::= IA5String 1499 UserNotice ::= SEQUENCE { 1500 noticeRef NoticeReference OPTIONAL, 1501 explicitText DisplayText OPTIONAL} 1503 NoticeReference ::= SEQUENCE { 1504 organization DisplayText, 1505 noticeNumbers SEQUENCE OF INTEGER } 1507 DisplayText ::= CHOICE { 1508 ia5String IA5String (SIZE (1..200)), 1509 visibleString VisibleString (SIZE (1..200)), 1510 bmpString BMPString (SIZE (1..200)), 1511 utf8String UTF8String (SIZE (1..200)) } 1513 4.2.1.6 Policy Mappings 1515 This extension is used in CA certificates. It lists one or more 1516 pairs of OIDs; each pair includes an issuerDomainPolicy and a 1517 subjectDomainPolicy. The pairing indicates the issuing CA considers 1518 its issuerDomainPolicy equivalent to the subject CA's 1519 subjectDomainPolicy. 1521 The issuing CA's users may accept an issuerDomainPolicy for certain 1522 applications. The policy mapping tells the issuing CA's users which 1523 policies associated with the subject CA are comparable to the policy 1524 they accept. 1526 Each issuerDomainPolicy named in the the policy mapping extension 1527 should also be asserted in a certificate policies extension in the 1528 same certificate. Policies should not be mapped either to or from 1529 the special value anyPolicy. (See 4.2.1.5 certificate policies). 1531 This extension may be supported by CAs and/or applications, and it 1532 MUST be non-critical. 1534 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 1536 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 1537 issuerDomainPolicy CertPolicyId, 1538 subjectDomainPolicy CertPolicyId } 1540 4.2.1.7 Subject Alternative Name 1542 The subject alternative names extension allows additional identities 1543 to be bound to the subject of the certificate. Defined options 1544 include an Internet electronic mail address, a DNS name, an IP 1545 address, and a uniform resource identifier (URI). Other options 1546 exist, including completely local definitions. Multiple name forms, 1547 and multiple instances of each name form, may be included. Whenever 1548 such identities are to be bound into a certificate, the subject 1549 alternative name (or issuer alternative name) extension MUST be used. 1551 Because the subject alternative name is considered to be definitively 1552 bound to the public key, all parts of the subject alternative name 1553 MUST be verified by the CA. 1555 Further, if the only subject identity included in the certificate is 1556 an alternative name form (e.g., an electronic mail address), then the 1557 subject distinguished name MUST be empty (an empty sequence), and the 1558 subjectAltName extension MUST be present. If the subject field 1559 contains an empty sequence, the subjectAltName extension MUST be 1560 marked critical. 1562 When the subjectAltName extension contains an Internet mail address, 1563 the address MUST be included as an rfc822Name. The format of an 1564 rfc822Name is an "addr-spec" as defined in RFC 822 [RFC 822]. An 1565 addr-spec has the form "local-part@domain". Note that an addr-spec 1566 has no phrase (such as a common name) before it, has no comment (text 1567 surrounded in parentheses) after it, and is not surrounded by "<" and 1568 ">". Note that while upper and lower case letters are allowed in an 1569 RFC 822 addr-spec, no significance is attached to the case. 1571 When the subjectAltName extension contains a iPAddress, the address 1572 MUST be stored in the octet string in "network byte order," as 1573 specified in RFC 791 [RFC 791]. The least significant bit (LSB) of 1574 each octet is the LSB of the corresponding byte in the network 1575 address. For IP Version 4, as specified in RFC 791, the octet string 1576 MUST contain exactly four octets. For IP Version 6, as specified in 1577 RFC 1883, the octet string MUST contain exactly sixteen octets [RFC 1578 1883]. 1580 When the subjectAltName extension contains a domain name service 1581 label, the domain name MUST be stored in the dNSName (an IA5String). 1582 The name MUST be in the "preferred name syntax," as specified by RFC 1583 1034 [RFC 1034]. Note that while upper and lower case letters are 1584 allowed in domain names, no signifigance is attached to the case. In 1585 addition, while the string " " is a legal domain name, subjectAltName 1586 extensions with a dNSName " " are not permitted. Finally, the use of 1587 the DNS representation for Internet mail addresses (wpolk.nist.gov 1588 instead of wpolk@nist.gov) MUST NOT be used; such identities are to 1589 be encoded as rfc822Name. 1591 Note: work is currently underway to specify domain names in 1592 international character sets. This names will likely not be 1593 accomodated by IA5String. Once this work is complete, this profile 1594 will be revisited and the appropriate functionality will be added. 1596 When the subjectAltName extension contains a URI, the name MUST be 1597 stored in the uniformResourceIdentifier (an IA5String). The name MUST 1598 be a non-relative URL, and MUST follow the URL syntax and encoding 1599 rules specified in [RFC 1738]. The name must include both a scheme 1600 (e.g., "http" or "ftp") and a scheme-specific-part. The scheme- 1601 specific-part must include a fully qualified domain name or IP 1602 address as the host. 1604 As specified in [RFC 1738], the scheme name is not case-sensitive 1605 (e.g., "http" is equivalent to "HTTP"). The host part is also not 1606 case-sensitive, but other components of the scheme-specific-part may 1607 be case-sensitive. When comparing URIs, conforming implementations 1608 MUST compare the scheme and host without regard to case, but assume 1609 the remainder of the scheme-specific-part is case sensitive. 1611 When the subjectAltName extension contains a DN in the directoryName, 1612 the DN MUST be unique for each subject entity certified by the one CA 1613 as defined by the issuer name field. A CA may issue more than one 1614 certificate with the same DN to the same subject entity. 1616 The subjectAltName may carry additional name types through the use of 1617 the otherName field. The format and semantics of the name are 1618 indicated through the OBJECT IDENTIFIER in the type-id field. The 1619 name itself is conveyed as value field in otherName. For example, 1620 Kerberos [RFC 1510] format names can be encoded into the otherName, 1621 using the krb5PrincipalName OID and the KerberosName syntax as 1622 defined in [PKINIT]. 1624 Subject alternative names may be constrained in the same manner as 1625 subject distinguished names using the name constraints extension as 1626 described in section 4.2.1.11. 1628 If the subjectAltName extension is present, the sequence MUST contain 1629 at least one entry. Unlike the subject field, conforming CAs MUST 1630 NOT issue certificates with subjectAltNames containing empty 1631 GeneralName fields. For example, an rfc822Name is represented as an 1632 IA5String. While an empty string is a valid IA5String, such an 1633 rfc822Name is not permitted by this profile. The behavior of clients 1634 that encounter such a certificate when processing a certificication 1635 path is not defined by this profile. 1637 Finally, the semantics of subject alternative names that include 1638 wildcard characters (e.g., as a placeholder for a set of names) are 1639 not addressed by this specification. Applications with specific 1640 requirements may use such names but shall define the semantics. 1642 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 1644 SubjectAltName ::= GeneralNames 1646 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 1648 GeneralName ::= CHOICE { 1649 otherName [0] OtherName, 1650 rfc822Name [1] IA5String, 1651 dNSName [2] IA5String, 1652 x400Address [3] ORAddress, 1653 directoryName [4] Name, 1654 ediPartyName [5] EDIPartyName, 1655 uniformResourceIdentifier [6] IA5String, 1656 iPAddress [7] OCTET STRING, 1657 registeredID [8] OBJECT IDENTIFIER} 1659 OtherName ::= SEQUENCE { 1660 type-id OBJECT IDENTIFIER, 1661 value [0] EXPLICIT ANY DEFINED BY type-id } 1663 EDIPartyName ::= SEQUENCE { 1664 nameAssigner [0] DirectoryString OPTIONAL, 1665 partyName [1] DirectoryString } 1667 4.2.1.8 Issuer Alternative Names 1669 As with 4.2.1.7, this extension is used to associate Internet style 1670 identities with the certificate issuer. Issuer alternative names MUST 1671 be encoded as in 4.2.1.7. 1673 Where present, this extension SHOULD NOT be marked critical. 1675 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 1677 IssuerAltName ::= GeneralNames 1679 4.2.1.9 Subject Directory Attributes 1681 The subject directory attributes extension is used to convey 1682 identification attributes (e.g.,nationality) of the subject. The 1683 extension is defined as a sequence of one or more attributes. This 1684 extension MUST be non-critical. 1686 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 1688 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 1690 4.2.1.10 Basic Constraints 1692 The basic constraints extension identifies whether the subject of the 1693 certificate is a CA and how deep a certification path may exist 1694 through that CA. 1696 The cA bit indicates if the certified public key may be used to 1697 verify signatures on other certificates. If the cA bit is asserted, 1698 then the keyCertSign bit in the key usage extension (see 4.2.1.3) 1699 MUST also be asserted. If the cA bit is not asserted, then the 1700 keyCertSign bit in the key usage extension MUST NOT be asserted. 1702 The pathLenConstraint field is meaningful only if cA is set to TRUE. 1703 In this case, it gives the maximum number of CA certificates that may 1704 follow this certificate in a certification path. (Note: The last 1705 certificate may be an end-entity certificate or a CA certificate. 1706 The cA bit, or its absence, determines the type of the last 1707 certificate rather than the application.) A pathLenConstraint of 1708 zero indicates that only an end-entity certificate may follow in the 1709 path. Where it appears, the pathLenConstraint field MUST be greater 1710 than or equal to zero. Where pathLenConstraint does not appear, there 1711 is no limit to the allowed length of the certification path. 1713 This extension MUST appear as a critical extension in all CA 1714 certificates. This extension MAY appear as a critical or non- 1715 critical extension in end entity certificates. 1717 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 1718 BasicConstraints ::= SEQUENCE { 1719 cA BOOLEAN DEFAULT FALSE, 1720 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 1722 4.2.1.11 Name Constraints 1724 The name constraints extension, which MUST be used only in a CA 1725 certificate, indicates a name space within which all subject names in 1726 subsequent certificates in a certification path shall be located. 1727 Restrictions may apply to the subject distinguished name or subject 1728 alternative names. Restrictions apply only when the specified name 1729 form is present. If no name of the type is in the certificate, the 1730 certificate is acceptable. 1732 Name constraints are not applied to certificates whose issuer and 1733 subject are identical. (This could prevent CAs that use name 1734 constraints from issuing self-signed certificates to implement key 1735 rollover.) 1737 Restrictions are defined in terms of permitted or excluded name 1738 subtrees. Any name matching a restriction in the excludedSubtrees 1739 field is invalid regardless of information appearing in the 1740 permittedSubtrees. This extension MUST be critical. 1742 Within this profile, the minimum and maximum fields are not used with 1743 any name forms, thus minimum is always zero, and maximum is always 1744 absent. 1746 For URIs, the constraint applies to the host part of the name. The 1747 constraint may specify a host or a domain. Examples would be 1748 "foo.bar.com"; and ".xyz.com". When the the constraint begins with 1749 a period, it may be expanded with one or more subdomains. That is, 1750 the constraint ".xyz.com" is satisfied by both abc.xyz.com and 1751 abc.def.xyz.com. However, the constraint ".xyz.com" is not satisfied 1752 by "xyz.com". When the constraint does not begin with a period, it 1753 specifies a host. 1755 A name constraint for Internet mail addresses may specify a 1756 particular mailbox, all addresses at a particular host, or all 1757 mailboxes in a domain. To indicate a particular mailbox, the 1758 constraint is the complete mail address. For example, "root@xyz.com" 1759 indicates the root mailbox on the host "xyz.com". To indicate all 1760 Internet mail addresses on a particular host, the constraint is 1761 specified as the host name. For example, the constraint "xyz.com" is 1762 satisfied by any mail address at the host "xyz.com". To specify any 1763 address within a domain, the constraint is specified with a leading 1764 period (as with URIs). For example, ".xyz.com" indicates all the 1765 Internet mail addresses in the domain "xyz.com", but not Internet 1766 mail addresses on the host "xyz.com". 1768 DNS name restrictions are expressed as foo.bar.com. Any DNS name that 1769 can be constructed by simply adding to the left hand side of the name 1770 satisfies the name constraint. For example, www.foo.bar.com would 1771 satisfy the constraint but foo1.bar.com would not. 1773 Legacy implementations exist where an RFC 822 name is embedded in the 1774 subject distinguished name in an attribute of type EmailAddress (see 1775 sec. 4.1.2.6). When rfc822 names are constrained, but the certificate 1776 does not include a subject alternative name, the rfc822 name 1777 constraint MUST be applied to the attribute of type EmailAddress in 1778 the subject distinguished name. The ASN.1 syntax for EmailAddress 1779 and the corresponding OID are supplied in Appendix A and B. 1781 Restrictions of the form directoryName MUST be applied to the subject 1782 field in the certificate and to the subjectAltName extensions of type 1783 directoryName. Restrictions of the form x400Address MUST be applied 1784 to subjectAltName extensions of type x400Address. 1786 When applying restrictions of the form directoryName, an 1787 implementation MUST compare DN attributes. At a minimum, 1788 implementations MUST perform the DN comparison rules specified in 1789 Section 4.1.2.4. CAs issuing certificates with a restriction of the 1790 form directoryName SHOULD NOT rely on implementation of the full ISO 1791 DN name comparison algorithm. This implies name restrictions shall 1792 be stated identically to the encoding used in the subject field or 1793 subjectAltName extension. 1795 The syntax of iPAddress MUST be as described in section 4.2.1.7 with 1796 the following additions specifically for Name Constraints. For IPv4 1797 addresses, the ipAddress field of generalName MUST contain eight (8) 1798 octets, encoded in the style of RFC 1519 (CIDR) to represent an 1799 address range.[RFC 1519] For IPv6 addresses, the ipAddress field 1800 MUST contain 32 octets similarly encoded. For example, a name 1801 constraint for "class C" subnet 10.9.8.0 shall be represented as the 1802 octets 0A 09 08 00 FF FF FF 00, representing the CIDR notation 1803 10.9.8.0/255.255.255.0. 1805 The syntax and semantics for name constraints for otherName, 1806 ediPartyName, and registeredID are not defined by this specification. 1808 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 1810 NameConstraints ::= SEQUENCE { 1811 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 1812 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 1814 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 1816 GeneralSubtree ::= SEQUENCE { 1817 base GeneralName, 1818 minimum [0] BaseDistance DEFAULT 0, 1819 maximum [1] BaseDistance OPTIONAL } 1821 BaseDistance ::= INTEGER (0..MAX) 1823 4.2.1.12 Policy Constraints 1825 The policy constraints extension can be used in certificates issued 1826 to CAs. The policy constraints extension constrains path validation 1827 in two ways. It can be used to prohibit policy mapping or require 1828 that each certificate in a path contain an acceptable policy 1829 identifier. 1831 If the inhibitPolicyMapping field is present, the value indicates the 1832 number of additional certificates that may appear in the path before 1833 policy mapping is no longer permitted. For example, a value of one 1834 indicates that policy mapping may be processed in certificates issued 1835 by the subject of this certificate, but not in additional 1836 certificates in the path. 1838 If the requireExplicitPolicy field is present, subsequent 1839 certificates shall include an acceptable policy identifier. The value 1840 of requireExplicitPolicy indicates the number of additional 1841 certificates that may appear in the path before an explicit policy is 1842 required. An acceptable policy identifier is the identifier of a 1843 policy required by the user of the certification path or the 1844 identifier of a policy which has been declared equivalent through 1845 policy mapping. 1847 Conforming CAs MUST NOT issue certificates where policy constraints 1848 is a null sequence. That is, at least one of the inhibitPolicyMapping 1849 field or the requireExplicitPolicy field MUST be present. The 1850 behavior of clients that encounter a null policy constraints field is 1851 not addressed in this profile. 1853 This extension may be critical or non-critical. 1855 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } 1857 PolicyConstraints ::= SEQUENCE { 1858 requireExplicitPolicy [0] SkipCerts OPTIONAL, 1859 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 1861 SkipCerts ::= INTEGER (0..MAX) 1863 4.2.1.13 Extended key usage field 1865 This field indicates one or more purposes for which the certified 1866 public key may be used, in addition to or in place of the basic 1867 purposes indicated in the key usage extension field. In general, 1868 this extension will appear only in end entity certificates. This 1869 field is defined as follows: 1871 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 1873 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 1875 KeyPurposeId ::= OBJECT IDENTIFIER 1877 Key purposes may be defined by any organization with a need. Object 1878 identifiers used to identify key purposes shall be assigned in 1879 accordance with IANA or ITU-T Rec. X.660 | ISO/IEC/ITU 9834-1. 1881 This extension may, at the option of the certificate issuer, be 1882 either critical or non-critical. 1884 If the extension is flagged critical, then the certificate MUST only 1885 be used for one of the purposes indicated. If multiple purposes are 1886 indicated the application need not recognize all purposes indicated, 1887 as long as the intended purpose is present and recognized. 1889 If the extension is flagged non-critical, then it indicates the 1890 intended purpose or purposes of the key, and may be used in finding 1891 the correct key/certificate of an entity that has multiple 1892 keys/certificates. It is an advisory field and does not imply that 1893 usage of the key is restricted by the certification authority to the 1894 purpose indicated. Certificate using applications may nevertheless 1895 require that a particular purpose be indicated in order for the 1896 certificate to be acceptable to that application. 1898 If a certificate contains both a critical key usage field and a 1899 critical extended key usage field, then both fields MUST be processed 1900 independently and the certificate MUST only be used for a purpose 1901 consistent with both fields. If there is no purpose consistent with 1902 both fields, then the certificate MUST NOT be used for any purpose. 1904 The following key usage purposes are defined by this profile: 1906 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 1908 id-kp-serverAuth OBJECT IDENTIFIER ::= {id-kp 1} 1909 -- TLS Web server authentication 1910 -- Key usage bits that may be consistent: digitalSignature, 1911 -- keyEncipherment or keyAgreement 1912 -- 1913 id-kp-clientAuth OBJECT IDENTIFIER ::= {id-kp 2} 1914 -- TLS Web client authentication 1915 -- Key usage bits that may be consistent: digitalSignature and/or 1916 -- keyAgreement 1917 -- 1918 id-kp-codeSigning OBJECT IDENTIFIER ::= {id-kp 3} 1919 -- Signing of downloadable executable code 1920 -- Key usage bits that may be consistent: digitalSignature 1921 -- 1922 id-kp-emailProtection OBJECT IDENTIFIER ::= {id-kp 4} 1923 -- E-mail protection 1924 -- Key usage bits that may be consistent: digitalSignature, 1925 -- nonRepudiation, and/or (keyEncipherment 1926 -- or keyAgreement) 1927 -- 1928 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 1929 -- Binding the hash of an object to a time from an agreed-upon time 1930 -- source. Key usage bits that may be consistent: digitalSignature, 1931 -- nonRepudiation 1933 4.2.1.14 CRL Distribution Points 1935 The CRL distribution points extension identifies how CRL information 1936 is obtained. The extension SHOULD be non-critical, but this profile 1937 recommends support for this extension by CAs and applications. 1938 Further discussion of CRL management is contained in section 5. 1940 The cRLDistributionPoints extension is a SEQUENCE of 1941 DistributionPoint. A DistributionPoint consists of three fields, 1942 each of which is optional: the name of the DistributionPoint, 1943 ReasonsFlags, and the cRLIssuer. While each component is optional, a 1944 DistributionPoint MUST NOT consist of only the ReasonsFlags field. If 1945 the distributionPoint omits cRLIssuer, the CRL MUST be issued by the 1946 CA that issued the certificate. If the distributionPointName is 1947 absent, cRLIssuer MUST be present and include a Name corresponding to 1948 an X.500 or LDAP directory entry where the CRL is located. 1950 If the cRLDistributionPoints extension contains a 1951 DistributionPointName of type URI, the following semantics MUST be 1952 assumed: the URI is a pointer to the current CRL for the associated 1953 reasons and will be issued by the associated cRLIssuer. The expected 1954 values for the URI are those defined in 4.2.1.7. Processing rules for 1955 other values are not defined by this specification. If the 1956 distributionPoint omits reasons, the CRL MUST include revocations for 1957 all reasons. 1959 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 } 1961 CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 1963 DistributionPoint ::= SEQUENCE { 1964 distributionPoint [0] DistributionPointName OPTIONAL, 1965 reasons [1] ReasonFlags OPTIONAL, 1966 cRLIssuer [2] GeneralNames OPTIONAL } 1968 DistributionPointName ::= CHOICE { 1969 fullName [0] GeneralNames, 1970 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 1972 ReasonFlags ::= BIT STRING { 1973 unused (0), 1974 keyCompromise (1), 1975 cACompromise (2), 1976 affiliationChanged (3), 1977 superseded (4), 1978 cessationOfOperation (5), 1979 certificateHold (6) } 1981 4.2.1.15 Inhibit Any-Policy 1983 The inhibit any-policy extension can be used in certificates issued 1984 to CAs. The inhibit any-policy indicates that the special any-policy 1985 OID, with the value {2 5 29 32 0}, is not considered an explicit 1986 match for other certificate policies. The value indicates the number 1987 of additional certificates that may appear in the path before any- 1988 policy is no longer permitted. For example, a value of one indicates 1989 that any-policy may be processed in certificates issued by the 1990 subject of this certificate, but not in additional certificates in 1991 the path. 1993 This extension MUST be critical. 1995 id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 } 1997 InhibitAnyPolicy ::= SkipCerts 1999 SkipCerts ::= INTEGER (0..MAX) 2001 4.2.1.16 Freshest CRL (a.k.a. Delta CRL Distribution Point) 2003 The freshest CRL extension identifies how delta-CRL information is 2004 obtained. The extension MUST be non-critical. Further discussion of 2005 CRL management is contained in section 5. 2007 The same syntax is used for this extension and the 2008 cRLDistributionPoints extension, and is described in section 2009 4.2.1.14. The same conventions apply to both extensions. 2011 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } 2013 FreshestCRL ::= CRLDistributionPoints 2015 4.2.2 Private Internet Extensions 2017 This section defines one new extension for use in the Internet Public 2018 Key Infrastructure. This extension may be used to direct 2019 applications to identify an on-line validation service supporting the 2020 issuing CA. As the information may be available in multiple forms, 2021 each extension is a sequence of IA5String values, each of which 2022 represents a URI. The URI implicitly specifies the location and 2023 format of the information and the method for obtaining the 2024 information. 2026 An object identifier is defined for the private extension. The 2027 object identifier associated with the private extension is defined 2028 under the arc id-pe within the id-pkix name space. Any future 2029 extensions defined for the Internet PKI will also be defined under 2030 the arc id-pe. 2032 id-pkix OBJECT IDENTIFIER ::= 2033 { iso(1) identified-organization(3) dod(6) internet(1) 2034 security(5) mechanisms(5) pkix(7) } 2036 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 2038 4.2.2.1 Authority Information Access 2040 The authority information access extension indicates how to access CA 2041 information and services for the issuer of the certificate in which 2042 the extension appears. Information and services may include on-line 2043 validation services and CA policy data. (The location of CRLs is not 2044 specified in this extension; that information is provided by the 2045 cRLDistributionPoints extension.) This extension may be included in 2046 subject or CA certificates, and it MUST be non-critical. 2048 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 2050 AuthorityInfoAccessSyntax ::= 2051 SEQUENCE SIZE (1..MAX) OF AccessDescription 2053 AccessDescription ::= SEQUENCE { 2054 accessMethod OBJECT IDENTIFIER, 2055 accessLocation GeneralName } 2057 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 2059 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 2061 Each entry in the sequence AuthorityInfoAccessSyntax describes the 2062 format and location of additional information provided by the CA who 2063 issued the certificate in which this extension appears. The type and 2064 format of the information is specified by the accessMethod field; the 2065 accessLocation field specifies the location of the information. The 2066 retrieval mechanism may be implied by the accessMethod or specified 2067 by accessLocation. 2069 This profile defines one OID for accessMethod. The id-ad-caIssuers 2070 OID is used when the additional information lists CAs that have 2071 issued certificates superior to the CA that issued the certificate 2072 containing this extension. The referenced CA Issuers description is 2073 intended to aid certificate users in the selection of a certification 2074 path that terminates at a point trusted by the certificate user. 2076 When id-ad-caIssuers appears as accessInfoType, the accessLocation 2077 field describes the referenced description server and the access 2078 protocol to obtain the referenced description. The accessLocation 2079 field is defined as a GeneralName, which can take several forms. 2080 Where the information is available via http, ftp, or ldap, 2081 accessLocation MUST be a uniformResourceIdentifier. Where the 2082 information is available via the directory access protocol (dap), 2083 accessLocation MUST be a directoryName. When the information is 2084 available via electronic mail, accessLocation MUST be an rfc822Name. 2085 The semantics of other name forms of accessLocation (when 2086 accessMethod is id-ad-caIssuers) are not defined by this 2087 specification. 2089 [RFC 2560] defines the access descriptor for the Online Certificate 2090 Status Protocol. When this access descriptor appears in the 2091 authority information access extension, this indicates the issuer 2092 provides revocation information for this certificate through the 2093 named OCSP service. Additional access descriptors may be defined in 2094 other PKIX specifications. 2096 4.2.2.2 Subject Information Access 2098 The subject information access extension indicates how to access 2099 information and services for the subject of the certificate in which 2100 the extension appears. When the subject is a CA, information and 2101 services may include certificate validation services and CA policy 2102 data. When the subject is an end entity, the information describes 2103 the type of services offered and how to access them. In this case, 2104 the contents of this extension are defined in the protocol 2105 specifications for the suported services. This extension may be 2106 included in subject or CA certificates, and it MUST be non-critical. 2108 id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 } 2110 SubjectInfoAccessSyntax ::= 2111 SEQUENCE SIZE (1..MAX) OF AccessDescription 2113 AccessDescription ::= SEQUENCE { 2114 accessMethod OBJECT IDENTIFIER, 2115 accessLocation GeneralName } 2117 Each entry in the sequence SubjectInfoAccessSyntax describes the 2118 format and location of additional information provided by the subject 2119 of the certificate in which this extension appears. The type and 2120 format of the information is specified by the accessMethod field; the 2121 accessLocation field specifies the location of the information. The 2122 retrieval mechanism may be implied by the accessMethod or specified 2123 by accessLocation. 2125 This profile defines one access method to be used when the subject is 2126 a CA, and one access method to be used when the subject is an end 2127 entity. Additional access methods may be defined in the future in 2128 the protocol specifications for other services. 2130 The id-ad-caRepository OID is used when the subject is a CA, and 2131 publishes its certificates and CRLs (if issued) in a repository. The 2132 accessLocation field is defined as a GeneralName, which can take 2133 several forms. Where the information is available via http, ftp, or 2134 ldap, accessLocation MUST be a uniformResourceIdentifier. Where the 2135 information is available via the directory access protocol (dap), 2136 accessLocation MUST be a directoryName. When the information is 2137 available via electronic mail, accessLocation MUST be an rfc822Name. 2138 The semantics of other name forms of of accessLocation (when 2139 accessMethod is id-ad-caRepository) are not defined by this 2140 specification. 2142 The id-ad-timeStamping OID is used when the subject offers 2143 timestamping services using the Time Stamp Protocol defined in [PKIX 2144 TSA]. Where the timestamping services are available via http or ftp, 2145 accessLocation MUST be a uniformResourceIdentifier. Where the 2146 timestamping services are available via electronic mail, 2147 accessLocation MUST be an rfc822Name. Where timestamping services 2148 are available using TCP/IP, the dNSName and ipAddress name forms may 2149 be used. The semantics of other name forms of accessLocation (when 2150 accessMethod is id-ad-timeStamping) are not defined by this 2151 specification. 2153 Additional access descriptors may be defined in other PKIX 2154 specifications. 2156 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 2158 id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 } 2160 id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 } 2162 5 CRL and CRL Extensions Profile 2164 As described above, one goal of this X.509 v2 CRL profile is to 2165 foster the creation of an interoperable and reusable Internet PKI. 2166 To achieve this goal, guidelines for the use of extensions are 2167 specified, and some assumptions are made about the nature of 2168 information included in the CRL. 2170 CRLs may be used in a wide range of applications and environments 2171 covering a broad spectrum of interoperability goals and an even 2172 broader spectrum of operational and assurance requirements. This 2173 profile establishes a common baseline for generic applications 2174 requiring broad interoperability. The profile defines a baseline set 2175 of information that can be expected in every CRL. Also, the profile 2176 defines common locations within the CRL for frequently used 2177 attributes as well as common representations for these attributes. 2179 This profile does not define any private Internet CRL extensions or 2180 CRL entry extensions. 2182 Environments with additional or special purpose requirements may 2183 build on this profile or may replace it. 2185 Conforming CAs are not required to issue CRLs if other revocation or 2186 certificate status mechanisms are provided. Conforming CAs that 2187 issue CRLs MUST issue version 2 CRLs, and CAs MUST include the date 2188 by which the next CRL will be issued in the nextUpdate field (see 2189 sec. 5.1.2.5), the CRL number extension (see sec. 5.2.3) and the 2190 authority key identifier extension (see sec. 5.2.1). Conforming 2191 applications are required to process version 1 and 2 CRLs. 2193 5.1 CRL Fields 2195 The X.509 v2 CRL syntax is as follows. For signature calculation, 2196 the data that is to be signed is ASN.1 DER encoded. ASN.1 DER 2197 encoding is a tag, length, value encoding system for each element. 2199 CertificateList ::= SEQUENCE { 2200 tbsCertList TBSCertList, 2201 signatureAlgorithm AlgorithmIdentifier, 2202 signatureValue BIT STRING } 2204 TBSCertList ::= SEQUENCE { 2205 version Version OPTIONAL, 2206 -- if present, shall be v2 2207 signature AlgorithmIdentifier, 2208 issuer Name, 2209 thisUpdate Time, 2210 nextUpdate Time OPTIONAL, 2211 revokedCertificates SEQUENCE OF SEQUENCE { 2212 userCertificate CertificateSerialNumber, 2213 revocationDate Time, 2214 crlEntryExtensions Extensions OPTIONAL 2215 -- if present, shall be v2 2216 } OPTIONAL, 2217 crlExtensions [0] EXPLICIT Extensions OPTIONAL 2218 -- if present, shall be v2 2219 } 2221 -- Version, Time, CertificateSerialNumber, and Extensions 2222 -- are all defined in the ASN.1 in section 4.1 2224 -- AlgorithmIdentifier is defined in section 4.1.1.2 2226 The following items describe the use of the X.509 v2 CRL in the 2227 Internet PKI. 2229 5.1.1 CertificateList Fields 2231 The CertificateList is a SEQUENCE of three required fields. The 2232 fields are described in detail in the following subsections. 2234 5.1.1.1 tbsCertList 2236 The first field in the sequence is the tbsCertList. This field is 2237 itself a sequence containing the name of the issuer, issue date, 2238 issue date of the next list, the optional list of revoked 2239 certificates, and optional CRL extensions. When there are no revoked 2240 certificates, the revoked certificates list is absent. When one or 2241 more certificates are revoked, each entry on the revoked certificate 2242 list is defined by a sequence of user certificate serial number, 2243 revocation date, and optional CRL entry extensions. 2245 5.1.1.2 signatureAlgorithm 2247 The signatureAlgorithm field contains the algorithm identifier for 2248 the algorithm used by the CA to sign the CertificateList. The field 2249 is of type AlgorithmIdentifier, which is defined in section 4.1.1.2. 2250 [PKIX ALGS] lists the supported algorithms for this specification. 2251 Conforming CAs MUST use the algorithm identifiers presented in [PKIX 2252 ALGS] when signing with a supported signature algorithm. 2254 This field MUST contain the same algorithm identifier as the 2255 signature field in the sequence tbsCertList (see sec. 5.1.2.2). 2257 5.1.1.3 signatureValue 2259 The signatureValue field contains a digital signature computed upon 2260 the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded tbsCertList 2261 is used as the input to the signature function. This signature value 2262 is then ASN.1 encoded as a BIT STRING and included in the CRL's 2263 signatureValue field. The details of this process are specified for 2264 each of the supported algorithms in [PKIX ALGS]. 2266 5.1.2 Certificate List "To Be Signed" 2268 The certificate list to be signed, or TBSCertList, is a SEQUENCE of 2269 required and optional fields. The required fields identify the CRL 2270 issuer, the algorithm used to sign the CRL, the date and time the CRL 2271 was issued, and the date and time by which the CA will issue the next 2272 CRL. 2274 Optional fields include lists of revoked certificates and CRL 2275 extensions. The revoked certificate list is optional to support the 2276 case where a CA has not revoked any unexpired certificates that it 2277 has issued. The profile requires conforming CAs to use the CRL 2278 extension cRLNumber in all CRLs issued. 2280 5.1.2.1 Version 2282 This optional field describes the version of the encoded CRL. When 2283 extensions are used, as required by this profile, this field MUST be 2284 present and MUST specify version 2 (the integer value is 1). 2286 5.1.2.2 Signature 2288 This field contains the algorithm identifier for the algorithm used 2289 to sign the CRL. [PKIX ALGS] lists OIDs for the most popular 2290 signature algorithms used in the Internet PKI. 2292 This field MUST contain the same algorithm identifier as the 2293 signatureAlgorithm field in the sequence CertificateList (see section 2294 5.1.1.2). 2296 5.1.2.3 Issuer Name 2298 The issuer name identifies the entity who has signed and issued the 2299 CRL. The issuer identity is carried in the issuer name field. 2300 Alternative name forms may also appear in the issuerAltName extension 2301 (see sec. 5.2.2). The issuer name field MUST contain an X.500 2302 distinguished name (DN). The issuer name field is defined as the 2303 X.501 type Name, and MUST follow the encoding rules for the issuer 2304 name field in the certificate (see sec. 4.1.2.4). 2306 5.1.2.4 This Update 2308 This field indicates the issue date of this CRL. ThisUpdate may be 2309 encoded as UTCTime or GeneralizedTime. 2311 CAs conforming to this profile that issue CRLs MUST encode thisUpdate 2312 as UTCTime for dates through the year 2049. CAs conforming to this 2313 profile that issue CRLs MUST encode thisUpdate as GeneralizedTime for 2314 dates in the year 2050 or later. 2316 Where encoded as UTCTime, thisUpdate MUST be specified and 2317 interpreted as defined in section 4.1.2.5.1. Where encoded as 2318 GeneralizedTime, thisUpdate MUST be specified and interpreted as 2319 defined in section 4.1.2.5.2. 2321 5.1.2.5 Next Update 2323 This field indicates the date by which the next CRL will be issued. 2324 The next CRL could be issued before the indicated date, but it will 2325 not be issued any later than the indicated date. CAs SHOULD issue 2326 CRLs with a nextUpdate time equal to or later than all previous CRLs. 2327 nextUpdate may be encoded as UTCTime or GeneralizedTime. 2329 This profile requires inclusion of nextUpdate in all CRLs issued by 2330 conforming CAs. Note that the ASN.1 syntax of TBSCertList describes 2331 this field as OPTIONAL, which is consistent with the ASN.1 structure 2332 defined in [X.509]. The behavior of clients processing CRLs which 2333 omit nextUpdate is not specified by this profile. 2335 CAs conforming to this profile that issue CRLs MUST encode nextUpdate 2336 as UTCTime for dates through the year 2049. CAs conforming to this 2337 profile that issue CRLs MUST encode nextUpdate as GeneralizedTime for 2338 dates in the year 2050 or later. 2340 Where encoded as UTCTime, nextUpdate MUST be specified and 2341 interpreted as defined in section 4.1.2.5.1. Where encoded as 2342 GeneralizedTime, nextUpdate MUST be specified and interpreted as 2343 defined in section 4.1.2.5.2. 2345 5.1.2.6 Revoked Certificates 2347 When there are no revoked certificates, the revoked certificates list 2348 is absent. Otherwise, revoked certificates are listed by their 2349 serial numbers. Certificates revoked by the CA are uniquely 2350 identified by the certificate serial number. The date on which the 2351 revocation occurred is specified. The time for revocationDate MUST 2352 be expressed as described in section 5.1.2.4. Additional information 2353 may be supplied in CRL entry extensions; CRL entry extensions are 2354 discussed in section 5.3. 2356 5.1.2.7 Extensions 2358 This field may only appear if the version is 2 (see sec. 5.1.2.1). 2359 If present, this field is a SEQUENCE of one or more CRL extensions. 2360 CRL extensions are discussed in section 5.2. 2362 5.2 CRL Extensions 2364 The extensions defined by ANSI X9 and ISO/IEC/ITU for X.509 v2 CRLs 2365 [X.509] [X9.55] provide methods for associating additional attributes 2366 with CRLs. The X.509 v2 CRL format also allows communities to define 2367 private extensions to carry information unique to those communities. 2368 Each extension in a CRL may be designated as critical or non- 2369 critical. A CRL validation MUST fail if it encounters a critical 2370 extension which it does not know how to process. However, an 2371 unrecognized non-critical extension may be ignored. The following 2372 subsections present those extensions used within Internet CRLs. 2373 Communities may elect to include extensions in CRLs which are not 2374 defined in this specification. However, caution should be exercised 2375 in adopting any critical extensions in CRLs which might be used in a 2376 general context. 2378 Conforming CAs that issue CRLs are required to include the authority 2379 key identifier (see sec. 5.2.1) and the CRL number (see sec. 5.2.3) 2380 extensions in all CRLs issued. 2382 5.2.1 Authority Key Identifier 2384 The authority key identifier extension provides a means of 2385 identifying the public key corresponding to the private key used to 2386 sign a CRL. The identification can be based on either the key 2387 identifier (the subject key identifier in the CRL signer's 2388 certificate) or on the issuer name and serial number. This extension 2389 is especially useful where an issuer has more than one signing key, 2390 either due to multiple concurrent key pairs or due to changeover. 2392 Conforming CAs MUST use the key identifier method, and MUST include 2393 this extension in all CRLs issued. 2395 The syntax for this CRL extension is defined in section 4.2.1.1. 2397 5.2.2 Issuer Alternative Name 2399 The issuer alternative names extension allows additional identities 2400 to be associated with the issuer of the CRL. Defined options include 2401 an rfc822 name (electronic mail address), a DNS name, an IP address, 2402 and a URI. Multiple instances of a name and multiple name forms may 2403 be included. Whenever such identities are used, the issuer 2404 alternative name extension MUST be used. 2406 The issuerAltName extension SHOULD NOT be marked critical. 2408 The OID and syntax for this CRL extension are defined in section 2409 4.2.1.8. 2411 5.2.3 CRL Number 2413 The CRL number is a non-critical CRL extension which conveys a 2414 monotonically increasing sequence number for each CRL issued by a CA. 2415 This extension allows users to easily determine when a particular CRL 2416 supersedes another CRL. CAs conforming to this profile MUST include 2417 this extension in all CRLs. 2419 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 2421 cRLNumber ::= INTEGER (0..MAX) 2423 5.2.4 Delta CRL Indicator 2425 The delta CRL indicator is a critical CRL extension that identifies a 2426 CRL as being a delta CRL. Delta CRLs contain updates to revocation 2427 information previously distributed, rather than all the information 2428 that would appear in a complete CRL. The use of delta CRLs can 2429 significantly reduce network load and processing time in some 2430 environments. Delta CRLs are generally smaller than the CRLs they 2431 update, so applications that obtain delta CRLs consume less network 2432 bandwidth than applications that obtain the corresponding complete 2433 CRLs. Applications which store revocation information in a format 2434 other than the CRL structure can add new revocation information to 2435 the local database without reprocessing information. 2437 The delta CRL indicator extension contains a single value of type 2438 BaseCRLNumber. This value identifies the CRL number of the base CRL 2439 that was used as the foundation in the generation of this delta CRL. 2440 The referenced base CRL is a CRL that was explicitly issued as a CRL 2441 that is complete for a given scope (e.g., a set of revocation reasons 2442 or a particular distribution point.) The CRL containing the delta CRL 2443 indicator extension contains all updates to the certificate 2444 revocation status for that same scope. The combination of a CRL 2445 containing the delta CRL indicator extension plus the CRL referenced 2446 in the BaseCRLNumber component of this extension is equivalent to a 2447 full CRL, for the applicable scope, at the time of publication of the 2448 delta CRL. 2450 When a conforming CA issues a delta CRL, the CA MUST also issue a CRL 2451 that is complete for the given scope. Both the delta CRL and the 2452 complete CRL MUST include the CRL number extension (see sec. 5.2.3). 2453 The CRL number extension in the delta CRL and the complete CRL MUST 2454 contain the same value. When a delta CRL is issued, it MUST cover 2455 the same set of reasons and same set of certificates that were 2456 covered by the base CRL it references. 2458 An application can construct a CRL that is complete for a given 2459 scope, at the current time, in either of the following ways: 2461 (a) by retrieving the current delta CRL for that scope, and 2462 combining it with an issued CRL that is complete for that scope 2463 and that has a cRLNumber greater than or equal to the cRLNumber of 2464 the base CRL referenced in the delta CRL; or 2466 (b) by retrieving the current delta CRL for that scope and 2467 combining it with a locally constructed CRL whose cRLNumber is 2468 greater than or equal to the cRLNumber of the base CRL referenced 2469 in the current delta CRL. 2471 The constructed CRL has the CRL number specified in the CRL number 2472 extension found in the delta CRL used in its construction. 2474 CAs must ensure that application of a delta CRL to the referenced 2475 base revocation information accurately reflects the current status of 2476 revocation. If a CA supports the certificateHold revocation reason 2477 the following rules must be applied when generating delta CRLs: 2479 (a) If a certificate was listed as revoked with revocation reason 2480 certificateHold on a CRL (either a delta CRL or a CRL that is 2481 complete for a given scope), whose cRLNumber is n, and the hold is 2482 subsequently released, the certificate must be included in all 2483 delta CRLs issued after the hold is released where the cRLNumber 2484 of the referenced base CRL is less than or equal to n. The 2485 certificate must be listed with revocation reason removeFromCRL 2486 unless the certificate is subsequently revoked again for one of 2487 the revocation reasons covered by the delta CRL, in which case the 2488 certificate must be listed with the revocation reason appropriate 2489 for the subsequent revocation. 2491 (b) If the certificate was not removed from hold, but was 2492 permanently revoked, then it must be listed on all subsequent 2493 delta CRLs where the cRLNumber of the referenced base CRL is less 2494 than the cRLNumber of the CRL (either a delta CRL or a CRL that is 2495 complete for the given scope) on which the permanent revocation 2496 notice first appeared. 2498 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 2500 deltaCRLIndicator EXTENSION ::= { 2501 SYNTAX BaseCRLNumber 2502 IDENTIFIED BY id-ce-deltaCRLIndicator } 2504 BaseCRLNumber ::= CRLNumber 2506 5.2.5 Issuing Distribution Point 2508 The issuing distribution point is a critical CRL extension that 2509 identifies the CRL distribution point for a particular CRL, and it 2510 indicates whether the CRL covers revocation for end entity 2511 certificates only, CA certificates only, or a limited set of reason 2512 codes. Although the extension is critical, conforming 2513 implementations are not required to support this extension. 2515 The CRL is signed using the CA's private key. CRL Distribution 2516 Points do not have their own key pairs. If the CRL is stored in the 2517 X.500 Directory, it is stored in the Directory entry corresponding to 2518 the CRL distribution point, which may be different than the Directory 2519 entry of the CA. 2521 The reason codes associated with a distribution point shall be 2522 specified in onlySomeReasons. If onlySomeReasons does not appear, the 2523 distribution point shall contain revocations for all reason codes. 2524 CAs may use CRL distribution points to partition the CRL on the basis 2525 of compromise and routine revocation. In this case, the revocations 2526 with reason code keyCompromise (1) and cACompromise (2) appear in one 2527 distribution point, and the revocations with other reason codes 2528 appear in another distribution point. 2530 Where the issuingDistributionPoint extension contains a URL, the 2531 following semantics MUST be assumed: the object is a pointer to the 2532 most current CRL issued by this CA. The URI schemes ftp, http, 2533 mailto [RFC1738] and ldap [RFC1778] are defined for this purpose. 2534 The URI MUST be an absolute, not relative, pathname and MUST specify 2535 the host. 2537 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 2539 issuingDistributionPoint ::= SEQUENCE { 2540 distributionPoint [0] DistributionPointName OPTIONAL, 2541 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 2542 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 2543 onlySomeReasons [3] ReasonFlags OPTIONAL, 2544 indirectCRL [4] BOOLEAN DEFAULT FALSE } 2546 5.2.6 Freshest CRL (a.k.a. Delta CRL Distribution Point) 2548 The freshest CRL extension identifies how delta-CRL information for 2549 this CRL is obtained. The extension MUST be non-critical. 2551 The same syntax is used for this extension as the 2552 cRLDistributionPoints certificate extension, and is described in 2553 section 4.2.1.14. The same conventions apply to both extensions. 2555 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } 2557 FreshestCRL ::= CRLDistributionPoints 2559 5.3 CRL Entry Extensions 2561 The CRL entry extensions already defined by ANSI X9 and ISO/IEC/ITU 2562 for X.509 v2 CRLs provide methods for associating additional 2563 attributes with CRL entries [X.509] [X9.55]. The X.509 v2 CRL format 2564 also allows communities to define private CRL entry extensions to 2565 carry information unique to those communities. Each extension in a 2566 CRL entry may be designated as critical or non-critical. A CRL 2567 validation MUST fail if it encounters a critical CRL entry extension 2568 which it does not know how to process. However, an unrecognized 2569 non-critical CRL entry extension may be ignored. The following 2570 subsections present recommended extensions used within Internet CRL 2571 entries and standard locations for information. Communities may 2572 elect to use additional CRL entry extensions; however, caution should 2573 be exercised in adopting any critical extensions in CRL entries which 2574 might be used in a general context. 2576 All CRL entry extensions used in this specification are non-critical. 2577 Support for these extensions is optional for conforming CAs and 2578 applications. However, CAs that issue CRLs SHOULD include reason 2579 codes (see sec. 5.3.1) and invalidity dates (see sec. 5.3.3) whenever 2580 this information is available. 2582 5.3.1 Reason Code 2584 The reasonCode is a non-critical CRL entry extension that identifies 2585 the reason for the certificate revocation. CAs are strongly 2586 encouraged to include meaningful reason codes in CRL entries; 2587 however, the reason code CRL entry extension SHOULD be absent instead 2588 of using the unspecified (0) reasonCode value. 2590 id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 } 2592 -- reasonCode ::= { CRLReason } 2594 CRLReason ::= ENUMERATED { 2595 unspecified (0), 2596 keyCompromise (1), 2597 cACompromise (2), 2598 affiliationChanged (3), 2599 superseded (4), 2600 cessationOfOperation (5), 2601 certificateHold (6), 2602 removeFromCRL (8) } 2604 5.3.2 Hold Instruction Code 2606 The hold instruction code is a non-critical CRL entry extension that 2607 provides a registered instruction identifier which indicates the 2608 action to be taken after encountering a certificate that has been 2609 placed on hold. 2611 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 2613 holdInstructionCode ::= OBJECT IDENTIFIER 2615 The following instruction codes have been defined. Conforming 2616 applications that process this extension MUST recognize the following 2617 instruction codes. 2619 holdInstruction OBJECT IDENTIFIER ::= 2620 { iso(1) member-body(2) us(840) x9-57(10040) 2 } 2622 id-holdinstruction-none OBJECT IDENTIFIER ::= {holdInstruction 1} 2623 id-holdinstruction-callissuer 2624 OBJECT IDENTIFIER ::= {holdInstruction 2} 2625 id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3} 2627 Conforming applications which encounter an id-holdinstruction- 2628 callissuer MUST call the certificate issuer or reject the 2629 certificate. Conforming applications which encounter an id- 2630 holdinstruction-reject MUST reject the certificate. The hold 2631 instruction id-holdinstruction-none is semantically equivalent to the 2632 absence of a holdInstructionCode, and its use is strongly deprecated 2633 for the Internet PKI. 2635 5.3.3 Invalidity Date 2637 The invalidity date is a non-critical CRL entry extension that 2638 provides the date on which it is known or suspected that the private 2639 key was compromised or that the certificate otherwise became invalid. 2640 This date may be earlier than the revocation date in the CRL entry, 2641 which is the date at which the CA processed the revocation. When a 2642 revocation is first posted by a CA in a CRL, the invalidity date may 2643 precede the date of issue of earlier CRLs, but the revocation date 2644 SHOULD NOT precede the date of issue of earlier CRLs. Whenever this 2645 information is available, CAs are strongly encouraged to share it 2646 with CRL users. 2648 The GeneralizedTime values included in this field MUST be expressed 2649 in Greenwich Mean Time (Zulu), and MUST be specified and interpreted 2650 as defined in section 4.1.2.5.2. 2652 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 2654 invalidityDate ::= GeneralizedTime 2656 5.3.4 Certificate Issuer 2658 This CRL entry extension identifies the certificate issuer associated 2659 with an entry in an indirect CRL, i.e. a CRL that has the indirectCRL 2660 indicator set in its issuing distribution point extension. If this 2661 extension is not present on the first entry in an indirect CRL, the 2662 certificate issuer defaults to the CRL issuer. On subsequent entries 2663 in an indirect CRL, if this extension is not present, the certificate 2664 issuer for the entry is the same as that for the preceding entry. 2665 This field is defined as follows: 2667 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } 2669 certificateIssuer ::= GeneralNames 2671 If used by conforming CAs that issue CRLs, this extension MUST always 2672 be critical. If an implementation ignored this extension it could 2673 not correctly attribute CRL entries to certificates. This 2674 specification RECOMMENDS that implementations recognize this 2675 extension. 2677 6 Certification Path Validation 2679 Certification path validation procedures for the Internet PKI are 2680 based on the algorithm supplied in [X.509]. Certification path 2681 processing verifies the binding between the subject distinguished 2682 name and/or subject alternative name and subject public key. The 2683 binding is limited by constraints which are specified in the 2684 certificates which comprise the path and inputs which are specified 2685 by the relying party. The basic constraints and policy constraints 2686 extensions allow the certification path processing logic to automate 2687 the decision making process. 2689 This section describes an algorithm for validating certification 2690 paths. Conforming implementations of this specification are not 2691 required to implement this algorithm, but MUST provide functionality 2692 equivalent to the external behavior resulting from this procedure. 2693 Any algorithm may be used by a particular implementation so long as 2694 it derives the correct result. 2696 In section 6.1, the text describes basic path validation. Valid paths 2697 begin with certificates issued by a "most-trusted CA". The algorithm 2698 requires the public key of the CA, the CA's name, and any constraints 2699 upon the set of paths which may be validated using this key. 2701 The selection of a "most-trusted CA" is a matter of policy: it could 2702 be the top CA in a hierarchical PKI; the CA that issued the 2703 verifier's own certificate(s); or any other CA in a network PKI. The 2704 path validation procedure is the same regardless of the choice of 2705 "most-trusted CA." In addition, different applications may rely on 2706 different "most-trusted CA", or may accept paths that begin with any 2707 of a set of "most-trusted CAs." 2709 Section 6.2 describes methods for using the path validation algorithm 2710 in specific implementations. Two specific cases are discussed: the 2711 case where paths may begin with one of several trusted CAs; and where 2712 compatibility with the PEM architecture is required. 2714 Section 6.3 describes the steps necessary to determine if a 2715 certificate is revoked or on hold status when CRLs are the revocation 2716 mechanism used by the certificate issuer. 2718 6.1 Basic Path Validation 2720 This text describes an algorithm for X.509 path processing. A 2721 conformant implementation MUST include an X.509 path processing 2722 procedure that is functionally equivalent to the external behavior of 2723 this algorithm. However, some of the certificate fields processed in 2724 this algorithm are optional for compliant implementations. Clients 2725 that do not support these fields may omit the corresponding steps in 2726 the path validation algorithm. 2728 For example, clients are not required to support the policy mapping 2729 extension. Clients that do not support this extension may omit the 2730 path validation steps where policy mappings are processed. Note that 2731 clients MUST reject the certificate if it contains critical 2732 extensions that are not supported. 2734 This text describes the trust anchor as an input to the algorithm. 2735 There is no requirement that the same trust anchor be used to 2736 validate all certification paths. Different trust anchors may be 2737 used to validate different paths, as discussed further in Section 2738 6.2. 2740 The primary goal of path validation is to verify the binding between 2741 a subject distinguished name or subject alternative name and subject 2742 public key, as represented in the end entity certificate, based on 2743 the public key of the trust anchor. This requires obtaining a 2744 sequence of certificates that support that binding. The procedure 2745 performed to obtain this sequence of certificates is outside the 2746 scope of this section. 2748 To meet this goal, the path validation process verifies, among other 2749 things, that a prospective certification path (a sequence of n 2750 certificates) satisfies the following conditions: 2752 (a) for all x in {1, ..., n-1}, the subject of certificate x is 2753 the issuer of certificate x+1; 2755 (b) certificate 1 is issued by the trust anchor; 2757 (c) certificate n is the end entity certificate; and 2759 (d) for all x in {1, ..., n}, the certificate was valid at the 2760 time in question. 2762 A particular certification path may not, however, be appropriate for 2763 all applications. The path validation process also determines the 2764 set of certificate policies that are valid for this path, based on 2765 the certificate policies extension, policy mapping extension, policy 2766 constraints extension, and inhibit any-policy extension. To achieve 2767 this, the path validation algorithm constructs a valid policy tree. 2768 If the set of certificate policies that are valid for this path is 2769 not empty, then the result will be a valid policy tree of depth n, 2770 otherwise the result will be a NULL valid policy tree. 2772 A certificate is termed self-issued if the DNs that appear in the 2773 subject and issuer fields are identical and are not empty. In 2774 general, the issuer and subject of the certificates that make up a 2775 path are different for each certificate. However, a CA may issue a 2776 certificate to itself to support key rollover or changes in 2777 certificate policies. These self-issued certificates are not counted 2778 when evaluating path length or name constraints. 2780 This section presents the algorithm in four basic steps: (1) 2781 initialization, (2) basic certificate processing, (3) preparation for 2782 the next certificate, and (4) wrap-up. Steps (1) and (4) are 2783 performed exactly once. Step (2) is performed for all certificates 2784 in the path. Step (3) is performed for all certificates in the path 2785 except the final certificate. Figure 2 provides a high-level 2786 flowchart of this algorithm. 2788 +-------+ 2789 | START | 2790 +-------+ 2791 | 2792 V 2793 +----------------+ 2794 | Initialization | 2795 +----------------+ 2796 | 2797 +<--------------------+ 2798 | | 2799 V | 2800 +----------------+ | 2801 | Process Cert | | 2802 +----------------+ | 2803 | | 2804 V | 2805 +================+ | 2806 | IF Last Cert | | 2807 | in Path | | 2808 +================+ | 2809 | | | 2810 THEN | | ELSE | 2811 V V | 2812 +----------------+ +----------------+ | 2813 | Wrap up | | Prepare for | | 2814 +----------------+ | Next Cert | | 2815 | +----------------+ | 2816 V | | 2817 +-------+ +--------------+ 2818 | STOP | 2819 +-------+ 2821 Figure 2. Path Processing Flowchart 2823 6.1.1 Inputs 2825 This algorithm assumes the following seven inputs are provided to the 2826 path processing logic: 2828 (a) a prospective certification path of length n; 2830 (b) the time, T, for which the validity of the path should be 2831 determined. This may be the current date/time, or some point in 2832 the past. 2834 (c) user-initial-policy-set: A set of certificate policy 2835 identifiers naming the policies that are acceptable to the 2836 certificate user. The user-initial-policy-set contains the special 2837 value any-policy if the user is not concerned about certificate 2838 policy. 2840 (d) trust anchor information, describing a CA that serves as a 2841 trust anchor for the certification path. The trust anchor 2842 information includes: 2844 (1) the trusted issuer name, 2846 (2) the trusted public key algorithm, 2848 (3) the trusted public key, and 2850 (4) optionally, the trusted public key parameters associated 2851 with the public key. 2853 The trust anchor information may be provided to the path 2854 processing procedure in the form of a self-signed certificate. The 2855 trusted anchor information is trusted because it was delivered to 2856 the path processing procedure by some trustworthy out-of-band 2857 procedure. If the trusted public key algorithm requires 2858 parameters, then the parameters are provided along with the 2859 trusted public key. 2861 (e) initial-policy-mapping-inhibit, which indicates if policy 2862 mapping is allowed in the certification path. 2864 (f) initial-explicit-policy, which indicates if the path must be 2865 valid for at least one of the certificate policies in the user- 2866 initial-policy-set. 2868 (g) initial-any-policy-inhibit, which indicates whether the any- 2869 policy OID should be processed if it is included in a certificate. 2871 6.1.2 Initialization 2873 The initialization phase establishes eleven state variables based 2874 upon the seven inputs: 2876 (a) valid_policy_tree: A tree of certificate policies with their 2877 optional qualifiers; each of the leaves of the tree represents a 2878 valid policy at this stage in the certification path validation. 2879 If valid policies exist at this stage in the certification path 2880 validation, the depth of the tree is equal to the number of 2881 certificates in the chain that have been processed. If valid 2882 policies do not exist at this stage in the certification path 2883 validation, the tree is set to NULL. Once the tree is set to NULL, 2884 policy processing ceases. 2886 Each node in the valid_policy_tree includes four data objects: the 2887 valid policy, a set of associated policy qualifiers, a set of one 2888 or more expected policy values, and a criticality indicator. If 2889 the node is at depth x, the components of the node have the 2890 following semantics: 2892 (1) The valid_policy is a single policy OID representing a 2893 valid policy for the path of length x. 2895 (2) The qualifier_set is a set of policy qualifiers associated 2896 with the valid policy in certificate x. 2898 (3) The criticality_indicator indicates whether the certificate 2899 policy extension in certificate x was marked as critical. 2901 (4) The expected_policy_set contains one or more policy OIDs 2902 that would satisfy this policy in the certificate x+1. 2904 The initial value of the valid_policy_tree is a single node with 2905 valid_policy any-policy, an empty qualifier_set, an 2906 expected_policy_set with the single value any-policy, and a 2907 criticality_indicator of FALSE. This node is considered to be at 2908 depth zero. 2910 Figure 3 is a graphic representation of the initial state of the 2911 valid_policy_tree. Additional figures will use this format to 2912 describe changes in the valid_policy_tree during path processing. 2914 +----------------+ 2915 | any-policy | <---- valid_policy 2916 +----------------+ 2917 | {} | <---- qualifier_set 2918 +----------------+ 2919 | FALSE | <---- criticality_indicator 2920 +----------------+ 2921 | {any-policy} | <---- expected_policy_set 2922 +----------------+ 2924 Figure 3. Initial value of the valid_policy_tree state variable 2926 (b) permitted_subtrees: A set of root names for each name type 2927 (e.g., X.500 distinguished names, email addresses, or ip 2928 addresses) defining a set of subtrees within which all subject 2929 names in subsequent certificates in the certification path shall 2930 fall. This variable includes a set for each name type: the initial 2931 value for the set for Distinguished Names is the set of all 2932 Distinguished names; the initial value for the set of RFC822 names 2933 is the set of all RFC822 names, etc. 2935 (c) excluded_subtrees: A set of root names for each name type 2936 (e.g., X.500 distinguished names, email addresses, or ip 2937 addresses) defining a set of subtrees within which no subject name 2938 in subsequent certificates in the certification path may fall. 2939 This variable includes a set for each name type, and the initial 2940 value for each set is empty. 2942 (d) explicit_policy: an integer which indicates if a non-NULL 2943 valid_policy_tree is required. The integer indicates the number of 2944 non-self-issued certificates to be processed before this 2945 requirement is imposed. Once set, this variable may be decreased, 2946 but may not be increased. That is, if a certificate in the path 2947 requires a non-NULL valid_policy_tree, a later certificate can not 2948 remove this requirement. If initial-explicit-policy is set, then 2949 the initial value is 0, otherwise the initial value is n+1. 2951 (e) inhibit_any-policy: an integer which indicates whether the 2952 any-policy policy identifier is considered a match. The integer 2953 indicates the number of non-self-issued certificates to be 2954 processed before the any-policy OID, if asserted in a certificate, 2955 is ignored. Once set, this variable may be decreased, but may not 2956 be increased. That is, if a certificate in the path inhibits 2957 processing of any-policy, a later certificate can not permit it. 2958 If initial-any-policy-inhibit is set, then the initial value is 0, 2959 otherwise the initial value is n+1. 2961 (f) policy_mapping: an integer which indicates if policy mapping 2962 is permitted. The integer indicates the number of non-self-issued 2963 certificates to be processed before policy mapping is inhibited. 2964 Once set, this variable may be decreased, but may not be 2965 increased. That is, if a certificate in the path specifies policy 2966 mapping is not permitted, it can not be overridden by a later 2967 certificate. If initial-policy-mapping-inhibit is set, then the 2968 initial value is 0, otherwise the initial value is n+1. 2970 (g) working_public_key_algorithm: the digital signature algorithm 2971 used to verify the signature of a certificate. The 2972 working_public_key_algorithm is initialized from the trusted 2973 public key algorithm provided in the trust anchor information. 2975 (h) working_public_key: the public key used to verify the 2976 signature of a certificate. The working_public_key is initialized 2977 from the trusted public key provided in the trust anchor 2978 information. 2980 (i) working_public_key_parameters: parameters associated with the 2981 current public key, that may required to verify a signature 2982 (depending upon the algorithm). The working_public_key_parameters 2983 variable is initialized from the trusted public key parameters 2984 provided in the trust anchor information. 2986 (j) working_issuer_name: the issuer distinguished name expected 2987 in the next certificate in the chain. The working_issuer_name is 2988 initialized to the trusted issuer provided in the trust anchor 2989 information. 2991 (k) max_path_length: this integer is initialized to n, and is 2992 reset by the path length constraint field within the basic 2993 constraints extension of a CA certificate. 2995 Upon completion of the initialization steps, perform the basic 2996 certificate processing steps specified in 6.1.3. 2998 6.1.3 Basic Certificate Processing 3000 The basic path processing actions to be performed for certificate i 3001 are listed below. 3003 (a) Verify the basic certificate information. The certificate 3004 must satisfy each of the following: 3006 (1) The certificate was signed with the 3007 working_public_key_algorithm using the working_public_key and 3008 the working_public_key_parameters. 3010 (2) The certificate validity period includes time T. 3012 (3) At time T, the certificate is not revoked and is not on 3013 hold status. This may be determined by obtaining the 3014 appropriate CRL (see section 6.3), status information, or by 3015 out-of-band mechanisms. 3017 (4) The certificate issuer name is the working_issuer_name. 3019 (b) If certificate i is not self-issued, verify that the subject 3020 name is within one of the permitted_subtrees for X.500 3021 distinguished names, and verify that each of the alternative names 3022 in the subjectAltName extension (critical or non-critical) is 3023 within one of the permitted_subtrees for that name type. 3025 (c) If certificate i is not self-issued, verify that the subject 3026 name is not within one of the excluded_subtrees for X.500 3027 distinguished names, and verify that each of the alternative names 3028 in the subjectAltName extension (critical or non-critical) is not 3029 within one of the excluded_subtrees for that name type. 3031 (d) If the certificate policies extension is present in the 3032 certificiate and the valid_policy_tree is not NULL, process the 3033 policy information by performing the following steps in order: 3035 (1) For each policy P not equal to any-policy in the 3036 certificate policies extension, let P-OID denote the OID in 3037 policy P and P-Q denote the qualifier set for policy P. 3038 Perform the following steps in order: 3040 (i) If the valid_policy_tree includes a node of depth i-1 3041 where P-OID is in the expected_policy_set, create a child 3042 node as follows: set the valid_policy to OID- P; set the 3043 qualifier_set to P-Q, and set the expected_policy_set to 3044 {P-OID}. 3046 For example, consider a valid_policy_tree with a node of 3047 depth i-1 where the expected_policy_set is {Gold, White}. 3048 Assume the certificate policies Gold and Silver appear in 3049 the certificate policies extension of certificate i. The 3050 Gold policy is matched but the Silver policy is not. This 3051 rule will generate a child node of depth i for the Gold 3052 policy. The result is shown as Figure 4. 3054 |-----------------| 3055 | Red | 3056 |-----------------| 3057 | {} | 3058 |-----------------| node of depth i-1 3059 | FALSE | 3060 |-----------------| 3061 | {Gold, White} | 3062 |-----------------| 3063 | 3064 | 3065 | 3066 V 3067 |-----------------| 3068 | Gold | 3069 |-----------------| 3070 | {} | 3071 |-----------------| node of depth i 3072 | uninitialized | 3073 |-----------------| 3074 | {Gold} | 3075 |-----------------| 3077 Figure 4. Processing an exact match 3079 (ii) If there was no match in step (i) and the 3080 valid_policy_tree includes a node of depth i-1 with the 3081 valid policy any-policy, generate a child node with the 3082 following values: set the valid_policy to P-OID; set the 3083 qualifier_set to P-Q, and set the expected_policy_set to 3084 {P-OID}. 3086 For example, consider a valid_policy_tree with a node of 3087 depth i-1 where the valid_policy is any-policy. Assume the 3088 certificate policies Gold and Silver appear in the 3089 certificate policies extension of certificate i. The Gold 3090 policy does not have a qualifier, but the Silver policy has 3091 the qualifier Q-Silver. If Gold and Silver were not matched 3092 in (i) above, this rule will generate two child nodes of 3093 depth i, one for each policy. The result is shown as Figure 3094 5. 3096 |-----------------| 3097 | any-policy | 3098 |-----------------| 3099 | {} | 3100 |-----------------| node of depth i-1 3101 | FALSE | 3102 |-----------------| 3103 | {any-policy} | 3104 |-----------------| 3105 / \ 3106 / \ 3107 / \ 3108 / \ 3109 |-----------------| |-----------------| 3110 | Gold | | Silver | 3111 |-----------------| |-----------------| 3112 | {} | | {Q-Silver} | 3113 |-----------------| nodes of |-----------------| 3114 | uninitialized | depth i | uninitialized | 3115 |-----------------| |-----------------| 3116 | {Gold} | | {Silver} | 3117 |-----------------| |-----------------| 3119 Figure 5. Processing unmatched policies when a leaf node 3120 specifies any-policy 3122 (2) If the certificate policies extension includes the policy 3123 any-policy with the qualifier set AP-Q and inhibit_any-policy 3124 is greater than 0, then: 3126 For each node in the valid_policy_tree of depth i-1, for each 3127 value in the expected_policy_set (including any-policy) that 3128 does not appear in a child node, create a child node with the 3129 following values: set the valid_policy to the value from the 3130 expected_policy_set in the parent node; set the qualifier_set 3131 to AP-Q, and set the expected_policy_set to the value in the 3132 valid_policy from this node. 3134 For example, consider a valid_policy_tree with a node of depth 3135 i-1 where the expected_policy_set = {Gold, Silver}. Assume 3136 any-policy appears in the certificate policies extension of 3137 certificate i, but Gold and Silver do not. This rule will 3138 generate two child nodes of depth i, one for each policy. The 3139 result is shown below as Figure 6. 3141 |-----------------| 3142 | Red | 3143 |-----------------| 3144 | {} | 3145 |-----------------| node of depth i-1 3146 | FALSE | 3147 |-----------------| 3148 | {Gold, Silver} | 3149 |-----------------| 3150 / \ 3151 / \ 3152 / \ 3153 / \ 3154 |-----------------| |-----------------| 3155 | Gold | | Silver | 3156 |-----------------| |-----------------| 3157 | {} | | {} | 3158 |-----------------| nodes of |-----------------| 3159 | uninitialized | depth i | uninitialized | 3160 |-----------------| |-----------------| 3161 | {Gold} | | {Silver} | 3162 |-----------------| |-----------------| 3164 Figure 6. Processing unmatched policies when the certificate 3165 policies extension specifies any-policy 3167 (3) If there is a node in the valid_policy_tree of depth i-1 or 3168 less without any child nodes, delete that node. Repeat this 3169 step until there are no nodes of depth i-1 or less without 3170 children. 3172 For example, consider the valid_policy_tree shown in Figure 7 3173 below. The two nodes at depth i-1 that are marked with an to 3174 the resulting tree will cause the node at depth i-2 that is 3175 marked with an 'Y' to be deleted. The following application of 3176 the rule does not cause any nodes to be deleted, and this step 3177 is complete. 3179 +-----------+ 3180 | | node of depth i-3 3181 +-----------+ 3182 / | \ 3183 / | \ 3184 / | \ 3185 +-----------+ +-----------+ +-----------+ 3186 | | | | | Y | nodes of 3187 +-----------+ +-----------+ +-----------+ depth i-2 3188 / \ || || 3189 / \ || || 3190 / \ || || 3191 +-----------+ +-----------+ +-----------+ +-----------+ nodes of 3192 | | | X | | | | X | depth 3193 +-----------+ +-----------+ +-----------+ +-----------+ i-1 3194 | / | \ 3195 | / | \ 3196 | / | \ 3197 +-----------+ +-----------+ +-----------+ +-----------+ nodes of 3198 | | | | | | | | depth 3199 +-----------+ +-----------+ +-----------+ +-----------+ i 3201 Figure 7. Pruning the valid_policy_tree 3203 (4) If the certificate policies extension was marked as 3204 critical, set the criticality_indicator in all nodes of depth i 3205 to TRUE. If the certificate policies extension was not marked 3206 critical, set the criticality_indicator in all nodes of depth i 3207 to FALSE. 3209 (e) If the certificate policies extension is not present, set the 3210 valid_policy_tree to NULL. 3212 (f) verify that either explicit_policy is greater than 0 or the 3213 valid_policy_tree is not equal to NULL; 3215 If any of steps (a), (b), (c), or (f) fails, the procedure 3216 terminates, returning a failure indication and an appropriate reason. 3218 If i is not equal to n, continue by performing the preparatory steps 3219 listed in 6.1.4. If i is equal to n, perform the wrap-up steps 3220 listed in 6.1.5. 3222 6.1.4 Preparation for Certificate i+1 3224 To prepare for processing of certificate i+1, perform the following 3225 steps for certificate i: 3227 (a) If a policy mapping extension is present, verify that the 3228 special value any-policy does not appear as an issuerDomainPolicy 3229 or a subjectDomainPolicy. 3231 (b) If a policy mapping extension is present, then for each 3232 issuerDomainPolicy ID-P in the policy mapping extension: 3234 (1) If the policy_mapping variable is greater than 0, for each 3235 node in the valid_policy_tree of depth i where ID-P is the 3236 valid_policy, set expected_policy_set to the set of 3237 subjectDomainPolicy values that are specified as equivalent to 3238 ID-P by the policy mapping extension. 3240 If no node of depth i in the valid_policy_tree has a 3241 valid_policy of ID-P but there is a node of depth i with a 3242 valid_policy of any-policy, then generate a child node of the 3243 node of depth i-1 that has a valid_policy of any-policy as 3244 follows: 3246 (i) set the valid_policy to ID-P; 3248 (ii) set the qualifier_set to the qualifier set of the 3249 policy any-policy in the certificate policies extension of 3250 certificate i; 3252 (iii) set the criticality_indicator to the criticality of 3253 the certificate policies extension of certificate i; 3255 (iv) and set the expected_policy_set to the set of 3256 subjectDomainPolicy values that are specified as equivalent 3257 to ID-P by the policy mappings extension. 3259 (2) If the policy_mapping variable is equal to 0: 3261 (i) delete each node of depth i in the valid_policy_tree 3262 where ID-P is the valid_policy. 3264 (ii) If there is a node in the valid_policy_tree of depth 3265 i-1 or less without any child nodes, delete that node. 3266 Repeat this step until there are no nodes of depth i-1 or 3267 less without children. 3269 (c) Assign the certificate subject name to working_issuer_name. 3271 (d) Assign the certificate subjectPublicKey to working_public_key. 3273 (e) If the subjectPublicKeyInfo field of the certificate contains 3274 an algorithm field with non-null parameters, assign the parameters 3275 to the working_public_key_parameters variable. 3277 If the subjectPublicKeyInfo field of the certificate contains an 3278 algorithm field with null parameters or parameters are omitted, 3279 compare the certificate subjectPublicKey algorithm to the 3280 working_public_key_algorithm. If the certificate subjectPublicKey 3281 algorithm and the working_public_key_algorithm are different, set 3282 the working_public_key_parameters to null. 3284 (f) Assign the certificate subjectPublicKey algorithm to the 3285 working_public_key_algorithm variable. 3287 (g) If a name constraints extension is included in the 3288 certificate, modify the permitted_subtrees and excluded_subtrees 3289 state variables as follows: 3291 (1) If permittedSubtrees is present in the certificate, set the 3292 permitted_subtrees state variable to the intersection of its 3293 previous value and the value indicated in the extension field. 3294 If permittedSubtrees does not include a particular name type, 3295 the permitted_subtrees state variable is unchanged for that 3296 name type. 3298 (2) If excludedSubtrees is present in the certificate, set the 3299 excluded_subtrees state variable to the union of its previous 3300 value and the value indicated in the extension field. If 3301 excludedSubtrees does not include a particular name type, the 3302 excluded_subtrees state variable is unchanged for that name 3303 type. 3305 (h) If the issuer and subject names are not identical: 3307 (1) If explicit_policy is not 0, decrement explicit_policy by 3308 1. 3310 (2) If policy_mapping is not 0, decrement policy_mapping by 1. 3312 (3) If inhibit_any-policy is not 0, decrement inhibit_any- 3313 policy by 1. 3315 (i) If a policy constraints extension is included in the 3316 certificate, modify the explicit_policy and policy_mapping state 3317 variables as follows: 3319 (1) If requireExplicitPolicy is present and is less than 3320 explicit_policy, set explicit_policy to the value of 3321 requireExplicitPolicy. 3323 (2) If inhibitPolicyMapping is present and is less than 3324 policy_mapping, set policy_mapping to the value of 3325 inhibitPolicyMapping. 3327 (j) If the inhibitAnyPolicy extension is included in the 3328 certificate and is less than inhibit_any-policy, set inhibit_any- 3329 policy to the value of inhibitAnyPolicy. 3331 (k) Verify that the certificate is a CA certificate (as specified 3332 in a basicConstraints extension or as verified out-of-band). 3334 (l) If the certificate was not self-issued, verify that 3335 max_path_length is greater than zero and decrement max_path_length 3336 by 1. 3338 (m) If pathLengthConstraint is present in the certificate and is 3339 less than max_path_length, set max_path_length to the value of 3340 pathLengthConstraint. 3342 (n) If a key usage extension is present and marked critical, 3343 verify that the keyCertSign bit is set. 3345 (o) Recognize and process any other critical extension present in 3346 the certificate. 3348 If check (a), (k), (l), (n) or (o) fails, the procedure terminates, 3349 returning a failure indication and an appropriate reason. 3351 If (a), (k), (l), (n) and (o) have completed successfully, increment 3352 i and perform the basic certificate processing specified in 6.1.2. 3354 6.1.5 Wrap-up procedure 3356 To complete the processing of the end entity certificate, perform the 3357 following steps for certificate n: 3359 (a) If certificate n was not self-issued and explicit_policy is 3360 not 0, decrement explicit_policy by 1. 3362 (b) If a policy constraints extension is included in the 3363 certificate and requireExplicitPolicy is present and has a value 3364 of 0, set the explicit_policy state variable to 0. 3366 (c) Assign the certificate subjectPublicKey to working_public_key. 3368 (d) If the subjectPublicKeyInfo field of the certificate contains 3369 an algorithm field with non-null parameters, assign the parameters 3370 to the working_public_key_parameters variable. 3372 If the subjectPublicKeyInfo field of the certificate contains an 3373 algorithm field with null parameters or parameters are omitted, 3374 compare the certificate subjectPublicKey algorithm to the 3375 working_public_key_algorithm. If the certificate subjectPublicKey 3376 algorithm and the working_public_key_algorithm are different, set 3377 the working_public_key_parameters to null. 3379 (e) Assign the certificate subjectPublicKey algorithm to the 3380 working_public_key_algorithm variable. 3382 (f) Recognize and process any other critical extension present in 3383 the certificate n. 3385 (g) Calculate the intersection of the valid_policy_tree and the 3386 user-initial-policy-set, as follows: 3388 (i) If the valid_policy_tree is NULL, the intersection is NULL. 3390 (ii) If the valid_policy_tree is not NULL and the user- 3391 initial-policy-set is any-policy, the intersection is the 3392 entire valid_policy_tree. 3394 (iii) If the valid_policy_tree is not NULL and the user- 3395 initial-policy-set is not any-policy, calculate the 3396 intersection of the valid_policy_tree and the user-initial- 3397 policy-set as follows: 3399 1. Determine the set of policy nodes whose parent nodes have 3400 a valid_policy of any-policy. This is the 3401 valid_policy_node_set. 3403 2. If the valid_policy of any node in the 3404 valid_policy_node_set is not in the user-initial-policy-set 3405 and is not any-policy, delete this node and all its 3406 children. 3408 3. If there is a node in the valid_policy_tree of depth n-1 3409 or less without any child nodes, delete that node. Repeat 3410 this step until there are no nodes of depth n-1 or less 3411 without children. 3413 (h) If the certificate was not self-issued, verify that 3414 max_path_length is greater than zero and decrement 3415 max_path_length by 1. 3417 If check (h) fails, the procedure terminates, returning a failure 3418 indication and an appropriate reason. 3420 If check (h) succeeds and either (1) value of explicit_policy 3421 variable is greater than zero, or (2) the valid_policy_tree is not 3422 NULL, then path processing has succeeded. 3424 6.1.6 Outputs 3426 If path processing succeeds, the procedure terminates, returning a 3427 success indication together with final value of the 3428 valid_policy_tree, the working_public_key, the 3429 working_public_key_algorithm, and the working_public_key_parameters. 3431 6.2 Using the Path Validation Algorithm 3433 The path validation algorithm describes the process of validating a 3434 single certification path. While each path begins with a specific 3435 trust anchor, there is no requirement that all paths validated by a 3436 particular system share a single trust anchor. 3438 The selection of one or more trusted CAs is a local decision. A 3439 system may provide any one of its trusted CAs as the trust anchor for 3440 a particular path. The inputs to the path validation algorithm may 3441 be different for each path. The inputs used to process a path may 3442 reflect application-specific requirements or limitations in the trust 3443 accorded a particular trust anchor. For example, a trusted CA may 3444 only be trusted for a particular certificate policy. This 3445 restriction can be expressed through the inputs to the path 3446 validation procedure. 3448 It is also possible to specify an extended version of the above 3449 certification path processing procedure which results in default 3450 behavior identical to the rules of PEM [RFC 1422]. In this extended 3451 version, additional inputs to the procedure are a list of one or more 3452 Policy Certification Authorities (PCAs) names and an indicator of the 3453 position in the certification path where the PCA is expected. At the 3454 nominated PCA position, the CA name is compared against this list. 3455 If a recognized PCA name is found, then a constraint of 3456 SubordinateToCA is implicitly assumed for the remainder of the 3457 certification path and processing continues. If no valid PCA name is 3458 found, and if the certification path cannot be validated on the basis 3459 of identified policies, then the certification path is considered 3460 invalid. 3462 6.3 CRL Validation 3464 This section describes the steps necessary to determine if a 3465 certificate is revoked or on hold status when CRLs are the revocation 3466 mechanism used by the certificate issuer. Conforming implementations 3467 of this specification are not required to implement this algorithm, 3468 but MUST be functionally equivalent to the external behavior 3469 resulting from this procedure. Any algorithm may be used by a 3470 particular implementation so long as it derives the correct result. 3472 This algorithm defines a set of inputs, a set of state variables, and 3473 processing steps that are performed for each certificate in the path. 3475 6.3.1 Revocation Inputs 3477 To support revocation processing, the algorithm requires two inputs: 3479 (a) certificate: the algorithm requires the certificate serial 3480 number and issuer name to determine if a certificate is on a 3481 particular CRL. The basicConstraints extension is used to 3482 determine whether the supplied certificate is associated with a CA 3483 or an end-entity. If present, the algorithm may use the 3484 cRLDistributionsPoint and freshestCRL extensions to determine 3485 revocation status. 3487 (b) use-deltas: This boolean input determines if the delta needs 3488 to be checked if the CRL is still valid. 3490 Note that implementations supporting legacy PKIs, such as RFC 1422 3491 and X.509 version 1, will need an additional input indicating 3492 whether the supplied certificate is associated with a CA or an 3493 end-entity. 3495 6.3.2 Initialization and Revocation State Variables 3497 To support CRL processing, the algorithm requires the following state 3498 variables: 3500 (a) reasons_mask: This variable contains the set of revocation 3501 reasons supported by the CRLs and delta CRLs processed so far. The 3502 legal members of the set are the possible values for reasonflags: 3503 unspecified; keyCompromise; caCompromise; affiliationChanged; 3504 superseded; cessationOfOperation; and certificateHold. The 3505 special value all-reasons is used to denote the set of all legal 3506 members. This variable is initialized to the empty set. 3508 (b) cert_status: This variable contains the status of the 3509 certificate. Legal values are unspecified; keyCompromise; 3510 caCompromise; affiliationChanged; superseded; 3511 cessationOfOperation; and certificateHold, the special value 3512 UNREVOKED, or the special value UNDETERMINED. This variable is 3513 initialized to the special value UNREVOKED. 3515 (c) interim_reasons_mask: This contains the set of revocation 3516 reasons supported by the CRL or delta CRL currently being 3517 processed. 3519 Note: In some environments, it is not necessary to check all reason 3520 codes. For example, some envornments only are concerned with 3521 caCompromise and keyCompromise for CA certificates. This algorithnm 3522 checks all reason codes. Additional processing and state variables 3523 may be necessary to limit the checking to a subset of the reason 3524 codes. 3526 6.3.3 CRL Processing 3528 This algorithm begins by assuming the certificate is not revoked. 3529 The algorithm checks one or more CRLs until either the certificate 3530 status is determined to be revoked or sufficent CRLs have been 3531 checked to cover all reason codes. 3533 For each distribution point (DP) in the crl distribution points 3534 extension while ((reasons_mask is not all-reasons) and (cert_status 3535 is UNREVOKED)) 3537 (1) locate the corresponding CRL in CRL cache, and perform the 3538 following verifications: 3540 (a) compute the interim_reasons_mask for this CRL as follows: 3542 1. if the CRL includes reasons and the DP includes reasons, 3543 then set interim_reasons_mask to the intersection of of 3544 reasons in the DP and reasons in CRL reasons extension. 3546 2. if the CRL includes reasons but the DP omits reasons, 3547 then set interim_reasons_mask to the value of CRL reasons. 3549 3. if the CRL omits reasons but the DP includes reasons, 3550 then set interim_reasons_mask to the value of DP reasons. 3552 4. if the CRL omits reasons and the DP omits reasons, then 3553 set interim_reasons_mask to the special value all-reasons. 3555 Verify that interim_reasons_mask includes one or more reasons 3556 that is not included in the reasons_mask. 3558 (b) Verify the issuer of the CRL as follows: 3560 if the DP includes cRLIssuer, then verify that the CRL 3561 issuer matches cRLIssuer else verify that the CRL issuer 3562 matches the certificate issuer. 3564 (c) obtain and validate the certification path for the CRL 3565 issuer. 3567 (d) validate the signature on the CRL. 3569 (2) If each of the verifications (a) through (d) succeeds, then 3570 perform the following steps: 3572 (a) If the value of next update field is before the current- 3573 time, otain an appropriate delta CRL or discard the CRL. 3575 (b) If the user wants freshest available info AND the freshest 3576 CRL extension is present, check for a corresponding delta for 3577 this base. 3579 (c) If a delta was obtained in (a) or (b), verify that the 3580 delta CRL addresses the same set of certificates and the same 3581 set of reasons as the CRL. 3583 (d) Perform the checks in step 1 (b) and (c): 3585 1. obtain and validate the certification path for the delta 3586 issuer 3588 2. validate the signature on the delta CRL 3590 (e) If a delta CRL was obtained in (a) or (b), and the 3591 verifications (c) and (d) suceeded, combine the base and 3592 delta to form a complete CRL. 3594 (3) If steps and (1) and (2) succeed, then set reasons_mask to the 3595 union of reasons_mask and interim_reasons_mask 3597 (4) Search for the certificate on the CRL 3599 (a) search for the serial number on the CRL 3601 (b) if (a) succeeds, verify that (1) the CRL entry extension 3602 Certificate issuer is not present or (2) the issuer identified 3603 in the CRL entry extension Certificate issuer is the issuer of 3604 the certificate. 3606 (c) if (a) and (b) succeeded, set the cert_status variable as 3607 appropriate: 3609 1. if the reasons extension is present, set the cert_status 3610 variable to the value of the reasons extension 3611 2. if the reasons extension is not present, set the 3612 cert_status variable to the special value not-specified. 3614 if ((reasons_mask is all-reasons) OR (if cert_status is not 3615 UNREVOKED) return cert_status 3617 If all CRLs named in the crl distribution points extension have 3618 been exhausted, and the reasons_mask is not all-reasons and the 3619 cert_status is still UNREVOKED, the verifier must obtain 3620 additional CRLs. 3622 The verifier must repeat the process above with the additional 3623 CRLs not specified in a distribution point. 3625 If all CRLs are exhausted and the reasons_mask is not all-reasons 3626 return the cert_status UNDETERMINED. 3628 7 References 3630 [RFC 791] J. Postel, "Internet Protocol", September 1981. 3632 [RFC 822] D. Crocker, "Standard for the format of ARPA Internet text 3633 messages", August 1982. 3635 [RFC 1034] P.V. Mockapetris, "Domain names - concepts and 3636 facilities", November 1987. 3638 [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic 3639 Mail: Part II: Certificate-Based Key Management," RFC 3640 1422, BBN Communications, February 1993. 3642 [RFC 1423] Balenson, D., "Privacy Enhancement for Internet Electronic 3643 Mail: Part III: Algorithms, Modes, and Identifiers," 3644 RFC 1423, Trusted Information Systems, February 1993. 3646 [RFC 1510] Kohl, J., and C. Neuman, "The Kerberos Network 3647 Authentication Service (V5)," RFC 1510, September 1993. 3649 [RFC 1519] V. Fuller, T. Li, J. Yu, and K. Varadhan. "Classless 3650 Inter-Domain Routing (CIDR): an Address Assignment and 3651 Aggregation Strategy", September 1993. 3653 [RFC 1738] Berners-Lee, T., Masinter L., and M. McCahill. 3654 "Uniform Resource Locators (URL)", RFC 1738, December 1994. 3656 [RFC 1778] Howes, T., Kille S., Yeong, W. and C. Robbins. "The 3657 String Representation of Standard Attribute Syntaxes," 3658 RFC 1778, March 1995. 3660 [RFC 1883] S. Deering and R. Hinden. "Internet Protocol, Version 6 3661 (IPv6) Specification", December 1995. 3663 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 3664 Requirement Levels", March 1997. 3666 [RFC 2247] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. 3667 Sataluri. "Using Domains in LDAP/X.500 Distinguished Names", 3668 RFC 2247, January 1998. 3670 [RFC 2277] H. Alvestrand, "IETF Policy on Character Sets and 3671 Languages", January 1998. 3673 [RFC 2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646", 3674 January 1998. 3676 [RFC 2560] Myers, M., Ankney R., Malpani A., Galperin S., and 3677 C. Adams, "Online Certificate Status Protocal - OCSP", 3678 June 1999. 3680 [SDN.701] SDN.701, "Message Security Protocol 4.0", Revision A 3681 1997-02-06. 3683 [X.208] CCITT Recommendation X.208: Specification of Abstract 3684 Syntax Notation One (ASN.1), 1988. 3686 [X.501] ITU-T Recommendation X.501: Information 3687 Technology - Open Systems Interconnection - The 3688 Directory: Models, 1993. 3690 [X.509] ITU-T Recommendation X.509 (1997 E): Information 3691 Technology - Open Systems Interconnection - The 3692 Directory: Authentication Framework, June 1997. 3694 [X.520] ITU-T Recommendation X.520: Information 3695 Technology - Open Systems Interconnection - The 3696 Directory: Selected Attribute Types, 1993. 3698 [X9.55] ANSI X9.55-1995, Public Key Cryptography For The Financial 3699 Services Industry: Extensions To Public Key Certificates 3700 And Certificate Revocation Lists, 8 December, 1995. 3702 [PKINIT] Tung, B., Neuman C., Hur M., Medvinsky A., Medvinsky S., 3703 Wray J., and J. Trostle, "Public Key Cryptography for 3704 Initial Authentciaion in Kerberos," 3705 draft-ietf-cat-kerberos-pk-init-11.txt, March 15, 2000. 3707 [PKIX ALGS] Bassham, L., Housley, R., and W. Polk, "Internet X.509 3708 Public Key Infrastructure Representation of Public Keys 3709 and Digital Signatures," 3710 draft-ietf-pkix-ipki-pkalgs-00.txt, July 14, 2000. 3712 [PKIX TSA] Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 3713 Public Key Infrastructure Time Stamp Protocol," 3714 draft-ietf-pkix-time-stamp-12.txt, November, 2000. 3716 8 Intellectual Property Rights 3718 The IETF has been notified of intellectual property rights claimed in 3719 regard to some or all of the specification contained in this 3720 document. For more information consult the online list of claimed 3721 rights. 3723 The IETF takes no position regarding the validity or scope of any 3724 intellectual property or other rights that might be claimed to 3725 pertain to the implementation or use of the technology described in 3726 this document or the extent to which any license under such rights 3727 might or might not be available; neither does it represent that it 3728 has made any effort to identify any such rights. Information on the 3729 IETF's procedures with respect to rights in standards-track and 3730 standards-related documentation can be found in BCP-11. Copies of 3731 claims of rights made available for publication and any assurances of 3732 licenses to be made available, or the result of an attempt made to 3733 obtain a general license or permission for the use of such 3734 proprietary rights by implementors or users of this specification can 3735 be obtained from the IETF Secretariat. 3737 9 Security Considerations 3739 The majority of this specification is devoted to the format and 3740 content of certificates and CRLs. Since certificates and CRLs are 3741 digitally signed, no additional integrity service is necessary. 3742 Neither certificates nor CRLs need be kept secret, and unrestricted 3743 and anonymous access to certificates and CRLs has no security 3744 implications. 3746 However, security factors outside the scope of this specification 3747 will affect the assurance provided to certificate users. This 3748 section highlights critical issues that should be considered by 3749 implementors, administrators, and users. 3751 The procedures performed by CAs and RAs to validate the binding of 3752 the subject's identity of their public key greatly affect the 3753 assurance that should be placed in the certificate. Relying parties 3754 may wish to review the CA's certificate practice statement. This may 3755 be particularly important when issuing certificates to other CAs. 3757 The use of a single key pair for both signature and other purposes is 3758 strongly discouraged. Use of separate key pairs for signature and key 3759 management provides several benefits to the users. The ramifications 3760 associated with loss or disclosure of a signature key are different 3761 from loss or disclosure of a key management key. Using separate key 3762 pairs permits a balanced and flexible response. Similarly, different 3763 validity periods or key lengths for each key pair may be appropriate 3764 in some application environments. Unfortunately, some legacy 3765 applications (e.g., SSL) use a single key pair for signature and key 3766 management. 3768 The protection afforded private keys is a critical factor in 3769 maintaining security. On a small scale, failure of users to protect 3770 their private keys will permit an attacker to masquerade as them, or 3771 decrypt their personal information. On a larger scale, compromise of 3772 a CA's private signing key may have a catastrophic effect. If an 3773 attacker obtains the private key unnoticed, the attacker may issue 3774 bogus certificates and CRLs. Existence of bogus certificates and 3775 CRLs will undermine confidence in the system. If the compromise is 3776 detected, all certificates issued to the CA shall be revoked, 3777 preventing services between its users and users of other CAs. 3778 Rebuilding after such a compromise will be problematic, so CAs are 3779 advised to implement a combination of strong technical measures 3780 (e.g., tamper-resistant cryptographic modules) and appropriate 3781 management procedures (e.g., separation of duties) to avoid such an 3782 incident. 3784 Loss of a CA's private signing key may also be problematic. The CA 3785 would not be able to produce CRLs or perform normal key rollover. 3786 CAs are advised to maintain secure backup for signing keys. The 3787 security of the key backup procedures is a critical factor in 3788 avoiding key compromise. 3790 The availability and freshness of revocation information will affect 3791 the degree of assurance that should be placed in a certificate. 3792 While certificates expire naturally, events may occur during its 3793 natural lifetime which negate the binding between the subject and 3794 public key. If revocation information is untimely or unavailable, 3795 the assurance associated with the binding is clearly reduced. 3796 Similarly, implementations of the Path Validation mechanism described 3797 in section 6 that omit revocation checking provide less assurance 3798 than those that support it. 3800 The path validation algorithm depends on the certain knowledge of the 3801 public keys (and other information) about one or more trusted CAs. 3802 The decision to trust a CA is an important decision as it ultimately 3803 determines the trust afforded a certificate. The authenticated 3804 distribution of trusted CA public keys (usually in the form of a 3805 "self-signed" certificate) is a security critical out of band process 3806 that is beyond the scope of this specification. 3808 In addition, where a key compromise or CA failure occurs for a 3809 trusted CA, the user will need to modify the information provided to 3810 the path validation routine. Selection of too many trusted CAs will 3811 make the trusted CA information difficult to maintain. On the other 3812 hand, selection of only one trusted CA may limit users to a closed 3813 community of users until a global PKI emerges. 3815 The quality of implementations that process certificates may also 3816 affect the degree of assurance provided. The path validation 3817 algorithm described in section 6 relies upon the integrity of the 3818 trusted CA information, and especially the integrity of the public 3819 keys associated with the trusted CAs. By substituting public keys 3820 for which an attacker has the private key, an attacker could trick 3821 the user into accepting false certificates. 3823 The binding between a key and certificate subject cannot be stronger 3824 than the cryptographic module implementation and algorithms used to 3825 generate the signature. Short key lengths or weak hash algorithms 3826 will limit the utility of a certificate. CAs are encouraged to note 3827 advances in cryptology so they can employ strong cryptographic 3828 techniques. In addition, CAs should decline to issue certificates to 3829 CAs or end entities that generate weak signatures. 3831 Inconsistent application of name comparison rules may result in 3832 acceptance of invalid X.509 certification paths, or rejection of 3833 valid ones. The X.500 series of specifications defines rules for 3834 comparing distinguished names require comparison of strings without 3835 regard to case, character set, multi-character white space substring, 3836 or leading and trailing white space. This specification relaxes 3837 these requirements, requiring support for binary comparison at a 3838 minimum. 3840 CAs shall encode the distinguished name in the subject field of a CA 3841 certificate identically to the distinguished name in the issuer field 3842 in certificates issued by the latter CA. If CAs use different 3843 encodings, implementations of this specification may fail to 3844 recognize name chains for paths that include this certificate. As a 3845 consequence, valid paths could be rejected. 3847 In addition, name constraints for distinguished names shall be stated 3848 identically to the encoding used in the subject field or 3849 subjectAltName extension. If not, (1) name constraints stated as 3850 excludedSubTrees will not match and invalid paths will be accepted 3851 and (2) name constraints expressed as permittedSubtrees will not 3852 match and valid paths will be rejected. To avoid acceptance of 3853 invalid paths, CAs should state name constraints for distinguished 3854 names as permittedSubtrees where ever possible. 3856 Appendix A. Psuedo-ASN.1 Structures and OIDs 3858 This section describes data objects used by conforming PKI components 3859 in an "ASN.1-like" syntax. This syntax is a hybrid of the 1988 and 3860 1993 ASN.1 syntaxes. The 1988 ASN.1 syntax is augmented with 1993 3861 UNIVERSAL Types UniversalString, BMPString and UTF8String. 3863 The ASN.1 syntax does not permit the inclusion of type statements in 3864 the ASN.1 module, and the 1993 ASN.1 standard does not permit use of 3865 the new UNIVERSAL types in modules using the 1988 syntax. As a 3866 result, this module does not conform to either version of the ASN.1 3867 standard. 3869 This appendix may be converted into 1988 ASN.1 by replacing the 3870 defintions for the UNIVERSAL Types with the 1988 catch-all "ANY". 3872 A.1 Explicitly Tagged Module, 1988 Syntax 3874 PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) 3875 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18)} 3877 DEFINITIONS EXPLICIT TAGS ::= 3879 BEGIN 3881 -- EXPORTS ALL -- 3883 -- IMPORTS NONE -- 3885 -- UNIVERSAL Types defined in '93 and '98 ASN.1 3886 -- but required by this specification 3888 UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING 3889 -- UniversalString is defined in ASN.1:1993 3891 BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING 3892 -- BMPString is the subtype of UniversalString and models 3893 -- the Basic Multilingual Plane of ISO/IEC/ITU 10646-1 3895 UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 3896 -- The content of this type conforms to RFC 2279. 3898 -- 3899 -- PKIX specific OIDs 3901 id-pkix OBJECT IDENTIFIER ::= 3902 { iso(1) identified-organization(3) dod(6) internet(1) 3903 security(5) mechanisms(5) pkix(7) } 3904 -- PKIX arcs 3906 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 3907 -- arc for private certificate extensions 3908 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 3909 -- arc for policy qualifier types 3910 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 3911 -- arc for extended key purpose OIDS 3912 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 3913 -- arc for access descriptors 3915 -- policyQualifierIds for Internet policy qualifiers 3917 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 3918 -- OID for CPS qualifier 3919 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 3920 -- OID for user notice qualifier 3922 -- access descriptor definitions 3924 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 3925 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 3926 id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 } 3927 id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 } 3929 -- attribute data types -- 3931 Attribute ::= SEQUENCE { 3932 type AttributeType, 3933 values SET OF AttributeValue 3934 -- at least one value is required -- } 3936 AttributeType ::= OBJECT IDENTIFIER 3938 AttributeValue ::= ANY 3940 AttributeTypeAndValue ::= SEQUENCE { 3941 type AttributeType, 3942 value AttributeValue } 3944 -- suggested naming attributes: Definition of the following 3945 -- information object set may be augmented to meet local 3946 -- requirements. Note that deleting members of the set may 3947 -- prevent interoperability with conforming implementations. 3948 -- presented in pairs: the AttributeType followed by the 3949 -- type definition for the corresponding AttributeValue 3950 --Arc for standard naming attributes 3951 id-at OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 4} 3953 -- Attributes of type NameDirectoryString 3954 id-at-name AttributeType ::= {id-at 41} 3955 id-at-surname AttributeType ::= {id-at 4} 3956 id-at-givenName AttributeType ::= {id-at 42} 3957 id-at-initials AttributeType ::= {id-at 43} 3958 id-at-generationQualifier AttributeType ::= {id-at 44} 3960 X520name ::= CHOICE { 3961 teletexString TeletexString (SIZE (1..ub-name)), 3962 printableString PrintableString (SIZE (1..ub-name)), 3963 universalString UniversalString (SIZE (1..ub-name)), 3964 utf8String UTF8String (SIZE (1..ub-name)), 3965 bmpString BMPString (SIZE(1..ub-name)) } 3967 -- 3969 id-at-commonName AttributeType ::= {id-at 3} 3971 X520CommonName ::= CHOICE { 3972 teletexString TeletexString (SIZE (1..ub-common-name)), 3973 printableString PrintableString (SIZE (1..ub-common-name)), 3974 universalString UniversalString (SIZE (1..ub-common-name)), 3975 utf8String UTF8String (SIZE (1..ub-common-name)), 3976 bmpString BMPString (SIZE(1..ub-common-name)) } 3978 -- 3980 id-at-localityName AttributeType ::= {id-at 7} 3982 X520LocalityName ::= CHOICE { 3983 teletexString TeletexString (SIZE (1..ub-locality-name)), 3984 printableString PrintableString (SIZE (1..ub-locality-name)), 3985 universalString UniversalString (SIZE (1..ub-locality-name)), 3986 utf8String UTF8String (SIZE (1..ub-locality-name)), 3987 bmpString BMPString (SIZE(1..ub-locality-name)) } 3989 -- 3991 id-at-stateOrProvinceName AttributeType ::= {id-at 8} 3993 X520StateOrProvinceName ::= CHOICE { 3994 teletexString TeletexString (SIZE (1..ub-state-name)), 3995 printableString PrintableString (SIZE (1..ub-state-name)), 3996 universalString UniversalString (SIZE (1..ub-state-name)), 3997 utf8String UTF8String (SIZE (1..ub-state-name)), 3998 bmpString BMPString (SIZE(1..ub-state-name)) } 4000 -- 4002 id-at-organizationName AttributeType ::= {id-at 10} 4004 X520OrganizationName ::= CHOICE { 4005 teletexString TeletexString (SIZE (1..ub-organization-name)), 4006 printableString PrintableString (SIZE (1..ub-organization-name)), 4007 universalString UniversalString (SIZE (1..ub-organization-name)), 4008 utf8String UTF8String (SIZE (1..ub-organization-name)), 4009 bmpString BMPString (SIZE(1..ub-organization-name)) } 4011 -- 4013 id-at-organizationalUnitName AttributeType ::= {id-at 11} 4015 X520OrganizationalUnitName ::= CHOICE { 4016 teletexString TeletexString (SIZE (1..ub-organizational-unit-name)), 4017 printableString PrintableString 4018 (SIZE (1..ub-organizational-unit-name)), 4019 universalString UniversalString 4020 (SIZE (1..ub-organizational-unit-name)), 4021 utf8String UTF8String (SIZE (1..ub-organizational-unit-name)), 4022 bmpString BMPString (SIZE(1..ub-organizational-unit-name)) } 4024 -- 4026 id-at-title AttributeType ::= {id-at 12} 4028 X520Title ::= CHOICE { 4029 teletexString TeletexString (SIZE (1..ub-title)), 4030 printableString PrintableString (SIZE (1..ub-title)), 4031 universalString UniversalString (SIZE (1..ub-title)), 4032 utf8String UTF8String (SIZE (1..ub-title)), 4033 bmpString BMPString (SIZE(1..ub-title)) } 4035 -- 4037 id-at-dnQualifier AttributeType ::= {id-at 46} 4038 X520dnQualifier ::= PrintableString 4040 id-at-countryName AttributeType ::= {id-at 6} 4041 X520countryName ::= PrintableString (SIZE (2)) -- IS 3166 codes 4043 id-at-serialNumber AttributeType ::= { id-at 5 } 4044 X520SerialNumber ::= PrintableString (SIZE (1..ub-serial-number)) 4045 -- domaincomponent and identifier from RFC 2247 4047 id-domainComponent OBJECT IDENTIFIER ::= 4048 { 0 9 2342 19200300 100 1 25 } 4050 DomainComponent ::= IA5String 4052 -- Legacy attributes 4054 pkcs-9 OBJECT IDENTIFIER ::= 4055 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 } 4057 emailAddress AttributeType ::= { pkcs-9 1 } 4059 Pkcs9email ::= IA5String (SIZE (1..ub-emailaddress-length)) 4061 -- naming data types -- 4063 Name ::= CHOICE { -- only one possibility for now -- 4064 rdnSequence RDNSequence } 4066 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 4068 DistinguishedName ::= RDNSequence 4070 RelativeDistinguishedName ::= 4071 SET SIZE (1 .. MAX) OF AttributeTypeAndValue 4073 -- Directory string type -- 4075 DirectoryString ::= CHOICE { 4076 teletexString TeletexString (SIZE (1..MAX)), 4077 printableString PrintableString (SIZE (1..MAX)), 4078 universalString UniversalString (SIZE (1..MAX)), 4079 utf8String UTF8String (SIZE (1..MAX)), 4080 bmpString BMPString (SIZE(1..MAX)) } 4082 -- certificate and CRL specific structures begin here 4084 Certificate ::= SEQUENCE { 4085 tbsCertificate TBSCertificate, 4086 signatureAlgorithm AlgorithmIdentifier, 4087 signature BIT STRING } 4089 TBSCertificate ::= SEQUENCE { 4090 version [0] Version DEFAULT v1, 4091 serialNumber CertificateSerialNumber, 4092 signature AlgorithmIdentifier, 4093 issuer Name, 4094 validity Validity, 4095 subject Name, 4096 subjectPublicKeyInfo SubjectPublicKeyInfo, 4097 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 4098 -- If present, version shall be v2 or v3 4099 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 4100 -- If present, version shall be v2 or v3 4101 extensions [3] Extensions OPTIONAL 4102 -- If present, version shall be v3 -- } 4104 Version ::= INTEGER { v1(0), v2(1), v3(2) } 4106 CertificateSerialNumber ::= INTEGER 4108 Validity ::= SEQUENCE { 4109 notBefore Time, 4110 notAfter Time } 4112 Time ::= CHOICE { 4113 utcTime UTCTime, 4114 generalTime GeneralizedTime } 4116 UniqueIdentifier ::= BIT STRING 4118 SubjectPublicKeyInfo ::= SEQUENCE { 4119 algorithm AlgorithmIdentifier, 4120 subjectPublicKey BIT STRING } 4122 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 4124 Extension ::= SEQUENCE { 4125 extnID OBJECT IDENTIFIER, 4126 critical BOOLEAN DEFAULT FALSE, 4127 extnValue OCTET STRING } 4129 -- CRL structures 4131 CertificateList ::= SEQUENCE { 4132 tbsCertList TBSCertList, 4133 signatureAlgorithm AlgorithmIdentifier, 4134 signature BIT STRING } 4136 TBSCertList ::= SEQUENCE { 4137 version Version OPTIONAL, 4138 -- if present, shall be v2 4139 signature AlgorithmIdentifier, 4140 issuer Name, 4141 thisUpdate Time, 4142 nextUpdate Time OPTIONAL, 4143 revokedCertificates SEQUENCE OF SEQUENCE { 4144 userCertificate CertificateSerialNumber, 4145 revocationDate Time, 4146 crlEntryExtensions Extensions OPTIONAL 4147 -- if present, shall be v2 4148 } OPTIONAL, 4149 crlExtensions [0] Extensions OPTIONAL 4150 -- if present, shall be v2 -- } 4152 -- Version, Time, CertificateSerialNumber, and Extensions were 4153 -- defined earlier for use in the certificate structure 4155 AlgorithmIdentifier ::= SEQUENCE { 4156 algorithm OBJECT IDENTIFIER, 4157 parameters ANY DEFINED BY algorithm OPTIONAL } 4158 -- contains a value of the type 4159 -- registered for use with the 4160 -- algorithm object identifier value 4162 -- x400 address syntax starts here 4163 -- OR Names 4165 ORAddress ::= SEQUENCE { 4166 built-in-standard-attributes BuiltInStandardAttributes, 4167 built-in-domain-defined-attributes 4168 BuiltInDomainDefinedAttributes OPTIONAL, 4169 -- see also teletex-domain-defined-attributes 4170 extension-attributes ExtensionAttributes OPTIONAL } 4171 -- The OR-address is semantically absent from the OR-name if the 4172 -- built-in-standard-attribute sequence is empty and the 4173 -- built-in-domain-defined-attributes and extension-attributes are 4174 -- both omitted. 4176 -- Built-in Standard Attributes 4178 BuiltInStandardAttributes ::= SEQUENCE { 4179 country-name CountryName OPTIONAL, 4180 administration-domain-name AdministrationDomainName OPTIONAL, 4181 network-address [0] NetworkAddress OPTIONAL, 4182 -- see also extended-network-address 4183 terminal-identifier [1] TerminalIdentifier OPTIONAL, 4184 private-domain-name [2] PrivateDomainName OPTIONAL, 4185 organization-name [3] OrganizationName OPTIONAL, 4186 -- see also teletex-organization-name 4187 numeric-user-identifier [4] NumericUserIdentifier OPTIONAL, 4188 personal-name [5] PersonalName OPTIONAL, 4189 -- see also teletex-personal-name 4190 organizational-unit-names [6] OrganizationalUnitNames OPTIONAL 4191 -- see also teletex-organizational-unit-names -- } 4193 CountryName ::= [APPLICATION 1] CHOICE { 4194 x121-dcc-code NumericString 4195 (SIZE (ub-country-name-numeric-length)), 4196 iso-3166-alpha2-code PrintableString 4197 (SIZE (ub-country-name-alpha-length)) } 4199 AdministrationDomainName ::= [APPLICATION 2] CHOICE { 4200 numeric NumericString (SIZE (0..ub-domain-name-length)), 4201 printable PrintableString (SIZE (0..ub-domain-name-length)) } 4203 NetworkAddress ::= X121Address -- see also extended-network-address 4205 X121Address ::= NumericString (SIZE (1..ub-x121-address-length)) 4207 TerminalIdentifier ::= PrintableString (SIZE (1..ub-terminal-id-length)) 4209 PrivateDomainName ::= CHOICE { 4210 numeric NumericString (SIZE (1..ub-domain-name-length)), 4211 printable PrintableString (SIZE (1..ub-domain-name-length)) } 4213 OrganizationName ::= PrintableString 4214 (SIZE (1..ub-organization-name-length)) 4215 -- see also teletex-organization-name 4217 NumericUserIdentifier ::= NumericString 4218 (SIZE (1..ub-numeric-user-id-length)) 4220 PersonalName ::= SET { 4221 surname [0] PrintableString (SIZE (1..ub-surname-length)), 4222 given-name [1] PrintableString 4223 (SIZE (1..ub-given-name-length)) OPTIONAL, 4224 initials [2] PrintableString (SIZE (1..ub-initials-length)) OPTIONAL, 4225 generation-qualifier [3] PrintableString 4226 (SIZE (1..ub-generation-qualifier-length)) OPTIONAL } 4227 -- see also teletex-personal-name 4229 OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units) 4230 OF OrganizationalUnitName 4231 -- see also teletex-organizational-unit-names 4233 OrganizationalUnitName ::= PrintableString (SIZE 4234 (1..ub-organizational-unit-name-length)) 4236 -- Built-in Domain-defined Attributes 4237 BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE 4238 (1..ub-domain-defined-attributes) OF 4239 BuiltInDomainDefinedAttribute 4241 BuiltInDomainDefinedAttribute ::= SEQUENCE { 4242 type PrintableString (SIZE 4243 (1..ub-domain-defined-attribute-type-length)), 4244 value PrintableString (SIZE 4245 (1..ub-domain-defined-attribute-value-length))} 4247 -- Extension Attributes 4249 ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF 4250 ExtensionAttribute 4252 ExtensionAttribute ::= SEQUENCE { 4253 extension-attribute-type [0] INTEGER (0..ub-extension-attributes), 4254 extension-attribute-value [1] 4255 ANY DEFINED BY extension-attribute-type } 4257 -- Extension types and attribute values 4258 -- 4260 common-name INTEGER ::= 1 4262 CommonName ::= PrintableString (SIZE (1..ub-common-name-length)) 4264 teletex-common-name INTEGER ::= 2 4266 TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length)) 4268 teletex-organization-name INTEGER ::= 3 4270 TeletexOrganizationName ::= 4271 TeletexString (SIZE (1..ub-organization-name-length)) 4273 teletex-personal-name INTEGER ::= 4 4275 TeletexPersonalName ::= SET { 4276 surname [0] TeletexString (SIZE (1..ub-surname-length)), 4277 given-name [1] TeletexString 4278 (SIZE (1..ub-given-name-length)) OPTIONAL, 4279 initials [2] TeletexString (SIZE (1..ub-initials-length)) OPTIONAL, 4280 generation-qualifier [3] TeletexString (SIZE 4281 (1..ub-generation-qualifier-length)) OPTIONAL } 4283 teletex-organizational-unit-names INTEGER ::= 5 4284 TeletexOrganizationalUnitNames ::= SEQUENCE SIZE 4285 (1..ub-organizational-units) OF TeletexOrganizationalUnitName 4287 TeletexOrganizationalUnitName ::= TeletexString 4288 (SIZE (1..ub-organizational-unit-name-length)) 4290 pds-name INTEGER ::= 7 4292 PDSName ::= PrintableString (SIZE (1..ub-pds-name-length)) 4294 physical-delivery-country-name INTEGER ::= 8 4296 PhysicalDeliveryCountryName ::= CHOICE { 4297 x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)), 4298 iso-3166-alpha2-code PrintableString 4299 (SIZE (ub-country-name-alpha-length)) } 4301 postal-code INTEGER ::= 9 4303 PostalCode ::= CHOICE { 4304 numeric-code NumericString (SIZE (1..ub-postal-code-length)), 4305 printable-code PrintableString (SIZE (1..ub-postal-code-length)) } 4307 physical-delivery-office-name INTEGER ::= 10 4309 PhysicalDeliveryOfficeName ::= PDSParameter 4311 physical-delivery-office-number INTEGER ::= 11 4313 PhysicalDeliveryOfficeNumber ::= PDSParameter 4315 extension-OR-address-components INTEGER ::= 12 4317 ExtensionORAddressComponents ::= PDSParameter 4319 physical-delivery-personal-name INTEGER ::= 13 4321 PhysicalDeliveryPersonalName ::= PDSParameter 4323 physical-delivery-organization-name INTEGER ::= 14 4325 PhysicalDeliveryOrganizationName ::= PDSParameter 4327 extension-physical-delivery-address-components INTEGER ::= 15 4329 ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter 4331 unformatted-postal-address INTEGER ::= 16 4332 UnformattedPostalAddress ::= SET { 4333 printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) OF 4334 PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL, 4335 teletex-string TeletexString 4336 (SIZE (1..ub-unformatted-address-length)) OPTIONAL } 4338 street-address INTEGER ::= 17 4340 StreetAddress ::= PDSParameter 4342 post-office-box-address INTEGER ::= 18 4344 PostOfficeBoxAddress ::= PDSParameter 4346 poste-restante-address INTEGER ::= 19 4348 PosteRestanteAddress ::= PDSParameter 4350 unique-postal-name INTEGER ::= 20 4352 UniquePostalName ::= PDSParameter 4354 local-postal-attributes INTEGER ::= 21 4356 LocalPostalAttributes ::= PDSParameter 4358 PDSParameter ::= SET { 4359 printable-string PrintableString 4360 (SIZE(1..ub-pds-parameter-length)) OPTIONAL, 4361 teletex-string TeletexString 4362 (SIZE(1..ub-pds-parameter-length)) OPTIONAL } 4364 extended-network-address INTEGER ::= 22 4366 ExtendedNetworkAddress ::= CHOICE { 4367 e163-4-address SEQUENCE { 4368 number [0] NumericString (SIZE (1..ub-e163-4-number-length)), 4369 sub-address [1] NumericString 4370 (SIZE (1..ub-e163-4-sub-address-length)) OPTIONAL }, 4371 psap-address [0] PresentationAddress } 4373 PresentationAddress ::= SEQUENCE { 4374 pSelector [0] EXPLICIT OCTET STRING OPTIONAL, 4375 sSelector [1] EXPLICIT OCTET STRING OPTIONAL, 4376 tSelector [2] EXPLICIT OCTET STRING OPTIONAL, 4377 nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING } 4379 terminal-type INTEGER ::= 23 4380 TerminalType ::= INTEGER { 4381 telex (3), 4382 teletex (4), 4383 g3-facsimile (5), 4384 g4-facsimile (6), 4385 ia5-terminal (7), 4386 videotex (8) } (0..ub-integer-options) 4388 -- Extension Domain-defined Attributes 4390 teletex-domain-defined-attributes INTEGER ::= 6 4392 TeletexDomainDefinedAttributes ::= SEQUENCE SIZE 4393 (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute 4395 TeletexDomainDefinedAttribute ::= SEQUENCE { 4396 type TeletexString 4397 (SIZE (1..ub-domain-defined-attribute-type-length)), 4398 value TeletexString 4399 (SIZE (1..ub-domain-defined-attribute-value-length)) } 4401 -- specifications of Upper Bounds shall be regarded as mandatory 4402 -- from Annex B of ITU-T X.411 Reference Definition of MTS Parameter 4403 -- Upper Bounds 4405 -- Upper Bounds 4406 ub-name INTEGER ::= 32768 4407 ub-common-name INTEGER ::= 64 4408 ub-locality-name INTEGER ::= 128 4409 ub-state-name INTEGER ::= 128 4410 ub-organization-name INTEGER ::= 64 4411 ub-organizational-unit-name INTEGER ::= 64 4412 ub-title INTEGER ::= 64 4413 ub-serialNumber INTEGER ::= 64 4414 ub-match INTEGER ::= 128 4416 ub-emailaddress-length INTEGER ::= 128 4418 ub-common-name-length INTEGER ::= 64 4419 ub-country-name-alpha-length INTEGER ::= 2 4420 ub-country-name-numeric-length INTEGER ::= 3 4421 ub-domain-defined-attributes INTEGER ::= 4 4422 ub-domain-defined-attribute-type-length INTEGER ::= 8 4423 ub-domain-defined-attribute-value-length INTEGER ::= 128 4424 ub-domain-name-length INTEGER ::= 16 4425 ub-extension-attributes INTEGER ::= 256 4426 ub-e163-4-number-length INTEGER ::= 15 4427 ub-e163-4-sub-address-length INTEGER ::= 40 4428 ub-generation-qualifier-length INTEGER ::= 3 4429 ub-given-name-length INTEGER ::= 16 4430 ub-initials-length INTEGER ::= 5 4431 ub-integer-options INTEGER ::= 256 4432 ub-numeric-user-id-length INTEGER ::= 32 4433 ub-organization-name-length INTEGER ::= 64 4434 ub-organizational-unit-name-length INTEGER ::= 32 4435 ub-organizational-units INTEGER ::= 4 4436 ub-pds-name-length INTEGER ::= 16 4437 ub-pds-parameter-length INTEGER ::= 30 4438 ub-pds-physical-address-lines INTEGER ::= 6 4439 ub-postal-code-length INTEGER ::= 16 4440 ub-surname-length INTEGER ::= 40 4441 ub-terminal-id-length INTEGER ::= 24 4442 ub-unformatted-address-length INTEGER ::= 180 4443 ub-x121-address-length INTEGER ::= 16 4445 -- Note - upper bounds on string types, such as TeletexString, are 4446 -- measured in characters. Excepting PrintableString or IA5String, a 4447 -- significantly greater number of octets will be required to hold 4448 -- such a value. As a minimum, 16 octets, or twice the specified upper 4449 -- bound, whichever is the larger, should be allowed for TeletexString. 4450 -- For UTF8String or UniversalString at least four times the upper 4451 -- bound should be allowed. 4453 END 4454 A.2 Implicitly Tagged Module, 1988 Syntax 4456 PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) 4457 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19)} 4459 DEFINITIONS IMPLICIT TAGS ::= 4461 BEGIN 4463 -- EXPORTS ALL -- 4465 IMPORTS 4466 id-pkix, id-pe, id-qt, id-kp, id-qt-unotice, id-qt-cps, 4467 id-ad, id-ad-ocsp, id-ad-caIssuers, 4468 -- delete following line if "new" types are supported -- 4469 BMPString, UniversalString, UTF8String, -- end "new" types 4470 ORAddress, Name, RelativeDistinguishedName, 4471 CertificateSerialNumber, 4472 CertificateList, AlgorithmIdentifier, ub-name, 4473 Attribute, DirectoryString 4474 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 4475 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 4476 id-mod(0) id-pkix1-explicit(1)}; 4478 -- ISO arc for standard certificate and CRL extensions 4480 id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 4482 -- authority key identifier OID and syntax 4484 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 4486 AuthorityKeyIdentifier ::= SEQUENCE { 4487 keyIdentifier [0] KeyIdentifier OPTIONAL, 4488 authorityCertIssuer [1] GeneralNames OPTIONAL, 4489 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 4490 -- authorityCertIssuer and authorityCertSerialNumber shall both 4491 -- be present or both be absent 4493 KeyIdentifier ::= OCTET STRING 4495 -- subject key identifier OID and syntax 4497 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 4499 SubjectKeyIdentifier ::= KeyIdentifier 4500 -- key usage extension OID and syntax 4502 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 4504 KeyUsage ::= BIT STRING { 4505 digitalSignature (0), 4506 nonRepudiation (1), 4507 keyEncipherment (2), 4508 dataEncipherment (3), 4509 keyAgreement (4), 4510 keyCertSign (5), 4511 cRLSign (6), 4512 encipherOnly (7), 4513 decipherOnly (8) } 4515 -- private key usage period extension OID and syntax 4517 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 4519 PrivateKeyUsagePeriod ::= SEQUENCE { 4520 notBefore [0] GeneralizedTime OPTIONAL, 4521 notAfter [1] GeneralizedTime OPTIONAL } 4522 -- either notBefore or notAfter shall be present 4524 -- certificate policies extension OID and syntax 4526 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 4528 anyPolicy OBJECT IDENTIFIER ::= {id-ce-certificatePolicies 0} 4530 CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 4532 PolicyInformation ::= SEQUENCE { 4533 policyIdentifier CertPolicyId, 4534 policyQualifiers SEQUENCE SIZE (1..MAX) OF 4535 PolicyQualifierInfo OPTIONAL } 4537 CertPolicyId ::= OBJECT IDENTIFIER 4539 PolicyQualifierInfo ::= SEQUENCE { 4540 policyQualifierId PolicyQualifierId, 4541 qualifier ANY DEFINED BY policyQualifierId } 4543 -- Implementations that recognize additional policy qualifiers shall 4544 -- augment the following definition for PolicyQualifierId 4546 PolicyQualifierId ::= 4547 OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) 4549 -- CPS pointer qualifier 4551 CPSuri ::= IA5String 4553 -- user notice qualifier 4555 UserNotice ::= SEQUENCE { 4556 noticeRef NoticeReference OPTIONAL, 4557 explicitText DisplayText OPTIONAL} 4559 NoticeReference ::= SEQUENCE { 4560 organization DisplayText, 4561 noticeNumbers SEQUENCE OF INTEGER } 4563 DisplayText ::= CHOICE { 4564 ia5String IA5String (SIZE (1..200)), 4565 visibleString VisibleString (SIZE (1..200)), 4566 bmpString BMPString (SIZE (1..200)), 4567 utf8String UTF8String (SIZE (1..200)) } 4569 -- policy mapping extension OID and syntax 4571 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 4573 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 4574 issuerDomainPolicy CertPolicyId, 4575 subjectDomainPolicy CertPolicyId } 4577 -- subject alternative name extension OID and syntax 4579 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 4581 SubjectAltName ::= GeneralNames 4583 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 4585 GeneralName ::= CHOICE { 4586 otherName [0] AnotherName, 4587 rfc822Name [1] IA5String, 4588 dNSName [2] IA5String, 4589 x400Address [3] ORAddress, 4590 directoryName [4] Name, 4591 ediPartyName [5] EDIPartyName, 4592 uniformResourceIdentifier [6] IA5String, 4593 iPAddress [7] OCTET STRING, 4594 registeredID [8] OBJECT IDENTIFIER } 4596 -- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as 4597 -- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax 4599 AnotherName ::= SEQUENCE { 4600 type-id OBJECT IDENTIFIER, 4601 value [0] EXPLICIT ANY DEFINED BY type-id } 4603 EDIPartyName ::= SEQUENCE { 4604 nameAssigner [0] DirectoryString OPTIONAL, 4605 partyName [1] DirectoryString } 4607 -- issuer alternative name extension OID and syntax 4609 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 4611 IssuerAltName ::= GeneralNames 4613 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 4615 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 4617 -- basic constraints extension OID and syntax 4619 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 4621 BasicConstraints ::= SEQUENCE { 4622 cA BOOLEAN DEFAULT FALSE, 4623 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 4625 -- name constraints extension OID and syntax 4627 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 4629 NameConstraints ::= SEQUENCE { 4630 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 4631 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 4633 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 4635 GeneralSubtree ::= SEQUENCE { 4636 base GeneralName, 4637 minimum [0] BaseDistance DEFAULT 0, 4638 maximum [1] BaseDistance OPTIONAL } 4640 BaseDistance ::= INTEGER (0..MAX) 4642 -- policy constraints extension OID and syntax 4644 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } 4645 PolicyConstraints ::= SEQUENCE { 4646 requireExplicitPolicy [0] SkipCerts OPTIONAL, 4647 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 4649 SkipCerts ::= INTEGER (0..MAX) 4651 -- CRL distribution points extension OID and syntax 4653 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31} 4655 CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 4657 DistributionPoint ::= SEQUENCE { 4658 distributionPoint [0] DistributionPointName OPTIONAL, 4659 reasons [1] ReasonFlags OPTIONAL, 4660 cRLIssuer [2] GeneralNames OPTIONAL } 4662 DistributionPointName ::= CHOICE { 4663 fullName [0] GeneralNames, 4664 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 4666 ReasonFlags ::= BIT STRING { 4667 unused (0), 4668 keyCompromise (1), 4669 cACompromise (2), 4670 affiliationChanged (3), 4671 superseded (4), 4672 cessationOfOperation (5), 4673 certificateHold (6) } 4675 -- extended key usage extension OID and syntax 4677 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 4679 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 4681 KeyPurposeId ::= OBJECT IDENTIFIER 4683 -- extended key purpose OIDs 4684 id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } 4685 id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } 4686 id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } 4687 id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } 4688 id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 } 4689 id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 } 4690 id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 } 4691 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 4692 -- inhibit any policy OID and syntax 4694 id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 } 4696 InhibitAnyPolicy ::= SkipCerts 4698 -- freshest (delta-)CRL extension OID and syntax 4700 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } 4702 FreshestCRL ::= CRLDistributionPoints 4704 -- authority info access 4706 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 4708 AuthorityInfoAccessSyntax ::= 4709 SEQUENCE SIZE (1..MAX) OF AccessDescription 4711 AccessDescription ::= SEQUENCE { 4712 accessMethod OBJECT IDENTIFIER, 4713 accessLocation GeneralName } 4715 -- CRL number extension OID and syntax 4717 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 4719 CRLNumber ::= INTEGER (0..MAX) 4721 -- issuing distribution point extension OID and syntax 4723 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 4725 IssuingDistributionPoint ::= SEQUENCE { 4726 distributionPoint [0] DistributionPointName OPTIONAL, 4727 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 4728 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 4729 onlySomeReasons [3] ReasonFlags OPTIONAL, 4730 indirectCRL [4] BOOLEAN DEFAULT FALSE } 4732 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 4734 -- deltaCRLIndicator ::= BaseCRLNumber 4736 BaseCRLNumber ::= CRLNumber 4738 -- CRL reasons extension OID and syntax 4739 id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 } 4741 CRLReason ::= ENUMERATED { 4742 unspecified (0), 4743 keyCompromise (1), 4744 cACompromise (2), 4745 affiliationChanged (3), 4746 superseded (4), 4747 cessationOfOperation (5), 4748 certificateHold (6), 4749 removeFromCRL (8) } 4751 -- certificate issuer CRL entry extension OID and syntax 4753 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } 4755 CertificateIssuer ::= GeneralNames 4757 -- hold instruction extension OID and syntax 4759 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 4761 HoldInstructionCode ::= OBJECT IDENTIFIER 4763 -- ANSI x9 holdinstructions 4765 -- ANSI x9 arc holdinstruction arc 4766 holdInstruction OBJECT IDENTIFIER ::= 4767 {joint-iso-itu-t(2) member-body(2) us(840) x9cm(10040) 2} 4769 -- ANSI X9 holdinstructions referenced by this standard 4770 id-holdinstruction-none OBJECT IDENTIFIER ::= 4771 {holdInstruction 1} -- deprecated 4772 id-holdinstruction-callissuer OBJECT IDENTIFIER ::= 4773 {holdInstruction 2} 4774 id-holdinstruction-reject OBJECT IDENTIFIER ::= 4775 {holdInstruction 3} 4777 -- invalidity date CRL entry extension OID and syntax 4779 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 4781 InvalidityDate ::= GeneralizedTime 4783 END 4784 Appendix B. ASN.1 Notes 4786 CAs MUST force the serialNumber to be a non-negative integer, that 4787 is, the sign bit in the DER encoding of the INTEGER value MUST be 4788 zero - this can be done by adding a leading (leftmost) `00'H octet if 4789 necessary. This removes a potential ambiguity in mapping between a 4790 string of octets and an integer value. 4792 As noted in section 4.1.2.2, serial numbers can be expected to 4793 contain long integers. Certificate users MUST be able to handle 4794 serialNumber values up to 20 octets in length. Conformant CAs MUST 4795 NOT use serialNumber values longer than 20 octets. 4797 The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 4798 constructs. A valid ASN.1 sequence will have zero or more entries. 4799 The SIZE (1..MAX) construct constrains the sequence to have at least 4800 one entry. MAX indicates the upper bound is unspecified. 4801 Implementations are free to choose an upper bound that suits their 4802 environment. 4804 The construct "positiveInt ::= INTEGER (0..MAX)" defines positiveInt 4805 as a subtype of INTEGER containing integers greater than or equal to 4806 zero. The upper bound is unspecified. Implementations are free to 4807 select an upper bound that suits their environment. 4809 The character string type PrintableString supports a very basic Latin 4810 character set: the lower case letters 'a' through 'z', upper case 4811 letters 'A' through 'Z', the digits '0' through '9', eleven special 4812 characters ' " ( ) + , - . / : ? and space. 4814 The character string type TeletexString is a superset of 4815 PrintableString. TeletexString supports a fairly standard (ascii- 4816 like) Latin character set, Latin characters with non-spacing accents 4817 and Japanese characters. 4819 The character string type UniversalString supports any of the 4820 characters allowed by ISO 10646-1. ISO 10646 is the Universal 4821 multiple-octet coded Character Set (UCS). ISO 10646-1 specifes the 4822 architecture and the "basic multilingual plane" - a large standard 4823 character set which includes all major world character standards. 4825 The character string type UTF8String will be introduced in the 1998 4826 version of ASN.1. UTF8String is a universal type and has been 4827 assigned tag number 12. The content of UTF8String was defined by RFC 4828 2044 and updated in RFC 2279, "UTF-8, a transformation Format of ISO 4829 10646." ISO is expected to formally add UTF8String to the list of 4830 choices for DirectoryString in 1998 as well. 4832 In anticipation of these changes, and in conformance with IETF Best 4833 Practices codified in RFC 2277, IETF Policy on Character Sets and 4834 Languages, this document includes UTF8String as a choice in 4835 DirectoryString and the CPS qualifier extensions. 4837 Implementers should note that the DER encoding of the SET OF values 4838 requires ordering of the encodings of the values. In particular, this 4839 issue arises with respect to distinguished names. 4841 Object Identifiers (OIDs) are used throught this specification to 4842 identify certificate policies, public key and signature algorithms, 4843 certificate extensions, etc. There is no maximum size for OIDs. 4844 This specification mandates support for OIDs which have arc elements 4845 with values that are less than 2^28, i.e. they MUST be between 0 and 4846 268,435,455 inclusive. This allows each arc element to be represented 4847 within a single 32 bit word. Implementations MUST also support OIDs 4848 where the length of the dotted decimal (see [LDAP], section 4.1.2) 4849 string representation can be up to 100 bytes (inclusive). 4850 Implementations MUST be able to handle OIDs with up to 20 elements 4851 (inclusive). CAs SHOULD NOT issue certificates which contain OIDs 4852 that breach these requirements. 4854 Appendix C. Examples 4856 This section contains four examples: three certificates and a CRL. 4857 The first two certificates and the CRL comprise a minimal 4858 certification path. 4860 Section C.1 contains an annotated hex dump of a "self-signed" 4861 certificate issued by a CA whose distinguished name is 4862 cn=us,o=gov,ou=nist. The certificate contains a DSA public key with 4863 parameters, and is signed by the corresponding DSA private key. 4865 Section C.2 contains an annotated hex dump of an end-entity 4866 certificate. The end entity certificate contains a DSA public key, 4867 and is signed by the private key corresponding to the "self-signed" 4868 certificate in section C.1. 4870 Section C.3 contains a dump of an end entity certificate which 4871 contains an RSA public key and is signed with RSA and MD5. This 4872 certificate is not part of the minimal certification path. 4874 Section C.4 contains an annotated hex dump of a CRL. The CRL is 4875 issued by the CA whose distinguished name is cn=us,o=gov,ou=nist and 4876 the list of revoked certificates includes the end entity certificate 4877 presented in C.2. 4879 The certificates were processed using Peter Gutman's dumpasn1 utility 4880 to generate the output. The source for the dumpasn1 utility is 4881 available at . The 4882 binaries for the certificates and CRLs are available at 4883 . 4885 C.1 Certificate 4887 This section contains an annotated hex dump of a 699 byte version 3 4888 certificate. The certificate contains the following information: 4889 (a) the serial number is 23 (17 hex); 4890 (b) the certificate is signed with DSA and the SHA-1 hash algorithm; 4891 (c) the issuer's distinguished name is OU=NIST; O=gov; C=US 4892 (d) and the subject's distinguished name is OU=NIST; O=gov; C=US 4893 (e) the certificate was issued on June 30, 1997 and will expire on 4894 December 31, 1997; 4895 (f) the certificate contains a 1024 bit DSA public key with 4896 parameters; 4897 (g) the certificate contains a subject key identifier extension; and 4898 (h) the certificate is a CA certificate (as indicated through the 4899 basic constraints extension.) 4901 0 30 701: SEQUENCE { 4902 4 30 637: SEQUENCE { 4903 8 A0 3: [0] { 4904 10 02 1: INTEGER 2 4905 : } 4906 13 02 1: INTEGER 23 4907 16 30 9: SEQUENCE { 4908 18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 4909 : } 4910 27 30 42: SEQUENCE { 4911 29 31 11: SET { 4912 31 30 9: SEQUENCE { 4913 33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 4914 38 13 2: PrintableString 'US' 4915 : } 4916 : } 4917 42 31 12: SET { 4918 44 30 10: SEQUENCE { 4919 46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 4920 51 13 3: PrintableString 'gov' 4921 : } 4922 : } 4923 56 31 13: SET { 4924 58 30 11: SEQUENCE { 4925 60 06 3: OBJECT IDENTIFIER 4926 organizationalUnitName (2 5 4 11) 4928 65 13 4: PrintableString 'NIST' 4929 : } 4930 : } 4931 : } 4932 71 30 30: SEQUENCE { 4933 73 17 13: UTCTime '970630000000Z' 4934 88 17 13: UTCTime '971231000000Z' 4935 : } 4936 103 30 42: SEQUENCE { 4937 105 31 11: SET { 4938 107 30 9: SEQUENCE { 4939 109 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 4940 114 13 2: PrintableString 'US' 4941 : } 4942 : } 4943 118 31 12: SET { 4944 120 30 10: SEQUENCE { 4945 122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 4946 127 13 3: PrintableString 'gov' 4947 : } 4948 : } 4949 132 31 13: SET { 4950 134 30 11: SEQUENCE { 4951 136 06 3: OBJECT IDENTIFIER 4952 organizationalUnitName (2 5 4 11) 4953 141 13 4: PrintableString 'NIST' 4954 : } 4955 : } 4956 : } 4957 147 30 440: SEQUENCE { 4958 151 30 300: SEQUENCE { 4959 155 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) 4960 164 30 287: SEQUENCE { 4961 168 02 129: INTEGER 4962 : 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC FB 95 4963 : 32 AC 01 12 33 B9 E0 1C AD 90 9B BC 48 54 9E F3 4964 : 94 77 3C 2C 71 35 55 E6 FE 4F 22 CB D5 D8 3E 89 4965 : 93 33 4D FC BD 4F 41 64 3E A2 98 70 EC 31 B4 50 4966 : DE EB F1 98 28 0A C9 3E 44 B3 FD 22 97 96 83 D0 4967 : 18 A3 E3 BD 35 5B FF EE A3 21 72 6A 7B 96 DA B9 4968 : 3F 1E 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A 4969 : FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48 63 FE 4970 : 43 4971 300 02 21: INTEGER 4972 : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA 55 F7 4973 : 7D 57 74 81 E5 4974 323 02 129: INTEGER 4975 : 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91 C0 8E 4976 : 47 F1 0A C3 01 47 C2 44 42 36 A9 92 81 DE 57 C5 4977 : E0 68 86 58 00 7B 1F F9 9B 77 A1 C5 10 A5 80 91 4978 : 78 51 51 3C F6 FC FC CC 46 C6 81 78 92 84 3D F4 4979 : 93 3D 0C 38 7E 1A 5B 99 4E AB 14 64 F6 0C 21 22 4980 : 4E 28 08 9C 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 4981 : 39 A2 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF 4982 : F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE 1E 57 4983 : 18 4984 : } 4985 : } 4986 455 03 133: BIT STRING 0 unused bits 4987 : 02 81 81 00 B5 9E 1F 49 04 47 D1 DB F5 3A DD CA 4988 : 04 75 E8 DD 75 F6 9B 8A B1 97 D6 59 69 82 D3 03 4989 : 4D FD 3B 36 5F 4A F2 D1 4E C1 07 F5 D1 2A D3 78 4990 : 77 63 56 EA 96 61 4D 42 0B 7A 1D FB AB 91 A4 CE 4991 : DE EF 77 C8 E5 EF 20 AE A6 28 48 AF BE 69 C3 6A 4992 : A5 30 F2 C2 B9 D9 82 2B 7D D9 C4 84 1F DE 0D E8 4993 : 54 D7 1B 99 2E B3 D0 88 F6 D6 63 9B A7 E2 0E 82 4994 : D4 3B 8A 68 1B 06 56 31 59 0B 49 EB 99 A5 D5 81 4995 : 41 7B C9 55 4996 : } 4997 591 A3 52: [3] { 4998 593 30 50: SEQUENCE { 4999 595 30 31: SEQUENCE { 5000 597 06 3: OBJECT IDENTIFIER 5001 subjectKeyIdentifier (2 5 29 14) 5002 602 04 24: OCTET STRING 5003 : 04 16 04 14 E7 26 C5 54 CD 5B A3 6F 35 68 95 AA 5004 : D5 FF 1C 21 E4 22 75 D6 5005 : } 5006 628 30 15: SEQUENCE { 5007 630 06 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19) 5008 635 01 1: BOOLEAN TRUE 5009 638 04 5: OCTET STRING 5010 : 30 03 01 01 FF 5011 : } 5012 : } 5013 : } 5014 : } 5015 645 30 9: SEQUENCE { 5016 647 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5017 : } 5018 656 03 47: BIT STRING 0 unused bits 5019 : 30 2C 02 14 6A F9 3F 72 30 7F 45 DC E5 50 C1 5E 5020 : 94 A0 6D C7 92 4C E5 E1 02 14 6F 61 B8 65 F7 AA 5021 : DF 46 1B F7 39 0D 0D 88 9E FE B6 83 F7 1A 5022 : } 5024 C.2 Certificate 5026 This section contains an annotated hex dump of a 730 byte version 3 5027 certificate. The certificate contains the following information: 5028 (a) the serial number is 18 (12 hex); 5029 (b) the certificate is signed with DSA and the SHA-1 hash algorithm; 5030 (c) the issuer's distinguished name is OU=nist; O=gov; C=US 5031 (d) and the subject's distinguished name is CN=Tim Polk; OU=nist; 5032 O=gov; C=US 5033 (e) the certificate was valid from July 30, 1997 through December 1, 5034 1997; 5035 (f) the certificate contains a 1024 bit DSA public key; 5036 (g) the certificate is an end entity certificate, as the basic 5037 constraints extension is not present; 5038 (h) the certificate contains an authority key identifier extension; 5039 and 5040 (i) the certificate includes one alternative name - an RFC 822 5041 address. 5043 0 30 734: SEQUENCE { 5044 4 30 669: SEQUENCE { 5045 8 A0 3: [0] { 5046 10 02 1: INTEGER 2 5047 : } 5048 13 02 1: INTEGER 18 5049 16 30 9: SEQUENCE { 5050 18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5051 : } 5052 27 30 42: SEQUENCE { 5053 29 31 11: SET { 5054 31 30 9: SEQUENCE { 5055 33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5056 38 13 2: PrintableString 'US' 5057 : } 5058 : } 5059 42 31 12: SET { 5060 44 30 10: SEQUENCE { 5061 46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5062 51 13 3: PrintableString 'gov' 5063 : } 5064 : } 5065 56 31 13: SET { 5066 58 30 11: SEQUENCE { 5067 60 06 3: OBJECT IDENTIFIER 5068 organizationalUnitName (2 5 4 11) 5069 65 13 4: PrintableString 'NIST' 5070 : } 5071 : } 5072 : } 5073 71 30 30: SEQUENCE { 5074 73 17 13: UTCTime '970730000000Z' 5075 88 17 13: UTCTime '971201000000Z' 5076 : } 5077 103 30 61: SEQUENCE { 5078 105 31 11: SET { 5079 107 30 9: SEQUENCE { 5080 109 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5081 114 13 2: PrintableString 'US' 5082 : } 5083 : } 5084 118 31 12: SET { 5085 120 30 10: SEQUENCE { 5086 122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5087 127 13 3: PrintableString 'gov' 5088 : } 5089 : } 5090 132 31 13: SET { 5091 134 30 11: SEQUENCE { 5092 136 06 3: OBJECT IDENTIFIER 5093 organizationalUnitName (2 5 4 11) 5094 141 13 4: PrintableString 'NIST' 5095 : } 5096 : } 5097 147 31 17: SET { 5098 149 30 15: SEQUENCE { 5099 151 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 5100 156 13 8: PrintableString 'Tim Polk' 5101 : } 5102 : } 5103 : } 5104 166 30 439: SEQUENCE { 5105 170 30 300: SEQUENCE { 5106 174 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) 5107 183 30 287: SEQUENCE { 5108 187 02 129: INTEGER 5109 : 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC FB 95 5110 : 32 AC 01 12 33 B9 E0 1C AD 90 9B BC 48 54 9E F3 5111 : 94 77 3C 2C 71 35 55 E6 FE 4F 22 CB D5 D8 3E 89 5112 : 93 33 4D FC BD 4F 41 64 3E A2 98 70 EC 31 B4 50 5113 : DE EB F1 98 28 0A C9 3E 44 B3 FD 22 97 96 83 D0 5114 : 18 A3 E3 BD 35 5B FF EE A3 21 72 6A 7B 96 DA B9 5115 : 3F 1E 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A 5116 : FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48 63 FE 5117 : 43 5118 319 02 21: INTEGER 5119 : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA 55 F7 5120 : 7D 57 74 81 E5 5121 342 02 129: INTEGER 5122 : 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91 C0 8E 5123 : 47 F1 0A C3 01 47 C2 44 42 36 A9 92 81 DE 57 C5 5124 : E0 68 86 58 00 7B 1F F9 9B 77 A1 C5 10 A5 80 91 5125 : 78 51 51 3C F6 FC FC CC 46 C6 81 78 92 84 3D F4 5126 : 93 3D 0C 38 7E 1A 5B 99 4E AB 14 64 F6 0C 21 22 5127 : 4E 28 08 9C 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 5128 : 39 A2 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF 5129 : F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE 1E 57 5130 : 18 5131 : } 5132 : } 5133 474 03 132: BIT STRING 0 unused bits 5134 : 02 81 80 30 B6 75 F7 7C 20 31 AE 38 BB 7E 0D 2B 5135 : AB A0 9C 4B DF 20 D5 24 13 3C CD 98 E5 5F 6C B7 5136 : C1 BA 4A BA A9 95 80 53 F0 0D 72 DC 33 37 F4 01 5137 : 0B F5 04 1F 9D 2E 1F 62 D8 84 3A 9B 25 09 5A 2D 5138 : C8 46 8E 2B D4 F5 0D 3B C7 2D C6 6C B9 98 C1 25 5139 : 3A 44 4E 8E CA 95 61 35 7C CE 15 31 5C 23 13 1E 5140 : A2 05 D1 7A 24 1C CB D3 72 09 90 FF 9B 9D 28 C0 5141 : A1 0A EC 46 9F 0D B8 D0 DC D0 18 A6 2B 5E F9 8F 5142 : B5 95 BE 5143 : } 5144 609 A3 66: [3] { 5145 611 30 64: SEQUENCE { 5146 613 30 25: SEQUENCE { 5147 615 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 5148 620 04 18: OCTET STRING 5149 : 30 10 81 0E 77 70 6F 6C 6B 40 6E 69 73 74 2E 67 5150 : 6F 76 5151 : } 5152 640 30 35: SEQUENCE { 5153 642 06 3: OBJECT IDENTIFIER 5154 authorityKeyIdentifier (2 5 29 35) 5155 647 04 28: OCTET STRING 5156 : 30 1A 80 18 04 16 04 14 E7 26 C5 54 CD 5B A3 6F 5157 : 35 68 95 AA D5 FF 1C 21 E4 22 75 D6 5158 : } 5159 : } 5160 : } 5161 : } 5162 677 30 9: SEQUENCE { 5163 679 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5164 : } 5165 688 03 48: BIT STRING 0 unused bits 5166 : 30 2D 02 14 37 FC 44 BF 7F 8D 18 1F 40 04 2F CF 5167 : EA CC 22 B2 16 01 FF 13 02 15 00 97 D0 24 96 0F 5168 : 64 8A C3 8D 41 B2 0E B9 26 D5 31 D1 A0 F1 BC 5169 : } 5171 C.3 End-Entity Certificate Using RSA 5173 This section contains an annotated hex dump of a 675 byte version 3 5174 certificate. The certificate contains the following information: 5175 (a) the serial number is 256; 5176 (b) the certificate is signed with RSA and the MD2 hash algorithm; 5177 (c) the issuer's distinguished name is OU=Dept. Arquitectura de 5178 Computadors; O=Universitat Politecnica de Catalunya; C=ES 5179 (d) and the subject's distinguished name is CN=Francisco Jordan; 5180 OU=Dept. Arquitectura de Computadors; O=Universitat Politecnica de 5181 Catalunya; C=ES 5182 (e) the certificate was issued on May 21, 1996 and expired on May 21, 5183 1997; 5184 (f) the certificate contains a 768 bit RSA public key; 5185 (g) the certificate is an end entity certificate (not a CA 5186 certificate); 5187 (h) the certificate includes an alternative subject name and an 5188 alternative issuer name - bothe are URLs; 5189 (i) the certificate include an authority key identifier and 5190 certificate policies extensions; and 5191 (j) the certificate includes a critical key usage extension 5192 specifying the public is intended for generation of digital 5193 signatures. 5195 0 30 654: SEQUENCE { 5196 4 30 503: SEQUENCE { 5197 8 A0 3: [0] { 5198 10 02 1: INTEGER 2 5199 : } 5200 13 02 2: INTEGER 256 5201 17 30 13: SEQUENCE { 5202 19 06 9: OBJECT IDENTIFIER 5203 : sha1withRSAEncryption (1 2 840 113549 1 1 5) 5204 30 05 0: NULL 5205 : } 5206 32 30 42: SEQUENCE { 5207 34 31 11: SET { 5208 36 30 9: SEQUENCE { 5209 38 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5210 43 13 2: PrintableString 'US' 5211 : } 5212 : } 5213 47 31 12: SET { 5214 49 30 10: SEQUENCE { 5215 51 06 3: OBJECT IDENTIFIER 5216 organizationalUnitName (2 5 4 11) 5217 56 13 3: PrintableString 'gov' 5218 : } 5219 : } 5220 61 31 13: SET { 5221 63 30 11: SEQUENCE { 5222 65 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5223 70 13 4: PrintableString 'NIST' 5224 : } 5225 : } 5226 : } 5227 76 30 30: SEQUENCE { 5228 78 17 13: UTCTime '960521095826Z' 5229 93 17 13: UTCTime '970521095826Z' 5230 : } 5231 108 30 61: SEQUENCE { 5232 110 31 11: SET { 5233 112 30 9: SEQUENCE { 5234 114 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5235 119 13 2: PrintableString 'US' 5236 : } 5237 : } 5238 123 31 12: SET { 5239 125 30 10: SEQUENCE { 5240 127 06 3: OBJECT IDENTIFIER 5241 organizationalUnitName (2 5 4 11) 5242 132 13 3: PrintableString 'gov' 5243 : } 5244 : } 5245 137 31 13: SET { 5246 139 30 11: SEQUENCE { 5247 141 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5248 146 13 4: PrintableString 'NIST' 5249 : } 5250 : } 5251 152 31 17: SET { 5252 154 30 15: SEQUENCE { 5253 156 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 5254 161 13 8: PrintableString 'Tim Polk' 5255 : } 5256 : } 5257 : } 5258 171 30 159: SEQUENCE { 5259 174 30 13: SEQUENCE { 5260 176 06 9: OBJECT IDENTIFIER 5261 rsaEncryption (1 2 840 113549 1 1 1) 5262 187 05 0: NULL 5263 : } 5265 189 03 141: BIT STRING 0 unused bits 5266 : 30 81 89 02 81 81 00 E1 CE 06 C9 D7 00 DF 65 27 5267 : 45 1E 63 6A 09 A0 A0 10 4B AF DF 9D 36 1D 44 1F 5268 : B7 07 5D 36 92 09 6A 1A 96 C7 4E D9 86 0D 0F 77 5269 : 94 F5 82 62 68 9A F2 D7 76 F5 9A 35 C7 B3 7F 4F 5270 : BE 64 CF A3 0C B3 84 32 80 F5 CA 77 29 C9 76 0B 5271 : 4C 38 19 EE 61 6F BA 68 E0 03 85 46 34 AB 84 64 5272 : 7F 43 69 02 C0 20 86 BD B1 D4 AD 21 A9 1A 8F CF 5273 : 96 83 86 92 57 5B 43 09 28 4C F2 5A 04 AD E5 DE 5274 : 9E 4F E8 38 3C F0 89 02 03 01 00 01 5275 : } 5276 333 A3 175: [3] { 5277 336 30 172: SEQUENCE { 5278 339 30 63: SEQUENCE { 5279 341 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 5280 346 04 56: OCTET STRING 5281 : 30 36 86 34 68 74 74 70 3A 2F 2F 77 77 77 2E 69 5282 : 74 6C 2E 6E 69 73 74 2E 67 6F 76 2F 64 69 76 38 5283 : 39 33 2F 73 74 61 66 66 2F 70 6F 6C 6B 2F 69 6E 5284 : 64 65 78 2E 68 74 6D 6C 5285 : } 5286 404 30 31: SEQUENCE { 5287 406 06 3: OBJECT IDENTIFIER issuerAltName (2 5 29 18) 5288 411 04 24: OCTET STRING 5289 : 30 16 86 14 68 74 74 70 3A 2F 2F 77 77 77 2E 6E 5290 : 69 73 74 2E 67 6F 76 2F 5291 : } 5292 437 30 31: SEQUENCE { 5293 439 06 3: OBJECT IDENTIFIER 5294 authorityKeyIdentifier (2 5 29 35) 5295 444 04 24: OCTET STRING 5296 : 30 16 80 14 30 12 80 10 0E 6B 3A BF 04 EA 04 C3 5297 : 0E 6B 3A BF 04 EA 04 C3 5298 : } 5299 470 30 23: SEQUENCE { 5300 472 06 3: OBJECT IDENTIFIER 5301 certificatePolicies (2 5 29 32) 5302 477 04 16: OCTET STRING 5303 : 30 0E 30 0C 06 0A 60 86 48 01 65 03 02 01 30 09 5304 : } 5305 495 30 14: SEQUENCE { 5306 497 06 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) 5307 502 01 1: BOOLEAN TRUE 5308 505 04 4: OCTET STRING 5309 : 03 02 07 80 5310 : } 5311 : } 5312 : } 5313 : } 5314 511 30 13: SEQUENCE { 5315 513 06 9: OBJECT IDENTIFIER 5316 : sha1withRSAEncryption (1 2 840 113549 1 1 5) 5317 524 05 0: NULL 5318 : } 5319 526 03 129: BIT STRING 0 unused bits 5320 : C1 25 6F AB 72 C0 5D DA E4 2F D5 E1 B0 25 D8 B4 5321 : F1 82 95 D6 0D A5 4E 4F A1 23 E1 13 A4 9C 3D C5 5322 : 7F FD 05 EC 75 06 30 66 97 75 A6 5D 8F 97 BA B4 5323 : EC A9 43 19 8D B7 54 FD E9 AD 43 B8 3C 8B D3 9E 5324 : C7 C7 27 E3 1A AD D3 79 AC 65 5A 52 78 C4 D0 43 5325 : 81 50 F7 8A BA E2 30 1A 6D D0 78 A0 4E AE 2E 79 5326 : 37 0C 93 05 5C D1 9C 1B B2 62 73 D1 EA 50 B7 84 5327 : 29 92 74 34 CF BA AA 2C 4D 43 59 EF 98 0C 41 6C 5328 : } 5330 C.4 Certificate Revocation List 5332 This section contains an annotated hex dump of a version 2 CRL with 5333 one extension (cRLNumber). The CRL was issued by OU=nist;O=gov;C=us 5334 on July 7, 1996; the next scheduled issuance was August 7, 1996. The 5335 CRL includes one revoked certificates: serial number 18 (12 hex). 5336 The CRL itself is number 18, and it was signed with DSA and SHA-1. 5338 0 30 203: SEQUENCE { 5339 3 30 140: SEQUENCE { 5340 6 02 1: INTEGER 1 5341 9 30 9: SEQUENCE { 5342 11 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5343 : } 5344 20 30 42: SEQUENCE { 5345 22 31 11: SET { 5346 24 30 9: SEQUENCE { 5347 26 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5348 31 13 2: PrintableString 'US' 5349 : } 5350 : } 5351 35 31 12: SET { 5352 37 30 10: SEQUENCE { 5353 39 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5354 44 13 3: PrintableString 'gov' 5355 : } 5356 : } 5357 49 31 13: SET { 5358 51 30 11: SEQUENCE { 5359 53 06 3: OBJECT IDENTIFIER 5360 organizationalUnitName (2 5 4 11) 5362 58 13 4: PrintableString 'NIST' 5363 : } 5364 : } 5365 : } 5366 64 17 13: UTCTime '970807000000Z' 5367 79 17 13: UTCTime '970907000000Z' 5368 94 30 34: SEQUENCE { 5369 96 30 32: SEQUENCE { 5370 98 02 1: INTEGER 18 5371 101 17 13: UTCTime '970731000000Z' 5372 116 30 12: SEQUENCE { 5373 118 30 10: SEQUENCE { 5374 120 06 3: OBJECT IDENTIFIER cRLReason (2 5 29 21) 5375 125 04 3: OCTET STRING 5376 : 0A 01 01 5377 : } 5378 : } 5379 : } 5380 : } 5381 130 A0 14: [0] { 5382 132 30 12: SEQUENCE { 5383 134 30 10: SEQUENCE { 5384 136 06 3: OBJECT IDENTIFIER cRLNumber (2 5 29 20) 5385 141 04 3: OCTET STRING 5386 : 02 01 12 5387 : } 5388 : } 5389 : } 5390 : } 5391 146 30 9: SEQUENCE { 5392 148 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5393 : } 5394 157 03 47: BIT STRING 0 unused bits 5395 : 30 2C 02 14 79 1F F6 93 0B 84 06 D6 A0 7C 8D 68 5396 : A7 52 2E 5F 3F 89 9B 4B 02 14 66 D4 B5 2A 68 36 5397 : 9B 72 88 58 E3 89 19 AD 81 89 2E 96 BB CC 5398 : } 5400 Appendix D. Author Addresses: 5402 Russell Housley 5403 SPYRUS 5404 381 Elden Street 5405 Suite 1120 5406 Herndon, VA 20170 5407 USA 5408 housley@spyrus.com 5410 Warwick Ford 5411 VeriSign, Inc. 5412 One Alewife Center 5413 Cambridge, MA 02140 5414 USA 5415 wford@verisign.com 5417 Tim Polk 5418 NIST 5419 Building 820, Room 426 5420 Gaithersburg, MD 20899 5421 USA 5422 wpolk@nist.gov 5424 David Solo 5425 Citicorp 5426 666 Fifth Ave, 3rd Floor 5427 New York, NY 10103 5428 USA 5429 david.solo@citicorp.com 5431 Appendix E. Full Copyright Statement 5433 Copyright (C) The Internet Society (date). All Rights Reserved. 5435 This document and translations of it may be copied and furnished to 5436 others, and derivative works that comment on or otherwise explain it 5437 or assist in its implementation may be prepared, copied, published 5438 and distributed, in whole or in part, without restriction of any 5439 kind, provided that the above copyright notice and this paragraph are 5440 included on all such copies and derivative works. In addition, the 5441 ASN.1 modules presented in Appendices A and B may be used in whole or 5442 in part without inclusion of the copyright notice. However, this 5443 document itself may not be modified in any way, such as by removing 5444 the copyright notice or references to the Internet Society or other 5445 Internet organizations, except as needed for the purpose of 5446 developing Internet standards in which case the procedures for 5447 copyrights defined in the Internet Standards process shall be 5448 followed, or as required to translate it into languages other than 5449 English. 5451 The limited permissions granted above are perpetual and will not be 5452 revoked by the Internet Society or its successors or assigns. This 5453 document and the information contained herein is provided on an "AS 5454 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 5455 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 5456 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 5457 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 5458 OR FITNESS FOR A PARTICULAR PURPOSE.