idnits 2.17.1 draft-ietf-pkix-ipki-part1-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 127 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 128 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 51 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 566 has weird spacing: '...issuing a cer...' == Line 576 has weird spacing: '...: This is th...' == 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 (July 28, 1998) is 9397 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 5689 -- Looks like a reference, but probably isn't: '1' on line 5248 -- Looks like a reference, but probably isn't: '2' on line 5249 -- Looks like a reference, but probably isn't: '3' on line 5774 == Missing Reference: 'ISO 8859-1' is mentioned on line 860, but not defined -- Looks like a reference, but probably isn't: '4' on line 5251 -- Looks like a reference, but probably isn't: '5' on line 5116 -- Looks like a reference, but probably isn't: '6' on line 5117 -- Looks like a reference, but probably isn't: '7' on line 5118 -- Looks like a reference, but probably isn't: '8' on line 5119 == Missing Reference: 'RFC1738' is mentioned on line 2192, but not defined ** Obsolete undefined reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) == Missing Reference: 'RFC1778' is mentioned on line 2192, but not defined ** Obsolete undefined reference: RFC 1778 (Obsoleted by RFC 3494) == Missing Reference: 'DB94' is mentioned on line 2615, but not defined == Missing Reference: 'UNIVERSAL 28' is mentioned on line 3289, but not defined == Missing Reference: 'UNIVERSAL 30' is mentioned on line 3292, but not defined == Missing Reference: 'UNIVERSAL 12' is mentioned on line 3296, but not defined == Missing Reference: 'APPLICATION 1' is mentioned on line 4670, but not defined == Missing Reference: 'APPLICATION 2' is mentioned on line 4676, but not defined == Unused Reference: 'FIPS 180-1' is defined on line 2909, but no explicit reference was found in the text == Unused Reference: 'RFC 1778' is defined on line 2949, but no explicit reference was found in the text == Unused Reference: 'RFC 1883' is defined on line 2953, but no explicit reference was found in the text == Unused Reference: 'RFC 2044' is defined on line 2956, but no explicit reference was found in the text == Unused Reference: 'RFC 2119' is defined on line 2959, but no explicit reference was found in the text == Unused Reference: 'RFC 2277' is defined on line 2966, but no explicit reference was found in the text == Unused Reference: 'RFC 2279' is defined on line 2969, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS 180-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS 186' -- Possible downref: Non-RFC (?) normative reference: ref. 'RC95' ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1319 (Obsoleted by RFC 6149) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Historic RFC: RFC 1422 ** Downref: Normative reference to an Historic RFC: RFC 1423 ** Obsolete normative reference: RFC 1519 (Obsoleted by RFC 4632) ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 1778 (Obsoleted by RFC 3494) ** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 2044 (Obsoleted by RFC 2279) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2313 (Obsoleted by RFC 2437) Summary: 23 errors (**), 0 flaws (~~), 26 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group R. Housley (SPYRUS) 3 Internet Draft W. Ford (VeriSign) 4 W. Polk (NIST) 5 D. Solo (Citicorp) 6 expires in six months July 28, 1998 8 Internet X.509 Public Key Infrastructure 10 Certificate and CRL Profile 12 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 To view the entire list of current Internet-Drafts, please check the 27 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 29 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 30 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 32 Copyright (C) The Internet Society (1998). All Rights Reserved. 34 Abstract 36 This is the ninth draft of the Internet Public Key Infrastructure 37 X.509 Certificate and CRL Profile. This draft is the result of 38 Working Group Last Call, and includes modifications to reflect the 39 group's final comments. 41 The key words "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" 42 in this document are to be interpreted as described in RFC 2119. 44 Please send comments on this document to the ietf-pkix@tandem.com 45 mail list. 47 Table of Contents 49 1 Introduction ................................................ 5 50 2 Requirements and Assumptions ................................ 6 51 2.1 Communication and Topology ................................ 6 52 2.2 Acceptability Criteria .................................... 7 53 2.3 User Expectations ......................................... 7 54 2.4 Administrator Expectations ................................ 7 55 3 Overview of Approach ........................................ 7 56 3.1 X.509 Version 3 Certificate ............................... 9 57 3.2 Certification Paths and Trust ............................. 10 58 3.3 Revocation ................................................ 12 59 3.4 Operational Protocols ..................................... 13 60 3.5 Management Protocols ...................................... 13 61 4 Certificate and Certificate Extensions Profile .............. 14 62 4.1 Basic Certificate Fields .................................. 15 63 4.1.1 Certificate Fields ...................................... 16 64 4.1.1.1 tbsCertificate ........................................ 16 65 4.1.1.2 signatureAlgorithm .................................... 16 66 4.1.1.3 signatureValue ........................................ 17 67 4.1.2 TBSCertificate .......................................... 17 68 4.1.2.1 Version ............................................... 17 69 4.1.2.2 Serial number ......................................... 17 70 4.1.2.3 Signature ............................................. 18 71 4.1.2.4 Issuer ................................................ 18 72 4.1.2.5 Validity .............................................. 21 73 4.1.2.5.1 UTCTime ............................................. 21 74 4.1.2.5.2 GeneralizedTime ..................................... 22 75 4.1.2.6 Subject ............................................... 22 76 4.1.2.7 Subject Public Key Info ............................... 23 77 4.1.2.8 Unique Identifiers .................................... 23 78 4.1.2.9 Extensions ............................................. 23 79 4.2 Certificate Extensions .................................... 23 80 4.2.1 Standard Extensions ..................................... 24 81 4.2.1.1 Authority Key Identifier .............................. 25 82 4.2.1.2 Subject Key Identifier ................................ 25 83 4.2.1.3 Key Usage ............................................. 26 84 4.2.1.4 Private Key Usage Period .............................. 28 85 4.2.1.5 Certificate Policies .................................. 28 86 4.2.1.6 Policy Mappings ....................................... 30 87 4.2.1.7 Subject Alternative Name .............................. 31 88 4.2.1.8 Issuer Alternative Name ............................... 33 89 4.2.1.9 Subject Directory Attributes .......................... 33 90 4.2.1.10 Basic Constraints .................................... 33 91 4.2.1.11 Name Constraints ..................................... 34 92 4.2.1.12 Policy Constraints ................................... 36 93 4.2.1.13 Extended key usage field ............................. 37 94 4.2.1.14 CRL Distribution Points .............................. 38 95 4.2.2 Internet Certificate Extensions ......................... 39 96 4.2.2.1 Authority Information Access .......................... 40 97 5 CRL and CRL Extensions Profile .............................. 41 98 5.1 CRL Fields ................................................ 41 99 5.1.1 CertificateList Fields .................................. 42 100 5.1.1.1 tbsCertList ........................................... 42 101 5.1.1.2 signatureAlgorithm .................................... 42 102 5.1.1.3 signatureValue ........................................ 43 103 5.1.2 Certificate List "To Be Signed" ......................... 43 104 5.1.2.1 Version ............................................... 43 105 5.1.2.2 Signature ............................................. 43 106 5.1.2.3 Issuer Name ........................................... 43 107 5.1.2.4 This Update ........................................... 44 108 5.1.2.5 Next Update ........................................... 44 109 5.1.2.6 Revoked Certificates .................................. 44 110 5.1.2.7 Extensions ............................................ 45 111 5.2 CRL Extensions ............................................ 45 112 5.2.1 Authority Key Identifier ................................ 45 113 5.2.2 Issuer Alternative Name ................................. 46 114 5.2.3 CRL Number .............................................. 46 115 5.2.4 Delta CRL Indicator ..................................... 46 116 5.2.5 Issuing Distribution Point .............................. 47 117 5.3 CRL Entry Extensions ...................................... 48 118 5.3.1 Reason Code ............................................. 48 119 5.3.2 Hold Instruction Code ................................... 49 120 5.3.3 Invalidity Date ......................................... 49 121 5.3.4 Certificate Issuer ...................................... 50 122 6 Certificate Path Validation ................................. 50 123 6.1 Basic Path Validation ..................................... 51 124 6.2 Extending Path Validation ................................. 55 125 7 Algorithm Support ........................................... 55 126 7.1 One-way Hash Functions .................................... 55 127 7.1.1 MD2 One-way Hash Function ............................... 56 128 7.1.2 MD5 One-way Hash Function ............................... 56 129 7.1.3 SHA-1 One-way Hash Function ............................. 56 130 7.2 Signature Algorithms ...................................... 56 131 7.2.1 RSA Signature Algorithm ................................. 57 132 7.2.2 DSA Signature Algorithm ................................. 58 133 7.3 Subject Public Key Algorithms ............................. 59 134 7.3.1 RSA Keys ................................................ 59 135 7.3.2 Diffie-Hellman Key Exchange Key ......................... 60 136 7.3.3 DSA Signature Keys ...................................... 61 137 8 References .................................................. 62 138 9 Patent Statements ........................................... 64 139 9.1 Digital Signature Algorithm (DSA) ......................... 65 140 9.2 RSA Signature and Encryption .............................. 65 141 9.3 Diffie-Hellman Key Agreement .............................. 66 142 9.4 Hellman-Merkle Public Key Cryptography .................... 66 143 9.5 CRL Distribution Points and Related Mechanisms ............ 66 144 10 Security Considerations .................................... 67 145 Appendix A. ASN.1 Structures and OIDs ......................... 70 146 A.1 Explicitly Tagged Module, 1988 Syntax ...................... 70 147 A.2 Implicitly Tagged Module, 1988 Syntax ...................... 84 148 Appendix B. 1993 ASN.1 Structures and OIDs .................... 91 149 B.1 Explicitly Tagged Module, 1993 Syntax ...................... 91 150 B.2 Implicitly Tagged Module, 1993 Syntax ...................... 108 151 Appendix C. ASN.1 Notes ....................................... 115 152 Appendix D. Examples .......................................... 116 153 D.1 Certificate ............................................... 116 154 D.2 Certificate ............................................... 119 155 D.3 End-Entity Certificate Using RSA .......................... 122 156 D.4 Certificate Revocation List ............................... 125 157 Appendix E. Author Addresses .................................. 126 158 Appendix F. Full Copyright Statement .......................... 127 160 1 Introduction 162 This specification is one part of a family of standards for the X.509 163 Public Key Infrastructure (PKI) for the Internet. This specification 164 is a standalone document; implementations of this standard may 165 proceed independent from the other parts. 167 This specification profiles the format and semantics of certificates 168 and certificate revocation lists for the Internet PKI. Procedures 169 are described for processing of certification paths in the Internet 170 environment. Encoding rules are provided for popular cryptographic 171 algorithms. Finally, ASN.1 modules are provided in the appendices 172 for all data structures defined or referenced. 174 The specification describes the requirements which inspire the crea- 175 tion of this document and the assumptions which affect its scope in 176 Section 2. Section 3 presents an architectural model and describes 177 its relationship to previous IETF and ISO/IEC/ITU standards. In par- 178 ticular, this document's relationship with the IETF PEM specifica- 179 tions and the ISO/IEC/ITU X.509 documents are described. 181 The specification profiles the X.509 version 3 certificate in Section 182 4, and the X.509 version 2 certificate revocation list (CRL) in Sec- 183 tion 5. The profiles include the identification of ISO/IEC/ITU and 184 ANSI extensions which may be useful in the Internet PKI. The profiles 185 are presented in the 1988 Abstract Syntax Notation One (ASN.1) rather 186 than the 1994 syntax used in the ISO/IEC/ITU standards. 188 This specification also includes path validation procedures in Sec- 189 tion 6. These procedures are based upon the ISO/IEC/ITU definition, 190 but the presentation assumes one or more self-signed trusted CA cer- 191 tificates. Implementations are required to derive the same results 192 but are not required to use the specified procedures. 194 Section 7 of the specification describes procedures for identifica- 195 tion and encoding of public key materials and digital signatures. 196 Implementations are not required to use any particular cryptographic 197 algorithms. However, conforming implementations which use the iden- 198 tified algorithms are required to identify and encode the public key 199 materials and digital signatures as described. 201 Finally, four appendices are provided to aid implementers. Appendix 202 A contains all ASN.1 structures defined or referenced within this 203 specification. As above, the material is presented in the 1988 204 Abstract Syntax Notation One (ASN.1) rather than the 1994 syntax. 205 Appendix B contains the same information in the 1994 ASN.1 notation 206 as a service to implementers using updated toolsets. However, Appen- 207 dix A takes precedence in case of conflict. Appendix C contains 208 notes on less familiar features of the ASN.1 notation used within 209 this specification. Appendix D contains examples of a conforming 210 certificate and a conforming CRL. 212 2 Requirements and Assumptions 214 The goal of this specification is to develop a profile to facilitate 215 the use of X.509 certificates within Internet applications for those 216 communities wishing to make use of X.509 technology. Such applica- 217 tions may include WWW, electronic mail, user authentication, and 218 IPsec. In order to relieve some of the obstacles to using X.509 cer- 219 tificates, this document defines a profile to promote the development 220 of certificate management systems; development of application tools; 221 and interoperability determined by policy. 223 Some communities will need to supplement, or possibly replace, this 224 profile in order to meet the requirements of specialized application 225 domains or environments with additional authorization, assurance, or 226 operational requirements. However, for basic applications, common 227 representations of frequently used attributes are defined so that 228 application developers can obtain necessary information without 229 regard to the issuer of a particular certificate or certificate revo- 230 cation list (CRL). 232 A certificate user should review the certificate policy generated by 233 the certification authority (CA) before relying on the authentication 234 or non-repudiation services associated with the public key in a par- 235 ticular certificate. To this end, this standard does not prescribe 236 legally binding rules or duties. 238 As supplemental authorization and attribute management tools emerge, 239 such as attribute certificates, it may be appropriate to limit the 240 authenticated attributes that are included in a certificate. These 241 other management tools may provide more appropriate methods of con- 242 veying many authenticated attributes. 244 2.1 Communication and Topology 246 The users of certificates will operate in a wide range of environ- 247 ments with respect to their communication topology, especially users 248 of secure electronic mail. This profile supports users without high 249 bandwidth, real-time IP connectivity, or high connection availabil- 250 ity. In addition, the profile allows for the presence of firewall or 251 other filtered communication. 253 This profile does not assume the deployment of an X.500 Directory 254 system. The profile does not prohibit the use of an X.500 Directory, 255 but other means of distributing certificates and certificate 256 revocation lists (CRLs) may be used. 258 2.2 Acceptability Criteria 260 The goal of the Internet Public Key Infrastructure (PKI) is to meet 261 the needs of deterministic, automated identification, authentication, 262 access control, and authorization functions. Support for these ser- 263 vices determines the attributes contained in the certificate as well 264 as the ancillary control information in the certificate such as pol- 265 icy data and certification path constraints. 267 2.3 User Expectations 269 Users of the Internet PKI are people and processes who use client 270 software and are the subjects named in certificates. These uses 271 include readers and writers of electronic mail, the clients for WWW 272 browsers, WWW servers, and the key manager for IPsec within a router. 273 This profile recognizes the limitations of the platforms these users 274 employ and the limitations in sophistication and attentiveness of the 275 users themselves. This manifests itself in minimal user configura- 276 tion responsibility (e.g., trusted CA keys, rules), explicit platform 277 usage constraints within the certificate, certification path con- 278 straints which shield the user from many malicious actions, and 279 applications which sensibly automate validation functions. 281 2.4 Administrator Expectations 283 As with user expectations, the Internet PKI profile is structured to 284 support the individuals who generally operate CAs. Providing 285 administrators with unbounded choices increases the chances that a 286 subtle CA administrator mistake will result in broad compromise. 287 Also, unbounded choices greatly complicate the software that shall 288 process and validate the certificates created by the CA. 290 3 Overview of Approach 292 Following is a simplified view of the architectural model assumed by 293 the PKIX specifications. 295 +---+ 296 | C | +------------+ 297 | e | <-------------------->| End entity | 298 | r | Operational +------------+ 299 | t | transactions ^ 300 | | and management | Management 301 | / | transactions | transactions 302 | | | PKI users 303 | C | v 304 | R | -------------------+--+-----------+---------------- 305 | L | ^ ^ 306 | | | | PKI management 307 | | v | entities 308 | R | +------+ | 309 | e | <---------------------| RA | <---+ | 310 | p | Publish certificate +------+ | | 311 | o | | | 312 | s | | | 313 | I | v v 314 | t | +------------+ 315 | o | <------------------------------| CA | 316 | r | Publish certificate +------------+ 317 | y | Publish CRL ^ 318 | | | 319 +---+ Management | 320 transactions | 321 v 322 +------+ 323 | CA | 324 +------+ 326 Figure 1 - PKI Entities 328 The components in this model are: 330 end entity: user of PKI certificates and/or end user system that 331 is the subject of a certificate; 332 CA: certification authority; 333 RA: registration authority, i.e., an optional system to 334 which a CA delegates certain management functions; 335 repository: a system or collection of distributed systems that 336 store certificates and CRLs and serves as a means of 337 distributing these certificates and CRLs to end 338 entities. 340 3.1 X.509 Version 3 Certificate 342 Users of a public key shall be confident that the associated private 343 key is owned by the correct remote subject (person or system) with 344 which an encryption or digital signature mechanism will be used. 345 This confidence is obtained through the use of public key certifi- 346 cates, which are data structures that bind public key values to sub- 347 jects. The binding is achieved by having a trusted CA digitally sign 348 each certificate. A certificate has a limited valid lifetime which 349 is indicated in its signed contents. Because a certificate's signa- 350 ture and timeliness can be independently checked by a certificate- 351 using client, certificates can be distributed via untrusted communi- 352 cations and server systems, and can be cached in unsecured storage in 353 certificate-using systems. 355 ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8, which was 356 first published in 1988 as part of the X.500 Directory recommenda- 357 tions, defines a standard certificate format [X.509]. The certificate 358 format in the 1988 standard is called the version 1 (v1) format. 359 When X.500 was revised in 1993, two more fields were added, resulting 360 in the version 2 (v2) format. These two fields may be used to support 361 directory access control. 363 The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993, 364 include specifications for a public key infrastructure based on X.509 365 v1 certificates [RFC 1422]. The experience gained in attempts to 366 deploy RFC 1422 made it clear that the v1 and v2 certificate formats 367 are deficient in several respects. Most importantly, more fields 368 were needed to carry information which PEM design and implementation 369 experience has proven necessary. In response to these new require- 370 ments, ISO/IEC/ITU and ANSI X9 developed the X.509 version 3 (v3) 371 certificate format. The v3 format extends the v2 format by adding 372 provision for additional extension fields. Particular extension 373 field types may be specified in standards or may be defined and 374 registered by any organization or community. In June 1996, standardi- 375 zation of the basic v3 format was completed [X.509]. 377 ISO/IEC/ITU and ANSI X9 have also developed standard extensions for 378 use in the v3 extensions field [X.509][X9.55]. These extensions can 379 convey such data as additional subject identification information, 380 key attribute information, policy information, and certification path 381 constraints. 383 However, the ISO/IEC/ITU and ANSI X9 standard extensions are very 384 broad in their applicability. In order to develop interoperable 385 implementations of X.509 v3 systems for Internet use, it is necessary 386 to specify a profile for use of the X.509 v3 extensions tailored for 387 the Internet. It is one goal of this document to specify a profile 388 for Internet WWW, electronic mail, and IPsec applications. Environ- 389 ments with additional requirements may build on this profile or may 390 replace it. 392 3.2 Certification Paths and Trust 394 A user of a security service requiring knowledge of a public key gen- 395 erally needs to obtain and validate a certificate containing the 396 required public key. If the public-key user does not already hold an 397 assured copy of the public key of the CA that signed the certificate, 398 then it might need an additional certificate to obtain that public 399 key. In general, a chain of multiple certificates may be needed, 400 comprising a certificate of the public key owner (the end entity) 401 signed by one CA, and zero or more additional certificates of CAs 402 signed by other CAs. Such chains, called certification paths, are 403 required because a public key user is only initialized with a limited 404 number of assured CA public keys. 406 There are different ways in which CAs might be configured in order 407 for public key users to be able to find certification paths. For 408 PEM, RFC 1422 defined a rigid hierarchical structure of CAs. There 409 are three types of PEM certification authority: 411 (a) Internet Policy Registration Authority (IPRA): This author- 412 ity, operated under the auspices of the Internet Society, acts as 413 the root of the PEM certification hierarchy at level 1. It issues 414 certificates only for the next level of authorities, PCAs. All 415 certification paths start with the IPRA. 417 (b) Policy Certification Authorities (PCAs): PCAs are at level 2 418 of the hierarchy, each PCA being certified by the IPRA. A PCA 419 shall establish and publish a statement of its policy with respect 420 to certifying users or subordinate certification authorities. 421 Distinct PCAs aim to satisfy different user needs. For example, 422 one PCA (an organizational PCA) might support the general elec- 423 tronic mail needs of commercial organizations, and another PCA (a 424 high-assurance PCA) might have a more stringent policy designed 425 for satisfying legally binding digital signature requirements. 427 (c) Certification Authorities (CAs): CAs are at level 3 of the 428 hierarchy and can also be at lower levels. Those at level 3 are 429 certified by PCAs. CAs represent, for example, particular organi- 430 zations, particular organizational units (e.g., departments, 431 groups, sections), or particular geographical areas. 433 RFC 1422 furthermore has a name subordination rule which requires 434 that a CA can only issue certificates for entities whose names are 435 subordinate (in the X.500 naming tree) to the name of the CA itself. 437 The trust associated with a PEM certification path is implied by the 438 PCA name. The name subordination rule ensures that CAs below the PCA 439 are sensibly constrained as to the set of subordinate entities they 440 can certify (e.g., a CA for an organization can only certify entities 441 in that organization's name tree). Certificate user systems are able 442 to mechanically check that the name subordination rule has been fol- 443 lowed. 445 The RFC 1422 uses the X.509 v1 certificate formats. The limitations 446 of X.509 v1 required imposition of several structural restrictions to 447 clearly associate policy information or restrict the utility of cer- 448 tificates. These restrictions included: 450 (a) a pure top-down hierarchy, with all certification paths start- 451 ing from IPRA; 453 (b) a naming subordination rule restricting the names of a CA's 454 subjects; and 456 (c) use of the PCA concept, which requires knowledge of individual 457 PCAs to be built into certificate chain verification logic. 458 Knowledge of individual PCAs was required to determine if a chain 459 could be accepted. 461 With X.509 v3, most of the requirements addressed by RFC 1422 can be 462 addressed using certificate extensions, without a need to restrict 463 the CA structures used. In particular, the certificate extensions 464 relating to certificate policies obviate the need for PCAs and the 465 constraint extensions obviate the need for the name subordination 466 rule. As a result, this document supports a more flexible architec- 467 ture, including: 469 (a) Certification paths may start with a public key of a CA in a 470 user's own domain, or with the public key of the top of a hierar- 471 chy. Starting with the public key of a CA in a user's own domain 472 has certain advantages. In some environments, the local domain is 473 the most trusted. 475 (b) Name constraints may be imposed through explicit inclusion of 476 a name constraints extension in a certificate, but are not 477 required. 479 (c) Policy extensions and policy mappings replace the PCA con- 480 cept, which permits a greater degree of automation. The applica- 481 tion can determine if the certification path is acceptable based 482 on the contents of the certificates instead of a priori knowledge 483 of PCAs. This permits automation of certificate chain processing. 485 3.3 Revocation 487 When a certificate is issued, it is expected to be in use for its 488 entire validity period. However, various circumstances may cause a 489 certificate to become invalid prior to the expiration of the validity 490 period. Such circumstances include change of name, change of associa- 491 tion between subject and CA (e.g., an employee terminates employment 492 with an organization), and compromise or suspected compromise of the 493 corresponding private key. Under such circumstances, the CA needs to 494 revoke the certificate. 496 X.509 defines one method of certificate revocation. This method 497 involves each CA periodically issuing a signed data structure called 498 a certificate revocation list (CRL). A CRL is a time stamped list 499 identifying revoked certificates which is signed by a CA and made 500 freely available in a public repository. Each revoked certificate is 501 identified in a CRL by its certificate serial number. When a 502 certificate-using system uses a certificate (e.g., for verifying a 503 remote user's digital signature), that system not only checks the 504 certificate signature and validity but also acquires a suitably- 505 recent CRL and checks that the certificate serial number is not on 506 that CRL. The meaning of "suitably-recent" may vary with local pol- 507 icy, but it usually means the most recently-issued CRL. A CA issues 508 a new CRL on a regular periodic basis (e.g., hourly, daily, or 509 weekly). An entry is added to the CRL as part of the next update 510 following notification of revocation. An entry may be removed from 511 the CRL after appearing on one regularly scheduled CRL issued beyond 512 the revoked certificate's validity period. 514 An advantage of this revocation method is that CRLs may be distri- 515 buted by exactly the same means as certificates themselves, namely, 516 via untrusted communications and server systems. 518 One limitation of the CRL revocation method, using untrusted communi- 519 cations and servers, is that the time granularity of revocation is 520 limited to the CRL issue period. For example, if a revocation is 521 reported now, that revocation will not be reliably notified to 522 certificate-using systems until the next periodic CRL is issued -- 523 this may be up to one hour, one day, or one week depending on the 524 frequency that the CA issues CRLs. 526 As with the X.509 v3 certificate format, in order to facilitate 527 interoperable implementations from multiple vendors, the X.509 v2 CRL 528 format needs to be profiled for Internet use. It is one goal of this 529 document to specify that profile. However, this profile does not 530 require CAs to issue CRLs. Message formats and protocols supporting 531 on-line revocation notification may be defined in other PKIX specifi- 532 cations. On-line methods of revocation notification may be 533 applicable in some environments as an alternative to the X.509 CRL. 534 On-line revocation checking may significantly reduce the latency 535 between a revocation report and the distribution of the information 536 to relying parties. Once the CA accepts the report as authentic and 537 valid, any query to the on-line service will correctly reflect the 538 certificate validation impacts of the revocation. However, these 539 methods impose new security requirements; the certificate validator 540 shall trust the on-line validation service while the repository does 541 not need to be trusted. 543 3.4 Operational Protocols 545 Operational protocols are required to deliver certificates and CRLs 546 (or status information) to certificate using client systems. Provi- 547 sion is needed for a variety of different means of certificate and 548 CRL delivery, including distribution procedures based on LDAP, HTTP, 549 FTP, and X.500. Operational protocols supporting these functions are 550 defined in other PKIX specifications. These specifications may 551 include definitions of message formats and procedures for supporting 552 all of the above operational environments, including definitions of 553 or references to appropriate MIME content types. 555 3.5 Management Protocols 557 Management protocols are required to support on-line interactions 558 between PKI user and management entities. For example, a management 559 protocol might be used between a CA and a client system with which a 560 key pair is associated, or between two CAs which cross-certify each 561 other. The set of functions which potentially need to be supported 562 by management protocols include: 564 (a) registration: This is the process whereby a user first makes 565 itself known to a CA (directly, or through an RA), prior to that 566 CA issuing a certificate or certificates for that user. 568 (b) initialization: Before a client system can operate securely 569 it is necessary to install key materials which have the appropri- 570 ate relationship with keys stored elsewhere in the infrastructure. 571 For example, the client needs to be securely initialized with the 572 public key and other assured information of the trusted CA(s), to 573 be used in validating certificate paths. Furthermore, a client 574 typically needs to be initialized with its own key pair(s). 576 (c) certification: This is the process in which a CA issues a 577 certificate for a user's public key, and returns that certificate 578 to the user's client system and/or posts that certificate in a 579 repository. 581 (d) key pair recovery: As an option, user client key materials 582 (e.g., a user's private key used for encryption purposes) may be 583 backed up by a CA or a key backup system. If a user needs to 584 recover these backed up key materials (e.g., as a result of a for- 585 gotten password or a lost key chain file), an on-line protocol 586 exchange may be needed to support such recovery. 588 (e) key pair update: All key pairs need to be updated regularly, 589 i.e., replaced with a new key pair, and new certificates issued. 591 (f) revocation request: An authorized person advises a CA of an 592 abnormal situation requiring certificate revocation. 594 (g) cross-certification: Two CAs exchange information used in 595 establishing a cross-certificate. A cross-certificate is a certi- 596 ficate issued by one CA to another CA which contains a CA signa- 597 ture key used for issuing certificates. 599 Note that on-line protocols are not the only way of implementing the 600 above functions. For all functions there are off-line methods of 601 achieving the same result, and this specification does not mandate 602 use of on-line protocols. For example, when hardware tokens are 603 used, many of the functions may be achieved as part of the physical 604 token delivery. Furthermore, some of the above functions may be com- 605 bined into one protocol exchange. In particular, two or more of the 606 registration, initialization, and certification functions can be com- 607 bined into one protocol exchange. 609 The PKIX series of specifications may define a set of standard mes- 610 sage formats supporting the above functions in future specifications. 611 In that case, the protocols for conveying these messages in different 612 environments (e.g., on-line, file transfer, e-mail, and WWW) will 613 also be described in those specifications. 615 4 Certificate and Certificate Extensions Profile 617 This section presents a profile for public key certificates that will 618 foster interoperability and a reusable PKI. This section is based 619 upon the X.509 v3 certificate format and the standard certificate 620 extensions defined in [X.509]. The ISO/IEC/ITU documents use the 621 1993 version of ASN.1; while this document uses the 1988 ASN.1 syn- 622 tax, the encoded certificate and standard extensions are equivalent. 623 This section also defines private extensions required to support a 624 PKI for the Internet community. 626 Certificates may be used in a wide range of applications and environ- 627 ments covering a broad spectrum of interoperability goals and a 628 broader spectrum of operational and assurance requirements. The goal 629 of this document is to establish a common baseline for generic appli- 630 cations requiring broad interoperability and limited special purpose 631 requirements. In particular, the emphasis will be on supporting the 632 use of X.509 v3 certificates for informal Internet electronic mail, 633 IPsec, and WWW applications. 635 4.1 Basic Certificate Fields 637 The X.509 v3 certificate basic syntax is as follows. For signature 638 calculation, the certificate is encoded using the ASN.1 distinguished 639 encoding rules (DER) [X.208]. ASN.1 DER encoding is a tag, length, 640 value encoding system for each element. 642 Certificate ::= SEQUENCE { 643 tbsCertificate TBSCertificate, 644 signatureAlgorithm AlgorithmIdentifier, 645 signatureValue BIT STRING } 647 TBSCertificate ::= SEQUENCE { 648 version [0] EXPLICIT Version DEFAULT v1, 649 serialNumber CertificateSerialNumber, 650 signature AlgorithmIdentifier, 651 issuer Name, 652 validity Validity, 653 subject Name, 654 subjectPublicKeyInfo SubjectPublicKeyInfo, 655 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 656 -- If present, version shall be v2 or v3 657 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 658 -- If present, version shall be v2 or v3 659 extensions [3] EXPLICIT Extensions OPTIONAL 660 -- If present, version shall be v3 661 } 663 Version ::= INTEGER { v1(0), v2(1), v3(2) } 665 CertificateSerialNumber ::= INTEGER 667 Validity ::= SEQUENCE { 668 notBefore Time, 669 notAfter Time } 671 Time ::= CHOICE { 672 utcTime UTCTime, 673 generalTime GeneralizedTime } 675 UniqueIdentifier ::= BIT STRING 676 SubjectPublicKeyInfo ::= SEQUENCE { 677 algorithm AlgorithmIdentifier, 678 subjectPublicKey BIT STRING } 680 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 682 Extension ::= SEQUENCE { 683 extnID OBJECT IDENTIFIER, 684 critical BOOLEAN DEFAULT FALSE, 685 extnValue OCTET STRING } 687 The following items describe the X.509 v3 certificate for use in the 688 Internet. 690 4.1.1 Certificate Fields 692 The Certificate is a SEQUENCE of three required fields. The fields 693 are described in detail in the following subsections. 695 4.1.1.1 tbsCertificate 697 The field contains the names of the subject and issuer, a public key 698 associated with the subject, a validity period, and other associated 699 information. The fields are described in detail in section 4.1.2; 700 the tbscertificate may also include extensions which are described in 701 section 4.2. 703 4.1.1.2 signatureAlgorithm 705 The signatureAlgorithm field contains the identifier for the crypto- 706 graphic algorithm used by the CA to sign this certificate. Section 707 7.2 lists the supported signature algorithms. 709 An algorithm identifier is defined by the following ASN.1 structure: 711 AlgorithmIdentifier ::= SEQUENCE { 712 algorithm OBJECT IDENTIFIER, 713 parameters ANY DEFINED BY algorithm OPTIONAL } 715 The algorithm identifier is used to identify a cryptographic algo- 716 rithm. The OBJECT IDENTIFIER component identifies the algorithm 717 (such as DSA with SHA-1). The contents of the optional parameters 718 field will vary according to the algorithm identified. Section 7.2 719 lists the supported algorithms for this specification. 721 This field shall contain the same algorithm identifier as the signa- 722 ture field in the sequence tbsCertificate (see sec. 4.1.2.3). 724 4.1.1.3 signatureValue 726 The signatureValue field contains a digital signature computed upon 727 the ASN.1 DER encoded tbsCertificate. The ASN.1 DER encoded tbsCer- 728 tificate is used as the input to the signature function. This signa- 729 ture value is then ASN.1 encoded as a BIT STRING and included in the 730 Certificate's signature field. The details of this process are speci- 731 fied for each of the supported algorithms in Section 7.2. 733 By generating this signature, a CA certifies the validity of the 734 information in the tbsCertificate field. In particular, the CA cer- 735 tifies the binding between the public key material and the subject of 736 the certificate. 738 4.1.2 TBSCertificate 740 The sequence TBSCertificate contains information associated with the 741 subject of the certificate and the CA who issued it. Every TBSCerti- 742 ficate contains the names of the subject and issuer, a public key 743 associated with the subject, a validity period, a version number, and 744 a serial number; some may contain optional unique identifier fields. 745 The remainder of this section describes the syntax and semantics of 746 these fields. A TBSCertificate may also include extensions. Exten- 747 sions for the Internet PKI are described in Section 4.2. 749 4.1.2.1 Version 751 This field describes the version of the encoded certificate. When 752 extensions are used, as expected in this profile, use X.509 version 3 753 (value is 2). If no extensions are present, but a UniqueIdentifier 754 is present, use version 2 (value is 1). If only basic fields are 755 present, use version 1 (the value is omitted from the certificate as 756 the default value). 758 Implementations should be prepared to accept any version certificate. 759 At a minimum, conforming implementations shall recognize version 3 760 certificates. 762 Generation of version 2 certificates is not expected by implementa- 763 tions based on this profile. 765 4.1.2.2 Serial number 767 The serial number is an integer assigned by the CA to each certifi- 768 cate. It shall be unique for each certificate issued by a given CA 769 (i.e., the issuer name and serial number identify a unique certifi- 770 cate). 772 4.1.2.3 Signature 774 This field contains the algorithm identifier for the algorithm used 775 by the CA to sign the certificate. 777 This field shall contain the same algorithm identifier as the signa- 778 tureAlgorithm field in the sequence Certificate (see sec. 4.1.1.2). 779 The contents of the optional parameters field will vary according to 780 the algorithm identified. Section 7.2 lists the supported signature 781 algorithms. 783 4.1.2.4 Issuer 785 The issuer field identifies the entity who has signed and issued the 786 certificate. The issuer field shall contain a non-empty dis- 787 tinguished name (DN). The issuer field is defined as the X.501 type 788 Name. [X.501] Name is defined by the following ASN.1 structures: 790 Name ::= CHOICE { 791 RDNSequence } 793 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 795 RelativeDistinguishedName ::= 796 SET OF AttributeTypeAndValue 798 AttributeTypeAndValue ::= SEQUENCE { 799 type AttributeType, 800 value AttributeValue } 802 AttributeType ::= OBJECT IDENTIFIER 804 AttributeValue ::= ANY DEFINED BY AttributeType 806 DirectoryString ::= CHOICE { 807 teletexString TeletexString (SIZE (1..MAX)), 808 printableString PrintableString (SIZE (1..MAX)), 809 universalString UniversalString (SIZE (1..MAX)), 810 utf8String UTF8String (SIZE (1.. MAX)), 811 bmpString BMPString (SIZE (1..MAX)) } 813 The Name describes a hierarchical name composed of attributes, such 814 as country name, and corresponding values, such as US. The type of 815 the component AttributeValue is determined by the AttributeType; in 816 general it will be a DirectoryString. 818 The DirectoryString type is defined as a choice of PrintableString, 819 TeletexString, BMPString, UTF8String, and UniversalString. The 820 UTF8String encoding is the preferred encoding, and all certificates 821 issued after December 31, 2003 shall use the UTF8String encoding of 822 DirectoryString (except as noted below). Until that date, conforming 823 CAs shall choose from the following options when creating a dis- 824 tinguished name, including their own: 826 (a) if the character set is sufficient, the string may be 827 represented as a PrintableString; 829 (b) failing (a), if the BMPString character set is sufficient the 830 string may be represented as a BMPString; and 832 (c) failing (a) and (b), the string shall be represented as a 833 UTF8String. If (a) or (b) is satisfied, the CA may still choose 834 to represent the string as a UTF8String. 836 Exceptions to the December 31, 2003 UTF8 encoding requirements are as 837 follows: 839 (a) CAs may issue "name rollover" certificates to support an ord- 840 erly migration to UTF8String encoding. Such certificates would 841 include the CA's UTF8String encoded name as issuer and and the old 842 name encoding as subject, or vice-versa. 844 (b) As stated in section 4.1.2.6, the subject field shall be popu- 845 lated with a non-empty distinguished name matching the contents of 846 the issuer field in all certificates issued by the subject CA 847 regardless of encoding. 849 The TeletexString and UniversalString are included for backward com- 850 patibility, and should not be used for certificates for new subjects. 851 However, these types may be used in certificates where the name was 852 previously established. Certificate users should be prepared to 853 receive certificates with these types. 855 In addition, many legacy implementations support names encoded in the 856 ISO 8859-1 character set (Latin1String) but tag them as Teletex- 857 String. The Latin1String includes characters used in Western Euro- 858 pean countries which are not part of the TeletexString charcter set. 859 Implementations that process TeletexString should be prepared to han- 860 dle the entire ISO 8859-1 character set.[ISO 8859-1] 862 As noted above, distinguished names are composed of attributes. This 863 specification does not restrict the set of attribute types that may 864 appear in names. However, conforming implementations shall be 865 prepared to receive certificates with issuer names containing the set 866 of attribute types defined below. This specification also recommends 867 support for additional attribute types. 869 Standard sets of attributes have been defined in the X.500 series of 870 specifications.[X.520] Implementations of this specification shall 871 be prepared to receive the following standard attribute types in 872 issuer names: country, organization, organizational-unit, dis- 873 tinguished name qualifier, state or province name, and common name 874 (e.g., "Susan Housley"). In addition, implementations of this 875 specification should be prepared to receive the following standard 876 attribute types in issuer names: locality, title, surname, given 877 name, initials, and generation qualifier (e.g., "Jr.", "3rd", or 878 "IV"). The syntax and associated object identifiers (OIDs) for these 879 attribute types are provided in the ASN.1 modules in Appendices A and 880 B. 882 In addition, implementations of this specification shall be prepared 883 to receive the domainComponent attribute, as defined in [RFC 2247]. 884 The Domain (Nameserver) System (DNS) provides a hierarchical resource 885 labeling system. This attribute provides is a convenient mechanism 886 for organizations that wish to use DNs that parallel their DNS names. 887 This is not a replacement for the dNSName component of the alterna- 888 tive name field. Implementations are not required to convert such 889 names into DNS names. The syntax and associated OID for this attri- 890 bute type is provided in the ASN.1 modules in Appendices A and B. 892 Certificate users shall be prepared to process the issuer dis- 893 tinguished name and subject distinguished name (see sec. 4.1.2.6) 894 fields to perform name chaining for certification path validation 895 (see section 6). Name chaining is performed by matching the issuer 896 distinguished name in one certificate with the subject name in a CA 897 certificate. 899 This specification requires only a subset of the name comparison 900 functionality specified in the X.500 series of specifications. The 901 requirements for conforming implementations are as follows: 903 (a) attribute values encoded in different types (e.g., Printable- 904 String and BMPString) may be assumed to represent different 905 strings; 907 (b) attribute values in types other than PrintableString are case 908 sensitive (this permits matching of attribute values as binary 909 objects); 911 (c) attribute values in PrintableString are not case sensitive 912 (e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and 914 (d) attribute values in PrintableString are compared after remov- 915 ing leading and trailing white space and converting internal sub- 916 strings of one or more consecutive white space characters to a 917 single space. 919 These name comparison rules permit a certificate user to validate 920 certificates issued using languages or encodings unfamiliar to the 921 certificate user. 923 Note that the comparison rules defined in the X.500 series of specif- 924 ications indicate that the character sets used to encode data in dis- 925 tinguished names are irrelevant. The characters themselves are com- 926 pared without regard to encoding. Implementations of the profile are 927 permitted to use the comparison algorithm defined in the X.500 928 series. Such an implementation will recognize a superset of name 929 matches recognized by the algorithm specified above. 931 4.1.2.5 Validity 933 The certificate validity period is the time interval during which the 934 CA warrants that it will maintain information about the status of the 935 certificate. The field is represented as a SEQUENCE of two dates: 936 the date on which the certificate validity period begins (notBefore) 937 and the date on which the certificate validity period ends 938 (notAfter). Both notBefore and notAfter may be encoded as UTCTime or 939 GeneralizedTime. 941 CAs conforming to this profile shall always encode certificate vali- 942 dity dates through the year 2049 as UTCTime; certificate validity 943 dates in 2050 or later shall be encoded as GeneralizedTime. 945 4.1.2.5.1 UTCTime 947 The universal time type, UTCTime, is a standard ASN.1 type intended 948 for international applications where local time alone is not ade- 949 quate. UTCTime specifies the year through the two low order digits 950 and time is specified to the precision of one minute or one second. 951 UTCTime includes either Z (for Zulu, or Greenwich Mean Time) or a 952 time differential. 954 For the purposes of this profile, UTCTime values shall be expressed 955 Greenwich Mean Time (Zulu) and shall include seconds (i.e., times are 956 YYMMDDHHMMSSZ), even where the number of seconds is zero. Conforming 957 systems shall interpret the year field (YY) as follows: 959 Where YY is greater than or equal to 50, the year shall be inter- 960 preted as 19YY; and 962 Where YY is less than 50, the year shall be interpreted as 20YY. 964 4.1.2.5.2 GeneralizedTime 966 The generalized time type, GeneralizedTime, is a standard ASN.1 type 967 for variable precision representation of time. Optionally, the Gen- 968 eralizedTime field can include a representation of the time differen- 969 tial between local and Greenwich Mean Time. 971 For the purposes of this profile, GeneralizedTime values shall be 972 expressed Greenwich Mean Time (Zulu) and shall include seconds (i.e., 973 times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. 974 GeneralizedTime values shall not include fractional seconds. 976 4.1.2.6 Subject 978 The subject field identifies the entity associated with the public 979 key stored in the subject public key field. The subject name may be 980 carried in the subject field and/or the subjectAltName extension. If 981 the subject is a CA (e.g., the basic constraints extension, as dis- 982 cussed in 4.2.1.10, is present and the value of cA is TRUE,) then the 983 subject field shall be populated with a non-empty distinguished name 984 matching the contents of the issuer field (see sec. 4.1.2.4) in all 985 certificates issued by the subject CA. If subject naming information 986 is present only in the subjectAltName extension (e.g., a key bound 987 only to an email address or URI), then the subject name shall be an 988 empty sequence and the subjectAltName extension shall be critical. 990 Where it is non-empty, the subject field shall contain an X.500 dis- 991 tinguished name (DN). The DN shall be unique for each subject entity 992 certified by the one CA as defined by the issuer name field. A CA may 993 issue more than one certificate with the same DN to the same subject 994 entity. 996 The subject name field is defined as the X.501 type Name. Implemen- 997 tation requirements for this field are those defined for the issuer 998 field (see sec. 4.1.2.4). When encoding attribute values of type 999 DirectoryString, the encoding rules for the issuer field shall be 1000 implemented. Implementations of this specification shall be prepared 1001 to receive subject names containing the attribute types required for 1002 the issuer field. Implementations of this specification should be 1003 prepared to receive subject names containing the recommended attri- 1004 bute types for the issuer field. The syntax and associated object 1005 identifiers (OIDs) for these attribute types are provided in the 1006 ASN.1 modules in Appendices A and B. 1008 In addition, legacy implementations exist where an RFC 822 name is 1009 embedded in the subject distinguished name as an EmailAddress attri- 1010 bute. The attribute value for EmailAddress is of type IA5String to 1011 permit inclusion of the character '@', which is not part of the 1012 PrintableString character set. EmailAddress attribute values are not 1013 case sensitive (e.g., "fanfeedback@redsox.com" is the same as 1014 "FANFEEDBACK@REDSOX.COM"). 1016 Conforming implementations generating new certificates with elec- 1017 tronic mail addresses shall use the rfc822Name in the subject alter- 1018 native name field (see sec. 4.2.1.7) to describe such identities. 1019 Simultaneous inclusion of the EmailAddress attribute in the subject 1020 distinguished name to support legacy implementations is deprecated 1021 but permitted. 1023 4.1.2.7 Subject Public Key Info 1025 This field is used to carry the public key and identify the algorithm 1026 with which the key is used. The algorithm is identified using the 1027 AlgorithmIdentifier structure specified in section 4.1.1.2. The 1028 object identifiers for the supported algorithms and the methods for 1029 encoding the public key materials (public key and parameters) are 1030 specified in section 7.3. 1032 4.1.2.8 Unique Identifiers 1034 These fields may only appear if the version is 2 or 3 (see sec. 1035 4.1.2.1). The subject and issuer unique identifiers are present in 1036 the certificate to handle the possibility of reuse of subject and/or 1037 issuer names over time. This profile recommends that names not be 1038 reused for different entities and that Internet certificates not make 1039 use of unique identifiers. CAs conforming to this profile should not 1040 generate certificates with unique identifiers. Applications conform- 1041 ing to this profile should be capable of parsing unique identifiers 1042 and making comparisons. 1044 4.1.2.9 Extensions 1046 This field may only appear if the version is 3 (see sec. 4.1.2.1). 1047 If present, this field is a SEQUENCE of one or more certificate 1048 extensions. The format and content of certificate extensions in the 1049 Internet PKI is defined in section 4.2. 1051 4.2 Standard Certificate Extensions 1053 The extensions defined for X.509 v3 certificates provide methods for 1054 associating additional attributes with users or public keys and for 1055 managing the certification hierarchy. The X.509 v3 certificate for- 1056 mat also allows communities to define private extensions to carry 1057 information unique to those communities. Each extension in a certi- 1058 ficate may be designated as critical or non-critical. A certificate 1059 using system shall reject the certificate if it encounters a critical 1060 extension it does not recognize; however, a non-critical extension 1061 may be ignored if it is not recognized. The following sections 1062 present recommended extensions used within Internet certificates and 1063 standard locations for information. Communities may elect to use 1064 additional extensions; however, caution should be exercised in adopt- 1065 ing any critical extensions in certificates which might prevent use 1066 in a general context. 1068 Each extension includes an OID and an ASN.1 structure. When an 1069 extension appears in a certificate, the OID appears as the field 1070 extnID and the corresponding ASN.1 encoded structure is the value of 1071 the octet string extnValue. Only one instance of a particular exten- 1072 sion may appear in a particular certificate. For example, a certifi- 1073 cate may contain only one authority key identifier extension (see 1074 sec. 4.2.1.1). An extension includes the boolean critical, with a 1075 default value of FALSE. The text for each extension specifies the 1076 acceptable values for the critical field. 1078 Conforming CAs are required to support key identifiers (see sec. 1079 4.2.1.1 and 4.2.1.2), basic constraints (see sec. 4.2.1.10), key 1080 usage (see sec. 4.2.1.3), and certificate policies (see sec. 4.2.1.5) 1081 extensions. If the CA issues certificates with an empty sequence for 1082 the subject field, the CA shall support the subject alternative name 1083 extension (see sec. 4.2.1.7). Support for the remaining extensions 1084 is optional. Conforming CAs may support extensions that are not iden- 1085 tified within this specification; certificate issuers are cautioned 1086 that marking such extensions as critical may inhibit interoperabil- 1087 ity. 1089 At a minimum, applications conforming to this profile shall recognize 1090 the extensions which shall or may be critical in this specification. 1091 These extensions are: key usage (see sec. 4.2.1.3), certificate pol- 1092 icies (see sec. 4.2.1.5), the subject alternative name (see sec. 1093 4.2.1.7), basic constraints (see sec. 4.2.1.10), name constraints 1094 (see sec. 4.2.1.11), policy constraints (see sec. 4.2.1.12), and 1095 extended key usage (see sec. 4.2.1.13). 1097 In addition, this profile recommends application support for key 1098 identifiers (see sec. 4.2.1.1 and 4.2.1.2) extensions. 1100 4.2.1 Standard Extensions 1102 This section identifies standard certificate extensions defined in 1103 [X.509] for use in the Internet PKI. Each extension is associated 1104 with an OID defined in [X.509]. These OIDs are members of the id-ce 1105 arc, which is defined by the following: 1107 id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 1109 4.2.1.1 Authority Key Identifier 1111 The authority key identifier extension provides a means of identify- 1112 ing the public key corresponding to the private key used to sign a 1113 certificate. This extension is used where an issuer has multiple 1114 signing keys (either due to multiple concurrent key pairs or due to 1115 changeover). The identification may be based on either the key iden- 1116 tifier (the subject key identifier in the issuer's certificate) or on 1117 the issuer name and serial number. 1119 The keyIdentifier field of the authorityKeyIdentifier extension shall 1120 be included in all certificates generated by conforming CAs to facil- 1121 itate chain building. There is one exception; where a CA distributes 1122 its public key in the form of a "self-signed" certificate, the 1123 authority key identifier may be omitted. In this case, the subject 1124 and authority key identifiers would be identical. 1126 This field of the keyIdentifier field should be derived from the pub- 1127 lic key used to verify the certificate's signature. Two common 1128 methods for generating key identifiers are described in (sec. 1129 4.2.1.2). 1131 This profile recommends support for the key identifier method by all 1132 certificate users. 1134 This extension shall not be marked critical. 1136 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 1138 AuthorityKeyIdentifier ::= SEQUENCE { 1139 keyIdentifier [0] KeyIdentifier OPTIONAL, 1140 authorityCertIssuer [1] GeneralNames OPTIONAL, 1141 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 1143 KeyIdentifier ::= OCTET STRING 1145 4.2.1.2 Subject Key Identifier 1147 The subject key identifier extension provides a means of identifying 1148 the particular public key used in an application. This extension 1149 should be included in all certificates. 1151 To facilitate chain building, this extension shall appear in all con- 1152 forming CA certificates, that is, all certificates including the 1153 basic constraints extension (see sec. 4.2.1.10) where the value of cA 1154 is TRUE. The value of the subject key identifier shall be the value 1155 placed in the key identifier field of the Authority Key Identifier 1156 extension (see sec. 4.2.1.1) of certificates issued by the subject of 1157 this certificate. 1159 Key identifiers should be derived from the public key. Two common 1160 methods for generating key identifiers are: 1162 (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the 1163 BIT STRING subjectPublicKey. 1165 (2) The keyIdentifier is composed of a four bit type field with 1166 the value 0100 followed by the least significant 60 bits of the 1167 SHA-1 hash of the BIT STRING subjectPublicKey. 1169 Where a key identifier has not been previously established, this 1170 specification recommends use of one of these methods for generating 1171 keyIdentifiers. 1173 This extension shall not be marked critical. 1175 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 1177 SubjectKeyIdentifier ::= KeyIdentifier 1179 4.2.1.3 Key Usage 1181 The key usage extension defines the purpose (e.g., encipherment, sig- 1182 nature, certificate signing) of the key contained in the certificate. 1183 The usage restriction might be employed when a key that could be used 1184 for more than one operation is to be restricted. For example, when 1185 an RSA key should be used only for signing, the digitalSignature 1186 and/or nonRepudiation bits would be asserted. Likewise, when an RSA 1187 key should be used only for key management, the keyEncipherment bit 1188 would be asserted. When used, this extension should be marked criti- 1189 cal. 1191 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 1193 KeyUsage ::= BIT STRING { 1194 digitalSignature (0), 1195 nonRepudiation (1), 1196 keyEncipherment (2), 1197 dataEncipherment (3), 1198 keyAgreement (4), 1199 keyCertSign (5), 1200 cRLSign (6), 1201 encipherOnly (7), 1202 decipherOnly (8) } 1204 Bits in the KeyUsage type are used as follows: 1206 The digitalSignature bit is asserted when the subject public key 1207 is used with a digital signature mechanism to support security 1208 services other than non-repudiation (bit 1), certificate signing 1209 (bit 5), or revocation information signing (bit 6). Digital signa- 1210 ture mechanisms are often used for entity authentication and data 1211 origin authentication with integrity. 1213 The nonRepudiation bit is asserted when the subject public key is 1214 used to verify digital signatures used to provide a non- 1215 repudiation service which protects against the signing entity 1216 falsely denying some action, excluding certificate or CRL signing. 1218 The keyEncipherment bit is asserted when the subject public key is 1219 used for key transport. For example, when an RSA key is to be 1220 used for key management, then this bit shall asserted. 1222 The dataEncipherment bit is asserted when the subject public key 1223 is used for enciphering user data, other than cryptographic keys. 1225 The keyAgreement bit is asserted when the subject public key is 1226 used for key agreement. For example, when a Diffie-Hellman key is 1227 to be used for key management, then this bit shall asserted. 1229 The keyCertSign bit is asserted when the subject public key is 1230 used for verifying a signature on certificates. This bit may only 1231 be asserted in CA certificates. 1233 The cRLSign bit is asserted when the subject public key is used 1234 for verifying a signature on revocation information (e.g., a CRL). 1236 The meaning of the encipherOnly bit is undefined in the absence of 1237 the keyAgreement bit. When the encipherOnly bit is asserted and 1238 the keyAgreement bit is also set, the subject public key may be 1239 used only for enciphering data while performing key agreement. 1241 The meaning of the decipherOnly bit is undefined in the absence of 1242 the keyAgreement bit. When the decipherOnly bit is asserted and 1243 the keyAgreement bit is also set, the subject public key may be 1244 used only for deciphering data while performing key agreement. 1246 This profile does not restrict the combinations of bits that may be 1247 set in an instantiation of the keyUsage extension. However, 1248 appropriate values for keyUsage extensions for particular algorithms 1249 are specified in section 7.3. 1251 4.2.1.4 Private Key Usage Period 1253 This profile recommends against the use of this extension. CAs con- 1254 forming to this profile shall not generate certificates with critical 1255 private key usage period extensions. 1257 The private key usage period extension allows the certificate issuer 1258 to specify a different validity period for the private key than the 1259 certificate. This extension is intended for use with digital signa- 1260 ture keys. This extension consists of two optional components, 1261 notBefore and notAfter. The private key associated with the certifi- 1262 cate should not be used to sign objects before or after the times 1263 specified by the two components, respectively. CAs conforming to this 1264 profile shall not generate certificates with private key usage period 1265 extensions unless at least one of the two components is present. 1267 Where used, notBefore and notAfter are represented as GeneralizedTime 1268 and shall be specified and interpreted as defined in section 1269 4.1.2.5.2. 1271 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 1273 PrivateKeyUsagePeriod ::= SEQUENCE { 1274 notBefore [0] GeneralizedTime OPTIONAL, 1275 notAfter [1] GeneralizedTime OPTIONAL } 1277 4.2.1.5 Certificate Policies 1279 The certificate policies extension contains a sequence of one or more 1280 policy information terms, each of which consists of an object iden- 1281 tifier (OID) and optional qualifiers. These policy information terms 1282 indicate the policy under which the certificate has been issued and 1283 the purposes for which the certificate may be used. Optional qualif- 1284 iers, which may be present, are not expected to change the definition 1285 of the policy. 1287 Applications with specific policy requirements are expected to have a 1288 list of those policies which they will accept and to compare the pol- 1289 icy OIDs in the certificate to that list. If this extension is crit- 1290 ical, the path validation software shall be able to interpret this 1291 extension (including the optional qualifier), or shall reject the 1292 certificate. 1294 To promote interoperability, this profile recommends that policy 1295 information terms consist of only an OID. Where an OID alone is 1296 insufficient, this profile strongly recommends that use of qualifiers 1297 be limited to those identified in this section. 1299 This specification defines two policy qualifier types for use by cer- 1300 tificate policy writers and certificate issuers. The qualifier types 1301 are the CPS Pointer and User Notice qualifiers. 1303 The CPS Pointer qualifier contains a pointer to a Certification Prac- 1304 tice Statement (CPS) published by the CA. The pointer is in the form 1305 of a URI. 1307 User notice is intended for display to a relying party when a certi- 1308 ficate is used. The application software should display all user 1309 notices in all certificates of the certification path used, except 1310 that if a notice is duplicated only one copy need be displayed. To 1311 prevent such duplication, this qualifier should only be present in 1312 end-entity certificates and CA certificates issued to other organiza- 1313 tions. 1315 The user notice has two optional fields: the noticeRef field and the 1316 explicitText field. 1318 The noticeRef field, if used, names an organization and identi- 1319 fies, by number, a particular textual statement prepared by that 1320 organization. For example, it might identify the organization 1321 "CertsRUs" and notice number 1. In a typical implementation, the 1322 application software will have a notice file containing the 1323 current set of notices for CertsRUs; the application will extract 1324 the notice text from the file and display it. Messages may be 1325 multilingual, allowing the software to select the particular 1326 language message for its own environment. 1328 An explicitText field includes the textual statement directly in 1329 the certificate. The explicitText field is a string with a max- 1330 imum size of 200 characters. 1332 If both the noticeRef and explicitText options are included in the 1333 one qualifier and if the application software can locate the notice 1334 text indicated by the noticeRef option then that text should be 1335 displayed; otherwise, the explicitText string should be displayed. 1337 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 1339 certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 1341 PolicyInformation ::= SEQUENCE { 1342 policyIdentifier CertPolicyId, 1343 policyQualifiers SEQUENCE SIZE (1..MAX) OF 1344 PolicyQualifierInfo OPTIONAL } 1346 CertPolicyId ::= OBJECT IDENTIFIER 1347 PolicyQualifierInfo ::= SEQUENCE { 1348 policyQualifierId PolicyQualifierId, 1349 qualifier ANY DEFINED BY policyQualifierId } 1351 -- policyQualifierIds for Internet policy qualifiers 1353 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 1354 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 1355 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 1357 PolicyQualifierId ::= 1358 OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) 1360 Qualifier ::= CHOICE { 1361 cPSuri CPSuri, 1362 userNotice UserNotice } 1364 CPSuri ::= IA5String 1366 UserNotice ::= SEQUENCE { 1367 noticeRef NoticeReference OPTIONAL, 1368 explicitText DisplayText OPTIONAL} 1370 NoticeReference ::= SEQUENCE { 1371 organization DisplayText, 1372 noticeNumbers SEQUENCE OF INTEGER } 1374 DisplayText ::= CHOICE { 1375 visibleString VisibleString (SIZE (1..200)), 1376 bmpString BMPString (SIZE (1..200)), 1377 utf8String UTF8String (SIZE (1..200)) } 1379 4.2.1.6 Policy Mappings 1381 This extension is used in CA certificates. It lists one or more 1382 pairs of OIDs; each pair includes an issuerDomainPolicy and a sub- 1383 jectDomainPolicy. The pairing indicates the issuing CA considers its 1384 issuerDomainPolicy equivalent to the subject CA's subjectDomainPol- 1385 icy. 1387 The issuing CA's users may accept an issuerDomainPolicy for certain 1388 applications. The policy mapping tells the issuing CA's users which 1389 policies associated with the subject CA are comparable to the policy 1390 they accept. 1392 This extension may be supported by CAs and/or applications, and it is 1393 always non-critical. 1395 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 1397 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 1398 issuerDomainPolicy CertPolicyId, 1399 subjectDomainPolicy CertPolicyId } 1401 4.2.1.7 Subject Alternative Name 1403 The subject alternative names extension allows additional identities 1404 to be bound to the subject of the certificate. Defined options 1405 include an Internet electronic mail address, a DNS name, an IP 1406 address, and a uniform resource identifier (URI). Other options 1407 exist, including completely local definitions. Multiple name forms, 1408 and multiple instances of each name form, may be included. Whenever 1409 such identities are to be bound into a certificate, the subject 1410 alternative name (or issuer alternative name) extension shall be 1411 used. 1413 Because the subject alternative name is considered to be defini- 1414 tiviely bound to the public key, all parts of the subject alternative 1415 name shall be verified by the CA. 1417 Further, if the only subject identity included in the certificate is 1418 an alternative name form (e.g., an electronic mail address), then the 1419 subject distinguished name shall be empty (an empty sequence), and 1420 the subjectAltName extension shall be present. If the subject field 1421 contains an empty sequence, the subjectAltName extension shall be 1422 marked critical. 1424 When the subjectAltName extension contains an Internet mail address, 1425 the adress shall be included as an rfc822Name. The format of an 1426 rfc822Name is an "addr-spec" as defined in RFC 822 [RFC 822]. An 1427 addr-spec has the form "local-part@domain". Note that an addr-spec 1428 has no phrase (such as a common name) before it, has no comment (text 1429 surrounded in parentheses) after it, and is not surrounded by "<" and 1430 ">". Note that while upper and lower case letters are allowed in an 1431 RFC 822 addr-spec, no significance is attached to the case. 1433 When the subjectAltName extension contains a iPAddress, the address 1434 shall be stored in the octet string in "network byte order," as 1435 specified in RFC 791 [RFC 791]. The least significant bit (LSB) of 1436 each octet is the LSB of the corresponding byte in the network 1437 address. For IP Version 4, as specified in RFC 791, the octet string 1438 shall contain exactly four octets. For IP Version 6, as specified in 1439 RFC 1883, the octet string shall contain exactly sixteen octets [RFC 1440 1883]. 1442 When the subjectAltName extension contains a domain name service 1443 label, the domain name shall be stored in the dNSName (an IA5String). 1444 The name shall be in the "preferred name syntax," as specified by RFC 1445 1034 [RFC 1034]. Note that while upper and lower case letters are 1446 allowed in domain names, no signifigance is attached to the case. In 1447 addition, while the string " " is a legal domain name, subjectAltName 1448 extensions with a dNSName " " are not permitted. Finally, the use of 1449 the DNS representation for Internet mail addresses (wpolk.nist.gov 1450 instead of wpolk@nist.gov) is not permitted; such identities are to 1451 be encoded as rfc822Name. 1453 When the subjectAltName extension contains a URI, the name shall be 1454 stored in the uniformResourceIdentifier (an IA5String). The name 1455 shall be a non-relative URL, and shall follow the URL syntax and 1456 encoding rules specified in [RFC 1738]. The name must include both a 1457 scheme (e.g., "http" or "ftp") and a scheme-specific-part. The 1458 scheme-specific-part must include a fully qualified domain name or IP 1459 address as the host. 1461 As specified in [RFC 1738], the scheme name is not case-sensitive 1462 (e.g., "http" is equivalent to "HTTP"). The host part is also not 1463 case-sensitive, but other components of the scheme-specific-part may 1464 be case-sensitive. When comparing URIs, conforming implementations 1465 shall compare the scheme and host without regard to case, but assume 1466 the remainder of the scheme-specific-part is case sensitive. 1468 Subject alternative names may be constrained in the same manner as 1469 subject distinguished names using the name constraints extension as 1470 described in section 4.2.1.11. 1472 If the subjectAltName extension is present, the sequence shall con- 1473 tain at least one entry. Unlike the subject field, conforming CAs 1474 shall not issue certificates with subjectAltNames containing empty 1475 GeneralName fields. For example, an rfc822Name is represented as an 1476 IA5String. While an empty string is a valid IA5String, such an 1477 rfc822Name is not permitted by this profile. The behavior of clients 1478 that encounter such a certificate when processing a certificication 1479 path is not defined by this profile. 1481 Finally, the semantics of subject alternative names that include 1482 wildcard characters (e.g., as a placeholder for a set of names) are 1483 not addressed by this specification. Applications with specific 1484 requirements may use such names but shall define the semantics. 1486 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 1488 SubjectAltName ::= GeneralNames 1489 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 1491 GeneralName ::= CHOICE { 1492 otherName [0] OtherName, 1493 rfc822Name [1] IA5String, 1494 dNSName [2] IA5String, 1495 x400Address [3] ORAddress, 1496 directoryName [4] Name, 1497 ediPartyName [5] EDIPartyName, 1498 uniformResourceIdentifier [6] IA5String, 1499 iPAddress [7] OCTET STRING, 1500 registeredID [8] OBJECT IDENTIFIER} 1502 OtherName ::= SEQUENCE { 1503 type-id OBJECT IDENTIFIER, 1504 value [0] EXPLICIT ANY DEFINED BY type-id } 1506 EDIPartyName ::= SEQUENCE { 1507 nameAssigner [0] DirectoryString OPTIONAL, 1508 partyName [1] DirectoryString } 1510 4.2.1.8 Issuer Alternative Names 1512 As with 4.2.1.7, this extension is used to associate Internet style 1513 identities with the certificate issuer. Issuer alternative names 1514 shall be encoded as in 4.2.1.7. 1516 Where present, this extension should not be marked critical. 1518 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 1520 IssuerAltName ::= GeneralNames 1522 4.2.1.9 Subject Directory Attributes 1524 The subject directory attributes extension is not recommended as an 1525 essential part of this profile, but it may be used in local environ- 1526 ments. This extension is always non-critical. 1528 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 1530 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 1532 4.2.1.10 Basic Constraints 1534 The basic constraints extension identifies whether the subject of the 1535 certificate is a CA and how deep a certification path may exist 1536 through that CA. 1538 The pathLenConstraint field is meaningful only if cA is set to TRUE. 1539 In this case, it gives the maximum number of CA certificates that may 1540 follow this certificate in a certification path. A value of zero 1541 indicates that only an end-entity certificate may follow in the path. 1542 Where it appears, the pathLenConstraint field shall be greater than 1543 or equal to zero. Where pathLenConstraint does not appear, there is 1544 no limit to the allowed length of the certification path. 1546 This extension shall appear as a critical extension in all CA certi- 1547 ficates. This extension should not appear in end entity certifi- 1548 cates. 1550 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 1552 BasicConstraints ::= SEQUENCE { 1553 cA BOOLEAN DEFAULT FALSE, 1554 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 1556 4.2.1.11 Name Constraints 1558 The name constraints extension, which shall be used only in a CA cer- 1559 tificate, indicates a name space within which all subject names in 1560 subsequent certificates in a certification path shall be located. 1561 Restrictions may apply to the subject distinguished name or subject 1562 alternative names. Restrictions apply only when the specified name 1563 form is present. If no name of the type is in the certificate, the 1564 certificate is acceptable. 1566 Restrictions are defined in terms of permitted or excluded name sub- 1567 trees. Any name matching a restriction in the excludedSubtrees field 1568 is invalid regardless of information appearing in the permittedSub- 1569 trees. This extension shall be critical. 1571 Within this profile, the minimum and maximum fields are not used with 1572 any name forms, thus minimum is always zero, and maximum is always 1573 absent. 1575 For URIs, the constraint applies to the host part of the name. The 1576 constraint may specify a host or a domain. Examples would be 1577 "foo.bar.com"; and ".xyz.com". When the the constraint begins with 1578 a period, it may be expanded with one or more subdomains. That is, 1579 the constraint ".xyz.com" is satisfied by both abc.xyz.com and 1580 abc.def.xyz.com. However, the constraint ".xyz.com" is not satisfied 1581 by "xyz.com". When the constraint does not begin with a period, it 1582 specifies a host. 1584 A name constraint for Internat mail addresses may specify a particu- 1585 lar mailbox, all addresses at a particular host, or all mailboxes in 1586 a domain. To indicate a particular mailbox, the constraint is the 1587 complete mail address. For example, "root@xyz.com" indicates the 1588 root mailbox on the host "xyz.com". To indicate all Internet mail 1589 addresses on a particular host, the constraint is specified as the 1590 host name. For example, the constraint "xyz.com" is satisfied by any 1591 mail address at the host "xyz.com". To specify any address within a 1592 domain, the constraint is specified with a leading period (as with 1593 URIs). For example, ".xyz.com" indicates all the Internet mail 1594 addresses in the domain "xyz.com", but Internet mail addresses on the 1595 host "xyz.com". 1597 DNS name restrictions are expressed as foo.bar.com. Any DNS name that 1598 can be constructed by simply adding to the left hand side of the name 1599 satisfies the name constraint. For example, www.foo.bar.com would 1600 satisfy the constraint but foo1.bar.com would not. 1602 Legacy implementations exist where an RFC 822 name is embedded in the 1603 subject distinguished name in an attribute of type EmailAddress (see 1604 sec. 4.1.2.6). When rfc822 names are constrained, but the certificate 1605 does not include a subject alternative name, the rfc822 name con- 1606 straint shall be applied to the attribute of type EmailAddress in the 1607 subject distinguished name. The ASN.1 syntax for EmailAddress and 1608 the corresponding OID are supplied in Appendix A and B. 1610 Restrictions of the form directoryName shall be applied to the sub- 1611 ject field in the certificate and to the subjectAltName extensions of 1612 type directoryName. Restrictions of the form x400Address shall be 1613 applied to subjectAltName extensions of type x400Address. 1615 When applying restrictions of the form directoryName, an implementa- 1616 tion shall compare DN attributes. At a minimum, implementations 1617 shall perform the DN comparison rules specified in Section 4.1.2.4. 1618 CAs issuing certificates with a restriction of the form directoryName 1619 should not rely on implementation of the full ISO DN name comparison 1620 algorithm. This implies name restrictions shall be stated identi- 1621 cally to the encoding used in the subject field or subjectAltName 1622 extension. 1624 The syntax of iPAddress shall be as described in section 4.2.1.7 with 1625 the following additions specifically for Name Constraints. For IPv4 1626 addresses, the ipAddress field of generalName shall contain eight (8) 1627 octets, encoded in the style of RFC 1519 (CIDR) to represent an 1628 address range.[RFC 1519] For IPv6 addresses, the ipAddress field 1629 shall contain 32 octets similarly encoded. For example, a name con- 1630 straint for "class C" subnet 10.9.8.0 shall be represented as the 1631 octets 0A 09 08 00 FF FF FF 00, representing the CIDR notation 1632 10.9.8.0/255.255.255.0. 1634 The syntax and semantics for name constraints for otherName, ediPar- 1635 tyName, and registeredID are not defined by this specification. 1637 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 1639 NameConstraints ::= SEQUENCE { 1640 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 1641 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 1643 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 1645 GeneralSubtree ::= SEQUENCE { 1646 base GeneralName, 1647 minimum [0] BaseDistance DEFAULT 0, 1648 maximum [1] BaseDistance OPTIONAL } 1650 BaseDistance ::= INTEGER (0..MAX) 1652 4.2.1.12 Policy Constraints 1654 The policy constraints extension can be used in certificates issued 1655 to CAs. The policy constraints extension constrains path validation 1656 in two ways. It can be used to prohibit policy mapping or require 1657 that each certificate in a path contain an acceptable policy identif- 1658 ier. 1660 If the inhibitPolicyMapping field is present, the value indicates the 1661 number of additional certificates that may appear in the path before 1662 policy mapping is no longer permitted. For example, a value of one 1663 indicates that policy mapping may be processed in certificates issued 1664 by the subject of this certificate, but not in additional certifi- 1665 cates in the path. 1667 If the requireExplicitPolicy field is present, subsequent certifi- 1668 cates shall include an acceptable policy identifier. The value of 1669 requireExplicitPolicy indicates the number of additional certificates 1670 that may appear in the path before an explicit policy is required. 1671 An acceptable policy identifier is the identifier of a policy 1672 required by the user of the certification path or the identifier of a 1673 policy which has been declared equivalent through policy mapping. 1675 Conforming CAs shall not issue certificates where policy constraints 1676 is a null sequence. That is, at least one of the inhibitPolicyMapping 1677 field or the requireExplicitPolicy field shall be present. The 1678 behavior of clients that encounter a null policy constraints field is 1679 not addressed in this profile. 1681 This extension may be critical or non-critical. 1683 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } 1685 CertificatePoliciesSyntax ::= 1686 SEQUENCE SIZE (1..MAX) OF PolicyInformation 1688 PolicyConstraints ::= SEQUENCE { 1689 requireExplicitPolicy [0] SkipCerts OPTIONAL, 1690 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 1692 SkipCerts ::= INTEGER (0..MAX) 1694 4.2.1.13 Extended key usage field 1696 This field indicates one or more purposes for which the certified 1697 public key may be used, in addition to or in place of the basic pur- 1698 poses indicated in the key usage extension field. This field is 1699 defined as follows: 1701 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 1703 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 1705 KeyPurposeId ::= OBJECT IDENTIFIER 1707 Key purposes may be defined by any organization with a need. Object 1708 identifiers used to identify key purposes shall be assigned in accor- 1709 dance with IANA or ITU-T Rec. X.660 | ISO/IEC/ITU 9834-1. 1711 This extension may, at the option of the certificate issuer, be 1712 either critical or non-critical. 1714 If the extension is flagged critical, then the certificate shall be 1715 used only for one of the purposes indicated. 1717 If the extension is flagged non-critical, then it indicates the 1718 intended purpose or purposes of the key, and may be used in finding 1719 the correct key/certificate of an entity that has multiple 1720 keys/certificates. It is an advisory field and does not imply that 1721 usage of the key is restricted by the certification authority to the 1722 purpose indicated. Certificate using applications may nevertheless 1723 require that a particular purpose be indicated in order for the cer- 1724 tificate to be acceptable to that application. 1726 If a certificate contains both a critical key usage field and a crit- 1727 ical extended key usage field, then both fields shall be processed 1728 independently and the certificate shall only be used for a purpose 1729 consistent with both fields. If there is no purpose consistent with 1730 both fields, then the certificate shall not be used for any purpose. 1732 The following key usage purposes are defined by this profile: 1734 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 1736 id-kp-serverAuth OBJECT IDENTIFIER ::= {id-kp 1} 1737 -- TLS Web server authentication 1738 -- Key usage bits that may be consistent: digitalSignature, 1739 -- keyEncipherment or keyAgreement 1740 -- 1741 id-kp-clientAuth OBJECT IDENTIFIER ::= {id-kp 2} 1742 -- TLS Web client authentication 1743 -- Key usage bits that may be consistent: digitalSignature and/or 1744 -- keyAgreement 1745 -- 1746 id-kp-codeSigning OBJECT IDENTIFIER ::= {id-kp 3} 1747 -- Signing of downloadable executable code 1748 -- Key usage bits that may be consistent: digitalSignature 1749 -- 1750 id-kp-emailProtection OBJECT IDENTIFIER ::= {id-kp 4} 1751 -- E-mail protection 1752 -- Key usage bits that may be consistent: digitalSignature, 1753 -- nonRepudiation, and/or (keyEncipherment 1754 -- or keyAgreement) 1755 -- 1756 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 1757 -- Binding the hash of an object to a time from an agreed-upon time 1758 -- source. Key usage bits that may be consistent: digitalSignature, 1759 -- nonRepudiation 1761 4.2.1.14 CRL Distribution Points 1763 The CRL distribution points extension identifies how CRL information 1764 is obtained. The extension should be non-critical, but this profile 1765 recommends support for this extension by CAs and applications. 1766 Further discussion of CRL management is contained in section 5. 1768 If the cRLDistributionPoints extension contains a Distribution- 1769 PointName of type URI, the following semantics shall be assumed: the 1770 URI is a pointer to the current CRL for the associated reasons and 1771 will be issued by the associated cRLIssuer. The expected values for 1772 the URI are those defined in 4.2.1.7. Processing rules for other 1773 values are not defined by this specification. If the distribution- 1774 Point omits reasons, the CRL shall include revocations for all rea- 1775 sons. If the distributionPoint omits cRLIssuer, the CRL shall be 1776 issued by the CA that issued the certificate. 1778 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 } 1779 cRLDistributionPoints ::= { 1780 CRLDistPointsSyntax } 1782 CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 1784 DistributionPoint ::= SEQUENCE { 1785 distributionPoint [0] DistributionPointName OPTIONAL, 1786 reasons [1] ReasonFlags OPTIONAL, 1787 cRLIssuer [2] GeneralNames OPTIONAL } 1789 DistributionPointName ::= CHOICE { 1790 fullName [0] GeneralNames, 1791 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 1793 ReasonFlags ::= BIT STRING { 1794 unused (0), 1795 keyCompromise (1), 1796 cACompromise (2), 1797 affiliationChanged (3), 1798 superseded (4), 1799 cessationOfOperation (5), 1800 certificateHold (6) } 1802 4.2.2 Private Internet Extensions 1804 This section defines one new extension for use in the Internet Public 1805 Key Infrastructure. This extension may be used to direct applica- 1806 tions to identify an on-line validation service supporting the issu- 1807 ing CA. As the information may be available in multiple forms, each 1808 extension is a sequence of IA5String values, each of which represents 1809 a URI. The URI implicitly specifies the location and format of the 1810 information and the method for obtaining the information. 1812 An object identifier is defined for the private extension. The 1813 object identifier associated with the private extension is defined 1814 under the arc id-pe within the id-pkix name space. Any future exten- 1815 sions defined for the Internet PKI will also be defined uder the arc 1816 id-pe. 1818 id-pkix OBJECT IDENTIFIER ::= 1819 { iso(1) identified-organization(3) dod(6) internet(1) 1820 security(5) mechanisms(5) pkix(7) } 1822 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 1824 4.2.2.1 Authority Information Access 1826 The authority information access extension indicates how to access CA 1827 information and services for the issuer of the certificate in which 1828 the extension appears. Information and services may include on-line 1829 validation services and CA policy data. (The location of CRLs is not 1830 specified in this extension; that information is provided by the 1831 cRLDistributionPoints extension.) This extension may be included in 1832 subject or CA certificates, and it is always non-critical. 1834 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 1836 AuthorityInfoAccessSyntax ::= 1837 SEQUENCE SIZE (1..MAX) OF AccessDescription 1839 AccessDescription ::= SEQUENCE { 1840 accessMethod OBJECT IDENTIFIER, 1841 accessLocation GeneralName } 1843 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 1845 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 1847 Each entry in the sequence AuthorityInfoAccessSyntax describes the 1848 format and location of additional information about the CA who issued 1849 the certificate in which this extension appears. The type and format 1850 of the information is specified by the accessMethod field; the 1851 accessLocation field specifies the location of the information. The 1852 retrieval mechanism may be implied by the accessMethod or specified 1853 by accessLocation. 1855 This profile defines one OID for accessMethod. The id-ad-caIssuers 1856 OID is used when the additional information lists CAs that have 1857 issued certificates superior to the CA that issued the certificate 1858 containing this extension. The referenced CA Issuers description is 1859 intended to aid certificate users in the selection of a certification 1860 path that terminates at a point trusted by the certificate user. 1862 When id-ad-caIssuers appears as accessInfoType, the accessLocation 1863 field describes the referenced description server and the access pro- 1864 tocol to obtain the referenced description. The accessLocation field 1865 is defined as a GeneralName, which can take several forms. Where the 1866 information is available via http, ftp, or ldap, accessLocation shall 1867 be a uniformResourceIdentifier. Where the information is available 1868 via the directory access protocol (dap), accessLocation shall be a 1869 directoryName. When the information is available via electronic mail, 1870 accessLocation shall be an rfc822Name. The semantics of other name 1871 forms of accessLocation (when accessMethod is id-ad-caIssuers) are 1872 not defined by this specification. 1874 Additional access descriptors may be defined in other PKIX specifica- 1875 tions. 1877 5 CRL and CRL Extensions Profile 1879 As described above, one goal of this X.509 v2 CRL profile is to 1880 foster the creation of an interoperable and reusable Internet PKI. 1881 To achieve this goal, guidelines for the use of extensions are speci- 1882 fied, and some assumptions are made about the nature of information 1883 included in the CRL. 1885 CRLs may be used in a wide range of applications and environments 1886 covering a broad spectrum of interoperability goals and an even 1887 broader spectrum of operational and assurance requirements. This 1888 profile establishes a common baseline for generic applications 1889 requiring broad interoperability. The profile defines a baseline set 1890 of information that can be expected in every CRL. Also, the profile 1891 defines common locations within the CRL for frequently used attri- 1892 butes as well as common representations for these attributes. 1894 This profile does not define any private Internet CRL extensions or 1895 CRL entry extensions. 1897 Environments with additional or special purpose requirements may 1898 build on this profile or may replace it. 1900 Conforming CAs are not required to issue CRLs if other revocation or 1901 certificate status mechanisms are provided. Conforming CAs that 1902 issue CRLs are required to issue version 2 CRLs, and CAs shall 1903 include the date by which the next CRL will be issued in the nextUp- 1904 date field (see sec. 5.1.2.5). Conforming applications are required 1905 to process version 1 and 2 CRLs. 1907 5.1 CRL Fields 1909 The X.509 v2 CRL syntax is as follows. For signature calculation, 1910 the data that is to be signed is ASN.1 DER encoded. ASN.1 DER encod- 1911 ing is a tag, length, value encoding system for each element. 1913 CertificateList ::= SEQUENCE { 1914 tbsCertList TBSCertList, 1915 signatureAlgorithm AlgorithmIdentifier, 1916 signatureValue BIT STRING } 1918 TBSCertList ::= SEQUENCE { 1919 version Version OPTIONAL, 1920 -- if present, shall be v2 1921 signature AlgorithmIdentifier, 1922 issuer Name, 1923 thisUpdate Time, 1924 nextUpdate Time OPTIONAL, 1925 revokedCertificates SEQUENCE OF SEQUENCE { 1926 userCertificate CertificateSerialNumber, 1927 revocationDate Time, 1928 crlEntryExtensions Extensions OPTIONAL 1929 -- if present, shall be v2 1930 } OPTIONAL, 1931 crlExtensions [0] EXPLICIT Extensions OPTIONAL 1932 -- if present, shall be v2 1933 } 1935 -- Version, Time, CertificateSerialNumber, and Extensions 1936 -- are all defined in the ASN.1 in section 4.1 1938 -- AlgorithmIdentifier is defined in section 4.1.1.2 1940 The following items describe the use of the X.509 v2 CRL in the 1941 Internet PKI. 1943 5.1.1 CertificateList Fields 1945 The CertificateList is a SEQUENCE of three required fields. The 1946 fields are described in detail in the following subsections. 1948 5.1.1.1 tbsCertList 1950 The first field in the sequence is the tbsCertList. This field is 1951 itself a sequence containing the name of the issuer, issue date, 1952 issue date of the next list, the list of revoked certificates, and 1953 optional CRL extensions. Further, each entry on the revoked certifi- 1954 cate list is defined by a sequence of user certificate serial number, 1955 revocation date, and optional CRL entry extensions. 1957 5.1.1.2 signatureAlgorithm 1959 The signatureAlgorithm field contains the algorithm identifier for 1960 the algorithm used by the CA to sign the CertificateList. The field 1961 is of type AlgorithmIdentifier, which is defined in section 4.1.1.2. 1962 Section 7.2 lists the supported algorithms for this specification. 1963 Conforming CAs shall use the algorithm identifiers presented in sec- 1964 tion 7.2 when signing with a supported signature algorithm. 1966 This field shall contain the same algorithm identifier as the signa- 1967 ture field in the sequence tbsCertList (see sec. 5.1.2.2). 1969 5.1.1.3 signatureValue 1971 The signatureValue field contains a digital signature computed upon 1972 the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded tbsCertList 1973 is used as the input to the signature function. This signature value 1974 is then ASN.1 encoded as a BIT STRING and included in the CRL's sig- 1975 natureValue field. The details of this process are specified for each 1976 of the supported algorithms in section 7.2. 1978 5.1.2 Certificate List "To Be Signed" 1980 The certificate list to be signed, or TBSCertList, is a SEQUENCE of 1981 required and optional fields. The required fields identify the CRL 1982 issuer, the algorithm used to sign the CRL, the date and time the CRL 1983 was issued, and the date and time by which the CA will issue the next 1984 CRL. 1986 Optional fields include lists of revoked certificates and CRL exten- 1987 sions. The revoked certificate list is optional to support the case 1988 where a CA has not revoked any unexpired certificates that it has 1989 issued. The profile requires conforming CAs to use the CRL extension 1990 cRLNumber in all CRLs issued. 1992 5.1.2.1 Version 1994 This optional field describes the version of the encoded CRL. When 1995 extensions are used, as required by this profile, this field shall be 1996 present and shall specify version 2 (the integer value is 1). 1998 5.1.2.2 Signature 2000 This field contains the algorithm identifier for the algorithm used 2001 to sign the CRL. Section 7.2 lists OIDs for the most popular signa- 2002 ture algorithms used in the Internet PKI. 2004 This field shall contain the same algorithm identifier as the signa- 2005 tureAlgorithm field in the sequence CertificateList (see section 2006 5.1.1.2). 2008 5.1.2.3 Issuer Name 2010 The issuer name identifies the entity who has signed and issued the 2011 CRL. The issuer identity is carried in the issuer name field. Alter- 2012 native name forms may also appear in the issuerAltName extension (see 2013 sec. 5.2.2). The issuer name field shall contain an X.500 2014 distinguished name (DN). The issuer name field is defined as the 2015 X.501 type Name, and shall follow the encoding rules for the issuer 2016 name field in the certificate (see sec. 4.1.2.4). 2018 5.1.2.4 This Update 2020 This field indicates the issue date of this CRL. ThisUpdate may be 2021 encoded as UTCTime or GeneralizedTime. 2023 CAs conforming to this profile that issue CRLs shall encode thisUp- 2024 date as UTCTime for dates through the year 2049. CAs conforming to 2025 this profile that issue CRLs shall encode thisUpdate as Generalized- 2026 Time for dates in the year 2050 or later. 2028 Where encoded as UTCTime, thisUpdate shall be specified and inter- 2029 preted as defined in section 4.1.2.5.1. Where encoded as General- 2030 izedTime, thisUpdate shall be specified and interpreted as defined in 2031 section 4.1.2.5.2. 2033 5.1.2.5 Next Update 2035 This field indicates the date by which the next CRL will be issued. 2036 The next CRL could be issued before the indicated date, but it will 2037 not be issued any later than the indicated date. CAs should issue 2038 CRLs with a nextUpdate time equal to or later than all previous CRLs. 2039 nextUpdate may be encoded as UTCTime or GeneralizedTime. 2041 This profile requires inclusion of nextUpdate in all CRLs issued by 2042 conforming CAs. Note that the ASN.1 syntax of TBSCertList describes 2043 this field as OPTIONAL, which is consistent with the ASN.1 structure 2044 defined in [X.509]. The behavior of clients processing CRLs which 2045 omit nextUpdate is not specified by this profile. 2047 CAs conforming to this profile that issue CRLs shall encode nextUp- 2048 date as UTCTime for dates through the year 2049. CAs conforming to 2049 this profile that issue CRLs shall encode nextUpdate as Generalized- 2050 Time for dates in the year 2050 or later. 2052 Where encoded as UTCTime, nextUpdate shall be specified and inter- 2053 preted as defined in section 4.1.2.5.1. Where encoded as General- 2054 izedTime, nextUpdate shall be specified and interpreted as defined in 2055 section 4.1.2.5.2. 2057 5.1.2.6 Revoked Certificates 2059 Revoked certificates are listed. The revoked certificates are named 2060 by their serial numbers. Certificates revoked by the CA are uniquely 2061 identified by the certificate serial number. The date on which the 2062 revocation occurred is specified. The time for revocationDate shall 2063 be expressed as described in section 5.1.2.4. Additional information 2064 may be supplied in CRL entry extensions; CRL entry extensions are 2065 discussed in section 5.3. 2067 5.1.2.7 Extensions 2069 This field may only appear if the version is 2 (see sec. 5.1.2.1). 2070 If present, this field is a SEQUENCE of one or more CRL extensions. 2071 CRL extensions are discussed in section 5.2. 2073 5.2 CRL Extensions 2075 The extensions defined by ANSI X9 and ISO/IEC/ITU for X.509 v2 CRLs 2076 [X.509] [X9.55] provide methods for associating additional attributes 2077 with CRLs. The X.509 v2 CRL format also allows communities to define 2078 private extensions to carry information unique to those communities. 2079 Each extension in a CRL may be designated as critical or non- 2080 critical. A CRL validation shall fail if it encounters a critical 2081 extension which it does not know how to process. However, an 2082 unrecognized non-critical extension may be ignored. The following 2083 subsections present those extensions used within Internet CRLs. Com- 2084 munities may elect to include extensions in CRLs which are not 2085 defined in this specification. However, caution should be exercised 2086 in adopting any critical extensions in CRLs which might be used in a 2087 general context. 2089 Conforming CAs that issue CRLs are required to include the authority 2090 key identifier (see sec. 5.2.1) and the CRL number (see sec. 5.2.3) 2091 extensions in all CRLs issued. 2093 5.2.1 Authority Key Identifier 2095 The authority key identifier extension provides a means of identify- 2096 ing the public key corresponding to the private key used to sign a 2097 CRL. The identification can be based on either the key identifier 2098 (the subject key identifier in the CRL signer's certificate) or on 2099 the issuer name and serial number. This extension is especially use- 2100 ful where an issuer has more than one signing key, either due to mul- 2101 tiple concurrent key pairs or due to changeover. 2103 Conforming CAs shall use the key identifier method, and shall include 2104 this extension in all CRLs issued. 2106 The syntax for this CRL extension is defined in section 4.2.1.1. 2108 5.2.2 Issuer Alternative Name 2110 The issuer alternative names extension allows additional identities 2111 to be associated with the issuer of the CRL. Defined options include 2112 an rfc822 name (electronic mail address), a DNS name, an IP address, 2113 and a URI. Multiple instances of a name and multiple name forms may 2114 be included. Whenever such identities are used, the issuer alterna- 2115 tive name extension shall be used. 2117 The issuerAltName extension should not be marked critical. 2119 The OID and syntax for this CRL extension are defined in section 2120 4.2.1.8. 2122 5.2.3 CRL Number 2124 The CRL number is a non-critical CRL extension which conveys a mono- 2125 tonically increasing sequence number for each CRL issued by a CA. 2126 This extension allows users to easily determine when a particular CRL 2127 supersedes another CRL. CAs conforming to this profile shall include 2128 this extension in all CRLs. 2130 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 2132 cRLNumber ::= INTEGER (0..MAX) 2134 5.2.4 Delta CRL Indicator 2136 The delta CRL indicator is a critical CRL extension that identifies a 2137 delta-CRL. The use of delta-CRLs can significantly improve process- 2138 ing time for applications which store revocation information in a 2139 format other than the CRL structure. This allows changes to be added 2140 to the local database while ignoring unchanged information that is 2141 already in the local database. 2143 When a delta-CRL is issued, the CAs shall also issue a complete CRL. 2145 The value of BaseCRLNumber identifies the CRL number of the base CRL 2146 that was used as the starting point in the generation of this delta- 2147 CRL. The delta-CRL contains the changes between the base CRL and the 2148 current CRL issued along with the delta-CRL. It is the decision of a 2149 CA as to whether to provide delta-CRLs. Again, a delta-CRL shall not 2150 be issued without a corresponding complete CRL. The value of 2151 CRLNumber for both the delta-CRL and the corresponding complete CRL 2152 shall be identical. 2154 A CRL user constructing a locally held CRL from delta-CRLs shall con- 2155 sider the constructed CRL incomplete and unusable if the CRLNumber of 2156 the received delta-CRL is more that one greater that the CRLnumber of 2157 the delta-CRL last processed. 2159 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 2161 deltaCRLIndicator ::= BaseCRLNumber 2163 BaseCRLNumber ::= CRLNumber 2165 5.2.5 Issuing Distribution Point 2167 The issuing distribution point is a critical CRL extension that iden- 2168 tifies the CRL distribution point for a particular CRL, and it indi- 2169 cates whether the CRL covers revocation for end entity certificates 2170 only, CA certificates only, or a limitied set of reason codes. 2171 Although the extension is critical, conforming implementations are 2172 not required to support this extension. 2174 The CRL is signed using the CA's private key. CRL Distribution 2175 Points do not have their own key pairs. If the CRL is stored in the 2176 X.500 Directory, it is stored in the Directory entry corresponding to 2177 the CRL distribution point, which may be different than the Directory 2178 entry of the CA. 2180 CAs may use CRL distribution points to partition the CRL on the basis 2181 of compromise and routine revocation. In this case, the revocations 2182 with reason code keyCompromise (1) shall appear in one distribution 2183 point, and the revocations with other reason codes shall appear in 2184 another distribution point. The reason codes associated with a dis- 2185 tribution point shall be specified in onlySomeReasons. If 2186 onlySomeReasons does not appear, the distribution point shall contain 2187 revocations for all reason codes. 2189 Where the issuingDistributionPoint extension contains a URL, the fol- 2190 lowing semantics shall be assumed: the object is a pointer to the 2191 most current CRL issued by this CA. The URI schemes ftp, http, 2192 mailto [RFC1738] and ldap [RFC1778] are defined for this purpose. 2193 The URI shall be an absolute, not relative, pathname and shall 2194 specify the host. 2196 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 2198 issuingDistributionPoint ::= SEQUENCE { 2199 distributionPoint [0] DistributionPointName OPTIONAL, 2200 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 2201 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 2202 onlySomeReasons [3] ReasonFlags OPTIONAL, 2203 indirectCRL [4] BOOLEAN DEFAULT FALSE } 2205 5.3 CRL Entry Extensions 2207 The CRL entry extensions already defined by ANSI X9 and ISO/IEC/ITU 2208 for X.509 v2 CRLs provide methods for associating additional attri- 2209 butes with CRL entries [X.509] [X9.55]. The X.509 v2 CRL format also 2210 allows communities to define private CRL entry extensions to carry 2211 information unique to those communities. Each extension in a CRL 2212 entry may be designated as critical or non-critical. A CRL valida- 2213 tion shall fail if it encounters a critical CRL entry extension which 2214 it does not know how to process. However, an unrecognized non- 2215 critical CRL entry extension may be ignored. The following subsec- 2216 tions present recommended extensions used within Internet CRL entries 2217 and standard locations for information. Communities may elect to use 2218 additional CRL entry extensions; however, caution should be exercised 2219 in adopting any critical extensions in CRL entries which might be 2220 used in a general context. 2222 All CRL entry extensions used in this specification are non-critical. 2223 Support for these extensions is optional for conforming CAs and 2224 applications. However, CAs that issue CRLs are strongly encouraged 2225 to include reason codes (see sec. 5.3.1) and invalidity dates (see 2226 sec. 5.3.3) whenever this information is available. 2228 5.3.1 Reason Code 2230 The reasonCode is a non-critical CRL entry extension that identifies 2231 the reason for the certificate revocation. CAs are strongly 2232 encouraged to include meaningful reason codes in CRL entries; how- 2233 ever, the reason code CRL entry extension should be absent instead of 2234 using the unspecified (0) reasonCode value. 2236 id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 } 2238 -- reasonCode ::= { CRLReason } 2240 CRLReason ::= ENUMERATED { 2241 unspecified (0), 2242 keyCompromise (1), 2243 cACompromise (2), 2244 affiliationChanged (3), 2245 superseded (4), 2246 cessationOfOperation (5), 2247 certificateHold (6), 2248 removeFromCRL (8) } 2250 5.3.2 Hold Instruction Code 2252 The hold instruction code is a non-critical CRL entry extension that 2253 provides a registered instruction identifier which indicates the 2254 action to be taken after encountering a certificate that has been 2255 placed on hold. 2257 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 2259 holdInstructionCode ::= OBJECT IDENTIFIER 2261 The following instruction codes have been defined. Conforming appli- 2262 cations that process this extension shall recognize the following 2263 instruction codes. 2265 holdInstruction OBJECT IDENTIFIER ::= 2266 { iso(1) member-body(2) us(840) x9-57(10040) 2 } 2268 id-holdinstruction-none OBJECT IDENTIFIER ::= {holdInstruction 1} 2269 id-holdinstruction-callissuer 2270 OBJECT IDENTIFIER ::= {holdInstruction 2} 2271 id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3} 2273 Conforming applications which encounter an id-holdinstruction- 2274 callissuer shall call the certificate issuer or reject the certifi- 2275 cate. Conforming applications which encounter an id- 2276 holdinstruction-reject shall reject the certificate. The hold 2277 instruction id-holdinstruction-none is semantically equivalent to the 2278 absence of a holdInstructionCode, and its use is strongly deprecated 2279 for the Internet PKI. 2281 5.3.3 Invalidity Date 2283 The invalidity date is a non-critical CRL entry extension that pro- 2284 vides the date on which it is known or suspected that the private key 2285 was compromised or that the certificate otherwise became invalid. 2286 This date may be earlier than the revocation date in the CRL entry, 2287 which is the date at which the CA processed the revocation. When a 2288 revocation is first posted by a CA in a CRL, the invalidity date may 2289 precede the date of issue of earlier CRLs, but the revocation date 2290 should not precede the date of issue of earlier CRLs. Whenever this 2291 information is available, CAs are strongly encouraged to share it 2292 with CRL users. 2294 The GeneralizedTime values included in this field shall be expressed 2295 in Greenwich Mean Time (Zulu), and shall be specified and interpreted 2296 as defined in section 4.1.2.5.2. 2298 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 2300 invalidityDate ::= GeneralizedTime 2302 5.3.4 Certificate Issuer 2304 This CRL entry extension identifies the certificate issuer associated 2305 with an entry in an indirect CRL, i.e. a CRL that has the indirectCRL 2306 indicator set in its issuing distribution point extension. If this 2307 extension is not present on the first entry in an indirect CRL, the 2308 certificate issuer defaults to the CRL issuer. On subsequent entries 2309 in an indirect CRL, if this extension is not present, the certificate 2310 issuer for the entry is the same as that for the preceding entry. 2311 This field is defined as follows: 2313 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } 2315 certificateIssuer ::= GeneralNames 2317 If used by conforming CAs that issue CRLs, this extension is always 2318 critical. If an implementation ignored this extension it could not 2319 correctly attribute CRL entries to certificates. This specification 2320 recommends that implementations recognize this extension. 2322 6 Certification Path Validation 2324 Certification path validation procedures for the Internet PKI are 2325 based on section 12.4.3 of [X.509]. Certification path processing 2326 verifies the binding between the subject distinguished name and/or 2327 subject alternative name and subject public key. The binding is lim- 2328 ited by constraints which are specified in the certificates which 2329 comprise the path. The basic constraints and policy constraints 2330 extensions allow the certification path processing logic to automate 2331 the decision making process. 2333 This section describes an algorithm for validating certification 2334 paths. Conforming implementations of this specification are not 2335 required to implement this algorithm, but shall be functionally 2336 equivalent to the external behavior resulting from this procedure. 2337 Any algorithm may be used by a particular implementation so long as 2338 it derives the correct result. 2340 In section 6.1, the text describes basic path validation. This text 2341 assumes that all valid paths begin with certificates issued by a sin- 2342 gle "most-trusted CA". The algorithm requires the public key of the 2343 CA, the CA's name, the validity period of the public key, and any 2344 constraints upon the set of paths which may be validated using this 2345 key. 2347 The "most-trusted CA" is a matter of policy: it could be a root CA in 2348 a hierarchical PKI; the CA that issued the verifier's own 2349 certificate(s); or any other CA in a network PKI. The path valida- 2350 tion procedure is the same regardless of the choice of "most-trusted 2351 CA." 2353 section 6.2 describes extensions to the basic path validation algo- 2354 rithm. Two specific cases are discussed: the case where paths may 2355 begin with one of several trusted CAs; and where compatibility with 2356 the PEM architecture is required. 2358 6.1 Basic Path Validation 2360 The text assumes that the trusted public key (and related informa- 2361 tion) is contained in a "self-signed" certificate. This simplifies 2362 the description of the path processing procedure. Note that the sig- 2363 nature on the self-signed certificate does not provide any security 2364 services. The trusted public key (and related information) may be 2365 obtained in other formats; the information is trusted because of 2366 other procedures used to obtain and protect it. 2368 The goal of path validation is to verify the binding between a sub- 2369 ject distinguished name or subject alternative name and subject pub- 2370 lic key, as represented in the "end entity" certificate, based on the 2371 public key of the "most-trusted CA". This requires obtaining a 2372 sequence of certificates that support that binding. The procedures 2373 performed to obtain this sequence is outside the scope of this sec- 2374 tion. 2376 The following text also assumes that certificates do not use subject 2377 or unique identifier fields or private critical extensions, as recom- 2378 mended within this profile. However, if these components appear in 2379 certificates, they shall be processed. Finally, policy qualifiers 2380 are also neglected for the sake of clarity. 2382 A certification path is a sequence of n certificates where: 2384 * for all x in {1,(n-1)}, the subject of certificate x is the 2385 issuer of certificate x+1. 2386 * certificate x=1 is the the self-signed certificate, and 2387 * certificate x=n is the end entity certificate. 2389 This section assumes the following inputs are provided to the path 2390 processing logic: 2392 (a) a certification path of length n; 2394 (b) a set of initial policy identifiers (each comprising a 2395 sequence of policy element identifiers), which identifies one or 2396 more certificate policies, any one of which would be acceptable 2397 for the purposes of certification path processing, or the special 2398 value "any-policy"; 2400 (c) the current date/time (if not available internally to the 2401 certification path processing module); and 2403 (d) the time, T, for which the validity of the path should be 2404 determined. (This may be the current date/time, or some point in 2405 the past.) 2407 From the inputs, the procedure intializes five state variables: 2409 (a) acceptable policy set: A set of certificate policy identif- 2410 iers comprising the policy or policies recognized by the public 2411 key user together with policies deemed equivalent through policy 2412 mapping. The initial value of the acceptable policy set is the 2413 special value "any-policy". 2415 (b) constrained subtrees: A set of root names defining a set of 2416 subtrees within which all subject names in subsequent certificates 2417 in the certification path shall fall. The initial value is 2418 "unbounded". 2420 (c) excluded subtrees: A set of root names defining a set of 2421 subtrees within which no subject name in subsequent certificates 2422 in the certification path may fall. The initial value is "empty". 2424 (d) explicit policy: an integer which indicates if an explicit 2425 policy identifier is required. The integer indicates the first 2426 certificate in the path where this requirement is imposed. Once 2427 set, this variable may be decreased, but may not be increased. 2428 (That is, if a certificate in the path requires explicit policy 2429 identifiers, a later certificate can not remove this requirement.) 2430 The initial value is n+1. 2432 (e) policy mapping: an integer which indicates if policy mapping 2433 is permitted. The integer indicates the last certificate on which 2434 policy mapping may be applied. Once set, this variable may be 2435 decreased, but may not be increased. (That is, if a certificate in 2436 the path specifies policy mapping is not permitted, it can not be 2437 overriden by a later certificate.) The initial value is n+1. 2439 The actions performed by the path processing software for each certi- 2440 ficate i=1 through n are described below. The self-signed certifi- 2441 cate is certificate i=1, the end entity certificate is i=n. The pro- 2442 cessing is performed sequentially, so that processing certificate i 2443 affects the state variables for processing certificate (i+1). Note 2444 that actions (h) through (m) are not applied to the end entity certi- 2445 ficate (certificate n). 2447 The path processing actions to be performed are: 2449 (a) Verify the basic certificate information, including: 2451 (1) the certificate was signed using the subject public key 2452 from certificate i-1 (in the special case i=1, this step may be 2453 omitted; if not, use the subject public key from the same cer- 2454 tificate), 2456 (2) the certificate validity period includes time T, 2458 (3) the certificate had not been revoked at time T and is not 2459 currently on hold status that commenced before time T, (this 2460 may be determined by obtaining the appropriate CRL or status 2461 information, or by out-of-band mechanisms), and 2463 (4) the subject and issuer names chain correctly (that is, the 2464 issuer of this certificate was the subject of the previous cer- 2465 tificate.) If the certificate has an empty sequence in the 2466 name field, name chaining will use the critical subjectAltNames 2467 and issuerAltNames fields. 2469 (b) Verify that the subject name and subjectAltName extension 2470 (critical or noncritical) is consistent with the constrained sub- 2471 trees state variables. 2473 (c) Verify that the subject name and subjectAltName extension 2474 (critical or noncritical) is consistent with the excluded subtrees 2475 state variables. 2477 (d) Verify that policy information is consistent with the initial 2478 policy set: 2480 (1) if the explicit policy state variable is less than or equal 2481 to i, a policy identifier in the certificate shall be in the 2482 initial policy set; and 2484 (2) if the policy mapping variable is less than or equal to i, 2485 the policy identifier may not be mapped. 2487 (e) Verify that policy information is consistent with the accept- 2488 able policy set: 2490 (1) if the certificate policies extension is marked critical, 2491 the intersection of the policies extension and the acceptable 2492 policy set shall be non-null; 2494 (2) the acceptable policy set is assigned the resulting inter- 2495 section as its new value. 2497 (g) Verify that the intersection of the acceptable policy set and 2498 the initial policy set is non-null. 2500 (h) Recognize and process any other critical extension present in 2501 the certificate. 2503 (i) Verify that the certificate is a CA certificate (as specified 2504 in a basicConstraints extension or as verified out-of-band). 2506 (j) If permittedSubtrees is present in the certificate, set the 2507 constrained subtrees state variable to the intersection of its 2508 previous value and the value indicated in the extension field. 2510 (k) If excludedSubtrees is present in the certificate, set the 2511 excluded subtrees state variable to the union of its previous 2512 value and the value indicated in the extension field. 2514 (l) If a policy constraints extension is included in the certifi- 2515 cate, modify the explicit policy and policy mapping state vari- 2516 ables as follows: 2518 (1) If requireExplicitPolicy is present and has value r, the 2519 explicit policy state variable is set to the minimum of its 2520 current value and the sum of r and i (the current certificate 2521 in the sequence). 2523 (2) If inhibitPolicyMapping is present and has value q, the 2524 policy mapping state variable is set to the minimum of its 2525 current value and the sum of q and i (the current certificate 2526 in the sequence). 2528 (m) If a key usage extension is marked critical, ensure the key- 2529 CertSign bit is set. 2531 If any one of the above checks fail, the procedure terminates, 2532 returning a failure indication and an appropriate reason. If none of 2533 the above checks fail on the end-entity certificate, the procedure 2534 terminates, returning a success indication together with the set of 2535 all policy qualifier values encountered in the set of certificates. 2537 6.2 Extending Path Validation 2539 The path validation algorithm presented in 6.1 is based on several 2540 simplifying assumptions (e.g., a single trusted CA that starts all 2541 valid paths). This algorithm may be extended for cases where the 2542 assumptions do not hold. 2544 This procedure may be extended for multiple trusted CAs by providing 2545 a set of self-signed certificates to the validation module. In this 2546 case, a valid path could begin with any one of the self-signed certi- 2547 ficates. Limitations in the trust paths for any particular key may 2548 be incorporated into the self-signed certificate's extensions. In 2549 this way, the self-signed certificates permit the path validation 2550 module to automatically incorporate local security policy and 2551 requirements. 2553 It is also possible to specify an extended version of the above cer- 2554 tification path processing procedure which results in default 2555 behavior identical to the rules of PEM [RFC 1422]. In this extended 2556 version, additional inputs to the procedure are a list of one or more 2557 Policy Certification Authorities (PCAs) names and an indicator of the 2558 position in the certification path where the PCA is expected. At the 2559 nominated PCA position, the CA name is compared against this list. 2560 If a recognized PCA name is found, then a constraint of Subordina- 2561 teToCA is implicitly assumed for the remainder of the certification 2562 path and processing continues. If no valid PCA name is found, and if 2563 the certification path cannot be validated on the basis of identified 2564 policies, then the certification path is considered invalid. 2566 7 Algorithm Support 2568 This section describes cryptographic algorithms which may be used 2569 with this profile. The section describes one-way hash functions and 2570 digital signature algorithms which may be used to sign certificates 2571 and CRLs, and identifies OIDs for public keys contained in a certifi- 2572 cate. 2574 Conforming CAs and applications are not required to support the algo- 2575 rithms or algorithm identifiers described in this section. However, 2576 conforming CAs and applications that use the algorithms identified 2577 here shall support them as specified. 2579 7.1 One-way Hash Functions 2581 This section identifies one-way hash functions for use in the Inter- 2582 net PKI. One-way hash functions are also called message digest algo- 2583 rithms. SHA-1 is the preferred one-way hash function for the Internet 2584 PKI. However, PEM uses MD2 for certificates [RFC 1422] [RFC 1423] 2585 and MD5 is used in other legacy applications. For this reason, MD2 2586 and MD5 are included in this profile. 2588 7.1.1 MD2 One-way Hash Function 2590 MD2 was developed by Ron Rivest for RSA Data Security. RSA Data Secu- 2591 rity has not placed the MD2 algorithm in the public domain. Rather, 2592 RSA Data Security has granted license to use MD2 for non-commercial 2593 Internet Privacy-Enhanced Mail. For this reason, MD2 may continue to 2594 be used with PEM certificates, but SHA-1 is preferred. MD2 produces 2595 a 128-bit "hash" of the input. MD2 is fully described in RFC 1319 2596 [RFC 1319]. 2598 At the Selected Areas in Cryptography '95 conference in May 1995, 2599 Rogier and Chauvaud presented an attack on MD2 that can nearly find 2600 collisions [RC95]. Collisions occur when one can find two different 2601 messages that generate the same message digest. A checksum operation 2602 in MD2 is the only remaining obstacle to the success of the attack. 2603 For this reason, the use of MD2 for new applications is discouraged. 2604 It is still reasonable to use MD2 to verify existing signatures, as 2605 the ability to find collisions in MD2 does not enable an attacker to 2606 find new messages having a previously computed hash value. 2608 7.1.2 MD5 One-way Hash Function 2610 MD5 was developed by Ron Rivest for RSA Data Security. RSA Data Secu- 2611 rity has placed the MD5 algorithm in the public domain. MD5 produces 2612 a 128-bit "hash" of the input. MD5 is fully described in RFC 1321 2613 [RFC 1321]. 2615 Den Boer and Bosselaers [DB94] have found pseudo-collisions for MD5, 2616 but there are no other known cryptanalytic results. The use of MD5 2617 for new applications is discouraged. It is still reasonable to use 2618 MD5 to verify existing signatures. 2620 7.1.3 SHA-1 One-way Hash Function 2622 SHA-1 was developed by the U.S. Government. SHA-1 produces a 160-bit 2623 "hash" of the input. SHA-1 is fully described in FIPS 180-1 [FIPS 2624 180-1]. 2626 SHA-1 is the one-way hash function of choice for use with both the 2627 RSA and DSA signature algorithms (see sec. 7.2). 2629 7.2 Signature Algorithms 2631 Certificates and CRLs described by this standard may be signed with 2632 any public key signature algorithm. The certificate or CRL indicates 2633 the algorithm through an algorithm identifier which appears in the 2634 signatureAlgorithm field in a Certificate or CertificateList. This 2635 algorithm identifier is an OID and has optionally associated parame- 2636 ters. This section identifies algorithm identifiers and parameters 2637 that shall be used in the signatureAlgorithm field in a Certificate 2638 or CertificateList. 2640 RSA and DSA are the most popular signature algorithms used in the 2641 Internet. Signature algorithms are always used in conjunction with a 2642 one-way hash function identified in section 7.1. 2644 The signature algorithm and one-way hash function used to sign a cer- 2645 tificate or CRL is indicated by use of an algorithm identifier. An 2646 algorithm identifier is an OID, and may include associated parame- 2647 ters. This section identifies OIDS for RSA and DSA. The contents of 2648 the parameters component for each algorithm vary; details are pro- 2649 vided for each algorithm. 2651 The data to be signed (e.g., the one-way hash function output value) 2652 is formatted for the signature algorithm to be used. Then, a private 2653 key operation (e.g., RSA encryption) is performed to generate the 2654 signature value. This signature value is then ASN.1 encoded as a BIT 2655 STRING and included in the Certificate or CertificateList in the sig- 2656 nature field. 2658 7.2.1 RSA Signature Algorithm 2660 A patent statement regarding the RSA algorithm can be found at the 2661 end of this profile. 2663 The RSA algorithm is named for its inventors: Rivest, Shamir, and 2664 Adleman. This profile includes three signature algorithms based on 2665 the RSA asymmetric encryption algorithm. The signature algorithms 2666 combine RSA with either the MD2, MD5, or the SHA-1 one-way hash func- 2667 tions. 2669 The signature algorithm with MD2 and the RSA encryption algorithm is 2670 defined in PKCS #1 [RFC 2313]. As defined in RFC 2313, the ASN.1 OID 2671 used to identify this signature algorithm is: 2673 md2WithRSAEncryption OBJECT IDENTIFIER ::= { 2674 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 2675 pkcs-1(1) 2 } 2677 The signature algorithm with MD5 and the RSA encryption algorithm is 2678 defined in PKCS #1 [RFC 2313]. As defined in RFC 2313, the ASN.1 OID 2679 used to identify this signature algorithm is: 2681 md5WithRSAEncryption OBJECT IDENTIFIER ::= { 2682 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 2683 pkcs-1(1) 4 } 2685 The signature algorithm with SHA-1 and the RSA encryption algorithm 2686 is implemented using the padding and encoding conventions described 2687 in PKCS #1 [RFC 2313]. The message digest is computed using the SHA-1 2688 hash algorithm. The ASN.1 object identifier used to identify this 2689 signature algorithm is: 2691 sha-1WithRSAEncryption OBJECT IDENTIFIER ::= { 2692 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 2693 pkcs-1(1) 5 } 2695 When any of these three OIDs appears within the ASN.1 type Algorith- 2696 mIdentifier, the parameters component of that type shall be the ASN.1 2697 type NULL. 2699 The RSA signature generation process and the encoding of the result 2700 is described in detail in RFC 2313. 2702 7.2.2 DSA Signature Algorithm 2704 A patent statement regarding the DSA can be found at the end of this 2705 profile. 2707 The Digital Signature Algorithm (DSA) is also called the Digital Sig- 2708 nature Standard (DSS). DSA was developed by the U.S. Government, and 2709 DSA is used in conjunction with the the SHA-1 one-way hash function. 2710 DSA is fully described in FIPS 186 [FIPS 186]. The ASN.1 OIDs used 2711 to identify this signature algorithm are: 2713 id-dsa-with-sha1 ID ::= { 2714 iso(1) member-body(2) us(840) x9-57 (10040) 2715 x9cm(4) 3 } 2717 Where the id-dsa-with-sha1 algorithm identifier appears as the algo- 2718 rithm field in an AlgorithmIdentifier, the encoding shall omit the 2719 parameters field. That is, the AlgorithmIdentifier shall be a 2720 SEQUENCE of one component - the OBJECT IDENTIFIER id-dsa-with-sha1. 2722 The DSA parameters in the subjectPublicKeyInfo field of the certifi- 2723 cate of the issuer shall apply to the verification of the signature. 2725 When signing, the DSA algorithm generates two values. These values 2726 are commonly referred to as r and s. To easily transfer these two 2727 values as one signature, they shall be ASN.1 encoded using the fol- 2728 lowing ASN.1 structure: 2730 Dss-Sig-Value ::= SEQUENCE { 2731 r INTEGER, 2732 s INTEGER } 2734 7.3 Subject Public Key Algorithms 2736 Certificates described by this profile may convey a public key for 2737 any public key algorithm. The certificate indicates the algorithm 2738 through an algorithm identifier. This algorithm identifier is an OID 2739 and optionally associated parameters. 2741 This section identifies preferred OIDs and parameters for the RSA, 2742 DSA, and Diffie-Hellman algorithms. Conforming CAs shall use the 2743 identified OIDs when issuing certificates containing public keys for 2744 these algorithms. Conforming applications supporting any of these 2745 algorithms shall, at a minimum, recognize the OID identified in this 2746 section. 2748 7.3.1 RSA Keys 2750 The OID rsaEncryption identifies RSA public keys. 2752 pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 2753 rsadsi(113549) pkcs(1) 1 } 2755 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1} 2757 The rsaEncryption OID is intended to be used in the algorithm field 2758 of a value of type AlgorithmIdentifier. The parameters field shall 2759 have ASN.1 type NULL for this algorithm identifier. 2761 The RSA public key shall be encoded using the ASN.1 type RSAPub- 2762 licKey: 2764 RSAPublicKey ::= SEQUENCE { 2765 modulus INTEGER, -- n 2766 publicExponent INTEGER -- e -- } 2768 where modulus is the modulus n, and publicExponent is the public 2769 exponent e. The DER encoded RSAPublicKey is the value of the BIT 2770 STRING subjectPublicKey. 2772 This OID is used in public key certificates for both RSA signature 2773 keys and RSA encryption keys. The intended application for the key 2774 may be indicated in the key usage field (see sec. 4.2.1.3). The use 2775 of a single key for both signature and encryption purposes is not 2776 recommended, but is not forbidden. 2778 If the keyUsage extension is present in an end entity certificate 2779 which conveys an RSA public key, any combination of the following 2780 values may be present: digitalSignature; nonRepudiation; keyEnci- 2781 pherment; and dataEncipherment. If the keyUsage extension is present 2782 in a CA certificate which conveys an RSA public key, any combination 2783 of the following values may be present: digitalSignature; nonRepudi- 2784 ation; keyEncipherment; dataEncipherment; keyCertSign; and cRLSign. 2785 However, this specification recommends that if keyCertSign or cRLSign 2786 is present, both keyEncipherment and dataEncipherment should not be 2787 present. 2789 7.3.2 Diffie-Hellman Key Exchange Key 2791 The Diffie-Hellman OID supported by this profile is defined by ANSI 2792 X9.42 [X9.42]. 2794 dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2795 us(840) ansi-x942(10046) number-type(2) 1 } 2797 The dhpublicnumber OID is intended to be used in the algorithm field 2798 of a value of type AlgorithmIdentifier. The parameters field of that 2799 type, which has the algorithm-specific syntax ANY DEFINED BY algo- 2800 rithm, have the ASN.1 type GroupParameters for this algorithm. 2802 DomainParameters ::= SEQUENCE { 2803 p INTEGER, -- odd prime, p=jq +1 2804 g INTEGER, -- generator, g 2805 q INTEGER, -- factor of p-1 2806 j INTEGER OPTIONAL, -- subgroup factor 2807 validationParms ValidationParms OPTIONAL } 2809 ValidationParms ::= SEQUENCE { 2810 seed BIT STRING, 2811 pgenCounter INTEGER } 2813 The fields of type DomainParameters have the following meanings: 2815 p identifies the prime p defining the Galois field; 2817 g specifies the generator of the multiplicative subgroup of order 2818 g; 2820 q specifies the prime factor of p-1; 2822 j optionally specifies the value that satisfies the equation 2823 p=jq+1 to support the optional verification of group parameters; 2825 seed optionally specifies the bit string parameter used as the 2826 seed for the system parameter generation process; and 2828 pgenCounter optionally specifies the integer value output as part 2829 of the of the system parameter prime generation process. 2831 If either of the parameter generation components (pgencounter or 2832 seed) is provided, the other shall be present as well. 2834 The Diffie-Hellman public key shall be ASN.1 encoded as an INTEGER; 2835 this encoding shall be used as the contents (i.e., the value) of the 2836 subjectPublicKey component (a BIT STRING) of the subjectPublicKeyInfo 2837 data element. 2839 DHPublicKey ::= INTEGER -- public key, y = g^x mod p 2841 If the keyUsage extension is present in a certificate which conveys a 2842 DH public key, the following values may be present: keyAgreement; 2843 encipherOnly; and decipherOnly. At most one of encipherOnly and 2844 decipherOnly shall be asserted in keyUsage extension. 2846 7.3.3 DSA Signature Keys 2848 The Digital Signature Algorithm (DSA) is also known as the Digital 2849 Signature Standard (DSS). The DSA OID supported by this profile is 2851 id-dsa ID ::= { iso(1) member-body(2) us(840) x9-57(10040) 2852 x9cm(4) 1 } 2854 The id-dsa algorithm syntax includes optional parameters. These 2855 parameters are commonly referred to as p, q, and g. When omitted, 2856 the parameters component shall be omitted entirely. That is, the 2857 AlgorithmIdentifier shall be a SEQUENCE of one component - the OBJECT 2858 IDENTIFIER id-dsa. 2860 If the DSA algorithm parameters are present in the subjectPublicKey- 2861 Info AlgorithmIdentifier, the parameters are included using the fol- 2862 lowing ASN.1 structure: 2864 Dss-Parms ::= SEQUENCE { 2865 p INTEGER, 2866 q INTEGER, 2867 g INTEGER } 2869 If the DSA algorithm parameters are absent from the subjectPublicKey- 2870 Info AlgorithmIdentifier and the CA signed the subject certificate 2871 using DSA, then the certificate issuer's DSA parameters apply to the 2872 subject's DSA key. If the DSA algorithm parameters are absent from 2873 the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the 2874 subject certificate using a signature algorithm other than DSA, then 2875 the subject's DSA parameters are distributed by other means. If the 2876 subjectPublicKeyInfo AlgorithmIdentifier field omits the parameters 2877 component and the CA signed the subject with a signature algorithm 2878 other than DSA, then clients shall reject the certificate. 2880 When signing, DSA algorithm generates two values. These values are 2881 commonly referred to as r and s. To easily transfer these two values 2882 as one signature, they are ASN.1 encoded using the following ASN.1 2883 structure: 2885 Dss-Sig-Value ::= SEQUENCE { 2886 r INTEGER, 2887 s INTEGER } 2889 The encoded signature is conveyed as the value of the BIT STRING sig- 2890 nature in a Certificate or CertificateList. 2892 The DSA public key shall be ASN.1 DER encoded as an INTEGER; this 2893 encoding shall be used as the contents (i.e., the value) of the sub- 2894 jectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo 2895 data element. 2897 DSAPublicKey ::= INTEGER -- public key, Y 2899 If the keyUsage extension is present in an end entity certificate 2900 which conveys a DSA public key, any combination of the following 2901 values may be present: digitalSignature; and nonRepudiation. 2903 If the keyUsage extension is present in an CA certificate which con- 2904 veys a DSA public key, any combination of the following values may be 2905 present: digitalSignature; nonRepudiation; keyCertSign; and cRLSign. 2907 8 References 2909 [FIPS 180-1] Federal Information Processing Standards Publication 2910 (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995. 2911 [Supersedes FIPS PUB 180 dated 11 May 1993.] 2913 [FIPS 186] Federal Information Processing Standards Publication 2914 (FIPS PUB) 186, Digital Signature Standard, 18 May 1994. 2916 [RC95] Rogier, N. and Chauvaud, P., "The compression function of 2917 MD2 is not collision free," Presented at Selected Areas in 2918 Cryptography '95, May 1995. 2920 [RFC 791] J. Postel, "Internet Protocol", September 1981. 2922 [RFC 822] D. Crocker, "Standard for the format of ARPA Internet text 2923 messages", August 1982. 2925 [RFC 1034] P.V. Mockapetris, "Domain names - concepts and 2926 facilities", November 1987. 2928 [RFC 1319] Kaliski, B., "The MD2 Message-Digest Algorithm," RFC 1319, 2929 RSA Laboratories, April 1992. 2931 [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321, 2932 MIT and RSA Data Security, April 1992. 2934 [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic 2935 Mail: Part II: Certificate-Based Key Management," RFC 2936 1422, BBN Communications, February 1993. 2938 [RFC 1423] Balenson, D., "Privacy Enhancement for Internet Electronic 2939 Mail: Part III: Algorithms, Modes, and Identifiers," 2940 RFC 1423, Trusted Information Systems, February 1993. 2942 [RFC 1519] V. Fuller, T. Li, J. Yu, and K. Varadhan. "Classless 2943 Inter-Domain Routing (CIDR): an Address Assignment and 2944 Aggregation Strategy", September 1993. 2946 [RFC 1738] Berners-Lee, T., Masinter L., and M. McCahill. 2947 "Uniform Resource Locators (URL)", RFC 1738, December 1994. 2949 [RFC 1778] Howes, T., Kille S., Yeong, W. and C. Robbins. "The 2950 String Representation of Standard Attribute Syntaxes," 2951 RFC 1778, March 1995. 2953 [RFC 1883] S. Deering and R. Hinden. "Internet Protocol, Version 6 2954 (IPv6) Specification", December 1995. 2956 [RFC 2044] F. Yergeau, "UTF-8, a transformation format of Unicode 2957 and ISO 10646", October 1996. 2959 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 2960 Requirement Levels", March 1997. 2962 [RFC 2247] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. 2963 Sataluri. "Using Domains in LDAP/X.500 Distinguished Names", 2964 RFC 2247, January 1998. 2966 [RFC 2277] H. Alvestrand, "IETF Policy on Character Sets and 2967 Languages", January 1998. 2969 [RFC 2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646", 2970 January 1998. 2972 [RFC 2313] B. Kaliski, "PKCS #1: RSA Encryption Version 1.5", 2973 March 1998. 2975 [SDN.701] SDN.701, "Message Security Protocol 4.0", Revision A 2976 1997-02-06. 2978 [X.208] CCITT Recommendation X.208: Specification of Abstract 2979 Syntax Notation One (ASN.1), 1988. 2981 [X.501] ITU-T Recommendation X.501: Information 2982 Technology - Open Systems Interconnection - The 2983 Directory: Models, 1993. 2985 [X.509] ITU-T Recommendation X.509 (1997 E): Information 2986 Technology - Open Systems Interconnection - The 2987 Directory: Authentication Framework, June 1997. 2989 [X.520] ITU-T Recommendation X.520: Information 2990 Technology - Open Systems Interconnection - The 2991 Directory: Selected Attribute Types, 1993. 2993 [X9.42] ANSI X9.42-199x, Public Key Cryptography for The Financial 2994 Services Industry: Agreement of Symmetric Algorithm Keys 2995 Using Diffie-Hellman (Working Draft), December 1997. 2997 [X9.55] ANSI X9.55-1995, Public Key Cryptography For The Financial 2998 Services Industry: Extensions To Public Key Certificates 2999 And Certificate Revocation Lists, 8 December, 1995. 3001 [X9.57] ANSI X9.57-199x, Public Key Cryptography For The Financial 3002 Services Industry: Certificate Management (Working Draft), 3003 21 June, 1996. 3005 9 Patent Statements 3007 The Internet PKI relies on the use of patented public key technology 3008 and secure hash technology for digital signature services. This 3009 specification references public key encryption technology for provi- 3010 sioning key exchange services. 3012 The Internet Standards Process as defined in RFC 1310 requires a 3013 written statement from the Patent holder that a license will be made 3014 available to applicants under reasonable terms and conditions prior 3015 to approving a specification as a Proposed, Draft or Internet Stan- 3016 dard. 3018 Patent statements for DSA, RSA, Diffie-Hellman, and Hellman-Merkle 3019 follow. These statements have been supplied by the patent holders, 3020 not the authors of this profile. 3022 The Internet Society, Internet Architecture Board, Internet Engineer- 3023 ing Steering Group and the Corporation for National Research Initia- 3024 tives take no position on the validity or scope of the following 3025 patents and patent applications, nor on the appropriateness of the 3026 terms of the assurance. The Internet Society and other groups men- 3027 tioned above have not made any determination as to any other intel- 3028 lectual property rights which may apply to the practice of this stan- 3029 dard. Any further consideration of these matters is the user's 3030 responsibility. 3032 9.1 Digital Signature Algorithm (DSA) 3034 The U.S. Government holds patent 5,231,668 on the Digital Signature 3035 Algorithm (DSA), which has been incorporated into Federal Information 3036 Processing Standard (FIPS) 186. The patent was issued on July 27, 3037 1993. 3039 The National Institute of Standards and Technology (NIST) has a long 3040 tradition of supplying U.S. Government-developed techniques to com- 3041 mittees and working groups for inclusion into standards on a 3042 royalty-free basis. NIST has made the DSA patent available royalty- 3043 free to users worldwide. 3045 NIST has provided the following statement with regard to this patent: 3047 Regarding patent infringement, FIPS 186 summarizes our position; 3048 the Department of Commerce is not aware of any patents that would 3049 be infringed by the DSA. Questions regarding this matter may be 3050 directed to the Deputy Chief Counsel for NIST. 3052 9.2 RSA Signature and Encryption 3054 The Massachusetts Institute of Technology has granted RSA Data Secu- 3055 rity, Inc., exclusive sub-licensing rights to the following patent 3056 issued in the United States: 3058 Cryptographic Communications System and Method ("RSA"), No. 4,405,829 3060 RSA Data Security, Inc. has provided the following statement with 3061 regard to this patent: 3063 It is our understanding that the proposed PKIX Certificate Profile 3064 (PKIX-1) standard currently under review contemplates the use of 3065 U.S Patent 4,405,829 entitled "Cryptographic Communication System 3066 and Method" (the "RSA patent") which patent is controlled by RSA. 3068 It is RSA's business practice to make licenses to its patents 3069 available on reasonable and nondiscriminatory terms. Accordingly, 3070 if the foregoing identified IETF standard is adopted, RSA is wil- 3071 ling, upon request, to grant non-exclusive licenses to such patent 3072 on reasonable and non-discriminatory terms and conditions to those 3073 who respect RSA's intellectual property rights and subject to 3074 RSA's then current royalty rate for the patent licensed. The roy- 3075 alty rate for the RSA patent is presently set at 2% of the 3076 licensee's selling price for each product covered by the patent. 3077 Any requests for license information may be directed to: 3079 Director of Licensing 3080 RSA Data Security, Inc. 3081 100 Marine Parkway, Suite 500 3082 Redwood City, CA 94065 3084 A license under RSA's patent(s) does not include any rights to 3085 know-how or other technical information or license under other 3086 intellectual property rights. Such license does not extend to any 3087 activities which constitute infringement or inducement thereto. A 3088 licensee shall make his own determination as to whether a license 3089 is necessary under patents of others. 3091 9.3 Diffie-Hellman Key Agreement 3093 Patent No. 4,200,770: Cryptographic Apparatus and Method ("Diffie- 3094 Hellman") expired on August 19, 1997. 3096 9.4 Hellman-Merkle Public Key Cryptography 3098 Patent No. 4,218,582: Public Key Cryptographic Apparatus and Method 3099 ("Hellman-Merkle") expired on April 29, 1997. 3101 9.5 CRL Distribution Points and Related Mechanisms 3103 Entrust Technologies Incorporated has provided the following state- 3104 ment with regard to this patent: 3106 Entrust Technologies Incorporated advises the IETF that it holds 3107 the Patent (as defined herein) which may relate to the IETF. In 3108 accordance with the Intellectual Property rights procedures of the 3109 IETF standards process, Entrust Technologies Incorporated, for 3110 itself and its subsidiaries (hereinafter called "Entrust") will 3111 offer licenses under its Patent on a perpetual, royalty-free, 3112 non-exclusive basis and on non-discriminatory, fair and equitable 3113 terms to all parties solely for their use in complying with the 3114 Standard, but on condition that any such party offers to Entrust 3115 and its corporate affiliates similar licenses under such party's 3116 patents, if any, for use in complying with the Standard. 3118 Any application for a license under Entrust's Patent pursuant to 3119 this Patent Disclosure Statement should be made to: 3121 Stephen Samson 3122 Entrust Technologies Limited 3123 750 Heron Road, Ottawa, Ontario, Canada, K1V 1A7 3124 voice: (613) 247 3725 3126 As used herein: 3128 "Patent" means US Patent 5,699,431 issued on 16 December, 1997 for 3129 an invention known as a "Method for Efficient Management of Certi- 3130 ficate Revocation Lists and Update Information", which invention 3131 is owned or controlled by Entrust and the use of which may be 3132 required in conjunction with the Standard. 3134 "Standard" means a specification progressing through the Standard 3135 Track of the IETF and relating to the Public Key Infrastructure 3136 (X.509) specification for certificate update and revocation. 3138 10 Security Considerations 3140 The majority of this specification is devoted to the format and con- 3141 tent of certificates and CRLs. Since certificates and CRLs are digi- 3142 tally signed, no additional integrity service is necessary. Neither 3143 certificates nor CRLs need be kept secret, and unrestricted and 3144 anonymous access to certificates and CRLs has no security implica- 3145 tions. 3147 However, security factors outside the scope of this specification 3148 will affect the assurance provided to certificate users. This sec- 3149 tion highlights critical issues that should be considered by imple- 3150 mentors, administrators, and users. 3152 The procedures performed by CAs and RAs to validate the binding of 3153 the subject's identity of their public key greatly affect the 3154 assurance that should be placed in the certificate. Relying parties 3155 may wish to review the CA's certificate practice statement. This may 3156 be particularly important when issuing certificates to other CAs. 3158 The use of a single key pair for both signature and other purposes is 3159 strongly discouraged. Use of separate key pairs for signature and key 3160 management provides several benefits to the users. The ramifications 3161 associated with loss or disclosure of a signature key are different 3162 from loss or disclosure of a key management key. Using separate key 3163 pairs permits a balanced and flexible response. Similarly, different 3164 validity periods or key lengths for each key pair may be appropriate 3165 in some application environments. Unfortunately, some legacy applica- 3166 tions (e.g., SSL) use a single key pair for signature and key manage- 3167 ment. 3169 The protection afforded private keys is a critical factor in main- 3170 taining security. On a small scale, failure of users to protect 3171 their private keys will permit an attacker to masquerade as them, or 3172 decrypt their personal information. On a larger scale, compromise of 3173 a CA's private signing key may have a catastrophic effect. If an 3174 attacker obtains the private key unnoticed, the attacker may issue 3175 bogus certificates and CRLs. Existence of bogus certificates and 3176 CRLs will undermine confidence in the system. If the compromise is 3177 detected, all certificates issued to the CA shall be revoked, 3178 preventing services between its users and users of other CAs. 3179 Rebuilding after such a compromise will be problematic, so CAs are 3180 advised to implement a combination of strong technical measures 3181 (e.g., tamper-resistant cryptographic modules) and appropriate 3182 management procedures (e.g., separation of duties) to avoid such an 3183 incident. 3185 Loss of a CA's private signing key may also be problematic. The CA 3186 would not be able to produce CRLs or perform normal key rollover. 3187 CAs are advised to maintain secure backup for signing keys. The 3188 security of the key backup procedures is a critical factor in avoid- 3189 ing key compromise. 3191 The availability and freshness of revocation information will affect 3192 the degree of assurance that should be placed in a certificate. 3193 While certificates expire naturally, events may occur during its 3194 natural lifetime which negate the binding between the subject and 3195 public key. If revocation information is untimely or unavailable, 3196 the assurance associated with the binding is clearly reduced. Simi- 3197 larly, implementations of the Path Validation mechanism described in 3198 section 6 that omit revocation checking provide less assurance than 3199 those that support it. 3201 The path validation algorithm depends on the certain knowledge of the 3202 public keys (and other information) about one or more trusted CAs. 3203 The decision to trust a CA is an important decision as it ultimately 3204 determines the trust afforded a certificate. The authenticated dis- 3205 tribution of trusted CA public keys (usually in the form of a "self- 3206 signed" certificate) is a security critical out of band process that 3207 is beyond the scope of this specification. 3209 In addition, where a key compromise or CA failure occurs for a 3210 trusted CA, the user will need to modify the information provided to 3211 the path validation routine. Selection of too many trusted CAs will 3212 make the trusted CA information difficult to maintain. On the other 3213 hand, selection of only one trusted CA may limit users to a closed 3214 community of users until a global PKI emerges. 3216 The quality of implementations that process certificates may also 3217 affect the degree of assurance provided. The path validation algo- 3218 rithm described in section 6 relies upon the integrity of the trusted 3219 CA information, and especially the integrity of the public keys asso- 3220 ciated with the trusted CAs. By substituting public keys for which 3221 an attacker has the private key, an attacker could trick the user 3222 into accepting false certificates. 3224 The binding between a key and certificate subject cannot be stronger 3225 than the cryptographic module implementation and algorithms used to 3226 generate the signature. Short key lengths or weak hash algorithms 3227 will limit the utility of a certificate. CAs are encouraged to note 3228 advances in cryptology so they can employ strong cryptographic tech- 3229 niques. In addition, CAs should decline to issue certificates to CAs 3230 or end entities that generate weak signatures. 3232 Inconsistent application of name comparison rules may result in 3233 acceptance of invalid X.509 certification paths, or rejection of 3234 valid ones. The X.500 series of specifications defines rules for 3235 comparing distinguished names require comparison of strings without 3236 regard to case, character set, multi-character white space substring, 3237 or leading and trailing white space. This specification relaxes 3238 these requirements, requiring support for binary comparison at a 3239 minimum. 3241 CAs shall encode the distinguished name in the subject field of a CA 3242 certificate identically to the distinguished name in the issuer field 3243 in certificates issued by the latter CA. If CAs use different encod- 3244 ings, implementations of this specification may fail to recognize 3245 name chains for paths that include this certificate. As a conse- 3246 quence, valid paths could be rejected. 3248 In addition, name constraints for distinguished names shall be stated 3249 identically to the encoding used in the subject field or subjectAlt- 3250 Name extension. If not, (1) name constraints stated as excludedSub- 3251 Trees will not match and invalid paths will be accepted and (2) name 3252 constraints expressed as permittedSubtrees will not match and valid 3253 paths will be rejected. To avoid acceptance of invalid paths, CAs 3254 should state name constraints for distinguished names as permit- 3255 tedSubtrees where ever possible. 3257 Appendix A. Psuedo-ASN.1 Structures and OIDs 3259 This section describes data objects used by conforming PKI components 3260 in an "ASN.1-like" syntax. This syntax is a hybrid of the 1988 and 3261 1993 ASN.1 syntaxes. The 1988 ASN.1 syntax is augmented with 1993 3262 UNIVERSAL Types UniversalString, BMPString and UTF8String. 3264 The ASN.1 syntax does not permit the inclusion of type statements in 3265 the ASN.1 module, and the 1993 ASN.1 standard does not permit use of 3266 the new UNIVERSAL types in modules using the 1988 syntax. As a 3267 result, this module does not conform to either version of the ASN.1 3268 standard. 3270 This appendix may be converted into 1988 ASN.1 by replacing the 3271 defintions for the UNIVERSAL Types with the 1988 catch-all "ANY". 3273 A.1 Explicitly Tagged Module, 1988 Syntax 3275 PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) 3276 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)} 3278 DEFINITIONS EXPLICIT TAGS ::= 3280 BEGIN 3282 -- EXPORTS ALL -- 3284 -- IMPORTS NONE -- 3286 -- UNIVERSAL Types defined in '93 and '98 ASN.1 3287 -- but required by this specification 3289 UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING 3290 -- UniversalString is defined in ASN.1:1993 3292 BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING 3293 -- BMPString is the subtype of UniversalString and models 3294 -- the Basic Multilingual Plane of ISO/IEC/ITU 10646-1 3296 UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 3297 -- The content of this type conforms to RFC 2044. 3299 -- 3300 -- PKIX specific OIDs 3302 id-pkix OBJECT IDENTIFIER ::= 3303 { iso(1) identified-organization(3) dod(6) internet(1) 3304 security(5) mechanisms(5) pkix(7) } 3305 -- PKIX arcs 3307 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 3308 -- arc for private certificate extensions 3309 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 3310 -- arc for policy qualifier types 3311 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 3312 -- arc for extended key purpose OIDS 3313 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 3314 -- arc for access descriptors 3316 -- policyQualifierIds for Internet policy qualifiers 3318 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 3319 -- OID for CPS qualifier 3320 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 3321 -- OID for user notice qualifier 3323 -- access descriptor definitions 3325 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 3326 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 3328 -- attribute data types -- 3330 Attribute ::= SEQUENCE { 3331 type AttributeType, 3332 values SET OF AttributeValue 3333 -- at least one value is required -- } 3335 AttributeType ::= OBJECT IDENTIFIER 3337 AttributeValue ::= ANY 3339 AttributeTypeAndValue ::= SEQUENCE { 3340 type AttributeType, 3341 value AttributeValue } 3343 -- suggested naming attributes: Definition of the following 3344 -- information object set may be augmented to meet local 3345 -- requirements. Note that deleting members of the set may 3346 -- prevent interoperability with conforming implementations. 3347 -- presented in pairs: the AttributeType followed by the 3348 -- type definition for the corresponding AttributeValue 3350 --Arc for standard naming attributes 3351 id-at OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 4} 3352 -- Attributes of type NameDirectoryString 3353 id-at-name AttributeType ::= {id-at 41} 3354 id-at-surname AttributeType ::= {id-at 4} 3355 id-at-givenName AttributeType ::= {id-at 42} 3356 id-at-initials AttributeType ::= {id-at 43} 3357 id-at-generationQualifier AttributeType ::= {id-at 44} 3359 X520name ::= CHOICE { 3360 teletexString TeletexString (SIZE (1..ub-name)), 3361 printableString PrintableString (SIZE (1..ub-name)), 3362 universalString UniversalString (SIZE (1..ub-name)), 3363 utf8String UTF8String (SIZE (1..ub-name)), 3364 bmpString BMPString (SIZE(1..ub-name)) } 3366 -- 3368 id-at-commonName AttributeType ::= {id-at 3} 3370 X520CommonName ::= CHOICE { 3371 teletexString TeletexString (SIZE (1..ub-common-name)), 3372 printableString PrintableString (SIZE (1..ub-common-name)), 3373 universalString UniversalString (SIZE (1..ub-common-name)), 3374 utf8String UTF8String (SIZE (1..ub-common-name)), 3375 bmpString BMPString (SIZE(1..ub-common-name)) } 3377 -- 3379 id-at-localityName AttributeType ::= {id-at 7} 3381 X520LocalityName ::= CHOICE { 3382 teletexString TeletexString (SIZE (1..ub-locality-name)), 3383 printableString PrintableString (SIZE (1..ub-locality-name)), 3384 universalString UniversalString (SIZE (1..ub-locality-name)), 3385 utf8String UTF8String (SIZE (1..ub-locality-name)), 3386 bmpString BMPString (SIZE(1..ub-locality-name)) } 3388 -- 3390 id-at-stateOrProvinceName AttributeType ::= {id-at 8} 3392 X520StateOrProvinceName ::= CHOICE { 3393 teletexString TeletexString (SIZE (1..ub-state-name)), 3394 printableString PrintableString (SIZE (1..ub-state-name)), 3395 universalString UniversalString (SIZE (1..ub-state-name)), 3396 utf8String UTF8String (SIZE (1..ub-state-name)), 3397 bmpString BMPString (SIZE(1..ub-state-name)) } 3399 -- 3400 id-at-organizationName AttributeType ::= {id-at 10} 3402 X520OrganizationName ::= CHOICE { 3403 teletexString TeletexString (SIZE (1..ub-organization-name)), 3404 printableString PrintableString (SIZE (1..ub-organization-name)), 3405 universalString UniversalString (SIZE (1..ub-organization-name)), 3406 utf8String UTF8String (SIZE (1..ub-organization-name)), 3407 bmpString BMPString (SIZE(1..ub-organization-name)) } 3409 -- 3411 id-at-organizationalUnitName AttributeType ::= {id-at 11} 3413 X520OrganizationalUnitName ::= CHOICE { 3414 teletexString TeletexString (SIZE (1..ub-organizational-unit-name)), 3415 printableString PrintableString 3416 (SIZE (1..ub-organizational-unit-name)), 3417 universalString UniversalString 3418 (SIZE (1..ub-organizational-unit-name)), 3419 utf8String UTF8String (SIZE (1..ub-organizational-unit-name)), 3420 bmpString BMPString (SIZE(1..ub-organizational-unit-name)) } 3422 -- 3424 id-at-title AttributeType ::= {id-at 12} 3426 X520Title ::= CHOICE { 3427 teletexString TeletexString (SIZE (1..ub-title)), 3428 printableString PrintableString (SIZE (1..ub-title)), 3429 universalString UniversalString (SIZE (1..ub-title)), 3430 utf8String UTF8String (SIZE (1..ub-title)), 3431 bmpString BMPString (SIZE(1..ub-title)) } 3433 -- 3435 id-at-dnQualifier AttributeType ::= {id-at 46} 3436 X520dnQualifier ::= PrintableString 3438 id-at-countryName AttributeType ::= {id-at 6} 3439 X520countryName ::= PrintableString (SIZE (2)) -- IS 3166 codes 3441 -- Legacy attributes 3443 pkcs-9 OBJECT IDENTIFIER ::= 3444 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 } 3446 emailAddress AttributeType ::= { pkcs-9 1 } 3447 Pkcs9email ::= IA5String (SIZE (1..ub-emailaddress-length)) 3449 -- naming data types -- 3451 Name ::= CHOICE { -- only one possibility for now -- 3452 rdnSequence RDNSequence } 3454 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 3456 DistinguishedName ::= RDNSequence 3458 RelativeDistinguishedName ::= 3459 SET SIZE (1 .. MAX) OF AttributeTypeAndValue 3461 -- Directory string type -- 3463 DirectoryString ::= CHOICE { 3464 teletexString TeletexString (SIZE (1..MAX)), 3465 printableString PrintableString (SIZE (1..MAX)), 3466 universalString UniversalString (SIZE (1..MAX)), 3467 utf8String UTF8String (SIZE (1..MAX)), 3468 bmpString BMPString (SIZE(1..MAX)) } 3470 -- certificate and CRL specific structures begin here 3472 Certificate ::= SEQUENCE { 3473 tbsCertificate TBSCertificate, 3474 signatureAlgorithm AlgorithmIdentifier, 3475 signature BIT STRING } 3477 TBSCertificate ::= SEQUENCE { 3478 version [0] Version DEFAULT v1, 3479 serialNumber CertificateSerialNumber, 3480 signature AlgorithmIdentifier, 3481 issuer Name, 3482 validity Validity, 3483 subject Name, 3484 subjectPublicKeyInfo SubjectPublicKeyInfo, 3485 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 3486 -- If present, version shall be v2 or v3 3487 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 3488 -- If present, version shall be v2 or v3 3489 extensions [3] Extensions OPTIONAL 3490 -- If present, version shall be v3 -- } 3492 Version ::= INTEGER { v1(0), v2(1), v3(2) } 3494 CertificateSerialNumber ::= INTEGER 3495 Validity ::= SEQUENCE { 3496 notBefore Time, 3497 notAfter Time } 3499 Time ::= CHOICE { 3500 utcTime UTCTime, 3501 generalTime GeneralizedTime } 3503 UniqueIdentifier ::= BIT STRING 3505 SubjectPublicKeyInfo ::= SEQUENCE { 3506 algorithm AlgorithmIdentifier, 3507 subjectPublicKey BIT STRING } 3509 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 3511 Extension ::= SEQUENCE { 3512 extnID OBJECT IDENTIFIER, 3513 critical BOOLEAN DEFAULT FALSE, 3514 extnValue OCTET STRING } 3516 -- CRL structures 3518 CertificateList ::= SEQUENCE { 3519 tbsCertList TBSCertList, 3520 signatureAlgorithm AlgorithmIdentifier, 3521 signature BIT STRING } 3523 TBSCertList ::= SEQUENCE { 3524 version Version OPTIONAL, 3525 -- if present, shall be v2 3526 signature AlgorithmIdentifier, 3527 issuer Name, 3528 thisUpdate Time, 3529 nextUpdate Time OPTIONAL, 3530 revokedCertificates SEQUENCE OF SEQUENCE { 3531 userCertificate CertificateSerialNumber, 3532 revocationDate Time, 3533 crlEntryExtensions Extensions OPTIONAL 3534 -- if present, shall be v2 3535 } OPTIONAL, 3536 crlExtensions [0] Extensions OPTIONAL 3537 -- if present, shall be v2 -- } 3539 -- Version, Time, CertificateSerialNumber, and Extensions were 3540 -- defined earlier for use in the certificate structure 3542 AlgorithmIdentifier ::= SEQUENCE { 3543 algorithm OBJECT IDENTIFIER, 3544 parameters ANY DEFINED BY algorithm OPTIONAL } 3545 -- contains a value of the type 3546 -- registered for use with the 3547 -- algorithm object identifier value 3549 -- Algorithm OIDs and parameter structures 3551 pkcs-1 OBJECT IDENTIFIER ::= { 3552 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 } 3554 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } 3556 md2WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 2 } 3558 md5WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 4 } 3560 sha1WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 5 } 3562 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { 3563 iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 3 } 3565 Dss-Sig-Value ::= SEQUENCE { 3566 r INTEGER, 3567 s INTEGER } 3569 dhpublicnumber OBJECT IDENTIFIER ::= { 3570 iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 } 3572 DomainParameters ::= SEQUENCE { 3573 p INTEGER, -- odd prime, p=jq +1 3574 g INTEGER, -- generator, g 3575 q INTEGER, -- factor of p-1 3576 j INTEGER OPTIONAL, -- subgroup factor, j>= 2 3577 validationParms ValidationParms OPTIONAL } 3579 ValidationParms ::= SEQUENCE { 3580 seed BIT STRING, 3581 pgenCounter INTEGER } 3583 id-dsa OBJECT IDENTIFIER ::= { 3584 iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 } 3586 Dss-Parms ::= SEQUENCE { 3587 p INTEGER, 3588 q INTEGER, 3589 g INTEGER } 3591 -- x400 address syntax starts here 3592 -- OR Names 3594 ORAddress ::= SEQUENCE { 3595 built-in-standard-attributes BuiltInStandardAttributes, 3596 built-in-domain-defined-attributes 3597 BuiltInDomainDefinedAttributes OPTIONAL, 3598 -- see also teletex-domain-defined-attributes 3599 extension-attributes ExtensionAttributes OPTIONAL } 3600 -- The OR-address is semantically absent from the OR-name if the 3601 -- built-in-standard-attribute sequence is empty and the 3602 -- built-in-domain-defined-attributes and extension-attributes are 3603 -- both omitted. 3605 -- Built-in Standard Attributes 3607 BuiltInStandardAttributes ::= SEQUENCE { 3608 country-name CountryName OPTIONAL, 3609 administration-domain-name AdministrationDomainName OPTIONAL, 3610 network-address [0] NetworkAddress OPTIONAL, 3611 -- see also extended-network-address 3612 terminal-identifier [1] TerminalIdentifier OPTIONAL, 3613 private-domain-name [2] PrivateDomainName OPTIONAL, 3614 organization-name [3] OrganizationName OPTIONAL, 3615 -- see also teletex-organization-name 3616 numeric-user-identifier [4] NumericUserIdentifier OPTIONAL, 3617 personal-name [5] PersonalName OPTIONAL, 3618 -- see also teletex-personal-name 3619 organizational-unit-names [6] OrganizationalUnitNames OPTIONAL 3620 -- see also teletex-organizational-unit-names -- } 3622 CountryName ::= [APPLICATION 1] CHOICE { 3623 x121-dcc-code NumericString 3624 (SIZE (ub-country-name-numeric-length)), 3625 iso-3166-alpha2-code PrintableString 3626 (SIZE (ub-country-name-alpha-length)) } 3628 AdministrationDomainName ::= [APPLICATION 2] CHOICE { 3629 numeric NumericString (SIZE (0..ub-domain-name-length)), 3630 printable PrintableString (SIZE (0..ub-domain-name-length)) } 3632 NetworkAddress ::= X121Address -- see also extended-network-address 3634 X121Address ::= NumericString (SIZE (1..ub-x121-address-length)) 3636 TerminalIdentifier ::= PrintableString (SIZE (1..ub-terminal-id-length)) 3638 PrivateDomainName ::= CHOICE { 3639 numeric NumericString (SIZE (1..ub-domain-name-length)), 3640 printable PrintableString (SIZE (1..ub-domain-name-length)) } 3642 OrganizationName ::= PrintableString 3643 (SIZE (1..ub-organization-name-length)) 3644 -- see also teletex-organization-name 3646 NumericUserIdentifier ::= NumericString 3647 (SIZE (1..ub-numeric-user-id-length)) 3649 PersonalName ::= SET { 3650 surname [0] PrintableString (SIZE (1..ub-surname-length)), 3651 given-name [1] PrintableString 3652 (SIZE (1..ub-given-name-length)) OPTIONAL, 3653 initials [2] PrintableString (SIZE (1..ub-initials-length)) OPTIONAL, 3654 generation-qualifier [3] PrintableString 3655 (SIZE (1..ub-generation-qualifier-length)) OPTIONAL } 3656 -- see also teletex-personal-name 3658 OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units) 3659 OF OrganizationalUnitName 3660 -- see also teletex-organizational-unit-names 3662 OrganizationalUnitName ::= PrintableString (SIZE 3663 (1..ub-organizational-unit-name-length)) 3665 -- Built-in Domain-defined Attributes 3667 BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE 3668 (1..ub-domain-defined-attributes) OF 3669 BuiltInDomainDefinedAttribute 3671 BuiltInDomainDefinedAttribute ::= SEQUENCE { 3672 type PrintableString (SIZE 3673 (1..ub-domain-defined-attribute-type-length)), 3674 value PrintableString (SIZE 3675 (1..ub-domain-defined-attribute-value-length))} 3677 -- Extension Attributes 3679 ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF 3680 ExtensionAttribute 3682 ExtensionAttribute ::= SEQUENCE { 3683 extension-attribute-type [0] INTEGER (0..ub-extension-attributes), 3684 extension-attribute-value [1] 3685 ANY DEFINED BY extension-attribute-type } 3687 -- Extension types and attribute values 3688 -- 3690 common-name INTEGER ::= 1 3692 CommonName ::= PrintableString (SIZE (1..ub-common-name-length)) 3694 teletex-common-name INTEGER ::= 2 3696 TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length)) 3698 teletex-organization-name INTEGER ::= 3 3700 TeletexOrganizationName ::= 3701 TeletexString (SIZE (1..ub-organization-name-length)) 3703 teletex-personal-name INTEGER ::= 4 3705 TeletexPersonalName ::= SET { 3706 surname [0] TeletexString (SIZE (1..ub-surname-length)), 3707 given-name [1] TeletexString 3708 (SIZE (1..ub-given-name-length)) OPTIONAL, 3709 initials [2] TeletexString (SIZE (1..ub-initials-length)) OPTIONAL, 3710 generation-qualifier [3] TeletexString (SIZE 3711 (1..ub-generation-qualifier-length)) OPTIONAL } 3713 teletex-organizational-unit-names INTEGER ::= 5 3715 TeletexOrganizationalUnitNames ::= SEQUENCE SIZE 3716 (1..ub-organizational-units) OF TeletexOrganizationalUnitName 3718 TeletexOrganizationalUnitName ::= TeletexString 3719 (SIZE (1..ub-organizational-unit-name-length)) 3721 pds-name INTEGER ::= 7 3723 PDSName ::= PrintableString (SIZE (1..ub-pds-name-length)) 3725 physical-delivery-country-name INTEGER ::= 8 3727 PhysicalDeliveryCountryName ::= CHOICE { 3728 x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)), 3729 iso-3166-alpha2-code PrintableString 3730 (SIZE (ub-country-name-alpha-length)) } 3732 postal-code INTEGER ::= 9 3734 PostalCode ::= CHOICE { 3735 numeric-code NumericString (SIZE (1..ub-postal-code-length)), 3736 printable-code PrintableString (SIZE (1..ub-postal-code-length)) } 3738 physical-delivery-office-name INTEGER ::= 10 3740 PhysicalDeliveryOfficeName ::= PDSParameter 3742 physical-delivery-office-number INTEGER ::= 11 3744 PhysicalDeliveryOfficeNumber ::= PDSParameter 3746 extension-OR-address-components INTEGER ::= 12 3748 ExtensionORAddressComponents ::= PDSParameter 3750 physical-delivery-personal-name INTEGER ::= 13 3752 PhysicalDeliveryPersonalName ::= PDSParameter 3754 physical-delivery-organization-name INTEGER ::= 14 3756 PhysicalDeliveryOrganizationName ::= PDSParameter 3758 extension-physical-delivery-address-components INTEGER ::= 15 3760 ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter 3762 unformatted-postal-address INTEGER ::= 16 3764 UnformattedPostalAddress ::= SET { 3765 printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) OF 3766 PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL, 3767 teletex-string TeletexString 3768 (SIZE (1..ub-unformatted-address-length)) OPTIONAL } 3770 street-address INTEGER ::= 17 3772 StreetAddress ::= PDSParameter 3774 post-office-box-address INTEGER ::= 18 3776 PostOfficeBoxAddress ::= PDSParameter 3778 poste-restante-address INTEGER ::= 19 3780 PosteRestanteAddress ::= PDSParameter 3782 unique-postal-name INTEGER ::= 20 3783 UniquePostalName ::= PDSParameter 3785 local-postal-attributes INTEGER ::= 21 3787 LocalPostalAttributes ::= PDSParameter 3789 PDSParameter ::= SET { 3790 printable-string PrintableString 3791 (SIZE(1..ub-pds-parameter-length)) OPTIONAL, 3792 teletex-string TeletexString 3793 (SIZE(1..ub-pds-parameter-length)) OPTIONAL } 3795 extended-network-address INTEGER ::= 22 3797 ExtendedNetworkAddress ::= CHOICE { 3798 e163-4-address SEQUENCE { 3799 number [0] NumericString (SIZE (1..ub-e163-4-number-length)), 3800 sub-address [1] NumericString 3801 (SIZE (1..ub-e163-4-sub-address-length)) OPTIONAL }, 3802 psap-address [0] PresentationAddress } 3804 PresentationAddress ::= SEQUENCE { 3805 pSelector [0] EXPLICIT OCTET STRING OPTIONAL, 3806 sSelector [1] EXPLICIT OCTET STRING OPTIONAL, 3807 tSelector [2] EXPLICIT OCTET STRING OPTIONAL, 3808 nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING } 3810 terminal-type INTEGER ::= 23 3812 TerminalType ::= INTEGER { 3813 telex (3), 3814 teletex (4), 3815 g3-facsimile (5), 3816 g4-facsimile (6), 3817 ia5-terminal (7), 3818 videotex (8) } (0..ub-integer-options) 3820 -- Extension Domain-defined Attributes 3822 teletex-domain-defined-attributes INTEGER ::= 6 3824 TeletexDomainDefinedAttributes ::= SEQUENCE SIZE 3825 (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute 3827 TeletexDomainDefinedAttribute ::= SEQUENCE { 3828 type TeletexString 3829 (SIZE (1..ub-domain-defined-attribute-type-length)), 3830 value TeletexString 3831 (SIZE (1..ub-domain-defined-attribute-value-length)) } 3833 -- specifications of Upper Bounds shall be regarded as mandatory 3834 -- from Annex B of ITU-T X.411 Reference Definition of MTS Parameter 3835 -- Upper Bounds 3837 -- Upper Bounds 3838 ub-name INTEGER ::= 32768 3839 ub-common-name INTEGER ::= 64 3840 ub-locality-name INTEGER ::= 128 3841 ub-state-name INTEGER ::= 128 3842 ub-organization-name INTEGER ::= 64 3843 ub-organizational-unit-name INTEGER ::= 64 3844 ub-title INTEGER ::= 64 3845 ub-match INTEGER ::= 128 3847 ub-emailaddress-length INTEGER ::= 128 3849 ub-common-name-length INTEGER ::= 64 3850 ub-country-name-alpha-length INTEGER ::= 2 3851 ub-country-name-numeric-length INTEGER ::= 3 3852 ub-domain-defined-attributes INTEGER ::= 4 3853 ub-domain-defined-attribute-type-length INTEGER ::= 8 3854 ub-domain-defined-attribute-value-length INTEGER ::= 128 3855 ub-domain-name-length INTEGER ::= 16 3856 ub-extension-attributes INTEGER ::= 256 3857 ub-e163-4-number-length INTEGER ::= 15 3858 ub-e163-4-sub-address-length INTEGER ::= 40 3859 ub-generation-qualifier-length INTEGER ::= 3 3860 ub-given-name-length INTEGER ::= 16 3861 ub-initials-length INTEGER ::= 5 3862 ub-integer-options INTEGER ::= 256 3863 ub-numeric-user-id-length INTEGER ::= 32 3864 ub-organization-name-length INTEGER ::= 64 3865 ub-organizational-unit-name-length INTEGER ::= 32 3866 ub-organizational-units INTEGER ::= 4 3867 ub-pds-name-length INTEGER ::= 16 3868 ub-pds-parameter-length INTEGER ::= 30 3869 ub-pds-physical-address-lines INTEGER ::= 6 3870 ub-postal-code-length INTEGER ::= 16 3871 ub-surname-length INTEGER ::= 40 3872 ub-terminal-id-length INTEGER ::= 24 3873 ub-unformatted-address-length INTEGER ::= 180 3874 ub-x121-address-length INTEGER ::= 16 3876 -- Note - upper bounds on string types, such as TeletexString, are 3877 -- measured in characters. Excepting PrintableString or IA5String, a 3878 -- significantly greater number of octets will be required to hold 3879 -- such a value. As a minimum, 16 octets, or twice the specified upper 3880 -- bound, whichever is the larger, should be allowed for TeletexString. 3881 -- For UTF8String or UniversalString at least four times the upper 3882 -- bound should be allowed. 3884 END 3885 A.2 Implicitly Tagged Module, 1988 Syntax 3887 PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) 3888 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)} 3890 DEFINITIONS IMPLICIT TAGS ::= 3892 BEGIN 3894 -- EXPORTS ALL -- 3896 IMPORTS 3897 id-pe, id-qt, id-kp, id-ad, id-qt-unotice, id-qt-cps, 3898 ORAddress, Name, RelativeDistinguishedName, 3899 CertificateSerialNumber, 3900 CertificateList, AlgorithmIdentifier, ub-name, 3901 Attribute, DirectoryString 3902 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 3903 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3904 id-mod(0) id-pkix1-explicit(1)}; 3906 -- ISO arc for standard certificate and CRL extensions 3908 id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 3910 -- authority key identifier OID and syntax 3912 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 3914 AuthorityKeyIdentifier ::= SEQUENCE { 3915 keyIdentifier [0] KeyIdentifier OPTIONAL, 3916 authorityCertIssuer [1] GeneralNames OPTIONAL, 3917 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 3918 -- authorityCertIssuer and authorityCertSerialNumber shall both 3919 -- be present or both be absent 3921 KeyIdentifier ::= OCTET STRING 3923 -- subject key identifier OID and syntax 3925 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 3927 SubjectKeyIdentifier ::= KeyIdentifier 3929 -- key usage extension OID and syntax 3931 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 3932 KeyUsage ::= BIT STRING { 3933 digitalSignature (0), 3934 nonRepudiation (1), 3935 keyEncipherment (2), 3936 dataEncipherment (3), 3937 keyAgreement (4), 3938 keyCertSign (5), 3939 cRLSign (6) } 3941 -- private key usage period extension OID and syntax 3943 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 3945 PrivateKeyUsagePeriod ::= SEQUENCE { 3946 notBefore [0] GeneralizedTime OPTIONAL, 3947 notAfter [1] GeneralizedTime OPTIONAL } 3948 -- either notBefore or notAfter shall be present 3950 -- certificate policies extension OID and syntax 3952 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 3954 CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 3956 PolicyInformation ::= SEQUENCE { 3957 policyIdentifier CertPolicyId, 3958 policyQualifiers SEQUENCE SIZE (1..MAX) OF 3959 PolicyQualifierInfo OPTIONAL } 3961 CertPolicyId ::= OBJECT IDENTIFIER 3963 PolicyQualifierInfo ::= SEQUENCE { 3964 policyQualifierId PolicyQualifierId, 3965 qualifier ANY DEFINED BY policyQualifierId } 3967 -- Implementations that recognize additional policy qualifiers shall 3968 -- augment the following definition for PolicyQualifierId 3970 PolicyQualifierId ::= 3971 OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) 3973 -- CPS pointer qualifier 3975 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 3977 CPSuri ::= IA5String 3979 -- user notice qualifier 3980 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 3982 UserNotice ::= SEQUENCE { 3983 noticeRef NoticeReference OPTIONAL, 3984 explicitText DisplayText OPTIONAL} 3986 NoticeReference ::= SEQUENCE { 3987 organization DisplayText, 3988 noticeNumbers SEQUENCE OF INTEGER } 3990 DisplayText ::= CHOICE { 3991 visibleString VisibleString (SIZE (1..200)), 3992 bmpString BMPString (SIZE (1..200)), 3993 utf8String UTF8String (SIZE (1..200)) } 3995 -- policy mapping extension OID and syntax 3997 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 3999 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 4000 issuerDomainPolicy CertPolicyId, 4001 subjectDomainPolicy CertPolicyId } 4003 -- subject alternative name extension OID and syntax 4005 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 4007 SubjectAltName ::= GeneralNames 4009 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 4011 GeneralName ::= CHOICE { 4012 otherName [0] AnotherName, 4013 rfc822Name [1] IA5String, 4014 dNSName [2] IA5String, 4015 x400Address [3] ORAddress, 4016 directoryName [4] Name, 4017 ediPartyName [5] EDIPartyName, 4018 uniformResourceIdentifier [6] IA5String, 4019 iPAddress [7] OCTET STRING, 4020 registeredID [8] OBJECT IDENTIFIER } 4022 -- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as 4023 -- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax 4025 AnotherName ::= SEQUENCE { 4026 type-id OBJECT IDENTIFIER, 4027 value [0] EXPLICIT ANY DEFINED BY type-id } 4029 EDIPartyName ::= SEQUENCE { 4030 nameAssigner [0] DirectoryString OPTIONAL, 4031 partyName [1] DirectoryString } 4033 -- issuer alternative name extension OID and syntax 4035 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 4037 IssuerAltName ::= GeneralNames 4039 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 4041 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 4043 -- basic constraints extension OID and syntax 4045 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 4047 BasicConstraints ::= SEQUENCE { 4048 cA BOOLEAN DEFAULT FALSE, 4049 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 4051 -- name constraints extension OID and syntax 4053 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 4055 NameConstraints ::= SEQUENCE { 4056 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 4057 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 4059 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 4061 GeneralSubtree ::= SEQUENCE { 4062 base GeneralName, 4063 minimum [0] BaseDistance DEFAULT 0, 4064 maximum [1] BaseDistance OPTIONAL } 4066 BaseDistance ::= INTEGER (0..MAX) 4068 -- policy constraints extension OID and syntax 4070 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } 4072 PolicyConstraints ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 4073 requireExplicitPolicy [0] SkipCerts OPTIONAL, 4074 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 4076 SkipCerts ::= INTEGER (0..MAX) 4077 -- CRL distribution points extension OID and syntax 4079 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31} 4081 CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 4083 DistributionPoint ::= SEQUENCE { 4084 distributionPoint [0] DistributionPointName OPTIONAL, 4085 reasons [1] ReasonFlags OPTIONAL, 4086 cRLIssuer [2] GeneralNames OPTIONAL } 4088 DistributionPointName ::= CHOICE { 4089 fullName [0] GeneralNames, 4090 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 4092 ReasonFlags ::= BIT STRING { 4093 unused (0), 4094 keyCompromise (1), 4095 cACompromise (2), 4096 affiliationChanged (3), 4097 superseded (4), 4098 cessationOfOperation (5), 4099 certificateHold (6) } 4101 -- extended key usage extension OID and syntax 4103 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 4105 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 4107 KeyPurposeId ::= OBJECT IDENTIFIER 4109 -- extended key purpose OIDs 4110 id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } 4111 id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } 4112 id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } 4113 id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } 4114 id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 } 4115 id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 } 4116 id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 } 4117 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 4119 -- authority info access 4121 AuthorityInfoAccessSyntax ::= 4122 SEQUENCE SIZE (1..MAX) OF AccessDescription 4124 AccessDescription ::= SEQUENCE { 4125 accessMethod OBJECT IDENTIFIER, 4126 accessLocation GeneralName } 4128 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 4130 -- access descriptor definitions 4132 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 4133 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 4135 -- CRL number extension OID and syntax 4137 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 4139 CRLNumber ::= INTEGER (0..MAX) 4141 -- issuing distribution point extension OID and syntax 4143 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 4145 IssuingDistributionPoint ::= SEQUENCE { 4146 distributionPoint [0] DistributionPointName OPTIONAL, 4147 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 4148 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 4149 onlySomeReasons [3] ReasonFlags OPTIONAL, 4150 indirectCRL [4] BOOLEAN DEFAULT FALSE } 4152 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 4154 -- deltaCRLIndicator ::= BaseCRLNumber 4156 BaseCRLNumber ::= CRLNumber 4158 -- CRL reasons extension OID and syntax 4160 id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 } 4162 CRLReason ::= ENUMERATED { 4163 unspecified (0), 4164 keyCompromise (1), 4165 cACompromise (2), 4166 affiliationChanged (3), 4167 superseded (4), 4168 cessationOfOperation (5), 4169 certificateHold (6), 4170 removeFromCRL (8) } 4172 -- certificate issuer CRL entry extension OID and syntax 4174 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } 4176 CertificateIssuer ::= GeneralNames 4178 -- hold instruction extension OID and syntax 4180 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 4182 HoldInstructionCode ::= OBJECT IDENTIFIER 4184 -- ANSI x9 holdinstructions 4186 -- ANSI x9 arc holdinstruction arc 4187 holdInstruction OBJECT IDENTIFIER ::= 4188 {joint-iso-itu-t(2) member-body(2) us(840) x9cm(10040) 2} 4190 -- ANSI X9 holdinstructions referenced by this standard 4191 id-holdinstruction-none OBJECT IDENTIFIER ::= 4192 {holdInstruction 1} -- deprecated 4193 id-holdinstruction-callissuer OBJECT IDENTIFIER ::= 4194 {holdInstruction 2} 4195 id-holdinstruction-reject OBJECT IDENTIFIER ::= 4196 {holdInstruction 3} 4198 -- invalidity date CRL entry extension OID and syntax 4200 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 4202 InvalidityDate ::= GeneralizedTime 4204 END 4205 Appendix B. 1993 ASN.1 Structures and OIDs 4207 B.1 Explicitly Tagged Module, 1993 Syntax 4209 PKIX1Explicit93 {iso(1) identified-organization(3) dod(6) internet(1) 4210 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-93(3)} 4212 DEFINITIONS EXPLICIT TAGS ::= 4214 BEGIN 4216 -- EXPORTS ALL -- 4218 IMPORTS 4219 authorityKeyIdentifier, subjectKeyIdentifier, keyUsage, 4220 extendedKeyUsage, privateKeyUsagePeriod, certificatePolicies, 4221 policyMappings, subjectAltName, issuerAltName, 4222 basicConstraints, nameConstraints, policyConstraints, 4223 cRLDistributionPoints, subjectDirectoryAttributes, 4224 cRLNumber, reasonCode, instructionCode, invalidityDate, 4225 issuingDistributionPoint, certificateIssuer, 4226 deltaCRLIndicator, authorityInfoAccess, id-ce 4227 FROM PKIX1Implicit93 {iso(1) identified-organization(3) 4228 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 4229 id-mod(0) id-pkix1-implicit-93(4)} ; 4231 -- 4232 -- Locally defined OIDs -- 4234 id-pkix OBJECT IDENTIFIER ::= 4235 { iso(1) identified-organization(3) dod(6) internet(1) 4236 security(5) mechanisms(5) pkix(7) } 4238 -- PKIX arcs 4239 -- arc for private certificate extensions 4240 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 4241 -- arc for policy qualifier types 4242 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 4243 -- arc for extended key purpose OIDS 4244 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 4245 -- arc for access descriptors 4246 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 4248 -- policyQualifierIds for Internet policy qualifiers 4249 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 4250 -- OID for CPS qualifier 4252 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 4253 -- OID for user notice qualifier 4255 -- based on excerpts from AuthenticationFramework 4256 -- {joint-iso-ccitt ds(5) modules(1) authenticationFramework(7) 2} 4258 -- Public Key Certificate -- 4260 Certificate ::= SIGNED { SEQUENCE { 4261 version [0] Version DEFAULT v1, 4262 serialNumber CertificateSerialNumber, 4263 signature AlgorithmIdentifier, 4264 issuer Name, 4265 validity Validity, 4266 subject Name, 4267 subjectPublicKeyInfo SubjectPublicKeyInfo, 4268 issuerUniqueIdentifier [1] IMPLICIT UniqueIdentifier OPTIONAL, 4269 ---if present, version shall be v2 or v3-- 4270 subjectUniqueIdentifier [2] IMPLICIT UniqueIdentifier OPTIONAL, 4271 ---if present, version shall be v2 or v3-- 4272 extensions [3] Extensions OPTIONAL 4273 --if present, version shall be v3--} } 4275 UniqueIdentifier ::= BIT STRING 4277 Version ::= INTEGER { v1(0), v2(1), v3(2) } 4279 CertificateSerialNumber ::= INTEGER 4281 Validity ::= SEQUENCE { 4282 notBefore Time, 4283 notAfter Time } 4285 Time ::= CHOICE { 4286 utcTime UTCTime, 4287 generalTime GeneralizedTime } 4289 SubjectPublicKeyInfo ::= SEQUENCE{ 4290 algorithm AlgorithmIdentifier, 4291 subjectPublicKey BIT STRING} 4293 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 4295 Extension ::= SEQUENCE { 4296 extnId EXTENSION.&id ({ExtensionSet}), 4297 critical BOOLEAN DEFAULT FALSE, 4298 extnValue OCTET STRING } 4299 -- contains a DER encoding of a value of type 4300 -- &ExtnType for the 4301 -- extension object identified by extnId -- 4303 -- The following information object set is defined to constrain the 4304 -- set of legal certificate extensions. 4306 ExtensionSet EXTENSION ::= { authorityKeyIdentifier | 4307 subjectKeyIdentifier | 4308 keyUsage | 4309 extendedKeyUsage | 4310 privateKeyUsagePeriod | 4311 certificatePolicies | 4312 policyMappings | 4313 subjectAltName | 4314 issuerAltName | 4315 basicConstraints | 4316 nameConstraints | 4317 policyConstraints | 4318 cRLDistributionPoints | 4319 subjectDirectoryAttributes | 4320 authorityInfoAccess } 4322 EXTENSION ::= CLASS { 4323 &id OBJECT IDENTIFIER UNIQUE, 4324 &ExtnType } 4325 WITH SYNTAX { 4326 SYNTAX &ExtnType 4327 IDENTIFIED BY &id } 4329 -- Certificate Revocation List -- 4331 CertificateList ::= SIGNED { SEQUENCE { 4332 version Version OPTIONAL, -- if present, shall be v2 4333 signature AlgorithmIdentifier, 4334 issuer Name, 4335 thisUpdate Time, 4336 nextUpdate Time OPTIONAL, 4337 revokedCertificates SEQUENCE OF SEQUENCE { 4338 userCertificate CertificateSerialNumber, 4339 revocationDate Time, 4340 crlEntryExtensions EntryExtensions OPTIONAL } OPTIONAL, 4341 crlExtensions [0] CRLExtensions OPTIONAL }} 4343 CRLExtensions ::= SEQUENCE SIZE (1..MAX) OF CRLExtension 4345 CRLExtension ::= SEQUENCE { 4346 extnId EXTENSION.&id ({CRLExtensionSet}), 4347 critical BOOLEAN DEFAULT FALSE, 4348 extnValue OCTET STRING } 4349 -- contains a DER encoding of a value of type 4350 -- &ExtnType for the 4351 -- extension object identified by extnId -- 4353 -- The following information object set is defined to constrain the 4354 -- set of legal CRL extensions. 4356 CRLExtensionSet EXTENSION ::= { authorityKeyIdentifier | 4357 issuerAltName | 4358 cRLNumber | 4359 deltaCRLIndicator | 4360 issuingDistributionPoint } 4362 -- EXTENSION defined above for certificates 4364 EntryExtensions ::= SEQUENCE SIZE (1..MAX) OF EntryExtension 4366 EntryExtension ::= SEQUENCE { 4367 extnId EXTENSION.&id ({EntryExtensionSet}), 4368 critical BOOLEAN DEFAULT FALSE, 4369 extnValue OCTET STRING } 4370 -- contains a DER encoding of a value of type 4371 -- &ExtnType for the 4372 -- extension object identified by extnId -- 4374 -- The following information object set is defined to constrain the 4375 -- set of legal CRL entry extensions. 4377 EntryExtensionSet EXTENSION ::= { reasonCode | 4378 instructionCode | 4379 invalidityDate | 4380 certificateIssuer } 4382 -- information object classes used in the defintion -- 4383 -- of certificates and CRLs -- 4385 -- Parameterized Type SIGNED -- 4387 SIGNED { ToBeSigned } ::= SEQUENCE { 4388 toBeSigned ToBeSigned, 4389 algorithm AlgorithmIdentifier, 4390 signature BIT STRING 4391 } 4393 -- Definition of AlgorithmIdentifier 4394 -- ISO definition was: 4395 -- 4396 -- AlgorithmIdentifier ::= SEQUENCE { 4397 -- algorithm ALGORITHM.&id({SupportedAlgorithms}), 4398 -- parameters ALGORITHM.&Type({SupportedAlgorithms} 4399 -- { @algorithm}) OPTIONAL } 4400 -- Definition of ALGORITHM 4401 -- ALGORITHM ::= TYPE-IDENTIFIER 4403 -- The following PKIX definition replaces the X.509 definition 4404 -- 4406 AlgorithmIdentifier ::= SEQUENCE { 4407 algorithm ALGORITHM-ID.&id({SupportedAlgorithms}), 4408 parameters ALGORITHM-ID.&Type({SupportedAlgorithms} 4409 { @algorithm}) OPTIONAL } 4411 -- Definition of ALGORITHM-ID 4413 ALGORITHM-ID ::= CLASS { 4414 &id OBJECT IDENTIFIER UNIQUE, 4415 &Type OPTIONAL 4416 } 4417 WITH SYNTAX { OID &id [PARMS &Type] } 4419 -- The definition of SupportedAlgorithms may be modified as this 4420 -- document does not specify a mandatory algorithm set. In addition, 4421 -- the set is specified as extensible, since additional algorithms 4422 -- may be supported 4424 SupportedAlgorithms ALGORITHM-ID ::= { ..., -- extensible 4425 RsaPublicKey | 4426 RsaSHA-1 | 4427 RsaMD5 | 4428 RsaMD2 | 4429 DssPublicKey | 4430 DsaSHA-1 | 4431 Dhpublicnumber } 4433 -- OIDs and parameter structures for ALGORITHM-IDs used 4434 -- in this specification 4436 RsaPublicKey ALGORITHM-ID ::= { OID rsaEncryption PARMS NULL } 4438 RsaSHA-1 ALGORITHM-ID ::= { OID sha1WithRSAEncryption PARMS NULL } 4440 RsaMD5 ALGORITHM-ID ::= { OID md5WithRSAEncryption PARMS NULL } 4442 RsaMD2 ALGORITHM-ID ::= { OID md2WithRSAEncryption PARMS NULL } 4443 DssPublicKey ALGORITHM-ID ::= { OID id-dsa PARMS Dss-Parms } 4445 DsaSHA-1 ALGORITHM-ID ::= { OID id-dsa-with-sha1 PARMS NULL } 4447 DhPublicKey ALGORITHM-ID ::= {OID dhpublicnumber PARMS DomainParameters} 4449 -- algorithm identifiers and parameter structures 4451 pkcs-1 OBJECT IDENTIFIER ::= { 4452 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 } 4454 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } 4456 md2WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 2 } 4458 md5WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 4 } 4460 sha1WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 5 } 4462 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { 4463 iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 3 } 4465 Dss-Sig-Value ::= SEQUENCE { 4466 r INTEGER, 4467 s INTEGER } 4469 dhpublicnumber OBJECT IDENTIFIER ::= { 4470 iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 } 4472 DomainParameters ::= SEQUENCE { 4473 p INTEGER, -- odd prime, p=jq +1 4474 g INTEGER, -- generator, g 4475 q INTEGER, -- factor of p-1 4476 j INTEGER OPTIONAL, -- subgroup factor, j>= 2 4477 validationParms ValidationParms OPTIONAL } 4479 ValidationParms ::= SEQUENCE { 4480 seed BIT STRING, 4481 pgenCounter INTEGER } 4483 id-dsa OBJECT IDENTIFIER ::= { 4484 iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 } 4486 Dss-Parms ::= SEQUENCE { 4487 p INTEGER, 4488 q INTEGER, 4489 g INTEGER } 4490 -- The ASN.1 in this section supports the Name type 4491 -- and the directoryAttribute extension 4493 -- attribute data types -- 4495 Attribute ::= SEQUENCE { 4496 type ATTRIBUTE.&id ({SupportedAttributes}), 4497 values SET SIZE (1 .. MAX) OF ATTRIBUTE.&Type 4498 ({SupportedAttributes}{@type})} 4500 AttributeTypeAndValue ::= SEQUENCE { 4501 type ATTRIBUTE.&id ({SupportedAttributes}), 4502 value ATTRIBUTE.&Type ({SupportedAttributes}{@type})} 4504 -- naming data types -- 4506 Name ::= CHOICE { -- only one possibility for now -- 4507 rdnSequence RDNSequence } 4509 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 4511 RelativeDistinguishedName ::= 4512 SET SIZE (1 .. MAX) OF AttributeTypeAndValue 4514 ID ::= OBJECT IDENTIFIER 4516 -- ATTRIBUTE information object class specification 4517 -- Note: This has been greatly simplified for PKIX !! 4519 ATTRIBUTE ::= CLASS { 4520 &Type, 4521 &id OBJECT IDENTIFIER UNIQUE } 4522 WITH SYNTAX { 4523 WITH SYNTAX &Type ID &id } 4525 -- suggested naming attributes 4526 -- Definition of the following information object set may be 4527 -- augmented to meet local requirements. Note that deleting 4528 -- members of the set may prevent interoperability with 4529 -- conforming implementations. 4531 SupportedAttributes ATTRIBUTE ::= { 4532 name | commonName | surname | givenName | initials | 4533 generationQualifier | dnQualifier | countryName | 4534 localityName | stateOrProvinceName | organizationName | 4535 organizationalUnitName | title | pkcs9email } 4537 name ATTRIBUTE ::= { 4538 WITH SYNTAX DirectoryString { ub-name } 4539 ID id-at-name } 4541 commonName ATTRIBUTE ::= { 4542 WITH SYNTAX DirectoryString {ub-common-name} 4543 ID id-at-commonName } 4545 surname ATTRIBUTE ::= { 4546 WITH SYNTAX DirectoryString {ub-name} 4547 ID id-at-surname } 4549 givenName ATTRIBUTE ::= { 4550 WITH SYNTAX DirectoryString {ub-name} 4551 ID id-at-givenName } 4553 initials ATTRIBUTE ::= { 4554 WITH SYNTAX DirectoryString {ub-name} 4555 ID id-at-initials } 4557 generationQualifier ATTRIBUTE ::= { 4558 WITH SYNTAX DirectoryString {ub-name} 4559 ID id-at-generationQualifier} 4561 dnQualifier ATTRIBUTE ::= { 4562 WITH SYNTAX PrintableString 4563 ID id-at-dnQualifier } 4565 countryName ATTRIBUTE ::= { 4566 WITH SYNTAX PrintableString (SIZE (2)) 4567 -- IS 3166 codes only 4568 ID id-at-countryName } 4570 localityName ATTRIBUTE ::= { 4571 WITH SYNTAX DirectoryString {ub-locality-name} 4572 ID id-at-localityName } 4574 stateOrProvinceName ATTRIBUTE ::= { 4575 WITH SYNTAX DirectoryString {ub-state-name} 4576 ID id-at-stateOrProvinceName } 4578 organizationName ATTRIBUTE ::= { 4579 WITH SYNTAX DirectoryString {ub-organization-name} 4580 ID id-at-organizationName } 4582 organizationalUnitName ATTRIBUTE ::= { 4583 WITH SYNTAX DirectoryString {ub-organizational-unit-name} 4584 ID id-at-organizationalUnitName } 4586 title ATTRIBUTE ::= { 4587 WITH SYNTAX DirectoryString {ub-title} 4588 ID id-at-title } 4590 -- Legacy attributes 4592 pkcs9email ATTRIBUTE ::= { 4593 WITH SYNTAX PHGString, 4594 ID emailAddress } 4596 PHGString ::= IA5String (SIZE(1..ub-emailaddress-length)) 4598 pkcs-9 OBJECT IDENTIFIER ::= 4599 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 } 4601 emailAddress OBJECT IDENTIFIER ::= { pkcs-9 1 } 4603 -- object identifiers for Name type and directory attribute support 4605 -- Object identifier assignments -- 4607 id-at OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 4} 4609 -- Attributes -- 4611 id-at-commonName OBJECT IDENTIFIER ::= {id-at 3} 4612 id-at-surname OBJECT IDENTIFIER ::= {id-at 4} 4613 id-at-countryName OBJECT IDENTIFIER ::= {id-at 6} 4614 id-at-localityName OBJECT IDENTIFIER ::= {id-at 7} 4615 id-at-stateOrProvinceName OBJECT IDENTIFIER ::= {id-at 8} 4616 id-at-organizationName OBJECT IDENTIFIER ::= {id-at 10} 4617 id-at-organizationalUnitName OBJECT IDENTIFIER ::= {id-at 11} 4618 id-at-title OBJECT IDENTIFIER ::= {id-at 12} 4619 id-at-name OBJECT IDENTIFIER ::= {id-at 41} 4620 id-at-givenName OBJECT IDENTIFIER ::= {id-at 42} 4621 id-at-initials OBJECT IDENTIFIER ::= {id-at 43} 4622 id-at-generationQualifier OBJECT IDENTIFIER ::= {id-at 44} 4623 id-at-dnQualifier OBJECT IDENTIFIER ::= {id-at 46} 4625 -- Directory string type, used extensively in Name types -- 4627 DirectoryString { INTEGER:maxSize } ::= CHOICE { 4628 teletexString TeletexString (SIZE (1..maxSize)), 4629 printableString PrintableString (SIZE (1..maxSize)), 4630 universalString UniversalString (SIZE (1..maxSize)), 4631 bmpString BMPString (SIZE(1..maxSize)), 4632 utf8String UTF8String (SIZE(1..maxSize)) 4633 } 4635 -- End of ASN.1 for Name type and directory attribute support -- 4637 -- The ASN.1 in this section supports X.400 style names -- 4638 -- for implementations that use the x400Address component -- 4639 -- of GeneralName. -- 4641 ORAddress ::= SEQUENCE { 4642 built-in-standard-attributes BuiltInStandardAttributes, 4643 built-in-domain-defined-attributes 4644 BuiltInDomainDefinedAttributes OPTIONAL, 4645 -- see also teletex-domain-defined-attributes 4646 extension-attributes ExtensionAttributes OPTIONAL } 4648 -- The OR-address is semantically absent from the OR-name if the 4649 -- built-in-standard-attribute sequence is empty and the 4650 -- built-in-domain-defined-attributes and extension-attributes are 4651 -- both omitted. 4653 -- Built-in Standard Attributes 4655 BuiltInStandardAttributes ::= SEQUENCE { 4656 country-name CountryName OPTIONAL, 4657 administration-domain-name AdministrationDomainName OPTIONAL, 4658 network-address [0] NetworkAddress OPTIONAL, 4659 -- see also extended-network-address 4660 terminal-identifier [1] TerminalIdentifier OPTIONAL, 4661 private-domain-name [2] PrivateDomainName OPTIONAL, 4662 organization-name [3] OrganizationName OPTIONAL, 4663 -- see also teletex-organization-name 4664 numeric-user-identifier [4] NumericUserIdentifier OPTIONAL, 4665 personal-name [5] PersonalName OPTIONAL, 4666 -- see also teletex-personal-name 4667 organizational-unit-names [6] OrganizationalUnitNames OPTIONAL 4668 -- see also teletex-organizational-unit-names -- } 4670 CountryName ::= [APPLICATION 1] CHOICE { 4671 x121-dcc-code NumericString 4672 (SIZE (ub-country-name-numeric-length)), 4673 iso-3166-alpha2-code PrintableString 4674 (SIZE (ub-country-name-alpha-length)) } 4676 AdministrationDomainName ::= [APPLICATION 2] CHOICE { 4677 numeric NumericString (SIZE (0..ub-domain-name-length)), 4678 printable PrintableString (SIZE (0..ub-domain-name-length)) } 4680 NetworkAddress ::= X121Address 4681 -- see also extended-network-address 4682 X121Address ::= NumericString (SIZE (1..ub-x121-address-length)) 4684 TerminalIdentifier ::= PrintableString (SIZE (1..ub-terminal-id-length)) 4686 PrivateDomainName ::= CHOICE { 4687 numeric NumericString (SIZE (1..ub-domain-name-length)), 4688 printable PrintableString (SIZE (1..ub-domain-name-length)) } 4690 OrganizationName ::= PrintableString 4691 (SIZE (1..ub-organization-name-length)) 4692 -- see also teletex-organization-name 4694 NumericUserIdentifier ::= NumericString 4695 (SIZE (1..ub-numeric-user-id-length)) 4697 PersonalName ::= SET { 4698 surname [0] PrintableString (SIZE (1..ub-surname-length)), 4699 given-name [1] PrintableString 4700 (SIZE (1..ub-given-name-length)) OPTIONAL, 4701 initials [2] PrintableString 4702 (SIZE (1..ub-initials-length)) OPTIONAL, 4703 generation-qualifier [3] PrintableString 4704 (SIZE (1..ub-generation-qualifier-length)) OPTIONAL} 4705 -- see also teletex-personal-name 4707 OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units) 4708 OF OrganizationalUnitName 4709 -- see also teletex-organizational-unit-names 4711 OrganizationalUnitName ::= PrintableString (SIZE 4712 (1..ub-organizational-unit-name-length)) 4714 -- Built-in Domain-defined Attributes 4715 BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE 4716 (1..ub-domain-defined-attributes) OF 4717 BuiltInDomainDefinedAttribute 4719 BuiltInDomainDefinedAttribute ::= SEQUENCE { 4720 type PrintableString (SIZE 4721 (1..ub-domain-defined-attribute-type-length)), 4722 value PrintableString (SIZE 4723 (1..ub-domain-defined-attribute-value-length)) } 4725 -- Extension Attributes 4727 ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) 4728 OF ExtensionAttribute 4729 ExtensionAttribute ::= SEQUENCE { 4730 extension-attribute-type [0] EXTENSION-ATTRIBUTE.&id 4731 ({ExtensionAttributeTable}), 4732 extension-attribute-value [1] EXTENSION-ATTRIBUTE.&Type 4733 ({ExtensionAttributeTable} {@extension-attribute-type}) } 4735 EXTENSION-ATTRIBUTE ::= CLASS { 4736 &id INTEGER (0..ub-extension-attributes) UNIQUE, 4737 &Type } 4738 WITH SYNTAX {&Type IDENTIFIED BY &id} 4740 ExtensionAttributeTable EXTENSION-ATTRIBUTE ::= { 4741 common-name | 4742 teletex-common-name | 4743 teletex-organization-name | 4744 teletex-personal-name | 4745 teletex-organizational-unit-names | 4746 teletex-domain-defined-attributes | 4747 pds-name | 4748 physical-delivery-country-name | 4749 postal-code | 4750 physical-delivery-office-name | 4751 physical-delivery-office-number | 4752 extension-OR-address-components | 4753 physical-delivery-personal-name | 4754 physical-delivery-organization-name | 4755 extension-physical-delivery-address-components | 4756 unformatted-postal-address | 4757 street-address | 4758 post-office-box-address | 4759 poste-restante-address | 4760 unique-postal-name | 4761 local-postal-attributes | 4762 extended-network-address | 4763 terminal-type } 4765 -- Extension Standard Attributes 4767 common-name EXTENSION-ATTRIBUTE ::= {CommonName IDENTIFIED BY 1} 4769 CommonName ::= PrintableString (SIZE (1..ub-common-name-length)) 4771 teletex-common-name EXTENSION-ATTRIBUTE ::= 4772 {TeletexCommonName IDENTIFIED BY 2} 4774 TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length)) 4776 teletex-organization-name EXTENSION-ATTRIBUTE ::= 4777 {TeletexOrganizationName IDENTIFIED BY 3} 4779 TeletexOrganizationName ::= 4780 TeletexString (SIZE (1..ub-organization-name-length)) 4782 teletex-personal-name EXTENSION-ATTRIBUTE ::= 4783 {TeletexPersonalName IDENTIFIED BY 4} 4785 TeletexPersonalName ::= SET { 4786 surname [0] TeletexString (SIZE (1..ub-surname-length)), 4787 given-name [1] TeletexString 4788 (SIZE (1..ub-given-name-length)) OPTIONAL, 4789 initials [2] TeletexString (SIZE (1..ub-initials-length)) OPTIONAL, 4790 generation-qualifier [3] TeletexString (SIZE 4791 (1..ub-generation-qualifier-length)) OPTIONAL } 4793 teletex-organizational-unit-names EXTENSION-ATTRIBUTE ::= 4794 {TeletexOrganizationalUnitNames IDENTIFIED BY 5} 4796 TeletexOrganizationalUnitNames ::= SEQUENCE SIZE 4797 (1..ub-organizational-units) OF TeletexOrganizationalUnitName 4799 TeletexOrganizationalUnitName ::= TeletexString 4800 (SIZE (1..ub-organizational-unit-name-length)) 4802 pds-name EXTENSION-ATTRIBUTE ::= {PDSName IDENTIFIED BY 7} 4804 PDSName ::= PrintableString (SIZE (1..ub-pds-name-length)) 4806 physical-delivery-country-name EXTENSION-ATTRIBUTE ::= 4807 {PhysicalDeliveryCountryName IDENTIFIED BY 8} 4809 PhysicalDeliveryCountryName ::= CHOICE { 4810 x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)), 4811 iso-3166-alpha2-code PrintableString 4812 (SIZE (ub-country-name-alpha-length)) } 4814 postal-code EXTENSION-ATTRIBUTE ::= {PostalCode IDENTIFIED BY 9} 4816 PostalCode ::= CHOICE { 4817 numeric-code NumericString (SIZE (1..ub-postal-code-length)), 4818 printable-code PrintableString (SIZE (1..ub-postal-code-length)) } 4820 physical-delivery-office-name EXTENSION-ATTRIBUTE ::= 4821 {PhysicalDeliveryOfficeName IDENTIFIED BY 10} 4823 PhysicalDeliveryOfficeName ::= PDSParameter 4825 physical-delivery-office-number EXTENSION-ATTRIBUTE ::= 4826 {PhysicalDeliveryOfficeNumber IDENTIFIED BY 11} 4828 PhysicalDeliveryOfficeNumber ::= PDSParameter 4830 extension-OR-address-components EXTENSION-ATTRIBUTE ::= 4831 {ExtensionORAddressComponents IDENTIFIED BY 12} 4833 ExtensionORAddressComponents ::= PDSParameter 4835 physical-delivery-personal-name EXTENSION-ATTRIBUTE ::= 4836 {PhysicalDeliveryPersonalName IDENTIFIED BY 13} 4838 PhysicalDeliveryPersonalName ::= PDSParameter 4840 physical-delivery-organization-name EXTENSION-ATTRIBUTE ::= 4841 {PhysicalDeliveryOrganizationName IDENTIFIED BY 14} 4843 PhysicalDeliveryOrganizationName ::= PDSParameter 4845 extension-physical-delivery-address-components EXTENSION-ATTRIBUTE ::= 4846 {ExtensionPhysicalDeliveryAddressComponents IDENTIFIED BY 15} 4848 ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter 4850 unformatted-postal-address EXTENSION-ATTRIBUTE ::= 4851 {UnformattedPostalAddress IDENTIFIED BY 16} 4853 UnformattedPostalAddress ::= SET { 4854 printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) OF 4855 PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL, 4856 teletex-string TeletexString (SIZE 4857 (1..ub-unformatted-address-length)) OPTIONAL } 4859 street-address EXTENSION-ATTRIBUTE ::= 4860 {StreetAddress IDENTIFIED BY 17} 4862 StreetAddress ::= PDSParameter 4864 post-office-box-address EXTENSION-ATTRIBUTE ::= 4865 {PostOfficeBoxAddress IDENTIFIED BY 18} 4867 PostOfficeBoxAddress ::= PDSParameter 4869 poste-restante-address EXTENSION-ATTRIBUTE ::= 4870 {PosteRestanteAddress IDENTIFIED BY 19} 4872 PosteRestanteAddress ::= PDSParameter 4874 unique-postal-name EXTENSION-ATTRIBUTE ::= 4875 {UniquePostalName IDENTIFIED BY 20} 4877 UniquePostalName ::= PDSParameter 4879 local-postal-attributes EXTENSION-ATTRIBUTE ::= 4880 {LocalPostalAttributes IDENTIFIED BY 21} 4882 LocalPostalAttributes ::= PDSParameter 4884 PDSParameter ::= SET { 4885 printable-string PrintableString 4886 (SIZE(1..ub-pds-parameter-length)) OPTIONAL, 4887 teletex-string TeletexString 4888 (SIZE(1..ub-pds-parameter-length)) OPTIONAL } 4890 extended-network-address EXTENSION-ATTRIBUTE ::= 4891 {ExtendedNetworkAddress IDENTIFIED BY 22} 4893 ExtendedNetworkAddress ::= CHOICE { 4894 e163-4-address SEQUENCE { 4895 number [0] NumericString 4896 (SIZE (1..ub-e163-4-number-length)), 4897 sub-address [1] NumericString 4898 (SIZE (1..ub-e163-4-sub-address-length)) OPTIONAL}, 4899 psap-address [0] PresentationAddress } 4901 PresentationAddress ::= SEQUENCE { 4902 pSelector [0] EXPLICIT OCTET STRING OPTIONAL, 4903 sSelector [1] EXPLICIT OCTET STRING OPTIONAL, 4904 tSelector [2] EXPLICIT OCTET STRING OPTIONAL, 4905 nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING} 4907 terminal-type EXTENSION-ATTRIBUTE ::= {TerminalType IDENTIFIED BY 23} 4909 TerminalType ::= INTEGER { 4910 telex (3), 4911 teletex (4), 4912 g3-facsimile (5), 4913 g4-facsimile (6), 4914 ia5-terminal (7), 4915 videotex (8) } (0..ub-integer-options) 4917 -- Extension Domain-defined Attributes 4919 teletex-domain-defined-attributes EXTENSION-ATTRIBUTE ::= 4920 {TeletexDomainDefinedAttributes IDENTIFIED BY 6} 4922 TeletexDomainDefinedAttributes ::= SEQUENCE SIZE 4923 (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute 4925 TeletexDomainDefinedAttribute ::= SEQUENCE { 4926 type TeletexString 4927 (SIZE (1..ub-domain-defined-attribute-type-length)), 4928 value TeletexString 4929 (SIZE (1..ub-domain-defined-attribute-value-length)) } 4931 -- specifications of Upper Bounds 4932 -- shall be regarded as mandatory 4933 -- from Annex B of ITU-T X.411 4934 -- Reference Definition of MTS Parameter Upper Bounds 4936 -- Upper Bounds 4937 ub-name INTEGER ::= 32768 4938 ub-common-name INTEGER ::= 64 4939 ub-locality-name INTEGER ::= 128 4940 ub-state-name INTEGER ::= 128 4941 ub-organization-name INTEGER ::= 64 4942 ub-organizational-unit-name INTEGER ::= 64 4943 ub-title INTEGER ::= 64 4944 ub-match INTEGER ::= 128 4946 ub-emailaddress-length INTEGER ::= 128 4948 ub-common-name-length INTEGER ::= 64 4949 ub-country-name-alpha-length INTEGER ::= 2 4950 ub-country-name-numeric-length INTEGER ::= 3 4951 ub-domain-defined-attributes INTEGER ::= 4 4952 ub-domain-defined-attribute-type-length INTEGER ::= 8 4953 ub-domain-defined-attribute-value-length INTEGER ::= 128 4954 ub-domain-name-length INTEGER ::= 16 4955 ub-extension-attributes INTEGER ::= 256 4956 ub-e163-4-number-length INTEGER ::= 15 4957 ub-e163-4-sub-address-length INTEGER ::= 40 4958 ub-generation-qualifier-length INTEGER ::= 3 4959 ub-given-name-length INTEGER ::= 16 4960 ub-initials-length INTEGER ::= 5 4961 ub-integer-options INTEGER ::= 256 4962 ub-numeric-user-id-length INTEGER ::= 32 4963 ub-organization-name-length INTEGER ::= 64 4964 ub-organizational-unit-name-length INTEGER ::= 32 4965 ub-organizational-units INTEGER ::= 4 4966 ub-pds-name-length INTEGER ::= 16 4967 ub-pds-parameter-length INTEGER ::= 30 4968 ub-pds-physical-address-lines INTEGER ::= 6 4969 ub-postal-code-length INTEGER ::= 16 4970 ub-surname-length INTEGER ::= 40 4971 ub-terminal-id-length INTEGER ::= 24 4972 ub-unformatted-address-length INTEGER ::= 180 4973 ub-x121-address-length INTEGER ::= 16 4975 -- Note - upper bounds on TeletexString are measured in characters. 4976 -- A significantly greater number of octets will be required to hold 4977 -- such a value. As a minimum, 16 octets, or twice the specified upper 4978 -- bound, whichever is the larger, should be allowed. 4980 END 4981 B.2 Implicitly Tagged Module, 1993 Syntax 4983 PKIX1Implicit93 {iso(1) identified-organization(3) dod(6) internet(1) 4984 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-93(4)} 4986 DEFINITIONS IMPLICIT TAGS::= 4988 BEGIN 4990 --EXPORTS ALL -- 4992 IMPORTS 4993 id-pe, id-qt, id-kp, id-ad, id-qt-unotice, 4994 ORAddress, Name, RelativeDistinguishedName, 4995 CertificateSerialNumber, CertificateList, 4996 AlgorithmIdentifier, ub-name, DirectoryString, 4997 Attribute, EXTENSION 4998 FROM PKIX1Explicit93 {iso(1) identified-organization(3) 4999 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 5000 id-mod(0) id-pkix1-explicit-93(3)}; 5002 -- Key and policy information extensions -- 5004 authorityKeyIdentifier EXTENSION ::= { 5005 SYNTAX AuthorityKeyIdentifier 5006 IDENTIFIED BY id-ce-authorityKeyIdentifier } 5008 AuthorityKeyIdentifier ::= SEQUENCE { 5009 keyIdentifier [0] KeyIdentifier OPTIONAL, 5010 authorityCertIssuer [1] GeneralNames OPTIONAL, 5011 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 5012 ( WITH COMPONENTS {..., authorityCertIssuer PRESENT, 5013 authorityCertSerialNumber PRESENT} | 5014 WITH COMPONENTS {..., authorityCertIssuer ABSENT, 5015 authorityCertSerialNumber ABSENT} ) 5017 KeyIdentifier ::= OCTET STRING 5019 subjectKeyIdentifier EXTENSION ::= { 5020 SYNTAX SubjectKeyIdentifier 5021 IDENTIFIED BY id-ce-subjectKeyIdentifier } 5023 SubjectKeyIdentifier ::= KeyIdentifier 5025 keyUsage EXTENSION ::= { 5026 SYNTAX KeyUsage 5027 IDENTIFIED BY id-ce-keyUsage } 5029 KeyUsage ::= BIT STRING { 5030 digitalSignature (0), 5031 nonRepudiation (1), 5032 keyEncipherment (2), 5033 dataEncipherment (3), 5034 keyAgreement (4), 5035 keyCertSign (5), 5036 cRLSign (6) } 5038 extendedKeyUsage EXTENSION ::= { 5039 SYNTAX SEQUENCE SIZE (1..MAX) OF KeyPurposeId 5040 IDENTIFIED BY id-ce-extKeyUsage } 5042 KeyPurposeId ::= OBJECT IDENTIFIER 5044 -- PKIX-defined extended key purpose OIDs 5045 id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } 5046 id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } 5047 id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } 5048 id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } 5049 id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 } 5050 id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 } 5051 id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 } 5052 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 5054 privateKeyUsagePeriod EXTENSION ::= { 5055 SYNTAX PrivateKeyUsagePeriod 5056 IDENTIFIED BY { id-ce-privateKeyUsagePeriod } } 5058 PrivateKeyUsagePeriod ::= SEQUENCE { 5059 notBefore [0] GeneralizedTime OPTIONAL, 5060 notAfter [1] GeneralizedTime OPTIONAL } 5061 ( WITH COMPONENTS {..., notBefore PRESENT} | 5062 WITH COMPONENTS {..., notAfter PRESENT} ) 5064 certificatePolicies EXTENSION ::= { 5065 SYNTAX CertificatePoliciesSyntax 5066 IDENTIFIED BY id-ce-certificatePolicies } 5068 CertificatePoliciesSyntax ::= 5069 SEQUENCE SIZE (1..MAX) OF PolicyInformation 5071 PolicyInformation ::= SEQUENCE { 5072 policyIdentifier CertPolicyId, 5073 policyQualifiers SEQUENCE SIZE (1..MAX) OF 5074 PolicyQualifierInfo OPTIONAL } 5076 CertPolicyId ::= OBJECT IDENTIFIER 5077 PolicyQualifierInfo ::= SEQUENCE { 5078 policyQualifierId CERT-POLICY-QUALIFIER.&id 5079 ({SupportedPolicyQualifiers}), 5080 qualifier CERT-POLICY-QUALIFIER.&Qualifier 5081 ({SupportedPolicyQualifiers} 5082 {@policyQualifierId})OPTIONAL } 5084 SupportedPolicyQualifiers CERT-POLICY-QUALIFIER ::= { noticeToUser | 5085 pointerToCPS } 5087 CERT-POLICY-QUALIFIER ::= CLASS { 5088 &id OBJECT IDENTIFIER UNIQUE, 5089 &Qualifier OPTIONAL } 5090 WITH SYNTAX { 5091 POLICY-QUALIFIER-ID &id 5092 [QUALIFIER-TYPE &Qualifier] } 5094 policyMappings EXTENSION ::= { 5095 SYNTAX PolicyMappingsSyntax 5096 IDENTIFIED BY id-ce-policyMappings } 5098 PolicyMappingsSyntax ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 5099 issuerDomainPolicy CertPolicyId, 5100 subjectDomainPolicy CertPolicyId } 5102 -- Certificate subject and certificate issuer attributes extensions -- 5104 subjectAltName EXTENSION ::= { 5105 SYNTAX GeneralNames 5106 IDENTIFIED BY id-ce-subjectAltName } 5108 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 5110 GeneralName ::= CHOICE { 5111 otherName [0] INSTANCE OF OTHER-NAME, 5112 rfc822Name [1] IA5String, 5113 dNSName [2] IA5String, 5114 x400Address [3] ORAddress, 5115 directoryName [4] Name, 5116 ediPartyName [5] EDIPartyName, 5117 uniformResourceIdentifier [6] IA5String, 5118 iPAddress [7] OCTET STRING, 5119 registeredID [8] OBJECT IDENTIFIER } 5121 OTHER-NAME ::= TYPE-IDENTIFIER 5123 EDIPartyName ::= SEQUENCE { 5124 nameAssigner [0] DirectoryString {ub-name} OPTIONAL, 5125 partyName [1] DirectoryString {ub-name} } 5127 issuerAltName EXTENSION ::= { 5128 SYNTAX GeneralNames 5129 IDENTIFIED BY id-ce-issuerAltName } 5131 subjectDirectoryAttributes EXTENSION ::= { 5132 SYNTAX AttributesSyntax 5133 IDENTIFIED BY id-ce-subjectDirectoryAttributes } 5135 AttributesSyntax ::= SEQUENCE SIZE (1..MAX) OF Attribute 5137 -- Certification path constraints extensions -- 5139 basicConstraints EXTENSION ::= { 5140 SYNTAX BasicConstraintsSyntax 5141 IDENTIFIED BY id-ce-basicConstraints } 5143 BasicConstraintsSyntax ::= SEQUENCE { 5144 cA BOOLEAN DEFAULT FALSE, 5145 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 5147 nameConstraints EXTENSION ::= { 5148 SYNTAX NameConstraintsSyntax 5149 IDENTIFIED BY id-ce-nameConstraints } 5151 NameConstraintsSyntax ::= SEQUENCE { 5152 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 5153 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 5155 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 5157 GeneralSubtree ::= SEQUENCE { 5158 base GeneralName, 5159 minimum [0] BaseDistance DEFAULT 0, 5160 maximum [1] BaseDistance OPTIONAL } 5162 BaseDistance ::= INTEGER (0..MAX) 5164 policyConstraints EXTENSION ::= { 5165 SYNTAX PolicyConstraintsSyntax 5166 IDENTIFIED BY id-ce-policyConstraints } 5168 PolicyConstraintsSyntax ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 5169 requireExplicitPolicy [0] SkipCerts OPTIONAL, 5170 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 5172 SkipCerts ::= INTEGER (0..MAX) 5173 -- Basic CRL extensions -- 5175 cRLNumber EXTENSION ::= { 5176 SYNTAX CRLNumber 5177 IDENTIFIED BY id-ce-cRLNumber } 5179 CRLNumber ::= INTEGER (0..MAX) 5181 reasonCode EXTENSION ::= { 5182 SYNTAX CRLReason 5183 IDENTIFIED BY id-ce-reasonCode } 5185 CRLReason ::= ENUMERATED { 5186 unspecified (0), 5187 keyCompromise (1), 5188 cACompromise (2), 5189 affiliationChanged (3), 5190 superseded (4), 5191 cessationOfOperation (5), 5192 certificateHold (6), 5193 removeFromCRL (8) } 5195 instructionCode EXTENSION ::= { 5196 SYNTAX HoldInstruction 5197 IDENTIFIED BY id-ce-instructionCode } 5199 HoldInstruction ::= OBJECT IDENTIFIER 5201 -- holdinstructions described in this specification, from ANSI x9 5203 -- ANSI x9 arc holdinstruction arc 5204 holdInstruction OBJECT IDENTIFIER ::= { 5205 joint-iso-ccitt(2) member-body(2) us(840) x9cm(10040) 2} 5207 -- ANSI X9 holdinstructions referenced by this standard 5208 id-holdinstruction-none OBJECT IDENTIFIER ::= {holdInstruction 1} 5209 id-holdinstruction-callissuer OBJECT IDENTIFIER ::= {holdInstruction 2} 5210 id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3} 5212 invalidityDate EXTENSION ::= { 5213 SYNTAX GeneralizedTime 5214 IDENTIFIED BY id-ce-invalidityDate } 5216 -- CRL distribution points and delta-CRL extensions -- 5218 cRLDistributionPoints EXTENSION ::= { 5219 SYNTAX CRLDistPointsSyntax 5220 IDENTIFIED BY id-ce-cRLDistributionPoints } 5222 CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 5224 DistributionPoint ::= SEQUENCE { 5225 distributionPoint [0] DistributionPointName OPTIONAL, 5226 reasons [1] ReasonFlags OPTIONAL, 5227 cRLIssuer [2] GeneralNames OPTIONAL } 5229 DistributionPointName ::= CHOICE { 5230 fullName [0] GeneralNames, 5231 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 5233 ReasonFlags ::= BIT STRING { 5234 unused (0), 5235 keyCompromise (1), 5236 caCompromise (2), 5237 affiliationChanged (3), 5238 superseded (4), 5239 cessationOfOperation (5), 5240 certificateHold (6) } 5242 issuingDistributionPoint EXTENSION ::= { 5243 SYNTAX IssuingDistPointSyntax 5244 IDENTIFIED BY id-ce-issuingDistributionPoint } 5246 IssuingDistPointSyntax ::= SEQUENCE { 5247 distributionPoint [0] DistributionPointName OPTIONAL, 5248 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 5249 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 5250 onlySomeReasons [3] ReasonFlags OPTIONAL, 5251 indirectCRL [4] BOOLEAN DEFAULT FALSE } 5253 certificateIssuer EXTENSION ::= { 5254 SYNTAX GeneralNames 5255 IDENTIFIED BY id-ce-certificateIssuer } 5257 deltaCRLIndicator EXTENSION ::= { 5258 SYNTAX BaseCRLNumber 5259 IDENTIFIED BY id-ce-deltaCRLIndicator } 5261 BaseCRLNumber ::= CRLNumber 5263 -- Object identifier assignments for ISO certificate extensions -- 5264 id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 5266 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= {id-ce 9} 5267 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= {id-ce 14} 5268 id-ce-keyUsage OBJECT IDENTIFIER ::= {id-ce 15} 5269 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= {id-ce 16} 5270 id-ce-subjectAltName OBJECT IDENTIFIER ::= {id-ce 17} 5271 id-ce-issuerAltName OBJECT IDENTIFIER ::= {id-ce 18} 5272 id-ce-basicConstraints OBJECT IDENTIFIER ::= {id-ce 19} 5273 id-ce-cRLNumber OBJECT IDENTIFIER ::= {id-ce 20} 5274 id-ce-reasonCode OBJECT IDENTIFIER ::= {id-ce 21} 5275 id-ce-instructionCode OBJECT IDENTIFIER ::= {id-ce 23} 5276 id-ce-invalidityDate OBJECT IDENTIFIER ::= {id-ce 24} 5277 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= {id-ce 27} 5278 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= {id-ce 28} 5279 id-ce-certificateIssuer OBJECT IDENTIFIER ::= {id-ce 29} 5280 id-ce-nameConstraints OBJECT IDENTIFIER ::= {id-ce 30} 5281 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31} 5282 id-ce-certificatePolicies OBJECT IDENTIFIER ::= {id-ce 32} 5283 id-ce-policyMappings OBJECT IDENTIFIER ::= {id-ce 33} 5284 id-ce-policyConstraints OBJECT IDENTIFIER ::= {id-ce 36} 5285 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= {id-ce 35} 5286 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 5288 -- PKIX 1 extensions 5290 authorityInfoAccess EXTENSION ::= { 5291 SYNTAX AuthorityInfoAccessSyntax 5292 IDENTIFIED BY id-pe-authorityInfoAccess } 5294 AuthorityInfoAccessSyntax ::= 5295 SEQUENCE SIZE (1..MAX) OF AccessDescription 5297 AccessDescription ::= SEQUENCE { 5298 accessMethod OBJECT IDENTIFIER, 5299 accessLocation GeneralName } 5301 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 5303 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 5304 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 5306 -- PKIX policy qualifier definitions 5308 noticeToUser CERT-POLICY-QUALIFIER ::= { 5309 POLICY-QUALIFIER-ID id-qt-cps QUALIFIER-TYPE CPSuri} 5311 pointerToCPS CERT-POLICY-QUALIFIER ::= { 5312 POLICY-QUALIFIER-ID id-qt-unotice QUALIFIER-TYPE UserNotice} 5314 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 5315 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 5317 CPSuri ::= IA5String 5318 UserNotice ::= SEQUENCE { 5319 noticeRef NoticeReference OPTIONAL, 5320 explicitText DisplayText OPTIONAL} 5322 NoticeReference ::= SEQUENCE { 5323 organization DisplayText, 5324 noticeNumbers SEQUENCE OF INTEGER } 5326 DisplayText ::= CHOICE { 5327 visibleString VisibleString (SIZE (1..200)), 5328 bmpString BMPString (SIZE (1..200)), 5329 utf8String UTF8String (SIZE (1..200)) } 5331 END 5333 Appendix C. ASN.1 Notes 5335 The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 5336 constructs. A valid ASN.1 sequence will have zero or more entries. 5337 The SIZE (1..MAX) construct constrains the sequence to have at least 5338 one entry. MAX indicates the upper bound is unspecified. Implementa- 5339 tions are free to choose an upper bound that suits their environment. 5341 The construct "positiveInt ::= INTEGER (0..MAX)" defines positiveInt 5342 as a subtype of INTEGER containing integers greater than or equal to 5343 zero. The upper bound is unspecified. Implementations are free to 5344 select an upper bound that suits their environment. 5346 The character string type PrintableString supports a very basic Latin 5347 character set: the lower case letters 'a' through 'z', upper case 5348 letters 'A' through 'Z', the digits '0' through '9', eleven special 5349 characters ' " ( ) + , - . / : ? and space. 5351 The character string type TeletexString is a superset of Printable- 5352 String. TeletexString supports a fairly standard (ascii-like) Latin 5353 character set, Latin characters with non-spacing accents and Japanese 5354 characters. 5356 The character string type UniversalString supports any of the charac- 5357 ters allowed by ISO 10646-1. ISO 10646 is the Universal multiple- 5358 octet coded Character Set (UCS). ISO 10646-1 specifes the architec- 5359 ture and the "basic multilingual plane" - a large standard character 5360 set which includes all major world character standards. 5362 The character string type UTF8String will be introduced in the 1998 5363 version of ASN.1. UTF8String is a universal type and has been 5364 assigned tag number 12. The content of UTF8String was defined by RFC 5365 2044 and updated in RFC 2279, "UTF-8, a transformation Format of ISP 5366 10646." ISO is expected to formally add UTF8String to the list of 5367 choices for DirectoryString in 1998 as well. 5369 In anticipation of these changes, and in conformance with IETF Best 5370 Practices codified in RFC 2277, IETF Policy on Character Sets and 5371 Languages, this document includes UTF8String as a choice in Directo- 5372 ryString and the CPS qualifier extensions. 5374 Appendix D. Examples 5376 This section contains four examples: three certificates and a CRL. 5377 The first two certificates and the CRL comprise a minimal certifica- 5378 tion path. 5380 Section D.1 contains an annotated hex dump of a "self-signed" certi- 5381 ficate issued by a CA whose distinguished name is 5382 cn=us,o=gov,ou=nist. The certificate contains a DSA public key with 5383 parameters, and is signed by the corresponding DSA private key. 5385 Section D.2 contains an annotated hex dump of an end-entity certifi- 5386 cate. The end entity certificate contains a DSA public key, and is 5387 signed by the private key corresponding to the "self-signed" certifi- 5388 cate in section D.1. 5390 Section D.3 contains a dump of an end entity certificate which con- 5391 tains an RSA public key and is signed with RSA and MD5. This certi- 5392 ficate is not part of the minimal certification path. 5394 Section D.4 contains an annotated hex dump of a CRL. The CRL is 5395 issued by the CA whose distinguished name is cn=us,o=gov,ou=nist and 5396 the list of revoked certificates includes the end entity certificate 5397 presented in D.2. 5399 D.1 Certificate 5401 This section contains an annotated hex dump of a 699 byte version 3 5402 certificate. The certificate contains the following information: 5403 (a) the serial number is 17 (11 hex); 5404 (b) the certificate is signed with DSA and the SHA-1 hash algorithm; 5405 (c) the issuer's distinguished name is OU=nist; O=gov; C=US 5406 (d) and the subject's distinguished name is OU=nist; O=gov; C=US 5407 (e) the certificate was issued on June 30, 1997 and will expire on 5408 December 31, 1997; 5409 (f) the certificate contains a 1024 bit DSA public key with parame- 5410 ters; 5411 (g) the certificate contains a subject key identifier extension; and 5412 (h) the certificate is a CA certificate (as indicated through the 5413 basic constraints extension.) 5415 0000 30 82 02 b7 695: SEQUENCE 5416 0004 30 82 02 77 631: . SEQUENCE tbscertificate 5417 0008 a0 03 3: . . [0] 5418 0010 02 01 1: . . . INTEGER 2 5419 : 02 5420 0013 02 01 1: . . INTEGER 17 5421 : 11 5422 0016 30 09 9: . . SEQUENCE 5423 0018 06 07 7: . . . OID 1.2.840.10040.4.3: dsa-with-sha 5424 : 2a 86 48 ce 38 04 03 5425 0027 30 2a 42: . . SEQUENCE 5426 0029 31 0b 11: . . . SET 5427 0031 30 09 9: . . . . SEQUENCE 5428 0033 06 03 3: . . . . . OID 2.5.4.6: C 5429 : 55 04 06 5430 0038 13 02 2: . . . . . PrintableString 'US' 5431 : 55 53 5432 0042 31 0c 12: . . . SET 5433 0044 30 0a 10: . . . . SEQUENCE 5434 0046 06 03 3: . . . . . OID 2.5.4.10: O 5435 : 55 04 0a 5436 0051 13 03 3: . . . . . PrintableString 'gov' 5437 : 67 6f 76 5438 0056 31 0d 13: . . . SET 5439 0058 30 0b 11: . . . . SEQUENCE 5440 0060 06 03 3: . . . . . OID 2.5.4.11: OU 5441 : 55 04 0b 5442 0065 13 04 4: . . . . . PrintableString 'nist' 5443 : 6e 69 73 74 5444 0071 30 1e 30: . . SEQUENCE 5445 0073 17 0d 13: . . . UTCTime '970630000000Z' 5446 : 39 37 30 36 33 30 30 30 30 30 30 30 5a 5447 0088 17 0d 13: . . . UTCTime '971231000000Z' 5448 : 39 37 31 32 33 31 30 30 30 30 30 30 5a 5449 0103 30 2a 42: . . SEQUENCE 5450 0105 31 0b 11: . . . SET 5451 0107 30 09 9: . . . . SEQUENCE 5452 0109 06 03 3: . . . . . OID 2.5.4.6: C 5453 : 55 04 06 5454 0114 13 02 2: . . . . . PrintableString 'US' 5455 : 55 53 5456 0118 31 0c 12: . . . SET 5457 0120 30 0a 10: . . . . SEQUENCE 5458 0122 06 03 3: . . . . . OID 2.5.4.10: O 5459 : 55 04 0a 5460 0127 13 03 3: . . . . . PrintableString 'gov' 5461 : 67 6f 76 5462 0132 31 0d 13: . . . SET 5463 0134 30 0b 11: . . . . SEQUENCE 5464 0136 06 03 3: . . . . . OID 2.5.4.11: OU 5465 : 55 04 0b 5466 0141 13 04 4: . . . . . PrintableString 'nist' 5467 : 6e 69 73 74 5468 0147 30 82 01 b4 436: . . SEQUENCE 5469 0151 30 82 01 29 297: . . . SEQUENCE 5470 0155 06 07 7: . . . . OID 1.2.840.10040.4.1: dsa 5471 : 2a 86 48 ce 38 04 01 5472 0164 30 82 01 1c 284: . . . . SEQUENCE 5473 0168 02 81 80 128: . . . . . INTEGER 5474 : d4 38 02 c5 35 7b d5 0b a1 7e 5d 72 59 63 55 d3 5475 : 45 56 ea e2 25 1a 6b c5 a4 ab aa 0b d4 62 b4 d2 5476 : 21 b1 95 a2 c6 01 c9 c3 fa 01 6f 79 86 83 3d 03 5477 : 61 e1 f1 92 ac bc 03 4e 89 a3 c9 53 4a f7 e2 a6 5478 : 48 cf 42 1e 21 b1 5c 2b 3a 7f ba be 6b 5a f7 0a 5479 : 26 d8 8e 1b eb ec bf 1e 5a 3f 45 c0 bd 31 23 be 5480 : 69 71 a7 c2 90 fe a5 d6 80 b5 24 dc 44 9c eb 4d 5481 : f9 da f0 c8 e8 a2 4c 99 07 5c 8e 35 2b 7d 57 8d 5482 0299 02 14 20: . . . . . INTEGER 5483 : a7 83 9b f3 bd 2c 20 07 fc 4c e7 e8 9f f3 39 83 5484 : 51 0d dc dd 5485 0321 02 81 80 128: . . . . . INTEGER 5486 : 0e 3b 46 31 8a 0a 58 86 40 84 e3 a1 22 0d 88 ca 5487 : 90 88 57 64 9f 01 21 e0 15 05 94 24 82 e2 10 90 5488 : d9 e1 4e 10 5c e7 54 6b d4 0c 2b 1b 59 0a a0 b5 5489 : a1 7d b5 07 e3 65 7c ea 90 d8 8e 30 42 e4 85 bb 5490 : ac fa 4e 76 4b 78 0e df 6c e5 a6 e1 bd 59 77 7d 5491 : a6 97 59 c5 29 a7 b3 3f 95 3e 9d f1 59 2d f7 42 5492 : 87 62 3f f1 b8 6f c7 3d 4b b8 8d 74 c4 ca 44 90 5493 : cf 67 db de 14 60 97 4a d1 f7 6d 9e 09 94 c4 0d 5494 0452 03 81 84 132: . . . BIT STRING (0 unused bits) 5495 : 02 81 80 aa 98 ea 13 94 a2 db f1 5b 7f 98 2f 78 5496 : e7 d8 e3 b9 71 86 f6 80 2f 40 39 c3 da 3b 4b 13 5497 : 46 26 ee 0d 56 c5 a3 3a 39 b7 7d 33 c2 6b 5c 77 5498 : 92 f2 55 65 90 39 cd 1a 3c 86 e1 32 eb 25 bc 91 5499 : c4 ff 80 4f 36 61 bd cc e2 61 04 e0 7e 60 13 ca 5500 : c0 9c dd e0 ea 41 de 33 c1 f1 44 a9 bc 71 de cf 5501 : 59 d4 6e da 44 99 3c 21 64 e4 78 54 9d d0 7b ba 5502 : 4e f5 18 4d 5e 39 30 bf e0 d1 f6 f4 83 25 4f 14 5503 : aa 71 e1 5504 0587 a3 32 50: . . [3] 5505 0589 30 30 48: . . . SEQUENCE 5506 0591 30 0f 9: . . . . SEQUENCE 5507 0593 06 03 3: . . . . . OID 2.5.29.19: basicConstraints 5508 : 55 1d 13 5509 0598 01 01 1: . . . . . TRUE 5510 : ff 5511 0601 04 05 5: . . . . . OCTET STRING 5512 : 30 03 01 01 ff 5513 0608 30 1d 29: . SEQUENCE 5514 0610 06 03 3: . . . . . OID 2.5.29.14: subjectKeyIdentifier 5515 : 55 1d 0e 5516 0615 04 16 22: . . . . . OCTET STRING 5517 : 04 14 e7 26 c5 54 cd 5b a3 6f 35 68 95 aa d5 ff 5518 : 1c 21 e4 22 75 d6 5519 0639 30 09 9: . SEQUENCE 5520 0641 06 07 7: . . OID 1.2.840.10040.4.3: dsa-with-sha 5521 : 2a 86 48 ce 38 04 03 5522 0650 03 2f 47: . BIT STRING (0 unused bits) 5523 : 30 2c 02 14 a0 66 c1 76 33 99 13 51 8d 93 64 2f 5524 : ca 13 73 de 79 1a 7d 33 02 14 5d 90 f6 ce 92 4a 5525 : bf 29 11 24 80 28 a6 5a 8e 73 b6 76 02 68 5527 D.2 Certificate 5529 This section contains an annotated hex dump of a 730 byte version 3 5530 certificate. The certificate contains the following information: 5531 (a) the serial number is 18 (12 hex); 5532 (b) the certificate is signed with DSA and the SHA-1 hash algorithm; 5533 (c) the issuer's distinguished name is OU=nist; O=gov; C=US 5534 (d) and the subject's distinguished name is CN=Tim Polk; OU=nist; 5535 O=gov; C=US 5536 (e) the certificate was valid from July 30, 1997 through December 1, 5537 1997; 5538 (f) the certificate contains a 1024 bit DSA public key; 5539 (g) the certificate is an end entity certificate, as the basic con- 5540 straints extension is not present; 5541 (h) the certificate contains an authority key identifier extension; 5542 and 5543 (i) the certificate includes one alternative name - an RFC 822 5544 address. 5546 0000 30 82 02 d6 726: SEQUENCE 5547 0004 30 82 02 96 662: . SEQUENCE 5548 0008 a0 03 3: . . [0] 5549 0010 02 01 1: . . . INTEGER 2 5550 : 02 5551 0013 02 01 1: . . INTEGER 18 5552 : 12 5553 0016 30 09 9: . . SEQUENCE 5554 0018 06 07 7: . . . OID 1.2.840.10040.4.3: dsa-with-sha 5555 : 2a 86 48 ce 38 04 03 5556 0027 30 2a 42: . . SEQUENCE 5557 0029 31 0b 11: . . . SET 5558 0031 30 09 9: . . . . SEQUENCE 5559 0033 06 03 3: . . . . . OID 2.5.4.6: C 5560 : 55 04 06 5561 0038 13 02 2: . . . . . PrintableString 'US' 5562 : 55 53 5563 0042 31 0c 12: . . . SET 5564 0044 30 0a 10: . . . . SEQUENCE 5565 0046 06 03 3: . . . . . OID 2.5.4.10: O 5566 : 55 04 0a 5567 0051 13 03 3: . . . . . PrintableString 'gov' 5568 : 67 6f 76 5569 0056 31 0d 13: . . . SET 5570 0058 30 0b 11: . . . . SEQUENCE 5571 0060 06 03 3: . . . . . OID 2.5.4.11: OU 5572 : 55 04 0b 5573 0065 13 04 4: . . . . . PrintableString 'nist' 5574 : 6e 69 73 74 5575 0071 30 1e 30: . . SEQUENCE 5576 0073 17 0d 13: . . . UTCTime '970730000000Z' 5577 : 39 37 30 37 33 30 30 30 30 30 30 30 5a 5578 0088 17 0d 13: . . . UTCTime '971201000000Z' 5579 : 39 37 31 32 30 31 30 30 30 30 30 30 5a 5580 0103 30 3d 61: . . SEQUENCE 5581 0105 31 0b 11: . . . SET 5582 0107 30 09 9: . . . . SEQUENCE 5583 0109 06 03 3: . . . . . OID 2.5.4.6: C 5584 : 55 04 06 5585 0114 13 02 2: . . . . . PrintableString 'US' 5586 : 55 53 5587 0118 31 0c 12: . . . SET 5588 0120 30 0a 10: . . . . SEQUENCE 5589 0122 06 03 3: . . . . . OID 2.5.4.10: O 5590 : 55 04 0a 5591 0127 13 03 3: . . . . . PrintableString 'gov' 5592 : 67 6f 76 5593 0132 31 0d 13: . . . SET 5594 0134 30 0b 11: . . . . SEQUENCE 5595 0136 06 03 3: . . . . . OID 2.5.4.11: OU 5596 : 55 04 0b 5597 0141 13 04 4: . . . . . PrintableString 'nist' 5598 : 6e 69 73 74 5599 0147 31 11 17: . . . SET 5600 0149 30 0f 15: . . . . SEQUENCE 5601 0151 06 03 3: . . . . . OID 2.5.4.3: CN 5602 : 55 04 03 5604 0156 13 08 8: . . . . . PrintableString 'Tim Polk' 5605 : 54 69 6d 20 50 6f 6c 6b 5606 0166 30 82 01 b4 436: . . SEQUENCE 5607 0170 30 82 01 29 297: . . . SEQUENCE 5608 0174 06 07 7: . . . . OID 1.2.840.10040.4.1: dsa 5609 : 2a 86 48 ce 38 04 01 5610 0183 30 82 01 1c 284: . . . . SEQUENCE 5611 0187 02 81 80 128: . . . . . INTEGER 5612 : d4 38 02 c5 35 7b d5 0b a1 7e 5d 72 59 63 55 d3 5613 : 45 56 ea e2 25 1a 6b c5 a4 ab aa 0b d4 62 b4 d2 5614 : 21 b1 95 a2 c6 01 c9 c3 fa 01 6f 79 86 83 3d 03 5615 : 61 e1 f1 92 ac bc 03 4e 89 a3 c9 53 4a f7 e2 a6 5616 : 48 cf 42 1e 21 b1 5c 2b 3a 7f ba be 6b 5a f7 0a 5617 : 26 d8 8e 1b eb ec bf 1e 5a 3f 45 c0 bd 31 23 be 5618 : 69 71 a7 c2 90 fe a5 d6 80 b5 24 dc 44 9c eb 4d 5619 : f9 da f0 c8 e8 a2 4c 99 07 5c 8e 35 2b 7d 57 8d 5620 0318 02 14 20: . . . . . INTEGER 5621 : a7 83 9b f3 bd 2c 20 07 fc 4c e7 e8 9f f3 39 83 5622 : 51 0d dc dd 5623 0340 02 81 80 128: . . . . . INTEGER 5624 : 0e 3b 46 31 8a 0a 58 86 40 84 e3 a1 22 0d 88 ca 5625 : 90 88 57 64 9f 01 21 e0 15 05 94 24 82 e2 10 90 5626 : d9 e1 4e 10 5c e7 54 6b d4 0c 2b 1b 59 0a a0 b5 5627 : a1 7d b5 07 e3 65 7c ea 90 d8 8e 30 42 e4 85 bb 5628 : ac fa 4e 76 4b 78 0e df 6c e5 a6 e1 bd 59 77 7d 5629 : a6 97 59 c5 29 a7 b3 3f 95 3e 9d f1 59 2d f7 42 5630 : 87 62 3f f1 b8 6f c7 3d 4b b8 8d 74 c4 ca 44 90 5631 : cf 67 db de 14 60 97 4a d1 f7 6d 9e 09 94 c4 0d 5632 0471 03 81 84 132: . . . BIT STRING (0 unused bits) 5633 : 02 81 80 a8 63 b1 60 70 94 7e 0b 86 08 93 0c 0d 5634 : 08 12 4a 58 a9 af 9a 09 38 54 3b 46 82 fb 85 0d 5635 : 18 8b 2a 77 f7 58 e8 f0 1d d2 18 df fe e7 e9 35 5636 : c8 a6 1a db 8d 3d 3d f8 73 14 a9 0b 39 c7 95 f6 5637 : 52 7d 2d 13 8c ae 03 29 3c 4e 8c b0 26 18 b6 d8 5638 : 11 1f d4 12 0c 13 ce 3f f1 c7 05 4e df e1 fc 44 5639 : fd 25 34 19 4a 81 0d dd 98 42 ac d3 b6 91 0c 7f 5640 : 16 72 a3 a0 8a d7 01 7f fb 9c 93 e8 99 92 c8 42 5641 : 47 c6 43 5642 0606 a3 3e 62: . . [3] 5643 0608 30 3c 60: . . . SEQUENCE 5644 0610 30 19 25: . . . . SEQUENCE 5645 0612 06 03 3: . . . . . OID 2.5.29.17: subjectAltName 5646 : 55 1d 11 5647 0617 04 12 18: . . . . . OCTET STRING 5648 : 30 10 81 0e 77 70 6f 6c 6b 40 6e 69 73 74 2e 67 5649 : 6f 76 5650 0637 30 1f 31: . . . . SEQUENCE 5651 0639 06 03 3: . . . . . OID 2.5.29.35: subjectAltName 5652 : 55 1d 23 5653 0644 04 18 24: . . . . . OCTET STRING 5654 : 30 16 80 14 e7 26 c5 54 cd 5b a3 6f 35 68 95 aa 5655 : d5 ff 1c 21 e4 22 75 d6 5656 0670 30 09 9: . SEQUENCE 5657 0672 06 07 7: . . OID 1.2.840.10040.4.3: dsa-with-sha 5658 : 2a 86 48 ce 38 04 03 5659 0681 03 2f 47: . BIT STRING (0 unused bits) 5660 : 30 2c 02 14 3c 02 e0 ab d9 5d 05 77 75 15 71 58 5661 : 92 29 48 c4 1c 54 df fc 02 14 5b da 53 98 7f c5 5662 : 33 df c6 09 b2 7a e3 6f 97 70 1e 14 ed 94 5664 D.3 End-Entity Certificate Using RSA 5666 This section contains an annotated hex dump of a 675 byte version 3 5667 certificate. The certificate contains the following information: 5668 (a) the serial number is 256; 5669 (b) the certificate is signed with RSA and the MD2 hash algorithm; 5670 (c) the issuer's distinguished name is OU=Dept. Arquitectura de Com- 5671 putadors; O=Universitat Politecnica de Catalunya; C=ES 5672 (d) and the subject's distinguished name is CN=Francisco Jordan; 5673 OU=Dept. Arquitectura de Computadors; O=Universitat Politecnica de 5674 Catalunya; C=ES 5675 (e) the certificate was issued on May 21, 1996 and expired on May 21, 5676 1997; 5677 (f) the certificate contains a 768 bit RSA public key; 5678 (g) the certificate is an end entity certificate (not a CA certifi- 5679 cate); 5680 (h) the certificate includes an alternative subject name and an 5681 alternative issuer name - bothe are URLs; 5682 (i) the certificate include an authority key identifier and certifi- 5683 cate policies extensions; and 5684 (j) the certificate includes a critical key usage extension specify- 5685 ing the public is intended for generation of digital signatures. 5687 0000 30 80 : SEQUENCE (size undefined) 5688 0002 30 82 02 40 576: . SEQUENCE 5689 0006 a0 03 3: . . [0] 5690 0008 02 01 1: . . . INTEGER 2 5691 : 02 5692 0011 02 02 2: . . INTEGER 256 5693 : 01 00 5694 0015 30 0d 13: . . SEQUENCE 5695 0017 06 09 9: . . . OID 1.2.840.113549.1.1.2: 5696 MD2WithRSAEncryption 5697 : 2a 86 48 86 f7 0d 01 01 02 5698 0028 05 00 0: . . . NULL 5699 0030 30 68 88: . . SEQUENCE 5700 0032 31 0b 11: . . . SET 5701 0034 30 09 9: . . . . SEQUENCE 5702 0036 06 03 3: . . . . . OID 2.5.4.6: C 5703 : 55 04 06 5704 0041 13 02 2: . . . . . PrintableString 'ES' 5705 : 45 53 5706 0045 31 2d 45: . . . SET 5707 0047 30 2b 43: . . . . SEQUENCE 5708 0049 06 03 3: . . . . . OID 2.5.4.10: O 5709 : 55 04 0a 5710 0054 13 24 36: . . . . . PrintableString 5711 'Universitat Politecnica de Catalunya' 5712 : 55 6e 69 76 65 72 73 69 74 61 74 20 50 6f 6c 69 5713 : 74 65 63 6e 69 63 61 20 64 65 20 43 61 74 61 6c 5714 : 75 6e 79 61 5715 0092 31 2a 42: . . . SET 5716 0094 30 28 40: . . . . SEQUENCE 5717 0096 06 03 3: . . . . . OID 2.5.4.11: OU 5718 : 55 04 0b 5719 0101 13 21 33: . . . . . PrintableString 5720 'OU=Dept. Arquitectura de Computadors' 5721 : 44 65 70 74 2e 20 41 72 71 75 69 74 65 63 74 75 5722 : 72 61 20 64 65 20 43 6f 6d 70 75 74 61 64 6f 72 5723 : 73 5724 0136 30 1e 30: . . SEQUENCE 5725 0138 17 0d 13: . . . UTCTime '960521095826Z' 5726 : 39 36 30 37 32 32 31 37 33 38 30 32 5a 5727 0153 17 0d 13: . . . UTCTime '979521095826Z' 5728 : 39 37 30 37 32 32 31 37 33 38 30 32 5a 5729 0168 30 81 83 112: . . SEQUENCE 5730 0171 31 0b 11: . . . SET 5731 0173 30 09 9: . . . . SEQUENCE 5732 0175 06 03 3: . . . . . OID 2.5.4.6: C 5733 : 55 04 06 5734 0180 13 02 2: . . . . . PrintableString 'ES' 5735 : 45 53 5736 0184 31 2d 12: . . . SET 5737 0186 30 2b 16: . . . . SEQUENCE 5738 0188 06 03 3: . . . . . OID 2.5.4.10: O 5739 : 55 04 0a 5740 0193 13 24 36: . . . . . PrintableString 5741 'Universitat Politecnica de Catalunya' 5742 : 55 6e 69 76 65 72 73 69 74 61 74 20 50 6f 6c 69 5743 : 74 65 63 6e 69 63 61 20 64 65 20 43 61 74 61 6c 5744 : 75 6e 79 61 5745 0231 31 2a 42: . . . SET 5746 0233 30 28 40: . . . . SEQUENCE 5747 0235 06 03 3: . . . . . OID 2.5.4.11: OU 5748 : 55 04 0b 5749 0240 13 21 33: . . . . . PrintableString 5750 'Dept. Arquitectura de Computadors' 5751 : 44 65 70 74 2e 20 41 72 71 75 69 74 65 63 74 75 5752 : 72 61 20 64 65 20 43 6f 6d 70 75 74 61 64 6f 72 5753 : 73 5754 0275 31 19 22: . . . SET 5755 0277 30 17 20: . . . . SEQUENCE 5756 0279 06 03 3: . . . . . OID 2.5.4.3: CN 5757 : 55 04 03 5758 0284 13 10 16: . . . . . PrintableString 'Francisco Jordan' 5759 : 46 72 61 6e 63 69 73 63 6f 20 4a 6f 72 64 61 6e 5760 0302 30 7c 2: . . SEQUENCE 5761 0304 30 0d 13: . . . SEQUENCE 5762 0306 06 09 9: . . . . OID 1.2.840.113549.1.1.1: RSAEncryption 5763 : 2a 86 48 86 f7 0d 01 01 01 5764 0317 05 00 0: . . . . NULL 5765 0319 03 6b 107: . . . BIT STRING 5766 : 00 (0 unused bits) 5767 : 30 68 02 61 00 be aa 8b 77 54 a3 af ca 77 9f 2f 5768 : b0 cf 43 88 ff a6 6d 79 55 5b 61 8c 68 ec 48 1e 5769 : 8a 86 38 a4 fe 19 b8 62 17 1d 9d 0f 47 2c ff 63 5770 : 8f 29 91 04 d1 52 bc 7f 67 b6 b2 8f 74 55 c1 33 5771 : 21 6c 8f ab 01 95 24 c8 b2 73 93 9d 22 61 50 a9 5772 : 35 fb 9d 57 50 32 ef 56 52 50 93 ab b1 88 94 78 5773 : 56 15 c6 1c 8b 02 03 01 00 01 5774 0428 a3 81 97 151: . . [3] 5775 0431 30 3c 60: . . . SEQUENCE 5776 0433 30 1f 31: . . . . SEQUENCE 5777 0435 06 03 3: . . . . . OID 2.5.29.35: authorityKeyIdentifier 5778 : 55 1d 23 5779 0440 04 14 22: . . . . . OCTET STRING 5780 : 30 12 80 10 0e 6b 3a bf 04 ea 04 c3 0e 6b 3a bf 5781 : 04 ea 04 c3 5782 0464 30 19 25: . . . . SEQUENCE 5783 0466 06 03 3: . . . . . OID 2.5.29.15: keyUsage 5784 : 55 1d 0f 5785 0471 01 01 1: . . . . . TRUE 5786 0474 04 04 4: . . . . . OCTET STRING 5787 : 03 02 07 80 5788 0480 30 19 25: . . . . SEQUENCE 5789 0482 06 03 3: . . . . . OID 2.5.29.32: certificatePolicies 5790 : 55 1d 20 5791 0487 04 21 33: . . . . . OCTET STRING 5792 : 30 1f 30 1d 06 04 2a 84 80 00 30 15 30 07 06 05 5793 : 2a 84 80 00 01 30 0a 06 05 2a 84 80 00 02 02 01 5794 : 0a 5795 0522 30 1c 28: . . . . SEQUENCE 5796 0524 06 03 3: . . . . . OID 2.5.29.17: subjectAltName 5797 : 55 1d 11 5798 0529 04 15 21: . . . . . OCTET STRING 5799 : 30 13 86 11 68 74 74 70 3a 2f 2f 61 63 2e 75 70 5800 : 63 2e 65 73 2f 5801 0552 30 19 25: . . . . SEQUENCE 5802 0554 06 03 3: . . . . . OID 2.5.29.18: issuerAltName 5803 : 55 1d 12 5804 0559 04 12 18: . . . . . OCTET STRING 5805 : 30 14 86 12 68 74 74 70 3a 2f 2f 77 77 77 2e 75 5806 : 70 63 2e 65 5807 0579 30 80 : . SEQUENCE (indefinite length) 5808 0581 06 07 7: . . OID 5809 0583 05 00 0: . . NULL 5810 0585 00 00 0: . . end of contents marker 5811 0587 03 81 81 47: . BIT STRING 5812 : 00 (0 unused bits) 5813 : 5c 01 bd b5 41 88 87 7a 0e d3 0e 6b 3a bf 04 ea 5814 : 04 cb 5f 61 72 3c a3 bd 78 f5 66 17 fe 37 3a ab 5815 : eb 67 bf b7 da a8 38 f6 33 15 71 75 2f b9 8c 91 5816 : a0 e4 87 ba 4b 43 a0 22 8f d3 a9 86 43 89 e6 50 5817 : 5c 01 bd b5 41 88 87 7a 0e d3 0e 6b 3a bf 04 ea 5818 : 04 cb 5f 61 72 3c a3 bd 78 f5 66 17 fe 37 3a ab 5819 : eb 67 bf b7 da a8 38 f6 33 15 71 75 2f b9 8c 91 5820 : a0 e4 87 ba 4b 43 a0 22 8f d3 a9 86 43 89 e6 50 5821 0637 00 00 0: . . end of contents marker 5823 D.4 Certificate Revocation List 5825 This section contains an annotated hex dump of a version 2 CRL with 5826 one extension (cRLNumber). The CRL was issued by OU=nist;O=gov;C=us 5827 on July 7, 1996; the next scheduled issuance was August 7, 1996. The 5828 CRL includes one revoked certificates: serial number 18 (12 hex). 5829 The CRL itself is number 18, and it was signed with DSA and SHA-1. 5831 0000 30 81 ba 186: SEQUENCE 5832 0003 30 7c 124: . SEQUENCE 5833 0005 02 01 1: . . INTEGER 1 5834 : 01 5835 0008 30 09 9: . . SEQUENCE 5836 0010 06 07 7: . . . OID 1.2.840.10040.4.3: dsa-with-sha 5837 : 2a 86 48 ce 38 04 03 5838 0019 30 2a 42: . . SEQUENCE 5839 0021 31 0b 11: . . . SET 5840 0023 30 09 9: . . . . SEQUENCE 5841 0025 06 03 3: . . . . . OID 2.5.4.6: C 5842 : 55 04 06 5843 0030 13 02 2: . . . . . PrintableString 'US' 5844 : 55 53 5845 0034 31 0c 12: . . . SET 5846 0036 30 0a 10: . . . . SEQUENCE 5847 0038 06 03 3: . . . . . OID 2.5.4.10: O 5848 : 55 04 0a 5849 0043 13 03 3: . . . . . PrintableString 'gov' 5850 : 67 6f 76 5851 0048 31 0d 13: . . . SET 5852 0050 30 0b 11: . . . . SEQUENCE 5853 0052 06 03 3: . . . . . OID 2.5.4.11: OU 5854 : 55 04 0b 5855 0057 13 04 4: . . . . . PrintableString 'nist' 5856 : 6e 69 73 74 5857 0063 17 0d 13: . . UTCTime '970801000000Z' 5858 : 39 37 30 38 30 31 30 30 30 30 30 30 5a 5859 0078 17 0d 13: . . UTCTime '970808000000Z' 5860 : 39 37 30 38 30 38 30 30 30 30 30 30 5a 5861 0093 30 22 34: . . SEQUENCE 5862 0095 30 20 32: . . . SEQUENCE 5863 0097 02 01 1: . . . . INTEGER 18 5864 : 12 5865 0100 17 0d 13: . . . . UTCTime '970731000000Z' 5866 : 39 37 30 37 33 31 30 30 30 30 30 30 5a 5867 0115 30 0c 12: . . . . SEQUENCE 5868 0117 30 0a 10: . . . . . SEQUENCE 5869 0119 06 03 3: . . . . . . OID 2.5.29.21: reasonCode 5870 : 55 1d 15 5871 0124 04 03 3: . . . . . . OCTET STRING 5872 : 0a 01 01 5873 0129 30 09 9: . SEQUENCE 5874 0131 06 07 7: . . OID 1.2.840.10040.4.3: dsa-with-sha 5875 : 2a 86 48 ce 38 04 03 5876 0140 03 2f 47: . BIT STRING (0 unused bits) 5877 : 30 2c 02 14 9e d8 6b c1 7d c2 c4 02 f5 17 84 f9 5878 : 9f 46 7a ca cf b7 05 8a 02 14 9e 43 39 85 dc ea 5879 : 14 13 72 93 54 5d 44 44 e5 05 fe 73 9a b2 5881 Appendix E. Author Addresses: 5883 Russell Housley 5884 SPYRUS 5885 381 Elden Street 5886 Suite 1120 5887 Herndon, VA 20170 5888 USA 5889 housley@spyrus.com 5890 Warwick Ford 5891 VeriSign, Inc. 5892 One Alewife Center 5893 Cambridge, MA 02140 5894 USA 5895 wford@verisign.com 5897 Tim Polk 5898 NIST 5899 Building 820, Room 426 5900 Gaithersburg, MD 20899 5901 USA 5902 wpolk@nist.gov 5904 David Solo 5905 Citicorp 5906 666 Fifth Ave, 3rd Floor 5907 New York, NY 10103 5908 USA 5909 david.solo@citicorp.com 5911 Appendix F. Full Copyright Statement 5913 Copyright (C) The Internet Society (date). All Rights Reserved. 5915 This document and translations of it may be copied and furnished to 5916 others, and derivative works that comment on or otherwise explain it 5917 or assist in its implementation may be prepared, copied, published 5918 and distributed, in whole or in part, without restriction of any 5919 kind, provided that the above copyright notice and this paragraph are 5920 included on all such copies and derivative works. In addition, the 5921 ASN.1 modules presented in Appendices A and B may be used in whole or 5922 in part without inclusion of the copyright notice. However, this 5923 document itself may not be modified in any way, such as by removing 5924 the copyright notice or references to the Internet Society or other 5925 Internet organizations, except as needed for the purpose of develop- 5926 ing Internet standards in which case the procedures for copyrights 5927 defined in the Internet Standards process shall be followed, or as 5928 required to translate it into languages other than English. 5930 The limited permissions granted above are perpetual and will not be 5931 revoked by the Internet Society or its successors or assigns. This 5932 document and the information contained herein is provided on an "AS 5933 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 5934 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 5935 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 5936 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 5937 OR FITNESS FOR A PARTICULAR PURPOSE.