idnits 2.17.00 (12 Aug 2021) /tmp/idnits42450/draft-ietf-pkix-new-part1-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 118 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 118 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There 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 602 has weird spacing: '...issuing a cer...' == Line 613 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 5372 -- Looks like a reference, but probably isn't: '1' on line 4718 -- Looks like a reference, but probably isn't: '2' on line 4719 -- Looks like a reference, but probably isn't: '3' on line 5267 == Missing Reference: 'ISO 8859-1' is mentioned on line 908, but not defined -- Looks like a reference, but probably isn't: '4' on line 4721 -- Looks like a reference, but probably isn't: '5' on line 4582 -- Looks like a reference, but probably isn't: '6' on line 4583 -- Looks like a reference, but probably isn't: '7' on line 4584 -- Looks like a reference, but probably isn't: '8' on line 4585 == Missing Reference: 'RFC1738' is mentioned on line 2524, but not defined ** Obsolete undefined reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) == Missing Reference: 'RFC1778' is mentioned on line 2524, but not defined ** Obsolete undefined reference: RFC 1778 (Obsoleted by RFC 3494) == Missing Reference: 'UNIVERSAL 28' is mentioned on line 3875, but not defined == Missing Reference: 'UNIVERSAL 30' is mentioned on line 3878, but not defined == Missing Reference: 'UNIVERSAL 12' is mentioned on line 3882, but not defined == Missing Reference: 'APPLICATION 1' is mentioned on line 4181, but not defined == Missing Reference: 'APPLICATION 2' is mentioned on line 4187, but not defined == Missing Reference: 'LDAP' is mentioned on line 4839, but not defined == Unused Reference: 'RFC 1423' is defined on line 3628, but no explicit reference was found in the text == Unused Reference: 'RFC 1778' is defined on line 3642, but no explicit reference was found in the text == Unused Reference: 'RFC 1883' is defined on line 3646, but no explicit reference was found in the text == Unused Reference: 'RFC 2119' is defined on line 3649, but no explicit reference was found in the text == Unused Reference: 'RFC 2277' is defined on line 3657, but no explicit reference was found in the text == Unused Reference: 'RFC 2279' is defined on line 3660, but no explicit reference was found in the text == Unused Reference: 'PKIX TSA' is defined on line 3699, 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 November, 2000 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 (1998). All Rights Reserved. 40 Abstract 42 This is the first draft of a specification based upon RFC 2459. When 43 complete, this specification will obsolete RFC 2459. This 44 specification includes numerous 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 This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use 65 in the Internet. An overview of the approach and model are provided 66 as an introduction. The X.509 v3 certificate format is described in 67 detail, with additional information regarding the format and 68 semantics of Internet name forms (e.g., IP addresses). Standard 69 certificate extensions are described and one new Internet-specific 70 extension is defined. A required set of certificate extensions is 71 specified. The X.509 v2 CRL format is described and a required 72 extension set is defined as well. An algorithm for X.509 certificate 73 path validation is described. Supplemental information is provided 74 describing the format of public keys and digital signatures in X.509 75 certificates for common Internet public key encryption algorithms 76 (i.e., RSA, DSA, and Diffie-Hellman). ASN.1 modules and examples are 77 provided in the appendices. 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in RFC 2119. 83 Please send comments on this document to the ietf-pkix@imc.org mail 84 list. 86 Table of Contents 88 1 Introduction ................................................ 6 89 2 Requirements and Assumptions ................................ 7 90 2.1 Communication and Topology ................................ 7 91 2.2 Acceptability Criteria .................................... 8 92 2.3 User Expectations ......................................... 8 93 2.4 Administrator Expectations ................................ 8 94 3 Overview of Approach ........................................ 8 95 3.1 X.509 Version 3 Certificate ............................... 10 96 3.2 Certification Paths and Trust ............................. 11 97 3.3 Revocation ................................................ 13 98 3.4 Operational Protocols ..................................... 14 99 3.5 Management Protocols ...................................... 14 100 4 Certificate and Certificate Extensions Profile .............. 15 101 4.1 Basic Certificate Fields .................................. 16 102 4.1.1 Certificate Fields ...................................... 17 103 4.1.1.1 tbsCertificate ........................................ 17 104 4.1.1.2 signatureAlgorithm .................................... 17 105 4.1.1.3 signatureValue ........................................ 18 106 4.1.2 TBSCertificate .......................................... 18 107 4.1.2.1 Version ............................................... 18 108 4.1.2.2 Serial number ......................................... 19 109 4.1.2.3 Signature ............................................. 19 110 4.1.2.4 Issuer ................................................ 19 111 4.1.2.5 Validity .............................................. 23 112 4.1.2.5.1 UTCTime ............................................. 23 113 4.1.2.5.2 GeneralizedTime ..................................... 23 114 4.1.2.6 Subject ............................................... 24 115 4.1.2.7 Subject Public Key Info ............................... 25 116 4.1.2.8 Unique Identifiers .................................... 25 117 4.1.2.9 Extensions ............................................. 25 118 4.2 Certificate Extensions .................................... 26 119 4.2.1 Standard Extensions ..................................... 26 120 4.2.1.1 Authority Key Identifier .............................. 27 121 4.2.1.2 Subject Key Identifier ................................ 27 122 4.2.1.3 Key Usage ............................................. 28 123 4.2.1.4 Private Key Usage Period .............................. 30 124 4.2.1.5 Certificate Policies .................................. 31 125 4.2.1.6 Policy Mappings ....................................... 33 126 4.2.1.7 Subject Alternative Name .............................. 34 127 4.2.1.8 Issuer Alternative Name ............................... 36 128 4.2.1.9 Subject Directory Attributes .......................... 37 129 4.2.1.10 Basic Constraints .................................... 37 130 4.2.1.11 Name Constraints ..................................... 38 131 4.2.1.12 Policy Constraints ................................... 40 132 4.2.1.13 Extended key usage field ............................. 41 133 4.2.1.14 CRL Distribution Points .............................. 42 134 4.2.1.15 Inhibit Any-Policy ................................... 43 135 4.2.1.16 Freshest CRL ......................................... 43 136 4.2.2 Internet Certificate Extensions ......................... 44 137 4.2.2.1 Authority Information Access .......................... 44 138 4.2.2.2 Subject Information Access ............................ 45 139 5 CRL and CRL Extensions Profile .............................. 47 140 5.1 CRL Fields ................................................ 47 141 5.1.1 CertificateList Fields .................................. 48 142 5.1.1.1 tbsCertList ........................................... 48 143 5.1.1.2 signatureAlgorithm .................................... 48 144 5.1.1.3 signatureValue ........................................ 49 145 5.1.2 Certificate List "To Be Signed" ......................... 49 146 5.1.2.1 Version ............................................... 49 147 5.1.2.2 Signature ............................................. 49 148 5.1.2.3 Issuer Name ........................................... 50 149 5.1.2.4 This Update ........................................... 50 150 5.1.2.5 Next Update ........................................... 50 151 5.1.2.6 Revoked Certificates .................................. 51 152 5.1.2.7 Extensions ............................................ 51 153 5.2 CRL Extensions ............................................ 51 154 5.2.1 Authority Key Identifier ................................ 51 155 5.2.2 Issuer Alternative Name ................................. 52 156 5.2.3 CRL Number .............................................. 52 157 5.2.4 Delta CRL Indicator ..................................... 52 158 5.2.5 Issuing Distribution Point .............................. 54 159 5.2.6 Freshest CRL ............................................ 55 160 5.3 CRL Entry Extensions ...................................... 55 161 5.3.1 Reason Code ............................................. 56 162 5.3.2 Hold Instruction Code ................................... 56 163 5.3.3 Invalidity Date ......................................... 57 164 5.3.4 Certificate Issuer ...................................... 57 165 6 Certificate Path Validation ................................. 58 166 6.1 Basic Path Validation ..................................... 58 167 6.1.1 Inputs ................................................... 61 168 6.1.2 Initialization ........................................... 62 169 6.1.3 Basic Certificate Processing ............................. 65 170 6.1.4 Preparation for Certificate i+1 .......................... 70 171 6.1.5 Wrap-up procedure ........................................ 73 172 6.1.6 Outputs .................................................. 74 173 6.2 Extending Path Validation ................................. 75 174 6.3 CRL Validation ............................................ 75 175 6.3.1 Revocation Inputs ....................................... 76 176 6.3.2 Initialization and Revocation State Variables ........... 76 177 6.3.3 CRL Processing .......................................... 77 178 7 References .................................................. 79 179 8 Intellectual Property Rights ................................ 81 180 9 Security Considerations ..................................... 81 181 Appendix A. ASN.1 Structures and OIDs ......................... 84 182 A.1 Explicitly Tagged Module, 1988 Syntax ...................... 84 183 A.2 Implicitly Tagged Module, 1988 Syntax ...................... 97 184 Appendix B. ASN.1 Notes ....................................... 104 185 Appendix C. Examples .......................................... 105 186 C.1 Certificate ............................................... 106 187 C.2 Certificate ............................................... 108 188 C.3 End-Entity Certificate Using RSA .......................... 112 189 C.4 Certificate Revocation List ............................... 115 190 Appendix D. Author Addresses .................................. 117 191 Appendix E. Full Copyright Statement .......................... 117 193 1 Introduction 195 This specification is one part of a family of standards for the X.509 196 Public Key Infrastructure (PKI) for the Internet. This specification 197 is a standalone document; implementations of this standard may 198 proceed independent from the other parts. 200 This specification profiles the format and semantics of certificates 201 and certificate revocation lists for the Internet PKI. Procedures 202 are described for processing of certification paths in the Internet 203 environment. Encoding rules are provided for popular cryptographic 204 algorithms. Finally, ASN.1 modules are provided in the appendices 205 for all data structures defined or referenced. 207 The specification describes the requirements which inspire the 208 creation of this document and the assumptions which affect its scope 209 in Section 2. Section 3 presents an architectural model and 210 describes its relationship to previous IETF and ISO/IEC/ITU 211 standards. In particular, this document's relationship with the IETF 212 PEM specifications and the ISO/IEC/ITU X.509 documents are described. 214 The specification profiles the X.509 version 3 certificate in Section 215 4, and the X.509 version 2 certificate revocation list (CRL) in 216 Section 5. The profiles include the identification of ISO/IEC/ITU 217 and ANSI extensions which may be useful in the Internet PKI. The 218 profiles are presented in the 1988 Abstract Syntax Notation One 219 (ASN.1) rather than the 1994 syntax used in the ISO/IEC/ITU 220 standards. 222 This specification also includes path validation procedures in 223 Section 6. These procedures are based upon the ISO/IEC/ITU 224 definition, but the presentation assumes one or more self-signed 225 trusted CA certificates. Implementations are required to derive the 226 same results but are not required to use the specified procedures. 228 Procedures for identification and encoding of public key materials 229 and digital signatures are defined in [PKIX ALGS]. Implementations of 230 this specification are not required to use any particular 231 cryptographic algorithms. However, conforming implementations which 232 use the algorithms identified in [PKIX ALGS] are required to identify 233 and encode the public key materials and digital signatures as 234 described in that specification. 236 Finally, three appendices are provided to aid implementers. Appendix 237 A contains all ASN.1 structures defined or referenced within this 238 specification. As above, the material is presented in the 1988 239 Abstract Syntax Notation One (ASN.1) rather than the 1994 syntax. 240 Appendix B contains notes on less familiar features of the ASN.1 241 notation used within this specification. Appendix C contains 242 examples of a conforming certificate and a conforming CRL. 244 2 Requirements and Assumptions 246 The goal of this specification is to develop a profile to facilitate 247 the use of X.509 certificates within Internet applications for those 248 communities wishing to make use of X.509 technology. Such 249 applications may include WWW, electronic mail, user authentication, 250 and IPsec. In order to relieve some of the obstacles to using X.509 251 certificates, this document defines a profile to promote the 252 development of certificate management systems; development of 253 application tools; and interoperability determined by policy. 255 Some communities will need to supplement, or possibly replace, this 256 profile in order to meet the requirements of specialized application 257 domains or environments with additional authorization, assurance, or 258 operational requirements. However, for basic applications, common 259 representations of frequently used attributes are defined so that 260 application developers can obtain necessary information without 261 regard to the issuer of a particular certificate or certificate 262 revocation list (CRL). 264 A certificate user should review the certificate policy generated by 265 the certification authority (CA) before relying on the authentication 266 or non-repudiation services associated with the public key in a 267 particular certificate. To this end, this standard does not 268 prescribe legally binding rules or duties. 270 As supplemental authorization and attribute management tools emerge, 271 such as attribute certificates, it may be appropriate to limit the 272 authenticated attributes that are included in a certificate. These 273 other management tools may provide more appropriate methods of 274 conveying many authenticated attributes. 276 2.1 Communication and Topology 278 The users of certificates will operate in a wide range of 279 environments with respect to their communication topology, especially 280 users of secure electronic mail. This profile supports users without 281 high bandwidth, real-time IP connectivity, or high connection 282 availability. In addition, the profile allows for the presence of 283 firewall or other filtered communication. 285 This profile does not assume the deployment of an X.500 Directory 286 system. The profile does not prohibit the use of an X.500 Directory, 287 but other means of distributing certificates and certificate 288 revocation lists (CRLs) may be used. 290 2.2 Acceptability Criteria 292 The goal of the Internet Public Key Infrastructure (PKI) is to meet 293 the needs of deterministic, automated identification, authentication, 294 access control, and authorization functions. Support for these 295 services determines the attributes contained in the certificate as 296 well as the ancillary control information in the certificate such as 297 policy data and certification path constraints. 299 2.3 User Expectations 301 Users of the Internet PKI are people and processes who use client 302 software and are the subjects named in certificates. These uses 303 include readers and writers of electronic mail, the clients for WWW 304 browsers, WWW servers, and the key manager for IPsec within a router. 305 This profile recognizes the limitations of the platforms these users 306 employ and the limitations in sophistication and attentiveness of the 307 users themselves. This manifests itself in minimal user 308 configuration responsibility (e.g., trusted CA keys, rules), explicit 309 platform usage constraints within the certificate, certification path 310 constraints which shield the user from many malicious actions, and 311 applications which sensibly automate validation functions. 313 2.4 Administrator Expectations 315 As with user expectations, the Internet PKI profile is structured to 316 support the individuals who generally operate CAs. Providing 317 administrators with unbounded choices increases the chances that a 318 subtle CA administrator mistake will result in broad compromise. 319 Also, unbounded choices greatly complicate the software that shall 320 process and validate the certificates created by the CA. 322 3 Overview of Approach 324 Following is a simplified view of the architectural model assumed by 325 the PKIX specifications. 327 +---+ 328 | C | +------------+ 329 | e | <-------------------->| End entity | 330 | r | Operational +------------+ 331 | t | transactions ^ 332 | | and management | Management 333 | / | transactions | transactions 334 | | | PKI users 335 | C | v 336 | R | -------------------+--+-----------+---------------- 337 | L | ^ ^ 338 | | | | PKI management 339 | | v | entities 340 | R | +------+ | 341 | e | <---------------------| RA | <---+ | 342 | p | Publish certificate +------+ | | 343 | o | | | 344 | s | | | 345 | I | v v 346 | t | +------------+ 347 | o | <------------------------------| CA | 348 | r | Publish certificate +------------+ 349 | y | Publish CRL ^ 350 | | | 351 +---+ Management | 352 transactions | 353 v 354 +------+ 355 | CA | 356 +------+ 358 Figure 1 - PKI Entities 360 The components in this model are: 362 end entity: user of PKI certificates and/or end user system that 363 is the subject of a certificate; 364 CA: certification authority; 365 RA: registration authority, i.e., an optional system to 366 which a CA delegates certain management functions; 367 repository: a system or collection of distributed systems that 368 store certificates and CRLs and serves as a means of 369 distributing these certificates and CRLs to end 370 entities. 372 3.1 X.509 Version 3 Certificate 374 Users of a public key require confidence that the associated private 375 key is owned by the correct remote subject (person or system) with 376 which an encryption or digital signature mechanism will be used. 377 This confidence is obtained through the use of public key 378 certificates, which are data structures that bind public key values 379 to subjects. The binding is asserted by having a trusted CA 380 digitally sign each certificate. The CA may base this assertion upon 381 technical means (a.k.a., proof of posession through a challenge- 382 response protocol), presentation of the private key, or on an 383 assertion by the subject. A certificate has a limited valid lifetime 384 which is indicated in its signed contents. Because a certificate's 385 signature and timeliness can be independently checked by a 386 certificate-using client, certificates can be distributed via 387 untrusted communications and server systems, and can be cached in 388 unsecured storage in certificate-using systems. 390 ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8, which was 391 first published in 1988 as part of the X.500 Directory 392 recommendations, defines a standard certificate format [X.509]. The 393 certificate format in the 1988 standard is called the version 1 (v1) 394 format. When X.500 was revised in 1993, two more fields were added, 395 resulting in the version 2 (v2) format. 397 The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993, 398 include specifications for a public key infrastructure based on X.509 399 v1 certificates [RFC 1422]. The experience gained in attempts to 400 deploy RFC 1422 made it clear that the v1 and v2 certificate formats 401 are deficient in several respects. Most importantly, more fields 402 were needed to carry information which PEM design and implementation 403 experience has proven necessary. In response to these new 404 requirements, ISO/IEC/ITU and ANSI X9 developed the X.509 version 3 405 (v3) certificate format. The v3 format extends the v2 format by 406 adding provision for additional extension fields. Particular 407 extension field types may be specified in standards or may be defined 408 and registered by any organization or community. In June 1996, 409 standardization of the basic v3 format was completed [X.509]. 411 ISO/IEC/ITU and ANSI X9 have also developed standard extensions for 412 use in the v3 extensions field [X.509][X9.55]. These extensions can 413 convey such data as additional subject identification information, 414 key attribute information, policy information, and certification path 415 constraints. 417 However, the ISO/IEC/ITU and ANSI X9 standard extensions are very 418 broad in their applicability. In order to develop interoperable 419 implementations of X.509 v3 systems for Internet use, it is necessary 420 to specify a profile for use of the X.509 v3 extensions tailored for 421 the Internet. It is one goal of this document to specify a profile 422 for Internet WWW, electronic mail, and IPsec applications. 423 Environments with additional requirements may build on this profile 424 or may replace it. 426 3.2 Certification Paths and Trust 428 A user of a security service requiring knowledge of a public key 429 generally needs to obtain and validate a certificate containing the 430 required public key. If the public-key user does not already hold an 431 assured copy of the public key of the CA that signed the certificate, 432 the CA's name, and related information (such as the validity period 433 or name constraints), then it might need an additional certificate to 434 obtain that public key. In general, a chain of multiple certificates 435 may be needed, comprising a certificate of the public key owner (the 436 end entity) signed by one CA, and zero or more additional 437 certificates of CAs signed by other CAs. Such chains, called 438 certification paths, are required because a public key user is only 439 initialized with a limited number of assured CA public keys. 441 There are different ways in which CAs might be configured in order 442 for public key users to be able to find certification paths. For 443 PEM, RFC 1422 defined a rigid hierarchical structure of CAs. There 444 are three types of PEM certification authority: 446 (a) Internet Policy Registration Authority (IPRA): This 447 authority, operated under the auspices of the Internet Society, 448 acts as the root of the PEM certification hierarchy at level 1. 449 It issues certificates only for the next level of authorities, 450 PCAs. All certification paths start with the IPRA. 452 (b) Policy Certification Authorities (PCAs): PCAs are at level 2 453 of the hierarchy, each PCA being certified by the IPRA. A PCA 454 shall establish and publish a statement of its policy with respect 455 to certifying users or subordinate certification authorities. 456 Distinct PCAs aim to satisfy different user needs. For example, 457 one PCA (an organizational PCA) might support the general 458 electronic mail needs of commercial organizations, and another PCA 459 (a high-assurance PCA) might have a more stringent policy designed 460 for satisfying legally binding digital signature requirements. 462 (c) Certification Authorities (CAs): CAs are at level 3 of the 463 hierarchy and can also be at lower levels. Those at level 3 are 464 certified by PCAs. CAs represent, for example, particular 465 organizations, particular organizational units (e.g., departments, 466 groups, sections), or particular geographical areas. 468 RFC 1422 furthermore has a name subordination rule which requires 469 that a CA can only issue certificates for entities whose names are 470 subordinate (in the X.500 naming tree) to the name of the CA itself. 471 The trust associated with a PEM certification path is implied by the 472 PCA name. The name subordination rule ensures that CAs below the PCA 473 are sensibly constrained as to the set of subordinate entities they 474 can certify (e.g., a CA for an organization can only certify entities 475 in that organization's name tree). Certificate user systems are able 476 to mechanically check that the name subordination rule has been 477 followed. 479 The RFC 1422 uses the X.509 v1 certificate formats. The limitations 480 of X.509 v1 required imposition of several structural restrictions to 481 clearly associate policy information or restrict the utility of 482 certificates. These restrictions included: 484 (a) a pure top-down hierarchy, with all certification paths 485 starting from IPRA; 487 (b) a naming subordination rule restricting the names of a CA's 488 subjects; and 490 (c) use of the PCA concept, which requires knowledge of individual 491 PCAs to be built into certificate chain verification logic. 492 Knowledge of individual PCAs was required to determine if a chain 493 could be accepted. 495 With X.509 v3, most of the requirements addressed by RFC 1422 can be 496 addressed using certificate extensions, without a need to restrict 497 the CA structures used. In particular, the certificate extensions 498 relating to certificate policies obviate the need for PCAs and the 499 constraint extensions obviate the need for the name subordination 500 rule. As a result, this document supports a more flexible 501 architecture, including: 503 (a) Certification paths may start with a public key of a CA in a 504 user's own domain, or with the public key of the top of a 505 hierarchy. Starting with the public key of a CA in a user's own 506 domain has certain advantages. In some environments, the local 507 domain is the most trusted. 509 (b) Name constraints may be imposed through explicit inclusion of 510 a name constraints extension in a certificate, but are not 511 required. 513 (c) Policy extensions and policy mappings replace the PCA 514 concept, which permits a greater degree of automation. The 515 application can determine if the certification path is acceptable 516 based on the contents of the certificates instead of a priori 517 knowledge of PCAs. This permits automation of certificate chain 518 processing. 520 3.3 Revocation 522 When a certificate is issued, it is expected to be in use for its 523 entire validity period. However, various circumstances may cause a 524 certificate to become invalid prior to the expiration of the validity 525 period. Such circumstances include change of name, change of 526 association between subject and CA (e.g., an employee terminates 527 employment with an organization), and compromise or suspected 528 compromise of the corresponding private key. Under such 529 circumstances, the CA needs to revoke the certificate. 531 X.509 defines one method of certificate revocation. This method 532 involves each CA periodically issuing a signed data structure called 533 a certificate revocation list (CRL). A CRL is a time stamped list 534 identifying revoked certificates which is signed by a CA and made 535 freely available in a public repository. Each revoked certificate is 536 identified in a CRL by its certificate serial number. When a 537 certificate-using system uses a certificate (e.g., for verifying a 538 remote user's digital signature), that system not only checks the 539 certificate signature and validity but also acquires a suitably- 540 recent CRL and checks that the certificate serial number is not on 541 that CRL. The meaning of "suitably-recent" may vary with local 542 policy, but it usually means the most recently-issued CRL. A CA 543 issues a new CRL on a regular periodic basis (e.g., hourly, daily, or 544 weekly). An entry is added to the CRL as part of the next update 545 following notification of revocation. An entry may be removed from 546 the CRL after appearing on one regularly scheduled CRL issued beyond 547 the revoked certificate's validity period. 549 An advantage of this revocation method is that CRLs may be 550 distributed by exactly the same means as certificates themselves, 551 namely, via untrusted communications and server systems. 553 One limitation of the CRL revocation method, using untrusted 554 communications and servers, is that the time granularity of 555 revocation is limited to the CRL issue period. For example, if a 556 revocation is reported now, that revocation will not be reliably 557 notified to certificate-using systems until the next periodic CRL is 558 issued -- this may be up to one hour, one day, or one week depending 559 on the frequency that the CA issues CRLs. 561 As with the X.509 v3 certificate format, in order to facilitate 562 interoperable implementations from multiple vendors, the X.509 v2 CRL 563 format needs to be profiled for Internet use. It is one goal of this 564 document to specify that profile. However, this profile does not 565 require CAs to issue CRLs. Message formats and protocols supporting 566 on-line revocation notification may be defined in other PKIX 567 specifications. On-line methods of revocation notification may be 568 applicable in some environments as an alternative to the X.509 CRL. 569 On-line revocation checking may significantly reduce the latency 570 between a revocation report and the distribution of the information 571 to relying parties. Once the CA accepts the report as authentic and 572 valid, any query to the on-line service will correctly reflect the 573 certificate validation impacts of the revocation. However, these 574 methods impose new security requirements: the certificate validator 575 needs to trust the on-line validation service while the repository 576 does not need to be trusted. 578 3.4 Operational Protocols 580 Operational protocols are required to deliver certificates and CRLs 581 (or status information) to certificate using client systems. 582 Provision is needed for a variety of different means of certificate 583 and CRL delivery, including distribution procedures based on LDAP, 584 HTTP, FTP, and X.500. Operational protocols supporting these 585 functions are defined in other PKIX specifications. These 586 specifications may include definitions of message formats and 587 procedures for supporting all of the above operational environments, 588 including definitions of or references to appropriate MIME content 589 types. 591 3.5 Management Protocols 593 Management protocols are required to support on-line interactions 594 between PKI user and management entities. For example, a management 595 protocol might be used between a CA and a client system with which a 596 key pair is associated, or between two CAs which cross-certify each 597 other. The set of functions which potentially need to be supported 598 by management protocols include: 600 (a) registration: This is the process whereby a user first makes 601 itself known to a CA (directly, or through an RA), prior to that 602 CA issuing a certificate or certificates for that user. 604 (b) initialization: Before a client system can operate securely 605 it is necessary to install key materials which have the 606 appropriate relationship with keys stored elsewhere in the 607 infrastructure. For example, the client needs to be securely 608 initialized with the public key and other assured information of 609 the trusted CA(s), to be used in validating certificate paths. 610 Furthermore, a client typically needs to be initialized with its 611 own key pair(s). 613 (c) certification: This is the process in which a CA issues a 614 certificate for a user's public key, and returns that certificate 615 to the user's client system and/or posts that certificate in a 616 repository. 618 (d) key pair recovery: As an option, user client key materials 619 (e.g., a user's private key used for encryption purposes) may be 620 backed up by a CA or a key backup system. If a user needs to 621 recover these backed up key materials (e.g., as a result of a 622 forgotten password or a lost key chain file), an on-line protocol 623 exchange may be needed to support such recovery. 625 (e) key pair update: All key pairs need to be updated regularly, 626 i.e., replaced with a new key pair, and new certificates issued. 628 (f) revocation request: An authorized person advises a CA of an 629 abnormal situation requiring certificate revocation. 631 (g) cross-certification: Two CAs exchange information used in 632 establishing a cross-certificate. A cross-certificate is a 633 certificate issued by one CA to another CA which contains a CA 634 signature key used for issuing certificates. 636 Note that on-line protocols are not the only way of implementing the 637 above functions. For all functions there are off-line methods of 638 achieving the same result, and this specification does not mandate 639 use of on-line protocols. For example, when hardware tokens are 640 used, many of the functions may be achieved as part of the physical 641 token delivery. Furthermore, some of the above functions may be 642 combined into one protocol exchange. In particular, two or more of 643 the registration, initialization, and certification functions can be 644 combined into one protocol exchange. 646 The PKIX series of specifications may define a set of standard 647 message formats supporting the above functions in future 648 specifications. In that case, the protocols for conveying these 649 messages in different environments (e.g., on-line, file transfer, e- 650 mail, and WWW) will also be described in those specifications. 652 4 Certificate and Certificate Extensions Profile 654 This section presents a profile for public key certificates that will 655 foster interoperability and a reusable PKI. This section is based 656 upon the X.509 v3 certificate format and the standard certificate 657 extensions defined in [X.509]. The ISO/IEC/ITU documents use the 658 1993 version of ASN.1; while this document uses the 1988 ASN.1 659 syntax, the encoded certificate and standard extensions are 660 equivalent. This section also defines private extensions required to 661 support a PKI for the Internet community. 663 Certificates may be used in a wide range of applications and 664 environments covering a broad spectrum of interoperability goals and 665 a broader spectrum of operational and assurance requirements. The 666 goal of this document is to establish a common baseline for generic 667 applications requiring broad interoperability and limited special 668 purpose requirements. In particular, the emphasis will be on 669 supporting the use of X.509 v3 certificates for informal Internet 670 electronic mail, IPsec, and WWW applications. 672 4.1 Basic Certificate Fields 674 The X.509 v3 certificate basic syntax is as follows. For signature 675 calculation, the certificate is encoded using the ASN.1 distinguished 676 encoding rules (DER) [X.208]. ASN.1 DER encoding is a tag, length, 677 value encoding system for each element. 679 Certificate ::= SEQUENCE { 680 tbsCertificate TBSCertificate, 681 signatureAlgorithm AlgorithmIdentifier, 682 signatureValue BIT STRING } 684 TBSCertificate ::= SEQUENCE { 685 version [0] EXPLICIT Version DEFAULT v1, 686 serialNumber CertificateSerialNumber, 687 signature AlgorithmIdentifier, 688 issuer Name, 689 validity Validity, 690 subject Name, 691 subjectPublicKeyInfo SubjectPublicKeyInfo, 692 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 693 -- If present, version shall be v2 or v3 694 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 695 -- If present, version shall be v2 or v3 696 extensions [3] EXPLICIT Extensions OPTIONAL 697 -- If present, version shall be v3 698 } 700 Version ::= INTEGER { v1(0), v2(1), v3(2) } 702 CertificateSerialNumber ::= INTEGER 704 Validity ::= SEQUENCE { 705 notBefore Time, 706 notAfter Time } 708 Time ::= CHOICE { 709 utcTime UTCTime, 710 generalTime GeneralizedTime } 712 UniqueIdentifier ::= BIT STRING 714 SubjectPublicKeyInfo ::= SEQUENCE { 715 algorithm AlgorithmIdentifier, 716 subjectPublicKey BIT STRING } 718 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 720 Extension ::= SEQUENCE { 721 extnID OBJECT IDENTIFIER, 722 critical BOOLEAN DEFAULT FALSE, 723 extnValue OCTET STRING } 725 The following items describe the X.509 v3 certificate for use in the 726 Internet. 728 4.1.1 Certificate Fields 730 The Certificate is a SEQUENCE of three required fields. The fields 731 are described in detail in the following subsections. 733 4.1.1.1 tbsCertificate 735 The field contains the names of the subject and issuer, a public key 736 associated with the subject, a validity period, and other associated 737 information. The fields are described in detail in section 4.1.2; 738 the tbscertificate may also include extensions which are described in 739 section 4.2. 741 4.1.1.2 signatureAlgorithm 743 The signatureAlgorithm field contains the identifier for the 744 cryptographic algorithm used by the CA to sign this certificate. 745 [PKIX ALGS] lists the supported signature algorithms. 747 An algorithm identifier is defined by the following ASN.1 structure: 749 AlgorithmIdentifier ::= SEQUENCE { 750 algorithm OBJECT IDENTIFIER, 751 parameters ANY DEFINED BY algorithm OPTIONAL } 753 The algorithm identifier is used to identify a cryptographic 754 algorithm. The OBJECT IDENTIFIER component identifies the algorithm 755 (such as DSA with SHA-1). The contents of the optional parameters 756 field will vary according to the algorithm identified. [PKIX ALGS] 757 lists the supported algorithms for this specification. 759 This field MUST contain the same algorithm identifier as the 760 signature field in the sequence tbsCertificate (see sec. 4.1.2.3). 762 4.1.1.3 signatureValue 764 The signatureValue field contains a digital signature computed upon 765 the ASN.1 DER encoded tbsCertificate. The ASN.1 DER encoded 766 tbsCertificate is used as the input to the signature function. This 767 signature value is then ASN.1 encoded as a BIT STRING and included in 768 the Certificate's signature field. The details of this process are 769 specified for each of the supported algorithms in [PKIX ALGS]. 771 By generating this signature, a CA certifies the validity of the 772 information in the tbsCertificate field. In particular, the CA 773 certifies the binding between the public key material and the subject 774 of the certificate. 776 4.1.2 TBSCertificate 778 The sequence TBSCertificate contains information associated with the 779 subject of the certificate and the CA who issued it. Every 780 TBSCertificate contains the names of the subject and issuer, a public 781 key associated with the subject, a validity period, a version number, 782 and a serial number; some may contain optional unique identifier 783 fields. The remainder of this section describes the syntax and 784 semantics of these fields. A TBSCertificate may also include 785 extensions. Extensions for the Internet PKI are described in Section 786 4.2. 788 4.1.2.1 Version 790 This field describes the version of the encoded certificate. When 791 extensions are used, as expected in this profile, use X.509 version 3 792 (value is 2). If no extensions are present, but a UniqueIdentifier 793 is present, use version 2 (value is 1). If only basic fields are 794 present, use version 1 (the value is omitted from the certificate as 795 the default value). 797 Implementations SHOULD be prepared to accept any version certificate. 798 At a minimum, conforming implementations MUST recognize version 3 799 certificates. 801 Generation of version 2 certificates is not expected by 802 implementations based on this profile. 804 4.1.2.2 Serial number 806 The serial number is a positive integer assigned by the CA to each 807 certificate. It MUST be unique for each certificate issued by a 808 given CA (i.e., the issuer name and serial number identify a unique 809 certificate). CAs MUST force the serialNumber to be a non-negative 810 integer. 812 Given the uniqueness requirements above serial numbers can be 813 expected to contain long integers. Certificate users MUST be able to 814 handle serialNumber values up to 20 octets. Conformant CAs MUST NOT 815 use serialNumber values longer than 20 octets. 817 Note: Non-conforming CAs may issue certificates with serial numbers 818 that are negative, or zero. Certificate users SHOULD be prepared to 819 handle such certificates. 821 4.1.2.3 Signature 823 This field contains the algorithm identifier for the algorithm used 824 by the CA to sign the certificate. 826 This field MUST contain the same algorithm identifier as the 827 signatureAlgorithm field in the sequence Certificate (see sec. 828 4.1.1.2). The contents of the optional parameters field will vary 829 according to the algorithm identified. [PKIX ALGS] lists the 830 supported signature algorithms. 832 4.1.2.4 Issuer 834 The issuer field identifies the entity who has signed and issued the 835 certificate. The issuer field MUST contain a non-empty distinguished 836 name (DN). The issuer field is defined as the X.501 type Name. 837 [X.501] Name is defined by the following ASN.1 structures: 839 Name ::= CHOICE { 840 RDNSequence } 842 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 844 RelativeDistinguishedName ::= 845 SET OF AttributeTypeAndValue 847 AttributeTypeAndValue ::= SEQUENCE { 848 type AttributeType, 849 value AttributeValue } 851 AttributeType ::= OBJECT IDENTIFIER 852 AttributeValue ::= ANY DEFINED BY AttributeType 854 DirectoryString ::= CHOICE { 855 teletexString TeletexString (SIZE (1..MAX)), 856 printableString PrintableString (SIZE (1..MAX)), 857 universalString UniversalString (SIZE (1..MAX)), 858 utf8String UTF8String (SIZE (1.. MAX)), 859 bmpString BMPString (SIZE (1..MAX)) } 861 The Name describes a hierarchical name composed of attributes, such 862 as country name, and corresponding values, such as US. The type of 863 the component AttributeValue is determined by the AttributeType; in 864 general it will be a DirectoryString. 866 The DirectoryString type is defined as a choice of PrintableString, 867 TeletexString, BMPString, UTF8String, and UniversalString. The 868 UTF8String encoding is the preferred encoding, and all certificates 869 issued after December 31, 2003 MUST use the UTF8String encoding of 870 DirectoryString (except as noted below). Until that date, conforming 871 CAs MUST choose from the following options when creating a 872 distinguished name, including their own: 874 (a) if the character set is sufficient, the string MAY be 875 represented as a PrintableString; 877 (b) failing (a), if the BMPString character set is sufficient the 878 string MAY be represented as a BMPString; and 880 (c) failing (a) and (b), the string MUST be represented as a 881 UTF8String. If (a) or (b) is satisfied, the CA MAY still choose 882 to represent the string as a UTF8String. 884 Exceptions to the December 31, 2003 UTF8 encoding requirements are as 885 follows: 887 (a) CAs MAY issue "name rollover" certificates to support an 888 orderly migration to UTF8String encoding. Such certificates would 889 include the CA's UTF8String encoded name as issuer and and the old 890 name encoding as subject, or vice-versa. 892 (b) As stated in section 4.1.2.6, the subject field MUST be 893 populated with a non-empty distinguished name matching the 894 contents of the issuer field in all certificates issued by the 895 subject CA regardless of encoding. 897 The TeletexString and UniversalString are included for backward 898 compatibility, and should not be used for certificates for new 899 subjects. However, these types may be used in certificates where the 900 name was previously established. Certificate users SHOULD be 901 prepared to receive certificates with these types. 903 In addition, many legacy implementations support names encoded in the 904 ISO 8859-1 character set (Latin1String) but tag them as 905 TeletexString. The Latin1String includes characters used in Western 906 European countries which are not part of the TeletexString charcter 907 set. Implementations that process TeletexString SHOULD be prepared 908 to handle the entire ISO 8859-1 character set.[ISO 8859-1] 910 As noted above, distinguished names are composed of attributes. This 911 specification does not restrict the set of attribute types that may 912 appear in names. However, conforming implementations MUST be 913 prepared to receive certificates with issuer names containing the set 914 of attribute types defined below. This specification also recommends 915 support for additional attribute types. 917 Standard sets of attributes have been defined in the X.500 series of 918 specifications.[X.520] Implementations of this specification MUST be 919 prepared to receive the following standard attribute types in issuer 920 and subject (see 4.1.2.6) names: 922 * country, 923 * organization, 924 * organizational-unit, 925 * distinguished name qualifier, 926 * state or province name, 927 * common name (e.g., "Susan Housley"), and 928 * serial number. 930 In addition, implementations of this specification SHOULD be prepared 931 to receive the following standard attribute types in issuer and 932 subject names: 934 * locality, 935 * title, 936 * surname, 937 * given name, 938 * initials, 939 * pseudonym, and 940 * generation qualifier (e.g., "Jr.", "3rd", or "IV"). 942 The syntax and associated object identifiers (OIDs) for these 943 attribute types are provided in the ASN.1 modules in Appendices A and 944 B. 946 In addition, implementations of this specification MUST be prepared 947 to receive the domainComponent attribute, as defined in [RFC 2247]. 948 The Domain (Nameserver) System (DNS) provides a hierarchical resource 949 labeling system. This attribute provides is a convenient mechanism 950 for organizations that wish to use DNs that parallel their DNS names. 951 This is not a replacement for the dNSName component of the 952 alternative name field. Implementations are not required to convert 953 such names into DNS names. The syntax and associated OID for this 954 attribute type is provided in the ASN.1 modules in Appendices A and 955 B. 957 Certificate users MUST be prepared to process the issuer 958 distinguished name and subject distinguished name (see sec. 4.1.2.6) 959 fields to perform name chaining for certification path validation 960 (see section 6). Name chaining is performed by matching the issuer 961 distinguished name in one certificate with the subject name in a CA 962 certificate. 964 This specification requires only a subset of the name comparison 965 functionality specified in the X.500 series of specifications. The 966 requirements for conforming implementations are as follows: 968 (a) attribute values encoded in different types (e.g., 969 PrintableString and BMPString) may be assumed to represent 970 different strings; 972 (b) attribute values in types other than PrintableString are case 973 sensitive (this permits matching of attribute values as binary 974 objects); 976 (c) attribute values in PrintableString are not case sensitive 977 (e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and 979 (d) attribute values in PrintableString are compared after 980 removing leading and trailing white space and converting internal 981 substrings of one or more consecutive white space characters to a 982 single space. 984 These name comparison rules permit a certificate user to validate 985 certificates issued using languages or encodings unfamiliar to the 986 certificate user. 988 In addition, implementations of this specification MAY use these 989 comparison rules to process unfamiliar attribute types for name 990 chaining. This allows implementations to process certificates with 991 unfamiliar attributes in the issuer name. 993 Note that the comparison rules defined in the X.500 series of 994 specifications indicate that the character sets used to encode data 995 in distinguished names are irrelevant. The characters themselves are 996 compared without regard to encoding. Implementations of the profile 997 are permitted to use the comparison algorithm defined in the X.500 998 series. Such an implementation will recognize a superset of name 999 matches recognized by the algorithm specified above. 1001 4.1.2.5 Validity 1003 The certificate validity period is the time interval during which the 1004 CA warrants that it will maintain information about the status of the 1005 certificate. The field is represented as a SEQUENCE of two dates: 1006 the date on which the certificate validity period begins (notBefore) 1007 and the date on which the certificate validity period ends 1008 (notAfter). Both notBefore and notAfter may be encoded as UTCTime or 1009 GeneralizedTime. 1011 CAs conforming to this profile MUST always encode certificate 1012 validity dates through the year 2049 as UTCTime; certificate validity 1013 dates in 2050 or later MUST be encoded as GeneralizedTime. 1015 The validity period for a certificate is the period of time from 1016 notBefore through notAfter, inclusive. 1018 4.1.2.5.1 UTCTime 1020 The universal time type, UTCTime, is a standard ASN.1 type intended 1021 for representation of dates and time. UTCTime specifies the year 1022 through the two low order digits and time is specified to the 1023 precision of one minute or one second. UTCTime includes either Z 1024 (for Zulu, or Greenwich Mean Time) or a time differential. 1026 For the purposes of this profile, UTCTime values MUST be expressed 1027 Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are 1028 YYMMDDHHMMSSZ), even where the number of seconds is zero. Conforming 1029 systems MUST interpret the year field (YY) as follows: 1031 Where YY is greater than or equal to 50, the year shall be 1032 interpreted as 19YY; and 1034 Where YY is less than 50, the year shall be interpreted as 20YY. 1036 4.1.2.5.2 GeneralizedTime 1038 The generalized time type, GeneralizedTime, is a standard ASN.1 type 1039 for variable precision representation of time. Optionally, the 1040 GeneralizedTime field can include a representation of the time 1041 differential between local and Greenwich Mean Time. 1043 For the purposes of this profile, GeneralizedTime values MUST be 1044 expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e., 1045 times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. 1046 GeneralizedTime values MUST NOT include fractional seconds. 1048 4.1.2.6 Subject 1050 The subject field identifies the entity associated with the public 1051 key stored in the subject public key field. The subject name may be 1052 carried in the subject field and/or the subjectAltName extension. If 1053 the subject is a CA (e.g., the basic constraints extension, as 1054 discussed in 4.2.1.10, is present and the value of cA is TRUE,) then 1055 the subject field MUST be populated with a non-empty distinguished 1056 name matching the contents of the issuer field (see sec. 4.1.2.4) in 1057 all certificates issued by the subject CA. If subject naming 1058 information is present only in the subjectAltName extension (e.g., a 1059 key bound only to an email address or URI), then the subject name 1060 MUST be an empty sequence and the subjectAltName extension MUST be 1061 critical. 1063 Where it is non-empty, the subject field MUST contain an X.500 1064 distinguished name (DN). The DN MUST be unique for each subject 1065 entity certified by the one CA as defined by the issuer name field. A 1066 CA may issue more than one certificate with the same DN to the same 1067 subject entity. 1069 The subject name field is defined as the X.501 type Name. 1070 Implementation requirements for this field are those defined for the 1071 issuer field (see sec. 4.1.2.4). When encoding attribute values of 1072 type DirectoryString, the encoding rules for the issuer field MUST be 1073 implemented. Implementations of this specification MUST be prepared 1074 to receive subject names containing the attribute types required for 1075 the issuer field. Implementations of this specification SHOULD be 1076 prepared to receive subject names containing the recommended 1077 attribute types for the issuer field. The syntax and associated 1078 object identifiers (OIDs) for these attribute types are provided in 1079 the ASN.1 modules in Appendices A and B. Implementations of this 1080 specification MAY use these comparison rules to process unfamiliar 1081 attribute types (i.e., for name chaining). This allows 1082 implementations to process certificates with unfamiliar attributes in 1083 the subject name. 1085 In addition, legacy implementations exist where an RFC 822 name is 1086 embedded in the subject distinguished name as an EmailAddress 1087 attribute. The attribute value for EmailAddress is of type IA5String 1088 to permit inclusion of the character '@', which is not part of the 1089 PrintableString character set. EmailAddress attribute values are not 1090 case sensitive (e.g., "fanfeedback@redsox.com" is the same as 1091 "FANFEEDBACK@REDSOX.COM"). 1093 Conforming implementations generating new certificates with 1094 electronic mail addresses MUST use the rfc822Name in the subject 1095 alternative name field (see sec. 4.2.1.7) to describe such 1096 identities. Simultaneous inclusion of the EmailAddress attribute in 1097 the subject distinguished name to support legacy implementations is 1098 deprecated but permitted. 1100 4.1.2.7 Subject Public Key Info 1102 This field is used to carry the public key and identify the algorithm 1103 with which the key is used. The algorithm is identified using the 1104 AlgorithmIdentifier structure specified in section 4.1.1.2. The 1105 object identifiers for the supported algorithms and the methods for 1106 encoding the public key materials (public key and parameters) are 1107 specified in [PKIX ALGS]. 1109 4.1.2.8 Unique Identifiers 1111 These fields may only appear if the version is 2 or 3 (see sec. 1112 4.1.2.1). The subject and issuer unique identifiers are present in 1113 the certificate to handle the possibility of reuse of subject and/or 1114 issuer names over time. This profile recommends that names not be 1115 reused for different entities and that Internet certificates not make 1116 use of unique identifiers. CAs conforming to this profile SHOULD NOT 1117 generate certificates with unique identifiers. Applications 1118 conforming to this profile SHOULD be capable of parsing unique 1119 identifiers and making comparisons. 1121 4.1.2.9 Extensions 1123 This field may only appear if the version is 3 (see sec. 4.1.2.1). 1124 If present, this field is a SEQUENCE of one or more certificate 1125 extensions. The format and content of certificate extensions in the 1126 Internet PKI is defined in section 4.2. 1128 4.2 Standard Certificate Extensions 1130 The extensions defined for X.509 v3 certificates provide methods for 1131 associating additional attributes with users or public keys and for 1132 managing the certification hierarchy. The X.509 v3 certificate 1133 format also allows communities to define private extensions to carry 1134 information unique to those communities. Each extension in a 1135 certificate may be designated as critical or non-critical. A 1136 certificate using system MUST reject the certificate if it encounters 1137 a critical extension it does not recognize; however, a non-critical 1138 extension may be ignored if it is not recognized. The following 1139 sections present recommended extensions used within Internet 1140 certificates and standard locations for information. Communities may 1141 elect to use additional extensions; however, caution should be 1142 exercised in adopting any critical extensions in certificates which 1143 might prevent use in a general context. 1145 Each extension includes an OID and an ASN.1 structure. When an 1146 extension appears in a certificate, the OID appears as the field 1147 extnID and the corresponding ASN.1 encoded structure is the value of 1148 the octet string extnValue. Only one instance of a particular 1149 extension may appear in a particular certificate. For example, a 1150 certificate may contain only one authority key identifier extension 1151 (see sec. 4.2.1.1). An extension includes the boolean critical, with 1152 a default value of FALSE. The text for each extension specifies the 1153 acceptable values for the critical field. 1155 Conforming CAs MUST support key identifiers (see sec. 4.2.1.1 and 1156 4.2.1.2), basic constraints (see sec. 4.2.1.10), key usage (see sec. 1157 4.2.1.3), and certificate policies (see sec. 4.2.1.5) extensions. If 1158 the CA issues certificates with an empty sequence for the subject 1159 field, the CA MUST support the subject alternative name extension 1160 (see sec. 4.2.1.7). Support for the remaining extensions is 1161 OPTIONAL. Conforming CAs may support extensions that are not 1162 identified within this specification; certificate issuers are 1163 cautioned that marking such extensions as critical may inhibit 1164 interoperability. 1166 At a minimum, applications conforming to this profile MUST recognize 1167 the following extensions: key usage (see sec. 4.2.1.3), certificate 1168 policies (see sec. 4.2.1.5), the subject alternative name (see sec. 1169 4.2.1.7), basic constraints (see sec. 4.2.1.10), name constraints 1170 (see sec. 4.2.1.11), policy constraints (see sec. 4.2.1.12), extended 1171 key usage (see sec. 4.2.1.13), and inhibit any-policy (see sec. 1172 4.2.1.15). 1174 In addition, this profile RECOMMENDS application support for the 1175 authority and subject key identifier (see sec. 4.2.1.1 and 4.2.1.2), 1176 and policy mapping (see sec. 4.2.1.6) extensions. 1178 4.2.1 Standard Extensions 1180 This section identifies standard certificate extensions defined in 1181 [X.509] for use in the Internet PKI. Each extension is associated 1182 with an OID defined in [X.509]. These OIDs are members of the id-ce 1183 arc, which is defined by the following: 1185 id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 1187 4.2.1.1 Authority Key Identifier 1189 The authority key identifier extension provides a means of 1190 identifying the public key corresponding to the private key used to 1191 sign a certificate. This extension is used where an issuer has 1192 multiple signing keys (either due to multiple concurrent key pairs or 1193 due to changeover). The identification may be based on either the 1194 key identifier (the subject key identifier in the issuer's 1195 certificate) or on the issuer name and serial number. 1197 The keyIdentifier field of the authorityKeyIdentifier extension MUST 1198 be included in all certificates generated by conforming CAs to 1199 facilitate chain building. There is one exception; where a CA 1200 distributes its public key in the form of a "self-signed" 1201 certificate, the authority key identifier may be omitted. In this 1202 case, the subject and authority key identifiers would be identical. 1204 The value of the keyIdentifier field SHOULD be derived from the 1205 public key used to verify the certificate's signature or a method 1206 that generates unique values. Two common methods for generating key 1207 identifiers from the public key are described in (sec. 4.2.1.2). One 1208 common method for generating unique values is described in (sec. 1209 4.2.1.2). Where a key identifier has not been previously 1210 established, this specification recommends use of one of these 1211 methods for generating keyIdentifiers. 1213 This profile recommends support for the key identifier method by all 1214 certificate users. 1216 This extension MUST NOT be marked critical. 1218 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 1220 AuthorityKeyIdentifier ::= SEQUENCE { 1221 keyIdentifier [0] KeyIdentifier OPTIONAL, 1222 authorityCertIssuer [1] GeneralNames OPTIONAL, 1223 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 1225 KeyIdentifier ::= OCTET STRING 1227 4.2.1.2 Subject Key Identifier 1229 The subject key identifier extension provides a means of identifying 1230 certificates that contain a particular public key. 1232 To facilitate chain building, this extension MUST appear in all con- 1233 forming CA certificates, that is, all certificates including the 1234 basic constraints extension (see sec. 4.2.1.10) where the value of cA 1235 is TRUE. The value of the subject key identifier MUST be the value 1236 placed in the key identifier field of the Authority Key Identifier 1237 extension (see sec. 4.2.1.1) of certificates issued by the subject of 1238 this certificate. 1240 For CA certificates, subject key identifiers SHOULD be derived from 1241 the public key or a method that generates unique values. Two common 1242 methods for generating key identifiers from the public key are: 1244 (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the 1245 value of the BIT STRING subjectPublicKey (excluding the tag, 1246 length, and number of unused bits). 1248 (2) The keyIdentifier is composed of a four bit type field with 1249 the value 0100 followed by the least significant 60 bits of the 1250 SHA-1 hash of the value of the BIT STRING subjectPublicKey. 1252 One common method for generating unique values is a monotonically 1253 increasing sequence of integers. 1255 For end entity certificates, the subject key identifier extension 1256 provides a means for identifying certificates containing the 1257 particular public key used in an application. Where an end entity has 1258 obtained multiple certificates, especially from multiple CAs, the 1259 subject key identifier provides a means to quickly identify the set 1260 of certificates containing a particular public key. To assist 1261 applications in identifying the appropriate end entity certificate, 1262 this extension SHOULD be included in all end entity certificates. 1264 For end entity certificates, subject key identifiers SHOULD be 1265 derived from the public key. Two common methods for generating key 1266 identifiers from the public key are identifed above. 1268 Where a key identifier has not been previously established, this 1269 specification recommends use of one of these methods for generating 1270 keyIdentifiers. 1272 This extension MUST NOT be marked critical. 1274 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 1276 SubjectKeyIdentifier ::= KeyIdentifier 1278 4.2.1.3 Key Usage 1280 The key usage extension defines the purpose (e.g., encipherment, 1281 signature, certificate signing) of the key contained in the 1282 certificate. The usage restriction might be employed when a key that 1283 could be used for more than one operation is to be restricted. For 1284 example, when an RSA key should be used only for signing, the 1285 digitalSignature and/or nonRepudiation bits would be asserted. 1286 Likewise, when an RSA key should be used only for key management, the 1287 keyEncipherment bit would be asserted. When used, this extension 1288 SHOULD be marked critical. 1290 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 1292 KeyUsage ::= BIT STRING { 1293 digitalSignature (0), 1294 nonRepudiation (1), 1295 keyEncipherment (2), 1296 dataEncipherment (3), 1297 keyAgreement (4), 1298 keyCertSign (5), 1299 cRLSign (6), 1300 encipherOnly (7), 1301 decipherOnly (8) } 1303 Bits in the KeyUsage type are used as follows: 1305 The digitalSignature bit is asserted when the subject public key 1306 is used with a digital signature mechanism to support security 1307 services other than non-repudiation (bit 1), certificate signing 1308 (bit 5), or revocation information signing (bit 6). Digital 1309 signature mechanisms are often used for entity authentication and 1310 data origin authentication with integrity. 1312 The nonRepudiation bit is asserted when the subject public key is 1313 used to verify digital signatures used to provide a non- 1314 repudiation service which protects against the signing entity 1315 falsely denying some action, excluding certificate or CRL signing. 1316 In the case of later conflict, a reliable third party may 1317 determine the authenticity of the signed data. 1319 Further distinctions between the digitalSignature and 1320 nonRepudiation bits may be provided in specific certificate 1321 policies. 1323 The keyEncipherment bit is asserted when the subject public key is 1324 used for key transport. For example, when an RSA key is to be 1325 used for key management, then this bit shall asserted. 1327 The dataEncipherment bit is asserted when the subject public key 1328 is used for enciphering user data, other than cryptographic keys. 1330 The keyAgreement bit is asserted when the subject public key is 1331 used for key agreement. For example, when a Diffie-Hellman key is 1332 to be used for key management, then this bit shall asserted. 1334 The keyCertSign bit is asserted when the subject public key is 1335 used for verifying a signature on certificates. This bit may only 1336 be asserted in CA certificates. If the keyCertSign bit is 1337 asserted, then the cA bit in the basic constraints extension (see 1338 4.2.1.10) MUST also be asserted. If the keyCertSign bit is not 1339 asserted, then the cA bit in the basic constraints extension MUST 1340 NOT be asserted. 1342 The cRLSign bit is asserted when the subject public key is used 1343 for verifying a signature on revocation information (e.g., a CRL). 1345 The meaning of the encipherOnly bit is undefined in the absence of 1346 the keyAgreement bit. When the encipherOnly bit is asserted and 1347 the keyAgreement bit is also set, the subject public key may be 1348 used only for enciphering data while performing key agreement. 1350 The meaning of the decipherOnly bit is undefined in the absence of 1351 the keyAgreement bit. When the decipherOnly bit is asserted and 1352 the keyAgreement bit is also set, the subject public key may be 1353 used only for deciphering data while performing key agreement. 1355 This profile does not restrict the combinations of bits that may be 1356 set in an instantiation of the keyUsage extension. However, 1357 appropriate values for keyUsage extensions for particular algorithms 1358 are specified in [PKIX ALGS]. 1360 4.2.1.4 Private Key Usage Period 1362 This profile recommends against the use of this extension. CAs 1363 conforming to this profile MUST NOT generate certificates with 1364 critical private key usage period extensions. 1366 The private key usage period extension allows the certificate issuer 1367 to specify a different validity period for the private key than the 1368 certificate. This extension is intended for use with digital 1369 signature keys. This extension consists of two optional components, 1370 notBefore and notAfter. The private key associated with the 1371 certificate should not be used to sign objects before or after the 1372 times specified by the two components, respectively. CAs conforming 1373 to this profile MUST NOT generate certificates with private key usage 1374 period extensions unless at least one of the two components is 1375 present. 1377 Where used, notBefore and notAfter are represented as GeneralizedTime 1378 and MUST be specified and interpreted as defined in section 1379 4.1.2.5.2. 1381 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 1383 PrivateKeyUsagePeriod ::= SEQUENCE { 1384 notBefore [0] GeneralizedTime OPTIONAL, 1385 notAfter [1] GeneralizedTime OPTIONAL } 1387 4.2.1.5 Certificate Policies 1389 The certificate policies extension contains a sequence of one or more 1390 policy information terms, each of which consists of an object 1391 identifier (OID) and optional qualifiers. Optional qualifiers, which 1392 may be present, are not expected to change the definition of the 1393 policy. 1395 In an end-entity certificate, these policy information terms indicate 1396 the policy under which the certificate has been issued and the 1397 purposes for which the certificate may be used. In a CA certificate, 1398 these policy information terms limit the set of policies for 1399 certification paths which include this certificate. When a CA does 1400 not wish to limit the set of policies for certification paths which 1401 include this certificate, they may assert the special policy 1402 anyPolicy, with a value of {2 5 29 32 0}. 1404 Applications with specific policy requirements are expected to have a 1405 list of those policies which they will accept and to compare the 1406 policy OIDs in the certificate to that list. If this extension is 1407 critical, the path validation software MUST be able to interpret this 1408 extension (including the optional qualifier), or MUST reject the 1409 certificate. 1411 To promote interoperability, this profile RECOMMENDS that policy 1412 information terms consist of only an OID. Where an OID alone is 1413 insufficient, this profile strongly recommends that use of qualifiers 1414 be limited to those identified in this section. When qualifiers are 1415 used with the special policy anyPolicy, they MUST be limited to the 1416 qualifers identified in this section. 1418 This specification defines two policy qualifier types for use by 1419 certificate policy writers and certificate issuers. The qualifier 1420 types are the CPS Pointer and User Notice qualifiers. 1422 The CPS Pointer qualifier contains a pointer to a Certification 1423 Practice Statement (CPS) published by the CA. The pointer is in the 1424 form of a URI. Processing requirements for this qualifier are a 1425 local matter. No action is mandated by this specification regardless 1426 of the criticality value asserted for the extension. 1428 User notice is intended for display to a relying party when a 1429 certificate is used. The application software SHOULD display all 1430 user notices in all certificates of the certification path used, 1431 except that if a notice is duplicated only one copy need be 1432 displayed. To prevent such duplication, this qualifier SHOULD only 1433 be present in end-entity certificates and CA certificates issued to 1434 other organizations. 1436 The user notice has two optional fields: the noticeRef field and the 1437 explicitText field. 1439 The noticeRef field, if used, names an organization and 1440 identifies, by number, a particular textual statement prepared by 1441 that organization. For example, it might identify the 1442 organization "CertsRUs" and notice number 1. In a typical 1443 implementation, the application software will have a notice file 1444 containing the current set of notices for CertsRUs; the 1445 application will extract the notice text from the file and display 1446 it. Messages may be multilingual, allowing the software to select 1447 the particular language message for its own environment. 1449 An explicitText field includes the textual statement directly in 1450 the certificate. The explicitText field is a string with a 1451 maximum size of 200 characters. 1453 If both the noticeRef and explicitText options are included in the 1454 one qualifier and if the application software can locate the notice 1455 text indicated by the noticeRef option then that text should be 1456 displayed; otherwise, the explicitText string should be displayed. 1458 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 1460 anyPolicy OBJECT IDENTIFIER ::= {id-ce-certificate-policies 0} 1462 certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 1464 PolicyInformation ::= SEQUENCE { 1465 policyIdentifier CertPolicyId, 1466 policyQualifiers SEQUENCE SIZE (1..MAX) OF 1467 PolicyQualifierInfo OPTIONAL } 1469 CertPolicyId ::= OBJECT IDENTIFIER 1471 PolicyQualifierInfo ::= SEQUENCE { 1472 policyQualifierId PolicyQualifierId, 1473 qualifier ANY DEFINED BY policyQualifierId } 1475 -- policyQualifierIds for Internet policy qualifiers 1477 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 1478 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 1479 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 1481 PolicyQualifierId ::= 1482 OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) 1484 Qualifier ::= CHOICE { 1485 cPSuri CPSuri, 1486 userNotice UserNotice } 1488 CPSuri ::= IA5String 1490 UserNotice ::= SEQUENCE { 1491 noticeRef NoticeReference OPTIONAL, 1492 explicitText DisplayText OPTIONAL} 1494 NoticeReference ::= SEQUENCE { 1495 organization DisplayText, 1496 noticeNumbers SEQUENCE OF INTEGER } 1498 DisplayText ::= CHOICE { 1499 ia5String IA5String (SIZE (1..200)), 1500 visibleString VisibleString (SIZE (1..200)), 1501 bmpString BMPString (SIZE (1..200)), 1502 utf8String UTF8String (SIZE (1..200)) } 1504 4.2.1.6 Policy Mappings 1506 This extension is used in CA certificates. It lists one or more 1507 pairs of OIDs; each pair includes an issuerDomainPolicy and a 1508 subjectDomainPolicy. The pairing indicates the issuing CA considers 1509 its issuerDomainPolicy equivalent to the subject CA's 1510 subjectDomainPolicy. 1512 The issuing CA's users may accept an issuerDomainPolicy for certain 1513 applications. The policy mapping tells the issuing CA's users which 1514 policies associated with the subject CA are comparable to the policy 1515 they accept. 1517 Each issuerDomainPolicy named in the the policy mapping extension 1518 should also be asserted in a certificate policies extension in the 1519 same certificate. Policies should not be mapped either to or from 1520 the special value anyPolicy. (See 4.2.1.5 certificate policies). 1522 This extension may be supported by CAs and/or applications, and it 1523 MUST be non-critical. 1525 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 1527 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 1528 issuerDomainPolicy CertPolicyId, 1529 subjectDomainPolicy CertPolicyId } 1531 4.2.1.7 Subject Alternative Name 1533 The subject alternative names extension allows additional identities 1534 to be bound to the subject of the certificate. Defined options 1535 include an Internet electronic mail address, a DNS name, an IP 1536 address, and a uniform resource identifier (URI). Other options 1537 exist, including completely local definitions. Multiple name forms, 1538 and multiple instances of each name form, may be included. Whenever 1539 such identities are to be bound into a certificate, the subject 1540 alternative name (or issuer alternative name) extension MUST be used. 1542 Because the subject alternative name is considered to be definitively 1543 bound to the public key, all parts of the subject alternative name 1544 MUST be verified by the CA. 1546 Further, if the only subject identity included in the certificate is 1547 an alternative name form (e.g., an electronic mail address), then the 1548 subject distinguished name MUST be empty (an empty sequence), and the 1549 subjectAltName extension MUST be present. If the subject field 1550 contains an empty sequence, the subjectAltName extension MUST be 1551 marked critical. 1553 When the subjectAltName extension contains an Internet mail address, 1554 the address MUST be included as an rfc822Name. The format of an 1555 rfc822Name is an "addr-spec" as defined in RFC 822 [RFC 822]. An 1556 addr-spec has the form "local-part@domain". Note that an addr-spec 1557 has no phrase (such as a common name) before it, has no comment (text 1558 surrounded in parentheses) after it, and is not surrounded by "<" and 1559 ">". Note that while upper and lower case letters are allowed in an 1560 RFC 822 addr-spec, no significance is attached to the case. 1562 When the subjectAltName extension contains a iPAddress, the address 1563 MUST be stored in the octet string in "network byte order," as 1564 specified in RFC 791 [RFC 791]. The least significant bit (LSB) of 1565 each octet is the LSB of the corresponding byte in the network 1566 address. For IP Version 4, as specified in RFC 791, the octet string 1567 MUST contain exactly four octets. For IP Version 6, as specified in 1568 RFC 1883, the octet string MUST contain exactly sixteen octets [RFC 1569 1883]. 1571 When the subjectAltName extension contains a domain name service 1572 label, the domain name MUST be stored in the dNSName (an IA5String). 1573 The name MUST be in the "preferred name syntax," as specified by RFC 1574 1034 [RFC 1034]. Note that while upper and lower case letters are 1575 allowed in domain names, no signifigance is attached to the case. In 1576 addition, while the string " " is a legal domain name, subjectAltName 1577 extensions with a dNSName " " are not permitted. Finally, the use of 1578 the DNS representation for Internet mail addresses (wpolk.nist.gov 1579 instead of wpolk@nist.gov) MUST NOT be used; such identities are to 1580 be encoded as rfc822Name. 1582 Note: work is currently underway to specify domain names in 1583 international character sets. This names will likely not be 1584 accomodated by IA5String. Once this work is complete, this profile 1585 will be revisited and the appropriate functionality will be added. 1587 When the subjectAltName extension contains a URI, the name MUST be 1588 stored in the uniformResourceIdentifier (an IA5String). The name MUST 1589 be a non-relative URL, and MUST follow the URL syntax and encoding 1590 rules specified in [RFC 1738]. The name must include both a scheme 1591 (e.g., "http" or "ftp") and a scheme-specific-part. The scheme- 1592 specific-part must include a fully qualified domain name or IP 1593 address as the host. 1595 As specified in [RFC 1738], the scheme name is not case-sensitive 1596 (e.g., "http" is equivalent to "HTTP"). The host part is also not 1597 case-sensitive, but other components of the scheme-specific-part may 1598 be case-sensitive. When comparing URIs, conforming implementations 1599 MUST compare the scheme and host without regard to case, but assume 1600 the remainder of the scheme-specific-part is case sensitive. 1602 When the subjectAltName extension contains a DN in the directoryName, 1603 the DN MUST be unique for each subject entity certified by the one CA 1604 as defined by the issuer name field. A CA may issue more than one 1605 certificate with the same DN to the same subject entity. 1607 The subjectAltName may carry additional name types through the use of 1608 the otherName field. The format and semantics of the name are 1609 indicated through the OBJECT IDENTIFIER in the type-id field. The 1610 name itself is conveyed as value field in otherName. For example, 1611 Kerberos [RFC 1510] format names can be encoded into the otherName, 1612 using the krb5PrincipalName OID and the KerberosName syntax as 1613 defined in [PKINIT]. 1615 Subject alternative names may be constrained in the same manner as 1616 subject distinguished names using the name constraints extension as 1617 described in section 4.2.1.11. 1619 If the subjectAltName extension is present, the sequence MUST contain 1620 at least one entry. Unlike the subject field, conforming CAs MUST 1621 NOT issue certificates with subjectAltNames containing empty 1622 GeneralName fields. For example, an rfc822Name is represented as an 1623 IA5String. While an empty string is a valid IA5String, such an 1624 rfc822Name is not permitted by this profile. The behavior of clients 1625 that encounter such a certificate when processing a certificication 1626 path is not defined by this profile. 1628 Finally, the semantics of subject alternative names that include 1629 wildcard characters (e.g., as a placeholder for a set of names) are 1630 not addressed by this specification. Applications with specific 1631 requirements may use such names but shall define the semantics. 1633 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 1635 SubjectAltName ::= GeneralNames 1637 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 1639 GeneralName ::= CHOICE { 1640 otherName [0] OtherName, 1641 rfc822Name [1] IA5String, 1642 dNSName [2] IA5String, 1643 x400Address [3] ORAddress, 1644 directoryName [4] Name, 1645 ediPartyName [5] EDIPartyName, 1646 uniformResourceIdentifier [6] IA5String, 1647 iPAddress [7] OCTET STRING, 1648 registeredID [8] OBJECT IDENTIFIER} 1650 OtherName ::= SEQUENCE { 1651 type-id OBJECT IDENTIFIER, 1652 value [0] EXPLICIT ANY DEFINED BY type-id } 1654 EDIPartyName ::= SEQUENCE { 1655 nameAssigner [0] DirectoryString OPTIONAL, 1656 partyName [1] DirectoryString } 1658 4.2.1.8 Issuer Alternative Names 1660 As with 4.2.1.7, this extension is used to associate Internet style 1661 identities with the certificate issuer. Issuer alternative names MUST 1662 be encoded as in 4.2.1.7. 1664 Where present, this extension SHOULD NOT be marked critical. 1666 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 1668 IssuerAltName ::= GeneralNames 1670 4.2.1.9 Subject Directory Attributes 1672 The subject directory attributes extension is used to convey 1673 identification attributes (e.g.,nationality) of the subject. The 1674 extension is defined as a sequence of one or more attributes. This 1675 extension MUST be non-critical. 1677 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 1679 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 1681 4.2.1.10 Basic Constraints 1683 The basic constraints extension identifies whether the subject of the 1684 certificate is a CA and how deep a certification path may exist 1685 through that CA. 1687 The cA bit indicates if the certified public key may be used to 1688 verify signatures on other certificates. If the cA bit is asserted, 1689 then the keyCertSign bit in the key usage extension (see 4.2.1.3) 1690 MUST also be asserted. If the cA bit is not asserted, then the 1691 keyCertSign bit in the key usage extension MUST NOT be asserted. 1693 The pathLenConstraint field is meaningful only if cA is set to TRUE. 1694 In this case, it gives the maximum number of CA certificates that may 1695 follow this certificate in a certification path. (Note: One end- 1696 entity certificate will follow the final CA certificate in the path. 1697 The last certificate in a path is considered an end-entity 1698 certificate, whether the subject of the certificate is a CA or not.) 1699 A pathLenConstrinat of zero indicates that only an end-entity 1700 certificate may follow in the path. Where it appears, the 1701 pathLenConstraint field MUST be greater than or equal to zero. Where 1702 pathLenConstraint does not appear, there is no limit to the allowed 1703 length of the certification path. 1705 This extension MUST appear as a critical extension in all CA 1706 certificates. This extension MAY appear as a critical or non- 1707 critical extension in end entity certificates. 1709 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 1711 BasicConstraints ::= SEQUENCE { 1712 cA BOOLEAN DEFAULT FALSE, 1713 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 1715 4.2.1.11 Name Constraints 1717 The name constraints extension, which MUST be used only in a CA 1718 certificate, indicates a name space within which all subject names in 1719 subsequent certificates in a certification path shall be located. 1720 Restrictions may apply to the subject distinguished name or subject 1721 alternative names. Restrictions apply only when the specified name 1722 form is present. If no name of the type is in the certificate, the 1723 certificate is acceptable. 1725 Name constraints are not applied to certificates whose issuer and 1726 subject are identical. (This could prevent CAs that use name 1727 constraints from issuing self-signed certificates to implement key 1728 rollover.) 1730 Restrictions are defined in terms of permitted or excluded name 1731 subtrees. Any name matching a restriction in the excludedSubtrees 1732 field is invalid regardless of information appearing in the 1733 permittedSubtrees. This extension MUST be critical. 1735 Within this profile, the minimum and maximum fields are not used with 1736 any name forms, thus minimum is always zero, and maximum is always 1737 absent. 1739 For URIs, the constraint applies to the host part of the name. The 1740 constraint may specify a host or a domain. Examples would be 1741 "foo.bar.com"; and ".xyz.com". When the the constraint begins with 1742 a period, it may be expanded with one or more subdomains. That is, 1743 the constraint ".xyz.com" is satisfied by both abc.xyz.com and 1744 abc.def.xyz.com. However, the constraint ".xyz.com" is not satisfied 1745 by "xyz.com". When the constraint does not begin with a period, it 1746 specifies a host. 1748 A name constraint for Internet mail addresses may specify a 1749 particular mailbox, all addresses at a particular host, or all 1750 mailboxes in a domain. To indicate a particular mailbox, the 1751 constraint is the complete mail address. For example, "root@xyz.com" 1752 indicates the root mailbox on the host "xyz.com". To indicate all 1753 Internet mail addresses on a particular host, the constraint is 1754 specified as the host name. For example, the constraint "xyz.com" is 1755 satisfied by any mail address at the host "xyz.com". To specify any 1756 address within a domain, the constraint is specified with a leading 1757 period (as with URIs). For example, ".xyz.com" indicates all the 1758 Internet mail addresses in the domain "xyz.com", but not Internet 1759 mail addresses on the host "xyz.com". 1761 DNS name restrictions are expressed as foo.bar.com. Any DNS name that 1762 can be constructed by simply adding to the left hand side of the name 1763 satisfies the name constraint. For example, www.foo.bar.com would 1764 satisfy the constraint but foo1.bar.com would not. 1766 Legacy implementations exist where an RFC 822 name is embedded in the 1767 subject distinguished name in an attribute of type EmailAddress (see 1768 sec. 4.1.2.6). When rfc822 names are constrained, but the certificate 1769 does not include a subject alternative name, the rfc822 name 1770 constraint MUST be applied to the attribute of type EmailAddress in 1771 the subject distinguished name. The ASN.1 syntax for EmailAddress 1772 and the corresponding OID are supplied in Appendix A and B. 1774 Restrictions of the form directoryName MUST be applied to the subject 1775 field in the certificate and to the subjectAltName extensions of type 1776 directoryName. Restrictions of the form x400Address MUST be applied 1777 to subjectAltName extensions of type x400Address. 1779 When applying restrictions of the form directoryName, an 1780 implementation MUST compare DN attributes. At a minimum, 1781 implementations MUST perform the DN comparison rules specified in 1782 Section 4.1.2.4. CAs issuing certificates with a restriction of the 1783 form directoryName SHOULD NOT rely on implementation of the full ISO 1784 DN name comparison algorithm. This implies name restrictions shall 1785 be stated identically to the encoding used in the subject field or 1786 subjectAltName extension. 1788 The syntax of iPAddress MUST be as described in section 4.2.1.7 with 1789 the following additions specifically for Name Constraints. For IPv4 1790 addresses, the ipAddress field of generalName MUST contain eight (8) 1791 octets, encoded in the style of RFC 1519 (CIDR) to represent an 1792 address range.[RFC 1519] For IPv6 addresses, the ipAddress field 1793 MUST contain 32 octets similarly encoded. For example, a name 1794 constraint for "class C" subnet 10.9.8.0 shall be represented as the 1795 octets 0A 09 08 00 FF FF FF 00, representing the CIDR notation 1796 10.9.8.0/255.255.255.0. 1798 The syntax and semantics for name constraints for otherName, 1799 ediPartyName, and registeredID are not defined by this specification. 1801 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 1803 NameConstraints ::= SEQUENCE { 1804 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 1805 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 1807 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 1809 GeneralSubtree ::= SEQUENCE { 1810 base GeneralName, 1811 minimum [0] BaseDistance DEFAULT 0, 1812 maximum [1] BaseDistance OPTIONAL } 1814 BaseDistance ::= INTEGER (0..MAX) 1816 4.2.1.12 Policy Constraints 1818 The policy constraints extension can be used in certificates issued 1819 to CAs. The policy constraints extension constrains path validation 1820 in two ways. It can be used to prohibit policy mapping or require 1821 that each certificate in a path contain an acceptable policy 1822 identifier. 1824 If the inhibitPolicyMapping field is present, the value indicates the 1825 number of additional certificates that may appear in the path before 1826 policy mapping is no longer permitted. For example, a value of one 1827 indicates that policy mapping may be processed in certificates issued 1828 by the subject of this certificate, but not in additional 1829 certificates in the path. 1831 If the requireExplicitPolicy field is present, subsequent 1832 certificates shall include an acceptable policy identifier. The value 1833 of requireExplicitPolicy indicates the number of additional 1834 certificates that may appear in the path before an explicit policy is 1835 required. An acceptable policy identifier is the identifier of a 1836 policy required by the user of the certification path or the 1837 identifier of a policy which has been declared equivalent through 1838 policy mapping. 1840 Conforming CAs MUST NOT issue certificates where policy constraints 1841 is a null sequence. That is, at least one of the inhibitPolicyMapping 1842 field or the requireExplicitPolicy field MUST be present. The 1843 behavior of clients that encounter a null policy constraints field is 1844 not addressed in this profile. 1846 This extension may be critical or non-critical. 1848 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } 1850 PolicyConstraints ::= SEQUENCE { 1851 requireExplicitPolicy [0] SkipCerts OPTIONAL, 1852 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 1854 SkipCerts ::= INTEGER (0..MAX) 1856 4.2.1.13 Extended key usage field 1858 This field indicates one or more purposes for which the certified 1859 public key may be used, in addition to or in place of the basic 1860 purposes indicated in the key usage extension field. This field is 1861 defined as follows: 1863 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 1865 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 1867 KeyPurposeId ::= OBJECT IDENTIFIER 1869 Key purposes may be defined by any organization with a need. Object 1870 identifiers used to identify key purposes shall be assigned in 1871 accordance with IANA or ITU-T Rec. X.660 | ISO/IEC/ITU 9834-1. 1873 This extension may, at the option of the certificate issuer, be 1874 either critical or non-critical. 1876 If the extension is flagged critical, then the certificate MUST only 1877 be used for one of the purposes indicated. If multiple purposes are 1878 indicated the application need not recognize all purposes indicated, 1879 as long as the intended purpose is present and recognized. 1881 If the extension is flagged non-critical, then it indicates the 1882 intended purpose or purposes of the key, and may be used in finding 1883 the correct key/certificate of an entity that has multiple 1884 keys/certificates. It is an advisory field and does not imply that 1885 usage of the key is restricted by the certification authority to the 1886 purpose indicated. Certificate using applications may nevertheless 1887 require that a particular purpose be indicated in order for the 1888 certificate to be acceptable to that application. 1890 If a certificate contains both a critical key usage field and a 1891 critical extended key usage field, then both fields MUST be processed 1892 independently and the certificate MUST only be used for a purpose 1893 consistent with both fields. If there is no purpose consistent with 1894 both fields, then the certificate MUST NOT be used for any purpose. 1896 The following key usage purposes are defined by this profile: 1898 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 1900 id-kp-serverAuth OBJECT IDENTIFIER ::= {id-kp 1} 1901 -- TLS Web server authentication 1902 -- Key usage bits that may be consistent: digitalSignature, 1903 -- keyEncipherment or keyAgreement 1904 -- 1905 id-kp-clientAuth OBJECT IDENTIFIER ::= {id-kp 2} 1906 -- TLS Web client authentication 1907 -- Key usage bits that may be consistent: digitalSignature and/or 1908 -- keyAgreement 1909 -- 1910 id-kp-codeSigning OBJECT IDENTIFIER ::= {id-kp 3} 1911 -- Signing of downloadable executable code 1912 -- Key usage bits that may be consistent: digitalSignature 1913 -- 1914 id-kp-emailProtection OBJECT IDENTIFIER ::= {id-kp 4} 1915 -- E-mail protection 1916 -- Key usage bits that may be consistent: digitalSignature, 1917 -- nonRepudiation, and/or (keyEncipherment 1918 -- or keyAgreement) 1919 -- 1920 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 1921 -- Binding the hash of an object to a time from an agreed-upon time 1922 -- source. Key usage bits that may be consistent: digitalSignature, 1923 -- nonRepudiation 1925 4.2.1.14 CRL Distribution Points 1927 The CRL distribution points extension identifies how CRL information 1928 is obtained. The extension SHOULD be non-critical, but this profile 1929 recommends support for this extension by CAs and applications. 1930 Further discussion of CRL management is contained in section 5. 1932 The cRLDistributionPoints extension is a SEQUENCE of 1933 DistributionPoint. A DistributionPoint consists of three fields, 1934 each of which is optional: the name of the DistributionPoint, 1935 ReasonsFlags, and the cRLIssuer. While each component is optional, a 1936 DistributionPoint MUST NOT consist of only the ReasonsFlags field. If 1937 the distributionPoint omits cRLIssuer, the CRL MUST be issued by the 1938 CA that issued the certificate. If the distributionPointName is 1939 absent, cRLIssuer MUST be present and include a Name corresponding to 1940 an X.500 or LDAP directory entry where the CRL is located. 1942 If the cRLDistributionPoints extension contains a 1943 DistributionPointName of type URI, the following semantics MUST be 1944 assumed: the URI is a pointer to the current CRL for the associated 1945 reasons and will be issued by the associated cRLIssuer. The expected 1946 values for the URI are those defined in 4.2.1.7. Processing rules for 1947 other values are not defined by this specification. If the 1948 distributionPoint omits reasons, the CRL MUST include revocations for 1949 all reasons. 1951 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 } 1952 CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 1954 DistributionPoint ::= SEQUENCE { 1955 distributionPoint [0] DistributionPointName OPTIONAL, 1956 reasons [1] ReasonFlags OPTIONAL, 1957 cRLIssuer [2] GeneralNames OPTIONAL } 1959 DistributionPointName ::= CHOICE { 1960 fullName [0] GeneralNames, 1961 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 1963 ReasonFlags ::= BIT STRING { 1964 unused (0), 1965 keyCompromise (1), 1966 cACompromise (2), 1967 affiliationChanged (3), 1968 superseded (4), 1969 cessationOfOperation (5), 1970 certificateHold (6) } 1972 4.2.1.15 Inhibit Any-Policy 1974 The inhibit any-policy extension can be used in certificates issued 1975 to CAs. The inhibit any-policy indicates that the special any-policy 1976 OID, with the value {2 5 29 32 0}, is not considered an explicit 1977 match for other certificate policies. The value indicates the number 1978 of additional certificates that may appear in the path before any- 1979 policy is no longer permitted. For example, a value of one indicates 1980 that any-policy may be processed in certificates issued by the 1981 subject of this certificate, but not in additional certificates in 1982 the path. 1984 This extension MUST be critical. 1986 id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 } 1988 InhibitAnyPolicy ::= SkipCerts 1990 SkipCerts ::= INTEGER (0..MAX) 1992 4.2.1.16 Freshest CRL (a.k.a. Delta CRL Distribution Point) 1994 The freshest CRL extension identifies how delta-CRL information is 1995 obtained. The extension MUST be non-critical. Further discussion of 1996 CRL management is contained in section 5. 1998 The same syntax is used for this extension and the 1999 cRLDistributionPoints extension, and is described in section 2000 4.2.1.14. The same conventions apply to both extensions. 2002 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } 2004 FreshestCRL ::= CRLDistributionPoints 2006 4.2.2 Private Internet Extensions 2008 This section defines one new extension for use in the Internet Public 2009 Key Infrastructure. This extension may be used to direct 2010 applications to identify an on-line validation service supporting the 2011 issuing CA. As the information may be available in multiple forms, 2012 each extension is a sequence of IA5String values, each of which 2013 represents a URI. The URI implicitly specifies the location and 2014 format of the information and the method for obtaining the 2015 information. 2017 An object identifier is defined for the private extension. The 2018 object identifier associated with the private extension is defined 2019 under the arc id-pe within the id-pkix name space. Any future 2020 extensions defined for the Internet PKI will also be defined under 2021 the arc id-pe. 2023 id-pkix OBJECT IDENTIFIER ::= 2024 { iso(1) identified-organization(3) dod(6) internet(1) 2025 security(5) mechanisms(5) pkix(7) } 2027 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 2029 4.2.2.1 Authority Information Access 2031 The authority information access extension indicates how to access CA 2032 information and services for the issuer of the certificate in which 2033 the extension appears. Information and services may include on-line 2034 validation services and CA policy data. (The location of CRLs is not 2035 specified in this extension; that information is provided by the 2036 cRLDistributionPoints extension.) This extension may be included in 2037 subject or CA certificates, and it MUST be non-critical. 2039 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 2041 AuthorityInfoAccessSyntax ::= 2042 SEQUENCE SIZE (1..MAX) OF AccessDescription 2044 AccessDescription ::= SEQUENCE { 2045 accessMethod OBJECT IDENTIFIER, 2046 accessLocation GeneralName } 2048 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 2050 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 2052 Each entry in the sequence AuthorityInfoAccessSyntax describes the 2053 format and location of additional information provided by the CA who 2054 issued the certificate in which this extension appears. The type and 2055 format of the information is specified by the accessMethod field; the 2056 accessLocation field specifies the location of the information. The 2057 retrieval mechanism may be implied by the accessMethod or specified 2058 by accessLocation. 2060 This profile defines one OID for accessMethod. The id-ad-caIssuers 2061 OID is used when the additional information lists CAs that have 2062 issued certificates superior to the CA that issued the certificate 2063 containing this extension. The referenced CA Issuers description is 2064 intended to aid certificate users in the selection of a certification 2065 path that terminates at a point trusted by the certificate user. 2067 When id-ad-caIssuers appears as accessInfoType, the accessLocation 2068 field describes the referenced description server and the access 2069 protocol to obtain the referenced description. The accessLocation 2070 field is defined as a GeneralName, which can take several forms. 2071 Where the information is available via http, ftp, or ldap, 2072 accessLocation MUST be a uniformResourceIdentifier. Where the 2073 information is available via the directory access protocol (dap), 2074 accessLocation MUST be a directoryName. When the information is 2075 available via electronic mail, accessLocation MUST be an rfc822Name. 2076 The semantics of other name forms of accessLocation (when 2077 accessMethod is id-ad-caIssuers) are not defined by this 2078 specification. 2080 [RFC 2560] defines the access descriptor for the Online Certificate 2081 Status Protocol. When this access descriptor appears in the 2082 authority information access extension, this indicates the issuer 2083 provides revocation information for this certificate through the 2084 named OCSP service. Additional access descriptors may be defined in 2085 other PKIX specifications. 2087 4.2.2.2 Subject Information Access 2089 The subject information access extension indicates how to access 2090 information and services for the subject of the certificate in which 2091 the extension appears. When the subject is a CA, information and 2092 services may include certificate validation services and CA policy 2093 data. When the subject is an end entity, the information describes 2094 the type of services offered and how to access them. In this case, 2095 the contents of this extension are defined in the protocol 2096 specifications for the suported services. This extension may be 2097 included in subject or CA certificates, and it MUST be non-critical. 2099 id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 } 2101 SubjectInfoAccessSyntax ::= 2102 SEQUENCE SIZE (1..MAX) OF AccessDescription 2104 AccessDescription ::= SEQUENCE { 2105 accessMethod OBJECT IDENTIFIER, 2106 accessLocation GeneralName } 2108 Each entry in the sequence SubjectInfoAccessSyntax describes the 2109 format and location of additional information provided by the subject 2110 of the certificate in which this extension appears. The type and 2111 format of the information is specified by the accessMethod field; the 2112 accessLocation field specifies the location of the information. The 2113 retrieval mechanism may be implied by the accessMethod or specified 2114 by accessLocation. 2116 This profile defines one accessMethod to be used when the subject is 2117 a CA, and one access mehod to be used when the subject is an end 2118 entity. Additional access methods may be defined in the future in 2119 the protocol specifications for other services. 2121 The id-ad-caRepository OID is used when the subject is a CA, and 2122 publishes its certificates and CRLs (if issued) in a repository. The 2123 accessLocation field is defined as a GeneralName, which can take 2124 several forms. Where the information is available via http, ftp, or 2125 ldap, accessLocation MUST be a uniformResourceIdentifier. Where the 2126 information is available via the directory access protocol (dap), 2127 accessLocation MUST be a directoryName. When the information is 2128 available via electronic mail, accessLocation MUST be an rfc822Name. 2129 The semantics of other name forms of of accessLocation (when 2130 accessMethod is id-ad-caRepository) are not defined by this 2131 specification. 2133 The id-ad-timeStamping OID is used when the subject offers 2134 timestamping services using the Time STamp Protocol defined in [PKIX 2135 TSA]. Where the timestamping services are available via http or ftp, 2136 accessLocation MUST be a uniformResourceIdentifier. Where the 2137 timestamping services are available via electronic mail, 2138 accessLocation MUST be an rfc822Name. Where timestamping services 2139 are available using TCP/IP, the dNSName and ipAddress name forms may 2140 be used. The semantics of other name forms of accessLocation (when 2141 accessMethod is id-ad-timeStamping) are not defined by this 2142 specification. 2144 Additional access descriptors may be defined in other PKIX 2145 specifications. 2147 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 2149 id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 } 2151 id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 } 2153 5 CRL and CRL Extensions Profile 2155 As described above, one goal of this X.509 v2 CRL profile is to 2156 foster the creation of an interoperable and reusable Internet PKI. 2157 To achieve this goal, guidelines for the use of extensions are 2158 specified, and some assumptions are made about the nature of 2159 information included in the CRL. 2161 CRLs may be used in a wide range of applications and environments 2162 covering a broad spectrum of interoperability goals and an even 2163 broader spectrum of operational and assurance requirements. This 2164 profile establishes a common baseline for generic applications 2165 requiring broad interoperability. The profile defines a baseline set 2166 of information that can be expected in every CRL. Also, the profile 2167 defines common locations within the CRL for frequently used 2168 attributes as well as common representations for these attributes. 2170 This profile does not define any private Internet CRL extensions or 2171 CRL entry extensions. 2173 Environments with additional or special purpose requirements may 2174 build on this profile or may replace it. 2176 Conforming CAs are not required to issue CRLs if other revocation or 2177 certificate status mechanisms are provided. Conforming CAs that 2178 issue CRLs MUST issue version 2 CRLs, and CAs MUST include the date 2179 by which the next CRL will be issued in the nextUpdate field (see 2180 sec. 5.1.2.5), the CRL number extension (see sec. 5.2.3) and the 2181 authority key identifier extension (see sec. 5.2.1). Conforming 2182 applications are required to process version 1 and 2 CRLs. 2184 5.1 CRL Fields 2186 The X.509 v2 CRL syntax is as follows. For signature calculation, 2187 the data that is to be signed is ASN.1 DER encoded. ASN.1 DER 2188 encoding is a tag, length, value encoding system for each element. 2190 CertificateList ::= SEQUENCE { 2191 tbsCertList TBSCertList, 2192 signatureAlgorithm AlgorithmIdentifier, 2193 signatureValue BIT STRING } 2195 TBSCertList ::= SEQUENCE { 2196 version Version OPTIONAL, 2197 -- if present, shall be v2 2198 signature AlgorithmIdentifier, 2199 issuer Name, 2200 thisUpdate Time, 2201 nextUpdate Time OPTIONAL, 2202 revokedCertificates SEQUENCE OF SEQUENCE { 2203 userCertificate CertificateSerialNumber, 2204 revocationDate Time, 2205 crlEntryExtensions Extensions OPTIONAL 2206 -- if present, shall be v2 2207 } OPTIONAL, 2208 crlExtensions [0] EXPLICIT Extensions OPTIONAL 2209 -- if present, shall be v2 2210 } 2212 -- Version, Time, CertificateSerialNumber, and Extensions 2213 -- are all defined in the ASN.1 in section 4.1 2215 -- AlgorithmIdentifier is defined in section 4.1.1.2 2217 The following items describe the use of the X.509 v2 CRL in the 2218 Internet PKI. 2220 5.1.1 CertificateList Fields 2222 The CertificateList is a SEQUENCE of three required fields. The 2223 fields are described in detail in the following subsections. 2225 5.1.1.1 tbsCertList 2227 The first field in the sequence is the tbsCertList. This field is 2228 itself a sequence containing the name of the issuer, issue date, 2229 issue date of the next list, the optional list of revoked 2230 certificates, and optional CRL extensions. When there are no revoked 2231 certificates, the revoked certificates list is absent. When one or 2232 more certificates are revoked, each entry on the revoked certificate 2233 list is defined by a sequence of user certificate serial number, 2234 revocation date, and optional CRL entry extensions. 2236 5.1.1.2 signatureAlgorithm 2238 The signatureAlgorithm field contains the algorithm identifier for 2239 the algorithm used by the CA to sign the CertificateList. The field 2240 is of type AlgorithmIdentifier, which is defined in section 4.1.1.2. 2241 [PKIX ALGS] lists the supported algorithms for this specification. 2242 Conforming CAs MUST use the algorithm identifiers presented in [PKIX 2243 ALGS] when signing with a supported signature algorithm. 2245 This field MUST contain the same algorithm identifier as the 2246 signature field in the sequence tbsCertList (see sec. 5.1.2.2). 2248 5.1.1.3 signatureValue 2250 The signatureValue field contains a digital signature computed upon 2251 the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded tbsCertList 2252 is used as the input to the signature function. This signature value 2253 is then ASN.1 encoded as a BIT STRING and included in the CRL's 2254 signatureValue field. The details of this process are specified for 2255 each of the supported algorithms in [PKIX ALGS]. 2257 5.1.2 Certificate List "To Be Signed" 2259 The certificate list to be signed, or TBSCertList, is a SEQUENCE of 2260 required and optional fields. The required fields identify the CRL 2261 issuer, the algorithm used to sign the CRL, the date and time the CRL 2262 was issued, and the date and time by which the CA will issue the next 2263 CRL. 2265 Optional fields include lists of revoked certificates and CRL 2266 extensions. The revoked certificate list is optional to support the 2267 case where a CA has not revoked any unexpired certificates that it 2268 has issued. The profile requires conforming CAs to use the CRL 2269 extension cRLNumber in all CRLs issued. 2271 5.1.2.1 Version 2273 This optional field describes the version of the encoded CRL. When 2274 extensions are used, as required by this profile, this field MUST be 2275 present and MUST specify version 2 (the integer value is 1). 2277 5.1.2.2 Signature 2279 This field contains the algorithm identifier for the algorithm used 2280 to sign the CRL. [PKIX ALGS] lists OIDs for the most popular 2281 signature algorithms used in the Internet PKI. 2283 This field MUST contain the same algorithm identifier as the 2284 signatureAlgorithm field in the sequence CertificateList (see section 2285 5.1.1.2). 2287 5.1.2.3 Issuer Name 2289 The issuer name identifies the entity who has signed and issued the 2290 CRL. The issuer identity is carried in the issuer name field. 2291 Alternative name forms may also appear in the issuerAltName extension 2292 (see sec. 5.2.2). The issuer name field MUST contain an X.500 2293 distinguished name (DN). The issuer name field is defined as the 2294 X.501 type Name, and MUST follow the encoding rules for the issuer 2295 name field in the certificate (see sec. 4.1.2.4). 2297 5.1.2.4 This Update 2299 This field indicates the issue date of this CRL. ThisUpdate may be 2300 encoded as UTCTime or GeneralizedTime. 2302 CAs conforming to this profile that issue CRLs MUST encode thisUpdate 2303 as UTCTime for dates through the year 2049. CAs conforming to this 2304 profile that issue CRLs MUST encode thisUpdate as GeneralizedTime for 2305 dates in the year 2050 or later. 2307 Where encoded as UTCTime, thisUpdate MUST be specified and 2308 interpreted as defined in section 4.1.2.5.1. Where encoded as 2309 GeneralizedTime, thisUpdate MUST be specified and interpreted as 2310 defined in section 4.1.2.5.2. 2312 5.1.2.5 Next Update 2314 This field indicates the date by which the next CRL will be issued. 2315 The next CRL could be issued before the indicated date, but it will 2316 not be issued any later than the indicated date. CAs SHOULD issue 2317 CRLs with a nextUpdate time equal to or later than all previous CRLs. 2318 nextUpdate may be encoded as UTCTime or GeneralizedTime. 2320 This profile requires inclusion of nextUpdate in all CRLs issued by 2321 conforming CAs. Note that the ASN.1 syntax of TBSCertList describes 2322 this field as OPTIONAL, which is consistent with the ASN.1 structure 2323 defined in [X.509]. The behavior of clients processing CRLs which 2324 omit nextUpdate is not specified by this profile. 2326 CAs conforming to this profile that issue CRLs MUST encode nextUpdate 2327 as UTCTime for dates through the year 2049. CAs conforming to this 2328 profile that issue CRLs MUST encode nextUpdate as GeneralizedTime for 2329 dates in the year 2050 or later. 2331 Where encoded as UTCTime, nextUpdate MUST be specified and 2332 interpreted as defined in section 4.1.2.5.1. Where encoded as 2333 GeneralizedTime, nextUpdate MUST be specified and interpreted as 2334 defined in section 4.1.2.5.2. 2336 5.1.2.6 Revoked Certificates 2338 When there are no revoked certificates, the revoked certificates list 2339 is absent. Otherwise, revoked certificates are listed by their 2340 serial numbers. Certificates revoked by the CA are uniquely 2341 identified by the certificate serial number. The date on which the 2342 revocation occurred is specified. The time for revocationDate MUST 2343 be expressed as described in section 5.1.2.4. Additional information 2344 may be supplied in CRL entry extensions; CRL entry extensions are 2345 discussed in section 5.3. 2347 5.1.2.7 Extensions 2349 This field may only appear if the version is 2 (see sec. 5.1.2.1). 2350 If present, this field is a SEQUENCE of one or more CRL extensions. 2351 CRL extensions are discussed in section 5.2. 2353 5.2 CRL Extensions 2355 The extensions defined by ANSI X9 and ISO/IEC/ITU for X.509 v2 CRLs 2356 [X.509] [X9.55] provide methods for associating additional attributes 2357 with CRLs. The X.509 v2 CRL format also allows communities to define 2358 private extensions to carry information unique to those communities. 2359 Each extension in a CRL may be designated as critical or non- 2360 critical. A CRL validation MUST fail if it encounters a critical 2361 extension which it does not know how to process. However, an 2362 unrecognized non-critical extension may be ignored. The following 2363 subsections present those extensions used within Internet CRLs. 2364 Communities may elect to include extensions in CRLs which are not 2365 defined in this specification. However, caution should be exercised 2366 in adopting any critical extensions in CRLs which might be used in a 2367 general context. 2369 Conforming CAs that issue CRLs are required to include the authority 2370 key identifier (see sec. 5.2.1) and the CRL number (see sec. 5.2.3) 2371 extensions in all CRLs issued. 2373 5.2.1 Authority Key Identifier 2375 The authority key identifier extension provides a means of 2376 identifying the public key corresponding to the private key used to 2377 sign a CRL. The identification can be based on either the key 2378 identifier (the subject key identifier in the CRL signer's 2379 certificate) or on the issuer name and serial number. This extension 2380 is especially useful where an issuer has more than one signing key, 2381 either due to multiple concurrent key pairs or due to changeover. 2383 Conforming CAs MUST use the key identifier method, and MUST include 2384 this extension in all CRLs issued. 2386 The syntax for this CRL extension is defined in section 4.2.1.1. 2388 5.2.2 Issuer Alternative Name 2390 The issuer alternative names extension allows additional identities 2391 to be associated with the issuer of the CRL. Defined options include 2392 an rfc822 name (electronic mail address), a DNS name, an IP address, 2393 and a URI. Multiple instances of a name and multiple name forms may 2394 be included. Whenever such identities are used, the issuer 2395 alternative name extension MUST be used. 2397 The issuerAltName extension SHOULD NOT be marked critical. 2399 The OID and syntax for this CRL extension are defined in section 2400 4.2.1.8. 2402 5.2.3 CRL Number 2404 The CRL number is a non-critical CRL extension which conveys a 2405 monotonically increasing sequence number for each CRL issued by a CA. 2406 This extension allows users to easily determine when a particular CRL 2407 supersedes another CRL. CAs conforming to this profile MUST include 2408 this extension in all CRLs. 2410 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 2412 cRLNumber ::= INTEGER (0..MAX) 2414 5.2.4 Delta CRL Indicator 2416 The delta CRL indicator is a critical CRL extension that identifies a 2417 CRL as being a delta CRL. Delta CRLs contain updates to revocation 2418 information previously distributed, rather than all the information 2419 that would appear in a complete CRL. The use of delta CRLs can 2420 significantly reduce network load and processing time in some 2421 environments. Delta CRLs are generally smaller than the CRLs they 2422 update, so applications that obtain delta CRLs consume less network 2423 bandwidth than applications that obtain the corresponding complete 2424 CRLs. Applications which store revocation information in a format 2425 other than the CRL structure can add new revocation information to 2426 the local database without reprocessing information. 2428 The delta CRL indicator extension contains a single value of type 2429 BaseCRLNumber. This value identifies the CRL number of the base CRL 2430 that was used as the foundation in the generation of this delta CRL. 2431 The referenced base CRL is a CRL that was explicitly issued as a CRL 2432 that is complete for a given scope (e.g., a set of revocation reasons 2433 or a particular distribution point.) The CRL containing the delta CRL 2434 indicator extension contains all updates to the certificate 2435 revocation status for that same scope. The combination of a CRL 2436 containing the delta CRL indicator extension plus the CRL referenced 2437 in the BaseCRLNumber component of this extension is equivalent to a 2438 full CRL, for the applicable scope, at the time of publication of the 2439 delta CRL. 2441 When a conforming CA issues a delta CRL, the CA MUST also issue a CRL 2442 that is complete for the given scope. Both the delta CRL and the 2443 complete CRL MUST include the CRL number extension (see sec. 5.2.3). 2444 The CRL number extension in the delta CRL and the complete CRL MUST 2445 contain the same value. When a delta CRL is issued, it MUST cover 2446 the same set of reasons and same set of certificates that were 2447 covered by the base CRL it references. 2449 An application can construct a CRL that is complete for a given 2450 scope, at the current time, in either of the following ways: 2452 (a) by retrieving the current delta CRL for that scope, and 2453 combining it with an issued CRL that is complete for that scope 2454 and that has a cRLNumber greater than or equal to the cRLNumber of 2455 the base CRL referenced in the delta CRL; or 2457 (b) by retrieving the current delta CRL for that scope and 2458 combining it with a locally constructed CRL whose cRLNumber is 2459 greater than or equal to the cRLNumber of the base CRL referenced 2460 in the current delta CRL. 2462 The constructed CRL has the CRL number specified in the CRL number 2463 extension found in the delta CRL used in its construction. 2465 CAs must ensure that application of a delta CRL to the referenced 2466 base revocation information accurately reflects the current status of 2467 revocation. If a CA supports the certificateHold revocation reason 2468 the following rules must be applied when generating delta CRLs: 2470 (a) If a certificate was listed as revoked with revocation reason 2471 certificateHold on a CRL (either a delta CRL or a CRL that is 2472 complete for a given scope), whose cRLNumber is n, and the hold is 2473 subsequently released, the certificate must be included in all 2474 delta CRLs issued after the hold is released where the cRLNumber 2475 of the referenced base CRL is less than or equal to n. The 2476 certificate must be listed with revocation reason removeFromCRL 2477 unless the certificate is subsequently revoked again for one of 2478 the revocation reasons covered by the delta CRL, in which case the 2479 certificate must be listed with the revocation reason appropriate 2480 for the subsequent revocation. 2482 (b) If the certificate was not removed from hold, but was 2483 permanently revoked, then it must be listed on all subsequent 2484 delta CRLs where the cRLNumber of the referenced base CRL is less 2485 than the cRLNumber of the CRL (either a delta CRL or a CRL that is 2486 complete for the given scope) on which the permanent revocation 2487 notice first appeared. 2489 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 2491 deltaCRLIndicator EXTENSION ::= { 2492 SYNTAX BaseCRLNumber 2493 IDENTIFIED BY id-ce-deltaCRLIndicator } 2495 BaseCRLNumber ::= CRLNumber 2497 5.2.5 Issuing Distribution Point 2499 The issuing distribution point is a critical CRL extension that 2500 identifies the CRL distribution point for a particular CRL, and it 2501 indicates whether the CRL covers revocation for end entity 2502 certificates only, CA certificates only, or a limited set of reason 2503 codes. Although the extension is critical, conforming 2504 implementations are not required to support this extension. 2506 The CRL is signed using the CA's private key. CRL Distribution 2507 Points do not have their own key pairs. If the CRL is stored in the 2508 X.500 Directory, it is stored in the Directory entry corresponding to 2509 the CRL distribution point, which may be different than the Directory 2510 entry of the CA. 2512 The reason codes associated with a distribution point shall be 2513 specified in onlySomeReasons. If onlySomeReasons does not appear, the 2514 distribution point shall contain revocations for all reason codes. 2515 CAs may use CRL distribution points to partition the CRL on the basis 2516 of compromise and routine revocation. In this case, the revocations 2517 with reason code keyCompromise (1) and cACompromise (2) appear in one 2518 distribution point, and the revocations with other reason codes 2519 appear in another distribution point. 2521 Where the issuingDistributionPoint extension contains a URL, the 2522 following semantics MUST be assumed: the object is a pointer to the 2523 most current CRL issued by this CA. The URI schemes ftp, http, 2524 mailto [RFC1738] and ldap [RFC1778] are defined for this purpose. 2525 The URI MUST be an absolute, not relative, pathname and MUST specify 2526 the host. 2528 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 2530 issuingDistributionPoint ::= SEQUENCE { 2531 distributionPoint [0] DistributionPointName OPTIONAL, 2532 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 2533 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 2534 onlySomeReasons [3] ReasonFlags OPTIONAL, 2535 indirectCRL [4] BOOLEAN DEFAULT FALSE } 2537 5.2.6 Freshest CRL (a.k.a. Delta CRL Distribution Point) 2539 The freshest CRL extension identifies how delta-CRL information for 2540 this CRL is obtained. The extension MUST be non-critical. 2542 The same syntax is used for this extension as the 2543 cRLDistributionPoints certificate extension, and is described in 2544 section 4.2.1.14. The same conventions apply to both extensions. 2546 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } 2548 FreshestCRL ::= CRLDistributionPoints 2550 5.3 CRL Entry Extensions 2552 The CRL entry extensions already defined by ANSI X9 and ISO/IEC/ITU 2553 for X.509 v2 CRLs provide methods for associating additional 2554 attributes with CRL entries [X.509] [X9.55]. The X.509 v2 CRL format 2555 also allows communities to define private CRL entry extensions to 2556 carry information unique to those communities. Each extension in a 2557 CRL entry may be designated as critical or non-critical. A CRL 2558 validation MUST fail if it encounters a critical CRL entry extension 2559 which it does not know how to process. However, an unrecognized 2560 non-critical CRL entry extension may be ignored. The following 2561 subsections present recommended extensions used within Internet CRL 2562 entries and standard locations for information. Communities may 2563 elect to use additional CRL entry extensions; however, caution should 2564 be exercised in adopting any critical extensions in CRL entries which 2565 might be used in a general context. 2567 All CRL entry extensions used in this specification are non-critical. 2568 Support for these extensions is optional for conforming CAs and 2569 applications. However, CAs that issue CRLs SHOULD include reason 2570 codes (see sec. 5.3.1) and invalidity dates (see sec. 5.3.3) whenever 2571 this information is available. 2573 5.3.1 Reason Code 2575 The reasonCode is a non-critical CRL entry extension that identifies 2576 the reason for the certificate revocation. CAs are strongly 2577 encouraged to include meaningful reason codes in CRL entries; 2578 however, the reason code CRL entry extension SHOULD be absent instead 2579 of using the unspecified (0) reasonCode value. 2581 id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 } 2583 -- reasonCode ::= { CRLReason } 2585 CRLReason ::= ENUMERATED { 2586 unspecified (0), 2587 keyCompromise (1), 2588 cACompromise (2), 2589 affiliationChanged (3), 2590 superseded (4), 2591 cessationOfOperation (5), 2592 certificateHold (6), 2593 removeFromCRL (8) } 2595 5.3.2 Hold Instruction Code 2597 The hold instruction code is a non-critical CRL entry extension that 2598 provides a registered instruction identifier which indicates the 2599 action to be taken after encountering a certificate that has been 2600 placed on hold. 2602 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 2604 holdInstructionCode ::= OBJECT IDENTIFIER 2606 The following instruction codes have been defined. Conforming 2607 applications that process this extension MUST recognize the following 2608 instruction codes. 2610 holdInstruction OBJECT IDENTIFIER ::= 2611 { iso(1) member-body(2) us(840) x9-57(10040) 2 } 2613 id-holdinstruction-none OBJECT IDENTIFIER ::= {holdInstruction 1} 2614 id-holdinstruction-callissuer 2615 OBJECT IDENTIFIER ::= {holdInstruction 2} 2616 id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3} 2618 Conforming applications which encounter an id-holdinstruction- 2619 callissuer MUST call the certificate issuer or reject the 2620 certificate. Conforming applications which encounter an id- 2621 holdinstruction-reject MUST reject the certificate. The hold 2622 instruction id-holdinstruction-none is semantically equivalent to the 2623 absence of a holdInstructionCode, and its use is strongly deprecated 2624 for the Internet PKI. 2626 5.3.3 Invalidity Date 2628 The invalidity date is a non-critical CRL entry extension that 2629 provides the date on which it is known or suspected that the private 2630 key was compromised or that the certificate otherwise became invalid. 2631 This date may be earlier than the revocation date in the CRL entry, 2632 which is the date at which the CA processed the revocation. When a 2633 revocation is first posted by a CA in a CRL, the invalidity date may 2634 precede the date of issue of earlier CRLs, but the revocation date 2635 SHOULD NOT precede the date of issue of earlier CRLs. Whenever this 2636 information is available, CAs are strongly encouraged to share it 2637 with CRL users. 2639 The GeneralizedTime values included in this field MUST be expressed 2640 in Greenwich Mean Time (Zulu), and MUST be specified and interpreted 2641 as defined in section 4.1.2.5.2. 2643 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 2645 invalidityDate ::= GeneralizedTime 2647 5.3.4 Certificate Issuer 2649 This CRL entry extension identifies the certificate issuer associated 2650 with an entry in an indirect CRL, i.e. a CRL that has the indirectCRL 2651 indicator set in its issuing distribution point extension. If this 2652 extension is not present on the first entry in an indirect CRL, the 2653 certificate issuer defaults to the CRL issuer. On subsequent entries 2654 in an indirect CRL, if this extension is not present, the certificate 2655 issuer for the entry is the same as that for the preceding entry. 2656 This field is defined as follows: 2658 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } 2660 certificateIssuer ::= GeneralNames 2662 If used by conforming CAs that issue CRLs, this extension MUST always 2663 be critical. If an implementation ignored this extension it could 2664 not correctly attribute CRL entries to certificates. This 2665 specification RECOMMENDS that implementations recognize this 2666 extension. 2668 6 Certification Path Validation 2670 Certification path validation procedures for the Internet PKI are 2671 based on the algorithm supplied in [X.509]. Certification path 2672 processing verifies the binding between the subject distinguished 2673 name and/or subject alternative name and subject public key. The 2674 binding is limited by constraints which are specified in the 2675 certificates which comprise the path and the initial state variables 2676 which are specified by the relying party. The basic constraints and 2677 policy constraints extensions allow the certification path processing 2678 logic to automate the decision making process. 2680 This section describes an algorithm for validating certification 2681 paths. Conforming implementations of this specification are not 2682 required to implement this algorithm, but MUST provide functionality 2683 equivalent to the external behavior resulting from this procedure. 2684 Any algorithm may be used by a particular implementation so long as 2685 it derives the correct result. 2687 In section 6.1, the text describes basic path validation. Valid paths 2688 begin with certificates issued by a "most-trusted CA". The algorithm 2689 requires the public key of the CA, the CA's name, and any constraints 2690 upon the set of paths which may be validated using this key. 2692 The selection of a "most-trusted CA" is a matter of policy: it could 2693 be the top CA in a hierarchical PKI; the CA that issued the 2694 verifier's own certificate(s); or any other CA in a network PKI. The 2695 path validation procedure is the same regardless of the choice of 2696 "most-trusted CA." In addition, different applications may rely on 2697 different "most-trusted CA", or may accept paths that begin with any 2698 of a set of "most-trusted CAs." 2700 Section 6.2 describes methods for using the path validation algorithm 2701 in specific implementations. Two specific cases are discussed: the 2702 case where paths may begin with one of several trusted CAs; and where 2703 compatibility with the PEM architecture is required. 2705 Section 6.3 describes the steps necessary to determine if a 2706 certificate is revoked or on hold status when CRLs are the revocation 2707 mechanism used by the certificate issuer. 2709 6.1 Basic Path Validation 2711 This text describes an algorithm for X.509 path processing. A 2712 conformant implementation MUST include an X.509 path processing 2713 procedure that is functionally equivalent to the external behavior of 2714 this algorithm. However, some of the certificate fields processed in 2715 this algorithm are optional for compliant implementations. Clients 2716 that do not support these fields may omit the corresponding steps in 2717 the path validation algorithm. 2719 For example, clients are not required to support the policy mapping 2720 extension. Clients that do not support this extension may omit the 2721 path validation steps where policy mappings are processed. Note that 2722 clients MUST reject the certificate if it contains critical 2723 extensions that are not supported. 2725 This text describes the trust anchor as an input to the algorithm. 2726 There is no requirement that the same trust anchor be used to 2727 validate all certification paths. Different trust anchors may be 2728 used to validate different paths, as discussed further in Section 2729 6.2. 2731 The primary goal of path validation is to verify the binding between 2732 a subject distinguished name or subject alternative name and subject 2733 public key, as represented in the end entity certificate, based on 2734 the public key of the trust anchor. This requires obtaining a 2735 sequence of certificates that support that binding. The procedure 2736 performed to obtain this sequence of certificates is outside the 2737 scope of this section. 2739 To meet this goal, the path validation process verifies, among other 2740 things, that a prospective certification path (a sequence of n 2741 certificates) satisfies the following conditions: 2743 (a) for all x in {1, ..., n-1}, the subject of certificate x is 2744 the issuer of certificate x+1; 2746 (b) certificate 1 is issued by the trust anchor; 2748 (c) certificate n is the end entity certificate; and 2750 (d) for all x in {1, ..., n}, the certificate was valid at the 2751 time in question. 2753 A particular certification path may not, however, be appropriate for 2754 all applications. The path validation process also determines the 2755 set of certificate policies that are valid for this path, based on 2756 the certificate policies extension, policy mapping extension, policy 2757 constraints extension, and inhibit any-policy extension. To achieve 2758 this, the path validation algorithm constructs a valid policy tree. 2759 If the set of certificate policies that are valid for this path is 2760 not empty, then the result will be a valid policy tree of depth n, 2761 otherwise the result will be a NULL valid policy tree. 2763 This section presents the algorithm in four basic steps: (1) 2764 initialization, (2) basic certificate processing, (3) preparation for 2765 the next certificate, and (4) wrap-up. Steps (1) and (4) are 2766 performed exactly once. Step (2) is performed for all certificates 2767 in the path. Step (3) is performed for all certificates in the path 2768 except the final certificate. Figure 2 provides a high-level 2769 flowchart of this algorithm. 2771 +-------+ 2772 | START | 2773 +-------+ 2774 | 2775 V 2776 +----------------+ 2777 | Initialization | 2778 +----------------+ 2779 | 2780 +<--------------------+ 2781 | | 2782 V | 2783 +----------------+ | 2784 | Process Cert | | 2785 +----------------+ | 2786 | | 2787 V | 2788 +================+ | 2789 | IF Last Cert | | 2790 | in Path | | 2791 +================+ | 2792 | | | 2793 THEN | | ELSE | 2794 V V | 2795 +----------------+ +----------------+ | 2796 | Wrap up | | Prepare for | | 2797 +----------------+ | Next Cert | | 2798 | +----------------+ | 2799 V | | 2800 +-------+ +--------------+ 2801 | STOP | 2802 +-------+ 2804 Figure 2. Path Processing Flowchart 2806 6.1.1 Inputs 2808 This algorithm assumes the following seven inputs are provided to the 2809 path processing logic: 2811 (a) a prospective certification path of length n; 2813 (b) the time, T, for which the validity of the path should be 2814 determined. This may be the current date/time, or some point in 2815 the past. 2817 (c) user-initial-policy-set: A set of certificate policy 2818 identifiers naming the policies that are acceptable to the 2819 certificate user. The user-initial-policy-set contains the special 2820 value any-policy if the user is not concerned about certificate 2821 policy. 2823 (d) trust anchor information, describing a CA that serves as a 2824 trust anchor for the certification path. The trust anchor 2825 information includes: 2827 (1) the trusted issuer name, 2829 (2) the trusted public key algorithm, 2831 (3) the trusted public key, and 2833 (4) optionally, the trusted public key parameters associated 2834 with the public key. 2836 The trust anchor information may be provided to the path 2837 processing procedure in the form of a self-signed certificate. The 2838 trusted anchor information is trusted because it was delivered to 2839 the path processing procedure by some trustworthy out-of-band 2840 procedure. If the trusted public key algorithm requires 2841 parameters, then the parameters are provided along with the 2842 trusted public key. 2844 (e) initial-policy-mapping-inhibit, which indicates if policy 2845 mapping is allowed in the certification path. 2847 (f) initial-explicit-policy, which indicates if the path must be 2848 valid for at least one of the certificate policies in the user- 2849 initial-policy-set. 2851 (g) initial-any-policy-inhibit, which indicates whether the any- 2852 policy OID should be processed if it is included in a certificate. 2854 6.1.2 Initialization 2856 The initialization phase establishes eleven state variables based 2857 upon the seven inputs: 2859 (a) valid_policy_tree: A tree of certificate policies with their 2860 optional qualifiers; each of the leaves of the tree represents a 2861 valid policy at this stage in the certification path validation. 2862 If valid policies exist at this stage in the certification path 2863 validation, the depth of the tree is equal to the number of 2864 certificates in the chain that have been processed. If valid 2865 policies do not exist at this stage in the certification path 2866 validation, the tree is set to NULL. Once the tree is set to NULL, 2867 policy processing ceases. 2869 Each node in the valid_policy_tree includes four data objects: the 2870 valid policy, a set of associated policy qualifiers, a set of one 2871 or more expected policy values, and a criticality indicator. If 2872 the node is at depth x, the components of the node have the 2873 following semantics: 2875 (1) The valid_policy is a single policy OID representing a 2876 valid policy for the path of length x. 2878 (2) The qualifier_set is a set of policy qualifiers associated 2879 with the valid policy in certificate x. 2881 (3) The criticality_indicator indicates whether the certificate 2882 policy extension in certificate x was marked as critical. 2884 (4) The expected_policy_set contains one or more policy OIDs 2885 that would satisfy this policy in the certificate x+1. 2887 The initial value of the valid_policy_tree is a single node with 2888 valid_policy any-policy, an empty qualifier_set, an 2889 expected_policy_set with the single value any-policy, and a 2890 criticality_indicator of FALSE. This node is considered to be at 2891 depth zero. 2893 Figure 3 is a graphic representation of the initial state of the 2894 valid_policy_tree. Additional figures will use this format to 2895 describe changes in the valid_policy_tree during path processing. 2897 +----------------+ 2898 | any-policy | <---- valid_policy 2899 +----------------+ 2900 | {} | <---- qualifier_set 2901 +----------------+ 2902 | FALSE | <---- criticality_indicator 2903 +----------------+ 2904 | {any-policy} | <---- expected_policy_set 2905 +----------------+ 2907 Figure 3. Initial value of the valid_policy_tree state variable 2909 (b) permitted_subtrees: A set of root names for each name type 2910 (e.g., X.500 distinguished names, email addresses, or ip 2911 addresses) defining a set of subtrees within which all subject 2912 names in subsequent certificates in the certification path shall 2913 fall. This variable includes a set for each name type: the initial 2914 value for the set for Distinguished Names is the set of all 2915 Distinguished names; the initial value for the set of RFC822 names 2916 is the set of all RFC822 names, etc. 2918 (c) excluded_subtrees: A set of root names for each name type 2919 (e.g., X.500 distinguished names, email addresses, or ip 2920 addresses) defining a set of subtrees within which no subject name 2921 in subsequent certificates in the certification path may fall. 2922 This variable includes a set for each name type, and the initial 2923 value for each set is empty. 2925 (d) explicit_policy: an integer which indicates if a non-NULL 2926 valid_policy_tree is required. The integer indicates the number of 2927 non-self-issued certificates to be processed before this 2928 requirement is imposed. Once set, this variable may be decreased, 2929 but may not be increased. That is, if a certificate in the path 2930 requires a non-NULL valid_policy_tree, a later certificate can not 2931 remove this requirement. If initial-explicit-policy is set, then 2932 the initial value is 0, otherwise the initial value is n+1. 2934 (e) inhibit_any-policy: an integer which indicates whether the 2935 any-policy policy identifier is considered a match. The integer 2936 indicates the number of non-self-issued certificates to be 2937 processed before the any-policy OID, if asserted in a certificate, 2938 is ignored. Once set, this variable may be decreased, but may not 2939 be increased. That is, if a certificate in the path inhibits 2940 processing of any-policy, a later certificate can not permit it. 2941 If initial-any-policy-inhibit is set, then the initial value is 0, 2942 otherwise the initial value is n+1. 2944 (f) policy_mapping: an integer which indicates if policy mapping 2945 is permitted. The integer indicates the number of non-self-issued 2946 certificates to be processed before policy mapping is inhibited. 2947 Once set, this variable may be decreased, but may not be 2948 increased. That is, if a certificate in the path specifies policy 2949 mapping is not permitted, it can not be overridden by a later 2950 certificate. If initial-policy-mapping-inhibit is set, then the 2951 initial value is 0, otherwise the initial value is n+1. 2953 (g) working_public_key_algorithm: the digital signature algorithm 2954 used to verify the signature of a certificate. The 2955 working_public_key_algorithm is initialized from the trusted 2956 public key algorithm provided in the trust anchor information. 2958 (h) working_public_key: the public key used to verify the 2959 signature of a certificate. The working_public_key is initialized 2960 from the trusted public key provided in the trust anchor 2961 information. 2963 (i) working_public_key_parameters: parameters associated with the 2964 current public key, that may required to verify a signature 2965 (depending upon the algorithm). The working_public_key_parameters 2966 variable is initialized from the trusted public key parameters 2967 provided in the trust anchor information. 2969 (j) working_issuer_name: the issuer distinguished name expected 2970 in the next certificate in the chain. The working_issuer_name is 2971 initialized to the trusted issuer provided in the trust anchor 2972 information. 2974 (k) max_path_length: this integer is initialized to n, and is 2975 reset by the path length constraint field within the basic 2976 constraints extension of a CA certificate. 2978 Upon completion of the initialization steps, perform the basic 2979 certificate processing steps specified in 6.1.3. 2981 6.1.3 Basic Certificate Processing 2983 The basic path processing actions to be performed for certificate i 2984 are listed below. 2986 (a) Verify the basic certificate information. The certificate 2987 must satisfy each of the following: 2989 (1) The certificate was signed with the 2990 working_public_key_algorithm using the working_public_key and 2991 the working_public_key_parameters. 2993 (2) The certificate validity period includes time T. 2995 (3) At time T, the certificate is not revoked and is not on 2996 hold status. This may be determined by obtaining the 2997 appropriate CRL (see section 6.3), status information, or by 2998 out-of-band mechanisms. 3000 (4) The certificate issuer name is the working_issuer_name. 3002 (5) The certificate issuer unique identifier is the 3003 working_issuer_UID, meaning: 3005 (i) working_issuer_UID is non-null and matches the value in 3006 the issuerUID field, or 3008 (ii) working_issuer_UID is null and the issuerUID field is 3009 not present. 3011 (b) If certificate i is not self-issued, verify that the subject 3012 name is within one of the permitted_subtrees for X.500 3013 distinguished names, and verify that each of the alternative names 3014 in the subjectAltName extension (critical or non-critical) is 3015 within one of the permitted_subtrees for that name type. 3017 (c) If certificate i is not self-issued, verify that the subject 3018 name is not within one of the excluded_subtrees for X.500 3019 distinguished names, and verify that each of the alternative names 3020 in the subjectAltName extension (critical or non-critical) is not 3021 within one of the excluded_subtrees for that name type. 3023 (d) If the certificate policies extension is present in the 3024 certificiate and the valid_policy_tree is not NULL, process the 3025 policy information by performing the following steps in order: 3027 (1) For each policy P not equal to any-policy in the 3028 certificate policies extension, let P-OID denote the OID in 3029 policy P and P-Q denote the qualifier set for policy P. 3030 Perform the following steps in order: 3032 (i) If the valid_policy_tree includes a node of depth i-1 3033 where P-OID is in the expected_policy_set, create a child 3034 node as follows: set the valid_policy to OID- P; set the 3035 qualifier_set to P-Q, and set the expected_policy_set to 3036 {P-OID}. 3038 For example, consider a valid_policy_tree with a node of 3039 depth i-1 where the expected_policy_set is {Gold, White}. 3040 Assume the certificate policies Gold and Silver appear in 3041 the certificate policies extension of certificate i. The 3042 Gold policy is matched but the Silver policy is not. This 3043 rule will generate a child node of depth i for the Gold 3044 policy. The result is shown as Figure 4. 3046 |-----------------| 3047 | Red | 3048 |-----------------| 3049 | {} | 3050 |-----------------| node of depth i-1 3051 | FALSE | 3052 |-----------------| 3053 | {Gold, White} | 3054 |-----------------| 3055 | 3056 | 3057 | 3058 V 3059 |-----------------| 3060 | Gold | 3061 |-----------------| 3062 | {} | 3063 |-----------------| node of depth i 3064 | uninitialized | 3065 |-----------------| 3066 | {Gold} | 3067 |-----------------| 3069 Figure 4. Processing an exact match 3071 (ii) If there was no match in step (i) and the 3072 valid_policy_tree includes a node of depth i-1 with the 3073 valid policy any-policy, generate a child node with the 3074 following values: set the valid_policy to P-OID; set the 3075 qualifier_set to P-Q, and set the expected_policy_set to 3076 {P-OID}. 3078 For example, consider a valid_policy_tree with a node of 3079 depth i-1 where the valid_policy is any-policy. Assume the 3080 certificate policies Gold and Silver appear in the 3081 certificate policies extension of certificate i. The Gold 3082 policy does not have a qualifier, but the Silver policy has 3083 the qualifier Q-Silver. If Gold and Silver were not matched 3084 in (i) above, this rule will generate two child nodes of 3085 depth i, one for each policy. The result is shown as Figure 3086 5. 3088 |-----------------| 3089 | any-policy | 3090 |-----------------| 3091 | {} | 3092 |-----------------| node of depth i-1 3093 | FALSE | 3094 |-----------------| 3095 | {any-policy} | 3096 |-----------------| 3097 / \ 3098 / \ 3099 / \ 3100 / \ 3101 |-----------------| |-----------------| 3102 | Gold | | Silver | 3103 |-----------------| |-----------------| 3104 | {} | | {Q-Silver} | 3105 |-----------------| nodes of |-----------------| 3106 | uninitialized | depth i | uninitialized | 3107 |-----------------| |-----------------| 3108 | {Gold} | | {Silver} | 3109 |-----------------| |-----------------| 3111 Figure 5. Processing unmatched policies when a leaf node 3112 specifies any-policy 3114 (2) If the certificate policies extension includes the policy 3115 any-policy with the qualifier set AP-Q and inhibit_any-policy 3116 is greater than 0, then: 3118 For each node in the valid_policy_tree of depth i-1, for each 3119 value in the expected_policy_set (including any-policy) that 3120 does not appear in a child node, create a child node with the 3121 following values: set the valid_policy to the value from the 3122 expected_policy_set in the parent node; set the qualifier_set 3123 to AP-Q, and set the expected_policy_set to the value in the 3124 valid_policy from this node. 3126 For example, consider a valid_policy_tree with a node of depth 3127 i-1 where the expected_policy_set = {Gold, Silver}. Assume 3128 any-policy appears in the certificate policies extension of 3129 certificate i, but Gold and Silver do not. This rule will 3130 generate two child nodes of depth i, one for each policy. The 3131 result is shown below as Figure 6. 3133 |-----------------| 3134 | Red | 3135 |-----------------| 3136 | {} | 3137 |-----------------| node of depth i-1 3138 | FALSE | 3139 |-----------------| 3140 | {Gold, Silver} | 3141 |-----------------| 3142 / \ 3143 / \ 3144 / \ 3145 / \ 3146 |-----------------| |-----------------| 3147 | Gold | | Silver | 3148 |-----------------| |-----------------| 3149 | {} | | {} | 3150 |-----------------| nodes of |-----------------| 3151 | uninitialized | depth i | uninitialized | 3152 |-----------------| |-----------------| 3153 | {Gold} | | {Silver} | 3154 |-----------------| |-----------------| 3156 Figure 6. Processing unmatched policies when the certificate 3157 policies extension specifies any-policy 3159 (3) If there is a node in the valid_policy_tree of depth i-1 or 3160 less without any child nodes, delete that node. Repeat this 3161 step until there are no nodes of depth i-1 or less without 3162 children. 3164 For example, consider the valid_policy_tree shown in Figure 7 3165 below. The two nodes at depth i-1 that are marked with an to 3166 the resulting tree will cause the node at depth i-2 that is 3167 marked with an 'Y' to be deleted. The following application of 3168 the rule does not cause any nodes to be deleted, and this step 3169 is complete. 3171 +-----------+ 3172 | | node of depth i-3 3173 +-----------+ 3174 / | \ 3175 / | \ 3176 / | \ 3177 +-----------+ +-----------+ +-----------+ 3178 | | | | | Y | nodes of 3179 +-----------+ +-----------+ +-----------+ depth i-2 3180 / \ || || 3181 / \ || || 3182 / \ || || 3183 +-----------+ +-----------+ +-----------+ +-----------+ nodes of 3184 | | | X | | | | X | depth 3185 +-----------+ +-----------+ +-----------+ +-----------+ i-1 3186 | / | \ 3187 | / | \ 3188 | / | \ 3189 +-----------+ +-----------+ +-----------+ +-----------+ nodes of 3190 | | | | | | | | depth 3191 +-----------+ +-----------+ +-----------+ +-----------+ i 3193 Figure 7. Pruning the valid_policy_tree 3195 (4) If the certificate policies extension was marked as 3196 critical, set the criticality_indicator in all nodes of depth i 3197 to TRUE. If the certificate policies extension was not marked 3198 critical, set the criticality_indicator in all nodes of depth i 3199 to FALSE. 3201 (e) If the certificate policies extension is not present, set the 3202 valid_policy_tree to NULL. 3204 (f) verify that either explicit_policy is greater than 0 or the 3205 valid_policy_tree is not equal to NULL; 3207 If any of steps (a), (b), (c), or (f) fails, the procedure 3208 terminates, returning a failure indication and an appropriate reason. 3210 If i is not equal to n, continue by performing the preparatory steps 3211 listed in 6.1.4. If i is equal to n, perform the wrap-up steps 3212 listed in 6.1.5. 3214 6.1.4 Preparation for Certificate i+1 3216 To prepare for processing of certificate i+1, perform the following 3217 steps for certificate i: 3219 (a) If a policy mapping extension is present, verify that the 3220 special value any-policy does not appear as an issuerDomainPolicy 3221 or a subjectDomainPolicy. 3223 (b) If a policy mapping extension is present, then for each 3224 issuerDomainPolicy ID-P in the policy mapping extension: 3226 (1) If the policy_mapping variable is greater than 0, for each 3227 node in the valid_policy_tree of depth i where ID-P is the 3228 valid_policy, set expected_policy_set to the set of 3229 subjectDomainPolicy values that are specified as equivalent to 3230 ID-P by the policy mapping extension. 3232 If no node of depth i in the valid_policy_tree has a 3233 valid_policy of ID-P but there is a node of depth i with a 3234 valid_policy of any-policy, then generate a child node of the 3235 node of depth i-1 that has a valid_policy of any-policy as 3236 follows: 3238 (i) set the valid_policy to ID-P; 3240 (ii) set the qualifier_set to the qualifier set of the 3241 policy any-policy in the certificate policies extension of 3242 certificate i; 3244 (iii) set the criticality_indicator to the criticality of 3245 the certificate policies extension of certificate i; 3247 (iv) and set the expected_policy_set to the set of 3248 subjectDomainPolicy values that are specified as equivalent 3249 to ID-P by the policy mappings extension. 3251 (2) If the policy_mapping variable is equal to 0: 3253 (i) delete each node of depth i in the valid_policy_tree 3254 where ID-P is the valid_policy. 3256 (ii) If there is a node in the valid_policy_tree of depth 3257 i-1 or less without any child nodes, delete that node. 3258 Repeat this step until there are no nodes of depth i-1 or 3259 less without children. 3261 (c) Assign the certificate subject name to working_issuer_name. 3263 (d) Assign the certificate subjectPublicKey to working_public_key. 3265 (e) If the subjectPublicKeyInfo field of the certificate contains 3266 an algorithm field with non-null parameters, assign the parameters 3267 to the working_public_key_parameters variable. 3269 If the subjectPublicKeyInfo field of the certificate contains an 3270 algorithm field with null parameters or parameters are omitted, 3271 compare the certificate subjectPublicKey algorithm to the 3272 working_public_key_algorithm. If the certificate subjectPublicKey 3273 algorithm and the working_public_key_algorithm are different, set 3274 the working_public_key_parameters to null. 3276 (f) Assign the certificate subjectPublicKey algorithm to the 3277 working_public_key_algorithm variable. 3279 (g) If a name constraints extension is included in the 3280 certificate, modify the permitted_subtrees and excluded_subtrees 3281 state variables as follows: 3283 (1) If permittedSubtrees is present in the certificate, set the 3284 permitted_subtrees state variable to the intersection of its 3285 previous value and the value indicated in the extension field. 3286 If permittedSubtrees does not include a particular name type, 3287 the permitted_subtrees state variable is unchanged for that 3288 name type. 3290 (2) If excludedSubtrees is present in the certificate, set the 3291 excluded_subtrees state variable to the union of its previous 3292 value and the value indicated in the extension field. If 3293 excludedSubtrees does not include a particular name type, the 3294 excluded_subtrees state variable is unchanged for that name 3295 type. 3297 (h) If the issuer and subject names are not identical: 3299 (1) If explicit_policy is not 0, decrement explicit_policy by 3300 1. 3302 (2) If policy_mapping is not 0, decrement policy_mapping by 1. 3304 (3) If inhibit_any-policy is not 0, decrement inhibit_any- 3305 policy by 1. 3307 (i) If a policy constraints extension is included in the 3308 certificate, modify the explicit_policy and policy_mapping state 3309 variables as follows: 3311 (1) If requireExplicitPolicy is present and is less than 3312 explicit_policy, set explicit_policy to the value of 3313 requireExplicitPolicy. 3315 (2) If inhibitPolicyMapping is present and is less than 3316 policy_mapping, set policy_mapping to the value of 3317 inhibitPolicyMapping. 3319 (j) If the inhibitAnyPolicy extension is included in the 3320 certificate and is less than inhibit_any-policy, set inhibit_any- 3321 policy to the value of inhibitAnyPolicy. 3323 (k) Verify that the certificate is a CA certificate (as specified 3324 in a basicConstraints extension or as verified out-of-band). 3326 (l) If the certificate was not self-issued, verify that 3327 max_path_length is greater than zero and decrement max_path_length 3328 by 1. 3330 (m) If pathLengthConstraint is present in the certificate and is 3331 less than max_path_length, set max_path_length to the value of 3332 pathLengthConstraint. 3334 (n) If a key usage extension is present and marked critical, 3335 verify that the keyCertSign bit is set. 3337 (o) Recognize and process any other critical extension present in 3338 the certificate. 3340 If check (a), (k), (l), (n) or (o) fails, the procedure terminates, 3341 returning a failure indication and an appropriate reason. 3343 If (a), (k), (l), (n) and (o) have completed successfully, increment 3344 i and perform the basic certificate processing specified in 6.1.2. 3346 6.1.5 Wrap-up procedure 3348 To complete the processing of the end entity certificate, perform the 3349 following steps for certificate n: 3351 (a) If certificate n was not self-issued and explicit_policy is 3352 not 0, decrement explicit_policy by 1. 3354 (b) If a policy constraints extension is included in the 3355 certificate and requireExplicitPolicy is present and has a value 3356 of 0, set the explicit_policy state variable to 0. 3358 (c) Assign the certificate subjectPublicKey to working_public_key. 3360 (d) If the subjectPublicKeyInfo field of the certificate contains 3361 an algorithm field with non-null parameters, assign the parameters 3362 to the working_public_key_parameters variable. 3364 If the subjectPublicKeyInfo field of the certificate contains an 3365 algorithm field with null parameters or parameters are omitted, 3366 compare the certificate subjectPublicKey algorithm to the 3367 working_public_key_algorithm. If the certificate subjectPublicKey 3368 algorithm and the working_public_key_algorithm are different, set 3369 the working_public_key_parameters to null. 3371 (e) Assign the certificate subjectPublicKey algorithm to the 3372 working_public_key_algorithm variable. 3374 (f) Recognize and process any other critical extension present in 3375 the certificate n. 3377 (g) Calculate the intersection of the valid_policy_tree and the 3378 user-initial-policy-set, as follows: 3380 (i) If the valid_policy_tree is NULL, the intersection is NULL. 3382 (ii) If the valid_policy_tree is not NULL and the user- 3383 initial-policy-set is any-policy, the intersection is the 3384 entire valid_policy_tree. 3386 (iii) If the valid_policy_tree is not NULL and the user- 3387 initial-policy-set is not any-policy, calculate the 3388 intersection of the valid_policy_tree and the user-initial- 3389 policy-set as follows: 3391 1. Determine the set of policy nodes whose parent nodes have 3392 a valid_policy of any-policy. This is the 3393 valid_policy_node_set. 3395 2. If the valid_policy of any node in the 3396 valid_policy_node_set is not in the user-initial-policy-set 3397 and is not any-policy, delete this node and all its 3398 children. 3400 3. If there is a node in the valid_policy_tree of depth n-1 3401 or less without any child nodes, delete that node. Repeat 3402 this step until there are no nodes of depth n-1 or less 3403 without children. 3405 Upon completion of all steps, path processing has succeeded if the 3406 value of explicit_policy variable is greater than zero, or the 3407 valid_policy_tree is not NULL. 3409 6.1.6 Outputs 3411 If path processing succeeds, the procedure terminates, returning a 3412 success indication together with final value of the 3413 valid_policy_tree, the working_public_key, the 3414 working_public_key_algorithm, and the working_public_key_parameters. 3416 6.2 Using the Path Validation Algorithm 3418 The path validation algorithm describes the process of validating a 3419 single certification path. While each path begins with a specific 3420 trust anchor, there is no requirement that all paths validated by a 3421 particular system share a single trust anchor. 3423 The selection of one or more trusted CAs is a local decision. A 3424 system may provide any one of its trusted CAs as the trust anchor for 3425 a particular path. The inputs to the path validation algorithm may 3426 be different for each path. The inputs used to process a path may 3427 reflect application-specific requirements or limitations in the trust 3428 accorded a particular trust anchor. For example, a trusted CA may 3429 only be trusted for a particular certificate policy. This 3430 restriction can be expressed through the inputs to the path 3431 validation procedure. 3433 It is also possible to specify an extended version of the above 3434 certification path processing procedure which results in default 3435 behavior identical to the rules of PEM [RFC 1422]. In this extended 3436 version, additional inputs to the procedure are a list of one or more 3437 Policy Certification Authorities (PCAs) names and an indicator of the 3438 position in the certification path where the PCA is expected. At the 3439 nominated PCA position, the CA name is compared against this list. 3440 If a recognized PCA name is found, then a constraint of 3441 SubordinateToCA is implicitly assumed for the remainder of the 3442 certification path and processing continues. If no valid PCA name is 3443 found, and if the certification path cannot be validated on the basis 3444 of identified policies, then the certification path is considered 3445 invalid. 3447 6.3 CRL Validation 3449 This section describes the steps necessary to determine if a 3450 certificate is revoked or on hold status when CRLs are the revocation 3451 mechanism used by the certificate issuer. Conforming implementations 3452 of this specification are not required to implement this algorithm, 3453 but MUST be functionally equivalent to the external behavior 3454 resulting from this procedure. Any algorithm may be used by a 3455 particular implementation so long as it derives the correct result. 3457 This algorithm defines a set of inputs, a set of state variables, and 3458 processing steps that are performed for each certificate in the path. 3460 6.3.1 Revocation Inputs 3462 To support revocation processing, the algorithm requires two inputs: 3464 (a) certificate: the algorithm requires the certificate serial 3465 number and issuer name to determine if a certificate is on a 3466 particular CRL. The basicConstraints extension is used to 3467 determine whether the supplied certificate is associated with a CA 3468 or an end-entity. If present, the algorithm may use the 3469 cRLDistributionsPoint and freshestCRL extensions to determine 3470 revocation status. 3472 (b) use-deltas: This boolean input determines if the delta needs 3473 to be checked if the CRL is still valid. 3475 Note that implementations supporting legacy PKIs, such as RFC 1422 3476 and X.509 version 1, will need an additional input indicating 3477 whether the supplied certificate is associated with a CA or an 3478 end-entity. 3480 6.3.2 Initialization and Revocation State Variables 3482 To support CRL processing, the algorithm requires the following state 3483 variables: 3485 (a) reasons_mask: This variable contains the set of revocation 3486 reasons supported by the CRLs and delta CRLs processed so far. The 3487 legal members of the set are the possible values for reasonflags: 3488 unspecified; keyCompromise; caCompromise; affiliationChanged; 3489 superseded; cessationOfOperation; and certificateHold. The 3490 special value all-reasons is used to denote the set of all legal 3491 members. This variable is initialized to the empty set. 3493 (b) cert_status: This variable contains the status of the 3494 certificate. Legal values are unspecified; keyCompromise; 3495 caCompromise; affiliationChanged; superseded; 3496 cessationOfOperation; and certificateHold, the special value 3497 UNREVOKED, or the special value UNDETERMINED. This variable is 3498 initialized to the special value UNREVOKED. 3500 (c) interim_reasons_mask: This contains the set of revocation 3501 reasons supported by the CRL or delta CRL currently being 3502 processed. 3504 Note: In some environments, it is not necessary to check all reason 3505 codes. For example, some envornments only are concerned with 3506 caCompromise and keyCompromise for CA certificates. This algorithnm 3507 checks all reason codes. Additional processing and state variables 3508 may be necessary to limit the checking to a subset of the reason 3509 codes. 3511 6.3.3 CRL Processing 3513 This algorithm begins by assuming the certificate is not revoked. 3514 The algorithm checks one or more CRLs until either the certificate 3515 status is determined to be revoked or sufficent CRLs have been 3516 checked to cover all reason codes. 3518 For each distribution point (DP) in the crl distribution points 3519 extension while ((reasons_mask is not all-reasons) and (cert_status 3520 is UNREVOKED)) 3522 (1) locate the corresponding CRL in CRL cache, and perform the 3523 following verifications: 3525 (a) compute the interim_reasons_mask for this CRL as follows: 3527 1. if the CRL includes reasons and the DP includes reasons, 3528 then set interim_reasons_mask to the intersection of of 3529 reasons in the DP and reasons in CRL reasons extension. 3531 2. if the CRL includes reasons but the DP omits reasons, 3532 then set interim_reasons_mask to the value of CRL reasons. 3534 3. if the CRL omits reasons but the DP includes reasons, 3535 then set interim_reasons_mask to the value of DP reasons. 3537 4. if the CRL omits reasons and the DP omits reasons, then 3538 set interim_reasons_mask to the special value all-reasons. 3540 Verify that interim_reasons_mask includes one or more reasons 3541 that is not included in the reasons_mask. 3543 (b) Verify the issuer of the CRL as follows: 3545 if the DP includes cRLIssuer, then verify that the CRL 3546 issuer matches cRLIssuer else verify that the CRL issuer 3547 matches the certificate issuer. 3549 (c) obtain and validate the certification path for the CRL 3550 issuer. 3552 (d) validate the signature on the CRL. 3554 (2) If each of the verifications (a) through (d) succeeds, then 3555 perform the following steps: 3557 (a) If the value of next update field is before the current- 3558 time, otain an appropriate delta CRL or discard the CRL. 3560 (b) If the user wants freshest available info AND the freshest 3561 CRL extension is present, check for a corresponding delta for 3562 this base. 3564 (c) If a delta was obtained in (a) or (b), verify that the 3565 delta CRL addresses the same set of certificates and the same 3566 set of reasons as the CRL. 3568 (d) Perform the checks in step 1 (b) and (c): 3570 1. obtain and validate the certification path for the delta 3571 issuer 3573 2. validate the signature on the delta CRL 3575 (e) If a delta CRL was obtained in (a) or (b), and the 3576 verifications (c) and (d) suceeded, combine the base and 3577 delta to form a complete CRL. 3579 (3) If steps and (1) and (2) succeed, then set reasons_mask to the 3580 union of reasons_mask and interim_reasons_mask 3582 (4) Search for the certificate on the CRL 3584 (a) search for the serial number on the CRL 3586 (b) if (a) succeeds, verify that (1) the CRL entry extension 3587 Certificate issuer is not present or (2) the issuer identified 3588 in the CRL entry extension Certificate issuer is the issuer of 3589 the certificate. 3591 (c) if (a) and (b) succeeded, set the cert_status variable as 3592 appropriate: 3594 1. if the reasons extension is present, set the cert_status 3595 variable to the value of the reasons extension 3597 2. if the reasons extension is not present, set the 3598 cert_status variable to the special value not-specified. 3600 if ((reasons_mask is all-reasons) OR (if cert_status is not 3601 UNREVOKED) return cert_status 3603 If all CRLs named in the crl distribution points extension have 3604 been exhausted, and the reasons_mask is not all-reasons and the 3605 cert_status is still UNREVOKED, the verifier must obtain 3606 additional CRLs. If the 3608 The verifier must repeat the process above with the additional 3609 CRLs not specified in a distribution point. 3611 If all CRLs are exhausted and the reasons_mask is not all-reasons 3612 return the cert_status UNDETERMINED. 3614 7 References 3616 [RFC 791] J. Postel, "Internet Protocol", September 1981. 3618 [RFC 822] D. Crocker, "Standard for the format of ARPA Internet text 3619 messages", August 1982. 3621 [RFC 1034] P.V. Mockapetris, "Domain names - concepts and 3622 facilities", November 1987. 3624 [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic 3625 Mail: Part II: Certificate-Based Key Management," RFC 3626 1422, BBN Communications, February 1993. 3628 [RFC 1423] Balenson, D., "Privacy Enhancement for Internet Electronic 3629 Mail: Part III: Algorithms, Modes, and Identifiers," 3630 RFC 1423, Trusted Information Systems, February 1993. 3632 [RFC 1510] Kohl, J., and C. Neuman, "The Kerberos Network 3633 Authentication Service (V5)," RFC 1510, September 1993. 3635 [RFC 1519] V. Fuller, T. Li, J. Yu, and K. Varadhan. "Classless 3636 Inter-Domain Routing (CIDR): an Address Assignment and 3637 Aggregation Strategy", September 1993. 3639 [RFC 1738] Berners-Lee, T., Masinter L., and M. McCahill. 3640 "Uniform Resource Locators (URL)", RFC 1738, December 1994. 3642 [RFC 1778] Howes, T., Kille S., Yeong, W. and C. Robbins. "The 3643 String Representation of Standard Attribute Syntaxes," 3644 RFC 1778, March 1995. 3646 [RFC 1883] S. Deering and R. Hinden. "Internet Protocol, Version 6 3647 (IPv6) Specification", December 1995. 3649 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 3650 Requirement Levels", March 1997. 3652 [RFC 2247] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. 3654 Sataluri. "Using Domains in LDAP/X.500 Distinguished Names", 3655 RFC 2247, January 1998. 3657 [RFC 2277] H. Alvestrand, "IETF Policy on Character Sets and 3658 Languages", January 1998. 3660 [RFC 2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646", 3661 January 1998. 3663 [RFC 2560] Myers, M., Ankney R., Malpani A., Galperin S., and 3664 C. Adams, "Online Certificate Status Protocal - OCSP", 3665 June 1999. 3667 [SDN.701] SDN.701, "Message Security Protocol 4.0", Revision A 3668 1997-02-06. 3670 [X.208] CCITT Recommendation X.208: Specification of Abstract 3671 Syntax Notation One (ASN.1), 1988. 3673 [X.501] ITU-T Recommendation X.501: Information 3674 Technology - Open Systems Interconnection - The 3675 Directory: Models, 1993. 3677 [X.509] ITU-T Recommendation X.509 (1997 E): Information 3678 Technology - Open Systems Interconnection - The 3679 Directory: Authentication Framework, June 1997. 3681 [X.520] ITU-T Recommendation X.520: Information 3682 Technology - Open Systems Interconnection - The 3683 Directory: Selected Attribute Types, 1993. 3685 [X9.55] ANSI X9.55-1995, Public Key Cryptography For The Financial 3686 Services Industry: Extensions To Public Key Certificates 3687 And Certificate Revocation Lists, 8 December, 1995. 3689 [PKINIT] Tung, B., Neuman C., Hur M., Medvinsky A., Medvinsky S., 3690 Wray J., and J. Trostle, "Public Key Cryptography for 3691 Initial Authentciaion in Kerberos," 3692 draft-ietf-cat-kerberos-pk-init-11.txt, March 15, 2000. 3694 [PKIX ALGS] Bassham, L., Housley, R., and W. Polk, "Internet X.509 3695 Public Key Infrastructure Representation of Public Keys 3696 and Digital Signatures," 3697 draft-ietf-pkix-ipki-pkalgs-00.txt, July 14, 2000. 3699 [PKIX TSA] Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 3700 Public Key Infrastructure Time Stamp Protocol," 3701 draft-ietf-pkix-time-stamp-12.txt, November, 2000. 3703 8 Intellectual Property Rights 3705 The IETF has been notified of intellectual property rights claimed in 3706 regard to some or all of the specification contained in this 3707 document. For more information consult the online list of claimed 3708 rights. 3710 The IETF takes no position regarding the validity or scope of any 3711 intellectual property or other rights that might be claimed to 3712 pertain to the implementation or use of the technology described in 3713 this document or the extent to which any license under such rights 3714 might or might not be available; neither does it represent that it 3715 has made any effort to identify any such rights. Information on the 3716 IETF's procedures with respect to rights in standards-track and 3717 standards-related documentation can be found in BCP-11. Copies of 3718 claims of rights made available for publication and any assurances of 3719 licenses to be made available, or the result of an attempt made to 3720 obtain a general license or permission for the use of such 3721 proprietary rights by implementors or users of this specification can 3722 be obtained from the IETF Secretariat. 3724 9 Security Considerations 3726 The majority of this specification is devoted to the format and 3727 content of certificates and CRLs. Since certificates and CRLs are 3728 digitally signed, no additional integrity service is necessary. 3729 Neither certificates nor CRLs need be kept secret, and unrestricted 3730 and anonymous access to certificates and CRLs has no security 3731 implications. 3733 However, security factors outside the scope of this specification 3734 will affect the assurance provided to certificate users. This 3735 section highlights critical issues that should be considered by 3736 implementors, administrators, and users. 3738 The procedures performed by CAs and RAs to validate the binding of 3739 the subject's identity of their public key greatly affect the 3740 assurance that should be placed in the certificate. Relying parties 3741 may wish to review the CA's certificate practice statement. This may 3742 be particularly important when issuing certificates to other CAs. 3744 The use of a single key pair for both signature and other purposes is 3745 strongly discouraged. Use of separate key pairs for signature and key 3746 management provides several benefits to the users. The ramifications 3747 associated with loss or disclosure of a signature key are different 3748 from loss or disclosure of a key management key. Using separate key 3749 pairs permits a balanced and flexible response. Similarly, different 3750 validity periods or key lengths for each key pair may be appropriate 3751 in some application environments. Unfortunately, some legacy 3752 applications (e.g., SSL) use a single key pair for signature and key 3753 management. 3755 The protection afforded private keys is a critical factor in 3756 maintaining security. On a small scale, failure of users to protect 3757 their private keys will permit an attacker to masquerade as them, or 3758 decrypt their personal information. On a larger scale, compromise of 3759 a CA's private signing key may have a catastrophic effect. If an 3760 attacker obtains the private key unnoticed, the attacker may issue 3761 bogus certificates and CRLs. Existence of bogus certificates and 3762 CRLs will undermine confidence in the system. If the compromise is 3763 detected, all certificates issued to the CA shall be revoked, 3764 preventing services between its users and users of other CAs. 3765 Rebuilding after such a compromise will be problematic, so CAs are 3766 advised to implement a combination of strong technical measures 3767 (e.g., tamper-resistant cryptographic modules) and appropriate 3768 management procedures (e.g., separation of duties) to avoid such an 3769 incident. 3771 Loss of a CA's private signing key may also be problematic. The CA 3772 would not be able to produce CRLs or perform normal key rollover. 3773 CAs are advised to maintain secure backup for signing keys. The 3774 security of the key backup procedures is a critical factor in 3775 avoiding key compromise. 3777 The availability and freshness of revocation information will affect 3778 the degree of assurance that should be placed in a certificate. 3779 While certificates expire naturally, events may occur during its 3780 natural lifetime which negate the binding between the subject and 3781 public key. If revocation information is untimely or unavailable, 3782 the assurance associated with the binding is clearly reduced. 3783 Similarly, implementations of the Path Validation mechanism described 3784 in section 6 that omit revocation checking provide less assurance 3785 than those that support it. 3787 The path validation algorithm depends on the certain knowledge of the 3788 public keys (and other information) about one or more trusted CAs. 3789 The decision to trust a CA is an important decision as it ultimately 3790 determines the trust afforded a certificate. The authenticated 3791 distribution of trusted CA public keys (usually in the form of a 3792 "self-signed" certificate) is a security critical out of band process 3793 that is beyond the scope of this specification. 3795 In addition, where a key compromise or CA failure occurs for a 3796 trusted CA, the user will need to modify the information provided to 3797 the path validation routine. Selection of too many trusted CAs will 3798 make the trusted CA information difficult to maintain. On the other 3799 hand, selection of only one trusted CA may limit users to a closed 3800 community of users until a global PKI emerges. 3802 The quality of implementations that process certificates may also 3803 affect the degree of assurance provided. The path validation 3804 algorithm described in section 6 relies upon the integrity of the 3805 trusted CA information, and especially the integrity of the public 3806 keys associated with the trusted CAs. By substituting public keys 3807 for which an attacker has the private key, an attacker could trick 3808 the user into accepting false certificates. 3810 The binding between a key and certificate subject cannot be stronger 3811 than the cryptographic module implementation and algorithms used to 3812 generate the signature. Short key lengths or weak hash algorithms 3813 will limit the utility of a certificate. CAs are encouraged to note 3814 advances in cryptology so they can employ strong cryptographic 3815 techniques. In addition, CAs should decline to issue certificates to 3816 CAs or end entities that generate weak signatures. 3818 Inconsistent application of name comparison rules may result in 3819 acceptance of invalid X.509 certification paths, or rejection of 3820 valid ones. The X.500 series of specifications defines rules for 3821 comparing distinguished names require comparison of strings without 3822 regard to case, character set, multi-character white space substring, 3823 or leading and trailing white space. This specification relaxes 3824 these requirements, requiring support for binary comparison at a 3825 minimum. 3827 CAs shall encode the distinguished name in the subject field of a CA 3828 certificate identically to the distinguished name in the issuer field 3829 in certificates issued by the latter CA. If CAs use different 3830 encodings, implementations of this specification may fail to 3831 recognize name chains for paths that include this certificate. As a 3832 consequence, valid paths could be rejected. 3834 In addition, name constraints for distinguished names shall be stated 3835 identically to the encoding used in the subject field or 3836 subjectAltName extension. If not, (1) name constraints stated as 3837 excludedSubTrees will not match and invalid paths will be accepted 3838 and (2) name constraints expressed as permittedSubtrees will not 3839 match and valid paths will be rejected. To avoid acceptance of 3840 invalid paths, CAs should state name constraints for distinguished 3841 names as permittedSubtrees where ever possible. 3843 Appendix A. Psuedo-ASN.1 Structures and OIDs 3845 This section describes data objects used by conforming PKI components 3846 in an "ASN.1-like" syntax. This syntax is a hybrid of the 1988 and 3847 1993 ASN.1 syntaxes. The 1988 ASN.1 syntax is augmented with 1993 3848 UNIVERSAL Types UniversalString, BMPString and UTF8String. 3850 The ASN.1 syntax does not permit the inclusion of type statements in 3851 the ASN.1 module, and the 1993 ASN.1 standard does not permit use of 3852 the new UNIVERSAL types in modules using the 1988 syntax. As a 3853 result, this module does not conform to either version of the ASN.1 3854 standard. 3856 This appendix may be converted into 1988 ASN.1 by replacing the 3857 defintions for the UNIVERSAL Types with the 1988 catch-all "ANY". 3859 A.1 Explicitly Tagged Module, 1988 Syntax 3861 PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) 3862 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)} 3864 DEFINITIONS EXPLICIT TAGS ::= 3866 BEGIN 3868 -- EXPORTS ALL -- 3870 -- IMPORTS NONE -- 3872 -- UNIVERSAL Types defined in '93 and '98 ASN.1 3873 -- but required by this specification 3875 UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING 3876 -- UniversalString is defined in ASN.1:1993 3878 BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING 3879 -- BMPString is the subtype of UniversalString and models 3880 -- the Basic Multilingual Plane of ISO/IEC/ITU 10646-1 3882 UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 3883 -- The content of this type conforms to RFC 2279. 3885 -- 3886 -- PKIX specific OIDs 3888 id-pkix OBJECT IDENTIFIER ::= 3889 { iso(1) identified-organization(3) dod(6) internet(1) 3890 security(5) mechanisms(5) pkix(7) } 3891 -- PKIX arcs 3893 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 3894 -- arc for private certificate extensions 3895 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 3896 -- arc for policy qualifier types 3897 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 3898 -- arc for extended key purpose OIDS 3899 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 3900 -- arc for access descriptors 3902 -- policyQualifierIds for Internet policy qualifiers 3904 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 3905 -- OID for CPS qualifier 3906 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 3907 -- OID for user notice qualifier 3909 -- access descriptor definitions 3911 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 3912 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 3913 id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 } 3914 id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 } 3916 -- attribute data types -- 3918 Attribute ::= SEQUENCE { 3919 type AttributeType, 3920 values SET OF AttributeValue 3921 -- at least one value is required -- } 3923 AttributeType ::= OBJECT IDENTIFIER 3925 AttributeValue ::= ANY 3927 AttributeTypeAndValue ::= SEQUENCE { 3928 type AttributeType, 3929 value AttributeValue } 3931 -- suggested naming attributes: Definition of the following 3932 -- information object set may be augmented to meet local 3933 -- requirements. Note that deleting members of the set may 3934 -- prevent interoperability with conforming implementations. 3935 -- presented in pairs: the AttributeType followed by the 3936 -- type definition for the corresponding AttributeValue 3937 --Arc for standard naming attributes 3938 id-at OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 4} 3940 -- Attributes of type NameDirectoryString 3941 id-at-name AttributeType ::= {id-at 41} 3942 id-at-surname AttributeType ::= {id-at 4} 3943 id-at-givenName AttributeType ::= {id-at 42} 3944 id-at-initials AttributeType ::= {id-at 43} 3945 id-at-generationQualifier AttributeType ::= {id-at 44} 3947 X520name ::= CHOICE { 3948 teletexString TeletexString (SIZE (1..ub-name)), 3949 printableString PrintableString (SIZE (1..ub-name)), 3950 universalString UniversalString (SIZE (1..ub-name)), 3951 utf8String UTF8String (SIZE (1..ub-name)), 3952 bmpString BMPString (SIZE(1..ub-name)) } 3954 -- 3956 id-at-commonName AttributeType ::= {id-at 3} 3958 X520CommonName ::= CHOICE { 3959 teletexString TeletexString (SIZE (1..ub-common-name)), 3960 printableString PrintableString (SIZE (1..ub-common-name)), 3961 universalString UniversalString (SIZE (1..ub-common-name)), 3962 utf8String UTF8String (SIZE (1..ub-common-name)), 3963 bmpString BMPString (SIZE(1..ub-common-name)) } 3965 -- 3967 id-at-localityName AttributeType ::= {id-at 7} 3969 X520LocalityName ::= CHOICE { 3970 teletexString TeletexString (SIZE (1..ub-locality-name)), 3971 printableString PrintableString (SIZE (1..ub-locality-name)), 3972 universalString UniversalString (SIZE (1..ub-locality-name)), 3973 utf8String UTF8String (SIZE (1..ub-locality-name)), 3974 bmpString BMPString (SIZE(1..ub-locality-name)) } 3976 -- 3978 id-at-stateOrProvinceName AttributeType ::= {id-at 8} 3980 X520StateOrProvinceName ::= CHOICE { 3981 teletexString TeletexString (SIZE (1..ub-state-name)), 3982 printableString PrintableString (SIZE (1..ub-state-name)), 3983 universalString UniversalString (SIZE (1..ub-state-name)), 3984 utf8String UTF8String (SIZE (1..ub-state-name)), 3985 bmpString BMPString (SIZE(1..ub-state-name)) } 3987 -- 3989 id-at-organizationName AttributeType ::= {id-at 10} 3991 X520OrganizationName ::= CHOICE { 3992 teletexString TeletexString (SIZE (1..ub-organization-name)), 3993 printableString PrintableString (SIZE (1..ub-organization-name)), 3994 universalString UniversalString (SIZE (1..ub-organization-name)), 3995 utf8String UTF8String (SIZE (1..ub-organization-name)), 3996 bmpString BMPString (SIZE(1..ub-organization-name)) } 3998 -- 4000 id-at-organizationalUnitName AttributeType ::= {id-at 11} 4002 X520OrganizationalUnitName ::= CHOICE { 4003 teletexString TeletexString (SIZE (1..ub-organizational-unit-name)), 4004 printableString PrintableString 4005 (SIZE (1..ub-organizational-unit-name)), 4006 universalString UniversalString 4007 (SIZE (1..ub-organizational-unit-name)), 4008 utf8String UTF8String (SIZE (1..ub-organizational-unit-name)), 4009 bmpString BMPString (SIZE(1..ub-organizational-unit-name)) } 4011 -- 4013 id-at-title AttributeType ::= {id-at 12} 4015 X520Title ::= CHOICE { 4016 teletexString TeletexString (SIZE (1..ub-title)), 4017 printableString PrintableString (SIZE (1..ub-title)), 4018 universalString UniversalString (SIZE (1..ub-title)), 4019 utf8String UTF8String (SIZE (1..ub-title)), 4020 bmpString BMPString (SIZE(1..ub-title)) } 4022 -- 4024 id-at-dnQualifier AttributeType ::= {id-at 46} 4025 X520dnQualifier ::= PrintableString 4027 id-at-countryName AttributeType ::= {id-at 6} 4028 X520countryName ::= PrintableString (SIZE (2)) -- IS 3166 codes 4030 id-at-serialNumber AttributeType ::= { id-at 5 } 4031 X520SerialNumber PrintableString (SIZE (1..ub-serial-number)) 4032 -- domaincomponent and identifier from RFC 2247 4034 id-domainComponent OBJECT IDENTIFIER := 4035 { 0 9 2342 19200300 100 1 25 } 4037 id-domainComponent AttributeType ::= id-domainComponent 4038 domainComponent ::= IA5String 4040 -- Legacy attributes 4042 pkcs-9 OBJECT IDENTIFIER ::= 4043 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 } 4045 emailAddress AttributeType ::= { pkcs-9 1 } 4047 Pkcs9email ::= IA5String (SIZE (1..ub-emailaddress-length)) 4049 -- naming data types -- 4051 Name ::= CHOICE { -- only one possibility for now -- 4052 rdnSequence RDNSequence } 4054 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 4056 DistinguishedName ::= RDNSequence 4058 RelativeDistinguishedName ::= 4059 SET SIZE (1 .. MAX) OF AttributeTypeAndValue 4061 -- Directory string type -- 4063 DirectoryString ::= CHOICE { 4064 teletexString TeletexString (SIZE (1..MAX)), 4065 printableString PrintableString (SIZE (1..MAX)), 4066 universalString UniversalString (SIZE (1..MAX)), 4067 utf8String UTF8String (SIZE (1..MAX)), 4068 bmpString BMPString (SIZE(1..MAX)) } 4070 -- certificate and CRL specific structures begin here 4072 Certificate ::= SEQUENCE { 4073 tbsCertificate TBSCertificate, 4074 signatureAlgorithm AlgorithmIdentifier, 4075 signature BIT STRING } 4077 TBSCertificate ::= SEQUENCE { 4078 version [0] Version DEFAULT v1, 4079 serialNumber CertificateSerialNumber, 4080 signature AlgorithmIdentifier, 4081 issuer Name, 4082 validity Validity, 4083 subject Name, 4084 subjectPublicKeyInfo SubjectPublicKeyInfo, 4085 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 4086 -- If present, version shall be v2 or v3 4087 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 4088 -- If present, version shall be v2 or v3 4089 extensions [3] Extensions OPTIONAL 4090 -- If present, version shall be v3 -- } 4092 Version ::= INTEGER { v1(0), v2(1), v3(2) } 4094 CertificateSerialNumber ::= INTEGER 4096 Validity ::= SEQUENCE { 4097 notBefore Time, 4098 notAfter Time } 4100 Time ::= CHOICE { 4101 utcTime UTCTime, 4102 generalTime GeneralizedTime } 4104 UniqueIdentifier ::= BIT STRING 4106 SubjectPublicKeyInfo ::= SEQUENCE { 4107 algorithm AlgorithmIdentifier, 4108 subjectPublicKey BIT STRING } 4110 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 4112 Extension ::= SEQUENCE { 4113 extnID OBJECT IDENTIFIER, 4114 critical BOOLEAN DEFAULT FALSE, 4115 extnValue OCTET STRING } 4117 -- CRL structures 4119 CertificateList ::= SEQUENCE { 4120 tbsCertList TBSCertList, 4121 signatureAlgorithm AlgorithmIdentifier, 4122 signature BIT STRING } 4124 TBSCertList ::= SEQUENCE { 4125 version Version OPTIONAL, 4126 -- if present, shall be v2 4127 signature AlgorithmIdentifier, 4128 issuer Name, 4129 thisUpdate Time, 4130 nextUpdate Time OPTIONAL, 4131 revokedCertificates SEQUENCE OF SEQUENCE { 4132 userCertificate CertificateSerialNumber, 4133 revocationDate Time, 4134 crlEntryExtensions Extensions OPTIONAL 4135 -- if present, shall be v2 4136 } OPTIONAL, 4137 crlExtensions [0] Extensions OPTIONAL 4138 -- if present, shall be v2 -- } 4140 -- Version, Time, CertificateSerialNumber, and Extensions were 4141 -- defined earlier for use in the certificate structure 4143 AlgorithmIdentifier ::= SEQUENCE { 4144 algorithm OBJECT IDENTIFIER, 4145 parameters ANY DEFINED BY algorithm OPTIONAL } 4146 -- contains a value of the type 4147 -- registered for use with the 4148 -- algorithm object identifier value 4150 -- x400 address syntax starts here 4151 -- OR Names 4153 ORAddress ::= SEQUENCE { 4154 built-in-standard-attributes BuiltInStandardAttributes, 4155 built-in-domain-defined-attributes 4156 BuiltInDomainDefinedAttributes OPTIONAL, 4157 -- see also teletex-domain-defined-attributes 4158 extension-attributes ExtensionAttributes OPTIONAL } 4159 -- The OR-address is semantically absent from the OR-name if the 4160 -- built-in-standard-attribute sequence is empty and the 4161 -- built-in-domain-defined-attributes and extension-attributes are 4162 -- both omitted. 4164 -- Built-in Standard Attributes 4166 BuiltInStandardAttributes ::= SEQUENCE { 4167 country-name CountryName OPTIONAL, 4168 administration-domain-name AdministrationDomainName OPTIONAL, 4169 network-address [0] NetworkAddress OPTIONAL, 4170 -- see also extended-network-address 4171 terminal-identifier [1] TerminalIdentifier OPTIONAL, 4172 private-domain-name [2] PrivateDomainName OPTIONAL, 4173 organization-name [3] OrganizationName OPTIONAL, 4174 -- see also teletex-organization-name 4175 numeric-user-identifier [4] NumericUserIdentifier OPTIONAL, 4176 personal-name [5] PersonalName OPTIONAL, 4177 -- see also teletex-personal-name 4178 organizational-unit-names [6] OrganizationalUnitNames OPTIONAL 4179 -- see also teletex-organizational-unit-names -- } 4181 CountryName ::= [APPLICATION 1] CHOICE { 4182 x121-dcc-code NumericString 4183 (SIZE (ub-country-name-numeric-length)), 4184 iso-3166-alpha2-code PrintableString 4185 (SIZE (ub-country-name-alpha-length)) } 4187 AdministrationDomainName ::= [APPLICATION 2] CHOICE { 4188 numeric NumericString (SIZE (0..ub-domain-name-length)), 4189 printable PrintableString (SIZE (0..ub-domain-name-length)) } 4191 NetworkAddress ::= X121Address -- see also extended-network-address 4193 X121Address ::= NumericString (SIZE (1..ub-x121-address-length)) 4195 TerminalIdentifier ::= PrintableString (SIZE (1..ub-terminal-id-length)) 4197 PrivateDomainName ::= CHOICE { 4198 numeric NumericString (SIZE (1..ub-domain-name-length)), 4199 printable PrintableString (SIZE (1..ub-domain-name-length)) } 4201 OrganizationName ::= PrintableString 4202 (SIZE (1..ub-organization-name-length)) 4203 -- see also teletex-organization-name 4205 NumericUserIdentifier ::= NumericString 4206 (SIZE (1..ub-numeric-user-id-length)) 4208 PersonalName ::= SET { 4209 surname [0] PrintableString (SIZE (1..ub-surname-length)), 4210 given-name [1] PrintableString 4211 (SIZE (1..ub-given-name-length)) OPTIONAL, 4212 initials [2] PrintableString (SIZE (1..ub-initials-length)) OPTIONAL, 4213 generation-qualifier [3] PrintableString 4214 (SIZE (1..ub-generation-qualifier-length)) OPTIONAL } 4215 -- see also teletex-personal-name 4217 OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units) 4218 OF OrganizationalUnitName 4219 -- see also teletex-organizational-unit-names 4221 OrganizationalUnitName ::= PrintableString (SIZE 4222 (1..ub-organizational-unit-name-length)) 4224 -- Built-in Domain-defined Attributes 4226 BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE 4227 (1..ub-domain-defined-attributes) OF 4228 BuiltInDomainDefinedAttribute 4230 BuiltInDomainDefinedAttribute ::= SEQUENCE { 4231 type PrintableString (SIZE 4232 (1..ub-domain-defined-attribute-type-length)), 4233 value PrintableString (SIZE 4234 (1..ub-domain-defined-attribute-value-length))} 4236 -- Extension Attributes 4238 ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF 4239 ExtensionAttribute 4241 ExtensionAttribute ::= SEQUENCE { 4242 extension-attribute-type [0] INTEGER (0..ub-extension-attributes), 4243 extension-attribute-value [1] 4244 ANY DEFINED BY extension-attribute-type } 4246 -- Extension types and attribute values 4247 -- 4249 common-name INTEGER ::= 1 4251 CommonName ::= PrintableString (SIZE (1..ub-common-name-length)) 4253 teletex-common-name INTEGER ::= 2 4255 TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length)) 4257 teletex-organization-name INTEGER ::= 3 4259 TeletexOrganizationName ::= 4260 TeletexString (SIZE (1..ub-organization-name-length)) 4262 teletex-personal-name INTEGER ::= 4 4264 TeletexPersonalName ::= SET { 4265 surname [0] TeletexString (SIZE (1..ub-surname-length)), 4266 given-name [1] TeletexString 4267 (SIZE (1..ub-given-name-length)) OPTIONAL, 4268 initials [2] TeletexString (SIZE (1..ub-initials-length)) OPTIONAL, 4269 generation-qualifier [3] TeletexString (SIZE 4270 (1..ub-generation-qualifier-length)) OPTIONAL } 4272 teletex-organizational-unit-names INTEGER ::= 5 4274 TeletexOrganizationalUnitNames ::= SEQUENCE SIZE 4275 (1..ub-organizational-units) OF TeletexOrganizationalUnitName 4277 TeletexOrganizationalUnitName ::= TeletexString 4278 (SIZE (1..ub-organizational-unit-name-length)) 4280 pds-name INTEGER ::= 7 4282 PDSName ::= PrintableString (SIZE (1..ub-pds-name-length)) 4284 physical-delivery-country-name INTEGER ::= 8 4286 PhysicalDeliveryCountryName ::= CHOICE { 4287 x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)), 4288 iso-3166-alpha2-code PrintableString 4289 (SIZE (ub-country-name-alpha-length)) } 4291 postal-code INTEGER ::= 9 4293 PostalCode ::= CHOICE { 4294 numeric-code NumericString (SIZE (1..ub-postal-code-length)), 4295 printable-code PrintableString (SIZE (1..ub-postal-code-length)) } 4297 physical-delivery-office-name INTEGER ::= 10 4299 PhysicalDeliveryOfficeName ::= PDSParameter 4301 physical-delivery-office-number INTEGER ::= 11 4303 PhysicalDeliveryOfficeNumber ::= PDSParameter 4305 extension-OR-address-components INTEGER ::= 12 4307 ExtensionORAddressComponents ::= PDSParameter 4309 physical-delivery-personal-name INTEGER ::= 13 4311 PhysicalDeliveryPersonalName ::= PDSParameter 4313 physical-delivery-organization-name INTEGER ::= 14 4315 PhysicalDeliveryOrganizationName ::= PDSParameter 4317 extension-physical-delivery-address-components INTEGER ::= 15 4319 ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter 4320 unformatted-postal-address INTEGER ::= 16 4322 UnformattedPostalAddress ::= SET { 4323 printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) OF 4324 PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL, 4325 teletex-string TeletexString 4326 (SIZE (1..ub-unformatted-address-length)) OPTIONAL } 4328 street-address INTEGER ::= 17 4330 StreetAddress ::= PDSParameter 4332 post-office-box-address INTEGER ::= 18 4334 PostOfficeBoxAddress ::= PDSParameter 4336 poste-restante-address INTEGER ::= 19 4338 PosteRestanteAddress ::= PDSParameter 4340 unique-postal-name INTEGER ::= 20 4342 UniquePostalName ::= PDSParameter 4344 local-postal-attributes INTEGER ::= 21 4346 LocalPostalAttributes ::= PDSParameter 4348 PDSParameter ::= SET { 4349 printable-string PrintableString 4350 (SIZE(1..ub-pds-parameter-length)) OPTIONAL, 4351 teletex-string TeletexString 4352 (SIZE(1..ub-pds-parameter-length)) OPTIONAL } 4354 extended-network-address INTEGER ::= 22 4356 ExtendedNetworkAddress ::= CHOICE { 4357 e163-4-address SEQUENCE { 4358 number [0] NumericString (SIZE (1..ub-e163-4-number-length)), 4359 sub-address [1] NumericString 4360 (SIZE (1..ub-e163-4-sub-address-length)) OPTIONAL }, 4361 psap-address [0] PresentationAddress } 4363 PresentationAddress ::= SEQUENCE { 4364 pSelector [0] EXPLICIT OCTET STRING OPTIONAL, 4365 sSelector [1] EXPLICIT OCTET STRING OPTIONAL, 4366 tSelector [2] EXPLICIT OCTET STRING OPTIONAL, 4367 nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING } 4369 terminal-type INTEGER ::= 23 4371 TerminalType ::= INTEGER { 4372 telex (3), 4373 teletex (4), 4374 g3-facsimile (5), 4375 g4-facsimile (6), 4376 ia5-terminal (7), 4377 videotex (8) } (0..ub-integer-options) 4379 -- Extension Domain-defined Attributes 4381 teletex-domain-defined-attributes INTEGER ::= 6 4383 TeletexDomainDefinedAttributes ::= SEQUENCE SIZE 4384 (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute 4386 TeletexDomainDefinedAttribute ::= SEQUENCE { 4387 type TeletexString 4388 (SIZE (1..ub-domain-defined-attribute-type-length)), 4389 value TeletexString 4390 (SIZE (1..ub-domain-defined-attribute-value-length)) } 4392 -- specifications of Upper Bounds shall be regarded as mandatory 4393 -- from Annex B of ITU-T X.411 Reference Definition of MTS Parameter 4394 -- Upper Bounds 4396 -- Upper Bounds 4397 ub-name INTEGER ::= 32768 4398 ub-common-name INTEGER ::= 64 4399 ub-locality-name INTEGER ::= 128 4400 ub-state-name INTEGER ::= 128 4401 ub-organization-name INTEGER ::= 64 4402 ub-organizational-unit-name INTEGER ::= 64 4403 ub-title INTEGER ::= 64 4404 ub-serialNumber INTEGER ::= 64 4405 ub-match INTEGER ::= 128 4407 ub-emailaddress-length INTEGER ::= 128 4409 ub-common-name-length INTEGER ::= 64 4410 ub-country-name-alpha-length INTEGER ::= 2 4411 ub-country-name-numeric-length INTEGER ::= 3 4412 ub-domain-defined-attributes INTEGER ::= 4 4413 ub-domain-defined-attribute-type-length INTEGER ::= 8 4414 ub-domain-defined-attribute-value-length INTEGER ::= 128 4415 ub-domain-name-length INTEGER ::= 16 4416 ub-extension-attributes INTEGER ::= 256 4417 ub-e163-4-number-length INTEGER ::= 15 4418 ub-e163-4-sub-address-length INTEGER ::= 40 4419 ub-generation-qualifier-length INTEGER ::= 3 4420 ub-given-name-length INTEGER ::= 16 4421 ub-initials-length INTEGER ::= 5 4422 ub-integer-options INTEGER ::= 256 4423 ub-numeric-user-id-length INTEGER ::= 32 4424 ub-organization-name-length INTEGER ::= 64 4425 ub-organizational-unit-name-length INTEGER ::= 32 4426 ub-organizational-units INTEGER ::= 4 4427 ub-pds-name-length INTEGER ::= 16 4428 ub-pds-parameter-length INTEGER ::= 30 4429 ub-pds-physical-address-lines INTEGER ::= 6 4430 ub-postal-code-length INTEGER ::= 16 4431 ub-surname-length INTEGER ::= 40 4432 ub-terminal-id-length INTEGER ::= 24 4433 ub-unformatted-address-length INTEGER ::= 180 4434 ub-x121-address-length INTEGER ::= 16 4436 -- Note - upper bounds on string types, such as TeletexString, are 4437 -- measured in characters. Excepting PrintableString or IA5String, a 4438 -- significantly greater number of octets will be required to hold 4439 -- such a value. As a minimum, 16 octets, or twice the specified upper 4440 -- bound, whichever is the larger, should be allowed for TeletexString. 4441 -- For UTF8String or UniversalString at least four times the upper 4442 -- bound should be allowed. 4444 END 4445 A.2 Implicitly Tagged Module, 1988 Syntax 4447 PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) 4448 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)} 4450 DEFINITIONS IMPLICIT TAGS ::= 4452 BEGIN 4454 -- EXPORTS ALL -- 4456 IMPORTS 4457 id-pkix, id-pe, id-qt, id-kp, id-qt-unotice, id-qt-cps, 4458 id-ad, id-ad-ocsp, id-ad-caIssuers, 4459 -- delete following line if "new" types are supported -- 4460 BMPString, UniversalString, UTF8String, -- end "new" types 4461 ORAddress, Name, RelativeDistinguishedName, 4462 CertificateSerialNumber, 4463 CertificateList, AlgorithmIdentifier, ub-name, 4464 Attribute, DirectoryString 4465 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 4466 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 4467 id-mod(0) id-pkix1-explicit(1)}; 4469 -- ISO arc for standard certificate and CRL extensions 4471 id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 4473 -- authority key identifier OID and syntax 4475 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 4477 AuthorityKeyIdentifier ::= SEQUENCE { 4478 keyIdentifier [0] KeyIdentifier OPTIONAL, 4479 authorityCertIssuer [1] GeneralNames OPTIONAL, 4480 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 4481 -- authorityCertIssuer and authorityCertSerialNumber shall both 4482 -- be present or both be absent 4484 KeyIdentifier ::= OCTET STRING 4486 -- subject key identifier OID and syntax 4488 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 4490 SubjectKeyIdentifier ::= KeyIdentifier 4491 -- key usage extension OID and syntax 4493 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 4495 KeyUsage ::= BIT STRING { 4496 digitalSignature (0), 4497 nonRepudiation (1), 4498 keyEncipherment (2), 4499 dataEncipherment (3), 4500 keyAgreement (4), 4501 keyCertSign (5), 4502 cRLSign (6), 4503 encipherOnly (7), 4504 decipherOnly (8) } 4506 -- private key usage period extension OID and syntax 4508 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 4510 PrivateKeyUsagePeriod ::= SEQUENCE { 4511 notBefore [0] GeneralizedTime OPTIONAL, 4512 notAfter [1] GeneralizedTime OPTIONAL } 4513 -- either notBefore or notAfter shall be present 4515 -- certificate policies extension OID and syntax 4517 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 4519 anyPolicy OBJECT IDENTIFIER ::= {id-ce-certificate-policies 0} 4521 CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 4523 PolicyInformation ::= SEQUENCE { 4524 policyIdentifier CertPolicyId, 4525 policyQualifiers SEQUENCE SIZE (1..MAX) OF 4526 PolicyQualifierInfo OPTIONAL } 4528 CertPolicyId ::= OBJECT IDENTIFIER 4530 PolicyQualifierInfo ::= SEQUENCE { 4531 policyQualifierId PolicyQualifierId, 4532 qualifier ANY DEFINED BY policyQualifierId } 4534 -- Implementations that recognize additional policy qualifiers shall 4535 -- augment the following definition for PolicyQualifierId 4537 PolicyQualifierId ::= 4538 OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) 4540 -- CPS pointer qualifier 4542 CPSuri ::= IA5String 4544 -- user notice qualifier 4546 UserNotice ::= SEQUENCE { 4547 noticeRef NoticeReference OPTIONAL, 4548 explicitText DisplayText OPTIONAL} 4550 NoticeReference ::= SEQUENCE { 4551 organization DisplayText, 4552 noticeNumbers SEQUENCE OF INTEGER } 4554 DisplayText ::= CHOICE { 4555 ia5String IA5String (SIZE (1..200)), 4556 visibleString VisibleString (SIZE (1..200)), 4557 bmpString BMPString (SIZE (1..200)), 4558 utf8String UTF8String (SIZE (1..200)) } 4560 -- policy mapping extension OID and syntax 4562 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 4564 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 4565 issuerDomainPolicy CertPolicyId, 4566 subjectDomainPolicy CertPolicyId } 4568 -- subject alternative name extension OID and syntax 4570 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 4572 SubjectAltName ::= GeneralNames 4574 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 4576 GeneralName ::= CHOICE { 4577 otherName [0] AnotherName, 4578 rfc822Name [1] IA5String, 4579 dNSName [2] IA5String, 4580 x400Address [3] ORAddress, 4581 directoryName [4] Name, 4582 ediPartyName [5] EDIPartyName, 4583 uniformResourceIdentifier [6] IA5String, 4584 iPAddress [7] OCTET STRING, 4585 registeredID [8] OBJECT IDENTIFIER } 4587 -- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as 4588 -- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax 4590 AnotherName ::= SEQUENCE { 4591 type-id OBJECT IDENTIFIER, 4592 value [0] EXPLICIT ANY DEFINED BY type-id } 4594 EDIPartyName ::= SEQUENCE { 4595 nameAssigner [0] DirectoryString OPTIONAL, 4596 partyName [1] DirectoryString } 4598 -- issuer alternative name extension OID and syntax 4600 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 4602 IssuerAltName ::= GeneralNames 4604 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 4606 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 4608 -- basic constraints extension OID and syntax 4610 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 4612 BasicConstraints ::= SEQUENCE { 4613 cA BOOLEAN DEFAULT FALSE, 4614 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 4616 -- name constraints extension OID and syntax 4618 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 4620 NameConstraints ::= SEQUENCE { 4621 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 4622 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 4624 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 4626 GeneralSubtree ::= SEQUENCE { 4627 base GeneralName, 4628 minimum [0] BaseDistance DEFAULT 0, 4629 maximum [1] BaseDistance OPTIONAL } 4631 BaseDistance ::= INTEGER (0..MAX) 4633 -- policy constraints extension OID and syntax 4635 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } 4636 PolicyConstraints ::= SEQUENCE { 4637 requireExplicitPolicy [0] SkipCerts OPTIONAL, 4638 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 4640 SkipCerts ::= INTEGER (0..MAX) 4642 -- CRL distribution points extension OID and syntax 4644 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31} 4646 CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 4648 DistributionPoint ::= SEQUENCE { 4649 distributionPoint [0] DistributionPointName OPTIONAL, 4650 reasons [1] ReasonFlags OPTIONAL, 4651 cRLIssuer [2] GeneralNames OPTIONAL } 4653 DistributionPointName ::= CHOICE { 4654 fullName [0] GeneralNames, 4655 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 4657 ReasonFlags ::= BIT STRING { 4658 unused (0), 4659 keyCompromise (1), 4660 cACompromise (2), 4661 affiliationChanged (3), 4662 superseded (4), 4663 cessationOfOperation (5), 4664 certificateHold (6) } 4666 -- extended key usage extension OID and syntax 4668 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 4670 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 4672 KeyPurposeId ::= OBJECT IDENTIFIER 4674 -- extended key purpose OIDs 4675 id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } 4676 id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } 4677 id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } 4678 id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } 4679 id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 } 4680 id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 } 4681 id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 } 4682 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 4683 -- inhibit any policy OID and syntax 4685 id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 } 4687 InhibitAnyPolicy ::= SkipCerts 4689 -- freshest (delta-)CRL extension OID and syntax 4691 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } 4693 FreshestCRL ::= CRLDistributionPoints 4695 -- authority info access 4697 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 4699 AuthorityInfoAccessSyntax ::= 4700 SEQUENCE SIZE (1..MAX) OF AccessDescription 4702 AccessDescription ::= SEQUENCE { 4703 accessMethod OBJECT IDENTIFIER, 4704 accessLocation GeneralName } 4706 -- CRL number extension OID and syntax 4708 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 4710 CRLNumber ::= INTEGER (0..MAX) 4712 -- issuing distribution point extension OID and syntax 4714 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 4716 IssuingDistributionPoint ::= SEQUENCE { 4717 distributionPoint [0] DistributionPointName OPTIONAL, 4718 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 4719 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 4720 onlySomeReasons [3] ReasonFlags OPTIONAL, 4721 indirectCRL [4] BOOLEAN DEFAULT FALSE } 4723 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 4725 -- deltaCRLIndicator ::= BaseCRLNumber 4727 BaseCRLNumber ::= CRLNumber 4729 -- CRL reasons extension OID and syntax 4730 id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 } 4732 CRLReason ::= ENUMERATED { 4733 unspecified (0), 4734 keyCompromise (1), 4735 cACompromise (2), 4736 affiliationChanged (3), 4737 superseded (4), 4738 cessationOfOperation (5), 4739 certificateHold (6), 4740 removeFromCRL (8) } 4742 -- certificate issuer CRL entry extension OID and syntax 4744 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } 4746 CertificateIssuer ::= GeneralNames 4748 -- hold instruction extension OID and syntax 4750 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 4752 HoldInstructionCode ::= OBJECT IDENTIFIER 4754 -- ANSI x9 holdinstructions 4756 -- ANSI x9 arc holdinstruction arc 4757 holdInstruction OBJECT IDENTIFIER ::= 4758 {joint-iso-itu-t(2) member-body(2) us(840) x9cm(10040) 2} 4760 -- ANSI X9 holdinstructions referenced by this standard 4761 id-holdinstruction-none OBJECT IDENTIFIER ::= 4762 {holdInstruction 1} -- deprecated 4763 id-holdinstruction-callissuer OBJECT IDENTIFIER ::= 4764 {holdInstruction 2} 4765 id-holdinstruction-reject OBJECT IDENTIFIER ::= 4766 {holdInstruction 3} 4768 -- invalidity date CRL entry extension OID and syntax 4770 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 4772 InvalidityDate ::= GeneralizedTime 4774 END 4775 Appendix B. ASN.1 Notes 4777 CAs MUST force the serialNumber to be a non-negative integer, that 4778 is, the sign bit in the DER encoding of the INTEGER value MUST be 4779 zero - this can be done by adding a leading (leftmost) `00'H octet if 4780 necessary. This removes a potential ambiguity in mapping between a 4781 string of octets and an integer value. 4783 As noted in section 4.1.2.2, serial numbers can be expected to 4784 contain long integers. Certificate users MUST be able to handle 4785 serialNumber values up to 20 octets in length. Conformant CAs MUST 4786 NOT use serialNumber values longer than 20 octets. 4788 The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 4789 constructs. A valid ASN.1 sequence will have zero or more entries. 4790 The SIZE (1..MAX) construct constrains the sequence to have at least 4791 one entry. MAX indicates the upper bound is unspecified. 4792 Implementations are free to choose an upper bound that suits their 4793 environment. 4795 The construct "positiveInt ::= INTEGER (0..MAX)" defines positiveInt 4796 as a subtype of INTEGER containing integers greater than or equal to 4797 zero. The upper bound is unspecified. Implementations are free to 4798 select an upper bound that suits their environment. 4800 The character string type PrintableString supports a very basic Latin 4801 character set: the lower case letters 'a' through 'z', upper case 4802 letters 'A' through 'Z', the digits '0' through '9', eleven special 4803 characters ' " ( ) + , - . / : ? and space. 4805 The character string type TeletexString is a superset of 4806 PrintableString. TeletexString supports a fairly standard (ascii- 4807 like) Latin character set, Latin characters with non-spacing accents 4808 and Japanese characters. 4810 The character string type UniversalString supports any of the 4811 characters allowed by ISO 10646-1. ISO 10646 is the Universal 4812 multiple-octet coded Character Set (UCS). ISO 10646-1 specifes the 4813 architecture and the "basic multilingual plane" - a large standard 4814 character set which includes all major world character standards. 4816 The character string type UTF8String will be introduced in the 1998 4817 version of ASN.1. UTF8String is a universal type and has been 4818 assigned tag number 12. The content of UTF8String was defined by RFC 4819 2044 and updated in RFC 2279, "UTF-8, a transformation Format of ISO 4820 10646." ISO is expected to formally add UTF8String to the list of 4821 choices for DirectoryString in 1998 as well. 4823 In anticipation of these changes, and in conformance with IETF Best 4824 Practices codified in RFC 2277, IETF Policy on Character Sets and 4825 Languages, this document includes UTF8String as a choice in 4826 DirectoryString and the CPS qualifier extensions. 4828 Implementers should note that the DER encoding of the SET OF values 4829 requires ordering of the encodings of the values. In particular, this 4830 issue arises with respect to distinguished names. 4832 Object Identifiers (OIDs) are used throught this specification to 4833 identify certificate policies, public key and signature algorithms, 4834 certificate extensions, etc. There is no maximum size for OIDs. 4835 This specification mandates support for OIDs which have arc elements 4836 with values that are less than 2^28, i.e. they MUST be between 0 and 4837 268,435,455 inclusive. This allows each arc element to be represented 4838 within a single 32 bit word. Implementations MUST also support OIDs 4839 where the length of the dotted decimal (see [LDAP], section 4.1.2) 4840 string representation can be up to 100 bytes (inclusive). 4841 Implementations MUST be able to handle OIDs with up to 20 elements 4842 (inclusive). CAs SHOULD NOT issue certificates which contain OIDs 4843 that breach these requirements. 4845 Appendix C. Examples 4847 This section contains four examples: three certificates and a CRL. 4848 The first two certificates and the CRL comprise a minimal 4849 certification path. 4851 Section C.1 contains an annotated hex dump of a "self-signed" 4852 certificate issued by a CA whose distinguished name is 4853 cn=us,o=gov,ou=nist. The certificate contains a DSA public key with 4854 parameters, and is signed by the corresponding DSA private key. 4856 Section C.2 contains an annotated hex dump of an end-entity 4857 certificate. The end entity certificate contains a DSA public key, 4858 and is signed by the private key corresponding to the "self-signed" 4859 certificate in section C.1. 4861 Section C.3 contains a dump of an end entity certificate which 4862 contains an RSA public key and is signed with RSA and MD5. This 4863 certificate is not part of the minimal certification path. 4865 Section C.4 contains an annotated hex dump of a CRL. The CRL is 4866 issued by the CA whose distinguished name is cn=us,o=gov,ou=nist and 4867 the list of revoked certificates includes the end entity certificate 4868 presented in C.2. 4870 The certificates were processed using Peter Gutman's dumpasn1 utility 4871 to generate the output. The source for the dumpasn1 utility is 4872 available at . The 4873 binaries for the certificates and CRLs are available at 4874 . 4876 C.1 Certificate 4878 This section contains an annotated hex dump of a 699 byte version 3 4879 certificate. The certificate contains the following information: 4880 (a) the serial number is 23 (17 hex); 4881 (b) the certificate is signed with DSA and the SHA-1 hash algorithm; 4882 (c) the issuer's distinguished name is OU=NIST; O=gov; C=US 4883 (d) and the subject's distinguished name is OU=NIST; O=gov; C=US 4884 (e) the certificate was issued on June 30, 1997 and will expire on 4885 December 31, 1997; 4886 (f) the certificate contains a 1024 bit DSA public key with 4887 parameters; 4888 (g) the certificate contains a subject key identifier extension; and 4889 (h) the certificate is a CA certificate (as indicated through the 4890 basic constraints extension.) 4892 0 30 701: SEQUENCE { 4893 4 30 637: SEQUENCE { 4894 8 A0 3: [0] { 4895 10 02 1: INTEGER 2 4896 : } 4897 13 02 1: INTEGER 23 4898 16 30 9: SEQUENCE { 4899 18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 4900 : } 4901 27 30 42: SEQUENCE { 4902 29 31 11: SET { 4903 31 30 9: SEQUENCE { 4904 33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 4905 38 13 2: PrintableString 'US' 4906 : } 4907 : } 4908 42 31 12: SET { 4909 44 30 10: SEQUENCE { 4910 46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 4911 51 13 3: PrintableString 'gov' 4912 : } 4913 : } 4914 56 31 13: SET { 4915 58 30 11: SEQUENCE { 4916 60 06 3: OBJECT IDENTIFIER 4917 organizationalUnitName (2 5 4 11) 4919 65 13 4: PrintableString 'NIST' 4920 : } 4921 : } 4922 : } 4923 71 30 30: SEQUENCE { 4924 73 17 13: UTCTime '970630000000Z' 4925 88 17 13: UTCTime '971231000000Z' 4926 : } 4927 103 30 42: SEQUENCE { 4928 105 31 11: SET { 4929 107 30 9: SEQUENCE { 4930 109 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 4931 114 13 2: PrintableString 'US' 4932 : } 4933 : } 4934 118 31 12: SET { 4935 120 30 10: SEQUENCE { 4936 122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 4937 127 13 3: PrintableString 'gov' 4938 : } 4939 : } 4940 132 31 13: SET { 4941 134 30 11: SEQUENCE { 4942 136 06 3: OBJECT IDENTIFIER 4943 organizationalUnitName (2 5 4 11) 4944 141 13 4: PrintableString 'NIST' 4945 : } 4946 : } 4947 : } 4948 147 30 440: SEQUENCE { 4949 151 30 300: SEQUENCE { 4950 155 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) 4951 164 30 287: SEQUENCE { 4952 168 02 129: INTEGER 4953 : 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC FB 95 4954 : 32 AC 01 12 33 B9 E0 1C AD 90 9B BC 48 54 9E F3 4955 : 94 77 3C 2C 71 35 55 E6 FE 4F 22 CB D5 D8 3E 89 4956 : 93 33 4D FC BD 4F 41 64 3E A2 98 70 EC 31 B4 50 4957 : DE EB F1 98 28 0A C9 3E 44 B3 FD 22 97 96 83 D0 4958 : 18 A3 E3 BD 35 5B FF EE A3 21 72 6A 7B 96 DA B9 4959 : 3F 1E 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A 4960 : FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48 63 FE 4961 : 43 4962 300 02 21: INTEGER 4963 : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA 55 F7 4964 : 7D 57 74 81 E5 4965 323 02 129: INTEGER 4966 : 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91 C0 8E 4967 : 47 F1 0A C3 01 47 C2 44 42 36 A9 92 81 DE 57 C5 4968 : E0 68 86 58 00 7B 1F F9 9B 77 A1 C5 10 A5 80 91 4969 : 78 51 51 3C F6 FC FC CC 46 C6 81 78 92 84 3D F4 4970 : 93 3D 0C 38 7E 1A 5B 99 4E AB 14 64 F6 0C 21 22 4971 : 4E 28 08 9C 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 4972 : 39 A2 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF 4973 : F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE 1E 57 4974 : 18 4975 : } 4976 : } 4977 455 03 133: BIT STRING 0 unused bits 4978 : 02 81 81 00 B5 9E 1F 49 04 47 D1 DB F5 3A DD CA 4979 : 04 75 E8 DD 75 F6 9B 8A B1 97 D6 59 69 82 D3 03 4980 : 4D FD 3B 36 5F 4A F2 D1 4E C1 07 F5 D1 2A D3 78 4981 : 77 63 56 EA 96 61 4D 42 0B 7A 1D FB AB 91 A4 CE 4982 : DE EF 77 C8 E5 EF 20 AE A6 28 48 AF BE 69 C3 6A 4983 : A5 30 F2 C2 B9 D9 82 2B 7D D9 C4 84 1F DE 0D E8 4984 : 54 D7 1B 99 2E B3 D0 88 F6 D6 63 9B A7 E2 0E 82 4985 : D4 3B 8A 68 1B 06 56 31 59 0B 49 EB 99 A5 D5 81 4986 : 41 7B C9 55 4987 : } 4988 591 A3 52: [3] { 4989 593 30 50: SEQUENCE { 4990 595 30 31: SEQUENCE { 4991 597 06 3: OBJECT IDENTIFIER 4992 subjectKeyIdentifier (2 5 29 14) 4993 602 04 24: OCTET STRING 4994 : 04 16 04 14 E7 26 C5 54 CD 5B A3 6F 35 68 95 AA 4995 : D5 FF 1C 21 E4 22 75 D6 4996 : } 4997 628 30 15: SEQUENCE { 4998 630 06 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19) 4999 635 01 1: BOOLEAN TRUE 5000 638 04 5: OCTET STRING 5001 : 30 03 01 01 FF 5002 : } 5003 : } 5004 : } 5005 : } 5006 645 30 9: SEQUENCE { 5007 647 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5008 : } 5009 656 03 47: BIT STRING 0 unused bits 5010 : 30 2C 02 14 6A F9 3F 72 30 7F 45 DC E5 50 C1 5E 5011 : 94 A0 6D C7 92 4C E5 E1 02 14 6F 61 B8 65 F7 AA 5012 : DF 46 1B F7 39 0D 0D 88 9E FE B6 83 F7 1A 5013 : } 5015 C.2 Certificate 5017 This section contains an annotated hex dump of a 730 byte version 3 5018 certificate. The certificate contains the following information: 5019 (a) the serial number is 18 (12 hex); 5020 (b) the certificate is signed with DSA and the SHA-1 hash algorithm; 5021 (c) the issuer's distinguished name is OU=nist; O=gov; C=US 5022 (d) and the subject's distinguished name is CN=Tim Polk; OU=nist; 5023 O=gov; C=US 5024 (e) the certificate was valid from July 30, 1997 through December 1, 5025 1997; 5026 (f) the certificate contains a 1024 bit DSA public key; 5027 (g) the certificate is an end entity certificate, as the basic 5028 constraints extension is not present; 5029 (h) the certificate contains an authority key identifier extension; 5030 and 5031 (i) the certificate includes one alternative name - an RFC 822 5032 address. 5034 0 30 734: SEQUENCE { 5035 4 30 669: SEQUENCE { 5036 8 A0 3: [0] { 5037 10 02 1: INTEGER 2 5038 : } 5039 13 02 1: INTEGER 18 5040 16 30 9: SEQUENCE { 5041 18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5042 : } 5043 27 30 42: SEQUENCE { 5044 29 31 11: SET { 5045 31 30 9: SEQUENCE { 5046 33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5047 38 13 2: PrintableString 'US' 5048 : } 5049 : } 5050 42 31 12: SET { 5051 44 30 10: SEQUENCE { 5052 46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5053 51 13 3: PrintableString 'gov' 5054 : } 5055 : } 5056 56 31 13: SET { 5057 58 30 11: SEQUENCE { 5058 60 06 3: OBJECT IDENTIFIER 5059 organizationalUnitName (2 5 4 11) 5060 65 13 4: PrintableString 'NIST' 5061 : } 5062 : } 5063 : } 5064 71 30 30: SEQUENCE { 5065 73 17 13: UTCTime '970730000000Z' 5066 88 17 13: UTCTime '971201000000Z' 5067 : } 5068 103 30 61: SEQUENCE { 5069 105 31 11: SET { 5070 107 30 9: SEQUENCE { 5071 109 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5072 114 13 2: PrintableString 'US' 5073 : } 5074 : } 5075 118 31 12: SET { 5076 120 30 10: SEQUENCE { 5077 122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5078 127 13 3: PrintableString 'gov' 5079 : } 5080 : } 5081 132 31 13: SET { 5082 134 30 11: SEQUENCE { 5083 136 06 3: OBJECT IDENTIFIER 5084 organizationalUnitName (2 5 4 11) 5085 141 13 4: PrintableString 'NIST' 5086 : } 5087 : } 5088 147 31 17: SET { 5089 149 30 15: SEQUENCE { 5090 151 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 5091 156 13 8: PrintableString 'Tim Polk' 5092 : } 5093 : } 5094 : } 5095 166 30 439: SEQUENCE { 5096 170 30 300: SEQUENCE { 5097 174 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) 5098 183 30 287: SEQUENCE { 5099 187 02 129: INTEGER 5100 : 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC FB 95 5101 : 32 AC 01 12 33 B9 E0 1C AD 90 9B BC 48 54 9E F3 5102 : 94 77 3C 2C 71 35 55 E6 FE 4F 22 CB D5 D8 3E 89 5103 : 93 33 4D FC BD 4F 41 64 3E A2 98 70 EC 31 B4 50 5104 : DE EB F1 98 28 0A C9 3E 44 B3 FD 22 97 96 83 D0 5105 : 18 A3 E3 BD 35 5B FF EE A3 21 72 6A 7B 96 DA B9 5106 : 3F 1E 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A 5107 : FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48 63 FE 5108 : 43 5109 319 02 21: INTEGER 5110 : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA 55 F7 5111 : 7D 57 74 81 E5 5112 342 02 129: INTEGER 5113 : 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91 C0 8E 5114 : 47 F1 0A C3 01 47 C2 44 42 36 A9 92 81 DE 57 C5 5115 : E0 68 86 58 00 7B 1F F9 9B 77 A1 C5 10 A5 80 91 5116 : 78 51 51 3C F6 FC FC CC 46 C6 81 78 92 84 3D F4 5117 : 93 3D 0C 38 7E 1A 5B 99 4E AB 14 64 F6 0C 21 22 5118 : 4E 28 08 9C 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 5119 : 39 A2 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF 5120 : F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE 1E 57 5121 : 18 5122 : } 5123 : } 5124 474 03 132: BIT STRING 0 unused bits 5125 : 02 81 80 30 B6 75 F7 7C 20 31 AE 38 BB 7E 0D 2B 5126 : AB A0 9C 4B DF 20 D5 24 13 3C CD 98 E5 5F 6C B7 5127 : C1 BA 4A BA A9 95 80 53 F0 0D 72 DC 33 37 F4 01 5128 : 0B F5 04 1F 9D 2E 1F 62 D8 84 3A 9B 25 09 5A 2D 5129 : C8 46 8E 2B D4 F5 0D 3B C7 2D C6 6C B9 98 C1 25 5130 : 3A 44 4E 8E CA 95 61 35 7C CE 15 31 5C 23 13 1E 5131 : A2 05 D1 7A 24 1C CB D3 72 09 90 FF 9B 9D 28 C0 5132 : A1 0A EC 46 9F 0D B8 D0 DC D0 18 A6 2B 5E F9 8F 5133 : B5 95 BE 5134 : } 5135 609 A3 66: [3] { 5136 611 30 64: SEQUENCE { 5137 613 30 25: SEQUENCE { 5138 615 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 5139 620 04 18: OCTET STRING 5140 : 30 10 81 0E 77 70 6F 6C 6B 40 6E 69 73 74 2E 67 5141 : 6F 76 5142 : } 5143 640 30 35: SEQUENCE { 5144 642 06 3: OBJECT IDENTIFIER 5145 authorityKeyIdentifier (2 5 29 35) 5146 647 04 28: OCTET STRING 5147 : 30 1A 80 18 04 16 04 14 E7 26 C5 54 CD 5B A3 6F 5148 : 35 68 95 AA D5 FF 1C 21 E4 22 75 D6 5149 : } 5150 : } 5151 : } 5152 : } 5153 677 30 9: SEQUENCE { 5154 679 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5155 : } 5156 688 03 48: BIT STRING 0 unused bits 5157 : 30 2D 02 14 37 FC 44 BF 7F 8D 18 1F 40 04 2F CF 5158 : EA CC 22 B2 16 01 FF 13 02 15 00 97 D0 24 96 0F 5159 : 64 8A C3 8D 41 B2 0E B9 26 D5 31 D1 A0 F1 BC 5160 : } 5162 C.3 End-Entity Certificate Using RSA 5164 This section contains an annotated hex dump of a 675 byte version 3 5165 certificate. The certificate contains the following information: 5166 (a) the serial number is 256; 5167 (b) the certificate is signed with RSA and the MD2 hash algorithm; 5168 (c) the issuer's distinguished name is OU=Dept. Arquitectura de 5169 Computadors; O=Universitat Politecnica de Catalunya; C=ES 5170 (d) and the subject's distinguished name is CN=Francisco Jordan; 5171 OU=Dept. Arquitectura de Computadors; O=Universitat Politecnica de 5172 Catalunya; C=ES 5173 (e) the certificate was issued on May 21, 1996 and expired on May 21, 5174 1997; 5175 (f) the certificate contains a 768 bit RSA public key; 5176 (g) the certificate is an end entity certificate (not a CA 5177 certificate); 5178 (h) the certificate includes an alternative subject name and an 5179 alternative issuer name - bothe are URLs; 5180 (i) the certificate include an authority key identifier and 5181 certificate policies extensions; and 5182 (j) the certificate includes a critical key usage extension 5183 specifying the public is intended for generation of digital 5184 signatures. 5186 0 30 654: SEQUENCE { 5187 4 30 503: SEQUENCE { 5188 8 A0 3: [0] { 5189 10 02 1: INTEGER 2 5190 : } 5191 13 02 2: INTEGER 256 5192 17 30 13: SEQUENCE { 5193 19 06 9: OBJECT IDENTIFIER 5194 : sha1withRSAEncryption (1 2 840 113549 1 1 5) 5195 30 05 0: NULL 5196 : } 5197 32 30 42: SEQUENCE { 5198 34 31 11: SET { 5199 36 30 9: SEQUENCE { 5200 38 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5201 43 13 2: PrintableString 'US' 5202 : } 5203 : } 5204 47 31 12: SET { 5205 49 30 10: SEQUENCE { 5206 51 06 3: OBJECT IDENTIFIER 5207 organizationalUnitName (2 5 4 11) 5208 56 13 3: PrintableString 'gov' 5209 : } 5210 : } 5211 61 31 13: SET { 5212 63 30 11: SEQUENCE { 5213 65 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5214 70 13 4: PrintableString 'NIST' 5215 : } 5216 : } 5217 : } 5218 76 30 30: SEQUENCE { 5219 78 17 13: UTCTime '960521095826Z' 5220 93 17 13: UTCTime '970521095826Z' 5221 : } 5222 108 30 61: SEQUENCE { 5223 110 31 11: SET { 5224 112 30 9: SEQUENCE { 5225 114 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5226 119 13 2: PrintableString 'US' 5227 : } 5228 : } 5229 123 31 12: SET { 5230 125 30 10: SEQUENCE { 5231 127 06 3: OBJECT IDENTIFIER 5232 organizationalUnitName (2 5 4 11) 5233 132 13 3: PrintableString 'gov' 5234 : } 5235 : } 5236 137 31 13: SET { 5237 139 30 11: SEQUENCE { 5238 141 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5239 146 13 4: PrintableString 'NIST' 5240 : } 5241 : } 5242 152 31 17: SET { 5243 154 30 15: SEQUENCE { 5244 156 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 5245 161 13 8: PrintableString 'Tim Polk' 5246 : } 5247 : } 5248 : } 5249 171 30 159: SEQUENCE { 5250 174 30 13: SEQUENCE { 5251 176 06 9: OBJECT IDENTIFIER 5252 rsaEncryption (1 2 840 113549 1 1 1) 5253 187 05 0: NULL 5254 : } 5256 189 03 141: BIT STRING 0 unused bits 5257 : 30 81 89 02 81 81 00 E1 CE 06 C9 D7 00 DF 65 27 5258 : 45 1E 63 6A 09 A0 A0 10 4B AF DF 9D 36 1D 44 1F 5259 : B7 07 5D 36 92 09 6A 1A 96 C7 4E D9 86 0D 0F 77 5260 : 94 F5 82 62 68 9A F2 D7 76 F5 9A 35 C7 B3 7F 4F 5261 : BE 64 CF A3 0C B3 84 32 80 F5 CA 77 29 C9 76 0B 5262 : 4C 38 19 EE 61 6F BA 68 E0 03 85 46 34 AB 84 64 5263 : 7F 43 69 02 C0 20 86 BD B1 D4 AD 21 A9 1A 8F CF 5264 : 96 83 86 92 57 5B 43 09 28 4C F2 5A 04 AD E5 DE 5265 : 9E 4F E8 38 3C F0 89 02 03 01 00 01 5266 : } 5267 333 A3 175: [3] { 5268 336 30 172: SEQUENCE { 5269 339 30 63: SEQUENCE { 5270 341 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 5271 346 04 56: OCTET STRING 5272 : 30 36 86 34 68 74 74 70 3A 2F 2F 77 77 77 2E 69 5273 : 74 6C 2E 6E 69 73 74 2E 67 6F 76 2F 64 69 76 38 5274 : 39 33 2F 73 74 61 66 66 2F 70 6F 6C 6B 2F 69 6E 5275 : 64 65 78 2E 68 74 6D 6C 5276 : } 5277 404 30 31: SEQUENCE { 5278 406 06 3: OBJECT IDENTIFIER issuerAltName (2 5 29 18) 5279 411 04 24: OCTET STRING 5280 : 30 16 86 14 68 74 74 70 3A 2F 2F 77 77 77 2E 6E 5281 : 69 73 74 2E 67 6F 76 2F 5282 : } 5283 437 30 31: SEQUENCE { 5284 439 06 3: OBJECT IDENTIFIER 5285 authorityKeyIdentifier (2 5 29 35) 5286 444 04 24: OCTET STRING 5287 : 30 16 80 14 30 12 80 10 0E 6B 3A BF 04 EA 04 C3 5288 : 0E 6B 3A BF 04 EA 04 C3 5289 : } 5290 470 30 23: SEQUENCE { 5291 472 06 3: OBJECT IDENTIFIER 5292 certificatePolicies (2 5 29 32) 5293 477 04 16: OCTET STRING 5294 : 30 0E 30 0C 06 0A 60 86 48 01 65 03 02 01 30 09 5295 : } 5296 495 30 14: SEQUENCE { 5297 497 06 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) 5298 502 01 1: BOOLEAN TRUE 5299 505 04 4: OCTET STRING 5300 : 03 02 07 80 5301 : } 5302 : } 5303 : } 5304 : } 5305 511 30 13: SEQUENCE { 5306 513 06 9: OBJECT IDENTIFIER 5307 : sha1withRSAEncryption (1 2 840 113549 1 1 5) 5308 524 05 0: NULL 5309 : } 5310 526 03 129: BIT STRING 0 unused bits 5311 : C1 25 6F AB 72 C0 5D DA E4 2F D5 E1 B0 25 D8 B4 5312 : F1 82 95 D6 0D A5 4E 4F A1 23 E1 13 A4 9C 3D C5 5313 : 7F FD 05 EC 75 06 30 66 97 75 A6 5D 8F 97 BA B4 5314 : EC A9 43 19 8D B7 54 FD E9 AD 43 B8 3C 8B D3 9E 5315 : C7 C7 27 E3 1A AD D3 79 AC 65 5A 52 78 C4 D0 43 5316 : 81 50 F7 8A BA E2 30 1A 6D D0 78 A0 4E AE 2E 79 5317 : 37 0C 93 05 5C D1 9C 1B B2 62 73 D1 EA 50 B7 84 5318 : 29 92 74 34 CF BA AA 2C 4D 43 59 EF 98 0C 41 6C 5319 : } 5321 C.4 Certificate Revocation List 5323 This section contains an annotated hex dump of a version 2 CRL with 5324 one extension (cRLNumber). The CRL was issued by OU=nist;O=gov;C=us 5325 on July 7, 1996; the next scheduled issuance was August 7, 1996. The 5326 CRL includes one revoked certificates: serial number 18 (12 hex). 5327 The CRL itself is number 18, and it was signed with DSA and SHA-1. 5329 0 30 203: SEQUENCE { 5330 3 30 140: SEQUENCE { 5331 6 02 1: INTEGER 1 5332 9 30 9: SEQUENCE { 5333 11 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5334 : } 5335 20 30 42: SEQUENCE { 5336 22 31 11: SET { 5337 24 30 9: SEQUENCE { 5338 26 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 5339 31 13 2: PrintableString 'US' 5340 : } 5341 : } 5342 35 31 12: SET { 5343 37 30 10: SEQUENCE { 5344 39 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 5345 44 13 3: PrintableString 'gov' 5346 : } 5347 : } 5348 49 31 13: SET { 5349 51 30 11: SEQUENCE { 5350 53 06 3: OBJECT IDENTIFIER 5351 organizationalUnitName (2 5 4 11) 5353 58 13 4: PrintableString 'NIST' 5354 : } 5355 : } 5356 : } 5357 64 17 13: UTCTime '970807000000Z' 5358 79 17 13: UTCTime '970907000000Z' 5359 94 30 34: SEQUENCE { 5360 96 30 32: SEQUENCE { 5361 98 02 1: INTEGER 18 5362 101 17 13: UTCTime '970731000000Z' 5363 116 30 12: SEQUENCE { 5364 118 30 10: SEQUENCE { 5365 120 06 3: OBJECT IDENTIFIER cRLReason (2 5 29 21) 5366 125 04 3: OCTET STRING 5367 : 0A 01 01 5368 : } 5369 : } 5370 : } 5371 : } 5372 130 A0 14: [0] { 5373 132 30 12: SEQUENCE { 5374 134 30 10: SEQUENCE { 5375 136 06 3: OBJECT IDENTIFIER cRLNumber (2 5 29 20) 5376 141 04 3: OCTET STRING 5377 : 02 01 12 5378 : } 5379 : } 5380 : } 5381 : } 5382 146 30 9: SEQUENCE { 5383 148 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 5384 : } 5385 157 03 47: BIT STRING 0 unused bits 5386 : 30 2C 02 14 79 1F F6 93 0B 84 06 D6 A0 7C 8D 68 5387 : A7 52 2E 5F 3F 89 9B 4B 02 14 66 D4 B5 2A 68 36 5388 : 9B 72 88 58 E3 89 19 AD 81 89 2E 96 BB CC 5389 : } 5391 Appendix D. Author Addresses: 5393 Russell Housley 5394 SPYRUS 5395 381 Elden Street 5396 Suite 1120 5397 Herndon, VA 20170 5398 USA 5399 housley@spyrus.com 5401 Warwick Ford 5402 VeriSign, Inc. 5403 One Alewife Center 5404 Cambridge, MA 02140 5405 USA 5406 wford@verisign.com 5408 Tim Polk 5409 NIST 5410 Building 820, Room 426 5411 Gaithersburg, MD 20899 5412 USA 5413 wpolk@nist.gov 5415 David Solo 5416 Citicorp 5417 666 Fifth Ave, 3rd Floor 5418 New York, NY 10103 5419 USA 5420 david.solo@citicorp.com 5422 Appendix E. Full Copyright Statement 5424 Copyright (C) The Internet Society (date). All Rights Reserved. 5426 This document and translations of it may be copied and furnished to 5427 others, and derivative works that comment on or otherwise explain it 5428 or assist in its implementation may be prepared, copied, published 5429 and distributed, in whole or in part, without restriction of any 5430 kind, provided that the above copyright notice and this paragraph are 5431 included on all such copies and derivative works. In addition, the 5432 ASN.1 modules presented in Appendices A and B may be used in whole or 5433 in part without inclusion of the copyright notice. However, this 5434 document itself may not be modified in any way, such as by removing 5435 the copyright notice or references to the Internet Society or other 5436 Internet organizations, except as needed for the purpose of 5437 developing Internet standards in which case the procedures for 5438 copyrights defined in the Internet Standards process shall be 5439 followed, or as required to translate it into languages other than 5440 English. 5442 The limited permissions granted above are perpetual and will not be 5443 revoked by the Internet Society or its successors or assigns. This 5444 document and the information contained herein is provided on an "AS 5445 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 5446 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 5447 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 5448 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 5449 OR FITNESS FOR A PARTICULAR PURPOSE.