idnits 2.17.1 draft-ietf-pkix-ipki-part1-11.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 127 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 128 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 53 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 574 has weird spacing: '...issuing a cer...' == Line 584 has weird spacing: '...: This is th...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 23, 1998) is 9345 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 5610 -- Looks like a reference, but probably isn't: '1' on line 5167 -- Looks like a reference, but probably isn't: '2' on line 5168 -- Looks like a reference, but probably isn't: '3' on line 5696 == Missing Reference: 'ISO 8859-1' is mentioned on line 869, but not defined -- Looks like a reference, but probably isn't: '4' on line 5170 -- Looks like a reference, but probably isn't: '5' on line 5035 -- Looks like a reference, but probably isn't: '6' on line 5036 -- Looks like a reference, but probably isn't: '7' on line 5037 -- Looks like a reference, but probably isn't: '8' on line 5038 == Missing Reference: 'RFC1738' is mentioned on line 2228, but not defined ** Obsolete undefined reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) == Missing Reference: 'RFC1778' is mentioned on line 2228, but not defined ** Obsolete undefined reference: RFC 1778 (Obsoleted by RFC 3494) == Missing Reference: 'DB94' is mentioned on line 2648, but not defined == Missing Reference: 'UNIVERSAL 28' is mentioned on line 3210, but not defined == Missing Reference: 'UNIVERSAL 30' is mentioned on line 3213, but not defined == Missing Reference: 'UNIVERSAL 12' is mentioned on line 3217, but not defined == Missing Reference: 'APPLICATION 1' is mentioned on line 4586, but not defined == Missing Reference: 'APPLICATION 2' is mentioned on line 4592, but not defined == Unused Reference: 'FIPS 180-1' is defined on line 2942, but no explicit reference was found in the text == Unused Reference: 'RFC 1778' is defined on line 2982, but no explicit reference was found in the text == Unused Reference: 'RFC 1883' is defined on line 2986, but no explicit reference was found in the text == Unused Reference: 'RFC 2044' is defined on line 2989, but no explicit reference was found in the text == Unused Reference: 'RFC 2119' is defined on line 2992, but no explicit reference was found in the text == Unused Reference: 'RFC 2277' is defined on line 2999, but no explicit reference was found in the text == Unused Reference: 'RFC 2279' is defined on line 3002, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS 180-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS 186' -- Possible downref: Non-RFC (?) normative reference: ref. 'RC95' ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1319 (Obsoleted by RFC 6149) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Historic RFC: RFC 1422 ** Downref: Normative reference to an Historic RFC: RFC 1423 ** 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 2044 (Obsoleted by RFC 2279) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2313 (Obsoleted by RFC 2437) Summary: 23 errors (**), 0 flaws (~~), 25 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group R. Housley (SPYRUS) 3 Internet Draft W. Ford (VeriSign) 4 W. Polk (NIST) 5 D. Solo (Citicorp) 6 expires in six months September 23, 1998 8 Internet X.509 Public Key Infrastructure 10 Certificate and CRL Profile 12 14 Status of this Memo 16 This document is an Internet-Draft. 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 To view the entire list of current Internet-Drafts, please check the 27 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 29 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 30 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 32 Copyright (C) The Internet Society (1998). All Rights Reserved. 34 Abstract 36 This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use 37 in the Internet. An overview of the approach and model are provided 38 as an introduction. The X.509 v3 certificate format is described in 39 detail, with additional information regarding the format and 40 semantics of Internet name forms (e.g., IP addresses). Standard 41 certificate extensions are described, and a set of required 42 extensions is defined. The X.509 v2 CRL format is described and a 43 required extension set is defined as well. An algorithm for X.509 44 certificate path validation is described. Supplemental information is 45 provided describing the format of public keys and digital signatures 46 in X.509 certificates for common Internet public key encryption 47 algorithms (i.e., RSA, DSA, and Diffie-Hellman). ASN.1 modules and 48 examples are provided in the appendices. 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in RFC 2119. 54 Please send comments on this document to the ietf-pkix@imc.org mail 55 list. 57 Table of Contents 59 1 Introduction ................................................ 6 60 2 Requirements and Assumptions ................................ 7 61 2.1 Communication and Topology ................................ 7 62 2.2 Acceptability Criteria .................................... 8 63 2.3 User Expectations ......................................... 8 64 2.4 Administrator Expectations ................................ 8 65 3 Overview of Approach ........................................ 8 66 3.1 X.509 Version 3 Certificate ............................... 10 67 3.2 Certification Paths and Trust ............................. 11 68 3.3 Revocation ................................................ 13 69 3.4 Operational Protocols ..................................... 14 70 3.5 Management Protocols ...................................... 14 71 4 Certificate and Certificate Extensions Profile .............. 15 72 4.1 Basic Certificate Fields .................................. 16 73 4.1.1 Certificate Fields ...................................... 17 74 4.1.1.1 tbsCertificate ........................................ 17 75 4.1.1.2 signatureAlgorithm .................................... 17 76 4.1.1.3 signatureValue ........................................ 18 77 4.1.2 TBSCertificate .......................................... 18 78 4.1.2.1 Version ............................................... 18 79 4.1.2.2 Serial number ......................................... 18 80 4.1.2.3 Signature ............................................. 19 81 4.1.2.4 Issuer ................................................ 19 82 4.1.2.5 Validity .............................................. 22 83 4.1.2.5.1 UTCTime ............................................. 22 84 4.1.2.5.2 GeneralizedTime ..................................... 23 85 4.1.2.6 Subject ............................................... 23 86 4.1.2.7 Subject Public Key Info ............................... 24 87 4.1.2.8 Unique Identifiers .................................... 24 88 4.1.2.9 Extensions ............................................. 24 89 4.2 Certificate Extensions .................................... 25 90 4.2.1 Standard Extensions ..................................... 26 91 4.2.1.1 Authority Key Identifier .............................. 26 92 4.2.1.2 Subject Key Identifier ................................ 27 93 4.2.1.3 Key Usage ............................................. 28 94 4.2.1.4 Private Key Usage Period .............................. 29 95 4.2.1.5 Certificate Policies .................................. 30 96 4.2.1.6 Policy Mappings ....................................... 32 97 4.2.1.7 Subject Alternative Name .............................. 32 98 4.2.1.8 Issuer Alternative Name ............................... 35 99 4.2.1.9 Subject Directory Attributes .......................... 35 100 4.2.1.10 Basic Constraints .................................... 35 101 4.2.1.11 Name Constraints ..................................... 36 102 4.2.1.12 Policy Constraints ................................... 38 103 4.2.1.13 Extended key usage field ............................. 38 104 4.2.1.14 CRL Distribution Points .............................. 40 105 4.2.2 Internet Certificate Extensions ......................... 41 106 4.2.2.1 Authority Information Access .......................... 41 107 5 CRL and CRL Extensions Profile .............................. 42 108 5.1 CRL Fields ................................................ 43 109 5.1.1 CertificateList Fields .................................. 44 110 5.1.1.1 tbsCertList ........................................... 44 111 5.1.1.2 signatureAlgorithm .................................... 44 112 5.1.1.3 signatureValue ........................................ 45 113 5.1.2 Certificate List "To Be Signed" ......................... 45 114 5.1.2.1 Version ............................................... 45 115 5.1.2.2 Signature ............................................. 45 116 5.1.2.3 Issuer Name ........................................... 45 117 5.1.2.4 This Update ........................................... 46 118 5.1.2.5 Next Update ........................................... 46 119 5.1.2.6 Revoked Certificates .................................. 46 120 5.1.2.7 Extensions ............................................ 47 121 5.2 CRL Extensions ............................................ 47 122 5.2.1 Authority Key Identifier ................................ 47 123 5.2.2 Issuer Alternative Name ................................. 48 124 5.2.3 CRL Number .............................................. 48 125 5.2.4 Delta CRL Indicator ..................................... 48 126 5.2.5 Issuing Distribution Point .............................. 49 127 5.3 CRL Entry Extensions ...................................... 50 128 5.3.1 Reason Code ............................................. 50 129 5.3.2 Hold Instruction Code ................................... 51 130 5.3.3 Invalidity Date ......................................... 51 131 5.3.4 Certificate Issuer ...................................... 52 132 6 Certificate Path Validation ................................. 52 133 6.1 Basic Path Validation ..................................... 53 134 6.2 Extending Path Validation ................................. 57 135 7 Algorithm Support ........................................... 57 136 7.1 One-way Hash Functions .................................... 57 137 7.1.1 MD2 One-way Hash Function ............................... 58 138 7.1.2 MD5 One-way Hash Function ............................... 58 139 7.1.3 SHA-1 One-way Hash Function ............................. 58 140 7.2 Signature Algorithms ...................................... 58 141 7.2.1 RSA Signature Algorithm ................................. 59 142 7.2.2 DSA Signature Algorithm ................................. 60 143 7.3 Subject Public Key Algorithms ............................. 61 144 7.3.1 RSA Keys ................................................ 61 145 7.3.2 Diffie-Hellman Key Exchange Key ......................... 62 146 7.3.3 DSA Signature Keys ...................................... 63 147 8 References .................................................. 64 148 9 Intellectual Property Rights ................................ 66 149 10 Security Considerations .................................... 67 150 Appendix A. ASN.1 Structures and OIDs ......................... 70 151 A.1 Explicitly Tagged Module, 1988 Syntax ...................... 70 152 A.2 Implicitly Tagged Module, 1988 Syntax ...................... 84 153 Appendix B. 1993 ASN.1 Structures and OIDs .................... 91 154 B.1 Explicitly Tagged Module, 1993 Syntax ...................... 91 155 B.2 Implicitly Tagged Module, 1993 Syntax ...................... 108 156 Appendix C. ASN.1 Notes ....................................... 115 157 Appendix D. Examples .......................................... 116 158 D.1 Certificate ............................................... 116 159 D.2 Certificate ............................................... 119 160 D.3 End-Entity Certificate Using RSA .......................... 122 161 D.4 Certificate Revocation List ............................... 125 162 Appendix E. Author Addresses .................................. 127 163 Appendix F. Full Copyright Statement .......................... 127 165 1 Introduction 167 This specification is one part of a family of standards for the X.509 168 Public Key Infrastructure (PKI) for the Internet. This specification 169 is a standalone document; implementations of this standard may 170 proceed independent from the other parts. 172 This specification profiles the format and semantics of certificates 173 and certificate revocation lists for the Internet PKI. Procedures 174 are described for processing of certification paths in the Internet 175 environment. Encoding rules are provided for popular cryptographic 176 algorithms. Finally, ASN.1 modules are provided in the appendices 177 for all data structures defined or referenced. 179 The specification describes the requirements which inspire the crea- 180 tion of this document and the assumptions which affect its scope in 181 Section 2. Section 3 presents an architectural model and describes 182 its relationship to previous IETF and ISO/IEC/ITU standards. In par- 183 ticular, this document's relationship with the IETF PEM specifica- 184 tions and the ISO/IEC/ITU X.509 documents are described. 186 The specification profiles the X.509 version 3 certificate in Section 187 4, and the X.509 version 2 certificate revocation list (CRL) in Sec- 188 tion 5. The profiles include the identification of ISO/IEC/ITU and 189 ANSI extensions which may be useful in the Internet PKI. The profiles 190 are presented in the 1988 Abstract Syntax Notation One (ASN.1) rather 191 than the 1994 syntax used in the ISO/IEC/ITU standards. 193 This specification also includes path validation procedures in Sec- 194 tion 6. These procedures are based upon the ISO/IEC/ITU definition, 195 but the presentation assumes one or more self-signed trusted CA cer- 196 tificates. Implementations are required to derive the same results 197 but are not required to use the specified procedures. 199 Section 7 of the specification describes procedures for identifica- 200 tion and encoding of public key materials and digital signatures. 201 Implementations are not required to use any particular cryptographic 202 algorithms. However, conforming implementations which use the iden- 203 tified algorithms are required to identify and encode the public key 204 materials and digital signatures as described. 206 Finally, four appendices are provided to aid implementers. Appendix 207 A contains all ASN.1 structures defined or referenced within this 208 specification. As above, the material is presented in the 1988 209 Abstract Syntax Notation One (ASN.1) rather than the 1994 syntax. 210 Appendix B contains the same information in the 1994 ASN.1 notation 211 as a service to implementers using updated toolsets. However, Appen- 212 dix A takes precedence in case of conflict. Appendix C contains 213 notes on less familiar features of the ASN.1 notation used within 214 this specification. Appendix D contains examples of a conforming 215 certificate and a conforming CRL. 217 2 Requirements and Assumptions 219 The goal of this specification is to develop a profile to facilitate 220 the use of X.509 certificates within Internet applications for those 221 communities wishing to make use of X.509 technology. Such applica- 222 tions may include WWW, electronic mail, user authentication, and 223 IPsec. In order to relieve some of the obstacles to using X.509 cer- 224 tificates, this document defines a profile to promote the development 225 of certificate management systems; development of application tools; 226 and interoperability determined by policy. 228 Some communities will need to supplement, or possibly replace, this 229 profile in order to meet the requirements of specialized application 230 domains or environments with additional authorization, assurance, or 231 operational requirements. However, for basic applications, common 232 representations of frequently used attributes are defined so that 233 application developers can obtain necessary information without 234 regard to the issuer of a particular certificate or certificate revo- 235 cation list (CRL). 237 A certificate user should review the certificate policy generated by 238 the certification authority (CA) before relying on the authentication 239 or non-repudiation services associated with the public key in a par- 240 ticular certificate. To this end, this standard does not prescribe 241 legally binding rules or duties. 243 As supplemental authorization and attribute management tools emerge, 244 such as attribute certificates, it may be appropriate to limit the 245 authenticated attributes that are included in a certificate. These 246 other management tools may provide more appropriate methods of con- 247 veying many authenticated attributes. 249 2.1 Communication and Topology 251 The users of certificates will operate in a wide range of environ- 252 ments with respect to their communication topology, especially users 253 of secure electronic mail. This profile supports users without high 254 bandwidth, real-time IP connectivity, or high connection availabil- 255 ity. In addition, the profile allows for the presence of firewall or 256 other filtered communication. 258 This profile does not assume the deployment of an X.500 Directory 259 system. The profile does not prohibit the use of an X.500 Directory, 260 but other means of distributing certificates and certificate 261 revocation lists (CRLs) may be used. 263 2.2 Acceptability Criteria 265 The goal of the Internet Public Key Infrastructure (PKI) is to meet 266 the needs of deterministic, automated identification, authentication, 267 access control, and authorization functions. Support for these ser- 268 vices determines the attributes contained in the certificate as well 269 as the ancillary control information in the certificate such as pol- 270 icy data and certification path constraints. 272 2.3 User Expectations 274 Users of the Internet PKI are people and processes who use client 275 software and are the subjects named in certificates. These uses 276 include readers and writers of electronic mail, the clients for WWW 277 browsers, WWW servers, and the key manager for IPsec within a router. 278 This profile recognizes the limitations of the platforms these users 279 employ and the limitations in sophistication and attentiveness of the 280 users themselves. This manifests itself in minimal user configura- 281 tion responsibility (e.g., trusted CA keys, rules), explicit platform 282 usage constraints within the certificate, certification path con- 283 straints which shield the user from many malicious actions, and 284 applications which sensibly automate validation functions. 286 2.4 Administrator Expectations 288 As with user expectations, the Internet PKI profile is structured to 289 support the individuals who generally operate CAs. Providing 290 administrators with unbounded choices increases the chances that a 291 subtle CA administrator mistake will result in broad compromise. 292 Also, unbounded choices greatly complicate the software that shall 293 process and validate the certificates created by the CA. 295 3 Overview of Approach 297 Following is a simplified view of the architectural model assumed by 298 the PKIX specifications. 300 +---+ 301 | C | +------------+ 302 | e | <-------------------->| End entity | 303 | r | Operational +------------+ 304 | t | transactions ^ 305 | | and management | Management 306 | / | transactions | transactions 307 | | | PKI users 308 | C | v 309 | R | -------------------+--+-----------+---------------- 310 | L | ^ ^ 311 | | | | PKI management 312 | | v | entities 313 | R | +------+ | 314 | e | <---------------------| RA | <---+ | 315 | p | Publish certificate +------+ | | 316 | o | | | 317 | s | | | 318 | I | v v 319 | t | +------------+ 320 | o | <------------------------------| CA | 321 | r | Publish certificate +------------+ 322 | y | Publish CRL ^ 323 | | | 324 +---+ Management | 325 transactions | 326 v 327 +------+ 328 | CA | 329 +------+ 331 Figure 1 - PKI Entities 333 The components in this model are: 335 end entity: user of PKI certificates and/or end user system that 336 is the subject of a certificate; 337 CA: certification authority; 338 RA: registration authority, i.e., an optional system to 339 which a CA delegates certain management functions; 340 repository: a system or collection of distributed systems that 341 store certificates and CRLs and serves as a means of 342 distributing these certificates and CRLs to end 343 entities. 345 3.1 X.509 Version 3 Certificate 347 Users of a public key shall be confident that the associated private 348 key is owned by the correct remote subject (person or system) with 349 which an encryption or digital signature mechanism will be used. 350 This confidence is obtained through the use of public key certifi- 351 cates, which are data structures that bind public key values to sub- 352 jects. The binding is asserted by having a trusted CA digitally sign 353 each certificate. The CA may base this assertion upon technical means 354 (a.k.a., proof of posession through a challenge-response protocol), 355 presentation of the private key, or on an assertion by the subject. 356 A certificate has a limited valid lifetime which is indicated in its 357 signed contents. Because a certificate's signature and timeliness 358 can be independently checked by a certificate-using client, certifi- 359 cates can be distributed via untrusted communications and server sys- 360 tems, and can be cached in unsecured storage in certificate-using 361 systems. 363 ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8, which was 364 first published in 1988 as part of the X.500 Directory recommenda- 365 tions, defines a standard certificate format [X.509]. The certificate 366 format in the 1988 standard is called the version 1 (v1) format. 367 When X.500 was revised in 1993, two more fields were added, resulting 368 in the version 2 (v2) format. These two fields may be used to support 369 directory access control. 371 The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993, 372 include specifications for a public key infrastructure based on X.509 373 v1 certificates [RFC 1422]. The experience gained in attempts to 374 deploy RFC 1422 made it clear that the v1 and v2 certificate formats 375 are deficient in several respects. Most importantly, more fields 376 were needed to carry information which PEM design and implementation 377 experience has proven necessary. In response to these new require- 378 ments, ISO/IEC/ITU and ANSI X9 developed the X.509 version 3 (v3) 379 certificate format. The v3 format extends the v2 format by adding 380 provision for additional extension fields. Particular extension 381 field types may be specified in standards or may be defined and 382 registered by any organization or community. In June 1996, standardi- 383 zation of the basic v3 format was completed [X.509]. 385 ISO/IEC/ITU and ANSI X9 have also developed standard extensions for 386 use in the v3 extensions field [X.509][X9.55]. These extensions can 387 convey such data as additional subject identification information, 388 key attribute information, policy information, and certification path 389 constraints. 391 However, the ISO/IEC/ITU and ANSI X9 standard extensions are very 392 broad in their applicability. In order to develop interoperable 393 implementations of X.509 v3 systems for Internet use, it is necessary 394 to specify a profile for use of the X.509 v3 extensions tailored for 395 the Internet. It is one goal of this document to specify a profile 396 for Internet WWW, electronic mail, and IPsec applications. Environ- 397 ments with additional requirements may build on this profile or may 398 replace it. 400 3.2 Certification Paths and Trust 402 A user of a security service requiring knowledge of a public key gen- 403 erally needs to obtain and validate a certificate containing the 404 required public key. If the public-key user does not already hold an 405 assured copy of the public key of the CA that signed the certificate, 406 the CA's name, and related information (such as the validity period 407 or name constraints), then it might need an additional certificate to 408 obtain that public key. In general, a chain of multiple certificates 409 may be needed, comprising a certificate of the public key owner (the 410 end entity) signed by one CA, and zero or more additional certifi- 411 cates of CAs signed by other CAs. Such chains, called certification 412 paths, are required because a public key user is only initialized 413 with a limited number of assured CA public keys. 415 There are different ways in which CAs might be configured in order 416 for public key users to be able to find certification paths. For 417 PEM, RFC 1422 defined a rigid hierarchical structure of CAs. There 418 are three types of PEM certification authority: 420 (a) Internet Policy Registration Authority (IPRA): This author- 421 ity, operated under the auspices of the Internet Society, acts as 422 the root of the PEM certification hierarchy at level 1. It issues 423 certificates only for the next level of authorities, PCAs. All 424 certification paths start with the IPRA. 426 (b) Policy Certification Authorities (PCAs): PCAs are at level 2 427 of the hierarchy, each PCA being certified by the IPRA. A PCA 428 shall establish and publish a statement of its policy with respect 429 to certifying users or subordinate certification authorities. 430 Distinct PCAs aim to satisfy different user needs. For example, 431 one PCA (an organizational PCA) might support the general elec- 432 tronic mail needs of commercial organizations, and another PCA (a 433 high-assurance PCA) might have a more stringent policy designed 434 for satisfying legally binding digital signature requirements. 436 (c) Certification Authorities (CAs): CAs are at level 3 of the 437 hierarchy and can also be at lower levels. Those at level 3 are 438 certified by PCAs. CAs represent, for example, particular organi- 439 zations, particular organizational units (e.g., departments, 440 groups, sections), or particular geographical areas. 442 RFC 1422 furthermore has a name subordination rule which requires 443 that a CA can only issue certificates for entities whose names are 444 subordinate (in the X.500 naming tree) to the name of the CA itself. 445 The trust associated with a PEM certification path is implied by the 446 PCA name. The name subordination rule ensures that CAs below the PCA 447 are sensibly constrained as to the set of subordinate entities they 448 can certify (e.g., a CA for an organization can only certify entities 449 in that organization's name tree). Certificate user systems are able 450 to mechanically check that the name subordination rule has been fol- 451 lowed. 453 The RFC 1422 uses the X.509 v1 certificate formats. The limitations 454 of X.509 v1 required imposition of several structural restrictions to 455 clearly associate policy information or restrict the utility of cer- 456 tificates. These restrictions included: 458 (a) a pure top-down hierarchy, with all certification paths start- 459 ing from IPRA; 461 (b) a naming subordination rule restricting the names of a CA's 462 subjects; and 464 (c) use of the PCA concept, which requires knowledge of individual 465 PCAs to be built into certificate chain verification logic. 466 Knowledge of individual PCAs was required to determine if a chain 467 could be accepted. 469 With X.509 v3, most of the requirements addressed by RFC 1422 can be 470 addressed using certificate extensions, without a need to restrict 471 the CA structures used. In particular, the certificate extensions 472 relating to certificate policies obviate the need for PCAs and the 473 constraint extensions obviate the need for the name subordination 474 rule. As a result, this document supports a more flexible architec- 475 ture, including: 477 (a) Certification paths may start with a public key of a CA in a 478 user's own domain, or with the public key of the top of a hierar- 479 chy. Starting with the public key of a CA in a user's own domain 480 has certain advantages. In some environments, the local domain is 481 the most trusted. 483 (b) Name constraints may be imposed through explicit inclusion of 484 a name constraints extension in a certificate, but are not 485 required. 487 (c) Policy extensions and policy mappings replace the PCA con- 488 cept, which permits a greater degree of automation. The applica- 489 tion can determine if the certification path is acceptable based 490 on the contents of the certificates instead of a priori knowledge 491 of PCAs. This permits automation of certificate chain processing. 493 3.3 Revocation 495 When a certificate is issued, it is expected to be in use for its 496 entire validity period. However, various circumstances may cause a 497 certificate to become invalid prior to the expiration of the validity 498 period. Such circumstances include change of name, change of associa- 499 tion between subject and CA (e.g., an employee terminates employment 500 with an organization), and compromise or suspected compromise of the 501 corresponding private key. Under such circumstances, the CA needs to 502 revoke the certificate. 504 X.509 defines one method of certificate revocation. This method 505 involves each CA periodically issuing a signed data structure called 506 a certificate revocation list (CRL). A CRL is a time stamped list 507 identifying revoked certificates which is signed by a CA and made 508 freely available in a public repository. Each revoked certificate is 509 identified in a CRL by its certificate serial number. When a 510 certificate-using system uses a certificate (e.g., for verifying a 511 remote user's digital signature), that system not only checks the 512 certificate signature and validity but also acquires a suitably- 513 recent CRL and checks that the certificate serial number is not on 514 that CRL. The meaning of "suitably-recent" may vary with local pol- 515 icy, but it usually means the most recently-issued CRL. A CA issues 516 a new CRL on a regular periodic basis (e.g., hourly, daily, or 517 weekly). An entry is added to the CRL as part of the next update 518 following notification of revocation. An entry may be removed from 519 the CRL after appearing on one regularly scheduled CRL issued beyond 520 the revoked certificate's validity period. 522 An advantage of this revocation method is that CRLs may be distri- 523 buted by exactly the same means as certificates themselves, namely, 524 via untrusted communications and server systems. 526 One limitation of the CRL revocation method, using untrusted communi- 527 cations and servers, is that the time granularity of revocation is 528 limited to the CRL issue period. For example, if a revocation is 529 reported now, that revocation will not be reliably notified to 530 certificate-using systems until the next periodic CRL is issued -- 531 this may be up to one hour, one day, or one week depending on the 532 frequency that the CA issues CRLs. 534 As with the X.509 v3 certificate format, in order to facilitate 535 interoperable implementations from multiple vendors, the X.509 v2 CRL 536 format needs to be profiled for Internet use. It is one goal of this 537 document to specify that profile. However, this profile does not 538 require CAs to issue CRLs. Message formats and protocols supporting 539 on-line revocation notification may be defined in other PKIX specifi- 540 cations. On-line methods of revocation notification may be applica- 541 ble in some environments as an alternative to the X.509 CRL. On-line 542 revocation checking may significantly reduce the latency between a 543 revocation report and the distribution of the information to relying 544 parties. Once the CA accepts the report as authentic and valid, any 545 query to the on-line service will correctly reflect the certificate 546 validation impacts of the revocation. However, these methods impose 547 new security requirements; the certificate validator shall trust the 548 on-line validation service while the repository does not need to be 549 trusted. 551 3.4 Operational Protocols 553 Operational protocols are required to deliver certificates and CRLs 554 (or status information) to certificate using client systems. Provi- 555 sion is needed for a variety of different means of certificate and 556 CRL delivery, including distribution procedures based on LDAP, HTTP, 557 FTP, and X.500. Operational protocols supporting these functions are 558 defined in other PKIX specifications. These specifications may 559 include definitions of message formats and procedures for supporting 560 all of the above operational environments, including definitions of 561 or references to appropriate MIME content types. 563 3.5 Management Protocols 565 Management protocols are required to support on-line interactions 566 between PKI user and management entities. For example, a management 567 protocol might be used between a CA and a client system with which a 568 key pair is associated, or between two CAs which cross-certify each 569 other. The set of functions which potentially need to be supported 570 by management protocols include: 572 (a) registration: This is the process whereby a user first makes 573 itself known to a CA (directly, or through an RA), prior to that 574 CA issuing a certificate or certificates for that user. 576 (b) initialization: Before a client system can operate securely 577 it is necessary to install key materials which have the appropri- 578 ate relationship with keys stored elsewhere in the infrastructure. 579 For example, the client needs to be securely initialized with the 580 public key and other assured information of the trusted CA(s), to 581 be used in validating certificate paths. Furthermore, a client 582 typically needs to be initialized with its own key pair(s). 584 (c) certification: This is the process in which a CA issues a 585 certificate for a user's public key, and returns that certificate 586 to the user's client system and/or posts that certificate in a 587 repository. 589 (d) key pair recovery: As an option, user client key materials 590 (e.g., a user's private key used for encryption purposes) may be 591 backed up by a CA or a key backup system. If a user needs to 592 recover these backed up key materials (e.g., as a result of a for- 593 gotten password or a lost key chain file), an on-line protocol 594 exchange may be needed to support such recovery. 596 (e) key pair update: All key pairs need to be updated regularly, 597 i.e., replaced with a new key pair, and new certificates issued. 599 (f) revocation request: An authorized person advises a CA of an 600 abnormal situation requiring certificate revocation. 602 (g) cross-certification: Two CAs exchange information used in 603 establishing a cross-certificate. A cross-certificate is a certi- 604 ficate issued by one CA to another CA which contains a CA signa- 605 ture key used for issuing certificates. 607 Note that on-line protocols are not the only way of implementing the 608 above functions. For all functions there are off-line methods of 609 achieving the same result, and this specification does not mandate 610 use of on-line protocols. For example, when hardware tokens are 611 used, many of the functions may be achieved as part of the physical 612 token delivery. Furthermore, some of the above functions may be com- 613 bined into one protocol exchange. In particular, two or more of the 614 registration, initialization, and certification functions can be com- 615 bined into one protocol exchange. 617 The PKIX series of specifications may define a set of standard mes- 618 sage formats supporting the above functions in future specifications. 619 In that case, the protocols for conveying these messages in different 620 environments (e.g., on-line, file transfer, e-mail, and WWW) will 621 also be described in those specifications. 623 4 Certificate and Certificate Extensions Profile 625 This section presents a profile for public key certificates that will 626 foster interoperability and a reusable PKI. This section is based 627 upon the X.509 v3 certificate format and the standard certificate 628 extensions defined in [X.509]. The ISO/IEC/ITU documents use the 629 1993 version of ASN.1; while this document uses the 1988 ASN.1 syn- 630 tax, the encoded certificate and standard extensions are equivalent. 631 This section also defines private extensions required to support a 632 PKI for the Internet community. 634 Certificates may be used in a wide range of applications and environ- 635 ments covering a broad spectrum of interoperability goals and a 636 broader spectrum of operational and assurance requirements. The goal 637 of this document is to establish a common baseline for generic appli- 638 cations requiring broad interoperability and limited special purpose 639 requirements. In particular, the emphasis will be on supporting the 640 use of X.509 v3 certificates for informal Internet electronic mail, 641 IPsec, and WWW applications. 643 4.1 Basic Certificate Fields 645 The X.509 v3 certificate basic syntax is as follows. For signature 646 calculation, the certificate is encoded using the ASN.1 distinguished 647 encoding rules (DER) [X.208]. ASN.1 DER encoding is a tag, length, 648 value encoding system for each element. 650 Certificate ::= SEQUENCE { 651 tbsCertificate TBSCertificate, 652 signatureAlgorithm AlgorithmIdentifier, 653 signatureValue BIT STRING } 655 TBSCertificate ::= SEQUENCE { 656 version [0] EXPLICIT Version DEFAULT v1, 657 serialNumber CertificateSerialNumber, 658 signature AlgorithmIdentifier, 659 issuer Name, 660 validity Validity, 661 subject Name, 662 subjectPublicKeyInfo SubjectPublicKeyInfo, 663 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 664 -- If present, version shall be v2 or v3 665 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 666 -- If present, version shall be v2 or v3 667 extensions [3] EXPLICIT Extensions OPTIONAL 668 -- If present, version shall be v3 669 } 671 Version ::= INTEGER { v1(0), v2(1), v3(2) } 673 CertificateSerialNumber ::= INTEGER 675 Validity ::= SEQUENCE { 676 notBefore Time, 677 notAfter Time } 679 Time ::= CHOICE { 680 utcTime UTCTime, 681 generalTime GeneralizedTime } 683 UniqueIdentifier ::= BIT STRING 685 SubjectPublicKeyInfo ::= SEQUENCE { 686 algorithm AlgorithmIdentifier, 687 subjectPublicKey BIT STRING } 689 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 691 Extension ::= SEQUENCE { 692 extnID OBJECT IDENTIFIER, 693 critical BOOLEAN DEFAULT FALSE, 694 extnValue OCTET STRING } 696 The following items describe the X.509 v3 certificate for use in the 697 Internet. 699 4.1.1 Certificate Fields 701 The Certificate is a SEQUENCE of three required fields. The fields 702 are described in detail in the following subsections. 704 4.1.1.1 tbsCertificate 706 The field contains the names of the subject and issuer, a public key 707 associated with the subject, a validity period, and other associated 708 information. The fields are described in detail in section 4.1.2; 709 the tbscertificate may also include extensions which are described in 710 section 4.2. 712 4.1.1.2 signatureAlgorithm 714 The signatureAlgorithm field contains the identifier for the crypto- 715 graphic algorithm used by the CA to sign this certificate. Section 716 7.2 lists the supported signature algorithms. 718 An algorithm identifier is defined by the following ASN.1 structure: 720 AlgorithmIdentifier ::= SEQUENCE { 721 algorithm OBJECT IDENTIFIER, 722 parameters ANY DEFINED BY algorithm OPTIONAL } 724 The algorithm identifier is used to identify a cryptographic algo- 725 rithm. The OBJECT IDENTIFIER component identifies the algorithm 726 (such as DSA with SHA-1). The contents of the optional parameters 727 field will vary according to the algorithm identified. Section 7.2 728 lists the supported algorithms for this specification. 730 This field MUST contain the same algorithm identifier as the 731 signature field in the sequence tbsCertificate (see sec. 4.1.2.3). 733 4.1.1.3 signatureValue 735 The signatureValue field contains a digital signature computed upon 736 the ASN.1 DER encoded tbsCertificate. The ASN.1 DER encoded tbsCer- 737 tificate is used as the input to the signature function. This signa- 738 ture value is then ASN.1 encoded as a BIT STRING and included in the 739 Certificate's signature field. The details of this process are speci- 740 fied for each of the supported algorithms in Section 7.2. 742 By generating this signature, a CA certifies the validity of the 743 information in the tbsCertificate field. In particular, the CA cer- 744 tifies the binding between the public key material and the subject of 745 the certificate. 747 4.1.2 TBSCertificate 749 The sequence TBSCertificate contains information associated with the 750 subject of the certificate and the CA who issued it. Every TBSCerti- 751 ficate contains the names of the subject and issuer, a public key 752 associated with the subject, a validity period, a version number, and 753 a serial number; some may contain optional unique identifier fields. 754 The remainder of this section describes the syntax and semantics of 755 these fields. A TBSCertificate may also include extensions. Exten- 756 sions for the Internet PKI are described in Section 4.2. 758 4.1.2.1 Version 760 This field describes the version of the encoded certificate. When 761 extensions are used, as expected in this profile, use X.509 version 3 762 (value is 2). If no extensions are present, but a UniqueIdentifier 763 is present, use version 2 (value is 1). If only basic fields are 764 present, use version 1 (the value is omitted from the certificate as 765 the default value). 767 Implementations SHOULD be prepared to accept any version certificate. 768 At a minimum, conforming implementations MUST recognize version 3 769 certificates. 771 Generation of version 2 certificates is not expected by implementa- 772 tions based on this profile. 774 4.1.2.2 Serial number 776 The serial number is an integer assigned by the CA to each certifi- 777 cate. It MUST be unique for each certificate issued by a given CA 778 (i.e., the issuer name and serial number identify a unique 779 certificate). 781 4.1.2.3 Signature 783 This field contains the algorithm identifier for the algorithm used 784 by the CA to sign the certificate. 786 This field MUST contain the same algorithm identifier as the signa- 787 tureAlgorithm field in the sequence Certificate (see sec. 4.1.1.2). 788 The contents of the optional parameters field will vary according to 789 the algorithm identified. Section 7.2 lists the supported signature 790 algorithms. 792 4.1.2.4 Issuer 794 The issuer field identifies the entity who has signed and issued the 795 certificate. The issuer field MUST contain a non-empty distinguished 796 name (DN). The issuer field is defined as the X.501 type Name. 797 [X.501] Name is defined by the following ASN.1 structures: 799 Name ::= CHOICE { 800 RDNSequence } 802 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 804 RelativeDistinguishedName ::= 805 SET OF AttributeTypeAndValue 807 AttributeTypeAndValue ::= SEQUENCE { 808 type AttributeType, 809 value AttributeValue } 811 AttributeType ::= OBJECT IDENTIFIER 813 AttributeValue ::= ANY DEFINED BY AttributeType 815 DirectoryString ::= CHOICE { 816 teletexString TeletexString (SIZE (1..MAX)), 817 printableString PrintableString (SIZE (1..MAX)), 818 universalString UniversalString (SIZE (1..MAX)), 819 utf8String UTF8String (SIZE (1.. MAX)), 820 bmpString BMPString (SIZE (1..MAX)) } 822 The Name describes a hierarchical name composed of attributes, such 823 as country name, and corresponding values, such as US. The type of 824 the component AttributeValue is determined by the AttributeType; in 825 general it will be a DirectoryString. 827 The DirectoryString type is defined as a choice of PrintableString, 828 TeletexString, BMPString, UTF8String, and UniversalString. The 829 UTF8String encoding is the preferred encoding, and all certificates 830 issued after December 31, 2003 MUST use the UTF8String encoding of 831 DirectoryString (except as noted below). Until that date, conforming 832 CAs MUST choose from the following options when creating a dis- 833 tinguished name, including their own: 835 (a) if the character set is sufficient, the string MAY be 836 represented as a PrintableString; 838 (b) failing (a), if the BMPString character set is sufficient the 839 string MAY be represented as a BMPString; and 841 (c) failing (a) and (b), the string MUST be represented as a 842 UTF8String. If (a) or (b) is satisfied, the CA MAY still choose 843 to represent the string as a UTF8String. 845 Exceptions to the December 31, 2003 UTF8 encoding requirements are as 846 follows: 848 (a) CAs MAY issue "name rollover" certificates to support an ord- 849 erly migration to UTF8String encoding. Such certificates would 850 include the CA's UTF8String encoded name as issuer and and the old 851 name encoding as subject, or vice-versa. 853 (b) As stated in section 4.1.2.6, the subject field MUST be popu- 854 lated with a non-empty distinguished name matching the contents of 855 the issuer field in all certificates issued by the subject CA 856 regardless of encoding. 858 The TeletexString and UniversalString are included for backward com- 859 patibility, and should not be used for certificates for new subjects. 860 However, these types may be used in certificates where the name was 861 previously established. Certificate users SHOULD be prepared to 862 receive certificates with these types. 864 In addition, many legacy implementations support names encoded in the 865 ISO 8859-1 character set (Latin1String) but tag them as Teletex- 866 String. The Latin1String includes characters used in Western Euro- 867 pean countries which are not part of the TeletexString charcter set. 868 Implementations that process TeletexString SHOULD be prepared to han- 869 dle the entire ISO 8859-1 character set.[ISO 8859-1] 871 As noted above, distinguished names are composed of attributes. This 872 specification does not restrict the set of attribute types that may 873 appear in names. However, conforming implementations MUST be 874 prepared to receive certificates with issuer names containing the set 875 of attribute types defined below. This specification also recommends 876 support for additional attribute types. 878 Standard sets of attributes have been defined in the X.500 series of 879 specifications.[X.520] Implementations of this specification MUST be 880 prepared to receive the following standard attribute types in issuer 881 names: country, organization, organizational-unit, distinguished name 882 qualifier, state or province name, and common name (e.g., "Susan 883 Housley"). In addition, implementations of this specification SHOULD 884 be prepared to receive the following standard attribute types in 885 issuer names: locality, title, surname, given name, initials, and 886 generation qualifier (e.g., "Jr.", "3rd", or "IV"). The syntax and 887 associated object identifiers (OIDs) for these attribute types are 888 provided in the ASN.1 modules in Appendices A and B. 890 In addition, implementations of this specification MUST be prepared 891 to receive the domainComponent attribute, as defined in [RFC 2247]. 892 The Domain (Nameserver) System (DNS) provides a hierarchical resource 893 labeling system. This attribute provides is a convenient mechanism 894 for organizations that wish to use DNs that parallel their DNS names. 895 This is not a replacement for the dNSName component of the alterna- 896 tive name field. Implementations are not required to convert such 897 names into DNS names. The syntax and associated OID for this attri- 898 bute type is provided in the ASN.1 modules in Appendices A and B. 900 Certificate users MUST be prepared to process the issuer dis- 901 tinguished name and subject distinguished name (see sec. 4.1.2.6) 902 fields to perform name chaining for certification path validation 903 (see section 6). Name chaining is performed by matching the issuer 904 distinguished name in one certificate with the subject name in a CA 905 certificate. 907 This specification requires only a subset of the name comparison 908 functionality specified in the X.500 series of specifications. The 909 requirements for conforming implementations are as follows: 911 (a) attribute values encoded in different types (e.g., Printable- 912 String and BMPString) may be assumed to represent different 913 strings; 915 (b) attribute values in types other than PrintableString are case 916 sensitive (this permits matching of attribute values as binary 917 objects); 919 (c) attribute values in PrintableString are not case sensitive 920 (e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and 922 (d) attribute values in PrintableString are compared after 923 removing leading and trailing white space and converting internal 924 substrings of one or more consecutive white space characters to a 925 single space. 927 These name comparison rules permit a certificate user to validate 928 certificates issued using languages or encodings unfamiliar to the 929 certificate user. 931 In addition, implementations of this specification MAY use these com- 932 parison rules to process unfamiliar attribute types for name chain- 933 ing. This allows implementations to process certificates with unfami- 934 liar attributes in the issuer name. 936 Note that the comparison rules defined in the X.500 series of specif- 937 ications indicate that the character sets used to encode data in dis- 938 tinguished names are irrelevant. The characters themselves are com- 939 pared without regard to encoding. Implementations of the profile are 940 permitted to use the comparison algorithm defined in the X.500 941 series. Such an implementation will recognize a superset of name 942 matches recognized by the algorithm specified above. 944 4.1.2.5 Validity 946 The certificate validity period is the time interval during which the 947 CA warrants that it will maintain information about the status of the 948 certificate. The field is represented as a SEQUENCE of two dates: 949 the date on which the certificate validity period begins (notBefore) 950 and the date on which the certificate validity period ends 951 (notAfter). Both notBefore and notAfter may be encoded as UTCTime or 952 GeneralizedTime. 954 CAs conforming to this profile MUST always encode certificate vali- 955 dity dates through the year 2049 as UTCTime; certificate validity 956 dates in 2050 or later MUST be encoded as GeneralizedTime. 958 4.1.2.5.1 UTCTime 960 The universal time type, UTCTime, is a standard ASN.1 type intended 961 for international applications where local time alone is not ade- 962 quate. UTCTime specifies the year through the two low order digits 963 and time is specified to the precision of one minute or one second. 964 UTCTime includes either Z (for Zulu, or Greenwich Mean Time) or a 965 time differential. 967 For the purposes of this profile, UTCTime values MUST be expressed 968 Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are 969 YYMMDDHHMMSSZ), even where the number of seconds is zero. Conforming 970 systems MUST interpret the year field (YY) as follows: 972 Where YY is greater than or equal to 50, the year shall be inter- 973 preted as 19YY; and 975 Where YY is less than 50, the year shall be interpreted as 20YY. 977 4.1.2.5.2 GeneralizedTime 979 The generalized time type, GeneralizedTime, is a standard ASN.1 type 980 for variable precision representation of time. Optionally, the Gen- 981 eralizedTime field can include a representation of the time differen- 982 tial between local and Greenwich Mean Time. 984 For the purposes of this profile, GeneralizedTime values MUST be 985 expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e., 986 times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. 987 GeneralizedTime values MUST NOT include fractional seconds. 989 4.1.2.6 Subject 991 The subject field identifies the entity associated with the public 992 key stored in the subject public key field. The subject name may be 993 carried in the subject field and/or the subjectAltName extension. If 994 the subject is a CA (e.g., the basic constraints extension, as dis- 995 cussed in 4.2.1.10, is present and the value of cA is TRUE,) then the 996 subject field MUST be populated with a non-empty distinguished name 997 matching the contents of the issuer field (see sec. 4.1.2.4) in all 998 certificates issued by the subject CA. If subject naming information 999 is present only in the subjectAltName extension (e.g., a key bound 1000 only to an email address or URI), then the subject name MUST be an 1001 empty sequence and the subjectAltName extension MUST be critical. 1003 Where it is non-empty, the subject field MUST contain an X.500 dis- 1004 tinguished name (DN). The DN MUST be unique for each subject entity 1005 certified by the one CA as defined by the issuer name field. A CA may 1006 issue more than one certificate with the same DN to the same subject 1007 entity. 1009 The subject name field is defined as the X.501 type Name. Implemen- 1010 tation requirements for this field are those defined for the issuer 1011 field (see sec. 4.1.2.4). When encoding attribute values of type 1012 DirectoryString, the encoding rules for the issuer field MUST be 1013 implemented. Implementations of this specification MUST be prepared 1014 to receive subject names containing the attribute types required for 1015 the issuer field. Implementations of this specification SHOULD be 1016 prepared to receive subject names containing the recommended attri- 1017 bute types for the issuer field. The syntax and associated object 1018 identifiers (OIDs) for these attribute types are provided in the 1019 ASN.1 modules in Appendices A and B. Implementations of this 1020 specification MAY use these comparison rules to process unfamiliar 1021 attribute types (i.e., for name chaining). This allows implementa- 1022 tions to process certificates with unfamiliar attributes in the sub- 1023 ject name. 1025 In addition, legacy implementations exist where an RFC 822 name is 1026 embedded in the subject distinguished name as an EmailAddress attri- 1027 bute. The attribute value for EmailAddress is of type IA5String to 1028 permit inclusion of the character '@', which is not part of the 1029 PrintableString character set. EmailAddress attribute values are not 1030 case sensitive (e.g., "fanfeedback@redsox.com" is the same as 1031 "FANFEEDBACK@REDSOX.COM"). 1033 Conforming implementations generating new certificates with elec- 1034 tronic mail addresses MUST use the rfc822Name in the subject alterna- 1035 tive name field (see sec. 4.2.1.7) to describe such identities. 1036 Simultaneous inclusion of the EmailAddress attribute in the subject 1037 distinguished name to support legacy implementations is deprecated 1038 but permitted. 1040 4.1.2.7 Subject Public Key Info 1042 This field is used to carry the public key and identify the algorithm 1043 with which the key is used. The algorithm is identified using the 1044 AlgorithmIdentifier structure specified in section 4.1.1.2. The 1045 object identifiers for the supported algorithms and the methods for 1046 encoding the public key materials (public key and parameters) are 1047 specified in section 7.3. 1049 4.1.2.8 Unique Identifiers 1051 These fields may only appear if the version is 2 or 3 (see sec. 1052 4.1.2.1). The subject and issuer unique identifiers are present in 1053 the certificate to handle the possibility of reuse of subject and/or 1054 issuer names over time. This profile recommends that names not be 1055 reused for different entities and that Internet certificates not make 1056 use of unique identifiers. CAs conforming to this profile SHOULD NOT 1057 generate certificates with unique identifiers. Applications conform- 1058 ing to this profile SHOULD be capable of parsing unique identifiers 1059 and making comparisons. 1061 4.1.2.9 Extensions 1063 This field may only appear if the version is 3 (see sec. 4.1.2.1). 1064 If present, this field is a SEQUENCE of one or more certificate 1065 extensions. The format and content of certificate extensions in the 1066 Internet PKI is defined in section 4.2. 1068 4.2 Standard Certificate Extensions 1070 The extensions defined for X.509 v3 certificates provide methods for 1071 associating additional attributes with users or public keys and for 1072 managing the certification hierarchy. The X.509 v3 certificate for- 1073 mat also allows communities to define private extensions to carry 1074 information unique to those communities. Each extension in a certi- 1075 ficate may be designated as critical or non-critical. A certificate 1076 using system MUST reject the certificate if it encounters a critical 1077 extension it does not recognize; however, a non-critical extension 1078 may be ignored if it is not recognized. The following sections 1079 present recommended extensions used within Internet certificates and 1080 standard locations for information. Communities may elect to use 1081 additional extensions; however, caution should be exercised in adopt- 1082 ing any critical extensions in certificates which might prevent use 1083 in a general context. 1085 Each extension includes an OID and an ASN.1 structure. When an 1086 extension appears in a certificate, the OID appears as the field 1087 extnID and the corresponding ASN.1 encoded structure is the value of 1088 the octet string extnValue. Only one instance of a particular exten- 1089 sion may appear in a particular certificate. For example, a certifi- 1090 cate may contain only one authority key identifier extension (see 1091 sec. 4.2.1.1). An extension includes the boolean critical, with a 1092 default value of FALSE. The text for each extension specifies the 1093 acceptable values for the critical field. 1095 Conforming CAs MUST support key identifiers (see sec. 4.2.1.1 and 1096 4.2.1.2), basic constraints (see sec. 4.2.1.10), key usage (see sec. 1097 4.2.1.3), and certificate policies (see sec. 4.2.1.5) extensions. If 1098 the CA issues certificates with an empty sequence for the subject 1099 field, the CA MUST support the subject alternative name extension 1100 (see sec. 4.2.1.7). Support for the remaining extensions is 1101 OPTIONAL. Conforming CAs may support extensions that are not identi- 1102 fied within this specification; certificate issuers are cautioned 1103 that marking such extensions as critical may inhibit interoperabil- 1104 ity. 1106 At a minimum, applications conforming to this profile MUST recognize 1107 the extensions which must or may be critical in this specification. 1108 These extensions are: key usage (see sec. 4.2.1.3), certificate pol- 1109 icies (see sec. 4.2.1.5), the subject alternative name (see sec. 1110 4.2.1.7), basic constraints (see sec. 4.2.1.10), name constraints 1111 (see sec. 4.2.1.11), policy constraints (see sec. 4.2.1.12), and 1112 extended key usage (see sec. 4.2.1.13). 1114 In addition, this profile RECOMMENDS application support for the 1115 authority and subject key identifier (see sec. 4.2.1.1 and 4.2.1.2) 1116 extensions. 1118 4.2.1 Standard Extensions 1120 This section identifies standard certificate extensions defined in 1121 [X.509] for use in the Internet PKI. Each extension is associated 1122 with an OID defined in [X.509]. These OIDs are members of the id-ce 1123 arc, which is defined by the following: 1125 id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 1127 4.2.1.1 Authority Key Identifier 1129 The authority key identifier extension provides a means of identify- 1130 ing the public key corresponding to the private key used to sign a 1131 certificate. This extension is used where an issuer has multiple 1132 signing keys (either due to multiple concurrent key pairs or due to 1133 changeover). The identification may be based on either the key iden- 1134 tifier (the subject key identifier in the issuer's certificate) or on 1135 the issuer name and serial number. 1137 The keyIdentifier field of the authorityKeyIdentifier extension MUST 1138 be included in all certificates generated by conforming CAs to facil- 1139 itate chain building. There is one exception; where a CA distributes 1140 its public key in the form of a "self-signed" certificate, the 1141 authority key identifier may be omitted. In this case, the subject 1142 and authority key identifiers would be identical. 1144 The value of the keyIdentifier field SHOULD be derived from the pub- 1145 lic key used to verify the certificate's signature or a method that 1146 generates unique values. Two common methods for generating key iden- 1147 tifiers from the public key are described in (sec. 4.2.1.2). One com- 1148 mon method for generating unique values isdescribed in (sec. 1149 4.2.1.2). Where a key identifier has not been previously esta- 1150 blished, this specification recommends use of one of these methods 1151 for generating keyIdentifiers. 1153 This profile recommends support for the key identifier method by all 1154 certificate users. 1156 This extension MUST NOT be marked critical. 1158 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 1160 AuthorityKeyIdentifier ::= SEQUENCE { 1161 keyIdentifier [0] KeyIdentifier OPTIONAL, 1162 authorityCertIssuer [1] GeneralNames OPTIONAL, 1163 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 1165 KeyIdentifier ::= OCTET STRING 1167 4.2.1.2 Subject Key Identifier 1169 The subject key identifier extension provides a means of identifying 1170 certificates that contain a particular public key. 1172 To facilitate chain building, this extension MUST appear in all con- 1173 forming CA certificates, that is, all certificates including the 1174 basic constraints extension (see sec. 4.2.1.10) where the value of cA 1175 is TRUE. The value of the subject key identifier MUST be the value 1176 placed in the key identifier field of the Authority Key Identifier 1177 extension (see sec. 4.2.1.1) of certificates issued by the subject of 1178 this certificate. 1180 For CA certificates, subject key identifiers SHOULD be derived from 1181 the public key or a method that generates unique values. Two common 1182 methods for generating key identifiers from the public key are: 1184 (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the 1185 value of the BIT STRING subjectPublicKey (excluding the tag, 1186 length, and number of unused bits). 1188 (2) The keyIdentifier is composed of a four bit type field with 1189 the value 0100 followed by the least significant 60 bits of the 1190 SHA-1 hash of the value of the BIT STRING subjectPublicKey. 1192 One common method for generating unique values is a monotomically 1193 increasing sequence of integers. 1195 For end entity certificates, the subject key identifier extension 1196 provides a means for identifying certificates containing the particu- 1197 lar public key used in an application. Where an end entity has 1198 obtained multiple certificates, especially from multiple CAs, the 1199 subject key identifier provides a means to quickly identify the set 1200 of certificates containing a particular public key. To assist appli- 1201 cations in identificiation the appropriate end entity certificate, 1202 this extension SHOULD be included in all end entity certificates. 1204 For end entity certificates, subject key identifiers SHOULD be 1205 derived from the public key. Two common methods for generating key 1206 identifiers from the public key are identifed above. 1208 Where a key identifier has not been previously established, this 1209 specification recommends use of one of these methods for generating 1210 keyIdentifiers. 1212 This extension MUST NOT be marked critical. 1214 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 1216 SubjectKeyIdentifier ::= KeyIdentifier 1218 4.2.1.3 Key Usage 1220 The key usage extension defines the purpose (e.g., encipherment, sig- 1221 nature, certificate signing) of the key contained in the certificate. 1222 The usage restriction might be employed when a key that could be used 1223 for more than one operation is to be restricted. For example, when 1224 an RSA key should be used only for signing, the digitalSignature 1225 and/or nonRepudiation bits would be asserted. Likewise, when an RSA 1226 key should be used only for key management, the keyEncipherment bit 1227 would be asserted. When used, this extension SHOULD be marked criti- 1228 cal. 1230 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 1232 KeyUsage ::= BIT STRING { 1233 digitalSignature (0), 1234 nonRepudiation (1), 1235 keyEncipherment (2), 1236 dataEncipherment (3), 1237 keyAgreement (4), 1238 keyCertSign (5), 1239 cRLSign (6), 1240 encipherOnly (7), 1241 decipherOnly (8) } 1243 Bits in the KeyUsage type are used as follows: 1245 The digitalSignature bit is asserted when the subject public key 1246 is used with a digital signature mechanism to support security 1247 services other than non-repudiation (bit 1), certificate signing 1248 (bit 5), or revocation information signing (bit 6). Digital signa- 1249 ture mechanisms are often used for entity authentication and data 1250 origin authentication with integrity. 1252 The nonRepudiation bit is asserted when the subject public key is 1253 used to verify digital signatures used to provide a non- 1254 repudiation service which protects against the signing entity 1255 falsely denying some action, excluding certificate or CRL signing. 1257 The keyEncipherment bit is asserted when the subject public key is 1258 used for key transport. For example, when an RSA key is to be 1259 used for key management, then this bit shall asserted. 1261 The dataEncipherment bit is asserted when the subject public key 1262 is used for enciphering user data, other than cryptographic keys. 1264 The keyAgreement bit is asserted when the subject public key is 1265 used for key agreement. For example, when a Diffie-Hellman key is 1266 to be used for key management, then this bit shall asserted. 1268 The keyCertSign bit is asserted when the subject public key is 1269 used for verifying a signature on certificates. This bit may only 1270 be asserted in CA certificates. 1272 The cRLSign bit is asserted when the subject public key is used 1273 for verifying a signature on revocation information (e.g., a CRL). 1275 The meaning of the encipherOnly bit is undefined in the absence of 1276 the keyAgreement bit. When the encipherOnly bit is asserted and 1277 the keyAgreement bit is also set, the subject public key may be 1278 used only for enciphering data while performing key agreement. 1280 The meaning of the decipherOnly bit is undefined in the absence of 1281 the keyAgreement bit. When the decipherOnly bit is asserted and 1282 the keyAgreement bit is also set, the subject public key may be 1283 used only for deciphering data while performing key agreement. 1285 This profile does not restrict the combinations of bits that may be 1286 set in an instantiation of the keyUsage extension. However, 1287 appropriate values for keyUsage extensions for particular algorithms 1288 are specified in section 7.3. 1290 4.2.1.4 Private Key Usage Period 1292 This profile recommends against the use of this extension. CAs con- 1293 forming to this profile MUST NOT generate certificates with critical 1294 private key usage period extensions. 1296 The private key usage period extension allows the certificate issuer 1297 to specify a different validity period for the private key than the 1298 certificate. This extension is intended for use with digital signa- 1299 ture keys. This extension consists of two optional components, 1300 notBefore and notAfter. The private key associated with the certifi- 1301 cate should not be used to sign objects before or after the times 1302 specified by the two components, respectively. CAs conforming to this 1303 profile MUST NOT generate certificates with private key usage period 1304 extensions unless at least one of the two components is present. 1306 Where used, notBefore and notAfter are represented as GeneralizedTime 1307 and MUST be specified and interpreted as defined in section 1308 4.1.2.5.2. 1310 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 1312 PrivateKeyUsagePeriod ::= SEQUENCE { 1313 notBefore [0] GeneralizedTime OPTIONAL, 1314 notAfter [1] GeneralizedTime OPTIONAL } 1316 4.2.1.5 Certificate Policies 1318 The certificate policies extension contains a sequence of one or more 1319 policy information terms, each of which consists of an object iden- 1320 tifier (OID) and optional qualifiers. These policy information terms 1321 indicate the policy under which the certificate has been issued and 1322 the purposes for which the certificate may be used. Optional qualif- 1323 iers, which may be present, are not expected to change the definition 1324 of the policy. 1326 Applications with specific policy requirements are expected to have a 1327 list of those policies which they will accept and to compare the pol- 1328 icy OIDs in the certificate to that list. If this extension is crit- 1329 ical, the path validation software MUST be able to interpret this 1330 extension (including the optional qualifier), or MUST reject the cer- 1331 tificate. 1333 To promote interoperability, this profile RECOMMENDS that policy 1334 information terms consist of only an OID. Where an OID alone is 1335 insufficient, this profile strongly recommends that use of qualifiers 1336 be limited to those identified in this section. 1338 This specification defines two policy qualifier types for use by cer- 1339 tificate policy writers and certificate issuers. The qualifier types 1340 are the CPS Pointer and User Notice qualifiers. 1342 The CPS Pointer qualifier contains a pointer to a Certification Prac- 1343 tice Statement (CPS) published by the CA. The pointer is in the form 1344 of a URI. 1346 User notice is intended for display to a relying party when a certi- 1347 ficate is used. The application software SHOULD display all user 1348 notices in all certificates of the certification path used, except 1349 that if a notice is duplicated only one copy need be displayed. To 1350 prevent such duplication, this qualifier SHOULD only be present in 1351 end-entity certificates and CA certificates issued to other organiza- 1352 tions. 1354 The user notice has two optional fields: the noticeRef field and the 1355 explicitText field. 1357 The noticeRef field, if used, names an organization and 1358 identifies, by number, a particular textual statement prepared by 1359 that organization. For example, it might identify the organiza- 1360 tion "CertsRUs" and notice number 1. In a typical implementation, 1361 the application software will have a notice file containing the 1362 current set of notices for CertsRUs; the application will extract 1363 the notice text from the file and display it. Messages may be 1364 multilingual, allowing the software to select the particular 1365 language message for its own environment. 1367 An explicitText field includes the textual statement directly in 1368 the certificate. The explicitText field is a string with a max- 1369 imum size of 200 characters. 1371 If both the noticeRef and explicitText options are included in the 1372 one qualifier and if the application software can locate the notice 1373 text indicated by the noticeRef option then that text should be 1374 displayed; otherwise, the explicitText string should be displayed. 1376 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 1378 certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 1380 PolicyInformation ::= SEQUENCE { 1381 policyIdentifier CertPolicyId, 1382 policyQualifiers SEQUENCE SIZE (1..MAX) OF 1383 PolicyQualifierInfo OPTIONAL } 1385 CertPolicyId ::= OBJECT IDENTIFIER 1387 PolicyQualifierInfo ::= SEQUENCE { 1388 policyQualifierId PolicyQualifierId, 1389 qualifier ANY DEFINED BY policyQualifierId } 1391 -- policyQualifierIds for Internet policy qualifiers 1393 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 1394 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 1395 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 1397 PolicyQualifierId ::= 1398 OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) 1400 Qualifier ::= CHOICE { 1401 cPSuri CPSuri, 1402 userNotice UserNotice } 1404 CPSuri ::= IA5String 1405 UserNotice ::= SEQUENCE { 1406 noticeRef NoticeReference OPTIONAL, 1407 explicitText DisplayText OPTIONAL} 1409 NoticeReference ::= SEQUENCE { 1410 organization DisplayText, 1411 noticeNumbers SEQUENCE OF INTEGER } 1413 DisplayText ::= CHOICE { 1414 visibleString VisibleString (SIZE (1..200)), 1415 bmpString BMPString (SIZE (1..200)), 1416 utf8String UTF8String (SIZE (1..200)) } 1418 4.2.1.6 Policy Mappings 1420 This extension is used in CA certificates. It lists one or more 1421 pairs of OIDs; each pair includes an issuerDomainPolicy and a sub- 1422 jectDomainPolicy. The pairing indicates the issuing CA considers its 1423 issuerDomainPolicy equivalent to the subject CA's subjectDomainPol- 1424 icy. 1426 The issuing CA's users may accept an issuerDomainPolicy for certain 1427 applications. The policy mapping tells the issuing CA's users which 1428 policies associated with the subject CA are comparable to the policy 1429 they accept. 1431 This extension may be supported by CAs and/or applications, and it 1432 MUST be non-critical. 1434 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 1436 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 1437 issuerDomainPolicy CertPolicyId, 1438 subjectDomainPolicy CertPolicyId } 1440 4.2.1.7 Subject Alternative Name 1442 The subject alternative names extension allows additional identities 1443 to be bound to the subject of the certificate. Defined options 1444 include an Internet electronic mail address, a DNS name, an IP 1445 address, and a uniform resource identifier (URI). Other options 1446 exist, including completely local definitions. Multiple name forms, 1447 and multiple instances of each name form, may be included. Whenever 1448 such identities are to be bound into a certificate, the subject 1449 alternative name (or issuer alternative name) extension MUST be used. 1451 Because the subject alternative name is considered to be defini- 1452 tiviely bound to the public key, all parts of the subject alternative 1453 name MUST be verified by the CA. 1455 Further, if the only subject identity included in the certificate is 1456 an alternative name form (e.g., an electronic mail address), then the 1457 subject distinguished name MUST be empty (an empty sequence), and the 1458 subjectAltName extension MUST be present. If the subject field con- 1459 tains an empty sequence, the subjectAltName extension MUST be marked 1460 critical. 1462 When the subjectAltName extension contains an Internet mail address, 1463 the address MUST be included as an rfc822Name. The format of an 1464 rfc822Name is an "addr-spec" as defined in RFC 822 [RFC 822]. An 1465 addr-spec has the form "local-part@domain". Note that an addr-spec 1466 has no phrase (such as a common name) before it, has no comment (text 1467 surrounded in parentheses) after it, and is not surrounded by "<" and 1468 ">". Note that while upper and lower case letters are allowed in an 1469 RFC 822 addr-spec, no significance is attached to the case. 1471 When the subjectAltName extension contains a iPAddress, the address 1472 MUST be stored in the octet string in "network byte order," as speci- 1473 fied in RFC 791 [RFC 791]. The least significant bit (LSB) of each 1474 octet is the LSB of the corresponding byte in the network address. 1475 For IP Version 4, as specified in RFC 791, the octet string MUST con- 1476 tain exactly four octets. For IP Version 6, as specified in RFC 1477 1883, the octet string MUST contain exactly sixteen octets [RFC 1478 1883]. 1480 When the subjectAltName extension contains a domain name service 1481 label, the domain name MUST be stored in the dNSName (an IA5String). 1482 The name MUST be in the "preferred name syntax," as specified by RFC 1483 1034 [RFC 1034]. Note that while upper and lower case letters are 1484 allowed in domain names, no signifigance is attached to the case. In 1485 addition, while the string " " is a legal domain name, subjectAltName 1486 extensions with a dNSName " " are not permitted. Finally, the use of 1487 the DNS representation for Internet mail addresses (wpolk.nist.gov 1488 instead of wpolk@nist.gov) is not permitted; such identities are to 1489 be encoded as rfc822Name. 1491 When the subjectAltName extension contains a URI, the name MUST be 1492 stored in the uniformResourceIdentifier (an IA5String). The name MUST 1493 be a non-relative URL, and MUST follow the URL syntax and encoding 1494 rules specified in [RFC 1738]. The name must include both a scheme 1495 (e.g., "http" or "ftp") and a scheme-specific-part. The scheme- 1496 specific-part must include a fully qualified domain name or IP 1497 address as the host. 1499 As specified in [RFC 1738], the scheme name is not case-sensitive 1500 (e.g., "http" is equivalent to "HTTP"). The host part is also not 1501 case-sensitive, but other components of the scheme-specific-part may 1502 be case-sensitive. When comparing URIs, conforming implementations 1503 MUST compare the scheme and host without regard to case, but assume 1504 the remainder of the scheme-specific-part is case sensitive. 1506 Subject alternative names may be constrained in the same manner as 1507 subject distinguished names using the name constraints extension as 1508 described in section 4.2.1.11. 1510 If the subjectAltName extension is present, the sequence MUST contain 1511 at least one entry. Unlike the subject field, conforming CAs MUST 1512 NOT issue certificates with subjectAltNames containing empty General- 1513 Name fields. For example, an rfc822Name is represented as an 1514 IA5String. While an empty string is a valid IA5String, such an 1515 rfc822Name is not permitted by this profile. The behavior of clients 1516 that encounter such a certificate when processing a certificication 1517 path is not defined by this profile. 1519 Finally, the semantics of subject alternative names that include 1520 wildcard characters (e.g., as a placeholder for a set of names) are 1521 not addressed by this specification. Applications with specific 1522 requirements may use such names but shall define the semantics. 1524 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 1526 SubjectAltName ::= GeneralNames 1528 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 1530 GeneralName ::= CHOICE { 1531 otherName [0] OtherName, 1532 rfc822Name [1] IA5String, 1533 dNSName [2] IA5String, 1534 x400Address [3] ORAddress, 1535 directoryName [4] Name, 1536 ediPartyName [5] EDIPartyName, 1537 uniformResourceIdentifier [6] IA5String, 1538 iPAddress [7] OCTET STRING, 1539 registeredID [8] OBJECT IDENTIFIER} 1541 OtherName ::= SEQUENCE { 1542 type-id OBJECT IDENTIFIER, 1543 value [0] EXPLICIT ANY DEFINED BY type-id } 1545 EDIPartyName ::= SEQUENCE { 1546 nameAssigner [0] DirectoryString OPTIONAL, 1547 partyName [1] DirectoryString } 1549 4.2.1.8 Issuer Alternative Names 1551 As with 4.2.1.7, this extension is used to associate Internet style 1552 identities with the certificate issuer. Issuer alternative names MUST 1553 be encoded as in 4.2.1.7. 1555 Where present, this extension SHOULD NOT be marked critical. 1557 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 1559 IssuerAltName ::= GeneralNames 1561 4.2.1.9 Subject Directory Attributes 1563 The subject directory attributes extension is not recommended as an 1564 essential part of this profile, but it may be used in local environ- 1565 ments. This extension MUST be non-critical. 1567 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 1569 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 1571 4.2.1.10 Basic Constraints 1573 The basic constraints extension identifies whether the subject of the 1574 certificate is a CA and how deep a certification path may exist 1575 through that CA. 1577 The pathLenConstraint field is meaningful only if cA is set to TRUE. 1578 In this case, it gives the maximum number of CA certificates that may 1579 follow this certificate in a certification path. A value of zero 1580 indicates that only an end-entity certificate may follow in the path. 1581 Where it appears, the pathLenConstraint field MUST be greater than or 1582 equal to zero. Where pathLenConstraint does not appear, there is no 1583 limit to the allowed length of the certification path. 1585 This extension MUST appear as a critical extension in all CA certifi- 1586 cates. This extension SHOULD NOT appear in end entity certificates. 1588 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 1590 BasicConstraints ::= SEQUENCE { 1591 cA BOOLEAN DEFAULT FALSE, 1592 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 1594 4.2.1.11 Name Constraints 1596 The name constraints extension, which MUST be used only in a CA cer- 1597 tificate, indicates a name space within which all subject names in 1598 subsequent certificates in a certification path shall be located. 1599 Restrictions may apply to the subject distinguished name or subject 1600 alternative names. Restrictions apply only when the specified name 1601 form is present. If no name of the type is in the certificate, the 1602 certificate is acceptable. 1604 Restrictions are defined in terms of permitted or excluded name sub- 1605 trees. Any name matching a restriction in the excludedSubtrees field 1606 is invalid regardless of information appearing in the permittedSub- 1607 trees. This extension MUST be critical. 1609 Within this profile, the minimum and maximum fields are not used with 1610 any name forms, thus minimum is always zero, and maximum is always 1611 absent. 1613 For URIs, the constraint applies to the host part of the name. The 1614 constraint may specify a host or a domain. Examples would be 1615 "foo.bar.com"; and ".xyz.com". When the the constraint begins with 1616 a period, it may be expanded with one or more subdomains. That is, 1617 the constraint ".xyz.com" is satisfied by both abc.xyz.com and 1618 abc.def.xyz.com. However, the constraint ".xyz.com" is not satisfied 1619 by "xyz.com". When the constraint does not begin with a period, it 1620 specifies a host. 1622 A name constraint for Internat mail addresses may specify a particu- 1623 lar mailbox, all addresses at a particular host, or all mailboxes in 1624 a domain. To indicate a particular mailbox, the constraint is the 1625 complete mail address. For example, "root@xyz.com" indicates the 1626 root mailbox on the host "xyz.com". To indicate all Internet mail 1627 addresses on a particular host, the constraint is specified as the 1628 host name. For example, the constraint "xyz.com" is satisfied by any 1629 mail address at the host "xyz.com". To specify any address within a 1630 domain, the constraint is specified with a leading period (as with 1631 URIs). For example, ".xyz.com" indicates all the Internet mail 1632 addresses in the domain "xyz.com", but Internet mail addresses on the 1633 host "xyz.com". 1635 DNS name restrictions are expressed as foo.bar.com. Any DNS name that 1636 can be constructed by simply adding to the left hand side of the name 1637 satisfies the name constraint. For example, www.foo.bar.com would 1638 satisfy the constraint but foo1.bar.com would not. 1640 Legacy implementations exist where an RFC 822 name is embedded in the 1641 subject distinguished name in an attribute of type EmailAddress (see 1642 sec. 4.1.2.6). When rfc822 names are constrained, but the certificate 1643 does not include a subject alternative name, the rfc822 name con- 1644 straint MUST be applied to the attribute of type EmailAddress in the 1645 subject distinguished name. The ASN.1 syntax for EmailAddress and 1646 the corresponding OID are supplied in Appendix A and B. 1648 Restrictions of the form directoryName MUST be applied to the subject 1649 field in the certificate and to the subjectAltName extensions of type 1650 directoryName. Restrictions of the form x400Address MUST be applied 1651 to subjectAltName extensions of type x400Address. 1653 When applying restrictions of the form directoryName, an implementa- 1654 tion MUST compare DN attributes. At a minimum, implementations MUST 1655 perform the DN comparison rules specified in Section 4.1.2.4. CAs 1656 issuing certificates with a restriction of the form directoryName 1657 SHOULD NOT rely on implementation of the full ISO DN name comparison 1658 algorithm. This implies name restrictions shall be stated identi- 1659 cally to the encoding used in the subject field or subjectAltName 1660 extension. 1662 The syntax of iPAddress MUST be as described in section 4.2.1.7 with 1663 the following additions specifically for Name Constraints. For IPv4 1664 addresses, the ipAddress field of generalName MUST contain eight (8) 1665 octets, encoded in the style of RFC 1519 (CIDR) to represent an 1666 address range.[RFC 1519] For IPv6 addresses, the ipAddress field 1667 MUST contain 32 octets similarly encoded. For example, a name con- 1668 straint for "class C" subnet 10.9.8.0 shall be represented as the 1669 octets 0A 09 08 00 FF FF FF 00, representing the CIDR notation 1670 10.9.8.0/255.255.255.0. 1672 The syntax and semantics for name constraints for otherName, ediPar- 1673 tyName, and registeredID are not defined by this specification. 1675 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 1677 NameConstraints ::= SEQUENCE { 1678 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 1679 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 1681 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 1683 GeneralSubtree ::= SEQUENCE { 1684 base GeneralName, 1685 minimum [0] BaseDistance DEFAULT 0, 1686 maximum [1] BaseDistance OPTIONAL } 1688 BaseDistance ::= INTEGER (0..MAX) 1690 4.2.1.12 Policy Constraints 1692 The policy constraints extension can be used in certificates issued 1693 to CAs. The policy constraints extension constrains path validation 1694 in two ways. It can be used to prohibit policy mapping or require 1695 that each certificate in a path contain an acceptable policy identif- 1696 ier. 1698 If the inhibitPolicyMapping field is present, the value indicates the 1699 number of additional certificates that may appear in the path before 1700 policy mapping is no longer permitted. For example, a value of one 1701 indicates that policy mapping may be processed in certificates issued 1702 by the subject of this certificate, but not in additional certifi- 1703 cates in the path. 1705 If the requireExplicitPolicy field is present, subsequent certifi- 1706 cates shall include an acceptable policy identifier. The value of 1707 requireExplicitPolicy indicates the number of additional certificates 1708 that may appear in the path before an explicit policy is required. 1709 An acceptable policy identifier is the identifier of a policy 1710 required by the user of the certification path or the identifier of a 1711 policy which has been declared equivalent through policy mapping. 1713 Conforming CAs MUST NOT issue certificates where policy constraints 1714 is a null sequence. That is, at least one of the inhibitPolicyMapping 1715 field or the requireExplicitPolicy field MUST be present. The 1716 behavior of clients that encounter a null policy constraints field is 1717 not addressed in this profile. 1719 This extension may be critical or non-critical. 1721 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } 1723 PolicyConstraints ::= SEQUENCE { 1724 requireExplicitPolicy [0] SkipCerts OPTIONAL, 1725 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 1727 SkipCerts ::= INTEGER (0..MAX) 1729 4.2.1.13 Extended key usage field 1731 This field indicates one or more purposes for which the certified 1732 public key may be used, in addition to or in place of the basic pur- 1733 poses indicated in the key usage extension field. This field is 1734 defined as follows: 1736 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 1737 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 1739 KeyPurposeId ::= OBJECT IDENTIFIER 1741 Key purposes may be defined by any organization with a need. Object 1742 identifiers used to identify key purposes shall be assigned in accor- 1743 dance with IANA or ITU-T Rec. X.660 | ISO/IEC/ITU 9834-1. 1745 This extension may, at the option of the certificate issuer, be 1746 either critical or non-critical. 1748 If the extension is flagged critical, then the certificate MUST be 1749 used only for one of the purposes indicated. 1751 If the extension is flagged non-critical, then it indicates the 1752 intended purpose or purposes of the key, and may be used in finding 1753 the correct key/certificate of an entity that has multiple 1754 keys/certificates. It is an advisory field and does not imply that 1755 usage of the key is restricted by the certification authority to the 1756 purpose indicated. Certificate using applications may nevertheless 1757 require that a particular purpose be indicated in order for the cer- 1758 tificate to be acceptable to that application. 1760 If a certificate contains both a critical key usage field and a crit- 1761 ical extended key usage field, then both fields MUST be processed 1762 independently and the certificate MUST only be used for a purpose 1763 consistent with both fields. If there is no purpose consistent with 1764 both fields, then the certificate MUST NOT be used for any purpose. 1766 The following key usage purposes are defined by this profile: 1768 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 1770 id-kp-serverAuth OBJECT IDENTIFIER ::= {id-kp 1} 1771 -- TLS Web server authentication 1772 -- Key usage bits that may be consistent: digitalSignature, 1773 -- keyEncipherment or keyAgreement 1774 -- 1775 id-kp-clientAuth OBJECT IDENTIFIER ::= {id-kp 2} 1776 -- TLS Web client authentication 1777 -- Key usage bits that may be consistent: digitalSignature and/or 1778 -- keyAgreement 1779 -- 1780 id-kp-codeSigning OBJECT IDENTIFIER ::= {id-kp 3} 1781 -- Signing of downloadable executable code 1782 -- Key usage bits that may be consistent: digitalSignature 1783 -- 1784 id-kp-emailProtection OBJECT IDENTIFIER ::= {id-kp 4} 1785 -- E-mail protection 1786 -- Key usage bits that may be consistent: digitalSignature, 1787 -- nonRepudiation, and/or (keyEncipherment 1788 -- or keyAgreement) 1789 -- 1790 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 1791 -- Binding the hash of an object to a time from an agreed-upon time 1792 -- source. Key usage bits that may be consistent: digitalSignature, 1793 -- nonRepudiation 1795 4.2.1.14 CRL Distribution Points 1797 The CRL distribution points extension identifies how CRL information 1798 is obtained. The extension SHOULD be non-critical, but this profile 1799 recommends support for this extension by CAs and applications. 1800 Further discussion of CRL management is contained in section 5. 1802 If the cRLDistributionPoints extension contains a Distribution- 1803 PointName of type URI, the following semantics MUST be assumed: the 1804 URI is a pointer to the current CRL for the associated reasons and 1805 will be issued by the associated cRLIssuer. The expected values for 1806 the URI are those defined in 4.2.1.7. Processing rules for other 1807 values are not defined by this specification. If the distribution- 1808 Point omits reasons, the CRL MUST include revocations for all rea- 1809 sons. If the distributionPoint omits cRLIssuer, the CRL MUST be 1810 issued by the CA that issued the certificate. 1812 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 } 1814 cRLDistributionPoints ::= { 1815 CRLDistPointsSyntax } 1817 CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 1819 DistributionPoint ::= SEQUENCE { 1820 distributionPoint [0] DistributionPointName OPTIONAL, 1821 reasons [1] ReasonFlags OPTIONAL, 1822 cRLIssuer [2] GeneralNames OPTIONAL } 1824 DistributionPointName ::= CHOICE { 1825 fullName [0] GeneralNames, 1826 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 1828 ReasonFlags ::= BIT STRING { 1829 unused (0), 1830 keyCompromise (1), 1831 cACompromise (2), 1832 affiliationChanged (3), 1833 superseded (4), 1834 cessationOfOperation (5), 1835 certificateHold (6) } 1837 4.2.2 Private Internet Extensions 1839 This section defines one new extension for use in the Internet Public 1840 Key Infrastructure. This extension may be used to direct applica- 1841 tions to identify an on-line validation service supporting the issu- 1842 ing CA. As the information may be available in multiple forms, each 1843 extension is a sequence of IA5String values, each of which represents 1844 a URI. The URI implicitly specifies the location and format of the 1845 information and the method for obtaining the information. 1847 An object identifier is defined for the private extension. The 1848 object identifier associated with the private extension is defined 1849 under the arc id-pe within the id-pkix name space. Any future exten- 1850 sions defined for the Internet PKI will also be defined under the arc 1851 id-pe. 1853 id-pkix OBJECT IDENTIFIER ::= 1854 { iso(1) identified-organization(3) dod(6) internet(1) 1855 security(5) mechanisms(5) pkix(7) } 1857 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 1859 4.2.2.1 Authority Information Access 1861 The authority information access extension indicates how to access CA 1862 information and services for the issuer of the certificate in which 1863 the extension appears. Information and services may include on-line 1864 validation services and CA policy data. (The location of CRLs is not 1865 specified in this extension; that information is provided by the 1866 cRLDistributionPoints extension.) This extension may be included in 1867 subject or CA certificates, and it MUST be non-critical. 1869 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 1871 AuthorityInfoAccessSyntax ::= 1872 SEQUENCE SIZE (1..MAX) OF AccessDescription 1874 AccessDescription ::= SEQUENCE { 1875 accessMethod OBJECT IDENTIFIER, 1876 accessLocation GeneralName } 1878 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 1880 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 1882 Each entry in the sequence AuthorityInfoAccessSyntax describes the 1883 format and location of additional information about the CA who issued 1884 the certificate in which this extension appears. The type and format 1885 of the information is specified by the accessMethod field; the 1886 accessLocation field specifies the location of the information. The 1887 retrieval mechanism may be implied by the accessMethod or specified 1888 by accessLocation. 1890 This profile defines one OID for accessMethod. The id-ad-caIssuers 1891 OID is used when the additional information lists CAs that have 1892 issued certificates superior to the CA that issued the certificate 1893 containing this extension. The referenced CA Issuers description is 1894 intended to aid certificate users in the selection of a certification 1895 path that terminates at a point trusted by the certificate user. 1897 When id-ad-caIssuers appears as accessInfoType, the accessLocation 1898 field describes the referenced description server and the access pro- 1899 tocol to obtain the referenced description. The accessLocation field 1900 is defined as a GeneralName, which can take several forms. Where the 1901 information is available via http, ftp, or ldap, accessLocation MUST 1902 be a uniformResourceIdentifier. Where the information is available 1903 via the directory access protocol (dap), accessLocation MUST be a 1904 directoryName. When the information is available via electronic mail, 1905 accessLocation MUST be an rfc822Name. The semantics of other name 1906 forms of accessLocation (when accessMethod is id-ad-caIssuers) are 1907 not defined by this specification. 1909 Additional access descriptors may be defined in other PKIX specifica- 1910 tions. 1912 5 CRL and CRL Extensions Profile 1914 As described above, one goal of this X.509 v2 CRL profile is to 1915 foster the creation of an interoperable and reusable Internet PKI. 1916 To achieve this goal, guidelines for the use of extensions are speci- 1917 fied, and some assumptions are made about the nature of information 1918 included in the CRL. 1920 CRLs may be used in a wide range of applications and environments 1921 covering a broad spectrum of interoperability goals and an even 1922 broader spectrum of operational and assurance requirements. This 1923 profile establishes a common baseline for generic applications 1924 requiring broad interoperability. The profile defines a baseline set 1925 of information that can be expected in every CRL. Also, the profile 1926 defines common locations within the CRL for frequently used attri- 1927 butes as well as common representations for these attributes. 1929 This profile does not define any private Internet CRL extensions or 1930 CRL entry extensions. 1932 Environments with additional or special purpose requirements may 1933 build on this profile or may replace it. 1935 Conforming CAs are not required to issue CRLs if other revocation or 1936 certificate status mechanisms are provided. Conforming CAs that 1937 issue CRLs MUST issue version 2 CRLs, and CAs MUST include the date 1938 by which the next CRL will be issued in the nextUpdate field (see 1939 sec. 5.1.2.5), the CRL number extension (see sec. 5.2.3) and the 1940 authority key identifier extension (see sec. 5.2.1). Conforming 1941 applications are required to process version 1 and 2 CRLs. 1943 5.1 CRL Fields 1945 The X.509 v2 CRL syntax is as follows. For signature calculation, 1946 the data that is to be signed is ASN.1 DER encoded. ASN.1 DER encod- 1947 ing is a tag, length, value encoding system for each element. 1949 CertificateList ::= SEQUENCE { 1950 tbsCertList TBSCertList, 1951 signatureAlgorithm AlgorithmIdentifier, 1952 signatureValue BIT STRING } 1954 TBSCertList ::= SEQUENCE { 1955 version Version OPTIONAL, 1956 -- if present, shall be v2 1957 signature AlgorithmIdentifier, 1958 issuer Name, 1959 thisUpdate Time, 1960 nextUpdate Time OPTIONAL, 1961 revokedCertificates SEQUENCE OF SEQUENCE { 1962 userCertificate CertificateSerialNumber, 1963 revocationDate Time, 1964 crlEntryExtensions Extensions OPTIONAL 1965 -- if present, shall be v2 1966 } OPTIONAL, 1967 crlExtensions [0] EXPLICIT Extensions OPTIONAL 1968 -- if present, shall be v2 1969 } 1971 -- Version, Time, CertificateSerialNumber, and Extensions 1972 -- are all defined in the ASN.1 in section 4.1 1974 -- AlgorithmIdentifier is defined in section 4.1.1.2 1976 The following items describe the use of the X.509 v2 CRL in the 1977 Internet PKI. 1979 5.1.1 CertificateList Fields 1981 The CertificateList is a SEQUENCE of three required fields. The 1982 fields are described in detail in the following subsections. 1984 5.1.1.1 tbsCertList 1986 The first field in the sequence is the tbsCertList. This field is 1987 itself a sequence containing the name of the issuer, issue date, 1988 issue date of the next list, the list of revoked certificates, and 1989 optional CRL extensions. Further, each entry on the revoked certifi- 1990 cate list is defined by a sequence of user certificate serial number, 1991 revocation date, and optional CRL entry extensions. 1993 5.1.1.2 signatureAlgorithm 1995 The signatureAlgorithm field contains the algorithm identifier for 1996 the algorithm used by the CA to sign the CertificateList. The field 1997 is of type AlgorithmIdentifier, which is defined in section 4.1.1.2. 1998 Section 7.2 lists the supported algorithms for this specification. 1999 Conforming CAs MUST use the algorithm identifiers presented in sec- 2000 tion 7.2 when signing with a supported signature algorithm. 2002 This field MUST contain the same algorithm identifier as the signa- 2003 ture field in the sequence tbsCertList (see sec. 5.1.2.2). 2005 5.1.1.3 signatureValue 2007 The signatureValue field contains a digital signature computed upon 2008 the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded tbsCertList 2009 is used as the input to the signature function. This signature value 2010 is then ASN.1 encoded as a BIT STRING and included in the CRL's sig- 2011 natureValue field. The details of this process are specified for each 2012 of the supported algorithms in section 7.2. 2014 5.1.2 Certificate List "To Be Signed" 2016 The certificate list to be signed, or TBSCertList, is a SEQUENCE of 2017 required and optional fields. The required fields identify the CRL 2018 issuer, the algorithm used to sign the CRL, the date and time the CRL 2019 was issued, and the date and time by which the CA will issue the next 2020 CRL. 2022 Optional fields include lists of revoked certificates and CRL exten- 2023 sions. The revoked certificate list is optional to support the case 2024 where a CA has not revoked any unexpired certificates that it has 2025 issued. The profile requires conforming CAs to use the CRL extension 2026 cRLNumber in all CRLs issued. 2028 5.1.2.1 Version 2030 This optional field describes the version of the encoded CRL. When 2031 extensions are used, as required by this profile, this field MUST be 2032 present and MUST specify version 2 (the integer value is 1). 2034 5.1.2.2 Signature 2036 This field contains the algorithm identifier for the algorithm used 2037 to sign the CRL. Section 7.2 lists OIDs for the most popular signa- 2038 ture algorithms used in the Internet PKI. 2040 This field MUST contain the same algorithm identifier as the signa- 2041 tureAlgorithm field in the sequence CertificateList (see section 2042 5.1.1.2). 2044 5.1.2.3 Issuer Name 2046 The issuer name identifies the entity who has signed and issued the 2047 CRL. The issuer identity is carried in the issuer name field. Alter- 2048 native name forms may also appear in the issuerAltName extension (see 2049 sec. 5.2.2). The issuer name field MUST contain an X.500 2050 distinguished name (DN). The issuer name field is defined as the 2051 X.501 type Name, and MUST follow the encoding rules for the issuer 2052 name field in the certificate (see sec. 4.1.2.4). 2054 5.1.2.4 This Update 2056 This field indicates the issue date of this CRL. ThisUpdate may be 2057 encoded as UTCTime or GeneralizedTime. 2059 CAs conforming to this profile that issue CRLs MUST encode thisUpdate 2060 as UTCTime for dates through the year 2049. CAs conforming to this 2061 profile that issue CRLs MUST encode thisUpdate as GeneralizedTime for 2062 dates in the year 2050 or later. 2064 Where encoded as UTCTime, thisUpdate MUST be specified and inter- 2065 preted as defined in section 4.1.2.5.1. Where encoded as General- 2066 izedTime, thisUpdate MUST be specified and interpreted as defined in 2067 section 4.1.2.5.2. 2069 5.1.2.5 Next Update 2071 This field indicates the date by which the next CRL will be issued. 2072 The next CRL could be issued before the indicated date, but it will 2073 not be issued any later than the indicated date. CAs SHOULD issue 2074 CRLs with a nextUpdate time equal to or later than all previous CRLs. 2075 nextUpdate may be encoded as UTCTime or GeneralizedTime. 2077 This profile requires inclusion of nextUpdate in all CRLs issued by 2078 conforming CAs. Note that the ASN.1 syntax of TBSCertList describes 2079 this field as OPTIONAL, which is consistent with the ASN.1 structure 2080 defined in [X.509]. The behavior of clients processing CRLs which 2081 omit nextUpdate is not specified by this profile. 2083 CAs conforming to this profile that issue CRLs MUST encode nextUpdate 2084 as UTCTime for dates through the year 2049. CAs conforming to this 2085 profile that issue CRLs MUST encode nextUpdate as GeneralizedTime for 2086 dates in the year 2050 or later. 2088 Where encoded as UTCTime, nextUpdate MUST be specified and inter- 2089 preted as defined in section 4.1.2.5.1. Where encoded as General- 2090 izedTime, nextUpdate MUST be specified and interpreted as defined in 2091 section 4.1.2.5.2. 2093 5.1.2.6 Revoked Certificates 2095 Revoked certificates are listed. The revoked certificates are named 2096 by their serial numbers. Certificates revoked by the CA are uniquely 2097 identified by the certificate serial number. The date on which the 2098 revocation occurred is specified. The time for revocationDate MUST 2099 be expressed as described in section 5.1.2.4. Additional information 2100 may be supplied in CRL entry extensions; CRL entry extensions are 2101 discussed in section 5.3. 2103 5.1.2.7 Extensions 2105 This field may only appear if the version is 2 (see sec. 5.1.2.1). 2106 If present, this field is a SEQUENCE of one or more CRL extensions. 2107 CRL extensions are discussed in section 5.2. 2109 5.2 CRL Extensions 2111 The extensions defined by ANSI X9 and ISO/IEC/ITU for X.509 v2 CRLs 2112 [X.509] [X9.55] provide methods for associating additional attributes 2113 with CRLs. The X.509 v2 CRL format also allows communities to define 2114 private extensions to carry information unique to those communities. 2115 Each extension in a CRL may be designated as critical or non- 2116 critical. A CRL validation MUST fail if it encounters a critical 2117 extension which it does not know how to process. However, an 2118 unrecognized non-critical extension may be ignored. The following 2119 subsections present those extensions used within Internet CRLs. Com- 2120 munities may elect to include extensions in CRLs which are not 2121 defined in this specification. However, caution should be exercised 2122 in adopting any critical extensions in CRLs which might be used in a 2123 general context. 2125 Conforming CAs that issue CRLs are required to include the authority 2126 key identifier (see sec. 5.2.1) and the CRL number (see sec. 5.2.3) 2127 extensions in all CRLs issued. 2129 5.2.1 Authority Key Identifier 2131 The authority key identifier extension provides a means of identify- 2132 ing the public key corresponding to the private key used to sign a 2133 CRL. The identification can be based on either the key identifier 2134 (the subject key identifier in the CRL signer's certificate) or on 2135 the issuer name and serial number. This extension is especially use- 2136 ful where an issuer has more than one signing key, either due to mul- 2137 tiple concurrent key pairs or due to changeover. 2139 Conforming CAs MUST use the key identifier method, and MUST include 2140 this extension in all CRLs issued. 2142 The syntax for this CRL extension is defined in section 4.2.1.1. 2144 5.2.2 Issuer Alternative Name 2146 The issuer alternative names extension allows additional identities 2147 to be associated with the issuer of the CRL. Defined options include 2148 an rfc822 name (electronic mail address), a DNS name, an IP address, 2149 and a URI. Multiple instances of a name and multiple name forms may 2150 be included. Whenever such identities are used, the issuer alterna- 2151 tive name extension MUST be used. 2153 The issuerAltName extension SHOULD NOT be marked critical. 2155 The OID and syntax for this CRL extension are defined in section 2156 4.2.1.8. 2158 5.2.3 CRL Number 2160 The CRL number is a non-critical CRL extension which conveys a mono- 2161 tonically increasing sequence number for each CRL issued by a CA. 2162 This extension allows users to easily determine when a particular CRL 2163 supersedes another CRL. CAs conforming to this profile MUST include 2164 this extension in all CRLs. 2166 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 2168 cRLNumber ::= INTEGER (0..MAX) 2170 5.2.4 Delta CRL Indicator 2172 The delta CRL indicator is a critical CRL extension that identifies a 2173 delta-CRL. The use of delta-CRLs can significantly improve process- 2174 ing time for applications which store revocation information in a 2175 format other than the CRL structure. This allows changes to be added 2176 to the local database while ignoring unchanged information that is 2177 already in the local database. 2179 When a delta-CRL is issued, the CAs MUST also issue a complete CRL. 2181 The value of BaseCRLNumber identifies the CRL number of the base CRL 2182 that was used as the starting point in the generation of this delta- 2183 CRL. The delta-CRL contains the changes between the base CRL and the 2184 current CRL issued along with the delta-CRL. It is the decision of a 2185 CA as to whether to provide delta-CRLs. Again, a delta-CRL MUST NOT 2186 be issued without a corresponding complete CRL. The value of 2187 CRLNumber for both the delta-CRL and the corresponding complete CRL 2188 MUST be identical. 2190 A CRL user constructing a locally held CRL from delta-CRLs MUST con- 2191 sider the constructed CRL incomplete and unusable if the CRLNumber of 2192 the received delta-CRL is more than one greater than the CRLnumber of 2193 the delta-CRL last processed. 2195 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 2197 deltaCRLIndicator ::= BaseCRLNumber 2199 BaseCRLNumber ::= CRLNumber 2201 5.2.5 Issuing Distribution Point 2203 The issuing distribution point is a critical CRL extension that iden- 2204 tifies the CRL distribution point for a particular CRL, and it indi- 2205 cates whether the CRL covers revocation for end entity certificates 2206 only, CA certificates only, or a limitied set of reason codes. 2207 Although the extension is critical, conforming implementations are 2208 not required to support this extension. 2210 The CRL is signed using the CA's private key. CRL Distribution 2211 Points do not have their own key pairs. If the CRL is stored in the 2212 X.500 Directory, it is stored in the Directory entry corresponding to 2213 the CRL distribution point, which may be different than the Directory 2214 entry of the CA. 2216 The reason codes associated with a distribution point shall be speci- 2217 fied in onlySomeReasons. If onlySomeReasons does not appear, the dis- 2218 tribution point shall contain revocations for all reason codes. CAs 2219 may use CRL distribution points to partition the CRL on the basis of 2220 compromise and routine revocation. In this case, the revocations 2221 with reason code keyCompromise (1) and cACompromise (2) appear in one 2222 distribution point, and the revocations with other reason codes 2223 appear in another distribution point. 2225 Where the issuingDistributionPoint extension contains a URL, the fol- 2226 lowing semantics MUST be assumed: the object is a pointer to the most 2227 current CRL issued by this CA. The URI schemes ftp, http, mailto 2228 [RFC1738] and ldap [RFC1778] are defined for this purpose. The URI 2229 MUST be an absolute, not relative, pathname and MUST specify the 2230 host. 2232 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 2234 issuingDistributionPoint ::= SEQUENCE { 2235 distributionPoint [0] DistributionPointName OPTIONAL, 2236 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 2237 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 2238 onlySomeReasons [3] ReasonFlags OPTIONAL, 2239 indirectCRL [4] BOOLEAN DEFAULT FALSE } 2241 5.3 CRL Entry Extensions 2243 The CRL entry extensions already defined by ANSI X9 and ISO/IEC/ITU 2244 for X.509 v2 CRLs provide methods for associating additional attri- 2245 butes with CRL entries [X.509] [X9.55]. The X.509 v2 CRL format also 2246 allows communities to define private CRL entry extensions to carry 2247 information unique to those communities. Each extension in a CRL 2248 entry may be designated as critical or non-critical. A CRL valida- 2249 tion MUST fail if it encounters a critical CRL entry extension which 2250 it does not know how to process. However, an unrecognized non- 2251 critical CRL entry extension may be ignored. The following subsec- 2252 tions present recommended extensions used within Internet CRL entries 2253 and standard locations for information. Communities may elect to use 2254 additional CRL entry extensions; however, caution should be exercised 2255 in adopting any critical extensions in CRL entries which might be 2256 used in a general context. 2258 All CRL entry extensions used in this specification are non-critical. 2259 Support for these extensions is optional for conforming CAs and 2260 applications. However, CAs that issue CRLs SHOULD include reason 2261 codes (see sec. 5.3.1) and invalidity dates (see sec. 5.3.3) whenever 2262 this information is available. 2264 5.3.1 Reason Code 2266 The reasonCode is a non-critical CRL entry extension that identifies 2267 the reason for the certificate revocation. CAs are strongly 2268 encouraged to include meaningful reason codes in CRL entries; how- 2269 ever, the reason code CRL entry extension SHOULD be absent instead of 2270 using the unspecified (0) reasonCode value. 2272 id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 } 2274 -- reasonCode ::= { CRLReason } 2276 CRLReason ::= ENUMERATED { 2277 unspecified (0), 2278 keyCompromise (1), 2279 cACompromise (2), 2280 affiliationChanged (3), 2281 superseded (4), 2282 cessationOfOperation (5), 2283 certificateHold (6), 2284 removeFromCRL (8) } 2286 5.3.2 Hold Instruction Code 2288 The hold instruction code is a non-critical CRL entry extension that 2289 provides a registered instruction identifier which indicates the 2290 action to be taken after encountering a certificate that has been 2291 placed on hold. 2293 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 2295 holdInstructionCode ::= OBJECT IDENTIFIER 2297 The following instruction codes have been defined. Conforming appli- 2298 cations that process this extension MUST recognize the following 2299 instruction codes. 2301 holdInstruction OBJECT IDENTIFIER ::= 2302 { iso(1) member-body(2) us(840) x9-57(10040) 2 } 2304 id-holdinstruction-none OBJECT IDENTIFIER ::= {holdInstruction 1} 2305 id-holdinstruction-callissuer 2306 OBJECT IDENTIFIER ::= {holdInstruction 2} 2307 id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3} 2309 Conforming applications which encounter an id-holdinstruction- 2310 callissuer MUST call the certificate issuer or reject the certifi- 2311 cate. Conforming applications which encounter an id- 2312 holdinstruction-reject MUST reject the certificate. The hold instruc- 2313 tion id-holdinstruction-none is semantically equivalent to the 2314 absence of a holdInstructionCode, and its use is strongly deprecated 2315 for the Internet PKI. 2317 5.3.3 Invalidity Date 2319 The invalidity date is a non-critical CRL entry extension that pro- 2320 vides the date on which it is known or suspected that the private key 2321 was compromised or that the certificate otherwise became invalid. 2322 This date may be earlier than the revocation date in the CRL entry, 2323 which is the date at which the CA processed the revocation. When a 2324 revocation is first posted by a CA in a CRL, the invalidity date may 2325 precede the date of issue of earlier CRLs, but the revocation date 2326 SHOULD NOT precede the date of issue of earlier CRLs. Whenever this 2327 information is available, CAs are strongly encouraged to share it 2328 with CRL users. 2330 The GeneralizedTime values included in this field MUST be expressed 2331 in Greenwich Mean Time (Zulu), and MUST be specified and interpreted 2332 as defined in section 4.1.2.5.2. 2334 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 2336 invalidityDate ::= GeneralizedTime 2338 5.3.4 Certificate Issuer 2340 This CRL entry extension identifies the certificate issuer associated 2341 with an entry in an indirect CRL, i.e. a CRL that has the indirectCRL 2342 indicator set in its issuing distribution point extension. If this 2343 extension is not present on the first entry in an indirect CRL, the 2344 certificate issuer defaults to the CRL issuer. On subsequent entries 2345 in an indirect CRL, if this extension is not present, the certificate 2346 issuer for the entry is the same as that for the preceding entry. 2347 This field is defined as follows: 2349 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } 2351 certificateIssuer ::= GeneralNames 2353 If used by conforming CAs that issue CRLs, this extension is always 2354 critical. If an implementation ignored this extension it could not 2355 correctly attribute CRL entries to certificates. This specification 2356 RECOMMENDS that implementations recognize this extension. 2358 6 Certification Path Validation 2360 Certification path validation procedures for the Internet PKI are 2361 based on section 12.4.3 of [X.509]. Certification path processing 2362 verifies the binding between the subject distinguished name and/or 2363 subject alternative name and subject public key. The binding is lim- 2364 ited by constraints which are specified in the certificates which 2365 comprise the path. The basic constraints and policy constraints 2366 extensions allow the certification path processing logic to automate 2367 the decision making process. 2369 This section describes an algorithm for validating certification 2370 paths. Conforming implementations of this specification are not 2371 required to implement this algorithm, but MUST be functionally 2372 equivalent to the external behavior resulting from this procedure. 2373 Any algorithm may be used by a particular implementation so long as 2374 it derives the correct result. 2376 In section 6.1, the text describes basic path validation. This text 2377 assumes that all valid paths begin with certificates issued by a sin- 2378 gle "most-trusted CA". The algorithm requires the public key of the 2379 CA, the CA's name, the validity period of the public key, and any 2380 constraints upon the set of paths which may be validated using this 2381 key. 2383 The "most-trusted CA" is a matter of policy: it could be a root CA in 2384 a hierarchical PKI; the CA that issued the verifier's own 2385 certificate(s); or any other CA in a network PKI. The path valida- 2386 tion procedure is the same regardless of the choice of "most-trusted 2387 CA." 2389 section 6.2 describes extensions to the basic path validation algo- 2390 rithm. Two specific cases are discussed: the case where paths may 2391 begin with one of several trusted CAs; and where compatibility with 2392 the PEM architecture is required. 2394 6.1 Basic Path Validation 2396 The text assumes that the trusted public key (and related informa- 2397 tion) is contained in a "self-signed" certificate. This simplifies 2398 the description of the path processing procedure. Note that the sig- 2399 nature on the self-signed certificate does not provide any security 2400 services. The trusted public key (and related information) may be 2401 obtained in other formats; the information is trusted because of 2402 other procedures used to obtain and protect it. 2404 The goal of path validation is to verify the binding between a sub- 2405 ject distinguished name or subject alternative name and subject pub- 2406 lic key, as represented in the "end entity" certificate, based on the 2407 public key of the "most-trusted CA". This requires obtaining a 2408 sequence of certificates that support that binding. The procedures 2409 performed to obtain this sequence is outside the scope of this sec- 2410 tion. 2412 The following text also assumes that certificates do not use subject 2413 or unique identifier fields or private critical extensions, as recom- 2414 mended within this profile. However, if these components appear in 2415 certificates, they MUST be processed. Finally, policy qualifiers are 2416 also neglected for the sake of clarity. 2418 A certification path is a sequence of n certificates where: 2420 * for all x in {1,(n-1)}, the subject of certificate x is the 2421 issuer of certificate x+1. 2422 * certificate x=1 is the the self-signed certificate, and 2423 * certificate x=n is the end entity certificate. 2425 This section assumes the following inputs are provided to the path 2426 processing logic: 2428 (a) a certification path of length n; 2430 (b) a set of initial policy identifiers (each comprising a 2431 sequence of policy element identifiers), which identifies one or 2432 more certificate policies, any one of which would be acceptable 2433 for the purposes of certification path processing, or the special 2434 value "any-policy"; 2436 (c) the current date/time (if not available internally to the 2437 certification path processing module); and 2439 (d) the time, T, for which the validity of the path should be 2440 determined. (This may be the current date/time, or some point in 2441 the past.) 2443 From the inputs, the procedure intializes five state variables: 2445 (a) acceptable policy set: A set of certificate policy identif- 2446 iers comprising the policy or policies recognized by the public 2447 key user together with policies deemed equivalent through policy 2448 mapping. The initial value of the acceptable policy set is the 2449 special value "any-policy". 2451 (b) constrained subtrees: A set of root names defining a set of 2452 subtrees within which all subject names in subsequent certificates 2453 in the certification path shall fall. The initial value is 2454 "unbounded". 2456 (c) excluded subtrees: A set of root names defining a set of 2457 subtrees within which no subject name in subsequent certificates 2458 in the certification path may fall. The initial value is "empty". 2460 (d) explicit policy: an integer which indicates if an explicit 2461 policy identifier is required. The integer indicates the first 2462 certificate in the path where this requirement is imposed. Once 2463 set, this variable may be decreased, but may not be increased. 2464 (That is, if a certificate in the path requires explicit policy 2465 identifiers, a later certificate can not remove this requirement.) 2466 The initial value is n+1. 2468 (e) policy mapping: an integer which indicates if policy mapping 2469 is permitted. The integer indicates the last certificate on which 2470 policy mapping may be applied. Once set, this variable may be 2471 decreased, but may not be increased. (That is, if a certificate in 2472 the path specifies policy mapping is not permitted, it can not be 2473 overriden by a later certificate.) The initial value is n+1. 2475 The actions performed by the path processing software for each certi- 2476 ficate i=1 through n are described below. The self-signed certifi- 2477 cate is certificate i=1, the end entity certificate is i=n. The pro- 2478 cessing is performed sequentially, so that processing certificate i 2479 affects the state variables for processing certificate (i+1). Note 2480 that actions (h) through (m) are not applied to the end entity certi- 2481 ficate (certificate n). 2483 The path processing actions to be performed are: 2485 (a) Verify the basic certificate information, including: 2487 (1) the certificate was signed using the subject public key 2488 from certificate i-1 (in the special case i=1, this step may be 2489 omitted; if not, use the subject public key from the same cer- 2490 tificate), 2492 (2) the certificate validity period includes time T, 2494 (3) the certificate had not been revoked at time T and is not 2495 currently on hold status that commenced before time T, (this 2496 may be determined by obtaining the appropriate CRL or status 2497 information, or by out-of-band mechanisms), and 2499 (4) the subject and issuer names chain correctly (that is, the 2500 issuer of this certificate was the subject of the previous cer- 2501 tificate.) 2503 (b) Verify that the subject name and subjectAltName extension 2504 (critical or noncritical) is consistent with the constrained sub- 2505 trees state variables. 2507 (c) Verify that the subject name and subjectAltName extension 2508 (critical or noncritical) is consistent with the excluded subtrees 2509 state variables. 2511 (d) Verify that policy information is consistent with the initial 2512 policy set: 2514 (1) if the explicit policy state variable is less than or equal 2515 to i, a policy identifier in the certificate shall be in the 2516 initial policy set; and 2518 (2) if the policy mapping variable is less than or equal to i, 2519 the policy identifier may not be mapped. 2521 (e) Verify that policy information is consistent with the accept- 2522 able policy set: 2524 (1) if the certificate policies extension is marked critical, 2525 the intersection of the policies extension and the acceptable 2526 policy set shall be non-null; 2527 (2) the acceptable policy set is assigned the resulting inter- 2528 section as its new value. 2530 (g) Verify that the intersection of the acceptable policy set and 2531 the initial policy set is non-null. 2533 (h) Recognize and process any other critical extension present in 2534 the certificate. 2536 (i) Verify that the certificate is a CA certificate (as specified 2537 in a basicConstraints extension or as verified out-of-band). 2539 (j) If permittedSubtrees is present in the certificate, set the 2540 constrained subtrees state variable to the intersection of its 2541 previous value and the value indicated in the extension field. 2543 (k) If excludedSubtrees is present in the certificate, set the 2544 excluded subtrees state variable to the union of its previous 2545 value and the value indicated in the extension field. 2547 (l) If a policy constraints extension is included in the certifi- 2548 cate, modify the explicit policy and policy mapping state vari- 2549 ables as follows: 2551 (1) If requireExplicitPolicy is present and has value r, the 2552 explicit policy state variable is set to the minimum of its 2553 current value and the sum of r and i (the current certificate 2554 in the sequence). 2556 (2) If inhibitPolicyMapping is present and has value q, the 2557 policy mapping state variable is set to the minimum of its 2558 current value and the sum of q and i (the current certificate 2559 in the sequence). 2561 (m) If a key usage extension is marked critical, ensure the key- 2562 CertSign bit is set. 2564 If any one of the above checks fail, the procedure terminates, 2565 returning a failure indication and an appropriate reason. If none of 2566 the above checks fail on the end-entity certificate, the procedure 2567 terminates, returning a success indication together with the set of 2568 all policy qualifier values encountered in the set of certificates. 2570 6.2 Extending Path Validation 2572 The path validation algorithm presented in 6.1 is based on several 2573 simplifying assumptions (e.g., a single trusted CA that starts all 2574 valid paths). This algorithm may be extended for cases where the 2575 assumptions do not hold. 2577 This procedure may be extended for multiple trusted CAs by providing 2578 a set of self-signed certificates to the validation module. In this 2579 case, a valid path could begin with any one of the self-signed certi- 2580 ficates. Limitations in the trust paths for any particular key may 2581 be incorporated into the self-signed certificate's extensions. In 2582 this way, the self-signed certificates permit the path validation 2583 module to automatically incorporate local security policy and 2584 requirements. 2586 It is also possible to specify an extended version of the above cer- 2587 tification path processing procedure which results in default 2588 behavior identical to the rules of PEM [RFC 1422]. In this extended 2589 version, additional inputs to the procedure are a list of one or more 2590 Policy Certification Authorities (PCAs) names and an indicator of the 2591 position in the certification path where the PCA is expected. At the 2592 nominated PCA position, the CA name is compared against this list. 2593 If a recognized PCA name is found, then a constraint of Subordina- 2594 teToCA is implicitly assumed for the remainder of the certification 2595 path and processing continues. If no valid PCA name is found, and if 2596 the certification path cannot be validated on the basis of identified 2597 policies, then the certification path is considered invalid. 2599 7 Algorithm Support 2601 This section describes cryptographic algorithms which may be used 2602 with this profile. The section describes one-way hash functions and 2603 digital signature algorithms which may be used to sign certificates 2604 and CRLs, and identifies OIDs for public keys contained in a certifi- 2605 cate. 2607 Conforming CAs and applications are not required to support the algo- 2608 rithms or algorithm identifiers described in this section. However, 2609 conforming CAs and applications that use the algorithms identified 2610 here MUST support them as specified. 2612 7.1 One-way Hash Functions 2614 This section identifies one-way hash functions for use in the Inter- 2615 net PKI. One-way hash functions are also called message digest algo- 2616 rithms. SHA-1 is the preferred one-way hash function for the Internet 2617 PKI. However, PEM uses MD2 for certificates [RFC 1422] [RFC 1423] 2618 and MD5 is used in other legacy applications. For this reason, MD2 2619 and MD5 are included in this profile. 2621 7.1.1 MD2 One-way Hash Function 2623 MD2 was developed by Ron Rivest for RSA Data Security. RSA Data Secu- 2624 rity has not placed the MD2 algorithm in the public domain. Rather, 2625 RSA Data Security has granted license to use MD2 for non-commercial 2626 Internet Privacy-Enhanced Mail. For this reason, MD2 may continue to 2627 be used with PEM certificates, but SHA-1 is preferred. MD2 produces 2628 a 128-bit "hash" of the input. MD2 is fully described in RFC 1319 2629 [RFC 1319]. 2631 At the Selected Areas in Cryptography '95 conference in May 1995, 2632 Rogier and Chauvaud presented an attack on MD2 that can nearly find 2633 collisions [RC95]. Collisions occur when one can find two different 2634 messages that generate the same message digest. A checksum operation 2635 in MD2 is the only remaining obstacle to the success of the attack. 2636 For this reason, the use of MD2 for new applications is discouraged. 2637 It is still reasonable to use MD2 to verify existing signatures, as 2638 the ability to find collisions in MD2 does not enable an attacker to 2639 find new messages having a previously computed hash value. 2641 7.1.2 MD5 One-way Hash Function 2643 MD5 was developed by Ron Rivest for RSA Data Security. RSA Data Secu- 2644 rity has placed the MD5 algorithm in the public domain. MD5 produces 2645 a 128-bit "hash" of the input. MD5 is fully described in RFC 1321 2646 [RFC 1321]. 2648 Den Boer and Bosselaers [DB94] have found pseudo-collisions for MD5, 2649 but there are no other known cryptanalytic results. The use of MD5 2650 for new applications is discouraged. It is still reasonable to use 2651 MD5 to verify existing signatures. 2653 7.1.3 SHA-1 One-way Hash Function 2655 SHA-1 was developed by the U.S. Government. SHA-1 produces a 160-bit 2656 "hash" of the input. SHA-1 is fully described in FIPS 180-1 [FIPS 2657 180-1]. 2659 SHA-1 is the one-way hash function of choice for use with both the 2660 RSA and DSA signature algorithms (see sec. 7.2). 2662 7.2 Signature Algorithms 2664 Certificates and CRLs described by this standard may be signed with 2665 any public key signature algorithm. The certificate or CRL indicates 2666 the algorithm through an algorithm identifier which appears in the 2667 signatureAlgorithm field in a Certificate or CertificateList. This 2668 algorithm identifier is an OID and has optionally associated parame- 2669 ters. This section identifies algorithm identifiers and parameters 2670 that shall be used in the signatureAlgorithm field in a Certificate 2671 or CertificateList. 2673 RSA and DSA are the most popular signature algorithms used in the 2674 Internet. Signature algorithms are always used in conjunction with a 2675 one-way hash function identified in section 7.1. 2677 The signature algorithm and one-way hash function used to sign a cer- 2678 tificate or CRL is indicated by use of an algorithm identifier. An 2679 algorithm identifier is an OID, and may include associated parame- 2680 ters. This section identifies OIDS for RSA and DSA. The contents of 2681 the parameters component for each algorithm vary; details are pro- 2682 vided for each algorithm. 2684 The data to be signed (e.g., the one-way hash function output value) 2685 is formatted for the signature algorithm to be used. Then, a private 2686 key operation (e.g., RSA encryption) is performed to generate the 2687 signature value. This signature value is then ASN.1 encoded as a BIT 2688 STRING and included in the Certificate or CertificateList in the sig- 2689 nature field. 2691 7.2.1 RSA Signature Algorithm 2693 A patent statement regarding the RSA algorithm can be found at the 2694 end of this profile. 2696 The RSA algorithm is named for its inventors: Rivest, Shamir, and 2697 Adleman. This profile includes three signature algorithms based on 2698 the RSA asymmetric encryption algorithm. The signature algorithms 2699 combine RSA with either the MD2, MD5, or the SHA-1 one-way hash func- 2700 tions. 2702 The signature algorithm with MD2 and the RSA encryption algorithm is 2703 defined in PKCS #1 [RFC 2313]. As defined in RFC 2313, the ASN.1 OID 2704 used to identify this signature algorithm is: 2706 md2WithRSAEncryption OBJECT IDENTIFIER ::= { 2707 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 2708 pkcs-1(1) 2 } 2710 The signature algorithm with MD5 and the RSA encryption algorithm is 2711 defined in PKCS #1 [RFC 2313]. As defined in RFC 2313, the ASN.1 OID 2712 used to identify this signature algorithm is: 2714 md5WithRSAEncryption OBJECT IDENTIFIER ::= { 2715 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 2716 pkcs-1(1) 4 } 2718 The signature algorithm with SHA-1 and the RSA encryption algorithm 2719 is implemented using the padding and encoding conventions described 2720 in PKCS #1 [RFC 2313]. The message digest is computed using the SHA-1 2721 hash algorithm. The ASN.1 object identifier used to identify this 2722 signature algorithm is: 2724 sha-1WithRSAEncryption OBJECT IDENTIFIER ::= { 2725 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 2726 pkcs-1(1) 5 } 2728 When any of these three OIDs appears within the ASN.1 type Algorith- 2729 mIdentifier, the parameters component of that type shall be the ASN.1 2730 type NULL. 2732 The RSA signature generation process and the encoding of the result 2733 is described in detail in RFC 2313. 2735 7.2.2 DSA Signature Algorithm 2737 A patent statement regarding the DSA can be found at the end of this 2738 profile. 2740 The Digital Signature Algorithm (DSA) is also called the Digital Sig- 2741 nature Standard (DSS). DSA was developed by the U.S. Government, and 2742 DSA is used in conjunction with the the SHA-1 one-way hash function. 2743 DSA is fully described in FIPS 186 [FIPS 186]. The ASN.1 OIDs used 2744 to identify this signature algorithm are: 2746 id-dsa-with-sha1 ID ::= { 2747 iso(1) member-body(2) us(840) x9-57 (10040) 2748 x9cm(4) 3 } 2750 Where the id-dsa-with-sha1 algorithm identifier appears as the algo- 2751 rithm field in an AlgorithmIdentifier, the encoding shall omit the 2752 parameters field. That is, the AlgorithmIdentifier shall be a 2753 SEQUENCE of one component - the OBJECT IDENTIFIER id-dsa-with-sha1. 2755 The DSA parameters in the subjectPublicKeyInfo field of the certifi- 2756 cate of the issuer shall apply to the verification of the signature. 2758 When signing, the DSA algorithm generates two values. These values 2759 are commonly referred to as r and s. To easily transfer these two 2760 values as one signature, they shall be ASN.1 encoded using the fol- 2761 lowing ASN.1 structure: 2763 Dss-Sig-Value ::= SEQUENCE { 2764 r INTEGER, 2765 s INTEGER } 2767 7.3 Subject Public Key Algorithms 2769 Certificates described by this profile may convey a public key for 2770 any public key algorithm. The certificate indicates the algorithm 2771 through an algorithm identifier. This algorithm identifier is an OID 2772 and optionally associated parameters. 2774 This section identifies preferred OIDs and parameters for the RSA, 2775 DSA, and Diffie-Hellman algorithms. Conforming CAs shall use the 2776 identified OIDs when issuing certificates containing public keys for 2777 these algorithms. Conforming applications supporting any of these 2778 algorithms shall, at a minimum, recognize the OID identified in this 2779 section. 2781 7.3.1 RSA Keys 2783 The OID rsaEncryption identifies RSA public keys. 2785 pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 2786 rsadsi(113549) pkcs(1) 1 } 2788 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1} 2790 The rsaEncryption OID is intended to be used in the algorithm field 2791 of a value of type AlgorithmIdentifier. The parameters field shall 2792 have ASN.1 type NULL for this algorithm identifier. 2794 The RSA public key shall be encoded using the ASN.1 type RSAPub- 2795 licKey: 2797 RSAPublicKey ::= SEQUENCE { 2798 modulus INTEGER, -- n 2799 publicExponent INTEGER -- e -- } 2801 where modulus is the modulus n, and publicExponent is the public 2802 exponent e. The DER encoded RSAPublicKey is the value of the BIT 2803 STRING subjectPublicKey. 2805 This OID is used in public key certificates for both RSA signature 2806 keys and RSA encryption keys. The intended application for the key 2807 may be indicated in the key usage field (see sec. 4.2.1.3). The use 2808 of a single key for both signature and encryption purposes is not 2809 recommended, but is not forbidden. 2811 If the keyUsage extension is present in an end entity certificate 2812 which conveys an RSA public key, any combination of the following 2813 values may be present: digitalSignature; nonRepudiation; keyEnci- 2814 pherment; and dataEncipherment. If the keyUsage extension is present 2815 in a CA certificate which conveys an RSA public key, any combination 2816 of the following values may be present: digitalSignature; nonRepudi- 2817 ation; keyEncipherment; dataEncipherment; keyCertSign; and cRLSign. 2818 However, this specification RECOMMENDS that if keyCertSign or cRLSign 2819 is present, both keyEncipherment and dataEncipherment should not be 2820 present. 2822 7.3.2 Diffie-Hellman Key Exchange Key 2824 The Diffie-Hellman OID supported by this profile is defined by ANSI 2825 X9.42 [X9.42]. 2827 dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2828 us(840) ansi-x942(10046) number-type(2) 1 } 2830 The dhpublicnumber OID is intended to be used in the algorithm field 2831 of a value of type AlgorithmIdentifier. The parameters field of that 2832 type, which has the algorithm-specific syntax ANY DEFINED BY algo- 2833 rithm, have the ASN.1 type GroupParameters for this algorithm. 2835 DomainParameters ::= SEQUENCE { 2836 p INTEGER, -- odd prime, p=jq +1 2837 g INTEGER, -- generator, g 2838 q INTEGER, -- factor of p-1 2839 j INTEGER OPTIONAL, -- subgroup factor 2840 validationParms ValidationParms OPTIONAL } 2842 ValidationParms ::= SEQUENCE { 2843 seed BIT STRING, 2844 pgenCounter INTEGER } 2846 The fields of type DomainParameters have the following meanings: 2848 p identifies the prime p defining the Galois field; 2850 g specifies the generator of the multiplicative subgroup of order 2851 g; 2853 q specifies the prime factor of p-1; 2855 j optionally specifies the value that satisfies the equation 2856 p=jq+1 to support the optional verification of group parameters; 2858 seed optionally specifies the bit string parameter used as the 2859 seed for the system parameter generation process; and 2861 pgenCounter optionally specifies the integer value output as part 2862 of the of the system parameter prime generation process. 2864 If either of the parameter generation components (pgencounter or 2865 seed) is provided, the other shall be present as well. 2867 The Diffie-Hellman public key shall be ASN.1 encoded as an INTEGER; 2868 this encoding shall be used as the contents (i.e., the value) of the 2869 subjectPublicKey component (a BIT STRING) of the subjectPublicKeyInfo 2870 data element. 2872 DHPublicKey ::= INTEGER -- public key, y = g^x mod p 2874 If the keyUsage extension is present in a certificate which conveys a 2875 DH public key, the following values may be present: keyAgreement; 2876 encipherOnly; and decipherOnly. At most one of encipherOnly and 2877 decipherOnly shall be asserted in keyUsage extension. 2879 7.3.3 DSA Signature Keys 2881 The Digital Signature Algorithm (DSA) is also known as the Digital 2882 Signature Standard (DSS). The DSA OID supported by this profile is 2884 id-dsa ID ::= { iso(1) member-body(2) us(840) x9-57(10040) 2885 x9cm(4) 1 } 2887 The id-dsa algorithm syntax includes optional parameters. These 2888 parameters are commonly referred to as p, q, and g. When omitted, 2889 the parameters component shall be omitted entirely. That is, the 2890 AlgorithmIdentifier shall be a SEQUENCE of one component - the OBJECT 2891 IDENTIFIER id-dsa. 2893 If the DSA algorithm parameters are present in the subjectPublicKey- 2894 Info AlgorithmIdentifier, the parameters are included using the fol- 2895 lowing ASN.1 structure: 2897 Dss-Parms ::= SEQUENCE { 2898 p INTEGER, 2899 q INTEGER, 2900 g INTEGER } 2902 If the DSA algorithm parameters are absent from the subjectPublicKey- 2903 Info AlgorithmIdentifier and the CA signed the subject certificate 2904 using DSA, then the certificate issuer's DSA parameters apply to the 2905 subject's DSA key. If the DSA algorithm parameters are absent from 2906 the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the 2907 subject certificate using a signature algorithm other than DSA, then 2908 the subject's DSA parameters are distributed by other means. If the 2909 subjectPublicKeyInfo AlgorithmIdentifier field omits the parameters 2910 component and the CA signed the subject with a signature algorithm 2911 other than DSA, then clients shall reject the certificate. 2913 When signing, DSA algorithm generates two values. These values are 2914 commonly referred to as r and s. To easily transfer these two values 2915 as one signature, they are ASN.1 encoded using the following ASN.1 2916 structure: 2918 Dss-Sig-Value ::= SEQUENCE { 2919 r INTEGER, 2920 s INTEGER } 2922 The encoded signature is conveyed as the value of the BIT STRING sig- 2923 nature in a Certificate or CertificateList. 2925 The DSA public key shall be ASN.1 DER encoded as an INTEGER; this 2926 encoding shall be used as the contents (i.e., the value) of the sub- 2927 jectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo 2928 data element. 2930 DSAPublicKey ::= INTEGER -- public key, Y 2932 If the keyUsage extension is present in an end entity certificate 2933 which conveys a DSA public key, any combination of the following 2934 values may be present: digitalSignature; and nonRepudiation. 2936 If the keyUsage extension is present in an CA certificate which con- 2937 veys a DSA public key, any combination of the following values may be 2938 present: digitalSignature; nonRepudiation; keyCertSign; and cRLSign. 2940 8 References 2942 [FIPS 180-1] Federal Information Processing Standards Publication 2943 (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995. 2944 [Supersedes FIPS PUB 180 dated 11 May 1993.] 2946 [FIPS 186] Federal Information Processing Standards Publication 2947 (FIPS PUB) 186, Digital Signature Standard, 18 May 1994. 2949 [RC95] Rogier, N. and Chauvaud, P., "The compression function of 2950 MD2 is not collision free," Presented at Selected Areas in 2951 Cryptography '95, May 1995. 2953 [RFC 791] J. Postel, "Internet Protocol", September 1981. 2955 [RFC 822] D. Crocker, "Standard for the format of ARPA Internet text 2956 messages", August 1982. 2958 [RFC 1034] P.V. Mockapetris, "Domain names - concepts and 2959 facilities", November 1987. 2961 [RFC 1319] Kaliski, B., "The MD2 Message-Digest Algorithm," RFC 1319, 2962 RSA Laboratories, April 1992. 2964 [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321, 2965 MIT and RSA Data Security, April 1992. 2967 [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic 2968 Mail: Part II: Certificate-Based Key Management," RFC 2969 1422, BBN Communications, February 1993. 2971 [RFC 1423] Balenson, D., "Privacy Enhancement for Internet Electronic 2972 Mail: Part III: Algorithms, Modes, and Identifiers," 2973 RFC 1423, Trusted Information Systems, February 1993. 2975 [RFC 1519] V. Fuller, T. Li, J. Yu, and K. Varadhan. "Classless 2976 Inter-Domain Routing (CIDR): an Address Assignment and 2977 Aggregation Strategy", September 1993. 2979 [RFC 1738] Berners-Lee, T., Masinter L., and M. McCahill. 2980 "Uniform Resource Locators (URL)", RFC 1738, December 1994. 2982 [RFC 1778] Howes, T., Kille S., Yeong, W. and C. Robbins. "The 2983 String Representation of Standard Attribute Syntaxes," 2984 RFC 1778, March 1995. 2986 [RFC 1883] S. Deering and R. Hinden. "Internet Protocol, Version 6 2987 (IPv6) Specification", December 1995. 2989 [RFC 2044] F. Yergeau, "UTF-8, a transformation format of Unicode 2990 and ISO 10646", October 1996. 2992 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 2993 Requirement Levels", March 1997. 2995 [RFC 2247] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. 2996 Sataluri. "Using Domains in LDAP/X.500 Distinguished Names", 2997 RFC 2247, January 1998. 2999 [RFC 2277] H. Alvestrand, "IETF Policy on Character Sets and 3000 Languages", January 1998. 3002 [RFC 2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646", 3003 January 1998. 3005 [RFC 2313] B. Kaliski, "PKCS #1: RSA Encryption Version 1.5", 3006 March 1998. 3008 [SDN.701] SDN.701, "Message Security Protocol 4.0", Revision A 3009 1997-02-06. 3011 [X.208] CCITT Recommendation X.208: Specification of Abstract 3012 Syntax Notation One (ASN.1), 1988. 3014 [X.501] ITU-T Recommendation X.501: Information 3015 Technology - Open Systems Interconnection - The 3016 Directory: Models, 1993. 3018 [X.509] ITU-T Recommendation X.509 (1997 E): Information 3019 Technology - Open Systems Interconnection - The 3020 Directory: Authentication Framework, June 1997. 3022 [X.520] ITU-T Recommendation X.520: Information 3023 Technology - Open Systems Interconnection - The 3024 Directory: Selected Attribute Types, 1993. 3026 [X9.42] ANSI X9.42-199x, Public Key Cryptography for The Financial 3027 Services Industry: Agreement of Symmetric Algorithm Keys 3028 Using Diffie-Hellman (Working Draft), December 1997. 3030 [X9.55] ANSI X9.55-1995, Public Key Cryptography For The Financial 3031 Services Industry: Extensions To Public Key Certificates 3032 And Certificate Revocation Lists, 8 December, 1995. 3034 [X9.57] ANSI X9.57-199x, Public Key Cryptography For The Financial 3035 Services Industry: Certificate Management (Working Draft), 3036 21 June, 1996. 3038 9 Intellectual Property Rights 3040 The IETF has been notified of intellectual property rights claimed in 3041 regard to some or all of the specification contained in this docu- 3042 ment. For more information consult the online list of claimed 3043 rights. 3045 The IETF takes no position regarding the validity or scope of any 3046 intellectual property or other rights that might be claimed to per- 3047 tain to the implementation or use of the technology described in this 3048 document or the extent to which any license under such rights might 3049 or might not be available; neither does it represent that it has made 3050 any effort to identify any such rights. Information on the IETF's 3051 procedures with respect to rights in standards-track and standards- 3052 related documentation can be found in BCP-11. Copies of claims of 3053 rights made available for publication and any assurances of licenses 3054 to be made available, or the result of an attempt made to obtain a 3055 general license or permission for the use of such proprietary rights 3056 by implementors or users of this specification can be obtained from 3057 the IETF Secretariat. 3059 10 Security Considerations 3061 The majority of this specification is devoted to the format and con- 3062 tent of certificates and CRLs. Since certificates and CRLs are digi- 3063 tally signed, no additional integrity service is necessary. Neither 3064 certificates nor CRLs need be kept secret, and unrestricted and 3065 anonymous access to certificates and CRLs has no security implica- 3066 tions. 3068 However, security factors outside the scope of this specification 3069 will affect the assurance provided to certificate users. This sec- 3070 tion highlights critical issues that should be considered by imple- 3071 mentors, administrators, and users. 3073 The procedures performed by CAs and RAs to validate the binding of 3074 the subject's identity of their public key greatly affect the 3075 assurance that should be placed in the certificate. Relying parties 3076 may wish to review the CA's certificate practice statement. This may 3077 be particularly important when issuing certificates to other CAs. 3079 The use of a single key pair for both signature and other purposes is 3080 strongly discouraged. Use of separate key pairs for signature and key 3081 management provides several benefits to the users. The ramifications 3082 associated with loss or disclosure of a signature key are different 3083 from loss or disclosure of a key management key. Using separate key 3084 pairs permits a balanced and flexible response. Similarly, different 3085 validity periods or key lengths for each key pair may be appropriate 3086 in some application environments. Unfortunately, some legacy applica- 3087 tions (e.g., SSL) use a single key pair for signature and key manage- 3088 ment. 3090 The protection afforded private keys is a critical factor in main- 3091 taining security. On a small scale, failure of users to protect 3092 their private keys will permit an attacker to masquerade as them, or 3093 decrypt their personal information. On a larger scale, compromise of 3094 a CA's private signing key may have a catastrophic effect. If an 3095 attacker obtains the private key unnoticed, the attacker may issue 3096 bogus certificates and CRLs. Existence of bogus certificates and 3097 CRLs will undermine confidence in the system. If the compromise is 3098 detected, all certificates issued to the CA shall be revoked, 3099 preventing services between its users and users of other CAs. 3100 Rebuilding after such a compromise will be problematic, so CAs are 3101 advised to implement a combination of strong technical measures 3102 (e.g., tamper-resistant cryptographic modules) and appropriate 3103 management procedures (e.g., separation of duties) to avoid such an 3104 incident. 3106 Loss of a CA's private signing key may also be problematic. The CA 3107 would not be able to produce CRLs or perform normal key rollover. 3108 CAs are advised to maintain secure backup for signing keys. The 3109 security of the key backup procedures is a critical factor in avoid- 3110 ing key compromise. 3112 The availability and freshness of revocation information will affect 3113 the degree of assurance that should be placed in a certificate. 3114 While certificates expire naturally, events may occur during its 3115 natural lifetime which negate the binding between the subject and 3116 public key. If revocation information is untimely or unavailable, 3117 the assurance associated with the binding is clearly reduced. Simi- 3118 larly, implementations of the Path Validation mechanism described in 3119 section 6 that omit revocation checking provide less assurance than 3120 those that support it. 3122 The path validation algorithm depends on the certain knowledge of the 3123 public keys (and other information) about one or more trusted CAs. 3124 The decision to trust a CA is an important decision as it ultimately 3125 determines the trust afforded a certificate. The authenticated dis- 3126 tribution of trusted CA public keys (usually in the form of a "self- 3127 signed" certificate) is a security critical out of band process that 3128 is beyond the scope of this specification. 3130 In addition, where a key compromise or CA failure occurs for a 3131 trusted CA, the user will need to modify the information provided to 3132 the path validation routine. Selection of too many trusted CAs will 3133 make the trusted CA information difficult to maintain. On the other 3134 hand, selection of only one trusted CA may limit users to a closed 3135 community of users until a global PKI emerges. 3137 The quality of implementations that process certificates may also 3138 affect the degree of assurance provided. The path validation algo- 3139 rithm described in section 6 relies upon the integrity of the trusted 3140 CA information, and especially the integrity of the public keys asso- 3141 ciated with the trusted CAs. By substituting public keys for which 3142 an attacker has the private key, an attacker could trick the user 3143 into accepting false certificates. 3145 The binding between a key and certificate subject cannot be stronger 3146 than the cryptographic module implementation and algorithms used to 3147 generate the signature. Short key lengths or weak hash algorithms 3148 will limit the utility of a certificate. CAs are encouraged to note 3149 advances in cryptology so they can employ strong cryptographic tech- 3150 niques. In addition, CAs should decline to issue certificates to CAs 3151 or end entities that generate weak signatures. 3153 Inconsistent application of name comparison rules may result in 3154 acceptance of invalid X.509 certification paths, or rejection of 3155 valid ones. The X.500 series of specifications defines rules for 3156 comparing distinguished names require comparison of strings without 3157 regard to case, character set, multi-character white space substring, 3158 or leading and trailing white space. This specification relaxes 3159 these requirements, requiring support for binary comparison at a 3160 minimum. 3162 CAs shall encode the distinguished name in the subject field of a CA 3163 certificate identically to the distinguished name in the issuer field 3164 in certificates issued by the latter CA. If CAs use different encod- 3165 ings, implementations of this specification may fail to recognize 3166 name chains for paths that include this certificate. As a conse- 3167 quence, valid paths could be rejected. 3169 In addition, name constraints for distinguished names shall be stated 3170 identically to the encoding used in the subject field or subjectAlt- 3171 Name extension. If not, (1) name constraints stated as excludedSub- 3172 Trees will not match and invalid paths will be accepted and (2) name 3173 constraints expressed as permittedSubtrees will not match and valid 3174 paths will be rejected. To avoid acceptance of invalid paths, CAs 3175 should state name constraints for distinguished names as permit- 3176 tedSubtrees where ever possible. 3178 Appendix A. Psuedo-ASN.1 Structures and OIDs 3180 This section describes data objects used by conforming PKI components 3181 in an "ASN.1-like" syntax. This syntax is a hybrid of the 1988 and 3182 1993 ASN.1 syntaxes. The 1988 ASN.1 syntax is augmented with 1993 3183 UNIVERSAL Types UniversalString, BMPString and UTF8String. 3185 The ASN.1 syntax does not permit the inclusion of type statements in 3186 the ASN.1 module, and the 1993 ASN.1 standard does not permit use of 3187 the new UNIVERSAL types in modules using the 1988 syntax. As a 3188 result, this module does not conform to either version of the ASN.1 3189 standard. 3191 This appendix may be converted into 1988 ASN.1 by replacing the 3192 defintions for the UNIVERSAL Types with the 1988 catch-all "ANY". 3194 A.1 Explicitly Tagged Module, 1988 Syntax 3196 PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) 3197 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)} 3199 DEFINITIONS EXPLICIT TAGS ::= 3201 BEGIN 3203 -- EXPORTS ALL -- 3205 -- IMPORTS NONE -- 3207 -- UNIVERSAL Types defined in '93 and '98 ASN.1 3208 -- but required by this specification 3210 UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING 3211 -- UniversalString is defined in ASN.1:1993 3213 BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING 3214 -- BMPString is the subtype of UniversalString and models 3215 -- the Basic Multilingual Plane of ISO/IEC/ITU 10646-1 3217 UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 3218 -- The content of this type conforms to RFC 2044. 3220 -- 3221 -- PKIX specific OIDs 3223 id-pkix OBJECT IDENTIFIER ::= 3224 { iso(1) identified-organization(3) dod(6) internet(1) 3225 security(5) mechanisms(5) pkix(7) } 3226 -- PKIX arcs 3228 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 3229 -- arc for private certificate extensions 3230 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 3231 -- arc for policy qualifier types 3232 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 3233 -- arc for extended key purpose OIDS 3234 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 3235 -- arc for access descriptors 3237 -- policyQualifierIds for Internet policy qualifiers 3239 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 3240 -- OID for CPS qualifier 3241 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 3242 -- OID for user notice qualifier 3244 -- access descriptor definitions 3246 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 3247 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 3249 -- attribute data types -- 3251 Attribute ::= SEQUENCE { 3252 type AttributeType, 3253 values SET OF AttributeValue 3254 -- at least one value is required -- } 3256 AttributeType ::= OBJECT IDENTIFIER 3258 AttributeValue ::= ANY 3260 AttributeTypeAndValue ::= SEQUENCE { 3261 type AttributeType, 3262 value AttributeValue } 3264 -- suggested naming attributes: Definition of the following 3265 -- information object set may be augmented to meet local 3266 -- requirements. Note that deleting members of the set may 3267 -- prevent interoperability with conforming implementations. 3268 -- presented in pairs: the AttributeType followed by the 3269 -- type definition for the corresponding AttributeValue 3271 --Arc for standard naming attributes 3272 id-at OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 4} 3273 -- Attributes of type NameDirectoryString 3274 id-at-name AttributeType ::= {id-at 41} 3275 id-at-surname AttributeType ::= {id-at 4} 3276 id-at-givenName AttributeType ::= {id-at 42} 3277 id-at-initials AttributeType ::= {id-at 43} 3278 id-at-generationQualifier AttributeType ::= {id-at 44} 3280 X520name ::= CHOICE { 3281 teletexString TeletexString (SIZE (1..ub-name)), 3282 printableString PrintableString (SIZE (1..ub-name)), 3283 universalString UniversalString (SIZE (1..ub-name)), 3284 utf8String UTF8String (SIZE (1..ub-name)), 3285 bmpString BMPString (SIZE(1..ub-name)) } 3287 -- 3289 id-at-commonName AttributeType ::= {id-at 3} 3291 X520CommonName ::= CHOICE { 3292 teletexString TeletexString (SIZE (1..ub-common-name)), 3293 printableString PrintableString (SIZE (1..ub-common-name)), 3294 universalString UniversalString (SIZE (1..ub-common-name)), 3295 utf8String UTF8String (SIZE (1..ub-common-name)), 3296 bmpString BMPString (SIZE(1..ub-common-name)) } 3298 -- 3300 id-at-localityName AttributeType ::= {id-at 7} 3302 X520LocalityName ::= CHOICE { 3303 teletexString TeletexString (SIZE (1..ub-locality-name)), 3304 printableString PrintableString (SIZE (1..ub-locality-name)), 3305 universalString UniversalString (SIZE (1..ub-locality-name)), 3306 utf8String UTF8String (SIZE (1..ub-locality-name)), 3307 bmpString BMPString (SIZE(1..ub-locality-name)) } 3309 -- 3311 id-at-stateOrProvinceName AttributeType ::= {id-at 8} 3313 X520StateOrProvinceName ::= CHOICE { 3314 teletexString TeletexString (SIZE (1..ub-state-name)), 3315 printableString PrintableString (SIZE (1..ub-state-name)), 3316 universalString UniversalString (SIZE (1..ub-state-name)), 3317 utf8String UTF8String (SIZE (1..ub-state-name)), 3318 bmpString BMPString (SIZE(1..ub-state-name)) } 3320 -- 3321 id-at-organizationName AttributeType ::= {id-at 10} 3323 X520OrganizationName ::= CHOICE { 3324 teletexString TeletexString (SIZE (1..ub-organization-name)), 3325 printableString PrintableString (SIZE (1..ub-organization-name)), 3326 universalString UniversalString (SIZE (1..ub-organization-name)), 3327 utf8String UTF8String (SIZE (1..ub-organization-name)), 3328 bmpString BMPString (SIZE(1..ub-organization-name)) } 3330 -- 3332 id-at-organizationalUnitName AttributeType ::= {id-at 11} 3334 X520OrganizationalUnitName ::= CHOICE { 3335 teletexString TeletexString (SIZE (1..ub-organizational-unit-name)), 3336 printableString PrintableString 3337 (SIZE (1..ub-organizational-unit-name)), 3338 universalString UniversalString 3339 (SIZE (1..ub-organizational-unit-name)), 3340 utf8String UTF8String (SIZE (1..ub-organizational-unit-name)), 3341 bmpString BMPString (SIZE(1..ub-organizational-unit-name)) } 3343 -- 3345 id-at-title AttributeType ::= {id-at 12} 3347 X520Title ::= CHOICE { 3348 teletexString TeletexString (SIZE (1..ub-title)), 3349 printableString PrintableString (SIZE (1..ub-title)), 3350 universalString UniversalString (SIZE (1..ub-title)), 3351 utf8String UTF8String (SIZE (1..ub-title)), 3352 bmpString BMPString (SIZE(1..ub-title)) } 3354 -- 3356 id-at-dnQualifier AttributeType ::= {id-at 46} 3357 X520dnQualifier ::= PrintableString 3359 id-at-countryName AttributeType ::= {id-at 6} 3360 X520countryName ::= PrintableString (SIZE (2)) -- IS 3166 codes 3362 -- Legacy attributes 3364 pkcs-9 OBJECT IDENTIFIER ::= 3365 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 } 3367 emailAddress AttributeType ::= { pkcs-9 1 } 3368 Pkcs9email ::= IA5String (SIZE (1..ub-emailaddress-length)) 3370 -- naming data types -- 3372 Name ::= CHOICE { -- only one possibility for now -- 3373 rdnSequence RDNSequence } 3375 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 3377 DistinguishedName ::= RDNSequence 3379 RelativeDistinguishedName ::= 3380 SET SIZE (1 .. MAX) OF AttributeTypeAndValue 3382 -- Directory string type -- 3384 DirectoryString ::= CHOICE { 3385 teletexString TeletexString (SIZE (1..MAX)), 3386 printableString PrintableString (SIZE (1..MAX)), 3387 universalString UniversalString (SIZE (1..MAX)), 3388 utf8String UTF8String (SIZE (1..MAX)), 3389 bmpString BMPString (SIZE(1..MAX)) } 3391 -- certificate and CRL specific structures begin here 3393 Certificate ::= SEQUENCE { 3394 tbsCertificate TBSCertificate, 3395 signatureAlgorithm AlgorithmIdentifier, 3396 signature BIT STRING } 3398 TBSCertificate ::= SEQUENCE { 3399 version [0] Version DEFAULT v1, 3400 serialNumber CertificateSerialNumber, 3401 signature AlgorithmIdentifier, 3402 issuer Name, 3403 validity Validity, 3404 subject Name, 3405 subjectPublicKeyInfo SubjectPublicKeyInfo, 3406 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 3407 -- If present, version shall be v2 or v3 3408 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 3409 -- If present, version shall be v2 or v3 3410 extensions [3] Extensions OPTIONAL 3411 -- If present, version shall be v3 -- } 3413 Version ::= INTEGER { v1(0), v2(1), v3(2) } 3415 CertificateSerialNumber ::= INTEGER 3416 Validity ::= SEQUENCE { 3417 notBefore Time, 3418 notAfter Time } 3420 Time ::= CHOICE { 3421 utcTime UTCTime, 3422 generalTime GeneralizedTime } 3424 UniqueIdentifier ::= BIT STRING 3426 SubjectPublicKeyInfo ::= SEQUENCE { 3427 algorithm AlgorithmIdentifier, 3428 subjectPublicKey BIT STRING } 3430 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 3432 Extension ::= SEQUENCE { 3433 extnID OBJECT IDENTIFIER, 3434 critical BOOLEAN DEFAULT FALSE, 3435 extnValue OCTET STRING } 3437 -- CRL structures 3439 CertificateList ::= SEQUENCE { 3440 tbsCertList TBSCertList, 3441 signatureAlgorithm AlgorithmIdentifier, 3442 signature BIT STRING } 3444 TBSCertList ::= SEQUENCE { 3445 version Version OPTIONAL, 3446 -- if present, shall be v2 3447 signature AlgorithmIdentifier, 3448 issuer Name, 3449 thisUpdate Time, 3450 nextUpdate Time OPTIONAL, 3451 revokedCertificates SEQUENCE OF SEQUENCE { 3452 userCertificate CertificateSerialNumber, 3453 revocationDate Time, 3454 crlEntryExtensions Extensions OPTIONAL 3455 -- if present, shall be v2 3456 } OPTIONAL, 3457 crlExtensions [0] Extensions OPTIONAL 3458 -- if present, shall be v2 -- } 3460 -- Version, Time, CertificateSerialNumber, and Extensions were 3461 -- defined earlier for use in the certificate structure 3463 AlgorithmIdentifier ::= SEQUENCE { 3464 algorithm OBJECT IDENTIFIER, 3465 parameters ANY DEFINED BY algorithm OPTIONAL } 3466 -- contains a value of the type 3467 -- registered for use with the 3468 -- algorithm object identifier value 3470 -- Algorithm OIDs and parameter structures 3472 pkcs-1 OBJECT IDENTIFIER ::= { 3473 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 } 3475 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } 3477 md2WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 2 } 3479 md5WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 4 } 3481 sha1WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 5 } 3483 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { 3484 iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 3 } 3486 Dss-Sig-Value ::= SEQUENCE { 3487 r INTEGER, 3488 s INTEGER } 3490 dhpublicnumber OBJECT IDENTIFIER ::= { 3491 iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 } 3493 DomainParameters ::= SEQUENCE { 3494 p INTEGER, -- odd prime, p=jq +1 3495 g INTEGER, -- generator, g 3496 q INTEGER, -- factor of p-1 3497 j INTEGER OPTIONAL, -- subgroup factor, j>= 2 3498 validationParms ValidationParms OPTIONAL } 3500 ValidationParms ::= SEQUENCE { 3501 seed BIT STRING, 3502 pgenCounter INTEGER } 3504 id-dsa OBJECT IDENTIFIER ::= { 3505 iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 } 3507 Dss-Parms ::= SEQUENCE { 3508 p INTEGER, 3509 q INTEGER, 3510 g INTEGER } 3512 -- x400 address syntax starts here 3513 -- OR Names 3515 ORAddress ::= SEQUENCE { 3516 built-in-standard-attributes BuiltInStandardAttributes, 3517 built-in-domain-defined-attributes 3518 BuiltInDomainDefinedAttributes OPTIONAL, 3519 -- see also teletex-domain-defined-attributes 3520 extension-attributes ExtensionAttributes OPTIONAL } 3521 -- The OR-address is semantically absent from the OR-name if the 3522 -- built-in-standard-attribute sequence is empty and the 3523 -- built-in-domain-defined-attributes and extension-attributes are 3524 -- both omitted. 3526 -- Built-in Standard Attributes 3528 BuiltInStandardAttributes ::= SEQUENCE { 3529 country-name CountryName OPTIONAL, 3530 administration-domain-name AdministrationDomainName OPTIONAL, 3531 network-address [0] NetworkAddress OPTIONAL, 3532 -- see also extended-network-address 3533 terminal-identifier [1] TerminalIdentifier OPTIONAL, 3534 private-domain-name [2] PrivateDomainName OPTIONAL, 3535 organization-name [3] OrganizationName OPTIONAL, 3536 -- see also teletex-organization-name 3537 numeric-user-identifier [4] NumericUserIdentifier OPTIONAL, 3538 personal-name [5] PersonalName OPTIONAL, 3539 -- see also teletex-personal-name 3540 organizational-unit-names [6] OrganizationalUnitNames OPTIONAL 3541 -- see also teletex-organizational-unit-names -- } 3543 CountryName ::= [APPLICATION 1] CHOICE { 3544 x121-dcc-code NumericString 3545 (SIZE (ub-country-name-numeric-length)), 3546 iso-3166-alpha2-code PrintableString 3547 (SIZE (ub-country-name-alpha-length)) } 3549 AdministrationDomainName ::= [APPLICATION 2] CHOICE { 3550 numeric NumericString (SIZE (0..ub-domain-name-length)), 3551 printable PrintableString (SIZE (0..ub-domain-name-length)) } 3553 NetworkAddress ::= X121Address -- see also extended-network-address 3555 X121Address ::= NumericString (SIZE (1..ub-x121-address-length)) 3557 TerminalIdentifier ::= PrintableString (SIZE (1..ub-terminal-id-length)) 3559 PrivateDomainName ::= CHOICE { 3560 numeric NumericString (SIZE (1..ub-domain-name-length)), 3561 printable PrintableString (SIZE (1..ub-domain-name-length)) } 3563 OrganizationName ::= PrintableString 3564 (SIZE (1..ub-organization-name-length)) 3565 -- see also teletex-organization-name 3567 NumericUserIdentifier ::= NumericString 3568 (SIZE (1..ub-numeric-user-id-length)) 3570 PersonalName ::= SET { 3571 surname [0] PrintableString (SIZE (1..ub-surname-length)), 3572 given-name [1] PrintableString 3573 (SIZE (1..ub-given-name-length)) OPTIONAL, 3574 initials [2] PrintableString (SIZE (1..ub-initials-length)) OPTIONAL, 3575 generation-qualifier [3] PrintableString 3576 (SIZE (1..ub-generation-qualifier-length)) OPTIONAL } 3577 -- see also teletex-personal-name 3579 OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units) 3580 OF OrganizationalUnitName 3581 -- see also teletex-organizational-unit-names 3583 OrganizationalUnitName ::= PrintableString (SIZE 3584 (1..ub-organizational-unit-name-length)) 3586 -- Built-in Domain-defined Attributes 3588 BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE 3589 (1..ub-domain-defined-attributes) OF 3590 BuiltInDomainDefinedAttribute 3592 BuiltInDomainDefinedAttribute ::= SEQUENCE { 3593 type PrintableString (SIZE 3594 (1..ub-domain-defined-attribute-type-length)), 3595 value PrintableString (SIZE 3596 (1..ub-domain-defined-attribute-value-length))} 3598 -- Extension Attributes 3600 ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF 3601 ExtensionAttribute 3603 ExtensionAttribute ::= SEQUENCE { 3604 extension-attribute-type [0] INTEGER (0..ub-extension-attributes), 3605 extension-attribute-value [1] 3606 ANY DEFINED BY extension-attribute-type } 3608 -- Extension types and attribute values 3609 -- 3611 common-name INTEGER ::= 1 3613 CommonName ::= PrintableString (SIZE (1..ub-common-name-length)) 3615 teletex-common-name INTEGER ::= 2 3617 TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length)) 3619 teletex-organization-name INTEGER ::= 3 3621 TeletexOrganizationName ::= 3622 TeletexString (SIZE (1..ub-organization-name-length)) 3624 teletex-personal-name INTEGER ::= 4 3626 TeletexPersonalName ::= SET { 3627 surname [0] TeletexString (SIZE (1..ub-surname-length)), 3628 given-name [1] TeletexString 3629 (SIZE (1..ub-given-name-length)) OPTIONAL, 3630 initials [2] TeletexString (SIZE (1..ub-initials-length)) OPTIONAL, 3631 generation-qualifier [3] TeletexString (SIZE 3632 (1..ub-generation-qualifier-length)) OPTIONAL } 3634 teletex-organizational-unit-names INTEGER ::= 5 3636 TeletexOrganizationalUnitNames ::= SEQUENCE SIZE 3637 (1..ub-organizational-units) OF TeletexOrganizationalUnitName 3639 TeletexOrganizationalUnitName ::= TeletexString 3640 (SIZE (1..ub-organizational-unit-name-length)) 3642 pds-name INTEGER ::= 7 3644 PDSName ::= PrintableString (SIZE (1..ub-pds-name-length)) 3646 physical-delivery-country-name INTEGER ::= 8 3648 PhysicalDeliveryCountryName ::= CHOICE { 3649 x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)), 3650 iso-3166-alpha2-code PrintableString 3651 (SIZE (ub-country-name-alpha-length)) } 3653 postal-code INTEGER ::= 9 3655 PostalCode ::= CHOICE { 3656 numeric-code NumericString (SIZE (1..ub-postal-code-length)), 3657 printable-code PrintableString (SIZE (1..ub-postal-code-length)) } 3659 physical-delivery-office-name INTEGER ::= 10 3661 PhysicalDeliveryOfficeName ::= PDSParameter 3663 physical-delivery-office-number INTEGER ::= 11 3665 PhysicalDeliveryOfficeNumber ::= PDSParameter 3667 extension-OR-address-components INTEGER ::= 12 3669 ExtensionORAddressComponents ::= PDSParameter 3671 physical-delivery-personal-name INTEGER ::= 13 3673 PhysicalDeliveryPersonalName ::= PDSParameter 3675 physical-delivery-organization-name INTEGER ::= 14 3677 PhysicalDeliveryOrganizationName ::= PDSParameter 3679 extension-physical-delivery-address-components INTEGER ::= 15 3681 ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter 3683 unformatted-postal-address INTEGER ::= 16 3685 UnformattedPostalAddress ::= SET { 3686 printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) OF 3687 PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL, 3688 teletex-string TeletexString 3689 (SIZE (1..ub-unformatted-address-length)) OPTIONAL } 3691 street-address INTEGER ::= 17 3693 StreetAddress ::= PDSParameter 3695 post-office-box-address INTEGER ::= 18 3697 PostOfficeBoxAddress ::= PDSParameter 3699 poste-restante-address INTEGER ::= 19 3701 PosteRestanteAddress ::= PDSParameter 3703 unique-postal-name INTEGER ::= 20 3704 UniquePostalName ::= PDSParameter 3706 local-postal-attributes INTEGER ::= 21 3708 LocalPostalAttributes ::= PDSParameter 3710 PDSParameter ::= SET { 3711 printable-string PrintableString 3712 (SIZE(1..ub-pds-parameter-length)) OPTIONAL, 3713 teletex-string TeletexString 3714 (SIZE(1..ub-pds-parameter-length)) OPTIONAL } 3716 extended-network-address INTEGER ::= 22 3718 ExtendedNetworkAddress ::= CHOICE { 3719 e163-4-address SEQUENCE { 3720 number [0] NumericString (SIZE (1..ub-e163-4-number-length)), 3721 sub-address [1] NumericString 3722 (SIZE (1..ub-e163-4-sub-address-length)) OPTIONAL }, 3723 psap-address [0] PresentationAddress } 3725 PresentationAddress ::= SEQUENCE { 3726 pSelector [0] EXPLICIT OCTET STRING OPTIONAL, 3727 sSelector [1] EXPLICIT OCTET STRING OPTIONAL, 3728 tSelector [2] EXPLICIT OCTET STRING OPTIONAL, 3729 nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING } 3731 terminal-type INTEGER ::= 23 3733 TerminalType ::= INTEGER { 3734 telex (3), 3735 teletex (4), 3736 g3-facsimile (5), 3737 g4-facsimile (6), 3738 ia5-terminal (7), 3739 videotex (8) } (0..ub-integer-options) 3741 -- Extension Domain-defined Attributes 3743 teletex-domain-defined-attributes INTEGER ::= 6 3745 TeletexDomainDefinedAttributes ::= SEQUENCE SIZE 3746 (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute 3748 TeletexDomainDefinedAttribute ::= SEQUENCE { 3749 type TeletexString 3750 (SIZE (1..ub-domain-defined-attribute-type-length)), 3751 value TeletexString 3752 (SIZE (1..ub-domain-defined-attribute-value-length)) } 3754 -- specifications of Upper Bounds shall be regarded as mandatory 3755 -- from Annex B of ITU-T X.411 Reference Definition of MTS Parameter 3756 -- Upper Bounds 3758 -- Upper Bounds 3759 ub-name INTEGER ::= 32768 3760 ub-common-name INTEGER ::= 64 3761 ub-locality-name INTEGER ::= 128 3762 ub-state-name INTEGER ::= 128 3763 ub-organization-name INTEGER ::= 64 3764 ub-organizational-unit-name INTEGER ::= 64 3765 ub-title INTEGER ::= 64 3766 ub-match INTEGER ::= 128 3768 ub-emailaddress-length INTEGER ::= 128 3770 ub-common-name-length INTEGER ::= 64 3771 ub-country-name-alpha-length INTEGER ::= 2 3772 ub-country-name-numeric-length INTEGER ::= 3 3773 ub-domain-defined-attributes INTEGER ::= 4 3774 ub-domain-defined-attribute-type-length INTEGER ::= 8 3775 ub-domain-defined-attribute-value-length INTEGER ::= 128 3776 ub-domain-name-length INTEGER ::= 16 3777 ub-extension-attributes INTEGER ::= 256 3778 ub-e163-4-number-length INTEGER ::= 15 3779 ub-e163-4-sub-address-length INTEGER ::= 40 3780 ub-generation-qualifier-length INTEGER ::= 3 3781 ub-given-name-length INTEGER ::= 16 3782 ub-initials-length INTEGER ::= 5 3783 ub-integer-options INTEGER ::= 256 3784 ub-numeric-user-id-length INTEGER ::= 32 3785 ub-organization-name-length INTEGER ::= 64 3786 ub-organizational-unit-name-length INTEGER ::= 32 3787 ub-organizational-units INTEGER ::= 4 3788 ub-pds-name-length INTEGER ::= 16 3789 ub-pds-parameter-length INTEGER ::= 30 3790 ub-pds-physical-address-lines INTEGER ::= 6 3791 ub-postal-code-length INTEGER ::= 16 3792 ub-surname-length INTEGER ::= 40 3793 ub-terminal-id-length INTEGER ::= 24 3794 ub-unformatted-address-length INTEGER ::= 180 3795 ub-x121-address-length INTEGER ::= 16 3797 -- Note - upper bounds on string types, such as TeletexString, are 3798 -- measured in characters. Excepting PrintableString or IA5String, a 3799 -- significantly greater number of octets will be required to hold 3800 -- such a value. As a minimum, 16 octets, or twice the specified upper 3801 -- bound, whichever is the larger, should be allowed for TeletexString. 3802 -- For UTF8String or UniversalString at least four times the upper 3803 -- bound should be allowed. 3805 END 3806 A.2 Implicitly Tagged Module, 1988 Syntax 3808 PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) 3809 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)} 3811 DEFINITIONS IMPLICIT TAGS ::= 3813 BEGIN 3815 -- EXPORTS ALL -- 3817 IMPORTS 3818 id-pkix, id-pe, id-qt, id-kp, id-qt-unotice, id-qt-cps, 3819 id-ad, id-ad-ocsp, id-ad-caIssuers, 3820 -- delete following line if "new" types are supported -- 3821 BMPString, UniversalString, UTF8String, -- end "new" types 3822 ORAddress, Name, RelativeDistinguishedName, 3823 CertificateSerialNumber, 3824 CertificateList, AlgorithmIdentifier, ub-name, 3825 Attribute, DirectoryString 3826 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 3827 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3828 id-mod(0) id-pkix1-explicit(1)}; 3830 -- ISO arc for standard certificate and CRL extensions 3832 id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 3834 -- authority key identifier OID and syntax 3836 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 3838 AuthorityKeyIdentifier ::= SEQUENCE { 3839 keyIdentifier [0] KeyIdentifier OPTIONAL, 3840 authorityCertIssuer [1] GeneralNames OPTIONAL, 3841 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 3842 -- authorityCertIssuer and authorityCertSerialNumber shall both 3843 -- be present or both be absent 3845 KeyIdentifier ::= OCTET STRING 3847 -- subject key identifier OID and syntax 3849 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 3851 SubjectKeyIdentifier ::= KeyIdentifier 3852 -- key usage extension OID and syntax 3854 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 3856 KeyUsage ::= BIT STRING { 3857 digitalSignature (0), 3858 nonRepudiation (1), 3859 keyEncipherment (2), 3860 dataEncipherment (3), 3861 keyAgreement (4), 3862 keyCertSign (5), 3863 cRLSign (6), 3864 encipherOnly (7), 3865 decipherOnly (8) } 3867 -- private key usage period extension OID and syntax 3869 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 3871 PrivateKeyUsagePeriod ::= SEQUENCE { 3872 notBefore [0] GeneralizedTime OPTIONAL, 3873 notAfter [1] GeneralizedTime OPTIONAL } 3874 -- either notBefore or notAfter shall be present 3876 -- certificate policies extension OID and syntax 3878 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 3880 CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 3882 PolicyInformation ::= SEQUENCE { 3883 policyIdentifier CertPolicyId, 3884 policyQualifiers SEQUENCE SIZE (1..MAX) OF 3885 PolicyQualifierInfo OPTIONAL } 3887 CertPolicyId ::= OBJECT IDENTIFIER 3889 PolicyQualifierInfo ::= SEQUENCE { 3890 policyQualifierId PolicyQualifierId, 3891 qualifier ANY DEFINED BY policyQualifierId } 3893 -- Implementations that recognize additional policy qualifiers shall 3894 -- augment the following definition for PolicyQualifierId 3896 PolicyQualifierId ::= 3897 OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) 3899 -- CPS pointer qualifier 3900 CPSuri ::= IA5String 3902 -- user notice qualifier 3904 UserNotice ::= SEQUENCE { 3905 noticeRef NoticeReference OPTIONAL, 3906 explicitText DisplayText OPTIONAL} 3908 NoticeReference ::= SEQUENCE { 3909 organization DisplayText, 3910 noticeNumbers SEQUENCE OF INTEGER } 3912 DisplayText ::= CHOICE { 3913 visibleString VisibleString (SIZE (1..200)), 3914 bmpString BMPString (SIZE (1..200)), 3915 utf8String UTF8String (SIZE (1..200)) } 3917 -- policy mapping extension OID and syntax 3919 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 3921 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 3922 issuerDomainPolicy CertPolicyId, 3923 subjectDomainPolicy CertPolicyId } 3925 -- subject alternative name extension OID and syntax 3927 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 3929 SubjectAltName ::= GeneralNames 3931 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 3933 GeneralName ::= CHOICE { 3934 otherName [0] AnotherName, 3935 rfc822Name [1] IA5String, 3936 dNSName [2] IA5String, 3937 x400Address [3] ORAddress, 3938 directoryName [4] Name, 3939 ediPartyName [5] EDIPartyName, 3940 uniformResourceIdentifier [6] IA5String, 3941 iPAddress [7] OCTET STRING, 3942 registeredID [8] OBJECT IDENTIFIER } 3944 -- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as 3945 -- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax 3947 AnotherName ::= SEQUENCE { 3948 type-id OBJECT IDENTIFIER, 3949 value [0] EXPLICIT ANY DEFINED BY type-id } 3951 EDIPartyName ::= SEQUENCE { 3952 nameAssigner [0] DirectoryString OPTIONAL, 3953 partyName [1] DirectoryString } 3955 -- issuer alternative name extension OID and syntax 3957 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 3959 IssuerAltName ::= GeneralNames 3961 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 3963 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 3965 -- basic constraints extension OID and syntax 3967 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 3969 BasicConstraints ::= SEQUENCE { 3970 cA BOOLEAN DEFAULT FALSE, 3971 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 3973 -- name constraints extension OID and syntax 3975 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 3977 NameConstraints ::= SEQUENCE { 3978 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 3979 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 3981 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 3983 GeneralSubtree ::= SEQUENCE { 3984 base GeneralName, 3985 minimum [0] BaseDistance DEFAULT 0, 3986 maximum [1] BaseDistance OPTIONAL } 3988 BaseDistance ::= INTEGER (0..MAX) 3990 -- policy constraints extension OID and syntax 3992 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } 3994 PolicyConstraints ::= SEQUENCE { 3995 requireExplicitPolicy [0] SkipCerts OPTIONAL, 3996 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 3998 SkipCerts ::= INTEGER (0..MAX) 4000 -- CRL distribution points extension OID and syntax 4002 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31} 4004 CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 4006 DistributionPoint ::= SEQUENCE { 4007 distributionPoint [0] DistributionPointName OPTIONAL, 4008 reasons [1] ReasonFlags OPTIONAL, 4009 cRLIssuer [2] GeneralNames OPTIONAL } 4011 DistributionPointName ::= CHOICE { 4012 fullName [0] GeneralNames, 4013 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 4015 ReasonFlags ::= BIT STRING { 4016 unused (0), 4017 keyCompromise (1), 4018 cACompromise (2), 4019 affiliationChanged (3), 4020 superseded (4), 4021 cessationOfOperation (5), 4022 certificateHold (6) } 4024 -- extended key usage extension OID and syntax 4026 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 4028 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 4030 KeyPurposeId ::= OBJECT IDENTIFIER 4032 -- extended key purpose OIDs 4033 id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } 4034 id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } 4035 id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } 4036 id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } 4037 id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 } 4038 id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 } 4039 id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 } 4040 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 4042 -- authority info access 4043 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 4045 AuthorityInfoAccessSyntax ::= 4046 SEQUENCE SIZE (1..MAX) OF AccessDescription 4048 AccessDescription ::= SEQUENCE { 4049 accessMethod OBJECT IDENTIFIER, 4050 accessLocation GeneralName } 4052 -- CRL number extension OID and syntax 4054 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 4056 CRLNumber ::= INTEGER (0..MAX) 4058 -- issuing distribution point extension OID and syntax 4060 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 4062 IssuingDistributionPoint ::= SEQUENCE { 4063 distributionPoint [0] DistributionPointName OPTIONAL, 4064 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 4065 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 4066 onlySomeReasons [3] ReasonFlags OPTIONAL, 4067 indirectCRL [4] BOOLEAN DEFAULT FALSE } 4069 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 4071 -- deltaCRLIndicator ::= BaseCRLNumber 4073 BaseCRLNumber ::= CRLNumber 4075 -- CRL reasons extension OID and syntax 4077 id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 } 4079 CRLReason ::= ENUMERATED { 4080 unspecified (0), 4081 keyCompromise (1), 4082 cACompromise (2), 4083 affiliationChanged (3), 4084 superseded (4), 4085 cessationOfOperation (5), 4086 certificateHold (6), 4087 removeFromCRL (8) } 4089 -- certificate issuer CRL entry extension OID and syntax 4090 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } 4092 CertificateIssuer ::= GeneralNames 4094 -- hold instruction extension OID and syntax 4096 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 4098 HoldInstructionCode ::= OBJECT IDENTIFIER 4100 -- ANSI x9 holdinstructions 4102 -- ANSI x9 arc holdinstruction arc 4103 holdInstruction OBJECT IDENTIFIER ::= 4104 {joint-iso-itu-t(2) member-body(2) us(840) x9cm(10040) 2} 4106 -- ANSI X9 holdinstructions referenced by this standard 4107 id-holdinstruction-none OBJECT IDENTIFIER ::= 4108 {holdInstruction 1} -- deprecated 4109 id-holdinstruction-callissuer OBJECT IDENTIFIER ::= 4110 {holdInstruction 2} 4111 id-holdinstruction-reject OBJECT IDENTIFIER ::= 4112 {holdInstruction 3} 4114 -- invalidity date CRL entry extension OID and syntax 4116 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 4118 InvalidityDate ::= GeneralizedTime 4120 END 4121 Appendix B. 1993 ASN.1 Structures and OIDs 4123 B.1 Explicitly Tagged Module, 1993 Syntax 4125 PKIX1Explicit93 {iso(1) identified-organization(3) dod(6) internet(1) 4126 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-93(3)} 4128 DEFINITIONS EXPLICIT TAGS ::= 4130 BEGIN 4132 -- EXPORTS ALL -- 4134 IMPORTS 4135 authorityKeyIdentifier, subjectKeyIdentifier, keyUsage, 4136 extendedKeyUsage, privateKeyUsagePeriod, certificatePolicies, 4137 policyMappings, subjectAltName, issuerAltName, 4138 basicConstraints, nameConstraints, policyConstraints, 4139 cRLDistributionPoints, subjectDirectoryAttributes, 4140 cRLNumber, reasonCode, instructionCode, invalidityDate, 4141 issuingDistributionPoint, certificateIssuer, 4142 deltaCRLIndicator, authorityInfoAccess, id-ce 4143 FROM PKIX1Implicit93 {iso(1) identified-organization(3) 4144 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 4145 id-mod(0) id-pkix1-implicit-93(4)} ; 4147 -- 4148 -- Locally defined OIDs -- 4150 id-pkix OBJECT IDENTIFIER ::= 4151 { iso(1) identified-organization(3) dod(6) internet(1) 4152 security(5) mechanisms(5) pkix(7) } 4154 -- PKIX arcs 4155 -- arc for private certificate extensions 4156 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 4157 -- arc for policy qualifier types 4158 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 4159 -- arc for extended key purpose OIDS 4160 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 4161 -- arc for access descriptors 4162 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 4164 -- policyQualifierIds for Internet policy qualifiers 4165 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 4166 -- OID for CPS qualifier 4168 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 4169 -- OID for user notice qualifier 4171 -- based on excerpts from AuthenticationFramework 4172 -- {joint-iso-ccitt ds(5) modules(1) authenticationFramework(7) 2} 4174 -- Public Key Certificate -- 4176 Certificate ::= SIGNED { SEQUENCE { 4177 version [0] Version DEFAULT v1, 4178 serialNumber CertificateSerialNumber, 4179 signature AlgorithmIdentifier, 4180 issuer Name, 4181 validity Validity, 4182 subject Name, 4183 subjectPublicKeyInfo SubjectPublicKeyInfo, 4184 issuerUniqueIdentifier [1] IMPLICIT UniqueIdentifier OPTIONAL, 4185 ---if present, version shall be v2 or v3-- 4186 subjectUniqueIdentifier [2] IMPLICIT UniqueIdentifier OPTIONAL, 4187 ---if present, version shall be v2 or v3-- 4188 extensions [3] Extensions OPTIONAL 4189 --if present, version shall be v3--} } 4191 UniqueIdentifier ::= BIT STRING 4193 Version ::= INTEGER { v1(0), v2(1), v3(2) } 4195 CertificateSerialNumber ::= INTEGER 4197 Validity ::= SEQUENCE { 4198 notBefore Time, 4199 notAfter Time } 4201 Time ::= CHOICE { 4202 utcTime UTCTime, 4203 generalTime GeneralizedTime } 4205 SubjectPublicKeyInfo ::= SEQUENCE{ 4206 algorithm AlgorithmIdentifier, 4207 subjectPublicKey BIT STRING} 4209 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 4211 Extension ::= SEQUENCE { 4212 extnId EXTENSION.&id ({ExtensionSet}), 4213 critical BOOLEAN DEFAULT FALSE, 4214 extnValue OCTET STRING } 4215 -- contains a DER encoding of a value of type 4216 -- &ExtnType for the 4217 -- extension object identified by extnId -- 4219 -- The following information object set is defined to constrain the 4220 -- set of legal certificate extensions. 4222 ExtensionSet EXTENSION ::= { authorityKeyIdentifier | 4223 subjectKeyIdentifier | 4224 keyUsage | 4225 extendedKeyUsage | 4226 privateKeyUsagePeriod | 4227 certificatePolicies | 4228 policyMappings | 4229 subjectAltName | 4230 issuerAltName | 4231 basicConstraints | 4232 nameConstraints | 4233 policyConstraints | 4234 cRLDistributionPoints | 4235 subjectDirectoryAttributes | 4236 authorityInfoAccess } 4238 EXTENSION ::= CLASS { 4239 &id OBJECT IDENTIFIER UNIQUE, 4240 &ExtnType } 4241 WITH SYNTAX { 4242 SYNTAX &ExtnType 4243 IDENTIFIED BY &id } 4245 -- Certificate Revocation List -- 4247 CertificateList ::= SIGNED { SEQUENCE { 4248 version Version OPTIONAL, -- if present, shall be v2 4249 signature AlgorithmIdentifier, 4250 issuer Name, 4251 thisUpdate Time, 4252 nextUpdate Time OPTIONAL, 4253 revokedCertificates SEQUENCE OF SEQUENCE { 4254 userCertificate CertificateSerialNumber, 4255 revocationDate Time, 4256 crlEntryExtensions EntryExtensions OPTIONAL } OPTIONAL, 4257 crlExtensions [0] CRLExtensions OPTIONAL }} 4259 CRLExtensions ::= SEQUENCE SIZE (1..MAX) OF CRLExtension 4261 CRLExtension ::= SEQUENCE { 4262 extnId EXTENSION.&id ({CRLExtensionSet}), 4263 critical BOOLEAN DEFAULT FALSE, 4264 extnValue OCTET STRING } 4265 -- contains a DER encoding of a value of type 4266 -- &ExtnType for the 4267 -- extension object identified by extnId -- 4269 -- The following information object set is defined to constrain the 4270 -- set of legal CRL extensions. 4272 CRLExtensionSet EXTENSION ::= { authorityKeyIdentifier | 4273 issuerAltName | 4274 cRLNumber | 4275 deltaCRLIndicator | 4276 issuingDistributionPoint } 4278 -- EXTENSION defined above for certificates 4280 EntryExtensions ::= SEQUENCE SIZE (1..MAX) OF EntryExtension 4282 EntryExtension ::= SEQUENCE { 4283 extnId EXTENSION.&id ({EntryExtensionSet}), 4284 critical BOOLEAN DEFAULT FALSE, 4285 extnValue OCTET STRING } 4286 -- contains a DER encoding of a value of type 4287 -- &ExtnType for the 4288 -- extension object identified by extnId -- 4290 -- The following information object set is defined to constrain the 4291 -- set of legal CRL entry extensions. 4293 EntryExtensionSet EXTENSION ::= { reasonCode | 4294 instructionCode | 4295 invalidityDate | 4296 certificateIssuer } 4298 -- information object classes used in the defintion -- 4299 -- of certificates and CRLs -- 4301 -- Parameterized Type SIGNED -- 4303 SIGNED { ToBeSigned } ::= SEQUENCE { 4304 toBeSigned ToBeSigned, 4305 algorithm AlgorithmIdentifier, 4306 signature BIT STRING 4307 } 4309 -- Definition of AlgorithmIdentifier 4310 -- ISO definition was: 4311 -- 4312 -- AlgorithmIdentifier ::= SEQUENCE { 4313 -- algorithm ALGORITHM.&id({SupportedAlgorithms}), 4314 -- parameters ALGORITHM.&Type({SupportedAlgorithms} 4315 -- { @algorithm}) OPTIONAL } 4316 -- Definition of ALGORITHM 4317 -- ALGORITHM ::= TYPE-IDENTIFIER 4319 -- The following PKIX definition replaces the X.509 definition 4320 -- 4322 AlgorithmIdentifier ::= SEQUENCE { 4323 algorithm ALGORITHM-ID.&id({SupportedAlgorithms}), 4324 parameters ALGORITHM-ID.&Type({SupportedAlgorithms} 4325 { @algorithm}) OPTIONAL } 4327 -- Definition of ALGORITHM-ID 4329 ALGORITHM-ID ::= CLASS { 4330 &id OBJECT IDENTIFIER UNIQUE, 4331 &Type OPTIONAL 4332 } 4333 WITH SYNTAX { OID &id [PARMS &Type] } 4335 -- The definition of SupportedAlgorithms may be modified as this 4336 -- document does not specify a mandatory algorithm set. In addition, 4337 -- the set is specified as extensible, since additional algorithms 4338 -- may be supported 4340 SupportedAlgorithms ALGORITHM-ID ::= { ..., -- extensible 4341 rsaPublicKey | 4342 rsaSHA-1 | 4343 rsaMD5 | 4344 rsaMD2 | 4345 dssPublicKey | 4346 dsaSHA-1 | 4347 dhPublicKey } 4349 -- OIDs and parameter structures for ALGORITHM-IDs used 4350 -- in this specification 4352 rsaPublicKey ALGORITHM-ID ::= { OID rsaEncryption PARMS NULL } 4354 rsaSHA-1 ALGORITHM-ID ::= { OID sha1WithRSAEncryption PARMS NULL } 4356 rsaMD5 ALGORITHM-ID ::= { OID md5WithRSAEncryption PARMS NULL } 4358 rsaMD2 ALGORITHM-ID ::= { OID md2WithRSAEncryption PARMS NULL } 4359 dssPublicKey ALGORITHM-ID ::= { OID id-dsa PARMS Dss-Parms } 4361 dsaSHA-1 ALGORITHM-ID ::= { OID id-dsa-with-sha1 } 4363 dhPublicKey ALGORITHM-ID ::= {OID dhpublicnumber PARMS DomainParameters} 4365 -- algorithm identifiers and parameter structures 4367 pkcs-1 OBJECT IDENTIFIER ::= { 4368 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 } 4370 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } 4372 md2WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 2 } 4374 md5WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 4 } 4376 sha1WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 5 } 4378 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { 4379 iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 3 } 4381 Dss-Sig-Value ::= SEQUENCE { 4382 r INTEGER, 4383 s INTEGER } 4385 dhpublicnumber OBJECT IDENTIFIER ::= { 4386 iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 } 4388 DomainParameters ::= SEQUENCE { 4389 p INTEGER, -- odd prime, p=jq +1 4390 g INTEGER, -- generator, g 4391 q INTEGER, -- factor of p-1 4392 j INTEGER OPTIONAL, -- subgroup factor, j>= 2 4393 validationParms ValidationParms OPTIONAL } 4395 ValidationParms ::= SEQUENCE { 4396 seed BIT STRING, 4397 pgenCounter INTEGER } 4399 id-dsa OBJECT IDENTIFIER ::= { 4400 iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 } 4402 Dss-Parms ::= SEQUENCE { 4403 p INTEGER, 4404 q INTEGER, 4405 g INTEGER } 4406 -- The ASN.1 in this section supports the Name type 4407 -- and the directoryAttribute extension 4409 -- attribute data types -- 4411 Attribute ::= SEQUENCE { 4412 type ATTRIBUTE.&id ({SupportedAttributes}), 4413 values SET SIZE (1 .. MAX) OF ATTRIBUTE.&Type 4414 ({SupportedAttributes}{@type})} 4416 AttributeTypeAndValue ::= SEQUENCE { 4417 type ATTRIBUTE.&id ({SupportedAttributes}), 4418 value ATTRIBUTE.&Type ({SupportedAttributes}{@type})} 4420 -- naming data types -- 4422 Name ::= CHOICE { -- only one possibility for now -- 4423 rdnSequence RDNSequence } 4425 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 4427 RelativeDistinguishedName ::= 4428 SET SIZE (1 .. MAX) OF AttributeTypeAndValue 4430 ID ::= OBJECT IDENTIFIER 4432 -- ATTRIBUTE information object class specification 4433 -- Note: This has been greatly simplified for PKIX !! 4435 ATTRIBUTE ::= CLASS { 4436 &Type, 4437 &id OBJECT IDENTIFIER UNIQUE } 4438 WITH SYNTAX { 4439 WITH SYNTAX &Type ID &id } 4441 -- suggested naming attributes 4442 -- Definition of the following information object set may be 4443 -- augmented to meet local requirements. Note that deleting 4444 -- members of the set may prevent interoperability with 4445 -- conforming implementations. 4447 SupportedAttributes ATTRIBUTE ::= { 4448 name | commonName | surname | givenName | initials | 4449 generationQualifier | dnQualifier | countryName | 4450 localityName | stateOrProvinceName | organizationName | 4451 organizationalUnitName | title | pkcs9email } 4453 name ATTRIBUTE ::= { 4454 WITH SYNTAX DirectoryString { ub-name } 4455 ID id-at-name } 4457 commonName ATTRIBUTE ::= { 4458 WITH SYNTAX DirectoryString {ub-common-name} 4459 ID id-at-commonName } 4461 surname ATTRIBUTE ::= { 4462 WITH SYNTAX DirectoryString {ub-name} 4463 ID id-at-surname } 4465 givenName ATTRIBUTE ::= { 4466 WITH SYNTAX DirectoryString {ub-name} 4467 ID id-at-givenName } 4469 initials ATTRIBUTE ::= { 4470 WITH SYNTAX DirectoryString {ub-name} 4471 ID id-at-initials } 4473 generationQualifier ATTRIBUTE ::= { 4474 WITH SYNTAX DirectoryString {ub-name} 4475 ID id-at-generationQualifier} 4477 dnQualifier ATTRIBUTE ::= { 4478 WITH SYNTAX PrintableString 4479 ID id-at-dnQualifier } 4481 countryName ATTRIBUTE ::= { 4482 WITH SYNTAX PrintableString (SIZE (2)) 4483 -- IS 3166 codes only 4484 ID id-at-countryName } 4486 localityName ATTRIBUTE ::= { 4487 WITH SYNTAX DirectoryString {ub-locality-name} 4488 ID id-at-localityName } 4490 stateOrProvinceName ATTRIBUTE ::= { 4491 WITH SYNTAX DirectoryString {ub-state-name} 4492 ID id-at-stateOrProvinceName } 4494 organizationName ATTRIBUTE ::= { 4495 WITH SYNTAX DirectoryString {ub-organization-name} 4496 ID id-at-organizationName } 4498 organizationalUnitName ATTRIBUTE ::= { 4499 WITH SYNTAX DirectoryString {ub-organizational-unit-name} 4500 ID id-at-organizationalUnitName } 4502 title ATTRIBUTE ::= { 4503 WITH SYNTAX DirectoryString {ub-title} 4504 ID id-at-title } 4506 -- Legacy attributes 4508 pkcs9email ATTRIBUTE ::= { 4509 WITH SYNTAX PHGString, 4510 ID emailAddress } 4512 PHGString ::= IA5String (SIZE(1..ub-emailaddress-length)) 4514 pkcs-9 OBJECT IDENTIFIER ::= 4515 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 } 4517 emailAddress OBJECT IDENTIFIER ::= { pkcs-9 1 } 4519 -- object identifiers for Name type and directory attribute support 4521 -- Object identifier assignments -- 4523 id-at OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 4} 4525 -- Attributes -- 4527 id-at-commonName OBJECT IDENTIFIER ::= {id-at 3} 4528 id-at-surname OBJECT IDENTIFIER ::= {id-at 4} 4529 id-at-countryName OBJECT IDENTIFIER ::= {id-at 6} 4530 id-at-localityName OBJECT IDENTIFIER ::= {id-at 7} 4531 id-at-stateOrProvinceName OBJECT IDENTIFIER ::= {id-at 8} 4532 id-at-organizationName OBJECT IDENTIFIER ::= {id-at 10} 4533 id-at-organizationalUnitName OBJECT IDENTIFIER ::= {id-at 11} 4534 id-at-title OBJECT IDENTIFIER ::= {id-at 12} 4535 id-at-name OBJECT IDENTIFIER ::= {id-at 41} 4536 id-at-givenName OBJECT IDENTIFIER ::= {id-at 42} 4537 id-at-initials OBJECT IDENTIFIER ::= {id-at 43} 4538 id-at-generationQualifier OBJECT IDENTIFIER ::= {id-at 44} 4539 id-at-dnQualifier OBJECT IDENTIFIER ::= {id-at 46} 4541 -- Directory string type, used extensively in Name types -- 4543 DirectoryString { INTEGER:maxSize } ::= CHOICE { 4544 teletexString TeletexString (SIZE (1..maxSize)), 4545 printableString PrintableString (SIZE (1..maxSize)), 4546 universalString UniversalString (SIZE (1..maxSize)), 4547 bmpString BMPString (SIZE(1..maxSize)), 4548 utf8String UTF8String (SIZE(1..maxSize)) 4549 } 4551 -- End of ASN.1 for Name type and directory attribute support -- 4553 -- The ASN.1 in this section supports X.400 style names -- 4554 -- for implementations that use the x400Address component -- 4555 -- of GeneralName. -- 4557 ORAddress ::= SEQUENCE { 4558 built-in-standard-attributes BuiltInStandardAttributes, 4559 built-in-domain-defined-attributes 4560 BuiltInDomainDefinedAttributes OPTIONAL, 4561 -- see also teletex-domain-defined-attributes 4562 extension-attributes ExtensionAttributes OPTIONAL } 4564 -- The OR-address is semantically absent from the OR-name if the 4565 -- built-in-standard-attribute sequence is empty and the 4566 -- built-in-domain-defined-attributes and extension-attributes are 4567 -- both omitted. 4569 -- Built-in Standard Attributes 4571 BuiltInStandardAttributes ::= SEQUENCE { 4572 country-name CountryName OPTIONAL, 4573 administration-domain-name AdministrationDomainName OPTIONAL, 4574 network-address [0] NetworkAddress OPTIONAL, 4575 -- see also extended-network-address 4576 terminal-identifier [1] TerminalIdentifier OPTIONAL, 4577 private-domain-name [2] PrivateDomainName OPTIONAL, 4578 organization-name [3] OrganizationName OPTIONAL, 4579 -- see also teletex-organization-name 4580 numeric-user-identifier [4] NumericUserIdentifier OPTIONAL, 4581 personal-name [5] PersonalName OPTIONAL, 4582 -- see also teletex-personal-name 4583 organizational-unit-names [6] OrganizationalUnitNames OPTIONAL 4584 -- see also teletex-organizational-unit-names -- } 4586 CountryName ::= [APPLICATION 1] CHOICE { 4587 x121-dcc-code NumericString 4588 (SIZE (ub-country-name-numeric-length)), 4589 iso-3166-alpha2-code PrintableString 4590 (SIZE (ub-country-name-alpha-length)) } 4592 AdministrationDomainName ::= [APPLICATION 2] CHOICE { 4593 numeric NumericString (SIZE (0..ub-domain-name-length)), 4594 printable PrintableString (SIZE (0..ub-domain-name-length)) } 4596 NetworkAddress ::= X121Address 4597 -- see also extended-network-address 4598 X121Address ::= NumericString (SIZE (1..ub-x121-address-length)) 4600 TerminalIdentifier ::= PrintableString (SIZE (1..ub-terminal-id-length)) 4602 PrivateDomainName ::= CHOICE { 4603 numeric NumericString (SIZE (1..ub-domain-name-length)), 4604 printable PrintableString (SIZE (1..ub-domain-name-length)) } 4606 OrganizationName ::= PrintableString 4607 (SIZE (1..ub-organization-name-length)) 4608 -- see also teletex-organization-name 4610 NumericUserIdentifier ::= NumericString 4611 (SIZE (1..ub-numeric-user-id-length)) 4613 PersonalName ::= SET { 4614 surname [0] PrintableString (SIZE (1..ub-surname-length)), 4615 given-name [1] PrintableString 4616 (SIZE (1..ub-given-name-length)) OPTIONAL, 4617 initials [2] PrintableString 4618 (SIZE (1..ub-initials-length)) OPTIONAL, 4619 generation-qualifier [3] PrintableString 4620 (SIZE (1..ub-generation-qualifier-length)) OPTIONAL} 4621 -- see also teletex-personal-name 4623 OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units) 4624 OF OrganizationalUnitName 4625 -- see also teletex-organizational-unit-names 4627 OrganizationalUnitName ::= PrintableString (SIZE 4628 (1..ub-organizational-unit-name-length)) 4630 -- Built-in Domain-defined Attributes 4631 BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE 4632 (1..ub-domain-defined-attributes) OF 4633 BuiltInDomainDefinedAttribute 4635 BuiltInDomainDefinedAttribute ::= SEQUENCE { 4636 type PrintableString (SIZE 4637 (1..ub-domain-defined-attribute-type-length)), 4638 value PrintableString (SIZE 4639 (1..ub-domain-defined-attribute-value-length)) } 4641 -- Extension Attributes 4643 ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) 4644 OF ExtensionAttribute 4645 ExtensionAttribute ::= SEQUENCE { 4646 extension-attribute-type [0] EXTENSION-ATTRIBUTE.&id 4647 ({ExtensionAttributeTable}), 4648 extension-attribute-value [1] EXTENSION-ATTRIBUTE.&Type 4649 ({ExtensionAttributeTable} {@extension-attribute-type}) } 4651 EXTENSION-ATTRIBUTE ::= CLASS { 4652 &id INTEGER (0..ub-extension-attributes) UNIQUE, 4653 &Type } 4654 WITH SYNTAX {&Type IDENTIFIED BY &id} 4656 ExtensionAttributeTable EXTENSION-ATTRIBUTE ::= { 4657 common-name | 4658 teletex-common-name | 4659 teletex-organization-name | 4660 teletex-personal-name | 4661 teletex-organizational-unit-names | 4662 teletex-domain-defined-attributes | 4663 pds-name | 4664 physical-delivery-country-name | 4665 postal-code | 4666 physical-delivery-office-name | 4667 physical-delivery-office-number | 4668 extension-OR-address-components | 4669 physical-delivery-personal-name | 4670 physical-delivery-organization-name | 4671 extension-physical-delivery-address-components | 4672 unformatted-postal-address | 4673 street-address | 4674 post-office-box-address | 4675 poste-restante-address | 4676 unique-postal-name | 4677 local-postal-attributes | 4678 extended-network-address | 4679 terminal-type } 4681 -- Extension Standard Attributes 4683 common-name EXTENSION-ATTRIBUTE ::= {CommonName IDENTIFIED BY 1} 4685 CommonName ::= PrintableString (SIZE (1..ub-common-name-length)) 4687 teletex-common-name EXTENSION-ATTRIBUTE ::= 4688 {TeletexCommonName IDENTIFIED BY 2} 4690 TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length)) 4692 teletex-organization-name EXTENSION-ATTRIBUTE ::= 4693 {TeletexOrganizationName IDENTIFIED BY 3} 4695 TeletexOrganizationName ::= 4696 TeletexString (SIZE (1..ub-organization-name-length)) 4698 teletex-personal-name EXTENSION-ATTRIBUTE ::= 4699 {TeletexPersonalName IDENTIFIED BY 4} 4701 TeletexPersonalName ::= SET { 4702 surname [0] TeletexString (SIZE (1..ub-surname-length)), 4703 given-name [1] TeletexString 4704 (SIZE (1..ub-given-name-length)) OPTIONAL, 4705 initials [2] TeletexString (SIZE (1..ub-initials-length)) OPTIONAL, 4706 generation-qualifier [3] TeletexString (SIZE 4707 (1..ub-generation-qualifier-length)) OPTIONAL } 4709 teletex-organizational-unit-names EXTENSION-ATTRIBUTE ::= 4710 {TeletexOrganizationalUnitNames IDENTIFIED BY 5} 4712 TeletexOrganizationalUnitNames ::= SEQUENCE SIZE 4713 (1..ub-organizational-units) OF TeletexOrganizationalUnitName 4715 TeletexOrganizationalUnitName ::= TeletexString 4716 (SIZE (1..ub-organizational-unit-name-length)) 4718 pds-name EXTENSION-ATTRIBUTE ::= {PDSName IDENTIFIED BY 7} 4720 PDSName ::= PrintableString (SIZE (1..ub-pds-name-length)) 4722 physical-delivery-country-name EXTENSION-ATTRIBUTE ::= 4723 {PhysicalDeliveryCountryName IDENTIFIED BY 8} 4725 PhysicalDeliveryCountryName ::= CHOICE { 4726 x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)), 4727 iso-3166-alpha2-code PrintableString 4728 (SIZE (ub-country-name-alpha-length)) } 4730 postal-code EXTENSION-ATTRIBUTE ::= {PostalCode IDENTIFIED BY 9} 4732 PostalCode ::= CHOICE { 4733 numeric-code NumericString (SIZE (1..ub-postal-code-length)), 4734 printable-code PrintableString (SIZE (1..ub-postal-code-length)) } 4736 physical-delivery-office-name EXTENSION-ATTRIBUTE ::= 4737 {PhysicalDeliveryOfficeName IDENTIFIED BY 10} 4739 PhysicalDeliveryOfficeName ::= PDSParameter 4741 physical-delivery-office-number EXTENSION-ATTRIBUTE ::= 4742 {PhysicalDeliveryOfficeNumber IDENTIFIED BY 11} 4744 PhysicalDeliveryOfficeNumber ::= PDSParameter 4746 extension-OR-address-components EXTENSION-ATTRIBUTE ::= 4747 {ExtensionORAddressComponents IDENTIFIED BY 12} 4749 ExtensionORAddressComponents ::= PDSParameter 4751 physical-delivery-personal-name EXTENSION-ATTRIBUTE ::= 4752 {PhysicalDeliveryPersonalName IDENTIFIED BY 13} 4754 PhysicalDeliveryPersonalName ::= PDSParameter 4756 physical-delivery-organization-name EXTENSION-ATTRIBUTE ::= 4757 {PhysicalDeliveryOrganizationName IDENTIFIED BY 14} 4759 PhysicalDeliveryOrganizationName ::= PDSParameter 4761 extension-physical-delivery-address-components EXTENSION-ATTRIBUTE ::= 4762 {ExtensionPhysicalDeliveryAddressComponents IDENTIFIED BY 15} 4764 ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter 4766 unformatted-postal-address EXTENSION-ATTRIBUTE ::= 4767 {UnformattedPostalAddress IDENTIFIED BY 16} 4769 UnformattedPostalAddress ::= SET { 4770 printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) OF 4771 PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL, 4772 teletex-string TeletexString (SIZE 4773 (1..ub-unformatted-address-length)) OPTIONAL } 4775 street-address EXTENSION-ATTRIBUTE ::= 4776 {StreetAddress IDENTIFIED BY 17} 4778 StreetAddress ::= PDSParameter 4780 post-office-box-address EXTENSION-ATTRIBUTE ::= 4781 {PostOfficeBoxAddress IDENTIFIED BY 18} 4783 PostOfficeBoxAddress ::= PDSParameter 4785 poste-restante-address EXTENSION-ATTRIBUTE ::= 4786 {PosteRestanteAddress IDENTIFIED BY 19} 4788 PosteRestanteAddress ::= PDSParameter 4790 unique-postal-name EXTENSION-ATTRIBUTE ::= 4791 {UniquePostalName IDENTIFIED BY 20} 4793 UniquePostalName ::= PDSParameter 4795 local-postal-attributes EXTENSION-ATTRIBUTE ::= 4796 {LocalPostalAttributes IDENTIFIED BY 21} 4798 LocalPostalAttributes ::= PDSParameter 4800 PDSParameter ::= SET { 4801 printable-string PrintableString 4802 (SIZE(1..ub-pds-parameter-length)) OPTIONAL, 4803 teletex-string TeletexString 4804 (SIZE(1..ub-pds-parameter-length)) OPTIONAL } 4806 extended-network-address EXTENSION-ATTRIBUTE ::= 4807 {ExtendedNetworkAddress IDENTIFIED BY 22} 4809 ExtendedNetworkAddress ::= CHOICE { 4810 e163-4-address SEQUENCE { 4811 number [0] NumericString 4812 (SIZE (1..ub-e163-4-number-length)), 4813 sub-address [1] NumericString 4814 (SIZE (1..ub-e163-4-sub-address-length)) OPTIONAL}, 4815 psap-address [0] PresentationAddress } 4817 PresentationAddress ::= SEQUENCE { 4818 pSelector [0] EXPLICIT OCTET STRING OPTIONAL, 4819 sSelector [1] EXPLICIT OCTET STRING OPTIONAL, 4820 tSelector [2] EXPLICIT OCTET STRING OPTIONAL, 4821 nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING} 4823 terminal-type EXTENSION-ATTRIBUTE ::= {TerminalType IDENTIFIED BY 23} 4825 TerminalType ::= INTEGER { 4826 telex (3), 4827 teletex (4), 4828 g3-facsimile (5), 4829 g4-facsimile (6), 4830 ia5-terminal (7), 4831 videotex (8) } (0..ub-integer-options) 4833 -- Extension Domain-defined Attributes 4835 teletex-domain-defined-attributes EXTENSION-ATTRIBUTE ::= 4836 {TeletexDomainDefinedAttributes IDENTIFIED BY 6} 4838 TeletexDomainDefinedAttributes ::= SEQUENCE SIZE 4839 (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute 4841 TeletexDomainDefinedAttribute ::= SEQUENCE { 4842 type TeletexString 4843 (SIZE (1..ub-domain-defined-attribute-type-length)), 4844 value TeletexString 4845 (SIZE (1..ub-domain-defined-attribute-value-length)) } 4847 -- specifications of Upper Bounds 4848 -- shall be regarded as mandatory 4849 -- from Annex B of ITU-T X.411 4850 -- Reference Definition of MTS Parameter Upper Bounds 4852 -- Upper Bounds 4853 ub-name INTEGER ::= 32768 4854 ub-common-name INTEGER ::= 64 4855 ub-locality-name INTEGER ::= 128 4856 ub-state-name INTEGER ::= 128 4857 ub-organization-name INTEGER ::= 64 4858 ub-organizational-unit-name INTEGER ::= 64 4859 ub-title INTEGER ::= 64 4860 ub-match INTEGER ::= 128 4862 ub-emailaddress-length INTEGER ::= 128 4864 ub-common-name-length INTEGER ::= 64 4865 ub-country-name-alpha-length INTEGER ::= 2 4866 ub-country-name-numeric-length INTEGER ::= 3 4867 ub-domain-defined-attributes INTEGER ::= 4 4868 ub-domain-defined-attribute-type-length INTEGER ::= 8 4869 ub-domain-defined-attribute-value-length INTEGER ::= 128 4870 ub-domain-name-length INTEGER ::= 16 4871 ub-extension-attributes INTEGER ::= 256 4872 ub-e163-4-number-length INTEGER ::= 15 4873 ub-e163-4-sub-address-length INTEGER ::= 40 4874 ub-generation-qualifier-length INTEGER ::= 3 4875 ub-given-name-length INTEGER ::= 16 4876 ub-initials-length INTEGER ::= 5 4877 ub-integer-options INTEGER ::= 256 4878 ub-numeric-user-id-length INTEGER ::= 32 4879 ub-organization-name-length INTEGER ::= 64 4880 ub-organizational-unit-name-length INTEGER ::= 32 4881 ub-organizational-units INTEGER ::= 4 4882 ub-pds-name-length INTEGER ::= 16 4883 ub-pds-parameter-length INTEGER ::= 30 4884 ub-pds-physical-address-lines INTEGER ::= 6 4885 ub-postal-code-length INTEGER ::= 16 4886 ub-surname-length INTEGER ::= 40 4887 ub-terminal-id-length INTEGER ::= 24 4888 ub-unformatted-address-length INTEGER ::= 180 4889 ub-x121-address-length INTEGER ::= 16 4891 -- Note - upper bounds on TeletexString are measured in characters. 4892 -- A significantly greater number of octets will be required to hold 4893 -- such a value. As a minimum, 16 octets, or twice the specified upper 4894 -- bound, whichever is the larger, should be allowed. 4896 END 4897 B.2 Implicitly Tagged Module, 1993 Syntax 4899 PKIX1Implicit93 {iso(1) identified-organization(3) dod(6) internet(1) 4900 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-93(4)} 4902 DEFINITIONS IMPLICIT TAGS::= 4904 BEGIN 4906 --EXPORTS ALL -- 4908 IMPORTS 4909 id-pe, id-qt, id-kp, id-ad, id-qt-unotice, 4910 ORAddress, Name, RelativeDistinguishedName, 4911 CertificateSerialNumber, CertificateList, 4912 AlgorithmIdentifier, ub-name, DirectoryString, 4913 Attribute, EXTENSION 4914 FROM PKIX1Explicit93 {iso(1) identified-organization(3) 4915 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 4916 id-mod(0) id-pkix1-explicit-93(3)}; 4918 -- Key and policy information extensions -- 4920 authorityKeyIdentifier EXTENSION ::= { 4921 SYNTAX AuthorityKeyIdentifier 4922 IDENTIFIED BY id-ce-authorityKeyIdentifier } 4924 AuthorityKeyIdentifier ::= SEQUENCE { 4925 keyIdentifier [0] KeyIdentifier OPTIONAL, 4926 authorityCertIssuer [1] GeneralNames OPTIONAL, 4927 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 4928 ( WITH COMPONENTS {..., authorityCertIssuer PRESENT, 4929 authorityCertSerialNumber PRESENT} | 4930 WITH COMPONENTS {..., authorityCertIssuer ABSENT, 4931 authorityCertSerialNumber ABSENT} ) 4933 KeyIdentifier ::= OCTET STRING 4935 subjectKeyIdentifier EXTENSION ::= { 4936 SYNTAX SubjectKeyIdentifier 4937 IDENTIFIED BY id-ce-subjectKeyIdentifier } 4939 SubjectKeyIdentifier ::= KeyIdentifier 4941 keyUsage EXTENSION ::= { 4942 SYNTAX KeyUsage 4943 IDENTIFIED BY id-ce-keyUsage } 4945 KeyUsage ::= BIT STRING { 4946 digitalSignature (0), 4947 nonRepudiation (1), 4948 keyEncipherment (2), 4949 dataEncipherment (3), 4950 keyAgreement (4), 4951 keyCertSign (5), 4952 cRLSign (6), 4953 encipherOnly (7), 4954 decipherOnly (8) } 4956 extendedKeyUsage EXTENSION ::= { 4957 SYNTAX SEQUENCE SIZE (1..MAX) OF KeyPurposeId 4958 IDENTIFIED BY id-ce-extKeyUsage } 4960 KeyPurposeId ::= OBJECT IDENTIFIER 4962 -- PKIX-defined extended key purpose OIDs 4963 id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } 4964 id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } 4965 id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } 4966 id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } 4967 id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 } 4968 id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 } 4969 id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 } 4970 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 4972 privateKeyUsagePeriod EXTENSION ::= { 4973 SYNTAX PrivateKeyUsagePeriod 4974 IDENTIFIED BY { id-ce-privateKeyUsagePeriod } } 4976 PrivateKeyUsagePeriod ::= SEQUENCE { 4977 notBefore [0] GeneralizedTime OPTIONAL, 4978 notAfter [1] GeneralizedTime OPTIONAL } 4979 ( WITH COMPONENTS {..., notBefore PRESENT} | 4980 WITH COMPONENTS {..., notAfter PRESENT} ) 4982 certificatePolicies EXTENSION ::= { 4983 SYNTAX CertificatePoliciesSyntax 4984 IDENTIFIED BY id-ce-certificatePolicies } 4986 CertificatePoliciesSyntax ::= 4987 SEQUENCE SIZE (1..MAX) OF PolicyInformation 4989 PolicyInformation ::= SEQUENCE { 4990 policyIdentifier CertPolicyId, 4991 policyQualifiers SEQUENCE SIZE (1..MAX) OF 4992 PolicyQualifierInfo OPTIONAL } 4994 CertPolicyId ::= OBJECT IDENTIFIER 4996 PolicyQualifierInfo ::= SEQUENCE { 4997 policyQualifierId CERT-POLICY-QUALIFIER.&id 4998 ({SupportedPolicyQualifiers}), 4999 qualifier CERT-POLICY-QUALIFIER.&Qualifier 5000 ({SupportedPolicyQualifiers} 5001 {@policyQualifierId})OPTIONAL } 5003 SupportedPolicyQualifiers CERT-POLICY-QUALIFIER ::= { noticeToUser | 5004 pointerToCPS } 5006 CERT-POLICY-QUALIFIER ::= CLASS { 5007 &id OBJECT IDENTIFIER UNIQUE, 5008 &Qualifier OPTIONAL } 5009 WITH SYNTAX { 5010 POLICY-QUALIFIER-ID &id 5011 [QUALIFIER-TYPE &Qualifier] } 5013 policyMappings EXTENSION ::= { 5014 SYNTAX PolicyMappingsSyntax 5015 IDENTIFIED BY id-ce-policyMappings } 5017 PolicyMappingsSyntax ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 5018 issuerDomainPolicy CertPolicyId, 5019 subjectDomainPolicy CertPolicyId } 5021 -- Certificate subject and certificate issuer attributes extensions -- 5023 subjectAltName EXTENSION ::= { 5024 SYNTAX GeneralNames 5025 IDENTIFIED BY id-ce-subjectAltName } 5027 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 5029 GeneralName ::= CHOICE { 5030 otherName [0] INSTANCE OF OTHER-NAME, 5031 rfc822Name [1] IA5String, 5032 dNSName [2] IA5String, 5033 x400Address [3] ORAddress, 5034 directoryName [4] Name, 5035 ediPartyName [5] EDIPartyName, 5036 uniformResourceIdentifier [6] IA5String, 5037 iPAddress [7] OCTET STRING, 5038 registeredID [8] OBJECT IDENTIFIER } 5040 OTHER-NAME ::= TYPE-IDENTIFIER 5041 EDIPartyName ::= SEQUENCE { 5042 nameAssigner [0] DirectoryString {ub-name} OPTIONAL, 5043 partyName [1] DirectoryString {ub-name} } 5045 issuerAltName EXTENSION ::= { 5046 SYNTAX GeneralNames 5047 IDENTIFIED BY id-ce-issuerAltName } 5049 subjectDirectoryAttributes EXTENSION ::= { 5050 SYNTAX AttributesSyntax 5051 IDENTIFIED BY id-ce-subjectDirectoryAttributes } 5053 AttributesSyntax ::= SEQUENCE SIZE (1..MAX) OF Attribute 5055 -- Certification path constraints extensions -- 5057 basicConstraints EXTENSION ::= { 5058 SYNTAX BasicConstraintsSyntax 5059 IDENTIFIED BY id-ce-basicConstraints } 5061 BasicConstraintsSyntax ::= SEQUENCE { 5062 cA BOOLEAN DEFAULT FALSE, 5063 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 5065 nameConstraints EXTENSION ::= { 5066 SYNTAX NameConstraintsSyntax 5067 IDENTIFIED BY id-ce-nameConstraints } 5069 NameConstraintsSyntax ::= SEQUENCE { 5070 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 5071 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 5073 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 5075 GeneralSubtree ::= SEQUENCE { 5076 base GeneralName, 5077 minimum [0] BaseDistance DEFAULT 0, 5078 maximum [1] BaseDistance OPTIONAL } 5080 BaseDistance ::= INTEGER (0..MAX) 5082 policyConstraints EXTENSION ::= { 5083 SYNTAX PolicyConstraintsSyntax 5084 IDENTIFIED BY id-ce-policyConstraints } 5086 PolicyConstraintsSyntax ::= SEQUENCE { 5087 requireExplicitPolicy [0] SkipCerts OPTIONAL, 5088 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 5090 SkipCerts ::= INTEGER (0..MAX) 5092 -- Basic CRL extensions -- 5094 cRLNumber EXTENSION ::= { 5095 SYNTAX CRLNumber 5096 IDENTIFIED BY id-ce-cRLNumber } 5098 CRLNumber ::= INTEGER (0..MAX) 5100 reasonCode EXTENSION ::= { 5101 SYNTAX CRLReason 5102 IDENTIFIED BY id-ce-reasonCode } 5104 CRLReason ::= ENUMERATED { 5105 unspecified (0), 5106 keyCompromise (1), 5107 cACompromise (2), 5108 affiliationChanged (3), 5109 superseded (4), 5110 cessationOfOperation (5), 5111 certificateHold (6), 5112 removeFromCRL (8) } 5114 instructionCode EXTENSION ::= { 5115 SYNTAX HoldInstruction 5116 IDENTIFIED BY id-ce-instructionCode } 5118 HoldInstruction ::= OBJECT IDENTIFIER 5120 -- holdinstructions described in this specification, from ANSI x9 5122 -- ANSI x9 arc holdinstruction arc 5123 holdInstruction OBJECT IDENTIFIER ::= { 5124 joint-iso-ccitt(2) member-body(2) us(840) x9cm(10040) 2} 5126 -- ANSI X9 holdinstructions referenced by this standard 5127 id-holdinstruction-none OBJECT IDENTIFIER ::= {holdInstruction 1} 5128 id-holdinstruction-callissuer OBJECT IDENTIFIER ::= {holdInstruction 2} 5129 id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3} 5131 invalidityDate EXTENSION ::= { 5132 SYNTAX GeneralizedTime 5133 IDENTIFIED BY id-ce-invalidityDate } 5135 -- CRL distribution points and delta-CRL extensions -- 5137 cRLDistributionPoints EXTENSION ::= { 5138 SYNTAX CRLDistPointsSyntax 5139 IDENTIFIED BY id-ce-cRLDistributionPoints } 5141 CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 5143 DistributionPoint ::= SEQUENCE { 5144 distributionPoint [0] DistributionPointName OPTIONAL, 5145 reasons [1] ReasonFlags OPTIONAL, 5146 cRLIssuer [2] GeneralNames OPTIONAL } 5148 DistributionPointName ::= CHOICE { 5149 fullName [0] GeneralNames, 5150 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 5152 ReasonFlags ::= BIT STRING { 5153 unused (0), 5154 keyCompromise (1), 5155 caCompromise (2), 5156 affiliationChanged (3), 5157 superseded (4), 5158 cessationOfOperation (5), 5159 certificateHold (6) } 5161 issuingDistributionPoint EXTENSION ::= { 5162 SYNTAX IssuingDistPointSyntax 5163 IDENTIFIED BY id-ce-issuingDistributionPoint } 5165 IssuingDistPointSyntax ::= SEQUENCE { 5166 distributionPoint [0] DistributionPointName OPTIONAL, 5167 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 5168 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 5169 onlySomeReasons [3] ReasonFlags OPTIONAL, 5170 indirectCRL [4] BOOLEAN DEFAULT FALSE } 5172 certificateIssuer EXTENSION ::= { 5173 SYNTAX GeneralNames 5174 IDENTIFIED BY id-ce-certificateIssuer } 5176 deltaCRLIndicator EXTENSION ::= { 5177 SYNTAX BaseCRLNumber 5178 IDENTIFIED BY id-ce-deltaCRLIndicator } 5180 BaseCRLNumber ::= CRLNumber 5182 -- Object identifier assignments for ISO certificate extensions -- 5183 id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 5185 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= {id-ce 9} 5186 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= {id-ce 14} 5187 id-ce-keyUsage OBJECT IDENTIFIER ::= {id-ce 15} 5188 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= {id-ce 16} 5189 id-ce-subjectAltName OBJECT IDENTIFIER ::= {id-ce 17} 5190 id-ce-issuerAltName OBJECT IDENTIFIER ::= {id-ce 18} 5191 id-ce-basicConstraints OBJECT IDENTIFIER ::= {id-ce 19} 5192 id-ce-cRLNumber OBJECT IDENTIFIER ::= {id-ce 20} 5193 id-ce-reasonCode OBJECT IDENTIFIER ::= {id-ce 21} 5194 id-ce-instructionCode OBJECT IDENTIFIER ::= {id-ce 23} 5195 id-ce-invalidityDate OBJECT IDENTIFIER ::= {id-ce 24} 5196 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= {id-ce 27} 5197 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= {id-ce 28} 5198 id-ce-certificateIssuer OBJECT IDENTIFIER ::= {id-ce 29} 5199 id-ce-nameConstraints OBJECT IDENTIFIER ::= {id-ce 30} 5200 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31} 5201 id-ce-certificatePolicies OBJECT IDENTIFIER ::= {id-ce 32} 5202 id-ce-policyMappings OBJECT IDENTIFIER ::= {id-ce 33} 5203 id-ce-policyConstraints OBJECT IDENTIFIER ::= {id-ce 36} 5204 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= {id-ce 35} 5205 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 5207 -- PKIX 1 extensions 5209 authorityInfoAccess EXTENSION ::= { 5210 SYNTAX AuthorityInfoAccessSyntax 5211 IDENTIFIED BY id-pe-authorityInfoAccess } 5213 AuthorityInfoAccessSyntax ::= 5214 SEQUENCE SIZE (1..MAX) OF AccessDescription 5216 AccessDescription ::= SEQUENCE { 5217 accessMethod OBJECT IDENTIFIER, 5218 accessLocation GeneralName } 5220 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 5222 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 5223 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 5225 -- PKIX policy qualifier definitions 5227 noticeToUser CERT-POLICY-QUALIFIER ::= { 5228 POLICY-QUALIFIER-ID id-qt-cps QUALIFIER-TYPE CPSuri} 5230 pointerToCPS CERT-POLICY-QUALIFIER ::= { 5231 POLICY-QUALIFIER-ID id-qt-unotice QUALIFIER-TYPE UserNotice} 5233 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 5234 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 5236 CPSuri ::= IA5String 5238 UserNotice ::= SEQUENCE { 5239 noticeRef NoticeReference OPTIONAL, 5240 explicitText DisplayText OPTIONAL} 5242 NoticeReference ::= SEQUENCE { 5243 organization DisplayText, 5244 noticeNumbers SEQUENCE OF INTEGER } 5246 DisplayText ::= CHOICE { 5247 visibleString VisibleString (SIZE (1..200)), 5248 bmpString BMPString (SIZE (1..200)), 5249 utf8String UTF8String (SIZE (1..200)) } 5251 END 5253 Appendix C. ASN.1 Notes 5255 The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 5256 constructs. A valid ASN.1 sequence will have zero or more entries. 5257 The SIZE (1..MAX) construct constrains the sequence to have at least 5258 one entry. MAX indicates the upper bound is unspecified. Implementa- 5259 tions are free to choose an upper bound that suits their environment. 5261 The construct "positiveInt ::= INTEGER (0..MAX)" defines positiveInt 5262 as a subtype of INTEGER containing integers greater than or equal to 5263 zero. The upper bound is unspecified. Implementations are free to 5264 select an upper bound that suits their environment. 5266 The character string type PrintableString supports a very basic Latin 5267 character set: the lower case letters 'a' through 'z', upper case 5268 letters 'A' through 'Z', the digits '0' through '9', eleven special 5269 characters ' " ( ) + , - . / : ? and space. 5271 The character string type TeletexString is a superset of Printable- 5272 String. TeletexString supports a fairly standard (ascii-like) Latin 5273 character set, Latin characters with non-spacing accents and Japanese 5274 characters. 5276 The character string type UniversalString supports any of the charac- 5277 ters allowed by ISO 10646-1. ISO 10646 is the Universal multiple- 5278 octet coded Character Set (UCS). ISO 10646-1 specifes the 5279 architecture and the "basic multilingual plane" - a large standard 5280 character set which includes all major world character standards. 5282 The character string type UTF8String will be introduced in the 1998 5283 version of ASN.1. UTF8String is a universal type and has been 5284 assigned tag number 12. The content of UTF8String was defined by RFC 5285 2044 and updated in RFC 2279, "UTF-8, a transformation Format of ISP 5286 10646." ISO is expected to formally add UTF8String to the list of 5287 choices for DirectoryString in 1998 as well. 5289 In anticipation of these changes, and in conformance with IETF Best 5290 Practices codified in RFC 2277, IETF Policy on Character Sets and 5291 Languages, this document includes UTF8String as a choice in Directo- 5292 ryString and the CPS qualifier extensions. 5294 Appendix D. Examples 5296 This section contains four examples: three certificates and a CRL. 5297 The first two certificates and the CRL comprise a minimal certifica- 5298 tion path. 5300 Section D.1 contains an annotated hex dump of a "self-signed" certi- 5301 ficate issued by a CA whose distinguished name is 5302 cn=us,o=gov,ou=nist. The certificate contains a DSA public key with 5303 parameters, and is signed by the corresponding DSA private key. 5305 Section D.2 contains an annotated hex dump of an end-entity certifi- 5306 cate. The end entity certificate contains a DSA public key, and is 5307 signed by the private key corresponding to the "self-signed" certifi- 5308 cate in section D.1. 5310 Section D.3 contains a dump of an end entity certificate which con- 5311 tains an RSA public key and is signed with RSA and MD5. This certi- 5312 ficate is not part of the minimal certification path. 5314 Section D.4 contains an annotated hex dump of a CRL. The CRL is 5315 issued by the CA whose distinguished name is cn=us,o=gov,ou=nist and 5316 the list of revoked certificates includes the end entity certificate 5317 presented in D.2. 5319 D.1 Certificate 5321 This section contains an annotated hex dump of a 699 byte version 3 5322 certificate. The certificate contains the following information: 5323 (a) the serial number is 17 (11 hex); 5324 (b) the certificate is signed with DSA and the SHA-1 hash algorithm; 5325 (c) the issuer's distinguished name is OU=nist; O=gov; C=US 5326 (d) and the subject's distinguished name is OU=nist; O=gov; C=US 5327 (e) the certificate was issued on June 30, 1997 and will expire on 5328 December 31, 1997; 5329 (f) the certificate contains a 1024 bit DSA public key with parame- 5330 ters; 5331 (g) the certificate contains a subject key identifier extension; and 5332 (h) the certificate is a CA certificate (as indicated through the 5333 basic constraints extension.) 5335 0000 30 82 02 b7 695: SEQUENCE 5336 0004 30 82 02 77 631: . SEQUENCE tbscertificate 5337 0008 a0 03 3: . . [0] 5338 0010 02 01 1: . . . INTEGER 2 5339 : 02 5340 0013 02 01 1: . . INTEGER 17 5341 : 11 5342 0016 30 09 9: . . SEQUENCE 5343 0018 06 07 7: . . . OID 1.2.840.10040.4.3: dsa-with-sha 5344 : 2a 86 48 ce 38 04 03 5345 0027 30 2a 42: . . SEQUENCE 5346 0029 31 0b 11: . . . SET 5347 0031 30 09 9: . . . . SEQUENCE 5348 0033 06 03 3: . . . . . OID 2.5.4.6: C 5349 : 55 04 06 5350 0038 13 02 2: . . . . . PrintableString 'US' 5351 : 55 53 5352 0042 31 0c 12: . . . SET 5353 0044 30 0a 10: . . . . SEQUENCE 5354 0046 06 03 3: . . . . . OID 2.5.4.10: O 5355 : 55 04 0a 5356 0051 13 03 3: . . . . . PrintableString 'gov' 5357 : 67 6f 76 5358 0056 31 0d 13: . . . SET 5359 0058 30 0b 11: . . . . SEQUENCE 5360 0060 06 03 3: . . . . . OID 2.5.4.11: OU 5361 : 55 04 0b 5362 0065 13 04 4: . . . . . PrintableString 'nist' 5363 : 6e 69 73 74 5364 0071 30 1e 30: . . SEQUENCE 5365 0073 17 0d 13: . . . UTCTime '970630000000Z' 5366 : 39 37 30 36 33 30 30 30 30 30 30 30 5a 5367 0088 17 0d 13: . . . UTCTime '971231000000Z' 5368 : 39 37 31 32 33 31 30 30 30 30 30 30 5a 5369 0103 30 2a 42: . . SEQUENCE 5370 0105 31 0b 11: . . . SET 5371 0107 30 09 9: . . . . SEQUENCE 5372 0109 06 03 3: . . . . . OID 2.5.4.6: C 5373 : 55 04 06 5374 0114 13 02 2: . . . . . PrintableString 'US' 5375 : 55 53 5376 0118 31 0c 12: . . . SET 5377 0120 30 0a 10: . . . . SEQUENCE 5378 0122 06 03 3: . . . . . OID 2.5.4.10: O 5379 : 55 04 0a 5380 0127 13 03 3: . . . . . PrintableString 'gov' 5381 : 67 6f 76 5382 0132 31 0d 13: . . . SET 5383 0134 30 0b 11: . . . . SEQUENCE 5384 0136 06 03 3: . . . . . OID 2.5.4.11: OU 5385 : 55 04 0b 5386 0141 13 04 4: . . . . . PrintableString 'nist' 5387 : 6e 69 73 74 5388 0147 30 82 01 b4 436: . . SEQUENCE 5389 0151 30 82 01 29 297: . . . SEQUENCE 5390 0155 06 07 7: . . . . OID 1.2.840.10040.4.1: dsa 5391 : 2a 86 48 ce 38 04 01 5392 0164 30 82 01 1c 284: . . . . SEQUENCE 5393 0168 02 81 80 128: . . . . . INTEGER 5394 : d4 38 02 c5 35 7b d5 0b a1 7e 5d 72 59 63 55 d3 5395 : 45 56 ea e2 25 1a 6b c5 a4 ab aa 0b d4 62 b4 d2 5396 : 21 b1 95 a2 c6 01 c9 c3 fa 01 6f 79 86 83 3d 03 5397 : 61 e1 f1 92 ac bc 03 4e 89 a3 c9 53 4a f7 e2 a6 5398 : 48 cf 42 1e 21 b1 5c 2b 3a 7f ba be 6b 5a f7 0a 5399 : 26 d8 8e 1b eb ec bf 1e 5a 3f 45 c0 bd 31 23 be 5400 : 69 71 a7 c2 90 fe a5 d6 80 b5 24 dc 44 9c eb 4d 5401 : f9 da f0 c8 e8 a2 4c 99 07 5c 8e 35 2b 7d 57 8d 5402 0299 02 14 20: . . . . . INTEGER 5403 : a7 83 9b f3 bd 2c 20 07 fc 4c e7 e8 9f f3 39 83 5404 : 51 0d dc dd 5405 0321 02 81 80 128: . . . . . INTEGER 5406 : 0e 3b 46 31 8a 0a 58 86 40 84 e3 a1 22 0d 88 ca 5407 : 90 88 57 64 9f 01 21 e0 15 05 94 24 82 e2 10 90 5408 : d9 e1 4e 10 5c e7 54 6b d4 0c 2b 1b 59 0a a0 b5 5409 : a1 7d b5 07 e3 65 7c ea 90 d8 8e 30 42 e4 85 bb 5410 : ac fa 4e 76 4b 78 0e df 6c e5 a6 e1 bd 59 77 7d 5411 : a6 97 59 c5 29 a7 b3 3f 95 3e 9d f1 59 2d f7 42 5412 : 87 62 3f f1 b8 6f c7 3d 4b b8 8d 74 c4 ca 44 90 5413 : cf 67 db de 14 60 97 4a d1 f7 6d 9e 09 94 c4 0d 5414 0452 03 81 84 132: . . . BIT STRING (0 unused bits) 5415 : 02 81 80 aa 98 ea 13 94 a2 db f1 5b 7f 98 2f 78 5416 : e7 d8 e3 b9 71 86 f6 80 2f 40 39 c3 da 3b 4b 13 5417 : 46 26 ee 0d 56 c5 a3 3a 39 b7 7d 33 c2 6b 5c 77 5418 : 92 f2 55 65 90 39 cd 1a 3c 86 e1 32 eb 25 bc 91 5419 : c4 ff 80 4f 36 61 bd cc e2 61 04 e0 7e 60 13 ca 5420 : c0 9c dd e0 ea 41 de 33 c1 f1 44 a9 bc 71 de cf 5421 : 59 d4 6e da 44 99 3c 21 64 e4 78 54 9d d0 7b ba 5422 : 4e f5 18 4d 5e 39 30 bf e0 d1 f6 f4 83 25 4f 14 5423 : aa 71 e1 5424 0587 a3 32 50: . . [3] 5425 0589 30 30 48: . . . SEQUENCE 5426 0591 30 0f 9: . . . . SEQUENCE 5427 0593 06 03 3: . . . . . OID 2.5.29.19: basicConstraints 5428 : 55 1d 13 5429 0598 01 01 1: . . . . . TRUE 5430 : ff 5431 0601 04 05 5: . . . . . OCTET STRING 5432 : 30 03 01 01 ff 5433 0608 30 1d 29: . SEQUENCE 5434 0610 06 03 3: . . . . . OID 2.5.29.14: subjectKeyIdentifier 5435 : 55 1d 0e 5436 0615 04 16 22: . . . . . OCTET STRING 5437 : 04 14 e7 26 c5 54 cd 5b a3 6f 35 68 95 aa d5 ff 5438 : 1c 21 e4 22 75 d6 5439 0639 30 09 9: . SEQUENCE 5440 0641 06 07 7: . . OID 1.2.840.10040.4.3: dsa-with-sha 5441 : 2a 86 48 ce 38 04 03 5442 0650 03 2f 47: . BIT STRING (0 unused bits) 5443 : 30 2c 02 14 a0 66 c1 76 33 99 13 51 8d 93 64 2f 5444 : ca 13 73 de 79 1a 7d 33 02 14 5d 90 f6 ce 92 4a 5445 : bf 29 11 24 80 28 a6 5a 8e 73 b6 76 02 68 5447 D.2 Certificate 5449 This section contains an annotated hex dump of a 730 byte version 3 5450 certificate. The certificate contains the following information: 5451 (a) the serial number is 18 (12 hex); 5452 (b) the certificate is signed with DSA and the SHA-1 hash algorithm; 5453 (c) the issuer's distinguished name is OU=nist; O=gov; C=US 5454 (d) and the subject's distinguished name is CN=Tim Polk; OU=nist; 5455 O=gov; C=US 5456 (e) the certificate was valid from July 30, 1997 through December 1, 5457 1997; 5458 (f) the certificate contains a 1024 bit DSA public key; 5459 (g) the certificate is an end entity certificate, as the basic con- 5460 straints extension is not present; 5461 (h) the certificate contains an authority key identifier extension; 5462 and 5463 (i) the certificate includes one alternative name - an RFC 822 5464 address. 5466 0000 30 82 02 d6 726: SEQUENCE 5467 0004 30 82 02 96 662: . SEQUENCE 5468 0008 a0 03 3: . . [0] 5469 0010 02 01 1: . . . INTEGER 2 5470 : 02 5472 0013 02 01 1: . . INTEGER 18 5473 : 12 5474 0016 30 09 9: . . SEQUENCE 5475 0018 06 07 7: . . . OID 1.2.840.10040.4.3: dsa-with-sha 5476 : 2a 86 48 ce 38 04 03 5477 0027 30 2a 42: . . SEQUENCE 5478 0029 31 0b 11: . . . SET 5479 0031 30 09 9: . . . . SEQUENCE 5480 0033 06 03 3: . . . . . OID 2.5.4.6: C 5481 : 55 04 06 5482 0038 13 02 2: . . . . . PrintableString 'US' 5483 : 55 53 5484 0042 31 0c 12: . . . SET 5485 0044 30 0a 10: . . . . SEQUENCE 5486 0046 06 03 3: . . . . . OID 2.5.4.10: O 5487 : 55 04 0a 5488 0051 13 03 3: . . . . . PrintableString 'gov' 5489 : 67 6f 76 5490 0056 31 0d 13: . . . SET 5491 0058 30 0b 11: . . . . SEQUENCE 5492 0060 06 03 3: . . . . . OID 2.5.4.11: OU 5493 : 55 04 0b 5494 0065 13 04 4: . . . . . PrintableString 'nist' 5495 : 6e 69 73 74 5496 0071 30 1e 30: . . SEQUENCE 5497 0073 17 0d 13: . . . UTCTime '970730000000Z' 5498 : 39 37 30 37 33 30 30 30 30 30 30 30 5a 5499 0088 17 0d 13: . . . UTCTime '971201000000Z' 5500 : 39 37 31 32 30 31 30 30 30 30 30 30 5a 5501 0103 30 3d 61: . . SEQUENCE 5502 0105 31 0b 11: . . . SET 5503 0107 30 09 9: . . . . SEQUENCE 5504 0109 06 03 3: . . . . . OID 2.5.4.6: C 5505 : 55 04 06 5506 0114 13 02 2: . . . . . PrintableString 'US' 5507 : 55 53 5508 0118 31 0c 12: . . . SET 5509 0120 30 0a 10: . . . . SEQUENCE 5510 0122 06 03 3: . . . . . OID 2.5.4.10: O 5511 : 55 04 0a 5512 0127 13 03 3: . . . . . PrintableString 'gov' 5513 : 67 6f 76 5514 0132 31 0d 13: . . . SET 5515 0134 30 0b 11: . . . . SEQUENCE 5516 0136 06 03 3: . . . . . OID 2.5.4.11: OU 5517 : 55 04 0b 5518 0141 13 04 4: . . . . . PrintableString 'nist' 5519 : 6e 69 73 74 5521 0147 31 11 17: . . . SET 5522 0149 30 0f 15: . . . . SEQUENCE 5523 0151 06 03 3: . . . . . OID 2.5.4.3: CN 5524 : 55 04 03 5525 0156 13 08 8: . . . . . PrintableString 'Tim Polk' 5526 : 54 69 6d 20 50 6f 6c 6b 5527 0166 30 82 01 b4 436: . . SEQUENCE 5528 0170 30 82 01 29 297: . . . SEQUENCE 5529 0174 06 07 7: . . . . OID 1.2.840.10040.4.1: dsa 5530 : 2a 86 48 ce 38 04 01 5531 0183 30 82 01 1c 284: . . . . SEQUENCE 5532 0187 02 81 80 128: . . . . . INTEGER 5533 : d4 38 02 c5 35 7b d5 0b a1 7e 5d 72 59 63 55 d3 5534 : 45 56 ea e2 25 1a 6b c5 a4 ab aa 0b d4 62 b4 d2 5535 : 21 b1 95 a2 c6 01 c9 c3 fa 01 6f 79 86 83 3d 03 5536 : 61 e1 f1 92 ac bc 03 4e 89 a3 c9 53 4a f7 e2 a6 5537 : 48 cf 42 1e 21 b1 5c 2b 3a 7f ba be 6b 5a f7 0a 5538 : 26 d8 8e 1b eb ec bf 1e 5a 3f 45 c0 bd 31 23 be 5539 : 69 71 a7 c2 90 fe a5 d6 80 b5 24 dc 44 9c eb 4d 5540 : f9 da f0 c8 e8 a2 4c 99 07 5c 8e 35 2b 7d 57 8d 5541 0318 02 14 20: . . . . . INTEGER 5542 : a7 83 9b f3 bd 2c 20 07 fc 4c e7 e8 9f f3 39 83 5543 : 51 0d dc dd 5544 0340 02 81 80 128: . . . . . INTEGER 5545 : 0e 3b 46 31 8a 0a 58 86 40 84 e3 a1 22 0d 88 ca 5546 : 90 88 57 64 9f 01 21 e0 15 05 94 24 82 e2 10 90 5547 : d9 e1 4e 10 5c e7 54 6b d4 0c 2b 1b 59 0a a0 b5 5548 : a1 7d b5 07 e3 65 7c ea 90 d8 8e 30 42 e4 85 bb 5549 : ac fa 4e 76 4b 78 0e df 6c e5 a6 e1 bd 59 77 7d 5550 : a6 97 59 c5 29 a7 b3 3f 95 3e 9d f1 59 2d f7 42 5551 : 87 62 3f f1 b8 6f c7 3d 4b b8 8d 74 c4 ca 44 90 5552 : cf 67 db de 14 60 97 4a d1 f7 6d 9e 09 94 c4 0d 5553 0471 03 81 84 132: . . . BIT STRING (0 unused bits) 5554 : 02 81 80 a8 63 b1 60 70 94 7e 0b 86 08 93 0c 0d 5555 : 08 12 4a 58 a9 af 9a 09 38 54 3b 46 82 fb 85 0d 5556 : 18 8b 2a 77 f7 58 e8 f0 1d d2 18 df fe e7 e9 35 5557 : c8 a6 1a db 8d 3d 3d f8 73 14 a9 0b 39 c7 95 f6 5558 : 52 7d 2d 13 8c ae 03 29 3c 4e 8c b0 26 18 b6 d8 5559 : 11 1f d4 12 0c 13 ce 3f f1 c7 05 4e df e1 fc 44 5560 : fd 25 34 19 4a 81 0d dd 98 42 ac d3 b6 91 0c 7f 5561 : 16 72 a3 a0 8a d7 01 7f fb 9c 93 e8 99 92 c8 42 5562 : 47 c6 43 5563 0606 a3 3e 62: . . [3] 5564 0608 30 3c 60: . . . SEQUENCE 5565 0610 30 19 25: . . . . SEQUENCE 5566 0612 06 03 3: . . . . . OID 2.5.29.17: subjectAltName 5567 : 55 1d 11 5568 0617 04 12 18: . . . . . OCTET STRING 5569 : 30 10 81 0e 77 70 6f 6c 6b 40 6e 69 73 74 2e 67 5570 : 6f 76 5571 0637 30 1f 31: . . . . SEQUENCE 5572 0639 06 03 3: . . . . . OID 2.5.29.35: subjectAltName 5573 : 55 1d 23 5574 0644 04 18 24: . . . . . OCTET STRING 5575 : 30 16 80 14 e7 26 c5 54 cd 5b a3 6f 35 68 95 aa 5576 : d5 ff 1c 21 e4 22 75 d6 5577 0670 30 09 9: . SEQUENCE 5578 0672 06 07 7: . . OID 1.2.840.10040.4.3: dsa-with-sha 5579 : 2a 86 48 ce 38 04 03 5580 0681 03 2f 47: . BIT STRING (0 unused bits) 5581 : 30 2c 02 14 3c 02 e0 ab d9 5d 05 77 75 15 71 58 5582 : 92 29 48 c4 1c 54 df fc 02 14 5b da 53 98 7f c5 5583 : 33 df c6 09 b2 7a e3 6f 97 70 1e 14 ed 94 5585 D.3 End-Entity Certificate Using RSA 5587 This section contains an annotated hex dump of a 675 byte version 3 5588 certificate. The certificate contains the following information: 5589 (a) the serial number is 256; 5590 (b) the certificate is signed with RSA and the MD2 hash algorithm; 5591 (c) the issuer's distinguished name is OU=Dept. Arquitectura de Com- 5592 putadors; O=Universitat Politecnica de Catalunya; C=ES 5593 (d) and the subject's distinguished name is CN=Francisco Jordan; 5594 OU=Dept. Arquitectura de Computadors; O=Universitat Politecnica de 5595 Catalunya; C=ES 5596 (e) the certificate was issued on May 21, 1996 and expired on May 21, 5597 1997; 5598 (f) the certificate contains a 768 bit RSA public key; 5599 (g) the certificate is an end entity certificate (not a CA certifi- 5600 cate); 5601 (h) the certificate includes an alternative subject name and an 5602 alternative issuer name - bothe are URLs; 5603 (i) the certificate include an authority key identifier and certifi- 5604 cate policies extensions; and 5605 (j) the certificate includes a critical key usage extension specify- 5606 ing the public is intended for generation of digital signatures. 5608 0000 30 80 : SEQUENCE (size undefined) 5609 0002 30 82 02 40 576: . SEQUENCE 5610 0006 a0 03 3: . . [0] 5611 0008 02 01 1: . . . INTEGER 2 5612 : 02 5613 0011 02 02 2: . . INTEGER 256 5614 : 01 00 5615 0015 30 0d 13: . . SEQUENCE 5616 0017 06 09 9: . . . OID 1.2.840.113549.1.1.2: 5618 MD2WithRSAEncryption 5619 : 2a 86 48 86 f7 0d 01 01 02 5620 0028 05 00 0: . . . NULL 5621 0030 30 68 88: . . SEQUENCE 5622 0032 31 0b 11: . . . SET 5623 0034 30 09 9: . . . . SEQUENCE 5624 0036 06 03 3: . . . . . OID 2.5.4.6: C 5625 : 55 04 06 5626 0041 13 02 2: . . . . . PrintableString 'ES' 5627 : 45 53 5628 0045 31 2d 45: . . . SET 5629 0047 30 2b 43: . . . . SEQUENCE 5630 0049 06 03 3: . . . . . OID 2.5.4.10: O 5631 : 55 04 0a 5632 0054 13 24 36: . . . . . PrintableString 5633 'Universitat Politecnica de Catalunya' 5634 : 55 6e 69 76 65 72 73 69 74 61 74 20 50 6f 6c 69 5635 : 74 65 63 6e 69 63 61 20 64 65 20 43 61 74 61 6c 5636 : 75 6e 79 61 5637 0092 31 2a 42: . . . SET 5638 0094 30 28 40: . . . . SEQUENCE 5639 0096 06 03 3: . . . . . OID 2.5.4.11: OU 5640 : 55 04 0b 5641 0101 13 21 33: . . . . . PrintableString 5642 'OU=Dept. Arquitectura de Computadors' 5643 : 44 65 70 74 2e 20 41 72 71 75 69 74 65 63 74 75 5644 : 72 61 20 64 65 20 43 6f 6d 70 75 74 61 64 6f 72 5645 : 73 5646 0136 30 1e 30: . . SEQUENCE 5647 0138 17 0d 13: . . . UTCTime '960521095826Z' 5648 : 39 36 30 37 32 32 31 37 33 38 30 32 5a 5649 0153 17 0d 13: . . . UTCTime '979521095826Z' 5650 : 39 37 30 37 32 32 31 37 33 38 30 32 5a 5651 0168 30 81 83 112: . . SEQUENCE 5652 0171 31 0b 11: . . . SET 5653 0173 30 09 9: . . . . SEQUENCE 5654 0175 06 03 3: . . . . . OID 2.5.4.6: C 5655 : 55 04 06 5656 0180 13 02 2: . . . . . PrintableString 'ES' 5657 : 45 53 5658 0184 31 2d 12: . . . SET 5659 0186 30 2b 16: . . . . SEQUENCE 5660 0188 06 03 3: . . . . . OID 2.5.4.10: O 5661 : 55 04 0a 5662 0193 13 24 36: . . . . . PrintableString 5663 'Universitat Politecnica de Catalunya' 5664 : 55 6e 69 76 65 72 73 69 74 61 74 20 50 6f 6c 69 5665 : 74 65 63 6e 69 63 61 20 64 65 20 43 61 74 61 6c 5666 : 75 6e 79 61 5667 0231 31 2a 42: . . . SET 5668 0233 30 28 40: . . . . SEQUENCE 5669 0235 06 03 3: . . . . . OID 2.5.4.11: OU 5670 : 55 04 0b 5671 0240 13 21 33: . . . . . PrintableString 5672 'Dept. Arquitectura de Computadors' 5673 : 44 65 70 74 2e 20 41 72 71 75 69 74 65 63 74 75 5674 : 72 61 20 64 65 20 43 6f 6d 70 75 74 61 64 6f 72 5675 : 73 5676 0275 31 19 22: . . . SET 5677 0277 30 17 20: . . . . SEQUENCE 5678 0279 06 03 3: . . . . . OID 2.5.4.3: CN 5679 : 55 04 03 5680 0284 13 10 16: . . . . . PrintableString 'Francisco Jordan' 5681 : 46 72 61 6e 63 69 73 63 6f 20 4a 6f 72 64 61 6e 5682 0302 30 7c 2: . . SEQUENCE 5683 0304 30 0d 13: . . . SEQUENCE 5684 0306 06 09 9: . . . . OID 1.2.840.113549.1.1.1: RSAEncryption 5685 : 2a 86 48 86 f7 0d 01 01 01 5686 0317 05 00 0: . . . . NULL 5687 0319 03 6b 107: . . . BIT STRING 5688 : 00 (0 unused bits) 5689 : 30 68 02 61 00 be aa 8b 77 54 a3 af ca 77 9f 2f 5690 : b0 cf 43 88 ff a6 6d 79 55 5b 61 8c 68 ec 48 1e 5691 : 8a 86 38 a4 fe 19 b8 62 17 1d 9d 0f 47 2c ff 63 5692 : 8f 29 91 04 d1 52 bc 7f 67 b6 b2 8f 74 55 c1 33 5693 : 21 6c 8f ab 01 95 24 c8 b2 73 93 9d 22 61 50 a9 5694 : 35 fb 9d 57 50 32 ef 56 52 50 93 ab b1 88 94 78 5695 : 56 15 c6 1c 8b 02 03 01 00 01 5696 0428 a3 81 97 151: . . [3] 5697 0431 30 3c 60: . . . SEQUENCE 5698 0433 30 1f 31: . . . . SEQUENCE 5699 0435 06 03 3: . . . . . OID 2.5.29.35: authorityKeyIdentifier 5700 : 55 1d 23 5701 0440 04 14 22: . . . . . OCTET STRING 5702 : 30 12 80 10 0e 6b 3a bf 04 ea 04 c3 0e 6b 3a bf 5703 : 04 ea 04 c3 5704 0464 30 19 25: . . . . SEQUENCE 5705 0466 06 03 3: . . . . . OID 2.5.29.15: keyUsage 5706 : 55 1d 0f 5707 0471 01 01 1: . . . . . TRUE 5708 0474 04 04 4: . . . . . OCTET STRING 5709 : 03 02 07 80 5710 0480 30 19 25: . . . . SEQUENCE 5711 0482 06 03 3: . . . . . OID 2.5.29.32: certificatePolicies 5712 : 55 1d 20 5713 0487 04 21 33: . . . . . OCTET STRING 5714 : 30 1f 30 1d 06 04 2a 84 80 00 30 15 30 07 06 05 5715 : 2a 84 80 00 01 30 0a 06 05 2a 84 80 00 02 02 01 5716 : 0a 5717 0522 30 1c 28: . . . . SEQUENCE 5718 0524 06 03 3: . . . . . OID 2.5.29.17: subjectAltName 5719 : 55 1d 11 5720 0529 04 15 21: . . . . . OCTET STRING 5721 : 30 13 86 11 68 74 74 70 3a 2f 2f 61 63 2e 75 70 5722 : 63 2e 65 73 2f 5723 0552 30 19 25: . . . . SEQUENCE 5724 0554 06 03 3: . . . . . OID 2.5.29.18: issuerAltName 5725 : 55 1d 12 5726 0559 04 12 18: . . . . . OCTET STRING 5727 : 30 14 86 12 68 74 74 70 3a 2f 2f 77 77 77 2e 75 5728 : 70 63 2e 65 5729 0579 30 80 : . SEQUENCE (indefinite length) 5730 0581 06 07 7: . . OID 5731 0583 05 00 0: . . NULL 5732 0585 00 00 0: . . end of contents marker 5733 0587 03 81 81 47: . BIT STRING 5734 : 00 (0 unused bits) 5735 : 5c 01 bd b5 41 88 87 7a 0e d3 0e 6b 3a bf 04 ea 5736 : 04 cb 5f 61 72 3c a3 bd 78 f5 66 17 fe 37 3a ab 5737 : eb 67 bf b7 da a8 38 f6 33 15 71 75 2f b9 8c 91 5738 : a0 e4 87 ba 4b 43 a0 22 8f d3 a9 86 43 89 e6 50 5739 : 5c 01 bd b5 41 88 87 7a 0e d3 0e 6b 3a bf 04 ea 5740 : 04 cb 5f 61 72 3c a3 bd 78 f5 66 17 fe 37 3a ab 5741 : eb 67 bf b7 da a8 38 f6 33 15 71 75 2f b9 8c 91 5742 : a0 e4 87 ba 4b 43 a0 22 8f d3 a9 86 43 89 e6 50 5743 0637 00 00 0: . . end of contents marker 5745 D.4 Certificate Revocation List 5747 This section contains an annotated hex dump of a version 2 CRL with 5748 one extension (cRLNumber). The CRL was issued by OU=nist;O=gov;C=us 5749 on July 7, 1996; the next scheduled issuance was August 7, 1996. The 5750 CRL includes one revoked certificates: serial number 18 (12 hex). 5751 The CRL itself is number 18, and it was signed with DSA and SHA-1. 5753 0000 30 81 ba 186: SEQUENCE 5754 0003 30 7c 124: . SEQUENCE 5755 0005 02 01 1: . . INTEGER 1 5756 : 01 5757 0008 30 09 9: . . SEQUENCE 5758 0010 06 07 7: . . . OID 1.2.840.10040.4.3: dsa-with-sha 5759 : 2a 86 48 ce 38 04 03 5760 0019 30 2a 42: . . SEQUENCE 5761 0021 31 0b 11: . . . SET 5762 0023 30 09 9: . . . . SEQUENCE 5763 0025 06 03 3: . . . . . OID 2.5.4.6: C 5764 : 55 04 06 5765 0030 13 02 2: . . . . . PrintableString 'US' 5766 : 55 53 5767 0034 31 0c 12: . . . SET 5768 0036 30 0a 10: . . . . SEQUENCE 5769 0038 06 03 3: . . . . . OID 2.5.4.10: O 5770 : 55 04 0a 5771 0043 13 03 3: . . . . . PrintableString 'gov' 5772 : 67 6f 76 5773 0048 31 0d 13: . . . SET 5774 0050 30 0b 11: . . . . SEQUENCE 5775 0052 06 03 3: . . . . . OID 2.5.4.11: OU 5776 : 55 04 0b 5777 0057 13 04 4: . . . . . PrintableString 'nist' 5778 : 6e 69 73 74 5779 0063 17 0d 13: . . UTCTime '970801000000Z' 5780 : 39 37 30 38 30 31 30 30 30 30 30 30 5a 5781 0078 17 0d 13: . . UTCTime '970808000000Z' 5782 : 39 37 30 38 30 38 30 30 30 30 30 30 5a 5783 0093 30 22 34: . . SEQUENCE 5784 0095 30 20 32: . . . SEQUENCE 5785 0097 02 01 1: . . . . INTEGER 18 5786 : 12 5787 0100 17 0d 13: . . . . UTCTime '970731000000Z' 5788 : 39 37 30 37 33 31 30 30 30 30 30 30 5a 5789 0115 30 0c 12: . . . . SEQUENCE 5790 0117 30 0a 10: . . . . . SEQUENCE 5791 0119 06 03 3: . . . . . . OID 2.5.29.21: reasonCode 5792 : 55 1d 15 5793 0124 04 03 3: . . . . . . OCTET STRING 5794 : 0a 01 01 5795 0129 30 09 9: . SEQUENCE 5796 0131 06 07 7: . . OID 1.2.840.10040.4.3: dsa-with-sha 5797 : 2a 86 48 ce 38 04 03 5798 0140 03 2f 47: . BIT STRING (0 unused bits) 5799 : 30 2c 02 14 9e d8 6b c1 7d c2 c4 02 f5 17 84 f9 5800 : 9f 46 7a ca cf b7 05 8a 02 14 9e 43 39 85 dc ea 5801 : 14 13 72 93 54 5d 44 44 e5 05 fe 73 9a b2 5803 Appendix E. Author Addresses: 5805 Russell Housley 5806 SPYRUS 5807 381 Elden Street 5808 Suite 1120 5809 Herndon, VA 20170 5810 USA 5811 housley@spyrus.com 5813 Warwick Ford 5814 VeriSign, Inc. 5815 One Alewife Center 5816 Cambridge, MA 02140 5817 USA 5818 wford@verisign.com 5820 Tim Polk 5821 NIST 5822 Building 820, Room 426 5823 Gaithersburg, MD 20899 5824 USA 5825 wpolk@nist.gov 5827 David Solo 5828 Citicorp 5829 666 Fifth Ave, 3rd Floor 5830 New York, NY 10103 5831 USA 5832 david.solo@citicorp.com 5834 Appendix F. Full Copyright Statement 5836 Copyright (C) The Internet Society (date). All Rights Reserved. 5838 This document and translations of it may be copied and furnished to 5839 others, and derivative works that comment on or otherwise explain it 5840 or assist in its implementation may be prepared, copied, published 5841 and distributed, in whole or in part, without restriction of any 5842 kind, provided that the above copyright notice and this paragraph are 5843 included on all such copies and derivative works. In addition, the 5844 ASN.1 modules presented in Appendices A and B may be used in whole or 5845 in part without inclusion of the copyright notice. However, this 5846 document itself may not be modified in any way, such as by removing 5847 the copyright notice or references to the Internet Society or other 5848 Internet organizations, except as needed for the purpose of develop- 5849 ing Internet standards in which case the procedures for copyrights 5850 defined in the Internet Standards process shall be followed, or as 5851 required to translate it into languages other than English. 5853 The limited permissions granted above are perpetual and will not be 5854 revoked by the Internet Society or its successors or assigns. This 5855 document and the information contained herein is provided on an "AS 5856 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 5857 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 5858 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 5859 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 5860 OR FITNESS FOR A PARTICULAR PURPOSE.