idnits 2.17.1 draft-ietf-pkix-ipki-part1-08.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 128 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 129 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 6 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 36 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: ---------------------------------------------------------------------------- == Line 577 has weird spacing: '...issuing a cer...' == Line 587 has weird spacing: '...: This is th...' == Line 5264 has weird spacing: '...ontains an an...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (June 16, 1998) is 9446 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 5456 -- Looks like a reference, but probably isn't: '1' on line 5125 -- Looks like a reference, but probably isn't: '2' on line 5126 -- Looks like a reference, but probably isn't: '3' on line 5529 -- Looks like a reference, but probably isn't: '4' on line 5128 -- Looks like a reference, but probably isn't: '5' on line 4993 -- Looks like a reference, but probably isn't: '6' on line 4994 -- Looks like a reference, but probably isn't: '7' on line 4995 -- Looks like a reference, but probably isn't: '8' on line 4996 == Missing Reference: 'RFC1738' is mentioned on line 2133, but not defined ** Obsolete undefined reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) == Missing Reference: 'RFC1778' is mentioned on line 2133, but not defined ** Obsolete undefined reference: RFC 1778 (Obsoleted by RFC 3494) == Missing Reference: 'RFC 1321' is mentioned on line 2553, but not defined == Missing Reference: 'DB94' is mentioned on line 2555, but not defined == Missing Reference: 'UNIVERSAL 28' is mentioned on line 3185, but not defined == Missing Reference: 'UNIVERSAL 30' is mentioned on line 3188, but not defined == Missing Reference: 'UNIVERSAL 12' is mentioned on line 3192, but not defined == Missing Reference: 'APPLICATION 1' is mentioned on line 4547, but not defined == Missing Reference: 'APPLICATION 2' is mentioned on line 4553, but not defined == Unused Reference: 'FIPS 180-1' is defined on line 2849, but no explicit reference was found in the text == Unused Reference: 'RFC 1519' is defined on line 2883, but no explicit reference was found in the text == Unused Reference: 'RFC 1883' is defined on line 2887, but no explicit reference was found in the text == Unused Reference: 'RFC 2044' is defined on line 2890, but no explicit reference was found in the text == Unused Reference: 'RFC 2119' is defined on line 2893, but no explicit reference was found in the text == Unused Reference: 'RFC 2277' is defined on line 2896, but no explicit reference was found in the text == Unused Reference: 'RFC 2279' is defined on line 2899, 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 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 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: 20 errors (**), 0 flaws (~~), 26 warnings (==), 15 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 June 16, 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 learn the current status of any Internet-Draft, please check the 27 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 28 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au Pacific Rim), ds.internic.net (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 Copyright (C) The Internet Society (date). All Rights Reserved. 34 Abstract 36 This is the eighth draft of the Internet Public Key Infrastructure 37 X.509 Certificate and CRL Profile. This draft is a complete 38 specification. This text includes minor modifications over the 39 previous draft. This draft clarifies name encoding and comparison 40 issues, updates the path validation process to conform with the 41 current X.509 specification, specifies performance enhancements for 42 path building, and clarifies conformance requirements. 44 The Entrust patent statement in section 9.5 is a placeholder. Recent 45 negotiations have produced new licensing terms; a new statement 46 aligned with those terms will be inserted when available. 48 The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" 49 in this document are to be interpreted as described in RFC 2119. 51 Please send comments on this document to the ietf-pkix@tandem.com 52 mail list. 54 Table of Contents 56 1 Introduction ................................................ 6 57 2 Requirements and Assumptions ................................ 7 58 2.1 Communication and Topology ................................ 7 59 2.2 Acceptability Criteria .................................... 8 60 2.3 User Expectations ......................................... 8 61 2.4 Administrator Expectations ................................ 8 62 3 Overview of Approach ........................................ 8 63 3.1 X.509 Version 3 Certificate ............................... 10 64 3.2 Certification Paths and Trust ............................. 11 65 3.3 Revocation ................................................ 13 66 3.4 Operational Protocols ..................................... 14 67 3.5 Management Protocols ...................................... 14 68 4 Certificate and Certificate Extensions Profile .............. 15 69 4.1 Basic Certificate Fields .................................. 16 70 4.1.1 Certificate Fields ...................................... 17 71 4.1.1.1 tbsCertificate ........................................ 17 72 4.1.1.2 signatureAlgorithm .................................... 17 73 4.1.1.3 signatureValue ........................................ 18 74 4.1.2 TBSCertificate .......................................... 18 75 4.1.2.1 Version ............................................... 18 76 4.1.2.2 Serial number ......................................... 18 77 4.1.2.3 Signature ............................................. 19 78 4.1.2.4 Issuer ................................................ 19 79 4.1.2.5 Validity .............................................. 21 80 4.1.2.5.1 UTCTime ............................................. 21 81 4.1.2.5.2 GeneralizedTime ..................................... 21 82 4.1.2.6 Subject ............................................... 22 83 4.1.2.7 Subject Public Key Info ............................... 23 84 4.1.2.8 Unique Identifiers .................................... 23 85 4.1.2.9 Extensions ............................................. 23 86 4.2 Certificate Extensions .................................... 23 87 4.2.1 Standard Extensions ..................................... 24 88 4.2.1.1 Authority Key Identifier .............................. 25 89 4.2.1.2 Subject Key Identifier ................................ 25 90 4.2.1.3 Key Usage ............................................. 26 91 4.2.1.4 Private Key Usage Period .............................. 27 92 4.2.1.5 Certificate Policies .................................. 28 93 4.2.1.6 Policy Mappings ....................................... 30 94 4.2.1.7 Subject Alternative Name .............................. 30 95 4.2.1.8 Issuer Alternative Name ............................... 32 96 4.2.1.9 Subject Directory Attributes .......................... 33 97 4.2.1.10 Basic Constraints .................................... 33 98 4.2.1.11 Name Constraints ..................................... 33 99 4.2.1.12 Policy Constraints ................................... 35 100 4.2.1.13 Extended key usage field ............................. 36 101 4.2.1.14 CRL Distribution Points .............................. 38 102 4.2.2 Internet Certificate Extensions ......................... 38 103 4.2.2.1 Authority Information Access .......................... 39 104 5 CRL and CRL Extensions Profile .............................. 40 105 5.1 CRL Fields ................................................ 41 106 5.1.1 CertificateList Fields .................................. 41 107 5.1.1.1 tbsCertList ........................................... 42 108 5.1.1.2 signatureAlgorithm .................................... 42 109 5.1.1.3 signatureValue ........................................ 42 110 5.1.2 Certificate List "To Be Signed" ......................... 42 111 5.1.2.1 Version ............................................... 42 112 5.1.2.2 Signature ............................................. 43 113 5.1.2.3 Issuer Name ........................................... 43 114 5.1.2.4 This Update ........................................... 43 115 5.1.2.5 Next Update ........................................... 43 116 5.1.2.6 Revoked Certificates .................................. 44 117 5.1.2.7 Extensions ............................................ 44 118 5.2 CRL Extensions ............................................ 44 119 5.2.1 Authority Key Identifier ................................ 45 120 5.2.2 Issuer Alternative Name ................................. 45 121 5.2.3 CRL Number .............................................. 45 122 5.2.4 Delta CRL Indicator ..................................... 45 123 5.2.5 Issuing Distribution Point .............................. 46 124 5.3 CRL Entry Extensions ...................................... 47 125 5.3.1 Reason Code ............................................. 47 126 5.3.2 Hold Instruction Code ................................... 48 127 5.3.3 Invalidity Date ......................................... 48 128 5.3.4 Certificate Issuer ...................................... 49 129 6 Certificate Path Validation ................................. 49 130 6.1 Basic Path Validation ..................................... 50 131 6.2 Extending Path Validation ................................. 54 132 7 Algorithm Support ........................................... 54 133 7.1 One-way Hash Functions .................................... 55 134 7.1.1 MD2 One-way Hash Function ............................... 55 135 7.1.2 MD5 One-way Hash Function ............................... 55 136 7.1.3 SHA-1 One-way Hash Function ............................. 55 137 7.2 Signature Algorithms ...................................... 56 138 7.2.1 RSA Signature Algorithm ................................. 56 139 7.2.2 DSA Signature Algorithm ................................. 57 140 7.3 Subject Public Key Algorithms ............................. 58 141 7.3.1 RSA Keys ................................................ 58 142 7.3.2 Diffie-Hellman Key Exchange Key ......................... 59 143 7.3.3 DSA Signature Keys ...................................... 60 144 8 References .................................................. 61 145 9 Patent Statements ........................................... 63 146 9.1 Digital Signature Algorithm (DSA) ......................... 64 147 9.2 RSA Signature and Encryption .............................. 64 148 9.3 Diffie-Hellman Key Agreement .............................. 65 149 9.4 Hellman-Merkle Public Key Cryptography .................... 65 150 9.5 CRL Distribution Points and Related Mechanisms ............ 65 151 10 Security Considerations .................................... 66 152 Appendix A. ASN.1 Structures and OIDs ......................... 69 153 A.1 Explicitly Tagged Module, 1988 Syntax ...................... 69 154 A.1 Implicitly Tagged Module, 1988 Syntax ...................... 83 155 Appendix B. 1993 ASN.1 Structures and OIDs .................... 90 156 B.1 Explicitly Tagged Module, 1993 Syntax ...................... 90 157 B.2 Implicitly Tagged Module, 1993 Syntax ...................... 107 158 Appendix C. ASN.1 Notes ....................................... 114 159 Appendix D. Examples .......................................... 115 160 D.1 Certificate ............................................... 115 161 D.1.1 ASN.1 Dump of "Self-Signed" Certificate ................. 116 162 D.1.2 Pretty Print of "Self-Signed" Certificate ............... 118 163 D.2 Certificate ............................................... 119 164 D.2.1 Basic ASN.1 Dump of "End Entity" Certificate ............ 119 165 D.2.2 Pretty Print of "End Entity" Certificate ................ 121 166 D.3 End-Entity Certificate Using RSA .......................... 122 167 D.4 Certificate Revocation List ............................... 127 168 Appendix E. Author Addresses .................................. 128 169 Appendix F. Full Copyright Statement .......................... 128 171 1 Introduction 173 This specification is one part of a family of standards for the X.509 174 Public Key Infrastructure (PKI) for the Internet. This specification 175 is a standalone document; implementations of this standard may 176 proceed independent from the other parts. 178 This specification profiles the format and semantics of certificates 179 and certificate revocation lists for the Internet PKI. Procedures 180 are described for processing of certification paths in the Internet 181 environment. Encoding rules are provided for popular cryptographic 182 algorithms. Finally, ASN.1 modules are provided in the appendices 183 for all data structures defined or referenced. 185 The specification describes the requirements which inspire the crea- 186 tion of this document and the assumptions which affect its scope in 187 Section 2. Section 3 presents an architectural model and describes 188 its relationship to previous IETF and ISO/IEC/ITU standards. In par- 189 ticular, this document's relationship with the IETF PEM specifica- 190 tions and the ISO/IEC/ITU X.509 documents are described. 192 The specification profiles the X.509 version 3 certificate in Section 193 4, and the X.509 version 2 certificate revocation list (CRL) in Sec- 194 tion 5. The profiles include the identification of ISO/IEC/ITU and 195 ANSI extensions which may be useful in the Internet PKI. The profiles 196 are presented in the 1988 Abstract Syntax Notation One (ASN.1) rather 197 than the 1994 syntax used in the ISO/IEC/ITU standards. 199 This specification also includes path validation procedures in Sec- 200 tion 6. These procedures are based upon the ISO/IEC/ITU definition, 201 but the presentation assumes a self-signed trusted CA certificate. 202 Implementations are required to derive the same results but are not 203 required to use the specified procedures. 205 Section 7 of the specification describes procedures for identifica- 206 tion and encoding of public key materials and digital signatures. 207 Implementations are not required to use any particular cryptographic 208 algorithms. However, conforming implementations which use the iden- 209 tified algorithms are required to identify and encode the public key 210 materials and digital signatures as described. 212 Finally, four appendices are provided to aid implementers. Appendix 213 A contains all ASN.1 structures defined or referenced within this 214 specification. As above, the material is presented in the 1988 215 Abstract Syntax Notation One (ASN.1) rather than the 1994 syntax. 216 Appendix B contains the same information in the 1994 ASN.1 notation 217 as a service to implementers using updated toolsets. However, Appen- 218 dix A takes precedence in case of conflict. Appendix C contains 219 notes on less familiar features of the ASN.1 notation used within 220 this specification. Appendix D contains examples of a conforming 221 certificate and a conforming CRL. 223 2 Requirements and Assumptions 225 The goal of this specification is to develop a profile to facilitate 226 the use of X.509 certificates within Internet applications for those 227 communities wishing to make use of X.509 technology. Such applica- 228 tions may include WWW, electronic mail, user authentication, and 229 IPsec. In order to relieve some of the obstacles to using X.509 cer- 230 tificates, this document defines a profile to promote the development 231 of certificate management systems; development of application tools; 232 and interoperability determined by policy. 234 Some communities will need to supplement, or possibly replace, this 235 profile in order to meet the requirements of specialized application 236 domains or environments with additional authorization, assurance, or 237 operational requirements. However, for basic applications, common 238 representations of frequently used attributes are defined so that 239 application developers can obtain necessary information without 240 regard to the issuer of a particular certificate or certificate revo- 241 cation list (CRL). 243 A certificate user should review the certificate policy generated by 244 the certification authority (CA) before relying on the authentication 245 or non-repudiation services associated with the public key in a par- 246 ticular certificate. To this end, this standard does not prescribe 247 legally binding rules or duties. 249 As supplemental authorization and attribute management tools emerge, 250 such as attribute certificates, it may be appropriate to limit the 251 authenticated attributes that are included in a certificate. These 252 other management tools may provide more appropriate methods of con- 253 veying many authenticated attributes. 255 2.1 Communication and Topology 257 The users of certificates will operate in a wide range of environ- 258 ments with respect to their communication topology, especially users 259 of secure electronic mail. This profile supports users without high 260 bandwidth, real-time IP connectivity, or high connection availabil- 261 ity. In addition, the profile allows for the presence of firewall or 262 other filtered communication. 264 This profile does not assume the deployment of an X.500 Directory 265 system. The profile does not prohibit the use of an X.500 Directory, 266 but other means of distributing certificates and certificate 267 revocation lists (CRLs) may be used. 269 2.2 Acceptability Criteria 271 The goal of the Internet Public Key Infrastructure (PKI) is to meet 272 the needs of deterministic, automated identification, authentication, 273 access control, and authorization functions. Support for these ser- 274 vices determines the attributes contained in the certificate as well 275 as the ancillary control information in the certificate such as pol- 276 icy data and certification path constraints. 278 2.3 User Expectations 280 Users of the Internet PKI are people and processes who use client 281 software and are the subjects named in certificates. These uses 282 include readers and writers of electronic mail, the clients for WWW 283 browsers, WWW servers, and the key manager for IPsec within a router. 284 This profile recognizes the limitations of the platforms these users 285 employ and the limitations in sophistication and attentiveness of the 286 users themselves. This manifests itself in minimal user configura- 287 tion responsibility (e.g., trusted CA keys, rules), explicit platform 288 usage constraints within the certificate, certification path con- 289 straints which shield the user from many malicious actions, and 290 applications which sensibly automate validation functions. 292 2.4 Administrator Expectations 294 As with user expectations, the Internet PKI profile is structured to 295 support the individuals who generally operate CAs. Providing 296 administrators with unbounded choices increases the chances that a 297 subtle CA administrator mistake will result in broad compromise. 298 Also, unbounded choices greatly complicate the software that must 299 process and validate the certificates created by the CA. 301 3 Overview of Approach 303 Following is a simplified view of the architectural model assumed by 304 the PKIX specifications. 306 +---+ 307 | C | +------------+ 308 | e | <-------------------->| End entity | 309 | r | Operational +------------+ 310 | t | transactions ^ 311 | | and management | Management 312 | / | transactions | transactions 313 | | | PKI users 314 | C | v 315 | R | -------------------+--+-----------+---------------- 316 | L | ^ ^ 317 | | | | PKI management 318 | | v | entities 319 | R | +------+ | 320 | e | <---------------------| RA | <---+ | 321 | p | Publish certificate +------+ | | 322 | o | | | 323 | s | | | 324 | I | v v 325 | t | +------------+ 326 | o | <------------------------------| CA | 327 | r | Publish certificate +------------+ 328 | y | Publish CRL ^ 329 | | | 330 +---+ Management | 331 transactions | 332 v 333 +------+ 334 | CA | 335 +------+ 337 Figure 1 - PKI Entities 339 The components in this model are: 341 end entity: user of PKI certificates and/or end user system that 342 is the subject of a certificate; 343 CA: certification authority; 344 RA: registration authority, i.e., an optional system to 345 which a CA delegates certain management functions; 346 repository: a system or collection of distributed systems that 347 store certificates and CRLs and serves as a means of 348 distributing these certificates and CRLs to end 349 entities. 351 3.1 X.509 Version 3 Certificate 353 Users of a public key must be confident that the associated private 354 key is owned by the correct remote subject (person or system) with 355 which an encryption or digital signature mechanism will be used. 356 This confidence is obtained through the use of public key certifi- 357 cates, which are data structures that bind public key values to sub- 358 jects. The binding is achieved by having a trusted CA digitally sign 359 each certificate. A certificate has a limited valid lifetime which 360 is indicated in its signed contents. Because a certificate's signa- 361 ture and timeliness can be independently checked by a certificate- 362 using client, certificates can be distributed via untrusted communi- 363 cations and server systems, and can be cached in unsecured storage in 364 certificate-using systems. 366 ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8, which was 367 first published in 1988 as part of the X.500 Directory recommenda- 368 tions, defines a standard certificate format [X.509]. The certificate 369 format in the 1988 standard is called the version 1 (v1) format. 370 When X.500 was revised in 1993, two more fields were added, resulting 371 in the version 2 (v2) format. These two fields may be used to support 372 directory access control. 374 The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993, 375 include specifications for a public key infrastructure based on X.509 376 v1 certificates [RFC 1422]. The experience gained in attempts to 377 deploy RFC 1422 made it clear that the v1 and v2 certificate formats 378 are deficient in several respects. Most importantly, more fields 379 were needed to carry information which PEM design and implementation 380 experience has proven necessary. In response to these new require- 381 ments, ISO/IEC/ITU and ANSI X9 developed the X.509 version 3 (v3) 382 certificate format. The v3 format extends the v2 format by adding 383 provision for additional extension fields. Particular extension 384 field types may be specified in standards or may be defined and 385 registered by any organization or community. In June 1996, standardi- 386 zation of the basic v3 format was completed [X.509]. 388 ISO/IEC/ITU and ANSI X9 have also developed standard extensions for 389 use in the v3 extensions field [X.509][X9.55]. These extensions can 390 convey such data as additional subject identification information, 391 key attribute information, policy information, and certification path 392 constraints. 394 However, the ISO/IEC/ITU and ANSI X9 standard extensions are very 395 broad in their applicability. In order to develop interoperable 396 implementations of X.509 v3 systems for Internet use, it is necessary 397 to specify a profile for use of the X.509 v3 extensions tailored for 398 the Internet. It is one goal of this document to specify a profile 399 for Internet WWW, electronic mail, and IPsec applications. Environ- 400 ments with additional requirements may build on this profile or may 401 replace it. 403 3.2 Certification Paths and Trust 405 A user of a security service requiring knowledge of a public key gen- 406 erally needs to obtain and validate a certificate containing the 407 required public key. If the public-key user does not already hold an 408 assured copy of the public key of the CA that signed the certificate, 409 then it might need an additional certificate to obtain that public 410 key. In general, a chain of multiple certificates may be needed, 411 comprising a certificate of the public key owner (the end entity) 412 signed by one CA, and zero or more additional certificates of CAs 413 signed by other CAs. Such chains, called certification paths, are 414 required because a public key user is only initialized with a limited 415 number of assured CA public keys. 417 There are different ways in which CAs might be configured in order 418 for public key users to be able to find certification paths. For 419 PEM, RFC 1422 defined a rigid hierarchical structure of CAs. There 420 are three types of PEM certification authority: 422 (a) Internet Policy Registration Authority (IPRA): This author- 423 ity, operated under the auspices of the Internet Society, acts as 424 the root of the PEM certification hierarchy at level 1. It issues 425 certificates only for the next level of authorities, PCAs. All 426 certification paths start with the IPRA. 428 (b) Policy Certification Authorities (PCAs): PCAs are at level 2 429 of the hierarchy, each PCA being certified by the IPRA. A PCA 430 must establish and publish a statement of its policy with respect 431 to certifying users or subordinate certification authorities. 432 Distinct PCAs aim to satisfy different user needs. For example, 433 one PCA (an organizational PCA) might support the general elec- 434 tronic mail needs of commercial organizations, and another PCA (a 435 high-assurance PCA) might have a more stringent policy designed 436 for satisfying legally binding digital signature requirements. 438 (c) Certification Authorities (CAs): CAs are at level 3 of the 439 hierarchy and can also be at lower levels. Those at level 3 are 440 certified by PCAs. CAs represent, for example, particular organi- 441 zations, particular organizational units (e.g., departments, 442 groups, sections), or particular geographical areas. 444 RFC 1422 furthermore has a name subordination rule which requires 445 that a CA can only issue certificates for entities whose names are 446 subordinate (in the X.500 naming tree) to the name of the CA itself. 448 The trust associated with a PEM certification path is implied by the 449 PCA name. The name subordination rule ensures that CAs below the PCA 450 are sensibly constrained as to the set of subordinate entities they 451 can certify (e.g., a CA for an organization can only certify entities 452 in that organization's name tree). Certificate user systems are able 453 to mechanically check that the name subordination rule has been fol- 454 lowed. 456 The RFC 1422 uses the X.509 v1 certificate formats. The limitations 457 of X.509 v1 required imposition of several structural restrictions to 458 clearly associate policy information or restrict the utility of cer- 459 tificates. These restrictions included: 461 (a) a pure top-down hierarchy, with all certification paths start- 462 ing from IPRA; 464 (b) a naming subordination rule restricting the names of a CA's 465 subjects; and 467 (c) use of the PCA concept, which requires knowledge of individual 468 PCAs to be built into certificate chain verification logic. 469 Knowledge of individual PCAs was required to determine if a chain 470 could be accepted. 472 With X.509 v3, most of the requirements addressed by RFC 1422 can be 473 addressed using certificate extensions, without a need to restrict 474 the CA structures used. In particular, the certificate extensions 475 relating to certificate policies obviate the need for PCAs and the 476 constraint extensions obviate the need for the name subordination 477 rule. As a result, this document supports a more flexible architec- 478 ture, including: 480 (a) Certification paths may start with a public key of a CA in a 481 user's own domain, or with the public key of the top of a hierar- 482 chy. Starting with the public key of a CA in a user's own domain 483 has certain advantages. In some environments, the local domain is 484 the most trusted. 486 (b) Name constraints may be imposed through explicit inclusion of 487 a name constraints extension in a certificate, but are not 488 required. 490 (c) Policy extensions and policy mappings replace the PCA con- 491 cept, which permits a greater degree of automation. The applica- 492 tion can determine if the certification path is acceptable based 493 on the contents of the certificates instead of a priori knowledge 494 of PCAs. This permits automation of certificate chain processing. 496 3.3 Revocation 498 When a certificate is issued, it is expected to be in use for its 499 entire validity period. However, various circumstances may cause a 500 certificate to become invalid prior to the expiration of the validity 501 period. Such circumstances include change of name, change of associa- 502 tion between subject and CA (e.g., an employee terminates employment 503 with an organization), and compromise or suspected compromise of the 504 corresponding private key. Under such circumstances, the CA needs to 505 revoke the certificate. 507 X.509 defines one method of certificate revocation. This method 508 involves each CA periodically issuing a signed data structure called 509 a certificate revocation list (CRL). A CRL is a time stamped list 510 identifying revoked certificates which is signed by a CA and made 511 freely available in a public repository. Each revoked certificate is 512 identified in a CRL by its certificate serial number. When a 513 certificate-using system uses a certificate (e.g., for verifying a 514 remote user's digital signature), that system not only checks the 515 certificate signature and validity but also acquires a suitably- 516 recent CRL and checks that the certificate serial number is not on 517 that CRL. The meaning of "suitably-recent" may vary with local pol- 518 icy, but it usually means the most recently-issued CRL. A CA issues 519 a new CRL on a regular periodic basis (e.g., hourly, daily, or 520 weekly). An entry is added to the CRL as part of the next update 521 following notification of revocation. An entry may be removed from 522 the CRL after appearing on one regularly scheduled CRL issued beyond 523 the revoked certificate's validity period. 525 An advantage of this revocation method is that CRLs may be distri- 526 buted by exactly the same means as certificates themselves, namely, 527 via untrusted communications and server systems. 529 One limitation of the CRL revocation method, using untrusted communi- 530 cations and servers, is that the time granularity of revocation is 531 limited to the CRL issue period. For example, if a revocation is 532 reported now, that revocation will not be reliably notified to 533 certificate-using systems until the next periodic CRL is issued -- 534 this may be up to one hour, one day, or one week depending on the 535 frequency that the CA issues CRLs. 537 As with the X.509 v3 certificate format, in order to facilitate 538 interoperable implementations from multiple vendors, the X.509 v2 CRL 539 format needs to be profiled for Internet use. It is one goal of this 540 document to specify that profile. However, this profile does not 541 require CAs to issue CRLs. Message formats and protocols supporting 542 on-line revocation notification may be defined in other PKIX specifi- 543 cations. On-line methods of revocation notification may be 544 applicable in some environments as an alternative to the X.509 CRL. 545 On-line revocation checking may significantly reduce the latency 546 between a revocation report and the distribution of the information 547 to relying parties. Once the CA accepts the report as authentic and 548 valid, any query to the on-line service will correctly reflect the 549 certificate validation impacts of the revocation. However, these 550 methods impose new security requirements; the certificate validator 551 must trust the on-line validation service while the repository does 552 not need to be trusted. 554 3.4 Operational Protocols 556 Operational protocols are required to deliver certificates and CRLs 557 (or status information) to certificate using client systems. Provi- 558 sion is needed for a variety of different means of certificate and 559 CRL delivery, including distribution procedures based on LDAP, HTTP, 560 FTP, and X.500. Operational protocols supporting these functions are 561 defined in other PKIX specifications. These specifications may 562 include definitions of message formats and procedures for supporting 563 all of the above operational environments, including definitions of 564 or references to appropriate MIME content types. 566 3.5 Management Protocols 568 Management protocols are required to support on-line interactions 569 between PKI user and management entities. For example, a management 570 protocol might be used between a CA and a client system with which a 571 key pair is associated, or between two CAs which cross-certify each 572 other. The set of functions which potentially need to be supported 573 by management protocols include: 575 (a) registration: This is the process whereby a user first makes 576 itself known to a CA (directly, or through an RA), prior to that 577 CA issuing a certificate or certificates for that user. 579 (b) initialization: Before a client system can operate securely 580 it is necessary to install key materials which have the appropri- 581 ate relationship with keys stored elsewhere in the infrastructure. 582 For example, the client needs to be securely initialized with the 583 public key of a trusted CA, to be used in validating certificate 584 paths. Furthermore, a client typically needs to be initialized 585 with its own key pair(s). 587 (c) certification: This is the process in which a CA issues a 588 certificate for a user's public key, and returns that certificate 589 to the user's client system and/or posts that certificate in a 590 repository. 592 (d) key pair recovery: As an option, user client key materials 593 (e.g., a user's private key used for encryption purposes) may be 594 backed up by a CA or a key backup system. If a user needs to 595 recover these backed up key materials (e.g., as a result of a for- 596 gotten password or a lost key chain file), an on-line protocol 597 exchange may be needed to support such recovery. 599 (e) key pair update: All key pairs need to be updated regularly, 600 i.e., replaced with a new key pair, and new certificates issued. 602 (f) revocation request: An authorized person advises a CA of an 603 abnormal situation requiring certificate revocation. 605 (g) cross-certification: Two CAs exchange information used in 606 establishing a cross-certificate. A cross-certificate is a certi- 607 ficate issued by one CA to another CA which contains a CA signa- 608 ture key used for issuing certificates. 610 Note that on-line protocols are not the only way of implementing the 611 above functions. For all functions there are off-line methods of 612 achieving the same result, and this specification does not mandate 613 use of on-line protocols. For example, when hardware tokens are 614 used, many of the functions may be achieved as part of the physical 615 token delivery. Furthermore, some of the above functions may be com- 616 bined into one protocol exchange. In particular, two or more of the 617 registration, initialization, and certification functions can be com- 618 bined into one protocol exchange. 620 The PKIX series of specifications may define a set of standard mes- 621 sage formats supporting the above functions in future specifications. 622 In that case, the protocols for conveying these messages in different 623 environments (e.g., on-line, file transfer, e-mail, and WWW) will 624 also be described in those specifications. 626 4 Certificate and Certificate Extensions Profile 628 This section presents a profile for public key certificates that will 629 foster interoperability and a reusable PKI. This section is based 630 upon the X.509 v3 certificate format and the standard certificate 631 extensions defined in [X.509]. The ISO/IEC/ITU documents use the 632 1993 version of ASN.1; while this document uses the 1988 ASN.1 syn- 633 tax, the encoded certificate and standard extensions are equivalent. 634 This section also defines private extensions required to support a 635 PKI for the Internet community. 637 Certificates may be used in a wide range of applications and environ- 638 ments covering a broad spectrum of interoperability goals and a 639 broader spectrum of operational and assurance requirements. The goal 640 of this document is to establish a common baseline for generic appli- 641 cations requiring broad interoperability and limited special purpose 642 requirements. In particular, the emphasis will be on supporting the 643 use of X.509 v3 certificates for informal Internet electronic mail, 644 IPsec, and WWW applications. 646 4.1 Basic Certificate Fields 648 The X.509 v3 certificate basic syntax is as follows. For signature 649 calculation, the certificate is encoded using the ASN.1 distinguished 650 encoding rules (DER) [X.208]. ASN.1 DER encoding is a tag, length, 651 value encoding system for each element. 653 Certificate ::= SEQUENCE { 654 tbsCertificate TBSCertificate, 655 signatureAlgorithm AlgorithmIdentifier, 656 signatureValue BIT STRING } 658 TBSCertificate ::= SEQUENCE { 659 version [0] EXPLICIT Version DEFAULT v1, 660 serialNumber CertificateSerialNumber, 661 signature AlgorithmIdentifier, 662 issuer Name, 663 validity Validity, 664 subject Name, 665 subjectPublicKeyInfo SubjectPublicKeyInfo, 666 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 667 -- If present, version must be v2 or v3 668 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 669 -- If present, version must be v2 or v3 670 extensions [3] EXPLICIT Extensions OPTIONAL 671 -- If present, version must be v3 672 } 674 Version ::= INTEGER { v1(0), v2(1), v3(2) } 676 CertificateSerialNumber ::= INTEGER 678 Validity ::= SEQUENCE { 679 notBefore Time, 680 notAfter Time } 682 Time ::= CHOICE { 683 utcTime UTCTime, 684 generalTime GeneralizedTime } 686 UniqueIdentifier ::= BIT STRING 687 SubjectPublicKeyInfo ::= SEQUENCE { 688 algorithm AlgorithmIdentifier, 689 subjectPublicKey BIT STRING } 691 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 693 Extension ::= SEQUENCE { 694 extnID OBJECT IDENTIFIER, 695 critical BOOLEAN DEFAULT FALSE, 696 extnValue OCTET STRING } 698 The following items describe the X.509 v3 certificate for use in the 699 Internet. 701 4.1.1 Certificate Fields 703 The Certificate is a SEQUENCE of three required fields. The fields 704 are described in detail in the following subsections. 706 4.1.1.1 tbsCertificate 708 The field contains the names of the subject and issuer, a public key 709 associated with the subject, a validity period, and other associated 710 information. The fields are described in detail in section 4.1.2; 711 the tbscertificate may also include extensions which are described in 712 section 4.2. 714 4.1.1.2 signatureAlgorithm 716 The signatureAlgorithm field contains the identifier for the crypto- 717 graphic algorithm used by the CA to sign this certificate. Section 718 7.2 lists the supported signature algorithms. 720 An algorithm identifier is defined by the following ASN.1 structure: 722 AlgorithmIdentifier ::= SEQUENCE { 723 algorithm OBJECT IDENTIFIER, 724 parameters ANY DEFINED BY algorithm OPTIONAL } 726 The algorithm identifier is used to identify a cryptographic algo- 727 rithm. The OBJECT IDENTIFIER component identifies the algorithm 728 (such as DSA with SHA-1). The contents of the optional parameters 729 field will vary according to the algorithm identified. Section 7.2 730 lists the supported algorithms for this specification. 732 This field must contain the same algorithm identifier as the signa- 733 ture field in the sequence tbsCertificate (see sec. 4.1.2.3). 735 4.1.1.3 signatureValue 737 The signatureValue field contains a digital signature computed upon 738 the ASN.1 DER encoded tbsCertificate. The ASN.1 DER encoded tbsCer- 739 tificate is used as the input to the signature function. This signa- 740 ture value is then ASN.1 encoded as a BIT STRING and included in the 741 Certificate's signature field. The details of this process are speci- 742 fied for each of the supported algorithms in Section 7.2. 744 By generating this signature, a CA certifies the validity of the 745 information in the tbsCertificate field. In particular, the CA cer- 746 tifies the binding between the public key material and the subject of 747 the certificate. 749 4.1.2 TBSCertificate 751 The sequence TBSCertificate contains information associated with the 752 subject of the certificate and the CA who issued it. Every TBSCerti- 753 ficate contains the names of the subject and issuer, a public key 754 associated with the subject, a validity period, a version number, and 755 a serial number; some may contain optional unique identifier fields. 756 The remainder of this section describes the syntax and semantics of 757 these fields. A TBSCertificate may also include extensions. Exten- 758 sions for the Internet PKI are described in Section 4.2. 760 4.1.2.1 Version 762 This field describes the version of the encoded certificate. When 763 extensions are used, as expected in this profile, use X.509 version 3 764 (value is 2). If no extensions are present, but a UniqueIdentifier 765 is present, use version 2 (value is 1). If only basic fields are 766 present, use version 1 (the value is omitted from the certificate as 767 the default value). 769 Implementations should be prepared to accept any version certificate. 770 At a minimum, conforming implementations shall recognize version 3 771 certificates. 773 Generation of version 2 certificates is not expected by implementa- 774 tions based on this profile. 776 4.1.2.2 Serial number 778 The serial number is an integer assigned by the CA to each certifi- 779 cate. It must be unique for each certificate issued by a given CA 780 (i.e., the issuer name and serial number identify a unique certifi- 781 cate). 783 4.1.2.3 Signature 785 This field contains the algorithm identifier for the algorithm used 786 by the CA to sign the certificate. 788 This field must contain the same algorithm identifier as the signa- 789 tureAlgorithm field in the sequence Certificate (see sec. 4.1.1.2). 790 The contents of the optional parameters field will vary according to 791 the algorithm identified. Section 7.2 lists the supported signature 792 algorithms. 794 4.1.2.4 Issuer 796 The issuer field identifies the entity who has signed and issued the 797 certificate. The issuer field shall contain a non-null distinguished 798 name (DN). The issuer field is defined as the X.501 type Name. Name 799 is defined by the following ASN.1 structures: 801 Name ::= CHOICE { 802 RDNSequence } 804 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 806 RelativeDistinguishedName ::= 807 SET OF AttributeTypeAndValue 809 AttributeTypeAndValue ::= SEQUENCE { 810 type AttributeType, 811 value AttributeValue } 813 AttributeType ::= OBJECT IDENTIFIER 815 AttributeValue ::= ANY DEFINED BY AttributeType 817 DirectoryString ::= CHOICE { 818 teletexString TeletexString (SIZE (1..MAX)), 819 printableString PrintableString (SIZE (1..MAX)), 820 universalString UniversalString (SIZE (1..MAX)), 821 utf8String UTF8String (SIZE (1.. MAX)), 822 bmpString BMPString (SIZE (1..MAX)) } 824 The Name describes a hierarchical name composed of attributes, such 825 as country name, and corresponding values, such as US. The type of 826 the component AttributeValue is determined by the AttributeType; in 827 general it will be a DirectoryString. 829 The DirectoryString type is defined as a choice of PrintableString, 830 TeletexString, BMPString UTF8String and UniversalString. When 831 creating a distinguished name, including their own, conforming CAs 832 shall choose from these options as follows: 834 (a) if the character set is sufficient, the string will be 835 represented as a PrintableString; 837 (b) failing (a), if the BMPString character set is sufficient the 838 string shall be represented as a BMPString; and 840 (c) failing (a) and (b), the string shall be represented as a 841 UTF8String. 843 The TeletexString and UniversalString are included for backward com- 844 patibility, and should not be used for certificates for new subjects. 845 However, these types may be used in certificates where the name was 846 previously established. Certificate users should be prepared to 847 receive certificates with these string types. 849 Standard sets of attributes have been defined in the X.500 series of 850 specifications. This specification recommends that issuer names con- 851 tain only the following attribute types: country, organization, 852 organizational-unit, distinguished name qualifier, title, locality, 853 state or province name, common name (e.g., "Susan Housley"), surname, 854 given name, initials, and generationqualifier (e.g., "Jr." or "IV"). 855 The syntax and associated object identifiers (OIDs) for these attri- 856 bute types are provided in the ASN.1 modules in Appendices A and B. 858 Certificate users must be prepared to process the issuer dis- 859 tinguished name and subject distinguished name (see sec. 4.1.2.6) 860 fields to perform name chaining for certification path validation 861 (see section 6). Name chaining is performed by matching the issuer 862 distinguished name in one certificate with the subject name in 863 another. 865 This specification requires only a subset of the name comparison 866 functionality specified in X.501. The requirements for conforming 867 implementations are as follows: 869 (a) attribute values encoded in different string types (e.g., 870 PrintableString and BMPString) may be assumed to represent dif- 871 ferent strings; 873 (b) attribute values in string types other than PrintableString 874 are case sensitive (this permits matching of attribute values as 875 binary objects); 877 (c) attribute values in PrintableString are not case sensitive 878 (e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and 879 (d) attribute values in PrintableString are compared after remov- 880 ing leading and trailing white space and converting internal 881 strings of one or more consecutive white space characters to a 882 single space. 884 These name comparison rules permit a certificate user to validate 885 certificates issued using languages or encodings unfamiliar to the 886 certificate user. 888 4.1.2.5 Validity 890 The certificate validity period is the time interval during which the 891 CA warrants that it will maintain information about the status of the 892 certificate. The field is represented as a SEQUENCE of two dates: 893 the date on which the certificate validity period begins (notBefore) 894 and the date on which the certificate validity period ends 895 (notAfter). Both notBefore and notAfter may be encoded as UTCTime or 896 GeneralizedTime. 898 CAs conforming to this profile shall always encode certificate vali- 899 dity dates through the year 2049 as UTCTime; certificate validity 900 dates in 2050 or later shall be encoded as GeneralizedTime. 902 4.1.2.5.1 UTCTime 904 The universal time type, UTCTime, is a standard ASN.1 type intended 905 for international applications where local time alone is not ade- 906 quate. UTCTime specifies the year through the two low order digits 907 and time is specified to the precision of one minute or one second. 908 UTCTime includes either Z (for Zulu, or Greenwich Mean Time) or a 909 time differential. 911 For the purposes of this profile, UTCTime values shall be expressed 912 Greenwich Mean Time (Zulu) and shall include seconds (i.e., times are 913 YYMMDDHHMMSSZ), even where the number of seconds is zero. Conforming 914 systems shall interpret the year field (YY) as follows: 916 Where YY is greater than or equal to 50, the year shall be inter- 917 preted as 19YY; and 919 Where YY is less than 50, the year shall be interpreted as 20YY. 921 4.1.2.5.2 GeneralizedTime 923 The generalized time type, GeneralizedTime, is a standard ASN.1 type 924 for variable precision representation of time. Optionally, the Gen- 925 eralizedTime field can include a representation of the time differen- 926 tial between local and Greenwich Mean Time. 928 For the purposes of this profile, GeneralizedTime values shall be 929 expressed Greenwich Mean Time (Zulu) and shall include seconds (i.e., 930 times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. 931 GeneralizedTime values shall not include fractional seconds. 933 4.1.2.6 Subject 935 The subject field identifies the entity associated with the public 936 key stored in the subject public key field. The subject name may be 937 carried in the subject field and/or the subjectAltName extension. If 938 the subject is a CA (e.g., the basic constraints extension, as dis- 939 cussed in 4.2.1.10, is present and the value of cA is TRUE,) then the 940 subject field must be populated with a non-null distinguished name 941 matching the contents of the issuer field (see sec. 4.1.2.4) in all 942 certificates issued by the subject CA. If subject naming information 943 is present only in the subjectAltName extension (e.g., a key bound 944 only to an email address or URI), then the subject name must be an 945 empty sequence and the subjectAltName extension must be critical. 947 Where it is non-empty, the subject field shall contain an X.500 dis- 948 tinguished name (DN). The DN must be unique for each subject entity 949 certified by the one CA as defined by the issuer name field. (A CA 950 may issue more than one certificate with the same DN to the same sub- 951 ject entity.) 953 The subject name field is defined as the X.501 type Name, and shall 954 follow the encoding rules for the issuer name field (see sec. 955 4.1.2.4). When encoding strings as the type PrintableString, conform- 956 ing CAs should use mixed case but should not include leading or 957 trailing white space and should limit internal white space to sub- 958 strings of a single space. 960 Implementations of this specification should be prepared to receive 961 the following X.501 attribute types: country, organization, 962 organizational-unit, distinguished name qualifier, title, locality, 963 state or province name, common name (e.g., "Susan Housley"), surname, 964 given name, initials, and generationqualifier (e.g., "Jr." or "IV"). 965 The syntax and associated object identifiers (OIDs) for these attri- 966 bute types are provided in the ASN.1 modules in Appendices A and B. 968 Legacy implementations exist where an RFC 822 name is embedded in the 969 subject distinguished name as a PKCS #9 EmailAddress attribute [PKCS 970 #9]. Conforming implementations generating new certificates with 971 electronic mail addresses must use the rfc822Name in the subject 972 alternative name field (see sec. 4.2.1.7) to describe such identi- 973 ties. Simultaneous inclusion of the EmailAddress attribute in the 974 subject distinugished name to support legacy implementations is 975 deprecated but permitted. 977 The ASN.1 syntax for EmailAddress and the corresponding OID are sup- 978 plied below. 980 EmailAddress ::= IA5String 982 pkcs-9 OBJECT IDENTIFIER ::= 983 { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 9 } 985 emailAddress OBJECT IDENTIFIER ::= { pkcs-9 1 } 987 4.1.2.7 Subject Public Key Info 989 This field is used to carry the public key and identify the algorithm 990 with which the key is used. The algorithm is identified using the 991 AlgorithmIdentifier structure specified in section 4.1.1.2. The 992 object identifiers for the supported algorithms and the methods for 993 encoding the public key materials (public key and parameters) are 994 specified in section 7.3. 996 4.1.2.8 Unique Identifiers 998 These fields may only appear if the version is 2 or 3 (see sec. 999 4.1.2.1). The subject and issuer unique identifiers are present in 1000 the certificate to handle the possibility of reuse of subject and/or 1001 issuer names over time. This profile recommends that names not be 1002 reused for different entities and that Internet certificates not make 1003 use of unique identifiers. CAs conforming to this profile should not 1004 generate certificates with unique identifiers. Applications conform- 1005 ing to this profile should be capable of parsing unique identifiers 1006 and making comparisons. 1008 4.1.2.9 Extensions 1010 This field may only appear if the version is 3 (see sec. 4.1.2.1). 1011 If present, this field is a SEQUENCE of one or more certificate 1012 extensions. The format and content of certificate extensions in the 1013 Internet PKI is defined in section 4.2. 1015 4.2 Standard Certificate Extensions 1017 The extensions defined for X.509 v3 certificates provide methods for 1018 associating additional attributes with users or public keys and for 1019 managing the certification hierarchy. The X.509 v3 certificate for- 1020 mat also allows communities to define private extensions to carry 1021 information unique to those communities. Each extension in a certi- 1022 ficate may be designated as critical or non-critical. A certificate 1023 using system must reject the certificate if it encounters a critical 1024 extension it does not recognize; however, a non-critical extension 1025 may be ignored if it is not recognized. The following sections 1026 present recommended extensions used within Internet certificates and 1027 standard locations for information. Communities may elect to use 1028 additional extensions; however, caution should be exercised in adopt- 1029 ing any critical extensions in certificates which might prevent use 1030 in a general context. 1032 Each extension includes an OID and an ASN.1 structure. When an 1033 extension appears in a certificate, the OID appears as the field 1034 extnID and the corresponding ASN.1 encoded structure is the value of 1035 the octet string extnValue. Only one instance of a particular exten- 1036 sion may appear in a particular certificate. For example, a certifi- 1037 cate may contain only one authority key identifier extension (see 1038 sec. 4.2.1.1). An extension includes the boolean critical, with a 1039 default value of FALSE. The text for each extension specifies the 1040 acceptable values for the critical field. 1042 Conforming CAs are required to support key identifiers (see sec. 1043 4.2.1.1 and 4.2.1.2), basic constraints (see sec. 4.2.1.10), key 1044 usage (see sec. 4.2.1.3), and certificate policies (see sec. 4.2.1.5) 1045 extensions. If the CA issues certificates with an empty sequence for 1046 the subject field, the CA must support the subject alternative name 1047 extension (see sec. 4.2.1.7). Support for the remaining extensions 1048 is optional. Conforming CAs may support extensions that are not iden- 1049 tified within this specification; certificate issuers are cautioned 1050 that marking such extensions as critical may inhibit interoperabil- 1051 ity. 1053 At a minimum, applications conforming to this profile shall recognize 1054 the extensions which shall or may be critical in this specification. 1055 These extensions are: key usage (see sec. 4.2.1.3), certificate pol- 1056 icies (see sec. 4.2.1.5), the subject alternative name (see sec. 1057 4.2.1.7), basic constraints (see sec. 4.2.1.10), name constraints 1058 (see sec. 4.2.1.11), policy constraints (see sec. 4.2.1.12), and 1059 extended key usage (see sec. 4.2.1.13). 1061 In addition, this profile recommends application support for key 1062 identifiers (see sec. 4.2.1.1 and 4.2.1.2) extensions. 1064 4.2.1 Standard Extensions 1066 This section identifies standard certificate extensions defined in 1067 [X.509] for use in the Internet PKI. Each extension is associated 1068 with an OID defined in [X.509]. These OIDs are members of the certi- 1069 ficateExtension arc, which is defined by the following: 1071 certificateExtension OBJECT IDENTIFIER ::= 1072 {joint-iso-ccitt(2) ds(5) 29} 1074 id-ce OBJECT IDENTIFIER ::= certificateExtension 1076 4.2.1.1 Authority Key Identifier 1078 The authority key identifier extension provides a means of identify- 1079 ing the public key corresponding to the private key used to sign a 1080 certificate. This extension is used where an issuer has multiple 1081 signing keys (either due to multiple concurrent key pairs or due to 1082 changeover). The identification may be based on either the key iden- 1083 tifier (the subject key identifier in the issuer's certificate) or on 1084 the issuer name and serial number. 1086 The keyIdentifier field of the authorityKeyIdentifier extension shall 1087 be included in all certificates generated by conforming CAs to facil- 1088 itate chain building. This profile recommends support for the key 1089 identifier method by all certificate users. There is one exception; 1090 where a CA distributes its public key in the form of a "self-signed" 1091 certificate, the authority key identifier may be omitted. In this 1092 case, the subject and authority key identifiers would be identical. 1094 This extension shall not be marked critical. 1096 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 1098 AuthorityKeyIdentifier ::= SEQUENCE { 1099 keyIdentifier [0] KeyIdentifier OPTIONAL, 1100 authorityCertIssuer [1] GeneralNames OPTIONAL, 1101 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL 1102 } 1104 KeyIdentifier ::= OCTET STRING 1106 4.2.1.2 Subject Key Identifier 1108 The subject key identifier extension provides a means of identifying 1109 the particular public key used in an application. This extension 1110 should be included in all certificates. 1112 To facilitate chain building, this extension MUST appear in all con- 1113 forming CA certificates, that is, all certificates including the 1114 basic constraints extension (see sec. 4.2.1.10) where the value of cA 1115 is TRUE. The value of the subject key identifier shall be the value 1116 placed in the key identifier field of the Authority Key Identifier 1117 extension (see sec. 4.2.1.1) of certificates issued by the subject of 1118 this certificate. 1120 Where a key identifier has not been previously established, this 1121 specification recommends the following method for generating 1122 keyIdentifiers: the keyIdentifier is composed of a four bit type 1123 field with the value 0100 followed by the least significant 60 bits 1124 of the SHA-1 hash of the BIT STRING subjectPublicKey. 1126 This extension should be marked non-critical. 1128 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 1130 SubjectKeyIdentifier ::= KeyIdentifier 1132 4.2.1.3 Key Usage 1134 The key usage extension defines the purpose (e.g., encipherment, sig- 1135 nature, certificate signing) of the key contained in the certificate. 1136 The usage restriction might be employed when a key that could be used 1137 for more than one operation is to be restricted. For example, when 1138 an RSA key should be used only for signing, the digitalSignature 1139 and/or nonRepudiation bits would be asserted. Likewise, when an RSA 1140 key should be used only for key management, the keyEncipherment bit 1141 would be asserted. When used, this extension should be marked criti- 1142 cal. 1144 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 1146 KeyUsage ::= BIT STRING { 1147 digitalSignature (0), 1148 nonRepudiation (1), 1149 keyEncipherment (2), 1150 dataEncipherment (3), 1151 keyAgreement (4), 1152 keyCertSign (5), 1153 cRLSign (6), 1154 encipherOnly (7), 1155 decipherOnly (8) } 1157 Bits in the KeyUsage type are used as follows: 1159 The digitalSignature bit is asserted when the subject public key 1160 is used to verify digital signatures that have purposes other than 1161 non-repudiation, certificate signature, and CRL signature. For 1162 example, the digitalSignature bit is asserted when the subject 1163 public key is used to provide authentication. 1165 The nonRepudiation bit is asserted when the subject public key is 1166 used to verify digital signatures used to provide a non- 1167 repudiation service which protects against the signing entity 1168 falsely denying some action, excluding certificate or CRL signing. 1170 The keyEncipherment bit is asserted when the subject public key is 1171 used for key transport. For example, when an RSA key is to be 1172 used for key management, then this bit must asserted. 1174 The dataEncipherment bit is asserted when the subject public key 1175 is used for enciphering user data, other than cryptographic keys. 1177 The keyAgreement bit is asserted when the subject public key is 1178 used for key agreement. For example, when a Diffie-Hellman key is 1179 to be used for key management, then this bit must asserted. 1181 The keyCertSign bit is asserted when the subject public key is 1182 used for verifying a signature on certificates. This bit may only 1183 be asserted in CA certificates. 1185 The cRLSign bit is asserted when the subject public key is used 1186 for verifying a signature on revocation information (e.g., a CRL). 1188 The meaning of the encipherOnly bit is undefined in the absence of 1189 the keyAgreement bit. When the encipherOnly bit is asserted and 1190 the keyAgreement bit is also set, the subject public key may be 1191 used only for enciphering data while performing key agreement. 1193 The meaning of the decipherOnly bit is undefined in the absence of 1194 the keyAgreement bit. When the decipherOnly bit is asserted and 1195 the keyAgreement bit is also set, the subject public key may be 1196 used only for deciphering data while performing key agreement. 1198 This profile does not restrict the combinations of bits that may be 1199 set in an instantiation of the keyUsage extension. However, 1200 appropriate values for keyUsage extensions for particular algorithms 1201 are specified in section 7.3. 1203 4.2.1.4 Private Key Usage Period 1205 This profile recommends against the use of this extension. CAs con- 1206 forming to this profile shall not generate certificates with critical 1207 private key usage period extensions. 1209 The private key usage period extension allows the certificate issuer 1210 to specify a different validity period for the private key than the 1211 certificate. This extension is intended for use with digital signa- 1212 ture keys. This extension consists of two optional components, 1213 notBefore and notAfter. The private key associated with the certifi- 1214 cate should not be used to sign objects before or after the times 1215 specified by the two components, respectively. CAs conforming to this 1216 profile shall not generate certificates with private key usage period 1217 extensions unless at least one of the two components is present. 1219 Where used, notBefore and notAfter are represented as GeneralizedTime 1220 and shall be specified and interpreted as defined in section 1221 4.1.2.5.2. 1223 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 1225 PrivateKeyUsagePeriod ::= SEQUENCE { 1226 notBefore [0] GeneralizedTime OPTIONAL, 1227 notAfter [1] GeneralizedTime OPTIONAL } 1229 4.2.1.5 Certificate Policies 1231 The certificate policies extension contains a sequence of one or more 1232 policy information terms, each of which consists of an object iden- 1233 tifier (OID) and optional qualifiers. These policy information terms 1234 indicate the policy under which the certificate has been issued and 1235 the purposes for which the certificate may be used. Optional qualif- 1236 iers, which may be present, are not expected to change the definition 1237 of the policy. 1239 Applications with specific policy requirements are expected to have a 1240 list of those policies which they will accept and to compare the pol- 1241 icy OIDs in the certificate to that list. If this extension is crit- 1242 ical, the path validation software must be able to interpret this 1243 extension (including the optional qualifier), or must reject the cer- 1244 tificate. 1246 To promote interoperability, this profile recommends that policy 1247 information terms consist of only an OID. Where an OID alone is 1248 insufficient, this profile strongly recommends that use of qualifiers 1249 be limited to those identified in this section. 1251 This specification defines two policy qualifier types for use by cer- 1252 tificate policy writers and certificate issuers. The qualifier types 1253 are the CPS Pointer and User Notice qualifiers. 1255 The CPS Pointer qualifier contains a pointer to a Certification Prac- 1256 tice Statement (CPS) published by the CA. The pointer is in the form 1257 of a URI. 1259 User notice is intended for display to a relying party when a certi- 1260 ficate is used. The application software should display all user 1261 notices in all certificates of the certification path used, except 1262 that if a notice is duplicated only one copy need be displayed. To 1263 prevent such duplication, this qualifier should only be present in 1264 end-entity certificates and CA certificates issued to other organiza- 1265 tions. 1267 The user notice has two optional fields: the noticeRef field and the 1268 explicitText field. 1270 The noticeRef field, if used, names an organization and identi- 1271 fies, by number, a particular textual statement prepared by that 1272 organization. For example, it might identify the organization 1273 "CertsRUs" and notice number 1. In a typical implementation, the 1274 application software will have a notice file containing the 1275 current set of notices for CertsRUs; the application will extract 1276 the notice text from the file and display it. Messages may be 1277 multilingual, allowing the software to select the particular 1278 language message for its own environment. 1280 An explicitText field includes the textual statement directly in 1281 the certificate. The explicitText field is a string with a max- 1282 imum size of 200 characters. 1284 If both the noticeRef and explicitText options are included in the 1285 one qualifier and if the application software can locate the notice 1286 text indicated by the noticeRef option then that text should be 1287 displayed; otherwise, the explicitText string should be displayed. 1289 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 1291 certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 1293 PolicyInformation ::= SEQUENCE { 1294 policyIdentifier CertPolicyId, 1295 policyQualifiers SEQUENCE SIZE (1..MAX) OF 1296 PolicyQualifierInfo OPTIONAL } 1298 CertPolicyId ::= OBJECT IDENTIFIER 1300 PolicyQualifierInfo ::= SEQUENCE { 1301 policyQualifierId PolicyQualifierId, 1302 qualifier ANY DEFINED BY policyQualifierId } 1304 -- policyQualifierIds for Internet policy qualifiers 1306 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 1307 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 1308 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 1310 PolicyQualifierId ::= 1311 OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) 1313 Qualifier ::= CHOICE { 1314 cPSuri CPSuri, 1315 userNotice UserNotice } 1317 CPSuri ::= IA5String 1319 UserNotice ::= SEQUENCE { 1320 noticeRef NoticeReference OPTIONAL, 1321 explicitText DisplayText OPTIONAL} 1323 NoticeReference ::= SEQUENCE { 1324 organization DisplayText, 1325 noticeNumbers SEQUENCE OF INTEGER } 1327 DisplayText ::= CHOICE { 1328 visibleString VisibleString (SIZE (1..200)), 1329 bmpString BMPString (SIZE (1..200)), 1330 utf8String UTF8String (SIZE (1..200)) } 1332 4.2.1.6 Policy Mappings 1334 This extension is used in CA certificates. It lists one or more 1335 pairs of OIDs; each pair includes an issuerDomainPolicy and a sub- 1336 jectDomainPolicy. The pairing indicates the issuing CA considers its 1337 issuerDomainPolicy equivalent to the subject CA's subjectDomainPol- 1338 icy. 1340 The issuing CA's users may accept an issuerDomainPolicy for certain 1341 applications. The policy mapping tells the issuing CA's users which 1342 policies associated with the subject CA are comparable to the policy 1343 they accept. 1345 This extension may be supported by CAs and/or applications, and it is 1346 always non-critical. 1348 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 1350 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 1351 issuerDomainPolicy CertPolicyId, 1352 subjectDomainPolicy CertPolicyId } 1354 4.2.1.7 Subject Alternative Name 1356 The subject alternative names extension allows additional identities 1357 to be bound to the subject of the certificate. Defined options 1358 include an Internet electronic mail address, a DNS name, an IP 1359 address, and a uniform resource indentifier (URI). Other options 1360 exist, including completely local definitions. Multiple name forms, 1361 and multiple instances of each name form, may be included. Whenever 1362 such identities are to be bound into a certificate, the subject 1363 alternative name (or issuer alternative name) extension shall be 1364 used. (Note: a form of such an identifier may also be present in the 1365 subject distinguished name; however, the alternative name extension 1366 is the preferred location for finding such information.) 1368 Because the subject alternative name is considered to be defini- 1369 tiviely bound to the public key, all parts of the subject alternative 1370 name must be verified by the CA. 1372 Further, if the only subject identity included in the certificate is 1373 an alternative name form (e.g., an electronic mail address), then the 1374 subject distinguished name shall be empty (an empty sequence), and 1375 the subjectAltName extension shall be present. If the subject field 1376 contains an empty sequence, the subjectAltName extension shall be 1377 marked critical. 1379 When the subjectAltName extension contains an Internet mail address, 1380 the adress shall be included as an rfc822Name. The format of an 1381 rfc822Name is an "addr-spec" as defined in RFC 822 [RFC 822]. An 1382 addr-spec has the form "local-part@domain". Note that an addr-spec 1383 has no phrase (such as a common name) before it, has no comment (text 1384 surrounded in parentheses) after it, and is not surrounded by "<" and 1385 ">". 1387 When the subjectAltName extension contains a iPAddress, the address 1388 shall be stored in the octet string in "network byte order," as 1389 specified in RFC 791 [RFC 791]. The least significant bit (LSB) of 1390 each octet is the LSB of the corresponding byte in the network 1391 address. For IP Version 4, as specified in RFC 791, the octet string 1392 must contain exactly four octets. For IP Version 6, as specified in 1393 RFC 1883, the octet string must contain exactly sixteen octets [RFC 1394 1883]. 1396 When the subjectAltName extension contains a domain name service 1397 label, the domain name shall be stored in the dNSName (an IA5String). 1398 The string shall be in the "preferred name syntax," as specified by 1399 RFC 1034 [RFC 1034]. Note that while upper and lower case letters are 1400 allowed in domain names, no signifigance is attached to the case. In 1401 addition, while the string " " is a legal domain name, subjectAltName 1402 extensions with a dNSName " " are not permitted. Finally, the use of 1403 the DNS representation for Internet mail addresses (wpolk.nist.gov 1404 instead of wpolk@nist.gov) is not permitted; such identities are to 1405 be encoded as rfc822Name. 1407 Subject alternative names may be constrained in the same manner as 1408 subject distinguished names using the name constraints extension as 1409 described in section 4.2.1.11. 1411 If the subjectAltName extension is present, the sequence must contain 1412 at least one entry. Unlike the subject field, conforming CAs shall 1413 not issue certificates with subjectAltNames containing empty General- 1414 Name fields. For example, an rfc822Name is represented as an 1415 IA5String. While an empty string is a valid IA5String, such an 1416 rfc822Name is not permitted by this profile. The behavior of clients 1417 that encounter such a certificate when processing a certificication 1418 path is not defined by this profile. 1420 Finally, the semantics of subject alternative names that include 1421 wildcard characters (e.g., as a placeholder for a set of names) are 1422 not addressed by this specification. Applications with specific 1423 requirements may use such names but must define the semantics. 1425 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 1427 SubjectAltName ::= GeneralNames 1429 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 1431 GeneralName ::= CHOICE { 1432 otherName [0] OtherName, 1433 rfc822Name [1] IA5String, 1434 dNSName [2] IA5String, 1435 x400Address [3] ORAddress, 1436 directoryName [4] Name, 1437 ediPartyName [5] EDIPartyName, 1438 uniformResourceIdentifier [6] IA5String, 1439 iPAddress [7] OCTET STRING, 1440 registeredID [8] OBJECT IDENTIFIER} 1442 OtherName ::= SEQUENCE { 1443 type-id OBJECT IDENTIFIER, 1444 value [0] EXPLICIT ANY DEFINED BY type-id } 1446 EDIPartyName ::= SEQUENCE { 1447 nameAssigner [0] DirectoryString OPTIONAL, 1448 partyName [1] DirectoryString } 1450 4.2.1.8 Issuer Alternative Names 1452 As with 4.2.1.7, this extension is used to associate Internet style 1453 identities with the certificate issuer. Issuer alternative names 1454 shall be encoded as in 4.2.1.7. 1456 Where present, this extension should not be marked critical. 1458 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 1460 IssuerAltName ::= GeneralNames 1462 4.2.1.9 Subject Directory Attributes 1464 The subject directory attributes extension is not recommended as an 1465 essential part of this profile, but it may be used in local environ- 1466 ments. This extension is always non-critical. 1468 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 1470 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 1472 4.2.1.10 Basic Constraints 1474 The basic constraints extension identifies whether the subject of the 1475 certificate is a CA and how deep a certification path may exist 1476 through that CA. 1478 The pathLenConstraint field is meaningful only if cA is set to TRUE. 1479 In this case, it gives the maximum number of CA certificates that may 1480 follow this certificate in a certification path. A value of zero 1481 indicates that only an end-entity certificate may follow in the path. 1482 Where it appears, the pathLenConstraint field must be greater than or 1483 equal to zero. Where pathLenConstraint does not appear, there is no 1484 limit to the allowed length of the certification path. 1486 This extension shall appear as a critical extension in all CA certi- 1487 ficates. This extension should not appear in other certificates. 1489 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 1491 BasicConstraints ::= SEQUENCE { 1492 cA BOOLEAN DEFAULT FALSE, 1493 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 1495 4.2.1.11 Name Constraints 1497 The name constraints extension, which shall be used only in a CA cer- 1498 tificate, indicates a name space within which all subject names in 1499 subsequent certificates in a certification path must be located. 1500 Restrictions may apply to the subject distinguished name or subject 1501 alternative names. Restrictions apply only when the specified name 1502 form is present. If no name of the type is in the certificate, the 1503 certificate is acceptable. 1505 Restrictions are defined in terms of permitted or excluded name 1506 subtrees. Any name matching a restriction in the excludedSubtrees 1507 field is invalid regardless of information appearing in the permit- 1508 tedSubtrees. This extension must be critical. 1510 Within this profile, the minimum and maximum fields are not used with 1511 any name forms, thus minimum is always zero, and maximum is always 1512 absent. 1514 Restrictions for the rfc822 and uri name forms are all expressed in 1515 terms of strings with wild card matching. An "*" is the wildcard 1516 character. 1518 For URIs, the constraint applies to the host part of the name. Exam- 1519 ples would be foo.bar.com; www*.bar.com; and *.xyz.com. When a wild- 1520 card appears as the leftmost subdomain, it may be matched with one or 1521 more subdomains. That is, the constraint "*.xyz.com" is satisfied by 1522 both abc.xyz.com and abc.def.xyz.com. However, the constraint 1523 "*.xyz.com" is not satisfied by "xyz.com". Otherwise, the wildcard 1524 may only be expanded within a single subdomain. That is, www*.bar.com 1525 is satisfied by www1.bar.com but not www.foo.bar.com. 1527 To indicate all Internet mail addresses on a particular host, the "*" 1528 character is used. For example, "*@xyz.com" indicates all mail 1529 addresses at the host "xyz.com". Note that although "*" is a valid 1530 character in Internet mail addresses, it is very rarely used on the 1531 Internet, and thus is appropriated by this specification for the 1532 email wildcard. 1534 Internet mail addresses may also be constrained by the host part of 1535 the name, as with URIs. For example, "root@*.xyz.com" indicates all 1536 the Internet mail addresses root in the domain "xyz.com". As above, 1537 "*" is a valid character in the host part of the name, but it is very 1538 rarely used on the Internet, and thus is appropriated by this specif- 1539 ication for the mail address wildcard. 1541 To indicate all Internet mail addresses in a particular domain, these 1542 mechanisms may be combined. For example, "*@*.xyz.com" indicates all 1543 email addresses in the domain "xyz.com". 1545 DNS name restrictions are expressed as foo.bar.com. Any DNS name that 1546 can be constructed by simply adding to the left hand side of the name 1547 satisfies the name constraint. For example, www.foo.bar.com would 1548 satisfy the constraint but foo1.bar.com would not. 1550 Legacy implementations exist where an RFC 822 name is embedded in the 1551 subject distinguished name as a PKCS #9 e-mail attribute, which has 1552 the ASN.1 type EmailAddress [PKCS #9] (see sec. 4.1.2.6). When rfc822 1553 names are constrained, but the certificate does not include a subject 1554 alternative name, the rfc822 name constraint must be applied to PKCS 1555 #9 e-mail attributes in the subject distinguished name. The ASN.1 1556 syntax for EmailAddress and the corresponding OID are supplied in 1557 4.1.2.6. 1559 Restrictions of the form directoryName shall be applied to the sub- 1560 ject field in the certificate and to the subjectAltName extensions of 1561 type directoryName. Restrictions of the form x400Address shall be 1562 applied to subjectAltName extensions of type x400Address. 1564 The syntax of iPAddress shall be as described in section 4.2.1.7 with 1565 the following additions specifically for Name Constraints. For IPv4 1566 addresses, the ipAddress field of generalName shall contain eight (8) 1567 octets, encoded in the style of RFC 1519 (CIDR) to represent an 1568 address range. For IPv6 addresses, the ipAddress field shall contain 1569 32 octets similarly encoded. For example, a name constraint for 1570 "class C" subnet 10.9.8.0 shall be represented as the octets 0A 09 08 1571 00 FF FF FF 00, representing the CIDR notation 1572 10.9.8.0/255.255.255.0. 1574 The syntax and semantics for name constraints for otherName, ediPar- 1575 tyName, and registeredID are not defined by this specification. 1577 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 1579 NameConstraints ::= SEQUENCE { 1580 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 1581 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 1583 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 1585 GeneralSubtree ::= SEQUENCE { 1586 base GeneralName, 1587 minimum [0] BaseDistance DEFAULT 0, 1588 maximum [1] BaseDistance OPTIONAL } 1590 BaseDistance ::= INTEGER (0..MAX) 1592 4.2.1.12 Policy Constraints 1594 The policy constraints extension can be used in certificates issued 1595 to CAs. The policy constraints extension constrains path validation 1596 in two ways. It can be used to prohibit policy mapping or require 1597 that each certificate in a path contain an acceptable policy identif- 1598 ier. 1600 If the inhibitPolicyMapping field is present, the value indicates the 1601 number of additional certificates that may appear in the path before 1602 policy mapping is no longer permitted. For example, a value of one 1603 indicates that policy mapping may be processed in certificates issued 1604 by the subject of this certificate, but not in additional certifi- 1605 cates in the path. 1607 If the requireExplicitPolicy field is present, subsequent certifi- 1608 cates must include an acceptable policy identifier. The value of 1609 requireExplicitPolicy indicates the number of additional certificates 1610 that may appear in the path before an explicit policy is required. 1611 An acceptable policy identifier is the identifier of a policy 1612 required by the user of the certification path or the identifier of a 1613 policy which has been declared equivalent through policy mapping. 1615 Conforming CAs shall not issue certificates where policy constraints 1616 is a null sequence. That is, at least one of the inhibitPolicyMapping 1617 field or the requireExplicitPolicy field must be present. The 1618 behavior of clients that encounter a null policy constraints field is 1619 not addressed in this profile. 1621 This extension may be critical or non-critical. 1623 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } 1625 CertificatePoliciesSyntax ::= 1626 SEQUENCE SIZE (1..MAX) OF PolicyInformation 1628 PolicyConstraints ::= SEQUENCE { 1629 requireExplicitPolicy [0] SkipCerts OPTIONAL, 1630 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 1632 SkipCerts ::= INTEGER (0..MAX) 1634 4.2.1.13 Extended key usage field 1636 This field indicates one or more purposes for which the certified 1637 public key may be used, in addition to or in place of the basic pur- 1638 poses indicated in the key usage extension field. This field is 1639 defined as follows: 1641 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 1643 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 1645 KeyPurposeId ::= OBJECT IDENTIFIER 1647 Key purposes may be defined by any organization with a need. Object 1648 identifiers used to identify key purposes shall be assigned in accor- 1649 dance with IANA or ITU-T Rec. X.660 | ISO/IEC/ITU 9834-1. 1651 This extension may, at the option of the certificate issuer, be 1652 either critical or non-critical. 1654 If the extension is flagged critical, then the certificate shall be 1655 used only for one of the purposes indicated. 1657 If the extension is flagged non-critical, then it indicates the 1658 intended purpose or purposes of the key, and may be used in finding 1659 the correct key/certificate of an entity that has multiple 1660 keys/certificates. It is an advisory field and does not imply that 1661 usage of the key is restricted by the certification authority to the 1662 purpose indicated. Certificate using applications may nevertheless 1663 require that a particular purpose be indicated in order for the cer- 1664 tificate to be acceptable to that application. 1666 If a certificate contains both a critical key usage field and a crit- 1667 ical extended key usage field, then both fields shall be processed 1668 independently and the certificate shall only be used for a purpose 1669 consistent with both fields. If there is no purpose consistent with 1670 both fields, then the certificate shall not be used for any purpose. 1672 The following key usage purposes are defined by this profile: 1674 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 1676 id-kp-serverAuth OBJECT IDENTIFIER ::= {id-kp 1} 1677 -- TLS Web server authentication 1678 -- Key usage bits that may be consistent: digitalSignature, 1679 -- keyEncipherment or keyAgreement 1680 -- 1681 id-kp-clientAuth OBJECT IDENTIFIER ::= {id-kp 2} 1682 -- TLS Web client authentication 1683 -- Key usage bits that may be consistent: digitalSignature and/or 1684 -- keyAgreement 1685 -- 1686 id-kp-codeSigning OBJECT IDENTIFIER ::= {id-kp 3} 1687 -- Signing of downloadable executable code 1688 -- Key usage bits that may be consistent: digitalSignature 1689 -- 1690 id-kp-emailProtection OBJECT IDENTIFIER ::= {id-kp 4} 1691 -- E-mail protection 1692 -- Key usage bits that may be consistent: digitalSignature, 1693 -- nonRepudiation, and/or (keyEncipherment 1694 -- or keyAgreement) 1695 -- 1696 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 1697 -- Binding the hash of an object to a time from an agreed-upon time 1698 -- source. Key usage bits that may be consistent: digitalSignature, 1699 -- nonRepudiation 1701 4.2.1.14 CRL Distribution Points 1703 The CRL distribution points extension identifies how CRL information 1704 is obtained. The extension should be non-critical, but this profile 1705 recommends support for this extension by CAs and applications. 1706 Further discussion of CRL management is contained in section 5. 1708 If the cRLDistributionPoints extension contains a Distribution- 1709 PointName of type URI, the following semantics shall be assumed: the 1710 URI is a pointer to the current CRL for the associated reasons and 1711 will be issued by the associated cRLIssuer. The expected values for 1712 the URI are those defined in 4.2.1.7. Processing rules for other 1713 values are not defined by this specification. If the distribution- 1714 Point omits reasons, the CRL shall include revocations for all rea- 1715 sons. If the distributionPoint omits cRLIssuer, the CRL shall be 1716 issued by the CA that issued the certificate. 1718 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 } 1720 cRLDistributionPoints ::= { 1721 CRLDistPointsSyntax } 1723 CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 1725 DistributionPoint ::= SEQUENCE { 1726 distributionPoint [0] DistributionPointName OPTIONAL, 1727 reasons [1] ReasonFlags OPTIONAL, 1728 cRLIssuer [2] GeneralNames OPTIONAL } 1730 DistributionPointName ::= CHOICE { 1731 fullName [0] GeneralNames, 1732 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 1734 ReasonFlags ::= BIT STRING { 1735 unused (0), 1736 keyCompromise (1), 1737 cACompromise (2), 1738 affiliationChanged (3), 1739 superseded (4), 1740 cessationOfOperation (5), 1741 certificateHold (6) } 1743 4.2.2 Private Internet Extensions 1745 This section defines one new extension for use in the Internet Public 1746 Key Infrastructure. This extension may be used to direct 1747 applications to identify an on-line validation service supporting the 1748 issuing CA. As the information may be available in multiple forms, 1749 each extension is a sequence of IA5String values, each of which 1750 represents a URI. The URI implicitly specifies the location and for- 1751 mat of the information and the method for obtaining the information. 1753 An object identifier is defined for the private extension. The 1754 object identifier associated with the private extension is defined 1755 under the arc id-pe within the id-pkix name space. Any future exten- 1756 sions defined for the Internet PKI will also be defined uder the arc 1757 id-pe. 1759 id-pkix OBJECT IDENTIFIER ::= 1760 { iso(1) identified-organization(3) dod(6) internet(1) 1761 security(5) mechanisms(5) pkix(7) } 1763 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 1765 4.2.2.1 Authority Information Access 1767 The authority information access extension indicates how to access CA 1768 information and services for the issuer of the certificate in which 1769 the extension appears. Information and services may include on-line 1770 validation services and CA policy data. (The location of CRLs is not 1771 specified in this extension; that information is provided by the 1772 cRLDistributionPoints extension.) This extension may be included in 1773 subject or CA certificates, and it is always non-critical. 1775 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 1777 AuthorityInfoAccessSyntax ::= 1778 SEQUENCE SIZE (1..MAX) OF AccessDescription 1780 AccessDescription ::= SEQUENCE { 1781 accessMethod OBJECT IDENTIFIER, 1782 accessLocation GeneralName } 1784 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 1786 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 1788 Each entry in the sequence AuthorityInfoAccessSyntax describes the 1789 format and location of additional information about the CA who issued 1790 the certificate in which this extension appears. The type and format 1791 of the information is specified by the accessMethod field; the 1792 accessLocation field specifies the location of the information. The 1793 retrieval mechanism may be implied by the accessMethod or specified 1794 by accessLocation. 1796 This profile defines one OID for accessMethod. The id-ad-caIssuers 1797 OID is used when the additional information lists CAs that have 1798 issued certificates superior to the CA that issued the certificate 1799 containing this extension. The referenced CA Issuers description is 1800 intended to aid certificate users in the selection of a certification 1801 path that terminates at a point trusted by the certificate user. 1803 When id-ad-caIssuers appears as accessInfoType, the accessLocation 1804 field describes the referenced description server and the access pro- 1805 tocol to obtain the referenced description. The accessLocation field 1806 is defined as a GeneralName, which can take several forms. Where the 1807 information is available via http, ftp, or ldap, accessLocation shall 1808 be a uniformResourceIdentifier. Where the information is available 1809 via the directory access protocol (dap), accessLocation shall be a 1810 directoryName. When the information is available via electronic mail, 1811 accessLocation shall be an rfc822Name. The semantics of other name 1812 forms of accessLocation (when accessMethod is id-ad-caIssuers) are 1813 not defined by this specification. 1815 Additional access descriptors may be defined in other PKIX specifica- 1816 tions. 1818 5 CRL and CRL Extensions Profile 1820 As described above, one goal of this X.509 v2 CRL profile is to 1821 foster the creation of an interoperable and reusable Internet PKI. 1822 To achieve this goal, guidelines for the use of extensions are speci- 1823 fied, and some assumptions are made about the nature of information 1824 included in the CRL. 1826 CRLs may be used in a wide range of applications and environments 1827 covering a broad spectrum of interoperability goals and an even 1828 broader spectrum of operational and assurance requirements. This 1829 profile establishes a common baseline for generic applications 1830 requiring broad interoperability. The profile defines a baseline set 1831 of information that can be expected in every CRL. Also, the profile 1832 defines common locations within the CRL for frequently used attri- 1833 butes as well as common representations for these attributes. 1835 This profile does not define any private Internet CRL extensions or 1836 CRL entry extensions. 1838 Environments with additional or special purpose requirements may 1839 build on this profile or may replace it. 1841 Conforming CAs are not required to issue CRLs if other revocation or 1842 certificate status mechanisms are provided. Conforming CAs that 1843 issue CRLs are required to issue version 2 CRLs, and CAs must include 1844 the date by which the next CRL will be issued in the nextUpdate field 1845 (see sec. 5.1.2.5). Conforming applications are required to process 1846 version 1 and 2 CRLs. 1848 5.1 CRL Fields 1850 The X.509 v2 CRL syntax is as follows. For signature calculation, 1851 the data that is to be signed is ASN.1 DER encoded. ASN.1 DER encod- 1852 ing is a tag, length, value encoding system for each element. 1854 CertificateList ::= SEQUENCE { 1855 tbsCertList TBSCertList, 1856 signatureAlgorithm AlgorithmIdentifier, 1857 signatureValue BIT STRING } 1859 TBSCertList ::= SEQUENCE { 1860 version Version OPTIONAL, 1861 -- if present, must be v2 1862 signature AlgorithmIdentifier, 1863 issuer Name, 1864 thisUpdate Time, 1865 nextUpdate Time OPTIONAL, 1866 revokedCertificates SEQUENCE OF SEQUENCE { 1867 userCertificate CertificateSerialNumber, 1868 revocationDate Time, 1869 crlEntryExtensions Extensions OPTIONAL 1870 -- if present, must be v2 1871 } OPTIONAL, 1872 crlExtensions [0] EXPLICIT Extensions OPTIONAL 1873 -- if present, must be v2 1874 } 1876 -- Version, Time, CertificateSerialNumber, and Extensions 1877 -- are all defined in the ASN.1 in section 4.1 1879 -- AlgorithmIdentifier is defined in section 4.1.1.2 1881 The following items describe the use of the X.509 v2 CRL in the 1882 Internet PKI. 1884 5.1.1 CertificateList Fields 1886 The CertificateList is a SEQUENCE of three required fields. The 1887 fields are described in detail in the following subsections. 1889 5.1.1.1 tbsCertList 1891 The first field in the sequence is the tbsCertList. This field is 1892 itself a sequence containing the name of the issuer, issue date, 1893 issue date of the next list, the list of revoked certificates, and 1894 optional CRL extensions. Further, each entry on the revoked certifi- 1895 cate list is defined by a sequence of user certificate serial number, 1896 revocation date, and optional CRL entry extensions. 1898 5.1.1.2 signatureAlgorithm 1900 The signatureAlgorithm field contains the algorithm identifier for 1901 the algorithm used by the CA to sign the CertificateList. The field 1902 is of type AlgorithmIdentifier, which is defined in section 4.1.1.2. 1903 Section 7.2 lists the supported algorithms for this specification. 1904 Conforming CAs shall use the algorithm identifiers presented in sec- 1905 tion 7.2 when signing with a supported signature algorithm. 1907 This field must contain the same algorithm identifier as the signa- 1908 ture field in the sequence tbsCertList (see sec. 5.1.2.2). 1910 5.1.1.3 signatureValue 1912 The signatureValue field contains a digital signature computed upon 1913 the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded tbsCertList 1914 is used as the input to the signature function. This signature value 1915 is then ASN.1 encoded as a BIT STRING and included in the CRL's sig- 1916 natureValue field. The details of this process are specified for each 1917 of the supported algorithms in section 7.2. 1919 5.1.2 Certificate List "To Be Signed" 1921 The certificate list to be signed, or TBSCertList, is a SEQUENCE of 1922 required and optional fields. The required fields identify the CRL 1923 issuer, the algorithm used to sign the CRL, the date and time the CRL 1924 was issued, and the date and time by which the CA will issue the next 1925 CRL. 1927 Optional fields include lists of revoked certificates and CRL exten- 1928 sions. The revoked certificate list is optional to support the case 1929 where a CA has not revoked any unexpired certificates that it has 1930 issued. The profile requires conforming CAs to use the CRL extension 1931 cRLNumber in all CRLs issued. 1933 5.1.2.1 Version 1935 This optional field describes the version of the encoded CRL. When 1936 extensions are used, as required by this profile, this field shall be 1937 present and shall specify version 2 (the integer value is 1). 1939 5.1.2.2 Signature 1941 This field contains the algorithm identifier for the algorithm used 1942 to sign the CRL. Section 7.2 lists OIDs for the most popular signa- 1943 ture algorithms used in the Internet PKI. 1945 This field must contain the same algorithm identifier as the signa- 1946 tureAlgorithm field in the sequence CertificateList (see section 1947 5.1.1.2). 1949 5.1.2.3 Issuer Name 1951 The issuer name identifies the entity who has signed and issued the 1952 CRL. The issuer identity is carried in the issuer name field. Alter- 1953 native name forms may also appear in the issuerAltName extension (see 1954 sec. 5.2.2). The issuer name field shall contain an X.500 dis- 1955 tinguished name (DN). The issuer name field is defined as the X.501 1956 type Name, and shall follow the encoding rules for the issuer name 1957 field in the certificate (see sec. 4.1.2.4). 1959 5.1.2.4 This Update 1961 This field indicates the issue date of this CRL. ThisUpdate may be 1962 encoded as UTCTime or GeneralizedTime. 1964 CAs conforming to this profile that issue CRLs shall encode thisUp- 1965 date as UTCTime for dates through the year 2049. CAs conforming to 1966 this profile that issue CRLs shall encode thisUpdate as Generalized- 1967 Time for dates in the year 2050 or later. 1969 Where encoded as UTCTime, thisUpdate shall be specified and inter- 1970 preted as defined in section 4.1.2.5.1. Where encoded as General- 1971 izedTime, thisUpdate shall be specified and interpreted as defined in 1972 section 4.1.2.5.2. 1974 5.1.2.5 Next Update 1976 This field indicates the date by which the next CRL will be issued. 1977 The next CRL could be issued before the indicated date, but it will 1978 not be issued any later than the indicated date. nextUpdate may be 1979 encoded as UTCTime or GeneralizedTime. 1981 This profile requires inclusion of nextUpdate in all CRLs issued by 1982 conforming CAs. Note that the ASN.1 syntax of TBSCertList describes 1983 this field as OPTIONAL, which is consistent with the ASN.1 structure 1984 defined in [X.509]. The behavior of clients processing CRLs which 1985 omit nextUpdate is not specified by this profile. 1987 CAs conforming to this profile that issue CRLs shall encode nextUp- 1988 date as UTCTime for dates through the year 2049. CAs conforming to 1989 this profile that issue CRLs shall encode nextUpdate as Generalized- 1990 Time for dates in the year 2050 or later. 1992 Where encoded as UTCTime, nextUpdate shall be specified and inter- 1993 preted as defined in section 4.1.2.5.1. Where encoded as General- 1994 izedTime, nextUpdate shall be specified and interpreted as defined in 1995 section 4.1.2.5.2. 1997 5.1.2.6 Revoked Certificates 1999 Revoked certificates are listed. The revoked certificates are named 2000 by their serial numbers. Certificates are uniquely identified by the 2001 combination of the issuer name or issuer alternative name along with 2002 the user certificate serial number. The date on which the revocation 2003 occurred is specified. The time for revocationDate shall be 2004 expressed as described in section 5.1.2.4. Additional information may 2005 be supplied in CRL entry extensions; CRL entry extensions are dis- 2006 cussed in section 5.3. 2008 5.1.2.7 Extensions 2010 This field may only appear if the version is 2 (see sec. 5.1.2.1). 2011 If present, this field is a SEQUENCE of one or more CRL extensions. 2012 CRL extensions are discussed in section 5.2. 2014 5.2 CRL Extensions 2016 The extensions defined by ANSI X9 and ISO/IEC/ITU for X.509 v2 CRLs 2017 [X.509] [X9.55] provide methods for associating additional attributes 2018 with CRLs. The X.509 v2 CRL format also allows communities to define 2019 private extensions to carry information unique to those communities. 2020 Each extension in a CRL may be designated as critical or non- 2021 critical. A CRL validation must fail if it encounters a critical 2022 extension which it does not know how to process. However, an 2023 unrecognized non-critical extension may be ignored. The following 2024 subsections present those extensions used within Internet CRLs. Com- 2025 munities may elect to include extensions in CRLs which are not 2026 defined in this specification. However, caution should be exercised 2027 in adopting any critical extensions in CRLs which might be used in a 2028 general context. 2030 Conforming CAs that issue CRLs are required to include the authority 2031 key identifier (see sec. 5.2.1) and the CRL number (see sec. 5.2.3) 2032 extensions in all CRLs issued. 2034 5.2.1 Authority Key Identifier 2036 The authority key identifier extension provides a means of identify- 2037 ing the public key corresponding to the private key used to sign a 2038 CRL. The identification can be based on either the key identifier 2039 (the subject key identifier in the CRL signer's certificate) or on 2040 the issuer name and serial number. This extension is especially use- 2041 ful where an issuer has more than one signing key, either due to mul- 2042 tiple concurrent key pairs or due to changeover. 2044 Conforming CAs shall use the key identifier method, and shall include 2045 this extension in all CRLs issued. 2047 The syntax for this CRL extension is defined in section 4.2.1.1. 2049 5.2.2 Issuer Alternative Name 2051 The issuer alternative names extension allows additional identities 2052 to be associated with the issuer of the CRL. Defined options include 2053 an rfc822 name (electronic mail address), a DNS name, an IP address, 2054 and a URI. Multiple instances of a name and multiple name forms may 2055 be included. Whenever such identities are used, the issuer alterna- 2056 tive name extension shall be used. 2058 The issuerAltName extension should not be marked critical. 2060 The OID and syntax for this CRL extension are defined in section 2061 4.2.1.8. 2063 5.2.3 CRL Number 2065 The CRL number is a non-critical CRL extension which conveys a mono- 2066 tonically increasing sequence number for each CRL issued by a CA. 2067 This extension allows users to easily determine when a particular CRL 2068 supersedes another CRL. CAs conforming to this profile shall include 2069 this extension in all CRLs. 2071 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 2073 cRLNumber ::= INTEGER (0..MAX) 2075 5.2.4 Delta CRL Indicator 2077 The delta CRL indicator is a critical CRL extension that identifies a 2078 delta-CRL. The use of delta-CRLs can significantly improve process- 2079 ing time for applications which store revocation information in a 2080 format other than the CRL structure. This allows changes to be added 2081 to the local database while ignoring unchanged information that is 2082 already in the local database. 2084 When a delta-CRL is issued, the CAs shall also issue a complete CRL. 2086 The value of BaseCRLNumber identifies the CRL number of the base CRL 2087 that was used as the starting point in the generation of this delta- 2088 CRL. The delta-CRL contains the changes between the base CRL and the 2089 current CRL issued along with the delta-CRL. It is the decision of a 2090 CA as to whether to provide delta-CRLs. Again, a delta-CRL shall not 2091 be issued without a corresponding complete CRL. The value of 2092 CRLNumber for both the delta-CRL and the corresponding complete CRL 2093 shall be identical. 2095 A CRL user constructing a locally held CRL from delta-CRLs shall con- 2096 sider the constructed CRL incomplete and unusable if the CRLNumber of 2097 the received delta-CRL is more that one greater that the CRLnumber of 2098 the delta-CRL last processed. 2100 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 2102 deltaCRLIndicator ::= BaseCRLNumber 2104 BaseCRLNumber ::= CRLNumber 2106 5.2.5 Issuing Distribution Point 2108 The issuing distribution point is a critical CRL extension that iden- 2109 tifies the CRL distribution point for a particular CRL, and it indi- 2110 cates whether the CRL covers revocation for end entity certificates 2111 only, CA certificates only, or a limitied set of reason codes. 2112 Although the extension is critical, conforming implementations are 2113 not required to support this extension. 2115 The CRL is signed using the CA's private key. CRL Distribution 2116 Points do not have their own key pairs. If the CRL is stored in the 2117 X.500 Directory, it is stored in the Directory entry corresponding to 2118 the CRL distribution point, which may be different than the Directory 2119 entry of the CA. 2121 CAs may use CRL distribution points to partition the CRL on the basis 2122 of compromise and routine revocation. In this case, the revocations 2123 with reason code keyCompromise (1) shall appear in one distribution 2124 point, and the revocations with other reason codes shall appear in 2125 another distribution point. The reason codes associated with a dis- 2126 tribution point must be specified in onlySomeReasons. If onlySomeRea- 2127 sons does not appear, the distribution point must contain revocations 2128 for all reason codes. 2130 Where the issuingDistributionPoint extension contains a URL, the fol- 2131 lowing semantics shall be assumed: the object is a pointer to the 2132 most current CRL issued by this CA. The URI schemes ftp, http, 2133 mailto [RFC1738] and ldap [RFC1778] are defined for this purpose. 2134 The URI must be an absolute, not relative, pathname and must specify 2135 the host. 2137 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 2139 issuingDistributionPoint ::= SEQUENCE { 2140 distributionPoint [0] DistributionPointName OPTIONAL, 2141 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 2142 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 2143 onlySomeReasons [3] ReasonFlags OPTIONAL, 2144 indirectCRL [4] BOOLEAN DEFAULT FALSE } 2146 5.3 CRL Entry Extensions 2148 The CRL entry extensions already defined by ANSI X9 and ISO/IEC/ITU 2149 for X.509 v2 CRLs provide methods for associating additional attri- 2150 butes with CRL entries [X.509] [X9.55]. The X.509 v2 CRL format also 2151 allows communities to define private CRL entry extensions to carry 2152 information unique to those communities. Each extension in a CRL 2153 entry may be designated as critical or non-critical. A CRL valida- 2154 tion must fail if it encounters a critical CRL entry extension which 2155 it does not know how to process. However, an unrecognized non- 2156 critical CRL entry extension may be ignored. The following subsec- 2157 tions present recommended extensions used within Internet CRL entries 2158 and standard locations for information. Communities may elect to use 2159 additional CRL entry extensions; however, caution should be exercised 2160 in adopting any critical extensions in CRL entries which might be 2161 used in a general context. 2163 All CRL entry extensions used in this specification are non-critical. 2164 Support for these extensions is optional for conforming CAs and 2165 applications. However, CAs that issue CRLs are strongly encouraged 2166 to include reason codes (see sec. 5.3.1) and invalidity dates (see 2167 sec. 5.3.3) whenever this information is available. 2169 5.3.1 Reason Code 2171 The reasonCode is a non-critical CRL entry extension that identifies 2172 the reason for the certificate revocation. CAs are strongly 2173 encouraged to include meaningful reason codes in CRL entries; how- 2174 ever, the reason code CRL entry extension should be absent instead of 2175 using the unspecified (0) reasonCode value. 2177 id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 } 2178 -- reasonCode ::= { CRLReason } 2180 CRLReason ::= ENUMERATED { 2181 unspecified (0), 2182 keyCompromise (1), 2183 cACompromise (2), 2184 affiliationChanged (3), 2185 superseded (4), 2186 cessationOfOperation (5), 2187 certificateHold (6), 2188 removeFromCRL (8) } 2190 5.3.2 Hold Instruction Code 2192 The hold instruction code is a non-critical CRL entry extension that 2193 provides a registered instruction identifier which indicates the 2194 action to be taken after encountering a certificate that has been 2195 placed on hold. 2197 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 2199 holdInstructionCode ::= OBJECT IDENTIFIER 2201 The following instruction codes have been defined. Conforming appli- 2202 cations that process this extension shall recognize the following 2203 instruction codes. 2205 holdInstruction OBJECT IDENTIFIER ::= 2206 { iso(1) member-body(2) us(840) x9-57(10040) 2 } 2208 id-holdinstruction-none OBJECT IDENTIFIER ::= {holdInstruction 1} 2209 id-holdinstruction-callissuer 2210 OBJECT IDENTIFIER ::= {holdInstruction 2} 2211 id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3} 2213 Conforming applications which encounter an id-holdinstruction- 2214 callissuer must call the certificate issuer or reject the certifi- 2215 cate. Conforming applications which encounter an id- 2216 holdinstruction-reject shall reject the certificate. The hold 2217 instruction id-holdinstruction-none is semantically equivalent to the 2218 absence of a holdInstructionCode, and its use is strongly deprecated 2219 for the Internet PKI. 2221 5.3.3 Invalidity Date 2223 The invalidity date is a non-critical CRL entry extension that pro- 2224 vides the date on which it is known or suspected that the private key 2225 was compromised or that the certificate otherwise became invalid. 2227 This date may be earlier than the revocation date in the CRL entry, 2228 which is the date at which the CA processed the revocation. When a 2229 revocation is first posted by a CA in a CRL, the invalidity date may 2230 precede the date of issue of earlier CRLs, but the revocation date 2231 should not precede the date of issue of earlier CRLs. Whenever this 2232 information is available, CAs are strongly encouraged to share it 2233 with CRL users. 2235 The GeneralizedTime values included in this field shall be expressed 2236 in Greenwich Mean Time (Zulu), and shall be specified and interpreted 2237 as defined in section 4.1.2.5.2. 2239 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 2241 invalidityDate ::= GeneralizedTime 2243 5.3.4 Certificate Issuer 2245 This CRL entry extension identifies the certificate issuer associated 2246 with an entry in an indirect CRL, i.e. a CRL that has the indirectCRL 2247 indicator set in its issuing distribution point extension. If this 2248 extension is not present on the first entry in an indirect CRL, the 2249 certificate issuer defaults to the CRL issuer. On subsequent entries 2250 in an indirect CRL, if this extension is not present, the certificate 2251 issuer for the entry is the same as that for the preceding entry. 2252 This field is defined as follows: 2254 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } 2256 certificateIssuer ::= GeneralNames 2258 If used by conforming CAs that issue CRLs, this extension is always 2259 critical. If an implementation ignored this extension it could not 2260 correctly attribute CRL entries to certificates. This specification 2261 recommends that implementations recognize this extension. 2263 6 Certification Path Validation 2265 Certification path validation procedures for the Internet PKI are 2266 based on section 12.4.3 of [X.509]. Certification path processing 2267 verifies the binding between the subject distinguished name and/or 2268 subject alternative name and subject public key. The binding is lim- 2269 ited by constraints which are specified in the certificates which 2270 comprise the path. The basic constraints and policy constraints 2271 extensions allow the certification path processing logic to automate 2272 the decision making process. 2274 This section describes an algorithm for validating certification 2275 paths. Conforming implementations of this specification are not 2276 required to implement this algorithm, but shall be functionally 2277 equivalent to the external behaviour resulting from this procedure. 2278 Any algorithm may be used by a particular implementation so long as 2279 it derives the correct result. 2281 In section 6.1, the text describes basic path validation. This text 2282 assumes that all valid paths begin with certificates issued by a sin- 2283 gle "most-trusted CA". The algorithm requires the public key of the 2284 CA, the CA's name, the validity period of the public key, and any 2285 constraints upon the set of paths which may be validated using this 2286 key. 2288 The "most-trusted CA" is a matter of policy: it could be a root CA in 2289 a hierarchical PKI; the CA that issued the verifier's own 2290 certificate(s); or any other CA in a network PKI. The path valida- 2291 tion procedure is the same regardless of the choice of "most-trusted 2292 CA." 2294 section 6.2 describes extensions to the basic path validation algo- 2295 rithm. Two specific cases are discussed: the case where paths may 2296 begin with one of several trusted CAs; and where compatibility with 2297 the PEM architecture is required. 2299 6.1 Basic Path Validation 2301 The text assumes that the trusted public key (and related informa- 2302 tion) is contained in a "self-signed" certificate. This simplifies 2303 the description of the path processing procedure. Note that the sig- 2304 nature on the self-signed certificate does not provide any security 2305 services. The public key it contains is trusted because of other 2306 procedures used to obtain and protect it. 2308 The goal of path validation is to verify the binding between a sub- 2309 ject distinguished name or subject alternative name and subject pub- 2310 lic key, as represented in the "end entity" certificate, based on the 2311 public key of the "most-trusted CA". This requires obtaining a 2312 sequence of certificates that support that binding. The procedures 2313 performed to obtain this sequence is outside the scope of this sec- 2314 tion. 2316 The following text also assumes that certificates do not use subject 2317 or unique identifier fields or private critical extensions, as recom- 2318 mended within this profile. However, if these components appear in 2319 certificates, they must be processed. Finally, policy qualifiers are 2320 also neglected for the sake of clarity. 2322 A certification path is a sequence of n certificates where: 2324 * for all x in {1,(n-1)}, the subject of certificate x is the 2325 issuer of certificate x+1. 2326 * certificate x=1 is the the self-signed certificate, and 2327 * certificate x=n is the end entity certificate. 2329 This section assumes the following inputs are provided to the path 2330 processing logic: 2332 (a) a certification path of length n; 2334 (b) a set of initial policy identifiers (each comprising a 2335 sequence of policy element identifiers), which identifies one or 2336 more certificate policies, any one of which would be acceptable 2337 for the purposes of certification path processing, or the special 2338 value "any-policy"; 2340 (c) the current date/time (if not available internally to the 2341 certification path processing module); and 2343 (d) the time, T, for which the validity of the path should be 2344 determined. (This may be the current date/time, or some point in 2345 the past.) 2347 From the inputs, the procedure intializes five state variables: 2349 (a) acceptable policy set: A set of certificate policy identif- 2350 iers comprising the policy or policies recognized by the public 2351 key user together with policies deemed equivalent through policy 2352 mapping. The initial value of the acceptable policy set is the 2353 special value "any-policy". 2355 (b) constrained subtrees: A set of root names defining a set of 2356 subtrees within which all subject names in subsequent certificates 2357 in the certification path shall fall. The initial value is 2358 "unbounded". 2360 (c) excluded subtrees: A set of root names defining a set of 2361 subtrees within which no subject name in subsequent certificates 2362 in the certification path may fall. The initial value is "empty". 2364 (d) explicit policy: an integer which indicates if an explicit 2365 policy identifier is required. The integer indicates the first 2366 certificate in the path where this requirement is imposed. Once 2367 set, this variable may be decreased, but may not be increased. 2368 (That is, if a certificate in the path requires explicit policy 2369 identifiers, a later certificate can not remove this requirement.) 2370 The initial value is n+1. 2372 (e) policy mapping: an integer which indicates if policy mapping 2373 is permitted. The integer indicates the last certificate on which 2374 policy mapping may be applied. Once set, this variable may be 2375 decreased, but may not be increased. (That is, if a certificate in 2376 the path specifies policy mapping is not permitted, it can not be 2377 overriden by a later certificate.) The initial value is n+1. 2379 The actions performed by the path processing software for each certi- 2380 ficate i=1 through n are described below. The self-signed certifi- 2381 cate is certificate i=1, the end entity certificate is i=n. The pro- 2382 cessing is performed sequentially, so that processing certificate i 2383 affects the state variables for processing certificate (i+1). Note 2384 that actions (h) through (m) are not applied to the end entity certi- 2385 ficate (certificate n). 2387 The path processing actions to be performed are: 2389 (a) Verify the basic certificate information, including: 2391 (1) the certificate was signed using the subject public key 2392 from certificate i-1 (in the special case i=1, this step may be 2393 omitted; if not, use the subject public key from the same cer- 2394 tificate), 2396 (2) the certificate validity period includes time T, 2398 (3) the certificate had not been revoked at time T and is not 2399 currently on hold status that commenced before time T, (this 2400 may be determined by obtaining the appropriate CRL or status 2401 information, or by out-of-band mechanisms), and 2403 (4) the subject and issuer names chain correctly (that is, the 2404 issuer of this certificate was the subject of the previous cer- 2405 tificate.) If the certificate has an empty sequence in the 2406 name field, name chaining will use the critical subjectAltNames 2407 and issuerAltNames fields. 2409 (b) Verify that the subject name and subjectAltName extension 2410 (critical or noncritical) is consistent with the constrained sub- 2411 trees state variables. 2413 (c) Verify that the subject name and subjectAltName extension 2414 (critical or noncritical) is consistent with the excluded subtrees 2415 state variables. 2417 (d) Verify that policy information is consistent with the initial 2418 policy set: 2420 (1) if the explicit policy state variable is less than or equal 2421 to i, a policy identifier in the certificate must be in the 2422 initial policy set; and 2424 (2) if the policy mapping variable is less than or equal to i, 2425 the policy identifier may not be mapped. 2427 (e) Verify that policy information is consistent with the accept- 2428 able policy set: 2430 (1) if the certificate policies extension is marked critical, 2431 the intersection of the policies extension and the acceptable 2432 policy set must be non-null; 2434 (2) the acceptable policy set is assigned the resulting inter- 2435 section as its new value. 2437 (g) Verify that the intersection of the acceptable policy set and 2438 the initial policy set is non-null. 2440 (h) Recognize and process any other critical extension present in 2441 the certificate. 2443 (i) Verify that the certificate is a CA certificate (as specified 2444 in a basicConstraints extension or as verified out-of-band). 2446 (j) If permittedSubtrees is present in the certificate, set the 2447 constrained subtrees state variable to the intersection of its 2448 previous value and the value indicated in the extension field. 2450 (k) If excludedSubtrees is present in the certificate, set the 2451 excluded subtrees state variable to the union of its previous 2452 value and the value indicated in the extension field. 2454 (l) If a policy constraints extension is included in the certifi- 2455 cate, modify the explicit policy and policy mapping state vari- 2456 ables as follows: 2458 (1) If requireExplicitPolicy is present and has value r, the 2459 explicit policy state variable is set to the minimum of its 2460 current value and the sum of r and i (the current certificate 2461 in the sequence). 2463 (2) If inhibitPolicyMapping is present and has value q, the 2464 policy mapping state variable is set to the minimum of its 2465 current value and the sum of q and i (the current certificate 2466 in the sequence). 2468 (m) If a key usage extension is marked critical, ensure the key- 2469 CertSign bit is set. 2471 If any one of the above checks fail, the procedure terminates, 2472 returning a failure indication and an appropriate reason. If none of 2473 the above checks fail on the end-entity certificate, the procedure 2474 terminates, returning a success indication together with the set of 2475 all policy qualifier values encountered in the set of certificates. 2477 6.2 Extending Path Validation 2479 The path validation algorithm presented in 6.1 is based on several 2480 simplifying assumptions (e.g., a single trusted CA that starts all 2481 valid paths). This algorithm may be extended for cases where the 2482 assumptions do not hold. 2484 This procedure may be extended for multiple trusted CAs by providing 2485 a set of self-signed certificates to the validation module. In this 2486 case, a valid path could begin with any one of the self-signed certi- 2487 ficates. Limitations in the trust paths for any particular key may 2488 be incorporated into the self-signed certificate's extensions. In 2489 this way, the self-signed certificates permit the path validation 2490 module to automatically incorporate local security policy and 2491 requirements. 2493 It is also possible to specify an extended version of the above cer- 2494 tification path processing procedure which results in default 2495 behaviour identical to the rules of PEM [RFC 1422]. In this extended 2496 version, additional inputs to the procedure are a list of one or more 2497 Policy Certification Authorities (PCAs) names and an indicator of the 2498 position in the certification path where the PCA is expected. At the 2499 nominated PCA position, the CA name is compared against this list. 2500 If a recognized PCA name is found, then a constraint of Subordina- 2501 teToCA is implicitly assumed for the remainder of the certification 2502 path and processing continues. If no valid PCA name is found, and if 2503 the certification path cannot be validated on the basis of identified 2504 policies, then the certification path is considered invalid. 2506 7 Algorithm Support 2508 This section describes cryptographic algorithms which may be used 2509 with this profile. The section describes one-way hash functions and 2510 digital signature algorithms which may be used to sign certificates 2511 and CRLs, and identifies OIDs for public keys contained in a certifi- 2512 cate. 2514 Conforming CAs and applications are not required to support the algo- 2515 rithms or algorithm identifiers described in this section. However, 2516 conforming CAs and applications that use the algorithms identified 2517 here shall support them as specified. 2519 7.1 One-way Hash Functions 2521 This section identifies one-way hash functions for use in the Inter- 2522 net PKI. One-way hash functions are also called message digest algo- 2523 rithms. SHA-1 is the preferred one-way hash function for the Internet 2524 PKI. However, PEM uses MD2 for certificates [RFC 1422] [RFC 1423] 2525 and MD5 is used in other legacy applications. For this reason, MD2 2526 and MD5 are included in this profile. 2528 7.1.1 MD2 One-way Hash Function 2530 MD2 was developed by Ron Rivest for RSA Data Security. RSA Data Secu- 2531 rity has not placed the MD2 algorithm in the public domain. Rather, 2532 RSA Data Security has granted license to use MD2 for non-commercial 2533 Internet Privacy-Enhanced Mail. For this reason, MD2 may continue to 2534 be used with PEM certificates, but SHA-1 is preferred. MD2 produces 2535 a 128-bit "hash" of the input. MD2 is fully described in RFC 1319 2536 [RFC 1319]. 2538 At the Selected Areas in Cryptography '95 conference in May 1995, 2539 Rogier and Chauvaud presented an attack on MD2 that can nearly find 2540 collisions [RC95]. Collisions occur when one can find two different 2541 messages that generate the same message digest. A checksum operation 2542 in MD2 is the only remaining obstacle to the success of the attack. 2543 For this reason, the use of MD2 for new applications is discouraged. 2544 It is still reasonable to use MD2 to verify existing signatures, as 2545 the ability to find collisions in MD2 does not enable an attacker to 2546 find new messages having a previously computed hash value. 2548 7.1.2 MD5 One-way Hash Function 2550 MD5 was developed by Ron Rivest for RSA Data Security. RSA Data Secu- 2551 rity has placed the MD5 algorithm in the public domain. MD5 produces 2552 a 128-bit "hash" of the input. MD5 is fully described in RFC 1321 2553 [RFC 1321]. 2555 Den Boer and Bosselaers [DB94] have found pseudo-collisions for MD5, 2556 but there are no other known cryptanalytic results. The use of MD5 2557 for new applications is discouraged. It is still reasonable to use 2558 MD5 to verify existing signatures. 2560 7.1.3 SHA-1 One-way Hash Function 2562 SHA-1 was developed by the U.S. Government. SHA-1 produces a 160-bit 2563 "hash" of the input. SHA-1 is fully described in FIPS 180-1 [FIPS 2564 180-1]. 2566 SHA-1 is the one-way hash function of choice for use with both the 2567 RSA and DSA signature algorithms (see sec. 7.2). 2569 7.2 Signature Algorithms 2571 Certificates and CRLs described by this standard may be signed with 2572 any public key signature algorithm. The certificate or CRL indicates 2573 the algorithm through an algorithm identifier which appears in the 2574 signatureAlgorithm field in a Certificate or CertificateList. This 2575 algorithm identifier is an OID and has optionally associated parame- 2576 ters. This section identifies algorithm identifiers and parameters 2577 that shall be used in the signatureAlgorithm field in a Certificate 2578 or CertificateList. 2580 RSA and DSA are the most popular signature algorithms used in the 2581 Internet. Signature algorithms are always used in conjunction with a 2582 one-way hash function identified in section 7.1. 2584 The signature algorithm and one-way hash function used to sign a cer- 2585 tificate or CRL is indicated by use of an algorithm identifier. An 2586 algorithm identifier is an OID, and may include associated parame- 2587 ters. This section identifies OIDS for RSA and DSA. The contents of 2588 the parameters component for each algorithm vary; details are pro- 2589 vided for each algorithm. 2591 The data to be signed (e.g., the one-way hash function output value) 2592 is formatted for the signature algorithm to be used. Then, a private 2593 key operation (e.g., RSA encryption) is performed to generate the 2594 signature value. This signature value is then ASN.1 encoded as a BIT 2595 STRING and included in the Certificate or CertificateList in the sig- 2596 nature field. 2598 7.2.1 RSA Signature Algorithm 2600 A patent statement regarding the RSA algorithm can be found at the 2601 end of this profile. 2603 The RSA algorithm is named for its inventors: Rivest, Shamir, and 2604 Adleman. This profile includes three signature algorithms based on 2605 the RSA asymmetric encryption algorithm. The signature algorithms 2606 combine RSA with either the MD2, MD5, or the SHA-1 one-way hash func- 2607 tions. 2609 The signature algorithm with MD2 and the RSA encryption algorithm is 2610 defined in PKCS #1 [RFC 2313]. As defined in RFC 2313, the ASN.1 OID 2611 used to identify this signature algorithm is: 2613 md2WithRSAEncryption OBJECT IDENTIFIER ::= { 2614 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 2615 pkcs-1(1) 2 } 2617 The signature algorithm with MD5 and the RSA encryption algorithm is 2618 defined in PKCS #1 [RFC 2313]. As defined in RFC 2313, the ASN.1 OID 2619 used to identify this signature algorithm is: 2621 md5WithRSAEncryption OBJECT IDENTIFIER ::= { 2622 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 2623 pkcs-1(1) 4 } 2625 The signature algorithm with SHA-1 and the RSA encryption algorithm 2626 is implemented using the padding and encoding conventions described 2627 in PKCS #1 [RFC 2313]. The message digest is computed using the SHA-1 2628 hash algorithm. The ASN.1 object identifier used to identify this 2629 signature algorithm is: 2631 sha-1WithRSAEncryption OBJECT IDENTIFIER ::= { 2632 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 2633 pkcs-1(1) 5 } 2635 When any of these three OIDs appears within the ASN.1 type Algorith- 2636 mIdentifier, the parameters component of that type shall be the ASN.1 2637 type NULL. 2639 The RSA signature generation process and the encoding of the result 2640 is described in detail in RFC 2313. 2642 7.2.2 DSA Signature Algorithm 2644 A patent statement regarding the DSA can be found at the end of this 2645 profile. 2647 The Digital Signature Algorithm (DSA) is also called the Digital Sig- 2648 nature Standard (DSS). DSA was developed by the U.S. Government, and 2649 DSA is used in conjunction with the the SHA-1 one-way hash function. 2650 DSA is fully described in FIPS 186 [FIPS 186]. The ASN.1 OIDs used 2651 to identify this signature algorithm are: 2653 id-dsa-with-sha1 ID ::= { 2654 iso(1) member-body(2) us(840) x9-57 (10040) 2655 x9cm(4) 3 } 2657 Where the id-dsa-with-sha1 algorithm identifier appears as the algo- 2658 rithm field in an AlgorithmIdentifier, the encoding shall omit the 2659 parameters field. That is, the AlgorithmIdentifier shall be a 2660 SEQUENCE of one component - the OBJECT IDENTIFIER id-dsa-with-sha1. 2662 The DSA parameters in the subjectPublicKeyInfo field of the certifi- 2663 cate of the issuer shall apply to the verification of the signature. 2665 When signing, the DSA algorithm generates two values. These values 2666 are commonly referred to as r and s. To easily transfer these two 2667 values as one signature, they shall be ASN.1 encoded using the fol- 2668 lowing ASN.1 structure: 2670 Dss-Sig-Value ::= SEQUENCE { 2671 r INTEGER, 2672 s INTEGER } 2674 7.3 Subject Public Key Algorithms 2676 Certificates described by this profile may convey a public key for 2677 any public key algorithm. The certificate indicates the algorithm 2678 through an algorithm identifier. This algorithm identifier is an OID 2679 and optionally associated parameters. 2681 This section identifies preferred OIDs and parameters for the RSA, 2682 DSA, and Diffie-Hellman algorithms. Conforming CAs shall use the 2683 identified OIDs when issuing certificates containing public keys for 2684 these algorithms. Conforming applications supporting any of these 2685 algorithms shall, at a minimum, recognize the OID identified in this 2686 section. 2688 7.3.1 RSA Keys 2690 The OID rsaEncryption identifies RSA public keys. 2692 pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 2693 rsadsi(113549) pkcs(1) 1 } 2695 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1} 2697 The rsaEncryption OID is intended to be used in the algorithm field 2698 of a value of type AlgorithmIdentifier. The parameters field shall 2699 have ASN.1 type NULL for this algorithm identifier. 2701 The RSA public key shall be encoded using the ASN.1 type RSAPub- 2702 licKey: 2704 RSAPublicKey ::= SEQUENCE { 2705 modulus INTEGER, -- n 2706 publicExponent INTEGER -- e -- } 2708 where modulus is the modulus n, and publicExponent is the public 2709 exponent e. The DER encoded RSAPublicKey is the value of the BIT 2710 STRING subjectPublicKey. 2712 This OID is used in public key certificates for both RSA signature 2713 keys and RSA encryption keys. The intended application for the key 2714 may be indicated in the key usage field (see sec. 4.2.1.3). The use 2715 of a single key for both signature and encryption purposes is not 2716 recommended, but is not forbidden. 2718 If the keyUsage extension is present in an end entity certificate 2719 which conveys an RSA public key, any combination of the following 2720 values may be present: digitalSignature; nonRepudiation; keyEnci- 2721 pherment; and dataEncipherment. If the keyUsage extension is present 2722 in a CA certificate which conveys an RSA public key, any combination 2723 of the following values may be present: digitalSignature; nonRepudi- 2724 ation; keyEncipherment; dataEncipherment; keyCertSign; and cRLSign. 2725 However, this specification recommends that if keyCertSign or cRLSign 2726 is present, both keyEncipherment and dataEncipherment should not be 2727 present. 2729 7.3.2 Diffie-Hellman Key Exchange Key 2731 The Diffie-Hellman OID supported by this profile is defined by ANSI 2732 X9.42 [X9.42]. 2734 dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2735 us(840) ansi-x942(10046) number-type(2) 1 } 2737 The dhpublicnumber OID is intended to be used in the algorithm field 2738 of a value of type AlgorithmIdentifier. The parameters field of that 2739 type, which has the algorithm-specific syntax ANY DEFINED BY algo- 2740 rithm, have the ASN.1 type GroupParameters for this algorithm. 2742 DomainParameters ::= SEQUENCE { 2743 p INTEGER, -- odd prime, p=jq +1 2744 g INTEGER, -- generator, g 2745 q INTEGER, -- factor of p-1 2746 j INTEGER OPTIONAL, -- subgroup factor 2747 validationParms ValidationParms OPTIONAL } 2749 ValidationParms ::= SEQUENCE { 2750 seed BIT STRING, 2751 pgenCounter INTEGER } 2753 The fields of type DomainParameters have the following meanings: 2755 p identifies the prime p defining the Galois field; 2757 g specifies the generator of the mutiplicative subgroup of order 2758 g; 2760 q specifies the prime factor of p-1; 2762 j optionally specifies the value that satisfies the equation 2763 p=jq+1 to support the optional verification of group parameters; 2765 seed optionally specifies the bit string parameter used as the 2766 seed for the system parameter generation process; and 2768 pgenCounter optionally specifies the integer value output as part 2769 of the of the system parameter prime generation process. 2771 If either of the parameter generation components (pgencounter or 2772 seed) is provided, the other must be present as well. 2774 The Diffie-Hellman public key shall be ASN.1 encoded as an INTEGER; 2775 this encoding shall be used as the contents (i.e., the value) of the 2776 subjectPublicKey component (a BIT STRING) of the subjectPublicKeyInfo 2777 data element. 2779 DHPublicKey ::= INTEGER -- public key, y = g^x mod p 2781 If the keyUsage extension is present in a certificate which conveys a 2782 DH public key, the following values may be present: keyAgreement; 2783 encipherOnly; and decipherOnly. At most one of encipherOnly and 2784 decipherOnly shall be asserted in keyUsage extension. 2786 7.3.3 DSA Signature Keys 2788 The Digital Signature Algorithm (DSA) is also known as the Digitial 2789 Signature Standard (DSS). The DSA OID supported by this profile is 2791 id-dsa ID ::= { iso(1) member-body(2) us(840) x9-57(10040) 2792 x9cm(4) 1 } 2794 The id-dsa algorithm syntax includes optional parameters. These 2795 parameters are commonly referred to as p, q, and g. When omitted, 2796 the parameters component shall be omitted entirely. That is, the 2797 AlgorithmIdentifier shall be a SEQUENCE of one component - the OBJECT 2798 IDENTIFIER id-dsa. 2800 If the DSA algorithm parameters are present in the subjectPublicKey- 2801 Info AlgorithmIdentifier, the parameters are included using the fol- 2802 lowing ASN.1 structure: 2804 Dss-Parms ::= SEQUENCE { 2805 p INTEGER, 2806 q INTEGER, 2807 g INTEGER } 2809 If the DSA algorithm parameters are absent from the subjectPublicKey- 2810 Info AlgorithmIdentifier and the CA signed the subject certificate 2811 using DSA, then the certificate issuer's DSA parameters apply to the 2812 subject's DSA key. If the DSA algorithm parameters are absent from 2813 the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the 2814 subject certificate using a signature algorithm other than DSA, then 2815 the subject's DSA parameters are distributed by other means. If the 2816 subjectPublicKeyInfo AlgorithmIdentifier field omits the parameters 2817 component and the CA signed the subject with a signature algorithm 2818 other than DSA, then clients shall reject the certificate. 2820 When signing, DSA algorithm generates two values. These values are 2821 commonly referred to as r and s. To easily transfer these two values 2822 as one signature, they are ASN.1 encoded using the following ASN.1 2823 structure: 2825 Dss-Sig-Value ::= SEQUENCE { 2826 r INTEGER, 2827 s INTEGER } 2829 The encoded signature is conveyed as the value of the BIT STRING sig- 2830 nature in a Certificate or CertificateList. 2832 The DSA public key shall be ASN.1 DER encoded as an INTEGER; this 2833 encoding shall be used as the contents (i.e., the value) of the sub- 2834 jectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo 2835 data element. 2837 DSAPublicKey ::= INTEGER -- public key, Y 2839 If the keyUsage extension is present in an end entity certificate 2840 which conveys a DSA public key, any combination of the following 2841 values may be present: digitalSignature; and nonRepudiation. 2843 If the keyUsage extension is present in an CA certificate which con- 2844 veys a DSA public key, any combination of the following values may be 2845 present: digitalSignature; nonRepudiation; keyCertSign; and cRLSign. 2847 8 References 2849 [FIPS 180-1] Federal Information Processing Standards Publication 2850 (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995. 2851 [Supersedes FIPS PUB 180 dated 11 May 1993.] 2853 [FIPS 186] Federal Information Processing Standards Publication 2854 (FIPS PUB) 186, Digital Signature Standard, 18 May 1994. 2856 [PKCS #9] PKCS #9: Selected Attribute Types, Version 1.1, RSA Data 2857 Security, Inc., November 1, 1993. 2859 [RC95] Rogier, N. and Chauvaud, P., "The compression function of 2860 MD2 is not collision free," Presented at Selected Areas in 2861 Cryptography '95, May 1995. 2863 [RFC 791] J. Postel, "Internet Protocol", September 1981. 2865 [RFC 822] D. Crocker, "Standard for the format of ARPA Internet text 2866 messages", August 1982. 2868 [RFC 1034] P.V. Mockapetris, "Domain names - concepts and facili- 2869 ties", 2870 November 1987. 2872 [RFC 1319] Kaliski, B., "The MD2 Message-Digest Algorithm," RFC 1319, 2873 RSA Laboratories, April 1992. 2875 [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic 2876 Mail: Part II: Certificate-Based Key Management," RFC 2877 1422, BBN Communications, February 1993. 2879 [RFC 1423] Balenson, D., "Privacy Enhancement for Internet Electronic 2880 Mail: Part III: Algorithms, Modes, and Identifiers," 2881 RFC 1423, Trusted Information Systems, February 1993. 2883 [RFC 1519] V. Fuller, T. Li, J. Yu, and K. Varadhan. "Classless 2884 Inter-Domain Routing (CIDR): an Address Assignment and 2885 Aggregation Strategy", September 1993. 2887 [RFC 1883] S. Deering and R. Hinden. "Internet Protocol, Version 6 2888 (IPv6) Specification", December 1995. 2890 [RFC 2044] F. Yergeau, "UTF-8, a transformation format of Unicode 2891 and ISO 10646", October 1996. 2893 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 2894 Requirement Levels", March 1997. 2896 [RFC 2277] H. Alvestrand, "IETF Policy on Character Sets and 2897 Languages", January 1998. 2899 [RFC 2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646", 2900 January 1998. 2902 [RFC 2313] B. Kaliski, "PKCS #1: RSA Encryption Version 1.5", 2903 March 1998. 2905 [SDN.701] SDN.701, "Message Security Protocol 4.0", Revision A 2906 1997-02-06. 2908 [X.208] CCITT Recommendation X.208: Specification of Abstract 2909 Syntax Notation One (ASN.1), 1988. 2911 [X.509] ITU-T Recommendation X.509 (1997 E): Information 2912 Technology - Open Systems Interconnection - The 2913 Directory: Authentication Framework, June 1997. 2915 [X9.42] ANSI X9.42-199x, Public Key Cryptography for The Financial 2916 Services Industry: Agreement of Symmetric Algorithm Keys 2917 Using Diffie-Hellman (Working Draft), December 1997. 2919 [X9.55] ANSI X9.55-1995, Public Key Cryptography For The Financial 2920 Services Industry: Extensions To Public Key Certificates 2921 And Certificate Revocation Lists, 8 December, 1995. 2923 [X9.57] ANSI X9.57-199x, Public Key Cryptography For The Financial 2924 Services Industry: Certificate Management (Working Draft), 2925 21 June, 1996. 2927 9 Patent Statements 2929 The Internet PKI relies on the use of patented public key technology 2930 and secure hash technology for digital signature services. This 2931 specification references public key encryption technology for provi- 2932 sioning key exchange services. 2934 The Internet Standards Process as defined in RFC 1310 requires a 2935 written statement from the Patent holder that a license will be made 2936 available to applicants under reasonable terms and conditions prior 2937 to approving a specification as a Proposed, Draft or Internet Stan- 2938 dard. 2940 Patent statements for DSA, RSA, Diffie-Hellman, and Hellman-Merkle 2941 follow. These statements have been supplied by the patent holders, 2942 not the authors of this profile. 2944 The Internet Society, Internet Architecture Board, Internet Engineer- 2945 ing Steering Group and the Corporation for National Research Initia- 2946 tives take no position on the validity or scope of the following 2947 patents and patent applications, nor on the appropriateness of the 2948 terms of the assurance. The Internet Society and other groups men- 2949 tioned above have not made any determination as to any other 2950 intellectual property rights which may apply to the practice of this 2951 standard. Any further consideration of these matters is the user's 2952 responsibility. 2954 9.1 Digital Signature Algorithm (DSA) 2956 The U.S. Government holds patent 5,231,668 on the Digital Signature 2957 Algorithm (DSA), which has been incorporated into Federal Information 2958 Processing Standard (FIPS) 186. The patent was issued on July 27, 2959 1993. 2961 The National Institute of Standards and Technology (NIST) has a long 2962 tradition of supplying U.S. Government-developed techniques to com- 2963 mittees and working groups for inclusion into standards on a 2964 royalty-free basis. NIST has made the DSA patent available royalty- 2965 free to users worldwide. 2967 NIST has provided the following statement with regard to this patent: 2969 Regarding patent infringement, FIPS 186 summarizes our position; 2970 the Department of Commerce is not aware of any patents that would 2971 be infringed by the DSA. Questions regarding this matter may be 2972 directed to the Deputy Chief Counsel for NIST. 2974 9.2 RSA Signature and Encryption 2976 The Massachusetts Institute of Technology has granted RSA Data Secu- 2977 rity, Inc., exclusive sub-licensing rights to the following patent 2978 issued in the United States: 2980 Cryptographic Communications System and Method ("RSA"), No. 4,405,829 2982 RSA Data Security, Inc. has provided the following statement with 2983 regard to this patent: 2985 It is our understanding that the proposed PKIX Certificate Profile 2986 (PKIX-1) standard currently under review contemplates the use of 2987 U.S Patent 4,405,829 entitled "Cryptographic Communication System 2988 and Method" (the "RSA patent") which patent is controlled by RSA. 2990 It is RSA's business practice to make licenses to its patents 2991 available on reasonable and nondiscriminatory terms. Accordingly, 2992 if the foregoing identified IETF standard is adopted, RSA is wil- 2993 ling, upon request, to grant non-exclusive licenses to such patent 2994 on reasonable and non-discriminatory terms and conditions to those 2995 who respect RSA's intellectual property rights and subject to 2996 RSA's then current royalty rate for the patent licensed. The roy- 2997 alty rate for the RSA patent is presently set at 2% of the 2998 licensee's selling price for each product covered by the patent. 2999 Any requests for license information may be directed to: 3001 Director of Licensing 3002 RSA Data Security, Inc. 3003 100 Marine Parkway, Suite 500 3004 Redwood City, CA 94065 3006 A license under RSA's patent(s) does not include any rights to 3007 know-how or other technical information or license under other 3008 intellectual property rights. Such license does not extend to any 3009 activities which constitute infringement or inducement thereto. A 3010 licensee must make his own determination as to whether a license 3011 is necessary under patents of others. 3013 9.3 Diffie-Hellman Key Agreement 3015 Patent No. 4,200,770: Cryptographic Apparatus and Method ("Diffie- 3016 Hellman") expired on August 19, 1997. 3018 9.4 Hellman-Merkle Public Key Cryptography 3020 Patent No. 4,218,582: Public Key Cryptographic Apparatus and Method 3021 ("Hellman-Merkle") expired on April 29, 1997. 3023 9.5 CRL Distribution Points and Related Mechanisms 3025 Entrust Technologies Incorporated has provided the following state- 3026 ment with regard to this patent: 3028 Entrust Technologies Incorporated advises the IETF that it holds 3029 the Patent (as defined herein) which may relate to the IETF. In 3030 accordance with the Intellectual Property rights procedures of the 3031 IETF standards process, Entrust Technologies Incorporated, for 3032 itself and its subsidiaries (hereinafter called "Entrust") will 3033 offer licenses under its Patent on a perpetual, royalty-free, 3034 non-exclusive basis and on non-discriminatory, fair and equitable 3035 terms to all parties solely for their use in complying with the 3036 Standard, but on condition that any such party offers to Entrust 3037 and its corporate affiliates similar licenses under such party's 3038 patents, if any, for use in complying with the Standard. 3040 Any application for a license under Entrust's Patent pursuant to 3041 this Patent Disclosure Statement should be made to: 3043 Stephen Samson 3044 Entrust Technologies Limited 3045 750 Heron Road, Ottawa, Ontario, Canada, K1V 1A7 3046 voice: (613) 247 3725 3048 As used herein: 3050 "Patent" means US Patent 5,699,431 issued on 16 December, 1997 for 3051 an invention known as a "Method for Efficient Management of Certi- 3052 ficate Revocation Lists and Update Information", which invention 3053 is owned or controlled by Entrust and the use of which may be 3054 required in conjunction with the Standard. 3056 "Standard" means a specification progressing through the Standard 3057 Track of the IETF and relating to the Public Key Infrastructure 3058 (X.509) specification for certificate update and revocation. 3060 10 Security Considerations 3062 The majority of this specification is devoted to the format and con- 3063 tent of certificates and CRLs. Since certificates and CRLs are digi- 3064 tally signed, no additional integrity service is necessary. Neither 3065 certificates nor CRLs need be kept secret, and unrestricted and 3066 anonymous access to certificates and CRLs has no security implica- 3067 tions. 3069 However, security factors outside the scope of this specification 3070 will affect the assurance provided to certificate users. This sec- 3071 tion highlights critical issues that should be considered by imple- 3072 mentors, administrators, and users. 3074 The procedures performed by CAs and RAs to validate the binding of 3075 the subject's identity of their public key greatly affect the 3076 assurance that should be placed in the certificate. Relying parties 3077 may wish to review the CA's certificate practice statement. This may 3078 be particularly important when issuing certificates to other CAs. 3080 The use of a single key pair for both signature and other purposes is 3081 strongly discouraged. Use of separate key pairs for signature and key 3082 management provides several benefits to the users. The ramifications 3083 associated with loss or disclosure of a signature key are different 3084 from loss or disclosure of a key management key. Using separate key 3085 pairs permits a balanced and flexible response. Similarly, different 3086 validity periods or key lengths for each key pair may be appropriate 3087 in some application environments. Unfortunately, some legacy applica- 3088 tions (e.g., SSL) use a single key pair for signature and key manage- 3089 ment. 3091 The protection afforded private keys is a critical factor in main- 3092 taining security. On a small scale, failure of users to protect 3093 their private keys will permit an attacker to masquerade as them, or 3094 decrypt their personal information. On a larger scale, compromise of 3095 a CA's private signing key may have a catastrophic effect. If an 3096 attacker obtains the private key unnoticed, the attacker may issue 3097 bogus certificates and CRLs. Existence of bogus certificates and 3098 CRLs will undermine confidence in the system. If the compromise is 3099 detected, all certificates issued to the CA must be revoked, prevent- 3100 ing services between its users and users of other CAs. Rebuilding 3101 after such a compromise will be problematic, so CAs are advised to 3102 implement a combination of strong technical measures (e.g., tamper- 3103 resistant cryptographic modules) and appropriate management pro- 3104 cedures (e.g., separation of duties) to avoid such an 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 Finally, the binding between a key and certificate subject cannot be 3146 stronger than the cryptographic module implementation and algorithms 3147 used to generate the signature. Short key lengths or weak hash algo- 3148 rithms will limit the utility of a certificate. CAs are encouraged 3149 to note advances in cryptology so they can employ strong crypto- 3150 graphic techniques. In addition, CAs should decline to issue certi- 3151 ficates to CAs or end entities that generate weak signatures. 3153 Appendix A. Psuedo-ASN.1 Structures and OIDs 3155 This section describes data objects used by conforming PKI components 3156 in an "ASN.1-like" syntax. This syntax is a hybrid of the 1988 and 3157 1993 ASN.1 syntaxes. The 1988 ASN.1 syntax is augmented with 1993 3158 UNIVERSAL Types UniversalString, BMPString and UTF8String. 3160 The ASN.1 syntax does not permit the inclusion of type statements in 3161 the ASN.1 module, and the 1993 ASN.1 standard does not permit use of 3162 the new UNIVERSAL types in modules using the 1988 syntax. As a 3163 result, this module does not conform to either version of the ASN.1 3164 standard. 3166 This appendix may be converted into 1988 ASN.1 by replacing the 3167 defintions for the UNIVERSAL Types with the 1988 catch-all "ANY". 3169 A.1 Explicitly Tagged Module 3171 PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) 3172 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)} 3174 DEFINITIONS EXPLICIT TAGS ::= 3176 BEGIN 3178 -- EXPORTS ALL -- 3180 -- IMPORTS NONE -- 3182 -- UNIVERSAL Types defined in '93 and '98 ASN.1 3183 -- but required by this specification 3185 UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING 3186 -- UniversalString is defined in ASN.1:1993 3188 BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING 3189 -- BMPString is the subtype of UniversalString and models 3190 -- the Basic Multilingual Plane of ISO/IEC/ITU 10646-1 3192 UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 3193 -- The content of this type conforms to RFC 2044. 3195 -- 3196 -- PKIX specific OIDs 3198 id-pkix OBJECT IDENTIFIER ::= 3199 { iso(1) identified-organization(3) dod(6) internet(1) 3200 security(5) mechanisms(5) pkix(7) } 3201 -- PKIX arcs 3203 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 3204 -- arc for private certificate extensions 3205 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 3206 -- arc for policy qualifier types 3207 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 3208 -- arc for extended key purpose OIDS 3209 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 3210 -- arc for access descriptors 3212 -- policyQualifierIds for Internet policy qualifiers 3214 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 3215 -- OID for CPS qualifier 3216 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 3217 -- OID for user notice qualifier 3219 -- attribute data types -- 3221 Attribute ::= SEQUENCE { 3222 type AttributeType, 3223 values SET OF AttributeValue 3224 -- at least one value is required -- } 3226 AttributeType ::= OBJECT IDENTIFIER 3228 AttributeValue ::= ANY 3230 AttributeTypeAndValue ::= SEQUENCE { 3231 type AttributeType, 3232 value AttributeValue } 3234 -- suggested naming attributes: Definition of the following 3235 -- information object set may be augmented to meet local 3236 -- requirements. Note that deleting members of the set may 3237 -- prevent interoperability with conforming implementations. 3238 -- presented in pairs: the AttributeType followed by the 3239 -- type definition for the corresponding AttributeValue 3241 --Arc for standard naming attributes 3242 id-at OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 4} 3244 -- Attributes of type NameDirectoryString 3245 id-at-name AttributeType ::= {id-at 41} 3246 id-at-surname AttributeType ::= {id-at 4} 3247 id-at-givenName AttributeType ::= {id-at 42} 3248 id-at-initials AttributeType ::= {id-at 43} 3249 id-at-generationQualifier AttributeType ::= {id-at 44} 3251 X520name ::= CHOICE { 3252 teletexString TeletexString (SIZE (1..ub-name)), 3253 printableString PrintableString (SIZE (1..ub-name)), 3254 universalString UniversalString (SIZE (1..ub-name)), 3255 utf8String UTF8String (SIZE (1..ub-name)), 3256 bmpString BMPString (SIZE(1..ub-name)) } 3258 -- 3260 id-at-commonName AttributeType ::= {id-at 3} 3262 X520CommonName ::= CHOICE { 3263 teletexString TeletexString (SIZE (1..ub-common-name)), 3264 printableString PrintableString (SIZE (1..ub-common-name)), 3265 universalString UniversalString (SIZE (1..ub-common-name)), 3266 utf8String UTF8String (SIZE (1..ub-common-name)), 3267 bmpString BMPString (SIZE(1..ub-common-name)) } 3269 -- 3271 id-at-localityName AttributeType ::= {id-at 7} 3273 X520LocalityName ::= CHOICE { 3274 teletexString TeletexString (SIZE (1..ub-locality-name)), 3275 printableString PrintableString (SIZE (1..ub-locality-name)), 3276 universalString UniversalString (SIZE (1..ub-locality-name)), 3277 utf8String UTF8String (SIZE (1..ub-locality-name)), 3278 bmpString BMPString (SIZE(1..ub-locality-name)) } 3280 -- 3282 id-at-stateOrProvinceName AttributeType ::= {id-at 8} 3284 X520StateOrProvinceName ::= CHOICE { 3285 teletexString TeletexString (SIZE (1..ub-state-name)), 3286 printableString PrintableString (SIZE (1..ub-state-name)), 3287 universalString UniversalString (SIZE (1..ub-state-name)), 3288 utf8String UTF8String (SIZE (1..ub-state-name)), 3289 bmpString BMPString (SIZE(1..ub-state-name)) } 3291 -- 3293 id-at-organizationName AttributeType ::= {id-at 10} 3295 X520OrganizationName ::= CHOICE { 3296 teletexString TeletexString (SIZE (1..ub-organization-name)), 3297 printableString PrintableString (SIZE (1..ub-organization-name)), 3298 universalString UniversalString (SIZE (1..ub-organization-name)), 3299 utf8String UTF8String (SIZE (1..ub-organization-name)), 3300 bmpString BMPString (SIZE(1..ub-organization-name)) } 3302 -- 3304 id-at-organizationalUnitName AttributeType ::= {id-at 11} 3306 X520OrganizationalUnitName ::= CHOICE { 3307 teletexString TeletexString (SIZE (1..ub-organizational-unit-name)), 3308 printableString PrintableString 3309 (SIZE (1..ub-organizational-unit-name)), 3310 universalString UniversalString 3311 (SIZE (1..ub-organizational-unit-name)), 3312 utf8String UTF8String (SIZE (1..ub-organizational-unit-name)), 3313 bmpString BMPString (SIZE(1..ub-organizational-unit-name)) } 3315 -- 3317 id-at-title AttributeType ::= {id-at 12} 3319 X520Title ::= CHOICE { 3320 teletexString TeletexString (SIZE (1..ub-title)), 3321 printableString PrintableString (SIZE (1..ub-title)), 3322 universalString UniversalString (SIZE (1..ub-title)), 3323 utf8String UTF8String (SIZE (1..ub-title)), 3324 bmpString BMPString (SIZE(1..ub-title)) } 3326 -- 3328 id-at-dnQualifier AttributeType ::= {id-at 46} 3329 X520dnQualifier ::= PrintableString 3331 id-at-countryName AttributeType ::= {id-at 6} 3332 X520countryName ::= PrintableString (SIZE (2)) -- IS 3166 codes 3334 -- Legacy attributes 3336 pkcs-9 OBJECT IDENTIFIER ::= 3337 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 } 3339 emailAddress AttributeType ::= { pkcs-9 1 } 3341 Pkcs9email ::= IA5String (SIZE (1..ub-emailaddress-length)) 3342 -- naming data types -- 3344 Name ::= CHOICE { -- only one possibility for now -- 3345 rdnSequence RDNSequence } 3347 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 3349 DistinguishedName ::= RDNSequence 3351 RelativeDistinguishedName ::= 3352 SET SIZE (1 .. MAX) OF AttributeTypeAndValue 3354 -- Directory string type -- 3356 DirectoryString ::= CHOICE { 3357 teletexString TeletexString (SIZE (1..MAX)), 3358 printableString PrintableString (SIZE (1..MAX)), 3359 universalString UniversalString (SIZE (1..MAX)), 3360 utf8String UTF8String (SIZE (1..MAX)), 3361 bmpString BMPString (SIZE(1..MAX)) } 3363 -- certificate and CRL specific structures begin here 3365 Certificate ::= SEQUENCE { 3366 tbsCertificate TBSCertificate, 3367 signatureAlgorithm AlgorithmIdentifier, 3368 signature BIT STRING } 3370 TBSCertificate ::= SEQUENCE { 3371 version [0] Version DEFAULT v1, 3372 serialNumber CertificateSerialNumber, 3373 signature AlgorithmIdentifier, 3374 issuer Name, 3375 validity Validity, 3376 subject Name, 3377 subjectPublicKeyInfo SubjectPublicKeyInfo, 3378 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 3379 -- If present, version must be v2 or v3 3380 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 3381 -- If present, version must be v2 or v3 3382 extensions [3] Extensions OPTIONAL 3383 -- If present, version must be v3 -- } 3385 Version ::= INTEGER { v1(0), v2(1), v3(2) } 3387 CertificateSerialNumber ::= INTEGER 3389 Validity ::= SEQUENCE { 3390 notBefore Time, 3391 notAfter Time } 3393 Time ::= CHOICE { 3394 utcTime UTCTime, 3395 generalTime GeneralizedTime } 3397 UniqueIdentifier ::= BIT STRING 3399 SubjectPublicKeyInfo ::= SEQUENCE { 3400 algorithm AlgorithmIdentifier, 3401 subjectPublicKey BIT STRING } 3403 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 3405 Extension ::= SEQUENCE { 3406 extnID OBJECT IDENTIFIER, 3407 critical BOOLEAN DEFAULT FALSE, 3408 extnValue OCTET STRING } 3410 -- CRL structures 3412 CertificateList ::= SEQUENCE { 3413 tbsCertList TBSCertList, 3414 signatureAlgorithm AlgorithmIdentifier, 3415 signature BIT STRING } 3417 TBSCertList ::= SEQUENCE { 3418 version Version OPTIONAL, 3419 -- if present, must be v2 3420 signature AlgorithmIdentifier, 3421 issuer Name, 3422 thisUpdate Time, 3423 nextUpdate Time OPTIONAL, 3424 revokedCertificates SEQUENCE OF SEQUENCE { 3425 userCertificate CertificateSerialNumber, 3426 revocationDate Time, 3427 crlEntryExtensions Extensions OPTIONAL 3428 -- if present, must be v2 3429 } OPTIONAL, 3430 crlExtensions [0] Extensions OPTIONAL 3431 -- if present, must be v2 -- } 3433 -- Version, Time, CertificateSerialNumber, and Extensions were 3434 -- defined earlier for use in the certificate structure 3436 AlgorithmIdentifier ::= SEQUENCE { 3437 algorithm OBJECT IDENTIFIER, 3438 parameters ANY DEFINED BY algorithm OPTIONAL } 3439 -- contains a value of the type 3440 -- registered for use with the 3441 -- algorithm object identifier value 3443 -- Algorithm OIDs and parameter structures 3445 pkcs-1 OBJECT IDENTIFIER ::= { 3446 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 } 3448 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } 3450 md2WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 2 } 3452 md5WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 4 } 3454 sha1WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 5 } 3456 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { 3457 iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 3 } 3459 Dss-Sig-Value ::= SEQUENCE { 3460 r INTEGER, 3461 s INTEGER } 3463 dhpublicnumber OBJECT IDENTIFIER ::= { 3464 iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 } 3466 DomainParameters ::= SEQUENCE { 3467 p INTEGER, -- odd prime, p=jq +1 3468 g INTEGER, -- generator, g 3469 q INTEGER, -- factor of p-1 3470 j INTEGER OPTIONAL, -- subgroup factor, j>= 2 3471 validationParms ValidationParms OPTIONAL } 3473 ValidationParms ::= SEQUENCE { 3474 seed BIT STRING, 3475 pgenCounter INTEGER } 3477 id-dsa OBJECT IDENTIFIER ::= { 3478 iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 } 3480 Dss-Parms ::= SEQUENCE { 3481 p INTEGER, 3482 q INTEGER, 3483 g INTEGER } 3485 -- x400 address syntax starts here 3486 -- OR Names 3488 ORAddress ::= SEQUENCE { 3489 built-in-standard-attributes BuiltInStandardAttributes, 3490 built-in-domain-defined-attributes 3491 BuiltInDomainDefinedAttributes OPTIONAL, 3492 -- see also teletex-domain-defined-attributes 3493 extension-attributes ExtensionAttributes OPTIONAL } 3494 -- The OR-address is semantically absent from the OR-name if the 3495 -- built-in-standard-attribute sequence is empty and the 3496 -- built-in-domain-defined-attributes and extension-attributes are 3497 -- both omitted. 3499 -- Built-in Standard Attributes 3501 BuiltInStandardAttributes ::= SEQUENCE { 3502 country-name CountryName OPTIONAL, 3503 administration-domain-name AdministrationDomainName OPTIONAL, 3504 network-address [0] NetworkAddress OPTIONAL, 3505 -- see also extended-network-address 3506 terminal-identifier [1] TerminalIdentifier OPTIONAL, 3507 private-domain-name [2] PrivateDomainName OPTIONAL, 3508 organization-name [3] OrganizationName OPTIONAL, 3509 -- see also teletex-organization-name 3510 numeric-user-identifier [4] NumericUserIdentifier OPTIONAL, 3511 personal-name [5] PersonalName OPTIONAL, 3512 -- see also teletex-personal-name 3513 organizational-unit-names [6] OrganizationalUnitNames OPTIONAL 3514 -- see also teletex-organizational-unit-names -- } 3516 CountryName ::= [APPLICATION 1] CHOICE { 3517 x121-dcc-code NumericString 3518 (SIZE (ub-country-name-numeric-length)), 3519 iso-3166-alpha2-code PrintableString 3520 (SIZE (ub-country-name-alpha-length)) } 3522 AdministrationDomainName ::= [APPLICATION 2] CHOICE { 3523 numeric NumericString (SIZE (0..ub-domain-name-length)), 3524 printable PrintableString (SIZE (0..ub-domain-name-length)) } 3526 NetworkAddress ::= X121Address -- see also extended-network-address 3528 X121Address ::= NumericString (SIZE (1..ub-x121-address-length)) 3530 TerminalIdentifier ::= PrintableString (SIZE (1..ub-terminal-id-length)) 3532 PrivateDomainName ::= CHOICE { 3533 numeric NumericString (SIZE (1..ub-domain-name-length)), 3534 printable PrintableString (SIZE (1..ub-domain-name-length)) } 3536 OrganizationName ::= PrintableString 3537 (SIZE (1..ub-organization-name-length)) 3538 -- see also teletex-organization-name 3540 NumericUserIdentifier ::= NumericString 3541 (SIZE (1..ub-numeric-user-id-length)) 3543 PersonalName ::= SET { 3544 surname [0] PrintableString (SIZE (1..ub-surname-length)), 3545 given-name [1] PrintableString 3546 (SIZE (1..ub-given-name-length)) OPTIONAL, 3547 initials [2] PrintableString (SIZE (1..ub-initials-length)) OPTIONAL, 3548 generation-qualifier [3] PrintableString 3549 (SIZE (1..ub-generation-qualifier-length)) OPTIONAL } 3550 -- see also teletex-personal-name 3552 OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units) 3553 OF OrganizationalUnitName 3554 -- see also teletex-organizational-unit-names 3556 OrganizationalUnitName ::= PrintableString (SIZE 3557 (1..ub-organizational-unit-name-length)) 3559 -- Built-in Domain-defined Attributes 3561 BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE 3562 (1..ub-domain-defined-attributes) OF 3563 BuiltInDomainDefinedAttribute 3565 BuiltInDomainDefinedAttribute ::= SEQUENCE { 3566 type PrintableString (SIZE 3567 (1..ub-domain-defined-attribute-type-length)), 3568 value PrintableString (SIZE 3569 (1..ub-domain-defined-attribute-value-length))} 3571 -- Extension Attributes 3573 ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF 3574 ExtensionAttribute 3576 ExtensionAttribute ::= SEQUENCE { 3577 extension-attribute-type [0] INTEGER (0..ub-extension-attributes), 3578 extension-attribute-value [1] 3579 ANY DEFINED BY extension-attribute-type } 3581 -- Extension types and attribute values 3582 -- 3584 common-name INTEGER ::= 1 3586 CommonName ::= PrintableString (SIZE (1..ub-common-name-length)) 3588 teletex-common-name INTEGER ::= 2 3590 TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length)) 3592 teletex-organization-name INTEGER ::= 3 3594 TeletexOrganizationName ::= 3595 TeletexString (SIZE (1..ub-organization-name-length)) 3597 teletex-personal-name INTEGER ::= 4 3599 TeletexPersonalName ::= SET { 3600 surname [0] TeletexString (SIZE (1..ub-surname-length)), 3601 given-name [1] TeletexString 3602 (SIZE (1..ub-given-name-length)) OPTIONAL, 3603 initials [2] TeletexString (SIZE (1..ub-initials-length)) OPTIONAL, 3604 generation-qualifier [3] TeletexString (SIZE 3605 (1..ub-generation-qualifier-length)) OPTIONAL } 3607 teletex-organizational-unit-names INTEGER ::= 5 3609 TeletexOrganizationalUnitNames ::= SEQUENCE SIZE 3610 (1..ub-organizational-units) OF TeletexOrganizationalUnitName 3612 TeletexOrganizationalUnitName ::= TeletexString 3613 (SIZE (1..ub-organizational-unit-name-length)) 3615 pds-name INTEGER ::= 7 3617 PDSName ::= PrintableString (SIZE (1..ub-pds-name-length)) 3619 physical-delivery-country-name INTEGER ::= 8 3621 PhysicalDeliveryCountryName ::= CHOICE { 3622 x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)), 3623 iso-3166-alpha2-code PrintableString 3624 (SIZE (ub-country-name-alpha-length)) } 3626 postal-code INTEGER ::= 9 3628 PostalCode ::= CHOICE { 3629 numeric-code NumericString (SIZE (1..ub-postal-code-length)), 3630 printable-code PrintableString (SIZE (1..ub-postal-code-length)) } 3632 physical-delivery-office-name INTEGER ::= 10 3634 PhysicalDeliveryOfficeName ::= PDSParameter 3636 physical-delivery-office-number INTEGER ::= 11 3638 PhysicalDeliveryOfficeNumber ::= PDSParameter 3640 extension-OR-address-components INTEGER ::= 12 3642 ExtensionORAddressComponents ::= PDSParameter 3644 physical-delivery-personal-name INTEGER ::= 13 3646 PhysicalDeliveryPersonalName ::= PDSParameter 3648 physical-delivery-organization-name INTEGER ::= 14 3650 PhysicalDeliveryOrganizationName ::= PDSParameter 3652 extension-physical-delivery-address-components INTEGER ::= 15 3654 ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter 3656 unformatted-postal-address INTEGER ::= 16 3658 UnformattedPostalAddress ::= SET { 3659 printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) OF 3660 PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL, 3661 teletex-string TeletexString 3662 (SIZE (1..ub-unformatted-address-length)) OPTIONAL } 3664 street-address INTEGER ::= 17 3666 StreetAddress ::= PDSParameter 3668 post-office-box-address INTEGER ::= 18 3670 PostOfficeBoxAddress ::= PDSParameter 3672 poste-restante-address INTEGER ::= 19 3674 PosteRestanteAddress ::= PDSParameter 3676 unique-postal-name INTEGER ::= 20 3677 UniquePostalName ::= PDSParameter 3679 local-postal-attributes INTEGER ::= 21 3681 LocalPostalAttributes ::= PDSParameter 3683 PDSParameter ::= SET { 3684 printable-string PrintableString 3685 (SIZE(1..ub-pds-parameter-length)) OPTIONAL, 3686 teletex-string TeletexString 3687 (SIZE(1..ub-pds-parameter-length)) OPTIONAL } 3689 extended-network-address INTEGER ::= 22 3691 ExtendedNetworkAddress ::= CHOICE { 3692 e163-4-address SEQUENCE { 3693 number [0] NumericString (SIZE (1..ub-e163-4-number-length)), 3694 sub-address [1] NumericString 3695 (SIZE (1..ub-e163-4-sub-address-length)) OPTIONAL }, 3696 psap-address [0] PresentationAddress } 3698 PresentationAddress ::= SEQUENCE { 3699 pSelector [0] EXPLICIT OCTET STRING OPTIONAL, 3700 sSelector [1] EXPLICIT OCTET STRING OPTIONAL, 3701 tSelector [2] EXPLICIT OCTET STRING OPTIONAL, 3702 nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING } 3704 terminal-type INTEGER ::= 23 3706 TerminalType ::= INTEGER { 3707 telex (3), 3708 teletex (4), 3709 g3-facsimile (5), 3710 g4-facsimile (6), 3711 ia5-terminal (7), 3712 videotex (8) } (0..ub-integer-options) 3714 -- Extension Domain-defined Attributes 3716 teletex-domain-defined-attributes INTEGER ::= 6 3718 TeletexDomainDefinedAttributes ::= SEQUENCE SIZE 3719 (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute 3721 TeletexDomainDefinedAttribute ::= SEQUENCE { 3722 type TeletexString 3723 (SIZE (1..ub-domain-defined-attribute-type-length)), 3724 value TeletexString 3725 (SIZE (1..ub-domain-defined-attribute-value-length)) } 3727 -- specifications of Upper Bounds must be regarded as mandatory 3728 -- from Annex B of ITU-T X.411 Reference Definition of MTS Parameter 3729 -- Upper Bounds 3731 -- Upper Bounds 3732 ub-name INTEGER ::= 32768 3733 ub-common-name INTEGER ::= 64 3734 ub-locality-name INTEGER ::= 128 3735 ub-state-name INTEGER ::= 128 3736 ub-organization-name INTEGER ::= 64 3737 ub-organizational-unit-name INTEGER ::= 64 3738 ub-title INTEGER ::= 64 3739 ub-match INTEGER ::= 128 3741 ub-emailaddress-length INTEGER ::= 128 3743 ub-common-name-length INTEGER ::= 64 3744 ub-country-name-alpha-length INTEGER ::= 2 3745 ub-country-name-numeric-length INTEGER ::= 3 3746 ub-domain-defined-attributes INTEGER ::= 4 3747 ub-domain-defined-attribute-type-length INTEGER ::= 8 3748 ub-domain-defined-attribute-value-length INTEGER ::= 128 3749 ub-domain-name-length INTEGER ::= 16 3750 ub-extension-attributes INTEGER ::= 256 3751 ub-e163-4-number-length INTEGER ::= 15 3752 ub-e163-4-sub-address-length INTEGER ::= 40 3753 ub-generation-qualifier-length INTEGER ::= 3 3754 ub-given-name-length INTEGER ::= 16 3755 ub-initials-length INTEGER ::= 5 3756 ub-integer-options INTEGER ::= 256 3757 ub-numeric-user-id-length INTEGER ::= 32 3758 ub-organization-name-length INTEGER ::= 64 3759 ub-organizational-unit-name-length INTEGER ::= 32 3760 ub-organizational-units INTEGER ::= 4 3761 ub-pds-name-length INTEGER ::= 16 3762 ub-pds-parameter-length INTEGER ::= 30 3763 ub-pds-physical-address-lines INTEGER ::= 6 3764 ub-postal-code-length INTEGER ::= 16 3765 ub-surname-length INTEGER ::= 40 3766 ub-terminal-id-length INTEGER ::= 24 3767 ub-unformatted-address-length INTEGER ::= 180 3768 ub-x121-address-length INTEGER ::= 16 3770 -- Note - upper bounds on string types, such as TeletexString, are 3771 -- measured in characters. Excepting PrintableString or IA5String, a 3772 -- significantly greater number of octets will be required to hold 3773 -- such a value. As a minimum, 16 octets, or twice the specified upper 3774 -- bound, whichever is the larger, should be allowed for TeletexString. 3775 -- For UTF8String or UniversalString at least four times the upper 3776 -- bound should be allowed. 3778 END 3779 A.2 Implicit Module 88-style ASN.1 3781 PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) 3782 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)} 3784 DEFINITIONS IMPLICIT TAGS ::= 3786 BEGIN 3788 -- EXPORTS ALL -- 3790 IMPORTS 3791 id-pe, id-qt, id-kp, id-ad, id-qt-unotice, id-qt-cps, 3792 ORAddress, Name, RelativeDistinguishedName, 3793 CertificateSerialNumber, 3794 CertificateList, AlgorithmIdentifier, ub-name, 3795 Attribute, DirectoryString 3796 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 3797 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3798 id-mod(0) id-pkix1-explicit(1)}; 3800 -- ISO arc for standard certificate and CRL extensions 3802 id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 3804 -- authority key identifier OID and syntax 3806 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 3808 AuthorityKeyIdentifier ::= SEQUENCE { 3809 keyIdentifier [0] KeyIdentifier OPTIONAL, 3810 authorityCertIssuer [1] GeneralNames OPTIONAL, 3811 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 3812 -- authorityCertIssuer and authorityCertSerialNumber must both 3813 -- be present or both be absent 3815 KeyIdentifier ::= OCTET STRING 3817 -- subject key identifier OID and syntax 3819 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 3821 SubjectKeyIdentifier ::= KeyIdentifier 3823 -- key usage extension OID and syntax 3825 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 3826 KeyUsage ::= BIT STRING { 3827 digitalSignature (0), 3828 nonRepudiation (1), 3829 keyEncipherment (2), 3830 dataEncipherment (3), 3831 keyAgreement (4), 3832 keyCertSign (5), 3833 cRLSign (6) } 3835 -- private key usage period extension OID and syntax 3837 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 3839 PrivateKeyUsagePeriod ::= SEQUENCE { 3840 notBefore [0] GeneralizedTime OPTIONAL, 3841 notAfter [1] GeneralizedTime OPTIONAL } 3842 -- either notBefore or notAfter must be present 3844 -- certificate policies extension OID and syntax 3846 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 3848 CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 3850 PolicyInformation ::= SEQUENCE { 3851 policyIdentifier CertPolicyId, 3852 policyQualifiers SEQUENCE SIZE (1..MAX) OF 3853 PolicyQualifierInfo OPTIONAL } 3855 CertPolicyId ::= OBJECT IDENTIFIER 3857 PolicyQualifierInfo ::= SEQUENCE { 3858 policyQualifierId PolicyQualifierId, 3859 qualifier ANY DEFINED BY policyQualifierId } 3861 -- Implementations that recognize additional policy qualifiers must 3862 -- augment the following definition for PolicyQualifierId 3864 PolicyQualifierId ::= 3865 OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) 3867 -- CPS pointer qualifier 3869 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 3871 CPSuri ::= IA5String 3873 -- user notice qualifier 3874 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 3876 UserNotice ::= SEQUENCE { 3877 noticeRef NoticeReference OPTIONAL, 3878 explicitText DisplayText OPTIONAL} 3880 NoticeReference ::= SEQUENCE { 3881 organization DisplayText, 3882 noticeNumbers SEQUENCE OF INTEGER } 3884 DisplayText ::= CHOICE { 3885 visibleString VisibleString (SIZE (1..200)), 3886 bmpString BMPString (SIZE (1..200)), 3887 utf8String UTF8String (SIZE (1..200)) } 3889 -- policy mapping extension OID and syntax 3891 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 3893 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 3894 issuerDomainPolicy CertPolicyId, 3895 subjectDomainPolicy CertPolicyId } 3897 -- subject alternative name extension OID and syntax 3899 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 3901 SubjectAltName ::= GeneralNames 3903 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 3905 GeneralName ::= CHOICE { 3906 otherName [0] AnotherName, 3907 rfc822Name [1] IA5String, 3908 dNSName [2] IA5String, 3909 x400Address [3] ORAddress, 3910 directoryName [4] Name, 3911 ediPartyName [5] EDIPartyName, 3912 uniformResourceIdentifier [6] IA5String, 3913 iPAddress [7] OCTET STRING, 3914 registeredID [8] OBJECT IDENTIFIER } 3916 -- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as 3917 -- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax 3919 AnotherName ::= SEQUENCE { 3920 type-id OBJECT IDENTIFIER, 3921 value [0] EXPLICIT ANY DEFINED BY type-id } 3923 EDIPartyName ::= SEQUENCE { 3924 nameAssigner [0] DirectoryString OPTIONAL, 3925 partyName [1] DirectoryString } 3927 -- issuer alternative name extension OID and syntax 3929 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 3931 IssuerAltName ::= GeneralNames 3933 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 3935 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 3937 -- basic constraints extension OID and syntax 3939 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 3941 BasicConstraints ::= SEQUENCE { 3942 cA BOOLEAN DEFAULT FALSE, 3943 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 3945 -- name constraints extension OID and syntax 3947 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 3949 NameConstraints ::= SEQUENCE { 3950 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 3951 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 3953 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 3955 GeneralSubtree ::= SEQUENCE { 3956 base GeneralName, 3957 minimum [0] BaseDistance DEFAULT 0, 3958 maximum [1] BaseDistance OPTIONAL } 3960 BaseDistance ::= INTEGER (0..MAX) 3962 -- policy constraints extension OID and syntax 3964 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } 3966 PolicyConstraints ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 3967 requireExplicitPolicy [0] SkipCerts OPTIONAL, 3968 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 3970 SkipCerts ::= INTEGER (0..MAX) 3971 -- CRL distribution points extension OID and syntax 3973 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31} 3975 CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 3977 DistributionPoint ::= SEQUENCE { 3978 distributionPoint [0] DistributionPointName OPTIONAL, 3979 reasons [1] ReasonFlags OPTIONAL, 3980 cRLIssuer [2] GeneralNames OPTIONAL } 3982 DistributionPointName ::= CHOICE { 3983 fullName [0] GeneralNames, 3984 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 3986 ReasonFlags ::= BIT STRING { 3987 unused (0), 3988 keyCompromise (1), 3989 cACompromise (2), 3990 affiliationChanged (3), 3991 superseded (4), 3992 cessationOfOperation (5), 3993 certificateHold (6) } 3995 -- extended key usage extension OID and syntax 3997 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 3999 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 4001 KeyPurposeId ::= OBJECT IDENTIFIER 4003 -- extended key purpose OIDs 4004 id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } 4005 id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } 4006 id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } 4007 id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } 4008 id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 } 4009 id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 } 4010 id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 } 4011 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 4013 -- CRL number extension OID and syntax 4015 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 4017 CRLNumber ::= INTEGER (0..MAX) 4018 -- issuing distribution point extension OID and syntax 4020 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 4022 IssuingDistributionPoint ::= SEQUENCE { 4023 distributionPoint [0] DistributionPointName OPTIONAL, 4024 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 4025 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 4026 onlySomeReasons [3] ReasonFlags OPTIONAL, 4027 indirectCRL [4] BOOLEAN DEFAULT FALSE } 4029 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 4031 -- deltaCRLIndicator ::= BaseCRLNumber 4033 BaseCRLNumber ::= CRLNumber 4035 -- CRL reasons extension OID and syntax 4037 id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 } 4039 CRLReason ::= ENUMERATED { 4040 unspecified (0), 4041 keyCompromise (1), 4042 cACompromise (2), 4043 affiliationChanged (3), 4044 superseded (4), 4045 cessationOfOperation (5), 4046 certificateHold (6), 4047 removeFromCRL (8) } 4049 -- certificate issuer CRL entry extension OID and syntax 4051 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } 4053 CertificateIssuer ::= GeneralNames 4055 -- hold instruction extension OID and syntax 4057 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 4059 HoldInstructionCode ::= OBJECT IDENTIFIER 4061 -- ANSI x9 holdinstructions 4063 -- ANSI x9 arc holdinstruction arc 4064 holdInstruction OBJECT IDENTIFIER ::= 4065 {joint-iso-itu-t(2) member-body(2) us(840) x9cm(10040) 2} 4067 -- ANSI X9 holdinstructions referenced by this standard 4068 id-holdinstruction-none OBJECT IDENTIFIER ::= 4069 {holdInstruction 1} -- deprecated 4070 id-holdinstruction-callissuer OBJECT IDENTIFIER ::= 4071 {holdInstruction 2} 4072 id-holdinstruction-reject OBJECT IDENTIFIER ::= 4073 {holdInstruction 3} 4075 -- invalidty date CRL entry extension OID and syntax 4077 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 4079 InvalidityDate ::= GeneralizedTime 4081 END 4082 Appendix B. 1993 ASN.1 Structures and OIDs 4084 B.1 1993 Explicitly Tagged Module 4086 PKIX1Explicit93 {iso(1) identified-organization(3) dod(6) internet(1) 4087 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-93(3)} 4089 DEFINITIONS EXPLICIT TAGS ::= 4091 BEGIN 4093 -- EXPORTS ALL -- 4095 IMPORTS 4096 authorityKeyIdentifier, subjectKeyIdentifier, keyUsage, 4097 extendedKeyUsage,privateKeyUsagePeriod, certificatePolicies, 4098 policyMappings, subjectAltName, issuerAltName, 4099 basicConstraints, nameConstraints, policyConstraints, 4100 cRLDistributionPoints, subjectDirectoryAttributes, 4101 cRLNumber, reasonCode, instructionCode, invalidityDate, 4102 issuingDistributionPoint, certificateIssuer, 4103 deltaCRLIndicator, authorityInfoAccess, id-ce 4104 FROM PKIX1Implicit93 {iso(1) identified-organization(3) 4105 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 4106 id-mod(0) id-pkix1-implicit-93(4)} ; 4108 -- 4109 -- Locally defined OIDs -- 4111 id-pkix OBJECT IDENTIFIER ::= 4112 { iso(1) identified-organization(3) dod(6) internet(1) 4113 security(5) mechanisms(5) pkix(7) } 4115 -- PKIX arcs 4116 -- arc for private certificate extensions 4117 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 4118 -- arc for policy qualifier types 4119 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 4120 -- arc for extended key purpose OIDS 4121 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 4122 -- arc for access descriptors 4123 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 4125 -- policyQualifierIds for Internet policy qualifiers 4126 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 4127 -- OID for CPS qualifier 4129 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 4130 -- OID for user notice qualifier 4132 -- based on excerpts from AuthenticationFramework 4133 -- {joint-iso-ccitt ds(5) modules(1) authenticationFramework(7) 2} 4135 -- Public Key Certificate -- 4137 Certificate ::= SIGNED { SEQUENCE { 4138 version [0] Version DEFAULT v1, 4139 serialNumber CertificateSerialNumber, 4140 signature AlgorithmIdentifier, 4141 issuer Name, 4142 validity Validity, 4143 subject Name, 4144 subjectPublicKeyInfo SubjectPublicKeyInfo, 4145 issuerUniqueIdentifier [1] IMPLICIT UniqueIdentifier OPTIONAL, 4146 ---if present, version must be v2 or v3-- 4147 subjectUniqueIdentifier [2] IMPLICIT UniqueIdentifier OPTIONAL, 4148 ---if present, version must be v2 or v3-- 4149 extensions [3] Extensions OPTIONAL 4150 --if present, version must be v3--} } 4152 UniqueIdentifier ::= BIT STRING 4154 Version ::= INTEGER { v1(0), v2(1), v3(2) } 4156 CertificateSerialNumber ::= INTEGER 4158 Validity ::= SEQUENCE { 4159 notBefore Time, 4160 notAfter Time } 4162 Time ::= CHOICE { 4163 utcTime UTCTime, 4164 generalTime GeneralizedTime } 4166 SubjectPublicKeyInfo ::= SEQUENCE{ 4167 algorithm AlgorithmIdentifier, 4168 subjectPublicKey BIT STRING} 4170 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 4172 Extension ::= SEQUENCE { 4173 extnId EXTENSION.&id ({ExtensionSet}), 4174 critical BOOLEAN DEFAULT FALSE, 4175 extnValue OCTET STRING } 4176 -- contains a DER encoding of a value of type 4177 -- &ExtnType for the 4178 -- extension object identified by extnId -- 4180 -- The following information object set is defined to constrain the 4181 -- set of legal certificate extensions. 4183 ExtensionSet EXTENSION ::= { authorityKeyIdentifier | 4184 subjectKeyIdentifier | 4185 keyUsage | 4186 extendedKeyUsage | 4187 privateKeyUsagePeriod | 4188 certificatePolicies | 4189 policyMappings | 4190 subjectAltName | 4191 issuerAltName | 4192 basicConstraints | 4193 nameConstraints | 4194 policyConstraints | 4195 cRLDistributionPoints | 4196 subjectDirectoryAttributes | 4197 authorityInfoAccess } 4199 EXTENSION ::= CLASS { 4200 &id OBJECT IDENTIFIER UNIQUE, 4201 &ExtnType } 4202 WITH SYNTAX { 4203 SYNTAX &ExtnType 4204 IDENTIFIED BY &id } 4206 -- Certificate Revocation List -- 4208 CertificateList ::= SIGNED { SEQUENCE { 4209 version Version OPTIONAL, -- if present, must be v2 4210 signature AlgorithmIdentifier, 4211 issuer Name, 4212 thisUpdate Time, 4213 nextUpdate Time OPTIONAL, 4214 revokedCertificates SEQUENCE OF SEQUENCE { 4215 userCertificate CertificateSerialNumber, 4216 revocationDate Time, 4217 crlEntryExtensions EntryExtensions OPTIONAL } OPTIONAL, 4218 crlExtensions [0] CRLExtensions OPTIONAL }} 4220 CRLExtensions ::= SEQUENCE SIZE (1..MAX) OF CRLExtension 4222 CRLExtension ::= SEQUENCE { 4223 extnId EXTENSION.&id ({CRLExtensionSet}), 4224 critical BOOLEAN DEFAULT FALSE, 4225 extnValue OCTET STRING } 4226 -- contains a DER encoding of a value of type 4227 -- &ExtnType for the 4228 -- extension object identified by extnId -- 4230 -- The following information object set is defined to constrain the 4231 -- set of legal CRL extensions. 4233 CRLExtensionSet EXTENSION ::= { authorityKeyIdentifier | 4234 issuerAltName | 4235 cRLNumber | 4236 deltaCRLIndicator | 4237 issuingDistributionPoint } 4239 -- EXTENSION defined above for certificates 4241 EntryExtensions ::= SEQUENCE SIZE (1..MAX) OF EntryExtension 4243 EntryExtension ::= SEQUENCE { 4244 extnId EXTENSION.&id ({EntryExtensionSet}), 4245 critical BOOLEAN DEFAULT FALSE, 4246 extnValue OCTET STRING } 4247 -- contains a DER encoding of a value of type 4248 -- &ExtnType for the 4249 -- extension object identified by extnId -- 4251 -- The following information object set is defined to constrain the 4252 -- set of legal CRL entry extensions. 4254 EntryExtensionSet EXTENSION ::= { reasonCode | 4255 instructionCode | 4256 invalidityDate | 4257 certificateIssuer } 4259 -- information object classes used in the defintion -- 4260 -- of certificates and CRLs -- 4262 -- Parameterized Type SIGNED -- 4264 SIGNED { ToBeSigned } ::= SEQUENCE { 4265 toBeSigned ToBeSigned, 4266 algorithm AlgorithmIdentifier, 4267 signature BIT STRING 4268 } 4270 -- Definition of AlgorithmIdentifier 4271 -- ISO definition was: 4272 -- 4273 -- AlgorithmIdentifier ::= SEQUENCE { 4274 -- algorithm ALGORITHM.&id({SupportedAlgorithms}), 4275 -- parameters ALGORITHM.&Type({SupportedAlgorithms} 4276 -- { @algorithm}) OPTIONAL } 4277 -- Definition of ALGORITHM 4278 -- ALGORITHM ::= TYPE-IDENTIFIER 4280 -- The following PKIX definition replaces the X.509 definition 4281 -- 4283 AlgorithmIdentifier ::= SEQUENCE { 4284 algorithm ALGORITHM-ID.&id({SupportedAlgorithms}), 4285 parameters ALGORITHM-ID.&Type({SupportedAlgorithms} 4286 { @algorithm}) OPTIONAL } 4288 -- Definition of ALGORITHM-ID 4290 ALGORITHM-ID ::= CLASS { 4291 &id OBJECT IDENTIFIER UNIQUE, 4292 &Type OPTIONAL 4293 } 4294 WITH SYNTAX { OID &id [PARMS &Type] } 4296 -- The definition of SupportedAlgorithms may be modified as this 4297 -- document does not specify a mandatory algorithm set. In addition, 4298 -- the set is specified as extensible, since additional algorithms 4299 -- may be supported 4301 SupportedAlgorithms ALGORITHM-ID ::= { ..., -- extensible 4302 RsaPublicKey | 4303 RsaSHA-1 | 4304 RsaMD5 | 4305 RsaMD2 | 4306 DssPublicKey | 4307 DsaSHA-1 | 4308 Dhpublicnumber } 4310 -- OIDs and parameter structures for ALGORITHM-IDs used 4311 -- in this specification 4313 RsaPublicKey ALGORITHM-ID ::= { OID rsaEncryption PARMS NULL } 4315 RsaSHA-1 ALGORITHM-ID ::= { OID sha1WithRSAEncryption PARMS NULL } 4317 RsaMD5 ALGORITHM-ID ::= { OID md5WithRSAEncryption PARMS NULL } 4319 RsaMD2 ALGORITHM-ID ::= { OID md2WithRSAEncryption PARMS NULL } 4320 DssPublicKey ALGORITHM-ID ::= { OID id-dsa PARMS Dss-Parms } 4322 DsaSHA-1 ALGORITHM-ID ::= { OID id-dsa-with-sha1 PARMS NULL } 4324 DhPublicKey ALGORITHM-ID ::= {OID dhpublicnumber PARMS DomainParameters} 4326 -- algorithm identifiers and parameter structures 4328 pkcs-1 OBJECT IDENTIFIER ::= { 4329 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 } 4331 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } 4333 md2WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 2 } 4335 md5WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 4 } 4337 sha1WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 5 } 4339 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { 4340 iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 3 } 4342 Dss-Sig-Value ::= SEQUENCE { 4343 r INTEGER, 4344 s INTEGER } 4346 dhpublicnumber OBJECT IDENTIFIER ::= { 4347 iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 } 4349 DomainParameters ::= SEQUENCE { 4350 p INTEGER, -- odd prime, p=jq +1 4351 g INTEGER, -- generator, g 4352 q INTEGER, -- factor of p-1 4353 j INTEGER OPTIONAL, -- subgroup factor, j>= 2 4354 validationParms ValidationParms OPTIONAL } 4356 ValidationParms ::= SEQUENCE { 4357 seed BIT STRING, 4358 pgenCounter INTEGER } 4360 id-dsa OBJECT IDENTIFIER ::= { 4361 iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 } 4363 Dss-Parms ::= SEQUENCE { 4364 p INTEGER, 4365 q INTEGER, 4366 g INTEGER } 4367 -- The ASN.1 in this section supports the Name type 4368 -- and the directoryAttribute extension 4370 -- attribute data types -- 4372 Attribute ::= SEQUENCE { 4373 type ATTRIBUTE.&id ({SupportedAttributes}), 4374 values SET SIZE (1 .. MAX) OF ATTRIBUTE.&Type 4375 ({SupportedAttributes}{@type})} 4377 AttributeTypeAndValue ::= SEQUENCE { 4378 type ATTRIBUTE.&id ({SupportedAttributes}), 4379 value ATTRIBUTE.&Type ({SupportedAttributes}{@type})} 4381 -- naming data types -- 4383 Name ::= CHOICE { -- only one possibility for now -- 4384 rdnSequence RDNSequence } 4386 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 4388 RelativeDistinguishedName ::= 4389 SET SIZE (1 .. MAX) OF AttributeTypeAndValue 4391 ID ::= OBJECT IDENTIFIER 4393 -- ATTRIBUTE information object class specification 4394 -- Note: This has been greatly simplified for PKIX !! 4396 ATTRIBUTE ::= CLASS { 4397 &Type, 4398 &id OBJECT IDENTIFIER UNIQUE } 4399 WITH SYNTAX { 4400 WITH SYNTAX &Type ID &id } 4402 -- suggested naming attributes 4403 -- Definition of the following information object set may be 4404 -- augmented to meet local requirements. Note that deleting 4405 -- members of the set may prevent interoperability with 4406 -- conforming implementations. 4408 SupportedAttributes ATTRIBUTE ::= { 4409 name | commonName | surname | givenName | initials | 4410 generationQualifier | dnQualifier | countryName | 4411 localityName | stateOrProvinceName | organizationName | 4412 organizationalUnitName | title | pkcs9email } 4414 name ATTRIBUTE ::= { 4415 WITH SYNTAX DirectoryString { ub-name } 4416 ID id-at-name } 4418 commonName ATTRIBUTE ::= { 4419 WITH SYNTAX DirectoryString {ub-common-name} 4420 ID id-at-commonName } 4422 surname ATTRIBUTE ::= { 4423 WITH SYNTAX DirectoryString {ub-name} 4424 ID id-at-surname } 4426 givenName ATTRIBUTE ::= { 4427 WITH SYNTAX DirectoryString {ub-name} 4428 ID id-at-givenName } 4430 initials ATTRIBUTE ::= { 4431 WITH SYNTAX DirectoryString {ub-name} 4432 ID id-at-initials } 4434 generationQualifier ATTRIBUTE ::= { 4435 WITH SYNTAX DirectoryString {ub-name} 4436 ID id-at-generationQualifier} 4438 dnQualifier ATTRIBUTE ::= { 4439 WITH SYNTAX PrintableString 4440 ID id-at-dnQualifier } 4442 countryName ATTRIBUTE ::= { 4443 WITH SYNTAX PrintableString (SIZE (2)) 4444 -- IS 3166 codes only 4445 ID id-at-countryName } 4447 localityName ATTRIBUTE ::= { 4448 WITH SYNTAX DirectoryString {ub-locality-name} 4449 ID id-at-localityName } 4451 stateOrProvinceName ATTRIBUTE ::= { 4452 WITH SYNTAX DirectoryString {ub-state-name} 4453 ID id-at-stateOrProvinceName } 4455 organizationName ATTRIBUTE ::= { 4456 WITH SYNTAX DirectoryString {ub-organization-name} 4457 ID id-at-organizationName } 4459 organizationalUnitName ATTRIBUTE ::= { 4460 WITH SYNTAX DirectoryString {ub-organizational-unit-name} 4461 ID id-at-organizationalUnitName } 4463 title ATTRIBUTE ::= { 4464 WITH SYNTAX DirectoryString {ub-title} 4465 ID id-at-title } 4467 -- Legacy attributes 4469 pkcs9email ATTRIBUTE ::= { 4470 WITH SYNTAX PHGString, 4471 ID emailAddress } 4473 PHGString ::= IA5String (SIZE(1..ub-emailaddress-length)) 4475 pkcs-9 OBJECT IDENTIFIER ::= 4476 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 } 4478 emailAddress OBJECT IDENTIFIER ::= { pkcs-9 1 } 4480 -- object identifiers for Name type and directory attribute support 4482 -- Object identifier assignments -- 4484 id-at OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 4} 4486 -- Attributes -- 4488 id-at-commonName OBJECT IDENTIFIER ::= {id-at 3} 4489 id-at-surname OBJECT IDENTIFIER ::= {id-at 4} 4490 id-at-countryName OBJECT IDENTIFIER ::= {id-at 6} 4491 id-at-localityName OBJECT IDENTIFIER ::= {id-at 7} 4492 id-at-stateOrProvinceName OBJECT IDENTIFIER ::= {id-at 8} 4493 id-at-organizationName OBJECT IDENTIFIER ::= {id-at 10} 4494 id-at-organizationalUnitName OBJECT IDENTIFIER ::= {id-at 11} 4495 id-at-title OBJECT IDENTIFIER ::= {id-at 12} 4496 id-at-name OBJECT IDENTIFIER ::= {id-at 41} 4497 id-at-givenName OBJECT IDENTIFIER ::= {id-at 42} 4498 id-at-initials OBJECT IDENTIFIER ::= {id-at 43} 4499 id-at-generationQualifier OBJECT IDENTIFIER ::= {id-at 44} 4500 id-at-dnQualifier OBJECT IDENTIFIER ::= {id-at 46} 4502 -- Directory string type, used extensively in Name types -- 4504 DirectoryString { INTEGER:maxSize } ::= CHOICE { 4505 teletexString TeletexString (SIZE (1..maxSize)), 4506 printableString PrintableString (SIZE (1..maxSize)), 4507 universalString UniversalString (SIZE (1..maxSize)), 4508 bmpString BMPString (SIZE(1..maxSize)), 4509 utf8String UTF8String (SIZE(1..maxSize)) 4510 } 4512 -- End of ASN.1 for Name type and directory attribute support -- 4514 -- The ASN.1 in this section supports X.400 style names -- 4515 -- for implementations that use the x400Address component -- 4516 -- of GeneralName. -- 4518 ORAddress ::= SEQUENCE { 4519 built-in-standard-attributes BuiltInStandardAttributes, 4520 built-in-domain-defined-attributes 4521 BuiltInDomainDefinedAttributes OPTIONAL, 4522 -- see also teletex-domain-defined-attributes 4523 extension-attributes ExtensionAttributes OPTIONAL } 4525 -- The OR-address is semantically absent from the OR-name if the 4526 -- built-in-standard-attribute sequence is empty and the 4527 -- built-in-domain-defined-attributes and extension-attributes are 4528 -- both omitted. 4530 -- Built-in Standard Attributes 4532 BuiltInStandardAttributes ::= SEQUENCE { 4533 country-name CountryName OPTIONAL, 4534 administration-domain-name AdministrationDomainName OPTIONAL, 4535 network-address [0] NetworkAddress OPTIONAL, 4536 -- see also extended-network-address 4537 terminal-identifier [1] TerminalIdentifier OPTIONAL, 4538 private-domain-name [2] PrivateDomainName OPTIONAL, 4539 organization-name [3] OrganizationName OPTIONAL, 4540 -- see also teletex-organization-name 4541 numeric-user-identifier [4] NumericUserIdentifier OPTIONAL, 4542 personal-name [5] PersonalName OPTIONAL, 4543 -- see also teletex-personal-name 4544 organizational-unit-names [6] OrganizationalUnitNames OPTIONAL 4545 -- see also teletex-organizational-unit-names -- } 4547 CountryName ::= [APPLICATION 1] CHOICE { 4548 x121-dcc-code NumericString 4549 (SIZE (ub-country-name-numeric-length)), 4550 iso-3166-alpha2-code PrintableString 4551 (SIZE (ub-country-name-alpha-length)) } 4553 AdministrationDomainName ::= [APPLICATION 2] CHOICE { 4554 numeric NumericString (SIZE (0..ub-domain-name-length)), 4555 printable PrintableString (SIZE (0..ub-domain-name-length)) } 4557 NetworkAddress ::= X121Address 4558 -- see also extended-network-address 4559 X121Address ::= NumericString (SIZE (1..ub-x121-address-length)) 4561 TerminalIdentifier ::= PrintableString (SIZE (1..ub-terminal-id-length)) 4563 PrivateDomainName ::= CHOICE { 4564 numeric NumericString (SIZE (1..ub-domain-name-length)), 4565 printable PrintableString (SIZE (1..ub-domain-name-length)) } 4567 OrganizationName ::= PrintableString 4568 (SIZE (1..ub-organization-name-length)) 4569 -- see also teletex-organization-name 4571 NumericUserIdentifier ::= NumericString 4572 (SIZE (1..ub-numeric-user-id-length)) 4574 PersonalName ::= SET { 4575 surname [0] PrintableString (SIZE (1..ub-surname-length)), 4576 given-name [1] PrintableString 4577 (SIZE (1..ub-given-name-length)) OPTIONAL, 4578 initials [2] PrintableString 4579 (SIZE (1..ub-initials-length)) OPTIONAL, 4580 generation-qualifier [3] PrintableString 4581 (SIZE (1..ub-generation-qualifier-length)) OPTIONAL} 4582 -- see also teletex-personal-name 4584 OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units) 4585 OF OrganizationalUnitName 4586 -- see also teletex-organizational-unit-names 4588 OrganizationalUnitName ::= PrintableString (SIZE 4589 (1..ub-organizational-unit-name-length)) 4591 -- Built-in Domain-defined Attributes 4592 BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE 4593 (1..ub-domain-defined-attributes) OF 4594 BuiltInDomainDefinedAttribute 4596 BuiltInDomainDefinedAttribute ::= SEQUENCE { 4597 type PrintableString (SIZE 4598 (1..ub-domain-defined-attribute-type-length)), 4599 value PrintableString (SIZE 4600 (1..ub-domain-defined-attribute-value-length)) } 4602 -- Extension Attributes 4604 ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) 4605 OF ExtensionAttribute 4606 ExtensionAttribute ::= SEQUENCE { 4607 extension-attribute-type [0] EXTENSION-ATTRIBUTE.&id 4608 ({ExtensionAttributeTable}), 4609 extension-attribute-value [1] EXTENSION-ATTRIBUTE.&Type 4610 ({ExtensionAttributeTable} {@extension-attribute-type}) } 4612 EXTENSION-ATTRIBUTE ::= CLASS { 4613 &id INTEGER (0..ub-extension-attributes) UNIQUE, 4614 &Type } 4615 WITH SYNTAX {&Type IDENTIFIED BY &id} 4617 ExtensionAttributeTable EXTENSION-ATTRIBUTE ::= { 4618 common-name | 4619 teletex-common-name | 4620 teletex-organization-name | 4621 teletex-personal-name | 4622 teletex-organizational-unit-names | 4623 teletex-domain-defined-attributes | 4624 pds-name | 4625 physical-delivery-country-name | 4626 postal-code | 4627 physical-delivery-office-name | 4628 physical-delivery-office-number | 4629 extension-OR-address-components | 4630 physical-delivery-personal-name | 4631 physical-delivery-organization-name | 4632 extension-physical-delivery-address-components | 4633 unformatted-postal-address | 4634 street-address | 4635 post-office-box-address | 4636 poste-restante-address | 4637 unique-postal-name | 4638 local-postal-attributes | 4639 extended-network-address | 4640 terminal-type } 4642 -- Extension Standard Attributes 4644 common-name EXTENSION-ATTRIBUTE ::= {CommonName IDENTIFIED BY 1} 4646 CommonName ::= PrintableString (SIZE (1..ub-common-name-length)) 4648 teletex-common-name EXTENSION-ATTRIBUTE ::= 4649 {TeletexCommonName IDENTIFIED BY 2} 4651 TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length)) 4653 teletex-organization-name EXTENSION-ATTRIBUTE ::= 4654 {TeletexOrganizationName IDENTIFIED BY 3} 4656 TeletexOrganizationName ::= 4657 TeletexString (SIZE (1..ub-organization-name-length)) 4659 teletex-personal-name EXTENSION-ATTRIBUTE ::= 4660 {TeletexPersonalName IDENTIFIED BY 4} 4662 TeletexPersonalName ::= SET { 4663 surname [0] TeletexString (SIZE (1..ub-surname-length)), 4664 given-name [1] TeletexString 4665 (SIZE (1..ub-given-name-length)) OPTIONAL, 4666 initials [2] TeletexString (SIZE (1..ub-initials-length)) OPTIONAL, 4667 generation-qualifier [3] TeletexString (SIZE 4668 (1..ub-generation-qualifier-length)) OPTIONAL } 4670 teletex-organizational-unit-names EXTENSION-ATTRIBUTE ::= 4671 {TeletexOrganizationalUnitNames IDENTIFIED BY 5} 4673 TeletexOrganizationalUnitNames ::= SEQUENCE SIZE 4674 (1..ub-organizational-units) OF TeletexOrganizationalUnitName 4676 TeletexOrganizationalUnitName ::= TeletexString 4677 (SIZE (1..ub-organizational-unit-name-length)) 4679 pds-name EXTENSION-ATTRIBUTE ::= {PDSName IDENTIFIED BY 7} 4681 PDSName ::= PrintableString (SIZE (1..ub-pds-name-length)) 4683 physical-delivery-country-name EXTENSION-ATTRIBUTE ::= 4684 {PhysicalDeliveryCountryName IDENTIFIED BY 8} 4686 PhysicalDeliveryCountryName ::= CHOICE { 4687 x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)), 4688 iso-3166-alpha2-code PrintableString 4689 (SIZE (ub-country-name-alpha-length)) } 4691 postal-code EXTENSION-ATTRIBUTE ::= {PostalCode IDENTIFIED BY 9} 4693 PostalCode ::= CHOICE { 4694 numeric-code NumericString (SIZE (1..ub-postal-code-length)), 4695 printable-code PrintableString (SIZE (1..ub-postal-code-length)) } 4697 physical-delivery-office-name EXTENSION-ATTRIBUTE ::= 4698 {PhysicalDeliveryOfficeName IDENTIFIED BY 10} 4700 PhysicalDeliveryOfficeName ::= PDSParameter 4702 physical-delivery-office-number EXTENSION-ATTRIBUTE ::= 4703 {PhysicalDeliveryOfficeNumber IDENTIFIED BY 11} 4705 PhysicalDeliveryOfficeNumber ::= PDSParameter 4707 extension-OR-address-components EXTENSION-ATTRIBUTE ::= 4708 {ExtensionORAddressComponents IDENTIFIED BY 12} 4710 ExtensionORAddressComponents ::= PDSParameter 4712 physical-delivery-personal-name EXTENSION-ATTRIBUTE ::= 4713 {PhysicalDeliveryPersonalName IDENTIFIED BY 13} 4715 PhysicalDeliveryPersonalName ::= PDSParameter 4717 physical-delivery-organization-name EXTENSION-ATTRIBUTE ::= 4718 {PhysicalDeliveryOrganizationName IDENTIFIED BY 14} 4720 PhysicalDeliveryOrganizationName ::= PDSParameter 4722 extension-physical-delivery-address-components EXTENSION-ATTRIBUTE ::= 4723 {ExtensionPhysicalDeliveryAddressComponents IDENTIFIED BY 15} 4725 ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter 4727 unformatted-postal-address EXTENSION-ATTRIBUTE ::= 4728 {UnformattedPostalAddress IDENTIFIED BY 16} 4730 UnformattedPostalAddress ::= SET { 4731 printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) OF 4732 PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL, 4733 teletex-string TeletexString (SIZE 4734 (1..ub-unformatted-address-length)) OPTIONAL } 4736 street-address EXTENSION-ATTRIBUTE ::= 4737 {StreetAddress IDENTIFIED BY 17} 4739 StreetAddress ::= PDSParameter 4741 post-office-box-address EXTENSION-ATTRIBUTE ::= 4742 {PostOfficeBoxAddress IDENTIFIED BY 18} 4744 PostOfficeBoxAddress ::= PDSParameter 4746 poste-restante-address EXTENSION-ATTRIBUTE ::= 4747 {PosteRestanteAddress IDENTIFIED BY 19} 4749 PosteRestanteAddress ::= PDSParameter 4751 unique-postal-name EXTENSION-ATTRIBUTE ::= 4752 {UniquePostalName IDENTIFIED BY 20} 4754 UniquePostalName ::= PDSParameter 4756 local-postal-attributes EXTENSION-ATTRIBUTE ::= 4757 {LocalPostalAttributes IDENTIFIED BY 21} 4759 LocalPostalAttributes ::= PDSParameter 4761 PDSParameter ::= SET { 4762 printable-string PrintableString 4763 (SIZE(1..ub-pds-parameter-length)) OPTIONAL, 4764 teletex-string TeletexString 4765 (SIZE(1..ub-pds-parameter-length)) OPTIONAL } 4767 extended-network-address EXTENSION-ATTRIBUTE ::= 4768 {ExtendedNetworkAddress IDENTIFIED BY 22} 4770 ExtendedNetworkAddress ::= CHOICE { 4771 e163-4-address SEQUENCE { 4772 number [0] NumericString 4773 (SIZE (1..ub-e163-4-number-length)), 4774 sub-address [1] NumericString 4775 (SIZE (1..ub-e163-4-sub-address-length)) OPTIONAL}, 4776 psap-address [0] PresentationAddress } 4778 PresentationAddress ::= SEQUENCE { 4779 pSelector [0] EXPLICIT OCTET STRING OPTIONAL, 4780 sSelector [1] EXPLICIT OCTET STRING OPTIONAL, 4781 tSelector [2] EXPLICIT OCTET STRING OPTIONAL, 4782 nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING} 4784 terminal-type EXTENSION-ATTRIBUTE ::= {TerminalType IDENTIFIED BY 23} 4786 TerminalType ::= INTEGER { 4787 telex (3), 4788 teletex (4), 4789 g3-facsimile (5), 4790 g4-facsimile (6), 4791 ia5-terminal (7), 4792 videotex (8) } (0..ub-integer-options) 4794 -- Extension Domain-defined Attributes 4796 teletex-domain-defined-attributes EXTENSION-ATTRIBUTE ::= 4797 {TeletexDomainDefinedAttributes IDENTIFIED BY 6} 4799 TeletexDomainDefinedAttributes ::= SEQUENCE SIZE 4800 (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute 4802 TeletexDomainDefinedAttribute ::= SEQUENCE { 4803 type TeletexString 4804 (SIZE (1..ub-domain-defined-attribute-type-length)), 4805 value TeletexString 4806 (SIZE (1..ub-domain-defined-attribute-value-length)) } 4808 -- specifications of Upper Bounds 4809 -- must be regarded as mandatory 4810 -- from Annex B of ITU-T X.411 4811 -- Reference Definition of MTS Parameter Upper Bounds 4813 -- Upper Bounds 4814 ub-name INTEGER ::= 32768 4815 ub-common-name INTEGER ::= 64 4816 ub-locality-name INTEGER ::= 128 4817 ub-state-name INTEGER ::= 128 4818 ub-organization-name INTEGER ::= 64 4819 ub-organizational-unit-name INTEGER ::= 64 4820 ub-title INTEGER ::= 64 4821 ub-match INTEGER ::= 128 4823 ub-emailaddress-length INTEGER ::= 128 4825 ub-common-name-length INTEGER ::= 64 4826 ub-country-name-alpha-length INTEGER ::= 2 4827 ub-country-name-numeric-length INTEGER ::= 3 4828 ub-domain-defined-attributes INTEGER ::= 4 4829 ub-domain-defined-attribute-type-length INTEGER ::= 8 4830 ub-domain-defined-attribute-value-length INTEGER ::= 128 4831 ub-domain-name-length INTEGER ::= 16 4832 ub-extension-attributes INTEGER ::= 256 4833 ub-e163-4-number-length INTEGER ::= 15 4834 ub-e163-4-sub-address-length INTEGER ::= 40 4835 ub-generation-qualifier-length INTEGER ::= 3 4836 ub-given-name-length INTEGER ::= 16 4837 ub-initials-length INTEGER ::= 5 4838 ub-integer-options INTEGER ::= 256 4839 ub-numeric-user-id-length INTEGER ::= 32 4840 ub-organization-name-length INTEGER ::= 64 4841 ub-organizational-unit-name-length INTEGER ::= 32 4842 ub-organizational-units INTEGER ::= 4 4843 ub-pds-name-length INTEGER ::= 16 4844 ub-pds-parameter-length INTEGER ::= 30 4845 ub-pds-physical-address-lines INTEGER ::= 6 4846 ub-postal-code-length INTEGER ::= 16 4847 ub-surname-length INTEGER ::= 40 4848 ub-terminal-id-length INTEGER ::= 24 4849 ub-unformatted-address-length INTEGER ::= 180 4850 ub-x121-address-length INTEGER ::= 16 4852 -- Note - upper bounds on TeletexString are measured in characters. 4853 -- A significantly greater number of octets will be required to hold 4854 -- such a value. As a minimum, 16 octets, or twice the specified upper 4855 -- bound, whichever is the larger, should be allowed. 4857 END 4858 B.2 1993 Implicitly Tagged Module 4860 PKIX1Implicit93 {iso(1) identified-organization(3) dod(6) internet(1) 4861 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-93(4)} 4863 DEFINITIONS IMPLICIT TAGS::= 4865 BEGIN 4867 --EXPORTS ALL -- 4869 IMPORTS 4870 id-pe, id-qt, id-kp, id-ad, id-qt-unotice, 4871 ORAddress, Name, RelativeDistinguishedName, 4872 CertificateSerialNumber, CertificateList, 4873 AlgorithmIdentifier, ub-name, DirectoryString, Attribute, 4874 EXTENSION 4875 FROM PKIX1Explicit93 {iso(1) identified-organization(3) 4876 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 4877 id-mod(0) id-pkix1-explicit-93(3)}; 4879 -- Key and policy information extensions -- 4881 authorityKeyIdentifier EXTENSION ::= { 4882 SYNTAX AuthorityKeyIdentifier 4883 IDENTIFIED BY id-ce-authorityKeyIdentifier } 4885 AuthorityKeyIdentifier ::= SEQUENCE { 4886 keyIdentifier [0] KeyIdentifier OPTIONAL, 4887 authorityCertIssuer [1] GeneralNames OPTIONAL, 4888 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 4889 ( WITH COMPONENTS {..., authorityCertIssuer PRESENT, 4890 authorityCertSerialNumber PRESENT} | 4891 WITH COMPONENTS {..., authorityCertIssuer ABSENT, 4892 authorityCertSerialNumber ABSENT} ) 4894 KeyIdentifier ::= OCTET STRING 4896 subjectKeyIdentifier EXTENSION ::= { 4897 SYNTAX SubjectKeyIdentifier 4898 IDENTIFIED BY id-ce-subjectKeyIdentifier } 4900 SubjectKeyIdentifier ::= KeyIdentifier 4902 keyUsage EXTENSION ::= { 4903 SYNTAX KeyUsage 4904 IDENTIFIED BY id-ce-keyUsage } 4906 KeyUsage ::= BIT STRING { 4907 digitalSignature (0), 4908 nonRepudiation (1), 4909 keyEncipherment (2), 4910 dataEncipherment (3), 4911 keyAgreement (4), 4912 keyCertSign (5), 4913 cRLSign (6) } 4915 extendedKeyUsage EXTENSION ::= { 4916 SYNTAX SEQUENCE SIZE (1..MAX) OF KeyPurposeId 4917 IDENTIFIED BY id-ce-extKeyUsage } 4919 KeyPurposeId ::= OBJECT IDENTIFIER 4921 -- PKIX-defined extended key purpose OIDs 4922 id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } 4923 id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } 4924 id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } 4925 id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } 4926 id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 } 4927 id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 } 4928 id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 } 4929 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 4931 privateKeyUsagePeriod EXTENSION ::= { 4932 SYNTAX PrivateKeyUsagePeriod 4933 IDENTIFIED BY { id-ce-privateKeyUsagePeriod } } 4935 PrivateKeyUsagePeriod ::= SEQUENCE { 4936 notBefore [0] GeneralizedTime OPTIONAL, 4937 notAfter [1] GeneralizedTime OPTIONAL } 4938 ( WITH COMPONENTS {..., notBefore PRESENT} | 4939 WITH COMPONENTS {..., notAfter PRESENT} ) 4941 certificatePolicies EXTENSION ::= { 4942 SYNTAX CertificatePoliciesSyntax 4943 IDENTIFIED BY id-ce-certificatePolicies } 4945 CertificatePoliciesSyntax ::= 4946 SEQUENCE SIZE (1..MAX) OF PolicyInformation 4948 PolicyInformation ::= SEQUENCE { 4949 policyIdentifier CertPolicyId, 4950 policyQualifiers SEQUENCE SIZE (1..MAX) OF 4951 PolicyQualifierInfo OPTIONAL } 4953 CertPolicyId ::= OBJECT IDENTIFIER 4954 PolicyQualifierInfo ::= SEQUENCE { 4955 policyQualifierId CERT-POLICY-QUALIFIER.&id 4956 ({SupportedPolicyQualifiers}), 4957 qualifier CERT-POLICY-QUALIFIER.&Qualifier 4958 ({SupportedPolicyQualifiers} 4959 {@policyQualifierId})OPTIONAL } 4961 SupportedPolicyQualifiers CERT-POLICY-QUALIFIER ::= { noticeToUser | 4962 pointerToCPS } 4964 CERT-POLICY-QUALIFIER ::= CLASS { 4965 &id OBJECT IDENTIFIER UNIQUE, 4966 &Qualifier OPTIONAL } 4967 WITH SYNTAX { 4968 POLICY-QUALIFIER-ID &id 4969 [QUALIFIER-TYPE &Qualifier] } 4971 policyMappings EXTENSION ::= { 4972 SYNTAX PolicyMappingsSyntax 4973 IDENTIFIED BY id-ce-policyMappings } 4975 PolicyMappingsSyntax ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 4976 issuerDomainPolicy CertPolicyId, 4977 subjectDomainPolicy CertPolicyId } 4979 -- Certificate subject and certificate issuer attributes extensions -- 4981 subjectAltName EXTENSION ::= { 4982 SYNTAX GeneralNames 4983 IDENTIFIED BY id-ce-subjectAltName } 4985 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 4987 GeneralName ::= CHOICE { 4988 otherName [0] INSTANCE OF OTHER-NAME, 4989 rfc822Name [1] IA5String, 4990 dNSName [2] IA5String, 4991 x400Address [3] ORAddress, 4992 directoryName [4] Name, 4993 ediPartyName [5] EDIPartyName, 4994 uniformResourceIdentifier [6] IA5String, 4995 iPAddress [7] OCTET STRING, 4996 registeredID [8] OBJECT IDENTIFIER } 4998 OTHER-NAME ::= TYPE-IDENTIFIER 5000 EDIPartyName ::= SEQUENCE { 5001 nameAssigner [0] DirectoryString {ub-name} OPTIONAL, 5002 partyName [1] DirectoryString {ub-name} } 5004 issuerAltName EXTENSION ::= { 5005 SYNTAX GeneralNames 5006 IDENTIFIED BY id-ce-issuerAltName } 5008 subjectDirectoryAttributes EXTENSION ::= { 5009 SYNTAX AttributesSyntax 5010 IDENTIFIED BY id-ce-subjectDirectoryAttributes } 5012 AttributesSyntax ::= SEQUENCE SIZE (1..MAX) OF Attribute 5014 -- Certification path constraints extensions -- 5016 basicConstraints EXTENSION ::= { 5017 SYNTAX BasicConstraintsSyntax 5018 IDENTIFIED BY id-ce-basicConstraints } 5020 BasicConstraintsSyntax ::= SEQUENCE { 5021 cA BOOLEAN DEFAULT FALSE, 5022 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 5024 nameConstraints EXTENSION ::= { 5025 SYNTAX NameConstraintsSyntax 5026 IDENTIFIED BY id-ce-nameConstraints } 5028 NameConstraintsSyntax ::= SEQUENCE { 5029 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 5030 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 5032 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 5034 GeneralSubtree ::= SEQUENCE { 5035 base GeneralName, 5036 minimum [0] BaseDistance DEFAULT 0, 5037 maximum [1] BaseDistance OPTIONAL } 5039 BaseDistance ::= INTEGER (0..MAX) 5041 policyConstraints EXTENSION ::= { 5042 SYNTAX PolicyConstraintsSyntax 5043 IDENTIFIED BY id-ce-policyConstraints } 5045 PolicyConstraintsSyntax ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 5046 requireExplicitPolicy [0] SkipCerts OPTIONAL, 5047 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 5049 SkipCerts ::= INTEGER (0..MAX) 5050 -- Basic CRL extensions -- 5052 cRLNumber EXTENSION ::= { 5053 SYNTAX CRLNumber 5054 IDENTIFIED BY id-ce-cRLNumber } 5056 CRLNumber ::= INTEGER (0..MAX) 5058 reasonCode EXTENSION ::= { 5059 SYNTAX CRLReason 5060 IDENTIFIED BY id-ce-reasonCode } 5062 CRLReason ::= ENUMERATED { 5063 unspecified (0), 5064 keyCompromise (1), 5065 cACompromise (2), 5066 affiliationChanged (3), 5067 superseded (4), 5068 cessationOfOperation (5), 5069 certificateHold (6), 5070 removeFromCRL (8) } 5072 instructionCode EXTENSION ::= { 5073 SYNTAX HoldInstruction 5074 IDENTIFIED BY id-ce-instructionCode } 5076 HoldInstruction ::= OBJECT IDENTIFIER 5078 -- holdinstructions described in this specification, from ANSI x9 5080 -- ANSI x9 arc holdinstruction arc 5081 holdInstruction OBJECT IDENTIFIER ::= { 5082 joint-iso-ccitt(2) member-body(2) us(840) x9cm(10040) 2} 5084 -- ANSI X9 holdinstructions referenced by this standard 5085 id-holdinstruction-none OBJECT IDENTIFIER ::= {holdInstruction 1} 5086 id-holdinstruction-callissuer OBJECT IDENTIFIER ::= {holdInstruction 2} 5087 id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3} 5089 invalidityDate EXTENSION ::= { 5090 SYNTAX GeneralizedTime 5091 IDENTIFIED BY id-ce-invalidityDate } 5093 -- CRL distribution points and delta-CRL extensions -- 5095 cRLDistributionPoints EXTENSION ::= { 5096 SYNTAX CRLDistPointsSyntax 5097 IDENTIFIED BY id-ce-cRLDistributionPoints } 5099 CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 5101 DistributionPoint ::= SEQUENCE { 5102 distributionPoint [0] DistributionPointName OPTIONAL, 5103 reasons [1] ReasonFlags OPTIONAL, 5104 cRLIssuer [2] GeneralNames OPTIONAL } 5106 DistributionPointName ::= CHOICE { 5107 fullName [0] GeneralNames, 5108 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 5110 ReasonFlags ::= BIT STRING { 5111 unused (0), 5112 keyCompromise (1), 5113 caCompromise (2), 5114 affiliationChanged (3), 5115 superseded (4), 5116 cessationOfOperation (5), 5117 certificateHold (6) } 5119 issuingDistributionPoint EXTENSION ::= { 5120 SYNTAX IssuingDistPointSyntax 5121 IDENTIFIED BY id-ce-issuingDistributionPoint } 5123 IssuingDistPointSyntax ::= SEQUENCE { 5124 distributionPoint [0] DistributionPointName OPTIONAL, 5125 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 5126 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 5127 onlySomeReasons [3] ReasonFlags OPTIONAL, 5128 indirectCRL [4] BOOLEAN DEFAULT FALSE } 5130 certificateIssuer EXTENSION ::= { 5131 SYNTAX GeneralNames 5132 IDENTIFIED BY id-ce-certificateIssuer } 5134 deltaCRLIndicator EXTENSION ::= { 5135 SYNTAX BaseCRLNumber 5136 IDENTIFIED BY id-ce-deltaCRLIndicator } 5138 BaseCRLNumber ::= CRLNumber 5140 -- Object identifier assignments for ISO certificate extensions -- 5141 id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 5143 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= {id-ce 9} 5144 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= {id-ce 14} 5145 id-ce-keyUsage OBJECT IDENTIFIER ::= {id-ce 15} 5146 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= {id-ce 16} 5147 id-ce-subjectAltName OBJECT IDENTIFIER ::= {id-ce 17} 5148 id-ce-issuerAltName OBJECT IDENTIFIER ::= {id-ce 18} 5149 id-ce-basicConstraints OBJECT IDENTIFIER ::= {id-ce 19} 5150 id-ce-cRLNumber OBJECT IDENTIFIER ::= {id-ce 20} 5151 id-ce-reasonCode OBJECT IDENTIFIER ::= {id-ce 21} 5152 id-ce-instructionCode OBJECT IDENTIFIER ::= {id-ce 23} 5153 id-ce-invalidityDate OBJECT IDENTIFIER ::= {id-ce 24} 5154 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= {id-ce 27} 5155 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= {id-ce 28} 5156 id-ce-certificateIssuer OBJECT IDENTIFIER ::= {id-ce 29} 5157 id-ce-nameConstraints OBJECT IDENTIFIER ::= {id-ce 30} 5158 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31} 5159 id-ce-certificatePolicies OBJECT IDENTIFIER ::= {id-ce 32} 5160 id-ce-policyMappings OBJECT IDENTIFIER ::= {id-ce 33} 5161 id-ce-policyConstraints OBJECT IDENTIFIER ::= {id-ce 36} 5162 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= {id-ce 35} 5163 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 5165 -- PKIX 1 extensions 5167 authorityInfoAccess EXTENSION ::= { 5168 SYNTAX AuthorityInfoAccessSyntax 5169 IDENTIFIED BY id-pe-authorityInfoAccess } 5171 AuthorityInfoAccessSyntax ::= 5172 SEQUENCE SIZE (1..MAX) OF AccessDescription 5174 AccessDescription ::= SEQUENCE { 5175 accessMethod OBJECT IDENTIFIER, 5176 accessLocation GeneralName } 5178 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 5180 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 5182 -- PKIX policy qualifier definitions 5184 noticeToUser CERT-POLICY-QUALIFIER ::= { 5185 POLICY-QUALIFIER-ID id-qt-cps QUALIFIER-TYPE CPSuri} 5187 pointerToCPS CERT-POLICY-QUALIFIER ::= { 5188 POLICY-QUALIFIER-ID id-qt-unotice QUALIFIER-TYPE UserNotice} 5190 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 5191 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 5193 CPSuri ::= IA5String 5194 UserNotice ::= SEQUENCE { 5195 noticeRef NoticeReference OPTIONAL, 5196 explicitText DisplayText OPTIONAL} 5198 NoticeReference ::= SEQUENCE { 5199 organization DisplayText, 5200 noticeNumbers SEQUENCE OF INTEGER } 5202 DisplayText ::= CHOICE { 5203 visibleString VisibleString (SIZE (1..200)), 5204 bmpString BMPString (SIZE (1..200)), 5205 utf8String UTF8String (SIZE (1..200)) } 5207 END 5209 Appendix C. ASN.1 Notes 5211 The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 5212 constructs. A valid ASN.1 sequence will have zero or more entries. 5213 The SIZE (1..MAX) construct constrains the sequence to have at least 5214 one entry. MAX indicates the upper bound is unspecified. Implementa- 5215 tions are free to choose an upper bound that suits their environment. 5217 The construct "positiveInt ::= INTEGER (0..MAX)" defines positiveInt 5218 as a subtype of INTEGER containing integers greater than or equal to 5219 zero. The upper bound is unspecified. Implementations are free to 5220 select an upper bound that suits their environment. 5222 The character string type PrintableString supports a very basic Latin 5223 character set: the lower case letters 'a' through 'z', upper case 5224 letters 'A' through 'Z', the digits '0' through '9', eleven special 5225 characters ' " ( ) + , - . / : ? and space. 5227 The character string type TeletexString is a superset of Printable- 5228 String. TeletexString supports a fairly standard (ascii-like) Latin 5229 character set, Latin characters with non-spacing accents and Japanese 5230 characters. 5232 The character string type UniversalString supports any of the charac- 5233 ters allowed by ISO 10646-1. ISO 10646 is the Universal multiple- 5234 octet coded Character Set (UCS). ISO 10646-1 specifes the architec- 5235 ture and the "basic multilingual plane" - a large standard character 5236 set which includes all major world character standards. 5238 The character string type UTF8String will be introduced in the 1998 5239 version of ASN.1. UTF8String is a universal type and has been 5240 assigned tag number 12. The content of UTF8String was defined by RFC 5241 2044 and updated in RFC 2279, "UTF-8, a transformation Format of ISP 5242 10646." ISO is expected to formally add UTF8String to the list of 5243 choices for DirectoryString in 1998 as well. 5245 In anticipation of these changes, and in conformance with IETF Best 5246 Practices codified in RFC 2277, IETF Policy on Character Sets and 5247 Languages, this document includes UTF8String as a choice in Directo- 5248 ryString and the CPS qualifier extensions. 5250 Appendix D. Examples 5252 This section contains four examples: three certificates and a CRL. 5253 The first two certificates and the CRL comprise a minimal certifica- 5254 tion path. 5256 Section D.1 contains two annotated hex dumps of a "self-signed" cer- 5257 tificate issued by a CA whose distinguished name is 5258 cn=us,o=gov,ou=nist. The certificate contains a DSA public key with 5259 parameters, and is signed by the corresponding DSA private key. The 5260 first hex dump is a basic dump of the ASN.1 encoding and does not not 5261 reflect the fact that the object is a certificate. The second dump 5262 identfies the values of the various certificate fields. 5264 Section D.2 contains an annotated hex dump of an end-entity certifi- 5265 cate. The end entity certificate contains a DSA public key, and is 5266 signed by the private key corresponding to the "self-signed" certifi- 5267 cate in section D.1. The first hex dump is a basic dump of the 5268 ASN.1 encoding and does not not reflect the fact that the object is a 5269 certificate. The second dump identfies the values of the various cer- 5270 tificate fields. 5272 Section D.3 contains a dump of an end entity certificate which con- 5273 tains an RSA public key and is signed with RSA and MD5. This certi- 5274 ficate is not part of the minimal certification path. 5276 Section D.4 contains an annotated hex dump of a CRL. The CRL is 5277 issued by the CA whose distinguished name is cn=us,o=gov,ou=nist and 5278 the list of revoked certifcates includes the end entity certificate 5279 presented in D.2. The hex dump is a basic dump of the ASN.1 encod- 5280 ing. 5282 D.1 Certificate 5284 This section contains an annotated hex dump of a 662 byte version 3 5285 certificate. The certificate contains the following information: 5286 (a) the serial number is 17 (11 hex); 5287 (b) the certificate is signed with DSA and the SHA-1 hash algorithm; 5288 (c) the issuer's distinguished name is OU=nist;O=gov;C=US 5289 (d) and the subject's distinguished name is OU=nist;O=gov;C=US 5290 (e) the certificate was issued on June 30, 1997 and will expire on 5291 December 31, 1997; 5292 (f) the certificate contains a 1024 bit DSA public key with parame- 5293 ters; and 5294 (g) the certificate is a CA certificate (as indicated through the 5295 basic constraints extension.) 5297 D.1.1 ASN.1 Dump of "Self-Signed" Certificate 5299 0000 30 82 02 92 658: SEQUENCE 5300 0004 30 82 02 52 594: . SEQUENCE 5301 0008 a0 03 3: . . [0] 5302 0010 02 01 1: . . . INTEGER 2 5303 0013 02 01 1: . . INTEGER 17 5304 0016 30 09 9: . . SEQUENCE 5305 0018 06 07 7: . . . OID 1.2.840.10040.4.3: dsa-with-sha 5306 0027 30 2a 42: . . SEQUENCE 5307 0029 31 0b 11: . . . SET 5308 0031 30 09 9: . . . . SEQUENCE 5309 0033 06 03 3: . . . . . OID 2.5.4.6: C 5310 0038 13 02 2: . . . . . PrintableString 'US' 5311 0042 31 0c 12: . . . SET 5312 0044 30 0a 10: . . . . SEQUENCE 5313 0046 06 03 3: . . . . . OID 2.5.4.10: O 5314 0051 13 03 3: . . . . . PrintableString 'gov' 5315 0056 31 0d 13: . . . SET 5316 0058 30 0b 11: . . . . SEQUENCE 5317 0060 06 03 3: . . . . . OID 2.5.4.11: OU 5318 0065 13 04 4: . . . . . PrintableString 'nist' 5319 0071 30 1e 30: . . SEQUENCE 5320 0073 17 0d 13: . . . UTCTime '970630000000Z' 5321 0088 17 0d 13: . . . UTCTime '971231000000Z' 5322 0103 30 2a 42: . . SEQUENCE 5323 0105 31 0b 11: . . . SET 5324 0107 30 09 9: . . . . SEQUENCE 5325 0109 06 03 3: . . . . . OID 2.5.4.6: C 5326 0114 13 02 2: . . . . . PrintableString 'US' 5327 0118 31 0c 12: . . . SET 5328 0120 30 0a 10: . . . . SEQUENCE 5329 0122 06 03 3: . . . . . OID 2.5.4.10: O 5330 0127 13 03 3: . . . . . PrintableString 'gov' 5331 0132 31 0d 13: . . . SET 5332 0134 30 0b 11: . . . . SEQUENCE 5333 0136 06 03 3: . . . . . OID 2.5.4.11: OU 5334 0141 13 04 4: . . . . . PrintableString 'nist' 5335 0147 30 82 01 b4 436: . . SEQUENCE 5336 0151 30 82 01 29 297: . . . SEQUENCE 5337 0155 06 07 7: . . . . OID 1.2.840.10040.4.1: dsa 5338 0164 30 82 01 1c 284: . . . . SEQUENCE 5339 0168 02 81 80 128: . . . . . INTEGER 5340 : d4 38 02 c5 35 7b d5 0b a1 7e 5d 72 59 63 55 d3 5341 : 45 56 ea e2 25 1a 6b c5 a4 ab aa 0b d4 62 b4 d2 5342 : 21 b1 95 a2 c6 01 c9 c3 fa 01 6f 79 86 83 3d 03 5343 : 61 e1 f1 92 ac bc 03 4e 89 a3 c9 53 4a f7 e2 a6 5344 : 48 cf 42 1e 21 b1 5c 2b 3a 7f ba be 6b 5a f7 0a 5345 : 26 d8 8e 1b eb ec bf 1e 5a 3f 45 c0 bd 31 23 be 5346 : 69 71 a7 c2 90 fe a5 d6 80 b5 24 dc 44 9c eb 4d 5347 : f9 da f0 c8 e8 a2 4c 99 07 5c 8e 35 2b 7d 57 8d 5348 0299 02 14 20: . . . . . INTEGER 5349 : a7 83 9b f3 bd 2c 20 07 fc 4c e7 e8 9f f3 39 83 5350 : 51 0d dc dd 5351 0321 02 81 80 128: . . . . . INTEGER 5352 : 0e 3b 46 31 8a 0a 58 86 40 84 e3 a1 22 0d 88 ca 5353 : 90 88 57 64 9f 01 21 e0 15 05 94 24 82 e2 10 90 5354 : d9 e1 4e 10 5c e7 54 6b d4 0c 2b 1b 59 0a a0 b5 5355 : a1 7d b5 07 e3 65 7c ea 90 d8 8e 30 42 e4 85 bb 5356 : ac fa 4e 76 4b 78 0e df 6c e5 a6 e1 bd 59 77 7d 5357 : a6 97 59 c5 29 a7 b3 3f 95 3e 9d f1 59 2d f7 42 5358 : 87 62 3f f1 b8 6f c7 3d 4b b8 8d 74 c4 ca 44 90 5359 : cf 67 db de 14 60 97 4a d1 f7 6d 9e 09 94 c4 0d 5360 0452 03 81 84 132: . . . BIT STRING (0 unused bits) 5361 : 02 81 80 aa 98 ea 13 94 a2 db f1 5b 7f 98 2f 78 5362 : e7 d8 e3 b9 71 86 f6 80 2f 40 39 c3 da 3b 4b 13 5363 : 46 26 ee 0d 56 c5 a3 3a 39 b7 7d 33 c2 6b 5c 77 5364 : 92 f2 55 65 90 39 cd 1a 3c 86 e1 32 eb 25 bc 91 5365 : c4 ff 80 4f 36 61 bd cc e2 61 04 e0 7e 60 13 ca 5366 : c0 9c dd e0 ea 41 de 33 c1 f1 44 a9 bc 71 de cf 5367 : 59 d4 6e da 44 99 3c 21 64 e4 78 54 9d d0 7b ba 5368 : 4e f5 18 4d 5e 39 30 bf e0 d1 f6 f4 83 25 4f 14 5369 : aa 71 e1 5370 0587 a3 0d 13: . . [3] 5371 0589 30 0b 11: . . . SEQUENCE 5372 0591 30 09 9: . . . . SEQUENCE 5373 0593 06 03 3: . . . . . OID 2.5.29.19: basicConstraints 5374 0598 04 02 2: . . . . . OCTET STRING 5375 : 30 00 5376 0602 30 09 9: . SEQUENCE 5377 0604 06 07 7: . . OID 1.2.840.10040.4.3: dsa-with-sha 5378 0613 03 2f 47: . BIT STRING (0 unused bits) 5379 : 30 2c 02 14 a0 66 c1 76 33 99 13 51 8d 93 64 2f 5380 : ca 13 73 de 79 1a 7d 33 02 14 5d 90 f6 ce 92 4a 5381 : bf 29 11 24 80 28 a6 5a 8e 73 b6 76 02 68 5383 D.1.2 Pretty Print of "Self-Signed" Certificate 5385 Version: v3 5386 Serial Number: 17 5387 Signature Alg: dsa-with-sha (1.2.840.10040.4.3) 5388 Issuer: C=US, O=gov, OU=nist 5389 Validity: from 970630000000Z 5390 to 971231000000Z 5391 Subject: OU=nist, O=gov, C=US 5392 SubjectPKInfo: dsa (1.2.840.10040.4.1) 5393 params: 5394 02 81 80 d4 38 02 c5 35 7b d5 0b a1 7e 5d 72 59 5395 63 55 d3 45 56 ea e2 25 1a 6b c5 a4 ab aa 0b d4 5396 62 b4 d2 21 b1 95 a2 c6 01 c9 c3 fa 01 6f 79 86 5397 83 3d 03 61 e1 f1 92 ac bc 03 4e 89 a3 c9 53 4a 5398 f7 e2 a6 48 cf 42 1e 21 b1 5c 2b 3a 7f ba be 6b 5399 5a f7 0a 26 d8 8e 1b eb ec bf 1e 5a 3f 45 c0 bd 5400 31 23 be 69 71 a7 c2 90 fe a5 d6 80 b5 24 dc 44 5401 9c eb 4d f9 da f0 c8 e8 a2 4c 99 07 5c 8e 35 2b 5402 7d 57 8d 02 14 a7 83 9b f3 bd 2c 20 07 fc 4c e7 5403 e8 9f f3 39 83 51 0d dc dd 02 81 80 0e 3b 46 31 5404 8a 0a 58 86 40 84 e3 a1 22 0d 88 ca 90 88 57 64 5405 9f 01 21 e0 15 05 94 24 82 e2 10 90 d9 e1 4e 10 5406 5c e7 54 6b d4 0c 2b 1b 59 0a a0 b5 a1 7d b5 07 5407 e3 65 7c ea 90 d8 8e 30 42 e4 85 bb ac fa 4e 76 5408 4b 78 0e df 6c e5 a6 e1 bd 59 77 7d a6 97 59 c5 5409 29 a7 b3 3f 95 3e 9d f1 59 2d f7 42 87 62 3f f1 5410 b8 6f c7 3d 4b b8 8d 74 c4 ca 44 90 cf 67 db de 5411 14 60 97 4a d1 f7 6d 9e 09 94 c4 0d 5412 Public Key: 5413 00 02 81 80 aa 98 ea 13 94 a2 db f1 5b 7f 98 2f 5414 78 e7 d8 e3 b9 71 86 f6 80 2f 40 39 c3 da 3b 4b 5415 13 46 26 ee 0d 56 c5 a3 3a 39 b7 7d 33 c2 6b 5c 5416 77 92 f2 55 65 90 39 cd 1a 3c 86 e1 32 eb 25 bc 5417 91 c4 ff 80 4f 36 61 bd cc e2 61 04 e0 7e 60 13 5418 ca c0 9c dd e0 ea 41 de 33 c1 f1 44 a9 bc 71 de 5419 cf 59 d4 6e da 44 99 3c 21 64 e4 78 54 9d d0 7b 5420 ba 4e f5 18 4d 5e 39 30 bf e0 d1 f6 f4 83 25 4f 5421 14 aa 71 e1 5422 issuerUID: 5423 subjectUID: 5424 1 extensions: 5425 Exten 1: basicConstraints (2.5.29.19) 5426 30 00 5427 Signature Alg: dsa-with-sha (1.2.840.10040.4.3) 5428 Sig Value: 368 bits: 5429 30 2c 02 14 a0 66 c1 76 33 99 13 51 8d 93 64 2f 5430 ca 13 73 de 79 1a 7d 33 02 14 5d 90 f6 ce 92 4a 5431 bf 29 11 24 80 28 a6 5a 8e 73 b6 76 02 68 5433 D.2 Certificate 5435 This section contains an annotated hex dump of a 697 byte version 3 5436 certificate. The certificate contains the following information: 5437 (a) the serial number is 18 (12 hex); 5438 (b) the certificate is signed with DSA and the SHA-1 hash algorithm; 5439 (c) the issuer's distinguished name is OU=nist;O=gov;C=US 5440 (d) and the subject's distinguished name is CN=Tim 5441 Polk;OU=nist;O=gov;C=US 5442 (e) the certificate was valid from July 30, 1997 through December 1, 5443 1997; 5444 (f) the certificate contains a 1024 bit DSA public key; 5445 (g) the certificate is an end entity certificate, as the basic con- 5446 straints extension is not present; 5447 (h) the certificate includes one alternative name - an RFC 822 5448 address. 5450 D.2.1 Basic ASN.1 Dump of "End Entity" Certificate 5452 ---------- 5454 0000 30 82 02 b5 693: SEQUENCE 5455 0004 30 82 02 75 629: . SEQUENCE 5456 0008 a0 03 3: . . [0] 5457 0010 02 01 1: . . . INTEGER 2 5458 0013 02 01 1: . . INTEGER 18 5459 0016 30 09 9: . . SEQUENCE 5460 0018 06 07 7: . . . OID 1.2.840.10040.4.3: dsa-with-sha 5461 0027 30 2a 42: . . SEQUENCE 5462 0029 31 0b 11: . . . SET 5463 0031 30 09 9: . . . . SEQUENCE 5464 0033 06 03 3: . . . . . OID 2.5.4.6: C 5465 0038 13 02 2: . . . . . PrintableString 'US' 5466 0042 31 0c 12: . . . SET 5467 0044 30 0a 10: . . . . SEQUENCE 5468 0046 06 03 3: . . . . . OID 2.5.4.10: O 5469 0051 13 03 3: . . . . . PrintableString 'gov' 5470 0056 31 0d 13: . . . SET 5471 0058 30 0b 11: . . . . SEQUENCE 5472 0060 06 03 3: . . . . . OID 2.5.4.11: OU 5473 0065 13 04 4: . . . . . PrintableString 'nist' 5474 0071 30 1e 30: . . SEQUENCE 5475 0073 17 0d 13: . . . UTCTime '970730000000Z' 5476 0088 17 0d 13: . . . UTCTime '971201000000Z' 5477 0103 30 3d 61: . . SEQUENCE 5478 0105 31 0b 11: . . . SET 5479 0107 30 09 9: . . . . SEQUENCE 5480 0109 06 03 3: . . . . . OID 2.5.4.6: C 5481 0114 13 02 2: . . . . . PrintableString 'US' 5482 0118 31 0c 12: . . . SET 5483 0120 30 0a 10: . . . . SEQUENCE 5484 0122 06 03 3: . . . . . OID 2.5.4.10: O 5485 0127 13 03 3: . . . . . PrintableString 'gov' 5486 0132 31 0d 13: . . . SET 5487 0134 30 0b 11: . . . . SEQUENCE 5488 0136 06 03 3: . . . . . OID 2.5.4.11: OU 5489 0141 13 04 4: . . . . . PrintableString 'nist' 5490 0147 31 11 17: . . . SET 5491 0149 30 0f 15: . . . . SEQUENCE 5492 0151 06 03 3: . . . . . OID 2.5.4.3: CN 5493 0156 13 08 8: . . . . . PrintableString 'Tim Polk' 5494 0166 30 82 01 b4 436: . . SEQUENCE 5495 0170 30 82 01 29 297: . . . SEQUENCE 5496 0174 06 07 7: . . . . OID 1.2.840.10040.4.1: dsa 5497 0183 30 82 01 1c 284: . . . . SEQUENCE 5498 0187 02 81 80 128: . . . . . INTEGER 5499 : d4 38 02 c5 35 7b d5 0b a1 7e 5d 72 59 63 55 d3 5500 : 45 56 ea e2 25 1a 6b c5 a4 ab aa 0b d4 62 b4 d2 5501 : 21 b1 95 a2 c6 01 c9 c3 fa 01 6f 79 86 83 3d 03 5502 : 61 e1 f1 92 ac bc 03 4e 89 a3 c9 53 4a f7 e2 a6 5503 : 48 cf 42 1e 21 b1 5c 2b 3a 7f ba be 6b 5a f7 0a 5504 : 26 d8 8e 1b eb ec bf 1e 5a 3f 45 c0 bd 31 23 be 5505 : 69 71 a7 c2 90 fe a5 d6 80 b5 24 dc 44 9c eb 4d 5506 : f9 da f0 c8 e8 a2 4c 99 07 5c 8e 35 2b 7d 57 8d 5507 0318 02 14 20: . . . . . INTEGER 5508 : a7 83 9b f3 bd 2c 20 07 fc 4c e7 e8 9f f3 39 83 5509 : 51 0d dc dd 5510 0340 02 81 80 128: . . . . . INTEGER 5511 : 0e 3b 46 31 8a 0a 58 86 40 84 e3 a1 22 0d 88 ca 5512 : 90 88 57 64 9f 01 21 e0 15 05 94 24 82 e2 10 90 5513 : d9 e1 4e 10 5c e7 54 6b d4 0c 2b 1b 59 0a a0 b5 5514 : a1 7d b5 07 e3 65 7c ea 90 d8 8e 30 42 e4 85 bb 5515 : ac fa 4e 76 4b 78 0e df 6c e5 a6 e1 bd 59 77 7d 5516 : a6 97 59 c5 29 a7 b3 3f 95 3e 9d f1 59 2d f7 42 5517 : 87 62 3f f1 b8 6f c7 3d 4b b8 8d 74 c4 ca 44 90 5518 : cf 67 db de 14 60 97 4a d1 f7 6d 9e 09 94 c4 0d 5519 0471 03 81 84 132: . . . BIT STRING (0 unused bits) 5520 : 02 81 80 a8 63 b1 60 70 94 7e 0b 86 08 93 0c 0d 5521 : 08 12 4a 58 a9 af 9a 09 38 54 3b 46 82 fb 85 0d 5522 : 18 8b 2a 77 f7 58 e8 f0 1d d2 18 df fe e7 e9 35 5523 : c8 a6 1a db 8d 3d 3d f8 73 14 a9 0b 39 c7 95 f6 5524 : 52 7d 2d 13 8c ae 03 29 3c 4e 8c b0 26 18 b6 d8 5525 : 11 1f d4 12 0c 13 ce 3f f1 c7 05 4e df e1 fc 44 5526 : fd 25 34 19 4a 81 0d dd 98 42 ac d3 b6 91 0c 7f 5527 : 16 72 a3 a0 8a d7 01 7f fb 9c 93 e8 99 92 c8 42 5528 : 47 c6 43 5529 0606 a3 1d 29: . . [3] 5530 0608 30 1b 27: . . . SEQUENCE 5531 0610 30 19 25: . . . . SEQUENCE 5532 0612 06 03 3: . . . . . OID 2.5.29.17: subjectAltName 5533 0617 04 12 18: . . . . . OCTET STRING 5534 : 30 10 81 0e 77 70 6f 6c 6b 40 6e 69 73 74 2e 67 5535 : 6f 76 5536 0637 30 09 9: . SEQUENCE 5537 0639 06 07 7: . . OID 1.2.840.10040.4.3: dsa-with-sha 5538 0648 03 2f 47: . BIT STRING (0 unused bits) 5539 : 30 2c 02 14 3c 02 e0 ab d9 5d 05 77 75 15 71 58 5540 : 92 29 48 c4 1c 54 df fc 02 14 5b da 53 98 7f c5 5541 : 33 df c6 09 b2 7a e3 6f 97 70 1e 14 ed 94 5543 D.2.2 Pretty Print of "End Entity" Certificate 5545 Version: v3 5546 Serial Number: 18 5547 Signature Alg: dsa-with-sha (1.2.840.10040.4.3) 5548 Issuer: C=US, O=gov, OU=nist 5549 Validity: from 970730000000Z 5550 to 971201000000Z 5551 Subject: CN=Tim Polk, OU=nist, O=gov, C=US 5552 SubjectPKInfo: dsa (1.2.840.10040.4.1) 5553 params: 5554 02 81 80 d4 38 02 c5 35 7b d5 0b a1 7e 5d 72 59 5555 63 55 d3 45 56 ea e2 25 1a 6b c5 a4 ab aa 0b d4 5556 62 b4 d2 21 b1 95 a2 c6 01 c9 c3 fa 01 6f 79 86 5557 83 3d 03 61 e1 f1 92 ac bc 03 4e 89 a3 c9 53 4a 5558 f7 e2 a6 48 cf 42 1e 21 b1 5c 2b 3a 7f ba be 6b 5559 5a f7 0a 26 d8 8e 1b eb ec bf 1e 5a 3f 45 c0 bd 5560 31 23 be 69 71 a7 c2 90 fe a5 d6 80 b5 24 dc 44 5561 9c eb 4d f9 da f0 c8 e8 a2 4c 99 07 5c 8e 35 2b 5562 7d 57 8d 02 14 a7 83 9b f3 bd 2c 20 07 fc 4c e7 5563 e8 9f f3 39 83 51 0d dc dd 02 81 80 0e 3b 46 31 5564 8a 0a 58 86 40 84 e3 a1 22 0d 88 ca 90 88 57 64 5565 9f 01 21 e0 15 05 94 24 82 e2 10 90 d9 e1 4e 10 5566 5c e7 54 6b d4 0c 2b 1b 59 0a a0 b5 a1 7d b5 07 5567 e3 65 7c ea 90 d8 8e 30 42 e4 85 bb ac fa 4e 76 5568 4b 78 0e df 6c e5 a6 e1 bd 59 77 7d a6 97 59 c5 5569 29 a7 b3 3f 95 3e 9d f1 59 2d f7 42 87 62 3f f1 5570 b8 6f c7 3d 4b b8 8d 74 c4 ca 44 90 cf 67 db de 5571 14 60 97 4a d1 f7 6d 9e 09 94 c4 0d 5572 Public Key: 5573 00 02 81 80 a8 63 b1 60 70 94 7e 0b 86 08 93 0c 5574 0d 08 12 4a 58 a9 af 9a 09 38 54 3b 46 82 fb 85 5575 0d 18 8b 2a 77 f7 58 e8 f0 1d d2 18 df fe e7 e9 5576 35 c8 a6 1a db 8d 3d 3d f8 73 14 a9 0b 39 c7 95 5577 f6 52 7d 2d 13 8c ae 03 29 3c 4e 8c b0 26 18 b6 5578 d8 11 1f d4 12 0c 13 ce 3f f1 c7 05 4e df e1 fc 5579 44 fd 25 34 19 4a 81 0d dd 98 42 ac d3 b6 91 0c 5580 7f 16 72 a3 a0 8a d7 01 7f fb 9c 93 e8 99 92 c8 5581 42 47 c6 43 5582 issuerUID: 5583 subjectUID: 5584 1 extensions: 5585 Exten 1: subjectAltName (2.5.29.17) 5586 30 10 81 0e 77 70 6f 6c 6b 40 6e 69 73 74 2e 67 5587 6f 76 5588 Signature Alg: dsa-with-sha (1.2.840.10040.4.3) 5589 Sig Value: 368 bits: 5590 30 2c 02 14 3c 02 e0 ab d9 5d 05 77 75 15 71 58 5591 92 29 48 c4 1c 54 df fc 02 14 5b da 53 98 7f c5 5592 33 df c6 09 b2 7a e3 6f 97 70 1e 14 ed 94 5594 D.3 End-Entity Certificate Using RSA 5596 This section contains an annotated hex dump of a 675 byte version 3 5597 certificate. The certificate contains the following information: 5598 (a) the serial number is 2; 5599 (b) the certificate is signed with RSA and the MD5 hash algorithm; 5600 (c) the issuer's distinguished name is OU=esCert- 5601 UPC;O=UPC;L=Barcelona;STREET=Catalunya;C=ES 5602 (d) and the subject's distinguished name is 5603 CN=escert.upc.es;OU=esCert- 5604 UPC;O=UPC;L=Barcelona;STREET=Catalunya;C=ES 5605 (e) the certificate was issued on May 21, 1996 and expired on May 21, 5606 1997; 5607 (f) the certificate contains a 768 bit RSA public key which is 5608 intended for generation of digital signatures; 5609 (g) the certificate is an end entity certificate (not a CA certifi- 5610 cate); 5611 (h) the certificate includes two alternative names - an RFC 822 5612 address, and a URL. 5614 sequence length 029f=671 bytes 5615 30 82 02 9f 5616 sequence length 0208h=520 bytes 5617 30 82 02 08 5618 explicit tag 00 "Version" 5619 a0 03 5620 integer length 1 value 2 [version is 3] 5621 02 01 02 5623 integer length 1 value 2 [serial number 2] 5624 02 01 02 5625 sequence length 13 [signature] 5626 30 0d 5627 object identifier length 9 {1 2 840 113549 1 1 4} 5628 {iso(1) member-body(2) us(840) etc.} 5629 06 09 2a 86 48 86 f7 0d 01 01 04 5630 null [null parameters] 5631 05 00 5632 sequence length 88 [issuer] 5633 30 58 5634 RDN length 11 5635 31 0b 5636 sequence length 9 5637 30 09 5638 object identifier length 3 { 2 5 4 6 } 5639 06 03 55 04 06 5640 printable string length 2 "ES" 5641 13 02 45 53 5642 RDN length 18 5643 31 12 5644 sequence length 16 5645 30 10 5646 object identifier length 3 { 2 5 4 9 } 5647 06 03 55 04 09 5648 printable string length 9 "Catalunya" 5649 13 09 43 61 74 61 6c 75 6e 79 61 5650 RDN length 18 5651 31 12 5652 sequence length 16 5653 30 10 5654 object identifier length 3 { 2 5 4 7 } 5655 06 03 55 04 07 5656 printable string length 9 "Barcelona" 5657 13 09 42 61 72 63 65 6c 6f 6e 61 5658 RDN length 12 5659 31 0c 5660 sequence length 10 5661 30 0a 5662 object identifier {2 5 4 10 } 5663 06 03 55 04 0a 5664 printable string length 3 "UPC" 5665 13 03 55 50 43 5666 RDN length 19 5667 31 13 5668 sequence length 17 5669 30 11 5670 object identifier {2 5 4 13 } 5671 06 03 55 04 0b 5672 printable string length 10 "esCERT-UPC" 5673 13 0a 65 73 43 45 52 54 2d 55 50 43 5674 sequence length 0x1e= 30 5675 30 1e 5676 UTCTime "960521095826Z" 5677 17 0d 39 36 30 35 32 31 30 39 35 38 32 36 5a 5678 UTCTime "979521095826Z" 5679 17 0d 39 37 30 35 32 31 30 39 35 38 32 36 5a 5680 sequence length 5681 30 70 5682 31 0b 5683 30 09 5684 { 2 5 4 6 } 5685 06 03 55 04 06 5686 "ES" 5687 13 02 45 53 5688 RDN 5689 31 12 5690 30 10 5691 { 2 5 4 9 } 5692 06 03 55 04 09 5693 "Catalunya" 5694 13 09 43 61 74 61 6c 75 6e 7961 5695 RDN 5696 31 12 5697 30 10 5698 { 2 5 4 7 } 5699 06 03 55 04 07 5700 "Barcelona" 5701 13 09 42 61 72 63 65 6c 6f 6e 61 5702 RDN 5703 31 0c 5704 30 0a 5705 { 2 5 4 10 } 5706 06 03 55 04 0a 5707 "UPC" 5708 13 03 55 50 43 5709 RDN 5710 31 13 5711 30 11 5712 { 2 5 4 11 } 5713 06 03 55 04 0b 5714 "esCERT-UPC" 5715 13 0a 65 73 43 45 52 54 2d 55 50 43 5716 RDN 5717 31 16 5718 30 14 5719 { 2 5 4 3 } 5720 06 03 55 04 03 5721 "escert.upc.es" 5722 13 0d 65 73 63 65 72 74 2e 75 70 63 2e 65 73 5723 subjectPublicKeyInfo 5724 30 7c 5725 algorithmIdentifier 5726 30 0d 5727 { 1 2 840 113549 1 1 1} 5728 06 09 2a 86 48 86 f7 0d 01 01 01 5729 null parameters 5730 05 00 5731 { subject's public key } 5732 03 6b BIT STRING length 107 bytes (856 bits) 5733 0030 6802 6100 beaa 8b77 54a3 afca 779f 5734 2fb0 cf43 88ff a66d 7955 5b61 8c68 ec48 5735 1e8a 8638 a4fe 19b8 6217 1d9d 0f47 2cff 5736 638f 2991 04d1 52bc 7f67 b6b2 8f74 55c1 5737 3321 6c8f ab01 9524 c8b2 7393 9d22 6150 5738 a935 fb9d 5750 32ef 5652 5093 abb1 8894 5739 7856 15c6 1c8b 0203 0100 01 5740 explicit tag 3 "extensions" length 0x84=132 5741 a3 81 84 5742 sequence 129 bytes 5743 30 81 81 5744 sequence 12 bytes 5745 30 0b 5746 id-ce-keyUsage = { 2 5 29 15 } 5747 06 03 55 1d 0f 5748 by default, critical = FALSE 5749 octet string 5750 04 04 03 02 07 80 5751 30 09 5752 id-ce-basicConstraints = { 2 5 29 19 } 5753 06 03 55 1d 13 5754 by default, critical = FALSE 5755 octet string 5756 04 02 5757 null sequence - by default, subject is end entity 5758 30 00 5759 30 3d 5760 id-ce-subjectAltName = { 2 5 29 17 } 5761 06 03 55 1d 11 5762 by default, critical = FALSE 5763 octet string 5764 04 36 5765 30 34 5766 rfc822name 5767 a1 1a 5768 IA5String "escert-upc@escert.upc.es" 5769 16 18 65 73 63 65 72 74 2d 75 70 63 40 65 73 5770 63 65 72 74 2e 75 70 63 2e 65 73 5771 uniformResourceIdentifier 5772 a6 16 5773 IA5String "http://escert.upc.es" 5774 16 14 68 74 74 70 3a 2f 2f 65 73 63 65 72 74 5775 2e 75 70 63 2e 65 73 5776 30 28 5777 id-ce-certificatePolicies = { 2 5 29 32 } 5778 06 03 55 1d 20 5779 by default, critical = FALSE 5780 octet string 5781 04 21 5782 30 1f 5783 30 1d 5784 06 04 2a 84 80 00 5785 { 2 2 32768 } 5786 30 15 5787 30 07 5788 { 2 2 32768 1 } 5789 06 05 2a 84 80 00 01 5790 30 0a 5791 { 2 2 32768 2 } 5792 06 05 2a 84 80 00 02 5793 02 01 0a 5794 sequence 5795 30 0d 5796 { 1 2 840 113549 1 1 4 } 5797 06 09 2a 86 48 86 f7 0d 01 01 04 5798 null parameters 5799 05 00 5800 bit string length 129 (signature) 5801 03 81 81 005b fdc2 a704 d483 4e17 6da6 fa27 e7c6 5802 f8ab b95d 9fd0 a1df d797 9fe0 20a6 c57a 5803 64cd 522f e9ae dabe 9ce4 d597 edf1 84c0 5804 d0fe 9bef 54b1 80e5 bf3c c9ed 9320 2d52 5805 21e9 bcb9 e34f ac11 650e 8fa1 6899 6347 5806 e53d e442 7313 fac5 c834 8cc0 4118 89d5 5807 e6a0 185b 5d86 1c1e c670 d80e 8964 9483 5808 8e3b 407c 59cf 2b2f b7ce 9798 1215 ef13 5809 d4 5811 D.4 Certificate Revocation List 5813 This section contains an annotated hex dump of a version 2 CRL with 5814 one extension (cRLNumber). The CRL was issued by OU=nist;O=gov;C=us 5815 on July 7, 1996; the next scheduled issuance was August 7, 1996. The 5816 CRL includes one revoked certificates: serial number 18 (12 hex). 5817 The CRL itself is number 18, and it was signed with DSA and SHA-1. 5819 0000 30 81 ba 186: SEQUENCE 5820 0003 30 7c 124: . SEQUENCE 5821 0005 02 01 1: . . INTEGER 1 5822 0008 30 09 9: . . SEQUENCE 5823 0010 06 07 7: . . . OID 1.2.840.10040.4.3: dsa-with-sha 5824 0019 30 2a 42: . . SEQUENCE 5825 0021 31 0b 11: . . . SET 5826 0023 30 09 9: . . . . SEQUENCE 5827 0025 06 03 3: . . . . . OID 2.5.4.6: C 5828 0030 13 02 2: . . . . . PrintableString 'US' 5829 0034 31 0c 12: . . . SET 5830 0036 30 0a 10: . . . . SEQUENCE 5831 0038 06 03 3: . . . . . OID 2.5.4.10: O 5832 0043 13 03 3: . . . . . PrintableString 'gov' 5833 0048 31 0d 13: . . . SET 5834 0050 30 0b 11: . . . . SEQUENCE 5835 0052 06 03 3: . . . . . OID 2.5.4.11: OU 5836 0057 13 04 4: . . . . . PrintableString 'nist' 5837 0063 17 0d 13: . . UTCTime '970801000000Z' 5838 0078 17 0d 13: . . UTCTime '970808000000Z' 5839 0093 30 22 34: . . SEQUENCE 5840 0095 30 20 32: . . . SEQUENCE 5841 0097 02 01 1: . . . . INTEGER 18 5842 0100 17 0d 13: . . . . UTCTime '970731000000Z' 5843 0115 30 0c 12: . . . . SEQUENCE 5844 0117 30 0a 10: . . . . . SEQUENCE 5845 0119 06 03 3: . . . . . . OID 2.5.29.21: reasonCode 5846 0124 04 03 3: . . . . . . OCTET STRING 5847 : 0a 01 01 5848 0129 30 09 9: . SEQUENCE 5849 0131 06 07 7: . . OID 1.2.840.10040.4.3: dsa-with-sha 5850 0140 03 2f 47: . BIT STRING (0 unused bits) 5851 : 30 2c 02 14 9e d8 6b c1 7d c2 c4 02 f5 17 84 f9 5852 : 9f 46 7a ca cf b7 05 8a 02 14 9e 43 39 85 dc ea 5853 : 14 13 72 93 54 5d 44 44 e5 05 fe 73 9a b2 5855 Appendix E. Author Addresses: 5857 Russell Housley 5858 SPYRUS 5859 381 Elden Street 5860 Suite 1120 5861 Herndon, VA 20170 5862 USA 5863 housley@spyrus.com 5865 Warwick Ford 5866 VeriSign, Inc. 5867 One Alewife Center 5868 Cambridge, MA 02140 5869 USA 5870 wford@verisign.com 5872 Tim Polk 5873 NIST 5874 Building 820, Room 426 5875 Gaithersburg, MD 20899 5876 USA 5877 wpolk@nist.gov 5879 David Solo 5880 Citicorp 5881 666 Fifth Ave, 3rd Floor 5882 New York, NY 10103 5883 USA 5884 david.solo@citicorp.com 5886 Appendix F. Full Copyright Statement 5888 Copyright (C) The Internet Society (date). All Rights Reserved. 5890 This document and translations of it may be copied and furnished to 5891 others, and derivative works that comment on or otherwise explain it 5892 or assist in its implementation may be prepared, copied, published 5893 and distributed, in whole or in part, without restriction of any 5894 kind, provided that the above copyright notice and this paragraph are 5895 included on all such copies and derivative works. In addition, the 5896 ASN.1 modules presented in Appendices A and B may be used in whole or 5897 in part without inclusion of the copyright notice. However, this 5898 document itself may not be modified in any way, such as by removing 5899 the copyright notice or references to the Internet Society or other 5900 Internet organizations, except as needed for the purpose of develop- 5901 ing Internet standards in which case the procedures for copyrights 5902 defined in the Internet Standards process must be followed, or as 5903 required to translate it into languages other than English. 5905 The limited permissions granted above are perpetual and will not be 5906 revoked by the Internet Society or its successors or assigns. This 5907 document and the information contained herein is provided on an "AS 5908 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 5909 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 5910 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 5911 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 5912 OR FITNESS FOR A PARTICULAR PURPOSE.