idnits 2.17.00 (12 Aug 2021) /tmp/idnits37712/draft-ietf-pkix-new-part1-00.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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 142 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 143 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 55 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The first octets (the first characters of the first line) of this draft are 'PK', which can make Internet Explorer erroneously think that it is a zip file. It is recommended that you change this, for instance by inserting a blank line before the line starting with 'PK'. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 613 has weird spacing: '...issuing a cer...' == Line 623 has weird spacing: '...: This is th...' == Line 3330 has weird spacing: '...y usage exten...' -- 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 (October 22, 1999) is 8246 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 6352 -- Looks like a reference, but probably isn't: '1' on line 5908 -- Looks like a reference, but probably isn't: '2' on line 5909 -- Looks like a reference, but probably isn't: '3' on line 6438 == Missing Reference: 'ISO 8859-1' is mentioned on line 908, but not defined -- Looks like a reference, but probably isn't: '4' on line 5911 -- Looks like a reference, but probably isn't: '5' on line 5776 -- Looks like a reference, but probably isn't: '6' on line 5777 -- Looks like a reference, but probably isn't: '7' on line 5778 -- Looks like a reference, but probably isn't: '8' on line 5779 == Missing Reference: 'RFC1738' is mentioned on line 2307, but not defined ** Obsolete undefined reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) == Missing Reference: 'RFC1778' is mentioned on line 2307, but not defined ** Obsolete undefined reference: RFC 1778 (Obsoleted by RFC 3494) == Missing Reference: 'DB94' is mentioned on line 3388, but not defined == Missing Reference: 'UNIVERSAL 28' is mentioned on line 3947, but not defined == Missing Reference: 'UNIVERSAL 30' is mentioned on line 3950, but not defined == Missing Reference: 'UNIVERSAL 12' is mentioned on line 3954, but not defined == Missing Reference: 'APPLICATION 1' is mentioned on line 5327, but not defined == Missing Reference: 'APPLICATION 2' is mentioned on line 5333, but not defined == Unused Reference: 'FIPS 180-1' is defined on line 3682, but no explicit reference was found in the text == Unused Reference: 'RFC 1778' is defined on line 3722, but no explicit reference was found in the text == Unused Reference: 'RFC 1883' is defined on line 3726, but no explicit reference was found in the text == Unused Reference: 'RFC 2119' is defined on line 3729, but no explicit reference was found in the text == Unused Reference: 'RFC 2277' is defined on line 3736, but no explicit reference was found in the text == Unused Reference: 'RFC 2279' is defined on line 3739, 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 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2313 (Obsoleted by RFC 2437) Summary: 20 errors (**), 0 flaws (~~), 25 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PKIX Working Group R. Housley (SPYRUS) 2 Internet Draft W. Ford (VeriSign) 3 W. Polk (NIST) 4 D. Solo (Citicorp) 5 expires in six months October 22, 1999 7 Internet X.509 Public Key Infrastructure 9 Certificate and CRL Profile 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 To view the entire list of current Internet-Drafts, please check the 33 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 34 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 35 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 36 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 38 Copyright (C) The Internet Society (1998). All Rights Reserved. 40 Abstract 42 This is the first draft of a specification based upon RFC 2459. When 43 complete, this specification will obsolete RFC 2459. This 44 specification includes numerous edits and clarifications. The most 45 notable departures from RFC 2459 are found in Section 6, Path 46 Validation. In RFC 2459, the reader was expected to augment the path 47 validation algorithm, which concentrated upon policy processing, with 48 information embedded in earlier sections. For example, parameter 49 inheritance is discussed in Section 7, Algorithm Support, and can 50 certainly affect the validity of a certification path. However, 51 parameter inheritance was omitted from the path validation algorithm 52 in RFC 2459. In this draft, the path validation algorithm has a 53 comprehensive and extremely detailed description. Details such as 54 parameter inheritance are covered thoroughly. In addition, this 55 draft anticipates certain corrections proposed in the X.509 standard 56 for the policy processing aspects of path validation. 58 A new section 6.3, CRL validation, has been added as well. This 59 section provides a supplement to the path validation algorithm that 60 determines if a particular CRL may be used to verify the status of a 61 particular certificate. (The basic path validation algorithm is, by 62 design, independent of the type and format of status information.) 64 This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use 65 in the Internet. An overview of the approach and model are provided 66 as an introduction. The X.509 v3 certificate format is described in 67 detail, with additional information regarding the format and 68 semantics of Internet name forms (e.g., IP addresses). Standard 69 certificate extensions are described and one new Internet-specific 70 extension is defined. A required set of certificate extensions is 71 specified. The X.509 v2 CRL format is described and a required 72 extension set is defined as well. An algorithm for X.509 certificate 73 path validation is described. Supplemental information is provided 74 describing the format of public keys and digital signatures in X.509 75 certificates for common Internet public key encryption algorithms 76 (i.e., RSA, DSA, and Diffie-Hellman). ASN.1 modules and examples are 77 provided in the appendices. 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in RFC 2119. 83 Please send comments on this document to the ietf-pkix@imc.org mail 84 list. 86 Table of Contents 88 1 Introduction ................................................ 6 89 2 Requirements and Assumptions ................................ 7 90 2.1 Communication and Topology ................................ 7 91 2.2 Acceptability Criteria .................................... 8 92 2.3 User Expectations ......................................... 8 93 2.4 Administrator Expectations ................................ 8 94 3 Overview of Approach ........................................ 8 95 3.1 X.509 Version 3 Certificate ............................... 10 96 3.2 Certification Paths and Trust ............................. 11 97 3.3 Revocation ................................................ 13 98 3.4 Operational Protocols ..................................... 14 99 3.5 Management Protocols ...................................... 14 100 4 Certificate and Certificate Extensions Profile .............. 15 101 4.1 Basic Certificate Fields .................................. 16 102 4.1.1 Certificate Fields ...................................... 17 103 4.1.1.1 tbsCertificate ........................................ 17 104 4.1.1.2 signatureAlgorithm .................................... 17 105 4.1.1.3 signatureValue ........................................ 18 106 4.1.2 TBSCertificate .......................................... 18 107 4.1.2.1 Version ............................................... 18 108 4.1.2.2 Serial number ......................................... 18 109 4.1.2.3 Signature ............................................. 19 110 4.1.2.4 Issuer ................................................ 19 111 4.1.2.5 Validity .............................................. 22 112 4.1.2.5.1 UTCTime ............................................. 23 113 4.1.2.5.2 GeneralizedTime ..................................... 23 114 4.1.2.6 Subject ............................................... 23 115 4.1.2.7 Subject Public Key Info ............................... 24 116 4.1.2.8 Unique Identifiers .................................... 24 117 4.1.2.9 Extensions ............................................. 25 118 4.2 Certificate Extensions .................................... 25 119 4.2.1 Standard Extensions ..................................... 26 120 4.2.1.1 Authority Key Identifier .............................. 26 121 4.2.1.2 Subject Key Identifier ................................ 27 122 4.2.1.3 Key Usage ............................................. 28 123 4.2.1.4 Private Key Usage Period .............................. 30 124 4.2.1.5 Certificate Policies .................................. 30 125 4.2.1.6 Policy Mappings ....................................... 32 126 4.2.1.7 Subject Alternative Name .............................. 33 127 4.2.1.8 Issuer Alternative Name ............................... 35 128 4.2.1.9 Subject Directory Attributes .......................... 36 129 4.2.1.10 Basic Constraints .................................... 36 130 4.2.1.11 Name Constraints ..................................... 36 131 4.2.1.12 Policy Constraints ................................... 39 132 4.2.1.13 Extended key usage field ............................. 39 133 4.2.1.14 CRL Distribution Points .............................. 41 134 4.2.2 Internet Certificate Extensions ......................... 42 135 4.2.2.1 Authority Information Access .......................... 42 136 5 CRL and CRL Extensions Profile .............................. 43 137 5.1 CRL Fields ................................................ 44 138 5.1.1 CertificateList Fields .................................. 45 139 5.1.1.1 tbsCertList ........................................... 45 140 5.1.1.2 signatureAlgorithm .................................... 45 141 5.1.1.3 signatureValue ........................................ 45 142 5.1.2 Certificate List "To Be Signed" ......................... 45 143 5.1.2.1 Version ............................................... 46 144 5.1.2.2 Signature ............................................. 46 145 5.1.2.3 Issuer Name ........................................... 46 146 5.1.2.4 This Update ........................................... 46 147 5.1.2.5 Next Update ........................................... 46 148 5.1.2.6 Revoked Certificates .................................. 47 149 5.1.2.7 Extensions ............................................ 47 150 5.2 CRL Extensions ............................................ 47 151 5.2.1 Authority Key Identifier ................................ 48 152 5.2.2 Issuer Alternative Name ................................. 48 153 5.2.3 CRL Number .............................................. 48 154 5.2.4 Delta CRL Indicator ..................................... 49 155 5.2.5 Issuing Distribution Point .............................. 49 156 5.3 CRL Entry Extensions ...................................... 50 157 5.3.1 Reason Code ............................................. 51 158 5.3.2 Hold Instruction Code ................................... 51 159 5.3.3 Invalidity Date ......................................... 52 160 5.3.4 Certificate Issuer ...................................... 52 161 6 Certificate Path Validation ................................. 52 162 6.1 Basic Path Validation ..................................... 53 163 6.1.1 Inputs ................................................... 55 164 6.1.2 Initialization ........................................... 56 165 6.1.3 Basic Certificate Processing ............................. 59 166 6.1.4 Preparation for Certificate i+1 .......................... 64 167 6.1.5 Wrap-up procedure ........................................ 67 168 6.1.6 Outputs .................................................. 68 169 6.2 Extending Path Validation ................................. 68 170 6.3 CRL Validation ............................................ 69 171 6.3.1 Revocation Inputs ....................................... 69 172 6.3.2 Initialization and Revocation State Variables ........... 69 173 6.3.3 Basic Certificate Processing ............................ 70 174 6.3.4 Preparation for Next Certificate ......................... 72 175 7 Algorithm Support ........................................... 72 176 7.1 One-way Hash Functions .................................... 73 177 7.1.1 MD2 One-way Hash Function ............................... 73 178 7.1.2 MD5 One-way Hash Function ............................... 73 179 7.1.3 SHA-1 One-way Hash Function ............................. 74 180 7.2 Signature Algorithms ...................................... 74 181 7.2.1 RSA Signature Algorithm ................................. 74 182 7.2.2 DSA Signature Algorithm ................................. 75 183 7.3 Subject Public Key Algorithms ............................. 76 184 7.3.1 RSA Keys ................................................ 76 185 7.3.2 Diffie-Hellman Key Exchange Key ......................... 77 186 7.3.3 DSA Signature Keys ...................................... 78 187 8 References .................................................. 80 188 9 Intellectual Property Rights ................................ 82 189 10 Security Considerations .................................... 82 190 Appendix A. ASN.1 Structures and OIDs ......................... 85 191 A.1 Explicitly Tagged Module, 1988 Syntax ...................... 85 192 A.2 Implicitly Tagged Module, 1988 Syntax ...................... 99 193 Appendix B. 1993 ASN.1 Structures and OIDs .................... 106 194 B.1 Explicitly Tagged Module, 1993 Syntax ...................... 106 195 B.2 Implicitly Tagged Module, 1993 Syntax ...................... 122 196 Appendix C. ASN.1 Notes ....................................... 130 197 Appendix D. Examples .......................................... 131 198 D.1 Certificate ............................................... 131 199 D.2 Certificate ............................................... 134 200 D.3 End-Entity Certificate Using RSA .......................... 137 201 D.4 Certificate Revocation List ............................... 140 202 Appendix E. Author Addresses .................................. 142 203 Appendix F. Full Copyright Statement .......................... 142 205 1 Introduction 207 This specification is one part of a family of standards for the X.509 208 Public Key Infrastructure (PKI) for the Internet. This specification 209 is a standalone document; implementations of this standard may 210 proceed independent from the other parts. 212 This specification profiles the format and semantics of certificates 213 and certificate revocation lists for the Internet PKI. Procedures 214 are described for processing of certification paths in the Internet 215 environment. Encoding rules are provided for popular cryptographic 216 algorithms. Finally, ASN.1 modules are provided in the appendices 217 for all data structures defined or referenced. 219 The specification describes the requirements which inspire the crea- 220 tion of this document and the assumptions which affect its scope in 221 Section 2. Section 3 presents an architectural model and describes 222 its relationship to previous IETF and ISO/IEC/ITU standards. In par- 223 ticular, this document's relationship with the IETF PEM specifica- 224 tions and the ISO/IEC/ITU X.509 documents are described. 226 The specification profiles the X.509 version 3 certificate in Section 227 4, and the X.509 version 2 certificate revocation list (CRL) in Sec- 228 tion 5. The profiles include the identification of ISO/IEC/ITU and 229 ANSI extensions which may be useful in the Internet PKI. The profiles 230 are presented in the 1988 Abstract Syntax Notation One (ASN.1) rather 231 than the 1994 syntax used in the ISO/IEC/ITU standards. 233 This specification also includes path validation procedures in Sec- 234 tion 6. These procedures are based upon the ISO/IEC/ITU definition, 235 but the presentation assumes one or more self-signed trusted CA cer- 236 tificates. Implementations are required to derive the same results 237 but are not required to use the specified procedures. 239 Section 7 of the specification describes procedures for identifica- 240 tion and encoding of public key materials and digital signatures. 241 Implementations are not required to use any particular cryptographic 242 algorithms. However, conforming implementations which use the iden- 243 tified algorithms are required to identify and encode the public key 244 materials and digital signatures as described. 246 Finally, four appendices are provided to aid implementers. Appendix 247 A contains all ASN.1 structures defined or referenced within this 248 specification. As above, the material is presented in the 1988 249 Abstract Syntax Notation One (ASN.1) rather than the 1994 syntax. 250 Appendix B contains the same information in the 1994 ASN.1 notation 251 as a service to implementers using updated toolsets. However, Appen- 252 dix A takes precedence in case of conflict. Appendix C contains 253 notes on less familiar features of the ASN.1 notation used within 254 this specification. Appendix D contains examples of a conforming 255 certificate and a conforming CRL. 257 2 Requirements and Assumptions 259 The goal of this specification is to develop a profile to facilitate 260 the use of X.509 certificates within Internet applications for those 261 communities wishing to make use of X.509 technology. Such applica- 262 tions may include WWW, electronic mail, user authentication, and 263 IPsec. In order to relieve some of the obstacles to using X.509 cer- 264 tificates, this document defines a profile to promote the development 265 of certificate management systems; development of application tools; 266 and interoperability determined by policy. 268 Some communities will need to supplement, or possibly replace, this 269 profile in order to meet the requirements of specialized application 270 domains or environments with additional authorization, assurance, or 271 operational requirements. However, for basic applications, common 272 representations of frequently used attributes are defined so that 273 application developers can obtain necessary information without 274 regard to the issuer of a particular certificate or certificate revo- 275 cation list (CRL). 277 A certificate user should review the certificate policy generated by 278 the certification authority (CA) before relying on the authentication 279 or non-repudiation services associated with the public key in a par- 280 ticular certificate. To this end, this standard does not prescribe 281 legally binding rules or duties. 283 As supplemental authorization and attribute management tools emerge, 284 such as attribute certificates, it may be appropriate to limit the 285 authenticated attributes that are included in a certificate. These 286 other management tools may provide more appropriate methods of con- 287 veying many authenticated attributes. 289 2.1 Communication and Topology 291 The users of certificates will operate in a wide range of environ- 292 ments with respect to their communication topology, especially users 293 of secure electronic mail. This profile supports users without high 294 bandwidth, real-time IP connectivity, or high connection availabil- 295 ity. In addition, the profile allows for the presence of firewall or 296 other filtered communication. 298 This profile does not assume the deployment of an X.500 Directory 299 system. The profile does not prohibit the use of an X.500 Directory, 300 but other means of distributing certificates and certificate 301 revocation lists (CRLs) may be used. 303 2.2 Acceptability Criteria 305 The goal of the Internet Public Key Infrastructure (PKI) is to meet 306 the needs of deterministic, automated identification, authentication, 307 access control, and authorization functions. Support for these ser- 308 vices determines the attributes contained in the certificate as well 309 as the ancillary control information in the certificate such as pol- 310 icy data and certification path constraints. 312 2.3 User Expectations 314 Users of the Internet PKI are people and processes who use client 315 software and are the subjects named in certificates. These uses 316 include readers and writers of electronic mail, the clients for WWW 317 browsers, WWW servers, and the key manager for IPsec within a router. 318 This profile recognizes the limitations of the platforms these users 319 employ and the limitations in sophistication and attentiveness of the 320 users themselves. This manifests itself in minimal user configura- 321 tion responsibility (e.g., trusted CA keys, rules), explicit platform 322 usage constraints within the certificate, certification path con- 323 straints which shield the user from many malicious actions, and 324 applications which sensibly automate validation functions. 326 2.4 Administrator Expectations 328 As with user expectations, the Internet PKI profile is structured to 329 support the individuals who generally operate CAs. Providing 330 administrators with unbounded choices increases the chances that a 331 subtle CA administrator mistake will result in broad compromise. 332 Also, unbounded choices greatly complicate the software that shall 333 process and validate the certificates created by the CA. 335 3 Overview of Approach 337 Following is a simplified view of the architectural model assumed by 338 the PKIX specifications. 340 +---+ 341 | C | +------------+ 342 | e | <-------------------->| End entity | 343 | r | Operational +------------+ 344 | t | transactions ^ 345 | | and management | Management 346 | / | transactions | transactions 347 | | | PKI users 348 | C | v 349 | R | -------------------+--+-----------+---------------- 350 | L | ^ ^ 351 | | | | PKI management 352 | | v | entities 353 | R | +------+ | 354 | e | <---------------------| RA | <---+ | 355 | p | Publish certificate +------+ | | 356 | o | | | 357 | s | | | 358 | I | v v 359 | t | +------------+ 360 | o | <------------------------------| CA | 361 | r | Publish certificate +------------+ 362 | y | Publish CRL ^ 363 | | | 364 +---+ Management | 365 transactions | 366 v 367 +------+ 368 | CA | 369 +------+ 371 Figure 1 - PKI Entities 373 The components in this model are: 375 end entity: user of PKI certificates and/or end user system that 376 is the subject of a certificate; 377 CA: certification authority; 378 RA: registration authority, i.e., an optional system to 379 which a CA delegates certain management functions; 380 repository: a system or collection of distributed systems that 381 store certificates and CRLs and serves as a means of 382 distributing these certificates and CRLs to end 383 entities. 385 3.1 X.509 Version 3 Certificate 387 Users of a public key require confidence that the associated private 388 key is owned by the correct remote subject (person or system) with 389 which an encryption or digital signature mechanism will be used. 390 This confidence is obtained through the use of public key certifi- 391 cates, which are data structures that bind public key values to sub- 392 jects. The binding is asserted by having a trusted CA digitally sign 393 each certificate. The CA may base this assertion upon technical means 394 (a.k.a., proof of posession through a challenge-response protocol), 395 presentation of the private key, or on an assertion by the subject. 396 A certificate has a limited valid lifetime which is indicated in its 397 signed contents. Because a certificate's signature and timeliness 398 can be independently checked by a certificate-using client, certifi- 399 cates can be distributed via untrusted communications and server sys- 400 tems, and can be cached in unsecured storage in certificate-using 401 systems. 403 ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8, which was 404 first published in 1988 as part of the X.500 Directory recommenda- 405 tions, defines a standard certificate format [X.509]. The certificate 406 format in the 1988 standard is called the version 1 (v1) format. 407 When X.500 was revised in 1993, two more fields were added, resulting 408 in the version 2 (v2) format. 410 The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993, 411 include specifications for a public key infrastructure based on X.509 412 v1 certificates [RFC 1422]. The experience gained in attempts to 413 deploy RFC 1422 made it clear that the v1 and v2 certificate formats 414 are deficient in several respects. Most importantly, more fields 415 were needed to carry information which PEM design and implementation 416 experience has proven necessary. In response to these new require- 417 ments, ISO/IEC/ITU and ANSI X9 developed the X.509 version 3 (v3) 418 certificate format. The v3 format extends the v2 format by adding 419 provision for additional extension fields. Particular extension 420 field types may be specified in standards or may be defined and 421 registered by any organization or community. In June 1996, standardi- 422 zation of the basic v3 format was completed [X.509]. 424 ISO/IEC/ITU and ANSI X9 have also developed standard extensions for 425 use in the v3 extensions field [X.509][X9.55]. These extensions can 426 convey such data as additional subject identification information, 427 key attribute information, policy information, and certification path 428 constraints. 430 However, the ISO/IEC/ITU and ANSI X9 standard extensions are very 431 broad in their applicability. In order to develop interoperable 432 implementations of X.509 v3 systems for Internet use, it is necessary 433 to specify a profile for use of the X.509 v3 extensions tailored for 434 the Internet. It is one goal of this document to specify a profile 435 for Internet WWW, electronic mail, and IPsec applications. Environ- 436 ments with additional requirements may build on this profile or may 437 replace it. 439 3.2 Certification Paths and Trust 441 A user of a security service requiring knowledge of a public key gen- 442 erally needs to obtain and validate a certificate containing the 443 required public key. If the public-key user does not already hold an 444 assured copy of the public key of the CA that signed the certificate, 445 the CA's name, and related information (such as the validity period 446 or name constraints), then it might need an additional certificate to 447 obtain that public key. In general, a chain of multiple certificates 448 may be needed, comprising a certificate of the public key owner (the 449 end entity) signed by one CA, and zero or more additional certifi- 450 cates of CAs signed by other CAs. Such chains, called certification 451 paths, are required because a public key user is only initialized 452 with a limited number of assured CA public keys. 454 There are different ways in which CAs might be configured in order 455 for public key users to be able to find certification paths. For 456 PEM, RFC 1422 defined a rigid hierarchical structure of CAs. There 457 are three types of PEM certification authority: 459 (a) Internet Policy Registration Authority (IPRA): This author- 460 ity, operated under the auspices of the Internet Society, acts as 461 the root of the PEM certification hierarchy at level 1. It issues 462 certificates only for the next level of authorities, PCAs. All 463 certification paths start with the IPRA. 465 (b) Policy Certification Authorities (PCAs): PCAs are at level 2 466 of the hierarchy, each PCA being certified by the IPRA. A PCA 467 shall establish and publish a statement of its policy with respect 468 to certifying users or subordinate certification authorities. 469 Distinct PCAs aim to satisfy different user needs. For example, 470 one PCA (an organizational PCA) might support the general elec- 471 tronic mail needs of commercial organizations, and another PCA (a 472 high-assurance PCA) might have a more stringent policy designed 473 for satisfying legally binding digital signature requirements. 475 (c) Certification Authorities (CAs): CAs are at level 3 of the 476 hierarchy and can also be at lower levels. Those at level 3 are 477 certified by PCAs. CAs represent, for example, particular organi- 478 zations, particular organizational units (e.g., departments, 479 groups, sections), or particular geographical areas. 481 RFC 1422 furthermore has a name subordination rule which requires 482 that a CA can only issue certificates for entities whose names are 483 subordinate (in the X.500 naming tree) to the name of the CA itself. 484 The trust associated with a PEM certification path is implied by the 485 PCA name. The name subordination rule ensures that CAs below the PCA 486 are sensibly constrained as to the set of subordinate entities they 487 can certify (e.g., a CA for an organization can only certify entities 488 in that organization's name tree). Certificate user systems are able 489 to mechanically check that the name subordination rule has been fol- 490 lowed. 492 The RFC 1422 uses the X.509 v1 certificate formats. The limitations 493 of X.509 v1 required imposition of several structural restrictions to 494 clearly associate policy information or restrict the utility of cer- 495 tificates. These restrictions included: 497 (a) a pure top-down hierarchy, with all certification paths start- 498 ing from IPRA; 500 (b) a naming subordination rule restricting the names of a CA's 501 subjects; and 503 (c) use of the PCA concept, which requires knowledge of individual 504 PCAs to be built into certificate chain verification logic. 505 Knowledge of individual PCAs was required to determine if a chain 506 could be accepted. 508 With X.509 v3, most of the requirements addressed by RFC 1422 can be 509 addressed using certificate extensions, without a need to restrict 510 the CA structures used. In particular, the certificate extensions 511 relating to certificate policies obviate the need for PCAs and the 512 constraint extensions obviate the need for the name subordination 513 rule. As a result, this document supports a more flexible architec- 514 ture, including: 516 (a) Certification paths may start with a public key of a CA in a 517 user's own domain, or with the public key of the top of a hierar- 518 chy. Starting with the public key of a CA in a user's own domain 519 has certain advantages. In some environments, the local domain is 520 the most trusted. 522 (b) Name constraints may be imposed through explicit inclusion of 523 a name constraints extension in a certificate, but are not 524 required. 526 (c) Policy extensions and policy mappings replace the PCA con- 527 cept, which permits a greater degree of automation. The applica- 528 tion can determine if the certification path is acceptable based 529 on the contents of the certificates instead of a priori knowledge 530 of PCAs. This permits automation of certificate chain processing. 532 3.3 Revocation 534 When a certificate is issued, it is expected to be in use for its 535 entire validity period. However, various circumstances may cause a 536 certificate to become invalid prior to the expiration of the validity 537 period. Such circumstances include change of name, change of associa- 538 tion between subject and CA (e.g., an employee terminates employment 539 with an organization), and compromise or suspected compromise of the 540 corresponding private key. Under such circumstances, the CA needs to 541 revoke the certificate. 543 X.509 defines one method of certificate revocation. This method 544 involves each CA periodically issuing a signed data structure called 545 a certificate revocation list (CRL). A CRL is a time stamped list 546 identifying revoked certificates which is signed by a CA and made 547 freely available in a public repository. Each revoked certificate is 548 identified in a CRL by its certificate serial number. When a 549 certificate-using system uses a certificate (e.g., for verifying a 550 remote user's digital signature), that system not only checks the 551 certificate signature and validity but also acquires a suitably- 552 recent CRL and checks that the certificate serial number is not on 553 that CRL. The meaning of "suitably-recent" may vary with local pol- 554 icy, but it usually means the most recently-issued CRL. A CA issues 555 a new CRL on a regular periodic basis (e.g., hourly, daily, or 556 weekly). An entry is added to the CRL as part of the next update 557 following notification of revocation. An entry may be removed from 558 the CRL after appearing on one regularly scheduled CRL issued beyond 559 the revoked certificate's validity period. 561 An advantage of this revocation method is that CRLs may be distri- 562 buted by exactly the same means as certificates themselves, namely, 563 via untrusted communications and server systems. 565 One limitation of the CRL revocation method, using untrusted communi- 566 cations and servers, is that the time granularity of revocation is 567 limited to the CRL issue period. For example, if a revocation is 568 reported now, that revocation will not be reliably notified to 569 certificate-using systems until the next periodic CRL is issued -- 570 this may be up to one hour, one day, or one week depending on the 571 frequency that the CA issues CRLs. 573 As with the X.509 v3 certificate format, in order to facilitate 574 interoperable implementations from multiple vendors, the X.509 v2 CRL 575 format needs to be profiled for Internet use. It is one goal of this 576 document to specify that profile. However, this profile does not 577 require CAs to issue CRLs. Message formats and protocols supporting 578 on-line revocation notification may be defined in other PKIX specifi- 579 cations. On-line methods of revocation notification may be applica- 580 ble in some environments as an alternative to the X.509 CRL. On-line 581 revocation checking may significantly reduce the latency between a 582 revocation report and the distribution of the information to relying 583 parties. Once the CA accepts the report as authentic and valid, any 584 query to the on-line service will correctly reflect the certificate 585 validation impacts of the revocation. However, these methods impose 586 new security requirements: the certificate validator needs to trust 587 the on-line validation service while the repository does not need to 588 be trusted. 590 3.4 Operational Protocols 592 Operational protocols are required to deliver certificates and CRLs 593 (or status information) to certificate using client systems. Provi- 594 sion is needed for a variety of different means of certificate and 595 CRL delivery, including distribution procedures based on LDAP, HTTP, 596 FTP, and X.500. Operational protocols supporting these functions are 597 defined in other PKIX specifications. These specifications may 598 include definitions of message formats and procedures for supporting 599 all of the above operational environments, including definitions of 600 or references to appropriate MIME content types. 602 3.5 Management Protocols 604 Management protocols are required to support on-line interactions 605 between PKI user and management entities. For example, a management 606 protocol might be used between a CA and a client system with which a 607 key pair is associated, or between two CAs which cross-certify each 608 other. The set of functions which potentially need to be supported 609 by management protocols include: 611 (a) registration: This is the process whereby a user first makes 612 itself known to a CA (directly, or through an RA), prior to that 613 CA issuing a certificate or certificates for that user. 615 (b) initialization: Before a client system can operate securely 616 it is necessary to install key materials which have the appropri- 617 ate relationship with keys stored elsewhere in the infrastructure. 618 For example, the client needs to be securely initialized with the 619 public key and other assured information of the trusted CA(s), to 620 be used in validating certificate paths. Furthermore, a client 621 typically needs to be initialized with its own key pair(s). 623 (c) certification: This is the process in which a CA issues a 624 certificate for a user's public key, and returns that certificate 625 to the user's client system and/or posts that certificate in a 626 repository. 628 (d) key pair recovery: As an option, user client key materials 629 (e.g., a user's private key used for encryption purposes) may be 630 backed up by a CA or a key backup system. If a user needs to 631 recover these backed up key materials (e.g., as a result of a for- 632 gotten password or a lost key chain file), an on-line protocol 633 exchange may be needed to support such recovery. 635 (e) key pair update: All key pairs need to be updated regularly, 636 i.e., replaced with a new key pair, and new certificates issued. 638 (f) revocation request: An authorized person advises a CA of an 639 abnormal situation requiring certificate revocation. 641 (g) cross-certification: Two CAs exchange information used in 642 establishing a cross-certificate. A cross-certificate is a certi- 643 ficate issued by one CA to another CA which contains a CA signa- 644 ture key used for issuing certificates. 646 Note that on-line protocols are not the only way of implementing the 647 above functions. For all functions there are off-line methods of 648 achieving the same result, and this specification does not mandate 649 use of on-line protocols. For example, when hardware tokens are 650 used, many of the functions may be achieved as part of the physical 651 token delivery. Furthermore, some of the above functions may be com- 652 bined into one protocol exchange. In particular, two or more of the 653 registration, initialization, and certification functions can be com- 654 bined into one protocol exchange. 656 The PKIX series of specifications may define a set of standard mes- 657 sage formats supporting the above functions in future specifications. 658 In that case, the protocols for conveying these messages in different 659 environments (e.g., on-line, file transfer, e-mail, and WWW) will 660 also be described in those specifications. 662 4 Certificate and Certificate Extensions Profile 664 This section presents a profile for public key certificates that will 665 foster interoperability and a reusable PKI. This section is based 666 upon the X.509 v3 certificate format and the standard certificate 667 extensions defined in [X.509]. The ISO/IEC/ITU documents use the 668 1993 version of ASN.1; while this document uses the 1988 ASN.1 syn- 669 tax, the encoded certificate and standard extensions are equivalent. 670 This section also defines private extensions required to support a 671 PKI for the Internet community. 673 Certificates may be used in a wide range of applications and environ- 674 ments covering a broad spectrum of interoperability goals and a 675 broader spectrum of operational and assurance requirements. The goal 676 of this document is to establish a common baseline for generic appli- 677 cations requiring broad interoperability and limited special purpose 678 requirements. In particular, the emphasis will be on supporting the 679 use of X.509 v3 certificates for informal Internet electronic mail, 680 IPsec, and WWW applications. 682 4.1 Basic Certificate Fields 684 The X.509 v3 certificate basic syntax is as follows. For signature 685 calculation, the certificate is encoded using the ASN.1 distinguished 686 encoding rules (DER) [X.208]. ASN.1 DER encoding is a tag, length, 687 value encoding system for each element. 689 Certificate ::= SEQUENCE { 690 tbsCertificate TBSCertificate, 691 signatureAlgorithm AlgorithmIdentifier, 692 signatureValue BIT STRING } 694 TBSCertificate ::= SEQUENCE { 695 version [0] EXPLICIT Version DEFAULT v1, 696 serialNumber CertificateSerialNumber, 697 signature AlgorithmIdentifier, 698 issuer Name, 699 validity Validity, 700 subject Name, 701 subjectPublicKeyInfo SubjectPublicKeyInfo, 702 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 703 -- If present, version shall be v2 or v3 704 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 705 -- If present, version shall be v2 or v3 706 extensions [3] EXPLICIT Extensions OPTIONAL 707 -- If present, version shall be v3 708 } 710 Version ::= INTEGER { v1(0), v2(1), v3(2) } 712 CertificateSerialNumber ::= INTEGER 714 Validity ::= SEQUENCE { 715 notBefore Time, 716 notAfter Time } 718 Time ::= CHOICE { 719 utcTime UTCTime, 720 generalTime GeneralizedTime } 722 UniqueIdentifier ::= BIT STRING 724 SubjectPublicKeyInfo ::= SEQUENCE { 725 algorithm AlgorithmIdentifier, 726 subjectPublicKey BIT STRING } 728 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 730 Extension ::= SEQUENCE { 731 extnID OBJECT IDENTIFIER, 732 critical BOOLEAN DEFAULT FALSE, 733 extnValue OCTET STRING } 735 The following items describe the X.509 v3 certificate for use in the 736 Internet. 738 4.1.1 Certificate Fields 740 The Certificate is a SEQUENCE of three required fields. The fields 741 are described in detail in the following subsections. 743 4.1.1.1 tbsCertificate 745 The field contains the names of the subject and issuer, a public key 746 associated with the subject, a validity period, and other associated 747 information. The fields are described in detail in section 4.1.2; 748 the tbscertificate may also include extensions which are described in 749 section 4.2. 751 4.1.1.2 signatureAlgorithm 753 The signatureAlgorithm field contains the identifier for the crypto- 754 graphic algorithm used by the CA to sign this certificate. Section 755 7.2 lists the supported signature algorithms. 757 An algorithm identifier is defined by the following ASN.1 structure: 759 AlgorithmIdentifier ::= SEQUENCE { 760 algorithm OBJECT IDENTIFIER, 761 parameters ANY DEFINED BY algorithm OPTIONAL } 763 The algorithm identifier is used to identify a cryptographic algo- 764 rithm. The OBJECT IDENTIFIER component identifies the algorithm 765 (such as DSA with SHA-1). The contents of the optional parameters 766 field will vary according to the algorithm identified. Section 7.2 767 lists the supported algorithms for this specification. 769 This field MUST contain the same algorithm identifier as the 770 signature field in the sequence tbsCertificate (see sec. 4.1.2.3). 772 4.1.1.3 signatureValue 774 The signatureValue field contains a digital signature computed upon 775 the ASN.1 DER encoded tbsCertificate. The ASN.1 DER encoded tbsCer- 776 tificate is used as the input to the signature function. This signa- 777 ture value is then ASN.1 encoded as a BIT STRING and included in the 778 Certificate's signature field. The details of this process are speci- 779 fied for each of the supported algorithms in Section 7.2. 781 By generating this signature, a CA certifies the validity of the 782 information in the tbsCertificate field. In particular, the CA cer- 783 tifies the binding between the public key material and the subject of 784 the certificate. 786 4.1.2 TBSCertificate 788 The sequence TBSCertificate contains information associated with the 789 subject of the certificate and the CA who issued it. Every TBSCerti- 790 ficate contains the names of the subject and issuer, a public key 791 associated with the subject, a validity period, a version number, and 792 a serial number; some may contain optional unique identifier fields. 793 The remainder of this section describes the syntax and semantics of 794 these fields. A TBSCertificate may also include extensions. Exten- 795 sions for the Internet PKI are described in Section 4.2. 797 4.1.2.1 Version 799 This field describes the version of the encoded certificate. When 800 extensions are used, as expected in this profile, use X.509 version 3 801 (value is 2). If no extensions are present, but a UniqueIdentifier 802 is present, use version 2 (value is 1). If only basic fields are 803 present, use version 1 (the value is omitted from the certificate as 804 the default value). 806 Implementations SHOULD be prepared to accept any version certificate. 807 At a minimum, conforming implementations MUST recognize version 3 808 certificates. 810 Generation of version 2 certificates is not expected by implementa- 811 tions based on this profile. 813 4.1.2.2 Serial number 815 The serial number is an integer assigned by the CA to each certifi- 816 cate. It MUST be unique for each certificate issued by a given CA 817 (i.e., the issuer name and serial number identify a unique 818 certificate). 820 4.1.2.3 Signature 822 This field contains the algorithm identifier for the algorithm used 823 by the CA to sign the certificate. 825 This field MUST contain the same algorithm identifier as the signa- 826 tureAlgorithm field in the sequence Certificate (see sec. 4.1.1.2). 827 The contents of the optional parameters field will vary according to 828 the algorithm identified. Section 7.2 lists the supported signature 829 algorithms. 831 4.1.2.4 Issuer 833 The issuer field identifies the entity who has signed and issued the 834 certificate. The issuer field MUST contain a non-empty distinguished 835 name (DN). The issuer field is defined as the X.501 type Name. 836 [X.501] Name is defined by the following ASN.1 structures: 838 Name ::= CHOICE { 839 RDNSequence } 841 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 843 RelativeDistinguishedName ::= 844 SET OF AttributeTypeAndValue 846 AttributeTypeAndValue ::= SEQUENCE { 847 type AttributeType, 848 value AttributeValue } 850 AttributeType ::= OBJECT IDENTIFIER 852 AttributeValue ::= ANY DEFINED BY AttributeType 854 DirectoryString ::= CHOICE { 855 teletexString TeletexString (SIZE (1..MAX)), 856 printableString PrintableString (SIZE (1..MAX)), 857 universalString UniversalString (SIZE (1..MAX)), 858 utf8String UTF8String (SIZE (1.. MAX)), 859 bmpString BMPString (SIZE (1..MAX)) } 861 The Name describes a hierarchical name composed of attributes, such 862 as country name, and corresponding values, such as US. The type of 863 the component AttributeValue is determined by the AttributeType; in 864 general it will be a DirectoryString. 866 The DirectoryString type is defined as a choice of PrintableString, 867 TeletexString, BMPString, UTF8String, and UniversalString. The 868 UTF8String encoding is the preferred encoding, and all certificates 869 issued after December 31, 2003 MUST use the UTF8String encoding of 870 DirectoryString (except as noted below). Until that date, conforming 871 CAs MUST choose from the following options when creating a dis- 872 tinguished name, including their own: 874 (a) if the character set is sufficient, the string MAY be 875 represented as a PrintableString; 877 (b) failing (a), if the BMPString character set is sufficient the 878 string MAY be represented as a BMPString; and 880 (c) failing (a) and (b), the string MUST be represented as a 881 UTF8String. If (a) or (b) is satisfied, the CA MAY still choose 882 to represent the string as a UTF8String. 884 Exceptions to the December 31, 2003 UTF8 encoding requirements are as 885 follows: 887 (a) CAs MAY issue "name rollover" certificates to support an ord- 888 erly migration to UTF8String encoding. Such certificates would 889 include the CA's UTF8String encoded name as issuer and and the old 890 name encoding as subject, or vice-versa. 892 (b) As stated in section 4.1.2.6, the subject field MUST be popu- 893 lated with a non-empty distinguished name matching the contents of 894 the issuer field in all certificates issued by the subject CA 895 regardless of encoding. 897 The TeletexString and UniversalString are included for backward com- 898 patibility, and should not be used for certificates for new subjects. 899 However, these types may be used in certificates where the name was 900 previously established. Certificate users SHOULD be prepared to 901 receive certificates with these types. 903 In addition, many legacy implementations support names encoded in the 904 ISO 8859-1 character set (Latin1String) but tag them as Teletex- 905 String. The Latin1String includes characters used in Western Euro- 906 pean countries which are not part of the TeletexString charcter set. 907 Implementations that process TeletexString SHOULD be prepared to han- 908 dle the entire ISO 8859-1 character set.[ISO 8859-1] 910 As noted above, distinguished names are composed of attributes. This 911 specification does not restrict the set of attribute types that may 912 appear in names. However, conforming implementations MUST be 913 prepared to receive certificates with issuer names containing the set 914 of attribute types defined below. This specification also recommends 915 support for additional attribute types. 917 Standard sets of attributes have been defined in the X.500 series of 918 specifications.[X.520] Implementations of this specification MUST be 919 prepared to receive the following standard attribute types in issuer 920 and subject (see 4.1.2.6) names: 922 * country, 923 * organization, 924 * organizational-unit, 925 * distinguished name qualifier, 926 * state or province name, and 927 * common name (e.g., "Susan Housley"). 929 In addition, implementations of this specification SHOULD be prepared 930 to receive the following standard attribute types in issuer and sub- 931 ject names: 933 * locality, 934 * title, 935 * surname, 936 * given name, 937 * initials, and 938 * generation qualifier (e.g., "Jr.", "3rd", or "IV"). 940 The syntax and associated object identifiers (OIDs) for these attri- 941 bute types are provided in the ASN.1 modules in Appendices A and B. 943 In addition, implementations of this specification MUST be prepared 944 to receive the domainComponent attribute, as defined in [RFC 2247]. 945 The Domain (Nameserver) System (DNS) provides a hierarchical resource 946 labeling system. This attribute provides is a convenient mechanism 947 for organizations that wish to use DNs that parallel their DNS names. 948 This is not a replacement for the dNSName component of the alterna- 949 tive name field. Implementations are not required to convert such 950 names into DNS names. The syntax and associated OID for this attri- 951 bute type is provided in the ASN.1 modules in Appendices A and B. 953 Certificate users MUST be prepared to process the issuer dis- 954 tinguished name and subject distinguished name (see sec. 4.1.2.6) 955 fields to perform name chaining for certification path validation 956 (see section 6). Name chaining is performed by matching the issuer 957 distinguished name in one certificate with the subject name in a CA 958 certificate. 960 This specification requires only a subset of the name comparison 961 functionality specified in the X.500 series of specifications. The 962 requirements for conforming implementations are as follows: 964 (a) attribute values encoded in different types (e.g., Printable- 965 String and BMPString) may be assumed to represent different 966 strings; 968 (b) attribute values in types other than PrintableString are case 969 sensitive (this permits matching of attribute values as binary 970 objects); 972 (c) attribute values in PrintableString are not case sensitive 973 (e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and 975 (d) attribute values in PrintableString are compared after remov- 976 ing leading and trailing white space and converting internal sub- 977 strings of one or more consecutive white space characters to a 978 single space. 980 These name comparison rules permit a certificate user to validate 981 certificates issued using languages or encodings unfamiliar to the 982 certificate user. 984 In addition, implementations of this specification MAY use these com- 985 parison rules to process unfamiliar attribute types for name chain- 986 ing. This allows implementations to process certificates with unfami- 987 liar attributes in the issuer name. 989 Note that the comparison rules defined in the X.500 series of specif- 990 ications indicate that the character sets used to encode data in dis- 991 tinguished names are irrelevant. The characters themselves are com- 992 pared without regard to encoding. Implementations of the profile are 993 permitted to use the comparison algorithm defined in the X.500 994 series. Such an implementation will recognize a superset of name 995 matches recognized by the algorithm specified above. 997 4.1.2.5 Validity 999 The certificate validity period is the time interval during which the 1000 CA warrants that it will maintain information about the status of the 1001 certificate. The field is represented as a SEQUENCE of two dates: 1002 the date on which the certificate validity period begins (notBefore) 1003 and the date on which the certificate validity period ends 1004 (notAfter). Both notBefore and notAfter may be encoded as UTCTime or 1005 GeneralizedTime. 1007 CAs conforming to this profile MUST always encode certificate vali- 1008 dity dates through the year 2049 as UTCTime; certificate validity 1009 dates in 2050 or later MUST be encoded as GeneralizedTime. 1011 4.1.2.5.1 UTCTime 1013 The universal time type, UTCTime, is a standard ASN.1 type intended 1014 for representation of dates and time. UTCTime specifies the year 1015 through the two low order digits and time is specified to the preci- 1016 sion of one minute or one second. UTCTime includes either Z (for 1017 Zulu, or Greenwich Mean Time) or a time differential. 1019 For the purposes of this profile, UTCTime values MUST be expressed 1020 Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are 1021 YYMMDDHHMMSSZ), even where the number of seconds is zero. Conforming 1022 systems MUST interpret the year field (YY) as follows: 1024 Where YY is greater than or equal to 50, the year shall be inter- 1025 preted as 19YY; and 1027 Where YY is less than 50, the year shall be interpreted as 20YY. 1029 4.1.2.5.2 GeneralizedTime 1031 The generalized time type, GeneralizedTime, is a standard ASN.1 type 1032 for variable precision representation of time. Optionally, the Gen- 1033 eralizedTime field can include a representation of the time differen- 1034 tial between local and Greenwich Mean Time. 1036 For the purposes of this profile, GeneralizedTime values MUST be 1037 expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e., 1038 times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. 1039 GeneralizedTime values MUST NOT include fractional seconds. 1041 4.1.2.6 Subject 1043 The subject field identifies the entity associated with the public 1044 key stored in the subject public key field. The subject name may be 1045 carried in the subject field and/or the subjectAltName extension. If 1046 the subject is a CA (e.g., the basic constraints extension, as dis- 1047 cussed in 4.2.1.10, is present and the value of cA is TRUE,) then the 1048 subject field MUST be populated with a non-empty distinguished name 1049 matching the contents of the issuer field (see sec. 4.1.2.4) in all 1050 certificates issued by the subject CA. If subject naming information 1051 is present only in the subjectAltName extension (e.g., a key bound 1052 only to an email address or URI), then the subject name MUST be an 1053 empty sequence and the subjectAltName extension MUST be critical. 1055 Where it is non-empty, the subject field MUST contain an X.500 dis- 1056 tinguished name (DN). The DN MUST be unique for each subject entity 1057 certified by the one CA as defined by the issuer name field. A CA may 1058 issue more than one certificate with the same DN to the same subject 1059 entity. 1061 The subject name field is defined as the X.501 type Name. Implemen- 1062 tation requirements for this field are those defined for the issuer 1063 field (see sec. 4.1.2.4). When encoding attribute values of type 1064 DirectoryString, the encoding rules for the issuer field MUST be 1065 implemented. Implementations of this specification MUST be prepared 1066 to receive subject names containing the attribute types required for 1067 the issuer field. Implementations of this specification SHOULD be 1068 prepared to receive subject names containing the recommended attri- 1069 bute types for the issuer field. The syntax and associated object 1070 identifiers (OIDs) for these attribute types are provided in the 1071 ASN.1 modules in Appendices A and B. Implementations of this specif- 1072 ication MAY use these comparison rules to process unfamiliar attri- 1073 bute types (i.e., for name chaining). This allows implementations to 1074 process certificates with unfamiliar attributes in the subject name. 1076 In addition, legacy implementations exist where an RFC 822 name is 1077 embedded in the subject distinguished name as an EmailAddress attri- 1078 bute. The attribute value for EmailAddress is of type IA5String to 1079 permit inclusion of the character '@', which is not part of the 1080 PrintableString character set. EmailAddress attribute values are not 1081 case sensitive (e.g., "fanfeedback@redsox.com" is the same as 1082 "FANFEEDBACK@REDSOX.COM"). 1084 Conforming implementations generating new certificates with elec- 1085 tronic mail addresses MUST use the rfc822Name in the subject alterna- 1086 tive name field (see sec. 4.2.1.7) to describe such identities. 1087 Simultaneous inclusion of the EmailAddress attribute in the subject 1088 distinguished name to support legacy implementations is deprecated 1089 but permitted. 1091 4.1.2.7 Subject Public Key Info 1093 This field is used to carry the public key and identify the algorithm 1094 with which the key is used. The algorithm is identified using the 1095 AlgorithmIdentifier structure specified in section 4.1.1.2. The 1096 object identifiers for the supported algorithms and the methods for 1097 encoding the public key materials (public key and parameters) are 1098 specified in section 7.3. 1100 4.1.2.8 Unique Identifiers 1102 These fields may only appear if the version is 2 or 3 (see sec. 1103 4.1.2.1). The subject and issuer unique identifiers are present in 1104 the certificate to handle the possibility of reuse of subject and/or 1105 issuer names over time. This profile recommends that names not be 1106 reused for different entities and that Internet certificates not make 1107 use of unique identifiers. CAs conforming to this profile SHOULD NOT 1108 generate certificates with unique identifiers. Applications conform- 1109 ing to this profile SHOULD be capable of parsing unique identifiers 1110 and making comparisons. 1112 4.1.2.9 Extensions 1114 This field may only appear if the version is 3 (see sec. 4.1.2.1). 1115 If present, this field is a SEQUENCE of one or more certificate 1116 extensions. The format and content of certificate extensions in the 1117 Internet PKI is defined in section 4.2. 1119 4.2 Standard Certificate Extensions 1121 The extensions defined for X.509 v3 certificates provide methods for 1122 associating additional attributes with users or public keys and for 1123 managing the certification hierarchy. The X.509 v3 certificate for- 1124 mat also allows communities to define private extensions to carry 1125 information unique to those communities. Each extension in a certi- 1126 ficate may be designated as critical or non-critical. A certificate 1127 using system MUST reject the certificate if it encounters a critical 1128 extension it does not recognize; however, a non-critical extension 1129 may be ignored if it is not recognized. The following sections 1130 present recommended extensions used within Internet certificates and 1131 standard locations for information. Communities may elect to use 1132 additional extensions; however, caution should be exercised in adopt- 1133 ing any critical extensions in certificates which might prevent use 1134 in a general context. 1136 Each extension includes an OID and an ASN.1 structure. When an 1137 extension appears in a certificate, the OID appears as the field 1138 extnID and the corresponding ASN.1 encoded structure is the value of 1139 the octet string extnValue. Only one instance of a particular exten- 1140 sion may appear in a particular certificate. For example, a certifi- 1141 cate may contain only one authority key identifier extension (see 1142 sec. 4.2.1.1). An extension includes the boolean critical, with a 1143 default value of FALSE. The text for each extension specifies the 1144 acceptable values for the critical field. 1146 Conforming CAs MUST support key identifiers (see sec. 4.2.1.1 and 1147 4.2.1.2), basic constraints (see sec. 4.2.1.10), key usage (see sec. 1148 4.2.1.3), and certificate policies (see sec. 4.2.1.5) extensions. If 1149 the CA issues certificates with an empty sequence for the subject 1150 field, the CA MUST support the subject alternative name extension 1151 (see sec. 4.2.1.7). Support for the remaining extensions is 1152 OPTIONAL. Conforming CAs may support extensions that are not identi- 1153 fied within this specification; certificate issuers are cautioned 1154 that marking such extensions as critical may inhibit 1155 interoperability. 1157 At a minimum, applications conforming to this profile MUST recognize 1158 the extensions which must or may be critical in this specification. 1159 These extensions are: key usage (see sec. 4.2.1.3), certificate pol- 1160 icies (see sec. 4.2.1.5), the subject alternative name (see sec. 1161 4.2.1.7), basic constraints (see sec. 4.2.1.10), name constraints 1162 (see sec. 4.2.1.11), policy constraints (see sec. 4.2.1.12), and 1163 extended key usage (see sec. 4.2.1.13). 1165 In addition, this profile RECOMMENDS application support for the 1166 authority and subject key identifier (see sec. 4.2.1.1 and 4.2.1.2) 1167 extensions. 1169 4.2.1 Standard Extensions 1171 This section identifies standard certificate extensions defined in 1172 [X.509] for use in the Internet PKI. Each extension is associated 1173 with an OID defined in [X.509]. These OIDs are members of the id-ce 1174 arc, which is defined by the following: 1176 id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 1178 4.2.1.1 Authority Key Identifier 1180 The authority key identifier extension provides a means of identify- 1181 ing the public key corresponding to the private key used to sign a 1182 certificate. This extension is used where an issuer has multiple 1183 signing keys (either due to multiple concurrent key pairs or due to 1184 changeover). The identification may be based on either the key iden- 1185 tifier (the subject key identifier in the issuer's certificate) or on 1186 the issuer name and serial number. 1188 The keyIdentifier field of the authorityKeyIdentifier extension MUST 1189 be included in all certificates generated by conforming CAs to facil- 1190 itate chain building. There is one exception; where a CA distributes 1191 its public key in the form of a "self-signed" certificate, the 1192 authority key identifier may be omitted. In this case, the subject 1193 and authority key identifiers would be identical. 1195 The value of the keyIdentifier field SHOULD be derived from the pub- 1196 lic key used to verify the certificate's signature or a method that 1197 generates unique values. Two common methods for generating key iden- 1198 tifiers from the public key are described in (sec. 4.2.1.2). One com- 1199 mon method for generating unique values is described in (sec. 1200 4.2.1.2). Where a key identifier has not been previously esta- 1201 blished, this specification recommends use of one of these methods 1202 for generating keyIdentifiers. 1204 This profile recommends support for the key identifier method by all 1205 certificate users. 1207 This extension MUST NOT be marked critical. 1209 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 1211 AuthorityKeyIdentifier ::= SEQUENCE { 1212 keyIdentifier [0] KeyIdentifier OPTIONAL, 1213 authorityCertIssuer [1] GeneralNames OPTIONAL, 1214 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 1216 KeyIdentifier ::= OCTET STRING 1218 4.2.1.2 Subject Key Identifier 1220 The subject key identifier extension provides a means of identifying 1221 certificates that contain a particular public key. 1223 To facilitate chain building, this extension MUST appear in all con- 1224 forming CA certificates, that is, all certificates including the 1225 basic constraints extension (see sec. 4.2.1.10) where the value of cA 1226 is TRUE. The value of the subject key identifier MUST be the value 1227 placed in the key identifier field of the Authority Key Identifier 1228 extension (see sec. 4.2.1.1) of certificates issued by the subject of 1229 this certificate. 1231 For CA certificates, subject key identifiers SHOULD be derived from 1232 the public key or a method that generates unique values. Two common 1233 methods for generating key identifiers from the public key are: 1235 (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the 1236 value of the BIT STRING subjectPublicKey (excluding the tag, 1237 length, and number of unused bits). 1239 (2) The keyIdentifier is composed of a four bit type field with 1240 the value 0100 followed by the least significant 60 bits of the 1241 SHA-1 hash of the value of the BIT STRING subjectPublicKey. 1243 One common method for generating unique values is a monotomically 1244 increasing sequence of integers. 1246 For end entity certificates, the subject key identifier extension 1247 provides a means for identifying certificates containing the particu- 1248 lar public key used in an application. Where an end entity has 1249 obtained multiple certificates, especially from multiple CAs, the 1250 subject key identifier provides a means to quickly identify the set 1251 of certificates containing a particular public key. To assist 1252 applications in identificiation the appropriate end entity certifi- 1253 cate, this extension SHOULD be included in all end entity certifi- 1254 cates. 1256 For end entity certificates, subject key identifiers SHOULD be 1257 derived from the public key. Two common methods for generating key 1258 identifiers from the public key are identifed above. 1260 Where a key identifier has not been previously established, this 1261 specification recommends use of one of these methods for generating 1262 keyIdentifiers. 1264 This extension MUST NOT be marked critical. 1266 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 1268 SubjectKeyIdentifier ::= KeyIdentifier 1270 4.2.1.3 Key Usage 1272 The key usage extension defines the purpose (e.g., encipherment, sig- 1273 nature, certificate signing) of the key contained in the certificate. 1274 The usage restriction might be employed when a key that could be used 1275 for more than one operation is to be restricted. For example, when 1276 an RSA key should be used only for signing, the digitalSignature 1277 and/or nonRepudiation bits would be asserted. Likewise, when an RSA 1278 key should be used only for key management, the keyEncipherment bit 1279 would be asserted. When used, this extension SHOULD be marked criti- 1280 cal. 1282 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 1284 KeyUsage ::= BIT STRING { 1285 digitalSignature (0), 1286 nonRepudiation (1), 1287 keyEncipherment (2), 1288 dataEncipherment (3), 1289 keyAgreement (4), 1290 keyCertSign (5), 1291 cRLSign (6), 1292 encipherOnly (7), 1293 decipherOnly (8) } 1295 Bits in the KeyUsage type are used as follows: 1297 The digitalSignature bit is asserted when the subject public key 1298 is used with a digital signature mechanism to support security 1299 services other than non-repudiation (bit 1), certificate signing 1300 (bit 5), or revocation information signing (bit 6). Digital signa- 1301 ture mechanisms are often used for entity authentication and data 1302 origin authentication with integrity. 1304 The nonRepudiation bit is asserted when the subject public key is 1305 used to verify digital signatures used to provide a non- 1306 repudiation service which protects against the signing entity 1307 falsely denying some action, excluding certificate or CRL signing. 1309 The keyEncipherment bit is asserted when the subject public key is 1310 used for key transport. For example, when an RSA key is to be 1311 used for key management, then this bit shall asserted. 1313 The dataEncipherment bit is asserted when the subject public key 1314 is used for enciphering user data, other than cryptographic keys. 1316 The keyAgreement bit is asserted when the subject public key is 1317 used for key agreement. For example, when a Diffie-Hellman key is 1318 to be used for key management, then this bit shall asserted. 1320 The keyCertSign bit is asserted when the subject public key is 1321 used for verifying a signature on certificates. This bit may only 1322 be asserted in CA certificates. If the keyCertSign bit is 1323 asserted, then the cA bit in the basic constraints extension (see 1324 4.2.1.10) MUST also be asserted. If the keyCertSign bit is not 1325 asserted, then the cA bit in the basic constraints extension MUST 1326 NOT be asserted. 1328 The cRLSign bit is asserted when the subject public key is used 1329 for verifying a signature on revocation information (e.g., a CRL). 1331 The meaning of the encipherOnly bit is undefined in the absence of 1332 the keyAgreement bit. When the encipherOnly bit is asserted and 1333 the keyAgreement bit is also set, the subject public key may be 1334 used only for enciphering data while performing key agreement. 1336 The meaning of the decipherOnly bit is undefined in the absence of 1337 the keyAgreement bit. When the decipherOnly bit is asserted and 1338 the keyAgreement bit is also set, the subject public key may be 1339 used only for deciphering data while performing key agreement. 1341 This profile does not restrict the combinations of bits that may be 1342 set in an instantiation of the keyUsage extension. However, 1343 appropriate values for keyUsage extensions for particular algorithms 1344 are specified in section 7.3. 1346 4.2.1.4 Private Key Usage Period 1348 This profile recommends against the use of this extension. CAs con- 1349 forming to this profile MUST NOT generate certificates with critical 1350 private key usage period extensions. 1352 The private key usage period extension allows the certificate issuer 1353 to specify a different validity period for the private key than the 1354 certificate. This extension is intended for use with digital signa- 1355 ture keys. This extension consists of two optional components, 1356 notBefore and notAfter. The private key associated with the certifi- 1357 cate should not be used to sign objects before or after the times 1358 specified by the two components, respectively. CAs conforming to this 1359 profile MUST NOT generate certificates with private key usage period 1360 extensions unless at least one of the two components is present. 1362 Where used, notBefore and notAfter are represented as GeneralizedTime 1363 and MUST be specified and interpreted as defined in section 1364 4.1.2.5.2. 1366 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 1368 PrivateKeyUsagePeriod ::= SEQUENCE { 1369 notBefore [0] GeneralizedTime OPTIONAL, 1370 notAfter [1] GeneralizedTime OPTIONAL } 1372 4.2.1.5 Certificate Policies 1374 The certificate policies extension contains a sequence of one or more 1375 policy information terms, each of which consists of an object iden- 1376 tifier (OID) and optional qualifiers. In an end entity certificate, 1377 these policy information terms indicate the policy under which the 1378 certificate has been issued and the purposes for which the certifi- 1379 cate may be used. In a CA certificate, these policy information 1380 terms limit the set of policies for certification paths which include 1381 When a CA does not wish to limit the set of policies for certifica- 1382 tion paths which include this certificate, they may assert the spe- 1383 cial policy anyPolicy. Optional qualifiers, which may be present, 1384 are not expected to change the definition of the policy. 1386 Applications with specific policy requirements are expected to have a 1387 list of those policies which they will accept and to compare the pol- 1388 icy OIDs in the certificate to that list. If this extension is crit- 1389 ical, the path validation software MUST be able to interpret this 1390 extension (including the optional qualifier), or MUST reject the cer- 1391 tificate. 1393 To promote interoperability, this profile RECOMMENDS that policy 1394 information terms consist of only an OID. Where an OID alone is 1395 insufficient, this profile strongly recommends that use of qualifiers 1396 be limited to those identified in this section. When qualifiers are 1397 used with the special policy anyPolicy, they MUST be limited to the 1398 qualifers identified in this section. 1400 This specification defines two policy qualifier types for use by cer- 1401 tificate policy writers and certificate issuers. The qualifier types 1402 are the CPS Pointer and User Notice qualifiers. 1404 The CPS Pointer qualifier contains a pointer to a Certification Prac- 1405 tice Statement (CPS) published by the CA. The pointer is in the form 1406 of a URI. 1408 User notice is intended for display to a relying party when a certi- 1409 ficate is used. The application software SHOULD display all user 1410 notices in all certificates of the certification path used, except 1411 that if a notice is duplicated only one copy need be displayed. To 1412 prevent such duplication, this qualifier SHOULD only be present in 1413 end-entity certificates and CA certificates issued to other organiza- 1414 tions. 1416 The user notice has two optional fields: the noticeRef field and the 1417 explicitText field. 1419 The noticeRef field, if used, names an organization and identi- 1420 fies, by number, a particular textual statement prepared by that 1421 organization. For example, it might identify the organization 1422 "CertsRUs" and notice number 1. In a typical implementation, the 1423 application software will have a notice file containing the 1424 current set of notices for CertsRUs; the application will extract 1425 the notice text from the file and display it. Messages may be 1426 multilingual, allowing the software to select the particular 1427 language message for its own environment. 1429 An explicitText field includes the textual statement directly in 1430 the certificate. The explicitText field is a string with a max- 1431 imum size of 200 characters. 1433 If both the noticeRef and explicitText options are included in the 1434 one qualifier and if the application software can locate the notice 1435 text indicated by the noticeRef option then that text should be 1436 displayed; otherwise, the explicitText string should be displayed. 1438 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 1440 anyPolicy OBJECT IDENTIFIER ::= {id-ce-certificate-policies 0} 1441 certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 1443 PolicyInformation ::= SEQUENCE { 1444 policyIdentifier CertPolicyId, 1445 policyQualifiers SEQUENCE SIZE (1..MAX) OF 1446 PolicyQualifierInfo OPTIONAL } 1448 CertPolicyId ::= OBJECT IDENTIFIER 1450 PolicyQualifierInfo ::= SEQUENCE { 1451 policyQualifierId PolicyQualifierId, 1452 qualifier ANY DEFINED BY policyQualifierId } 1454 -- policyQualifierIds for Internet policy qualifiers 1456 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 1457 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 1458 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 1460 PolicyQualifierId ::= 1461 OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) 1463 Qualifier ::= CHOICE { 1464 cPSuri CPSuri, 1465 userNotice UserNotice } 1467 CPSuri ::= IA5String 1469 UserNotice ::= SEQUENCE { 1470 noticeRef NoticeReference OPTIONAL, 1471 explicitText DisplayText OPTIONAL} 1473 NoticeReference ::= SEQUENCE { 1474 organization DisplayText, 1475 noticeNumbers SEQUENCE OF INTEGER } 1477 DisplayText ::= CHOICE { 1478 ia5String IA5String (SIZE (1..200)), 1479 visibleString VisibleString (SIZE (1..200)), 1480 bmpString BMPString (SIZE (1..200)), 1481 utf8String UTF8String (SIZE (1..200)) } 1483 4.2.1.6 Policy Mappings 1485 This extension is used in CA certificates. It lists one or more 1486 pairs of OIDs; each pair includes an issuerDomainPolicy and a sub- 1487 jectDomainPolicy. The pairing indicates the issuing CA considers its 1488 issuerDomainPolicy equivalent to the subject CA's 1489 subjectDomainPolicy. 1491 The issuing CA's users may accept an issuerDomainPolicy for certain 1492 applications. The policy mapping tells the issuing CA's users which 1493 policies associated with the subject CA are comparable to the policy 1494 they accept. 1496 Policies should not be mapped either to or from the special value 1497 anyPolicy. (see 4.2.1.5 certificate policies). 1499 This extension may be supported by CAs and/or applications, and it 1500 MUST be non-critical. 1502 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 1504 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 1505 issuerDomainPolicy CertPolicyId, 1506 subjectDomainPolicy CertPolicyId } 1508 4.2.1.7 Subject Alternative Name 1510 The subject alternative names extension allows additional identities 1511 to be bound to the subject of the certificate. Defined options 1512 include an Internet electronic mail address, a DNS name, an IP 1513 address, and a uniform resource identifier (URI). Other options 1514 exist, including completely local definitions. Multiple name forms, 1515 and multiple instances of each name form, may be included. Whenever 1516 such identities are to be bound into a certificate, the subject 1517 alternative name (or issuer alternative name) extension MUST be used. 1519 Because the subject alternative name is considered to be defini- 1520 tiviely bound to the public key, all parts of the subject alternative 1521 name MUST be verified by the CA. 1523 Further, if the only subject identity included in the certificate is 1524 an alternative name form (e.g., an electronic mail address), then the 1525 subject distinguished name MUST be empty (an empty sequence), and the 1526 subjectAltName extension MUST be present. If the subject field con- 1527 tains an empty sequence, the subjectAltName extension MUST be marked 1528 critical. 1530 When the subjectAltName extension contains an Internet mail address, 1531 the address MUST be included as an rfc822Name. The format of an 1532 rfc822Name is an "addr-spec" as defined in RFC 822 [RFC 822]. An 1533 addr-spec has the form "local-part@domain". Note that an addr-spec 1534 has no phrase (such as a common name) before it, has no comment (text 1535 surrounded in parentheses) after it, and is not surrounded by "<" and 1536 ">". Note that while upper and lower case letters are allowed in an 1537 RFC 822 addr-spec, no significance is attached to the case. 1539 When the subjectAltName extension contains a iPAddress, the address 1540 MUST be stored in the octet string in "network byte order," as speci- 1541 fied in RFC 791 [RFC 791]. The least significant bit (LSB) of each 1542 octet is the LSB of the corresponding byte in the network address. 1543 For IP Version 4, as specified in RFC 791, the octet string MUST con- 1544 tain exactly four octets. For IP Version 6, as specified in RFC 1545 1883, the octet string MUST contain exactly sixteen octets [RFC 1546 1883]. 1548 When the subjectAltName extension contains a domain name service 1549 label, the domain name MUST be stored in the dNSName (an IA5String). 1550 The name MUST be in the "preferred name syntax," as specified by RFC 1551 1034 [RFC 1034]. Note that while upper and lower case letters are 1552 allowed in domain names, no signifigance is attached to the case. In 1553 addition, while the string " " is a legal domain name, subjectAltName 1554 extensions with a dNSName " " are not permitted. Finally, the use of 1555 the DNS representation for Internet mail addresses (wpolk.nist.gov 1556 instead of wpolk@nist.gov) is not permitted; such identities are to 1557 be encoded as rfc822Name. 1559 When the subjectAltName extension contains a URI, the name MUST be 1560 stored in the uniformResourceIdentifier (an IA5String). The name MUST 1561 be a non-relative URL, and MUST follow the URL syntax and encoding 1562 rules specified in [RFC 1738]. The name must include both a scheme 1563 (e.g., "http" or "ftp") and a scheme-specific-part. The scheme- 1564 specific-part must include a fully qualified domain name or IP 1565 address as the host. 1567 As specified in [RFC 1738], the scheme name is not case-sensitive 1568 (e.g., "http" is equivalent to "HTTP"). The host part is also not 1569 case-sensitive, but other components of the scheme-specific-part may 1570 be case-sensitive. When comparing URIs, conforming implementations 1571 MUST compare the scheme and host without regard to case, but assume 1572 the remainder of the scheme-specific-part is case sensitive. 1574 Subject alternative names may be constrained in the same manner as 1575 subject distinguished names using the name constraints extension as 1576 described in section 4.2.1.11. 1578 If the subjectAltName extension is present, the sequence MUST contain 1579 at least one entry. Unlike the subject field, conforming CAs MUST 1580 NOT issue certificates with subjectAltNames containing empty General- 1581 Name fields. For example, an rfc822Name is represented as an 1582 IA5String. While an empty string is a valid IA5String, such an 1583 rfc822Name is not permitted by this profile. The behavior of clients 1584 that encounter such a certificate when processing a certificication 1585 path is not defined by this profile. 1587 Finally, the semantics of subject alternative names that include 1588 wildcard characters (e.g., as a placeholder for a set of names) are 1589 not addressed by this specification. Applications with specific 1590 requirements may use such names but shall define the semantics. 1592 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 1594 SubjectAltName ::= GeneralNames 1596 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 1598 GeneralName ::= CHOICE { 1599 otherName [0] OtherName, 1600 rfc822Name [1] IA5String, 1601 dNSName [2] IA5String, 1602 x400Address [3] ORAddress, 1603 directoryName [4] Name, 1604 ediPartyName [5] EDIPartyName, 1605 uniformResourceIdentifier [6] IA5String, 1606 iPAddress [7] OCTET STRING, 1607 registeredID [8] OBJECT IDENTIFIER} 1609 OtherName ::= SEQUENCE { 1610 type-id OBJECT IDENTIFIER, 1611 value [0] EXPLICIT ANY DEFINED BY type-id } 1613 EDIPartyName ::= SEQUENCE { 1614 nameAssigner [0] DirectoryString OPTIONAL, 1615 partyName [1] DirectoryString } 1617 4.2.1.8 Issuer Alternative Names 1619 As with 4.2.1.7, this extension is used to associate Internet style 1620 identities with the certificate issuer. Issuer alternative names MUST 1621 be encoded as in 4.2.1.7. 1623 Where present, this extension SHOULD NOT be marked critical. 1625 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 1627 IssuerAltName ::= GeneralNames 1629 4.2.1.9 Subject Directory Attributes 1631 The subject directory attributes extension is not recommended as an 1632 essential part of this profile, but it may be used in local environ- 1633 ments. This extension MUST be non-critical. 1635 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 1637 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 1639 4.2.1.10 Basic Constraints 1641 The basic constraints extension identifies whether the subject of the 1642 certificate is a CA and how deep a certification path may exist 1643 through that CA. 1645 The cA bit indicates if the certified public key may be used to ver- 1646 ify signatures on other certificates. If the cA bit is asserted, then 1647 the keyCertSign bit in the key usage extension (see 4.2.1.3) MUST 1648 also be asserted. If the cA bit is not asserted, then the keyCertSign 1649 bit in the key usage extension MUST NOT be asserted. 1651 The pathLenConstraint field is meaningful only if cA is set to TRUE. 1652 In this case, it gives the maximum number of CA certificates that may 1653 follow this certificate in a certification path. A value of zero 1654 indicates that only an end-entity certificate may follow in the path. 1655 Where it appears, the pathLenConstraint field MUST be greater than or 1656 equal to zero. Where pathLenConstraint does not appear, there is no 1657 limit to the allowed length of the certification path. 1659 This extension MUST appear as a critical extension in all CA certifi- 1660 cates. This extension MAY appear as a critical or non-critical 1661 extension in end entity certificates. 1663 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 1665 BasicConstraints ::= SEQUENCE { 1666 cA BOOLEAN DEFAULT FALSE, 1667 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 1669 4.2.1.11 Name Constraints 1671 The name constraints extension, which MUST be used only in a CA cer- 1672 tificate, indicates a name space within which all subject names in 1673 subsequent certificates in a certification path shall be located. 1674 Restrictions may apply to the subject distinguished name or subject 1675 alternative names. Restrictions apply only when the specified name 1676 form is present. If no name of the type is in the certificate, the 1677 certificate is acceptable. 1679 Name constraints are not applied to certificates whose issuer and 1680 subject are identical. (This could prevent CAs that utilize name 1681 constraints from issuing self-signed certificates to implement key 1682 rollover.) 1684 Restrictions are defined in terms of permitted or excluded name sub- 1685 trees. Any name matching a restriction in the excludedSubtrees field 1686 is invalid regardless of information appearing in the permittedSub- 1687 trees. This extension MUST be critical. 1689 Within this profile, the minimum and maximum fields are not used with 1690 any name forms, thus minimum is always zero, and maximum is always 1691 absent. 1693 For URIs, the constraint applies to the host part of the name. The 1694 constraint may specify a host or a domain. Examples would be 1695 "foo.bar.com"; and ".xyz.com". When the the constraint begins with 1696 a period, it may be expanded with one or more subdomains. That is, 1697 the constraint ".xyz.com" is satisfied by both abc.xyz.com and 1698 abc.def.xyz.com. However, the constraint ".xyz.com" is not satisfied 1699 by "xyz.com". When the constraint does not begin with a period, it 1700 specifies a host. 1702 A name constraint for Internat mail addresses may specify a particu- 1703 lar mailbox, all addresses at a particular host, or all mailboxes in 1704 a domain. To indicate a particular mailbox, the constraint is the 1705 complete mail address. For example, "root@xyz.com" indicates the 1706 root mailbox on the host "xyz.com". To indicate all Internet mail 1707 addresses on a particular host, the constraint is specified as the 1708 host name. For example, the constraint "xyz.com" is satisfied by any 1709 mail address at the host "xyz.com". To specify any address within a 1710 domain, the constraint is specified with a leading period (as with 1711 URIs). For example, ".xyz.com" indicates all the Internet mail 1712 addresses in the domain "xyz.com", but not Internet mail addresses on 1713 the host "xyz.com". 1715 DNS name restrictions are expressed as foo.bar.com. Any DNS name that 1716 can be constructed by simply adding to the left hand side of the name 1717 satisfies the name constraint. For example, www.foo.bar.com would 1718 satisfy the constraint but foo1.bar.com would not. 1720 Legacy implementations exist where an RFC 822 name is embedded in the 1721 subject distinguished name in an attribute of type EmailAddress (see 1722 sec. 4.1.2.6). When rfc822 names are constrained, but the certificate 1723 does not include a subject alternative name, the rfc822 name con- 1724 straint MUST be applied to the attribute of type EmailAddress in the 1725 subject distinguished name. The ASN.1 syntax for EmailAddress and 1726 the corresponding OID are supplied in Appendix A and B. 1728 Restrictions of the form directoryName MUST be applied to the subject 1729 field in the certificate and to the subjectAltName extensions of type 1730 directoryName. Restrictions of the form x400Address MUST be applied 1731 to subjectAltName extensions of type x400Address. 1733 When applying restrictions of the form directoryName, an implementa- 1734 tion MUST compare DN attributes. At a minimum, implementations MUST 1735 perform the DN comparison rules specified in Section 4.1.2.4. CAs 1736 issuing certificates with a restriction of the form directoryName 1737 SHOULD NOT rely on implementation of the full ISO DN name comparison 1738 algorithm. This implies name restrictions shall be stated identi- 1739 cally to the encoding used in the subject field or subjectAltName 1740 extension. 1742 The syntax of iPAddress MUST be as described in section 4.2.1.7 with 1743 the following additions specifically for Name Constraints. For IPv4 1744 addresses, the ipAddress field of generalName MUST contain eight (8) 1745 octets, encoded in the style of RFC 1519 (CIDR) to represent an 1746 address range.[RFC 1519] For IPv6 addresses, the ipAddress field 1747 MUST contain 32 octets similarly encoded. For example, a name con- 1748 straint for "class C" subnet 10.9.8.0 shall be represented as the 1749 octets 0A 09 08 00 FF FF FF 00, representing the CIDR notation 1750 10.9.8.0/255.255.255.0. 1752 The syntax and semantics for name constraints for otherName, ediPar- 1753 tyName, and registeredID are not defined by this specification. 1755 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 1757 NameConstraints ::= SEQUENCE { 1758 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 1759 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 1761 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 1763 GeneralSubtree ::= SEQUENCE { 1764 base GeneralName, 1765 minimum [0] BaseDistance DEFAULT 0, 1766 maximum [1] BaseDistance OPTIONAL } 1768 BaseDistance ::= INTEGER (0..MAX) 1770 4.2.1.12 Policy Constraints 1772 The policy constraints extension can be used in certificates issued 1773 to CAs. The policy constraints extension constrains path validation 1774 in two ways. It can be used to prohibit policy mapping or require 1775 that each certificate in a path contain an acceptable policy identif- 1776 ier. 1778 If the inhibitPolicyMapping field is present, the value indicates the 1779 number of additional certificates that may appear in the path before 1780 policy mapping is no longer permitted. For example, a value of one 1781 indicates that policy mapping may be processed in certificates issued 1782 by the subject of this certificate, but not in additional certifi- 1783 cates in the path. 1785 If the requireExplicitPolicy field is present, subsequent certifi- 1786 cates shall include an acceptable policy identifier. The value of 1787 requireExplicitPolicy indicates the number of additional certificates 1788 that may appear in the path before an explicit policy is required. 1789 An acceptable policy identifier is the identifier of a policy 1790 required by the user of the certification path or the identifier of a 1791 policy which has been declared equivalent through policy mapping. 1793 Conforming CAs MUST NOT issue certificates where policy constraints 1794 is a null sequence. That is, at least one of the inhibitPolicyMapping 1795 field or the requireExplicitPolicy field MUST be present. The 1796 behavior of clients that encounter a null policy constraints field is 1797 not addressed in this profile. 1799 This extension may be critical or non-critical. 1801 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } 1803 PolicyConstraints ::= SEQUENCE { 1804 requireExplicitPolicy [0] SkipCerts OPTIONAL, 1805 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 1807 SkipCerts ::= INTEGER (0..MAX) 1809 4.2.1.13 Extended key usage field 1811 This field indicates one or more purposes for which the certified 1812 public key may be used, in addition to or in place of the basic pur- 1813 poses indicated in the key usage extension field. This field is 1814 defined as follows: 1816 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 1817 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 1819 KeyPurposeId ::= OBJECT IDENTIFIER 1821 Key purposes may be defined by any organization with a need. Object 1822 identifiers used to identify key purposes shall be assigned in accor- 1823 dance with IANA or ITU-T Rec. X.660 | ISO/IEC/ITU 9834-1. 1825 This extension may, at the option of the certificate issuer, be 1826 either critical or non-critical. 1828 If the extension is flagged critical, then the certificate MUST be 1829 used only for one of the purposes indicated. 1831 If the extension is flagged non-critical, then it indicates the 1832 intended purpose or purposes of the key, and may be used in finding 1833 the correct key/certificate of an entity that has multiple 1834 keys/certificates. It is an advisory field and does not imply that 1835 usage of the key is restricted by the certification authority to the 1836 purpose indicated. Certificate using applications may nevertheless 1837 require that a particular purpose be indicated in order for the cer- 1838 tificate to be acceptable to that application. 1840 If a certificate contains both a critical key usage field and a crit- 1841 ical extended key usage field, then both fields MUST be processed 1842 independently and the certificate MUST only be used for a purpose 1843 consistent with both fields. If there is no purpose consistent with 1844 both fields, then the certificate MUST NOT be used for any purpose. 1846 The following key usage purposes are defined by this profile: 1848 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 1850 id-kp-serverAuth OBJECT IDENTIFIER ::= {id-kp 1} 1851 -- TLS Web server authentication 1852 -- Key usage bits that may be consistent: digitalSignature, 1853 -- keyEncipherment or keyAgreement 1854 -- 1855 id-kp-clientAuth OBJECT IDENTIFIER ::= {id-kp 2} 1856 -- TLS Web client authentication 1857 -- Key usage bits that may be consistent: digitalSignature and/or 1858 -- keyAgreement 1859 -- 1860 id-kp-codeSigning OBJECT IDENTIFIER ::= {id-kp 3} 1861 -- Signing of downloadable executable code 1862 -- Key usage bits that may be consistent: digitalSignature 1863 -- 1864 id-kp-emailProtection OBJECT IDENTIFIER ::= {id-kp 4} 1865 -- E-mail protection 1866 -- Key usage bits that may be consistent: digitalSignature, 1867 -- nonRepudiation, and/or (keyEncipherment 1868 -- or keyAgreement) 1869 -- 1870 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 1871 -- Binding the hash of an object to a time from an agreed-upon time 1872 -- source. Key usage bits that may be consistent: digitalSignature, 1873 -- nonRepudiation 1875 4.2.1.14 CRL Distribution Points 1877 The CRL distribution points extension identifies how CRL information 1878 is obtained. The extension SHOULD be non-critical, but this profile 1879 recommends support for this extension by CAs and applications. 1880 Further discussion of CRL management is contained in section 5. 1882 If the cRLDistributionPoints extension contains a Distribution- 1883 PointName of type URI, the following semantics MUST be assumed: the 1884 URI is a pointer to the current CRL for the associated reasons and 1885 will be issued by the associated cRLIssuer. The expected values for 1886 the URI are those defined in 4.2.1.7. Processing rules for other 1887 values are not defined by this specification. If the distribution- 1888 Point omits reasons, the CRL MUST include revocations for all rea- 1889 sons. If the distributionPoint omits cRLIssuer, the CRL MUST be 1890 issued by the CA that issued the certificate. 1892 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 } 1894 cRLDistributionPoints ::= { 1895 CRLDistPointsSyntax } 1897 CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 1899 DistributionPoint ::= SEQUENCE { 1900 distributionPoint [0] DistributionPointName OPTIONAL, 1901 reasons [1] ReasonFlags OPTIONAL, 1902 cRLIssuer [2] GeneralNames OPTIONAL } 1904 DistributionPointName ::= CHOICE { 1905 fullName [0] GeneralNames, 1906 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 1908 ReasonFlags ::= BIT STRING { 1909 unused (0), 1910 keyCompromise (1), 1911 cACompromise (2), 1912 affiliationChanged (3), 1913 superseded (4), 1914 cessationOfOperation (5), 1915 certificateHold (6) } 1917 4.2.2 Private Internet Extensions 1919 This section defines one new extension for use in the Internet Public 1920 Key Infrastructure. This extension may be used to direct applica- 1921 tions to identify an on-line validation service supporting the issu- 1922 ing CA. As the information may be available in multiple forms, each 1923 extension is a sequence of IA5String values, each of which represents 1924 a URI. The URI implicitly specifies the location and format of the 1925 information and the method for obtaining the information. 1927 An object identifier is defined for the private extension. The 1928 object identifier associated with the private extension is defined 1929 under the arc id-pe within the id-pkix name space. Any future exten- 1930 sions defined for the Internet PKI will also be defined under the arc 1931 id-pe. 1933 id-pkix OBJECT IDENTIFIER ::= 1934 { iso(1) identified-organization(3) dod(6) internet(1) 1935 security(5) mechanisms(5) pkix(7) } 1937 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 1939 4.2.2.1 Authority Information Access 1941 The authority information access extension indicates how to access CA 1942 information and services for the issuer of the certificate in which 1943 the extension appears. Information and services may include on-line 1944 validation services and CA policy data. (The location of CRLs is not 1945 specified in this extension; that information is provided by the 1946 cRLDistributionPoints extension.) This extension may be included in 1947 subject or CA certificates, and it MUST be non-critical. 1949 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 1951 AuthorityInfoAccessSyntax ::= 1952 SEQUENCE SIZE (1..MAX) OF AccessDescription 1954 AccessDescription ::= SEQUENCE { 1955 accessMethod OBJECT IDENTIFIER, 1956 accessLocation GeneralName } 1958 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 1960 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 1961 Each entry in the sequence AuthorityInfoAccessSyntax describes the 1962 format and location of additional information provided by the CA who 1963 issued the certificate in which this extension appears. The type and 1964 format of the information is specified by the accessMethod field; the 1965 accessLocation field specifies the location of the information. The 1966 retrieval mechanism may be implied by the accessMethod or specified 1967 by accessLocation. 1969 This profile defines one OID for accessMethod. The id-ad-caIssuers 1970 OID is used when the additional information lists CAs that have 1971 issued certificates superior to the CA that issued the certificate 1972 containing this extension. The referenced CA Issuers description is 1973 intended to aid certificate users in the selection of a certification 1974 path that terminates at a point trusted by the certificate user. 1976 When id-ad-caIssuers appears as accessInfoType, the accessLocation 1977 field describes the referenced description server and the access pro- 1978 tocol to obtain the referenced description. The accessLocation field 1979 is defined as a GeneralName, which can take several forms. Where the 1980 information is available via http, ftp, or ldap, accessLocation MUST 1981 be a uniformResourceIdentifier. Where the information is available 1982 via the directory access protocol (dap), accessLocation MUST be a 1983 directoryName. When the information is available via electronic mail, 1984 accessLocation MUST be an rfc822Name. The semantics of other name 1985 forms of accessLocation (when accessMethod is id-ad-caIssuers) are 1986 not defined by this specification. The information 1988 Additional access descriptors may be defined in other PKIX specifica- 1989 tions. 1991 5 CRL and CRL Extensions Profile 1993 As described above, one goal of this X.509 v2 CRL profile is to 1994 foster the creation of an interoperable and reusable Internet PKI. 1995 To achieve this goal, guidelines for the use of extensions are speci- 1996 fied, and some assumptions are made about the nature of information 1997 included in the CRL. 1999 CRLs may be used in a wide range of applications and environments 2000 covering a broad spectrum of interoperability goals and an even 2001 broader spectrum of operational and assurance requirements. This 2002 profile establishes a common baseline for generic applications 2003 requiring broad interoperability. The profile defines a baseline set 2004 of information that can be expected in every CRL. Also, the profile 2005 defines common locations within the CRL for frequently used attri- 2006 butes as well as common representations for these attributes. 2008 This profile does not define any private Internet CRL extensions or 2009 CRL entry extensions. 2011 Environments with additional or special purpose requirements may 2012 build on this profile or may replace it. 2014 Conforming CAs are not required to issue CRLs if other revocation or 2015 certificate status mechanisms are provided. Conforming CAs that 2016 issue CRLs MUST issue version 2 CRLs, and CAs MUST include the date 2017 by which the next CRL will be issued in the nextUpdate field (see 2018 sec. 5.1.2.5), the CRL number extension (see sec. 5.2.3) and the 2019 authority key identifier extension (see sec. 5.2.1). Conforming 2020 applications are required to process version 1 and 2 CRLs. 2022 5.1 CRL Fields 2024 The X.509 v2 CRL syntax is as follows. For signature calculation, 2025 the data that is to be signed is ASN.1 DER encoded. ASN.1 DER encod- 2026 ing is a tag, length, value encoding system for each element. 2028 CertificateList ::= SEQUENCE { 2029 tbsCertList TBSCertList, 2030 signatureAlgorithm AlgorithmIdentifier, 2031 signatureValue BIT STRING } 2033 TBSCertList ::= SEQUENCE { 2034 version Version OPTIONAL, 2035 -- if present, shall be v2 2036 signature AlgorithmIdentifier, 2037 issuer Name, 2038 thisUpdate Time, 2039 nextUpdate Time OPTIONAL, 2040 revokedCertificates SEQUENCE OF SEQUENCE { 2041 userCertificate CertificateSerialNumber, 2042 revocationDate Time, 2043 crlEntryExtensions Extensions OPTIONAL 2044 -- if present, shall be v2 2045 } OPTIONAL, 2046 crlExtensions [0] EXPLICIT Extensions OPTIONAL 2047 -- if present, shall be v2 2048 } 2050 -- Version, Time, CertificateSerialNumber, and Extensions 2051 -- are all defined in the ASN.1 in section 4.1 2053 -- AlgorithmIdentifier is defined in section 4.1.1.2 2055 The following items describe the use of the X.509 v2 CRL in the 2056 Internet PKI. 2058 5.1.1 CertificateList Fields 2060 The CertificateList is a SEQUENCE of three required fields. The 2061 fields are described in detail in the following subsections. 2063 5.1.1.1 tbsCertList 2065 The first field in the sequence is the tbsCertList. This field is 2066 itself a sequence containing the name of the issuer, issue date, 2067 issue date of the next list, the list of revoked certificates, and 2068 optional CRL extensions. Further, each entry on the revoked certifi- 2069 cate list is defined by a sequence of user certificate serial number, 2070 revocation date, and optional CRL entry extensions. 2072 5.1.1.2 signatureAlgorithm 2074 The signatureAlgorithm field contains the algorithm identifier for 2075 the algorithm used by the CA to sign the CertificateList. The field 2076 is of type AlgorithmIdentifier, which is defined in section 4.1.1.2. 2077 Section 7.2 lists the supported algorithms for this specification. 2078 Conforming CAs MUST use the algorithm identifiers presented in sec- 2079 tion 7.2 when signing with a supported signature algorithm. 2081 This field MUST contain the same algorithm identifier as the signa- 2082 ture field in the sequence tbsCertList (see sec. 5.1.2.2). 2084 5.1.1.3 signatureValue 2086 The signatureValue field contains a digital signature computed upon 2087 the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded tbsCertList 2088 is used as the input to the signature function. This signature value 2089 is then ASN.1 encoded as a BIT STRING and included in the CRL's sig- 2090 natureValue field. The details of this process are specified for each 2091 of the supported algorithms in section 7.2. 2093 5.1.2 Certificate List "To Be Signed" 2095 The certificate list to be signed, or TBSCertList, is a SEQUENCE of 2096 required and optional fields. The required fields identify the CRL 2097 issuer, the algorithm used to sign the CRL, the date and time the CRL 2098 was issued, and the date and time by which the CA will issue the next 2099 CRL. 2101 Optional fields include lists of revoked certificates and CRL exten- 2102 sions. The revoked certificate list is optional to support the case 2103 where a CA has not revoked any unexpired certificates that it has 2104 issued. The profile requires conforming CAs to use the CRL extension 2105 cRLNumber in all CRLs issued. 2107 5.1.2.1 Version 2109 This optional field describes the version of the encoded CRL. When 2110 extensions are used, as required by this profile, this field MUST be 2111 present and MUST specify version 2 (the integer value is 1). 2113 5.1.2.2 Signature 2115 This field contains the algorithm identifier for the algorithm used 2116 to sign the CRL. Section 7.2 lists OIDs for the most popular signa- 2117 ture algorithms used in the Internet PKI. 2119 This field MUST contain the same algorithm identifier as the signa- 2120 tureAlgorithm field in the sequence CertificateList (see section 2121 5.1.1.2). 2123 5.1.2.3 Issuer Name 2125 The issuer name identifies the entity who has signed and issued the 2126 CRL. The issuer identity is carried in the issuer name field. Alter- 2127 native name forms may also appear in the issuerAltName extension (see 2128 sec. 5.2.2). The issuer name field MUST contain an X.500 dis- 2129 tinguished name (DN). The issuer name field is defined as the X.501 2130 type Name, and MUST follow the encoding rules for the issuer name 2131 field in the certificate (see sec. 4.1.2.4). 2133 5.1.2.4 This Update 2135 This field indicates the issue date of this CRL. ThisUpdate may be 2136 encoded as UTCTime or GeneralizedTime. 2138 CAs conforming to this profile that issue CRLs MUST encode thisUpdate 2139 as UTCTime for dates through the year 2049. CAs conforming to this 2140 profile that issue CRLs MUST encode thisUpdate as GeneralizedTime for 2141 dates in the year 2050 or later. 2143 Where encoded as UTCTime, thisUpdate MUST be specified and inter- 2144 preted as defined in section 4.1.2.5.1. Where encoded as General- 2145 izedTime, thisUpdate MUST be specified and interpreted as defined in 2146 section 4.1.2.5.2. 2148 5.1.2.5 Next Update 2150 This field indicates the date by which the next CRL will be issued. 2151 The next CRL could be issued before the indicated date, but it will 2152 not be issued any later than the indicated date. CAs SHOULD issue 2153 CRLs with a nextUpdate time equal to or later than all previous CRLs. 2154 nextUpdate may be encoded as UTCTime or GeneralizedTime. 2156 This profile requires inclusion of nextUpdate in all CRLs issued by 2157 conforming CAs. Note that the ASN.1 syntax of TBSCertList describes 2158 this field as OPTIONAL, which is consistent with the ASN.1 structure 2159 defined in [X.509]. The behavior of clients processing CRLs which 2160 omit nextUpdate is not specified by this profile. 2162 CAs conforming to this profile that issue CRLs MUST encode nextUpdate 2163 as UTCTime for dates through the year 2049. CAs conforming to this 2164 profile that issue CRLs MUST encode nextUpdate as GeneralizedTime for 2165 dates in the year 2050 or later. 2167 Where encoded as UTCTime, nextUpdate MUST be specified and inter- 2168 preted as defined in section 4.1.2.5.1. Where encoded as General- 2169 izedTime, nextUpdate MUST be specified and interpreted as defined in 2170 section 4.1.2.5.2. 2172 5.1.2.6 Revoked Certificates 2174 Revoked certificates are listed. The revoked certificates are named 2175 by their serial numbers. Certificates revoked by the CA are uniquely 2176 identified by the certificate serial number. The date on which the 2177 revocation occurred is specified. The time for revocationDate MUST 2178 be expressed as described in section 5.1.2.4. Additional information 2179 may be supplied in CRL entry extensions; CRL entry extensions are 2180 discussed in section 5.3. 2182 5.1.2.7 Extensions 2184 This field may only appear if the version is 2 (see sec. 5.1.2.1). 2185 If present, this field is a SEQUENCE of one or more CRL extensions. 2186 CRL extensions are discussed in section 5.2. 2188 5.2 CRL Extensions 2190 The extensions defined by ANSI X9 and ISO/IEC/ITU for X.509 v2 CRLs 2191 [X.509] [X9.55] provide methods for associating additional attributes 2192 with CRLs. The X.509 v2 CRL format also allows communities to define 2193 private extensions to carry information unique to those communities. 2194 Each extension in a CRL may be designated as critical or non- 2195 critical. A CRL validation MUST fail if it encounters a critical 2196 extension which it does not know how to process. However, an 2197 unrecognized non-critical extension may be ignored. The following 2198 subsections present those extensions used within Internet CRLs. Com- 2199 munities may elect to include extensions in CRLs which are not 2200 defined in this specification. However, caution should be exercised 2201 in adopting any critical extensions in CRLs which might be used in a 2202 general context. 2204 Conforming CAs that issue CRLs are required to include the authority 2205 key identifier (see sec. 5.2.1) and the CRL number (see sec. 5.2.3) 2206 extensions in all CRLs issued. 2208 5.2.1 Authority Key Identifier 2210 The authority key identifier extension provides a means of identify- 2211 ing the public key corresponding to the private key used to sign a 2212 CRL. The identification can be based on either the key identifier 2213 (the subject key identifier in the CRL signer's certificate) or on 2214 the issuer name and serial number. This extension is especially use- 2215 ful where an issuer has more than one signing key, either due to mul- 2216 tiple concurrent key pairs or due to changeover. 2218 Conforming CAs MUST use the key identifier method, and MUST include 2219 this extension in all CRLs issued. 2221 The syntax for this CRL extension is defined in section 4.2.1.1. 2223 5.2.2 Issuer Alternative Name 2225 The issuer alternative names extension allows additional identities 2226 to be associated with the issuer of the CRL. Defined options include 2227 an rfc822 name (electronic mail address), a DNS name, an IP address, 2228 and a URI. Multiple instances of a name and multiple name forms may 2229 be included. Whenever such identities are used, the issuer alterna- 2230 tive name extension MUST be used. 2232 The issuerAltName extension SHOULD NOT be marked critical. 2234 The OID and syntax for this CRL extension are defined in section 2235 4.2.1.8. 2237 5.2.3 CRL Number 2239 The CRL number is a non-critical CRL extension which conveys a mono- 2240 tonically increasing sequence number for each CRL issued by a CA. 2241 This extension allows users to easily determine when a particular CRL 2242 supersedes another CRL. CAs conforming to this profile MUST include 2243 this extension in all CRLs. 2245 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 2247 cRLNumber ::= INTEGER (0..MAX) 2249 5.2.4 Delta CRL Indicator 2251 The delta CRL indicator is a critical CRL extension that identifies a 2252 delta-CRL. The use of delta-CRLs can significantly improve process- 2253 ing time for applications which store revocation information in a 2254 format other than the CRL structure. This allows changes to be added 2255 to the local database while ignoring unchanged information that is 2256 already in the local database. 2258 When a delta-CRL is issued, the CAs MUST also issue a complete CRL. 2260 The value of BaseCRLNumber identifies the CRL number of the base CRL 2261 that was used as the starting point in the generation of this delta- 2262 CRL. The delta-CRL contains the changes between the base CRL and the 2263 current CRL issued along with the delta-CRL. It is the decision of a 2264 CA as to whether to provide delta-CRLs. Again, a delta-CRL MUST NOT 2265 be issued without a corresponding complete CRL. The value of 2266 CRLNumber for both the delta-CRL and the corresponding complete CRL 2267 MUST be identical. 2269 A CRL user constructing a locally held CRL from delta-CRLs MUST con- 2270 sider the constructed CRL incomplete and unusable if the CRLNumber of 2271 the received delta-CRL is more than one greater than the CRLnumber of 2272 the delta-CRL last processed. 2274 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 2276 deltaCRLIndicator ::= BaseCRLNumber 2278 BaseCRLNumber ::= CRLNumber 2280 5.2.5 Issuing Distribution Point 2282 The issuing distribution point is a critical CRL extension that iden- 2283 tifies the CRL distribution point for a particular CRL, and it indi- 2284 cates whether the CRL covers revocation for end entity certificates 2285 only, CA certificates only, or a limitied set of reason codes. 2286 Although the extension is critical, conforming implementations are 2287 not required to support this extension. 2289 The CRL is signed using the CA's private key. CRL Distribution 2290 Points do not have their own key pairs. If the CRL is stored in the 2291 X.500 Directory, it is stored in the Directory entry corresponding to 2292 the CRL distribution point, which may be different than the Directory 2293 entry of the CA. 2295 The reason codes associated with a distribution point shall be speci- 2296 fied in onlySomeReasons. If onlySomeReasons does not appear, the 2297 distribution point shall contain revocations for all reason codes. 2298 CAs may use CRL distribution points to partition the CRL on the basis 2299 of compromise and routine revocation. In this case, the revocations 2300 with reason code keyCompromise (1) and cACompromise (2) appear in one 2301 distribution point, and the revocations with other reason codes 2302 appear in another distribution point. 2304 Where the issuingDistributionPoint extension contains a URL, the fol- 2305 lowing semantics MUST be assumed: the object is a pointer to the most 2306 current CRL issued by this CA. The URI schemes ftp, http, mailto 2307 [RFC1738] and ldap [RFC1778] are defined for this purpose. The URI 2308 MUST be an absolute, not relative, pathname and MUST specify the 2309 host. 2311 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 2313 issuingDistributionPoint ::= SEQUENCE { 2314 distributionPoint [0] DistributionPointName OPTIONAL, 2315 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 2316 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 2317 onlySomeReasons [3] ReasonFlags OPTIONAL, 2318 indirectCRL [4] BOOLEAN DEFAULT FALSE } 2320 5.3 CRL Entry Extensions 2322 The CRL entry extensions already defined by ANSI X9 and ISO/IEC/ITU 2323 for X.509 v2 CRLs provide methods for associating additional attri- 2324 butes with CRL entries [X.509] [X9.55]. The X.509 v2 CRL format also 2325 allows communities to define private CRL entry extensions to carry 2326 information unique to those communities. Each extension in a CRL 2327 entry may be designated as critical or non-critical. A CRL valida- 2328 tion MUST fail if it encounters a critical CRL entry extension which 2329 it does not know how to process. However, an unrecognized non- 2330 critical CRL entry extension may be ignored. The following subsec- 2331 tions present recommended extensions used within Internet CRL entries 2332 and standard locations for information. Communities may elect to use 2333 additional CRL entry extensions; however, caution should be exercised 2334 in adopting any critical extensions in CRL entries which might be 2335 used in a general context. 2337 All CRL entry extensions used in this specification are non-critical. 2338 Support for these extensions is optional for conforming CAs and 2339 applications. However, CAs that issue CRLs SHOULD include reason 2340 codes (see sec. 5.3.1) and invalidity dates (see sec. 5.3.3) whenever 2341 this information is available. 2343 5.3.1 Reason Code 2345 The reasonCode is a non-critical CRL entry extension that identifies 2346 the reason for the certificate revocation. CAs are strongly 2347 encouraged to include meaningful reason codes in CRL entries; how- 2348 ever, the reason code CRL entry extension SHOULD be absent instead of 2349 using the unspecified (0) reasonCode value. 2351 id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 } 2353 -- reasonCode ::= { CRLReason } 2355 CRLReason ::= ENUMERATED { 2356 unspecified (0), 2357 keyCompromise (1), 2358 cACompromise (2), 2359 affiliationChanged (3), 2360 superseded (4), 2361 cessationOfOperation (5), 2362 certificateHold (6), 2363 removeFromCRL (8) } 2365 5.3.2 Hold Instruction Code 2367 The hold instruction code is a non-critical CRL entry extension that 2368 provides a registered instruction identifier which indicates the 2369 action to be taken after encountering a certificate that has been 2370 placed on hold. 2372 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 2374 holdInstructionCode ::= OBJECT IDENTIFIER 2376 The following instruction codes have been defined. Conforming appli- 2377 cations that process this extension MUST recognize the following 2378 instruction codes. 2380 holdInstruction OBJECT IDENTIFIER ::= 2381 { iso(1) member-body(2) us(840) x9-57(10040) 2 } 2383 id-holdinstruction-none OBJECT IDENTIFIER ::= {holdInstruction 1} 2384 id-holdinstruction-callissuer 2385 OBJECT IDENTIFIER ::= {holdInstruction 2} 2386 id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3} 2388 Conforming applications which encounter an id-holdinstruction- 2389 callissuer MUST call the certificate issuer or reject the certifi- 2390 cate. Conforming applications which encounter an id- 2391 holdinstruction-reject MUST reject the certificate. The hold instruc- 2392 tion id-holdinstruction-none is semantically equivalent to the 2393 absence of a holdInstructionCode, and its use is strongly deprecated 2394 for the Internet PKI. 2396 5.3.3 Invalidity Date 2398 The invalidity date is a non-critical CRL entry extension that pro- 2399 vides the date on which it is known or suspected that the private key 2400 was compromised or that the certificate otherwise became invalid. 2401 This date may be earlier than the revocation date in the CRL entry, 2402 which is the date at which the CA processed the revocation. When a 2403 revocation is first posted by a CA in a CRL, the invalidity date may 2404 precede the date of issue of earlier CRLs, but the revocation date 2405 SHOULD NOT precede the date of issue of earlier CRLs. Whenever this 2406 information is available, CAs are strongly encouraged to share it 2407 with CRL users. 2409 The GeneralizedTime values included in this field MUST be expressed 2410 in Greenwich Mean Time (Zulu), and MUST be specified and interpreted 2411 as defined in section 4.1.2.5.2. 2413 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 2415 invalidityDate ::= GeneralizedTime 2417 5.3.4 Certificate Issuer 2419 This CRL entry extension identifies the certificate issuer associated 2420 with an entry in an indirect CRL, i.e. a CRL that has the indirectCRL 2421 indicator set in its issuing distribution point extension. If this 2422 extension is not present on the first entry in an indirect CRL, the 2423 certificate issuer defaults to the CRL issuer. On subsequent entries 2424 in an indirect CRL, if this extension is not present, the certificate 2425 issuer for the entry is the same as that for the preceding entry. 2426 This field is defined as follows: 2428 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } 2430 certificateIssuer ::= GeneralNames 2432 If used by conforming CAs that issue CRLs, this extension is always 2433 critical. If an implementation ignored this extension it could not 2434 correctly attribute CRL entries to certificates. This specification 2435 RECOMMENDS that implementations recognize this extension. 2437 6 Certification Path Validation 2439 Certification path validation procedures for the Internet PKI are 2440 based on section 12.4.3 of [X.509]. Certification path processing 2441 verifies the binding between the subject distinguished name and/or 2442 subject alternative name and subject public key. The binding is lim- 2443 ited by constraints which are specified in the certificates which 2444 comprise the path. The basic constraints and policy constraints 2445 extensions allow the certification path processing logic to automate 2446 the decision making process. 2448 This section describes an algorithm for validating certification 2449 paths. Conforming implementations of this specification are not 2450 required to implement this algorithm, but MUST be functionally 2451 equivalent to the external behavior resulting from this procedure. 2452 Any algorithm may be used by a particular implementation so long as 2453 it derives the correct result. 2455 In section 6.1, the text describes basic path validation. This text 2456 assumes that all valid paths begin with certificates issued by a sin- 2457 gle "most-trusted CA". The algorithm requires the public key of the 2458 CA, the CA's name, the validity period of the public key, and any 2459 constraints upon the set of paths which may be validated using this 2460 key. 2462 The "most-trusted CA" is a matter of policy: it could be a root CA in 2463 a hierarchical PKI; the CA that issued the verifier's own 2464 certificate(s); or any other CA in a network PKI. The path valida- 2465 tion procedure is the same regardless of the choice of "most-trusted 2466 CA." 2468 section 6.2 describes extensions to the basic path validation algo- 2469 rithm. Two specific cases are discussed: the case where paths may 2470 begin with one of several trusted CAs; and where compatibility with 2471 the PEM architecture is required. 2473 6.1 Basic Path Validation 2475 This text describes an algorithm for X.509 path processing. A con- 2476 formant implementation MUST include an X.509 path processing pro- 2477 cedure that is functionally equivalent to the external behavior of 2478 this algorithm. 2480 This text assumes that there is a single trust anchor for certifica- 2481 tion path processing, which simplifies the description of the path 2482 processing procedure. This procedure can be extended to address mul- 2483 tiple trust anchors, as discussed further in Section 6.2. 2485 The primary goal of path validation is to verify the binding between 2486 a subject distinguished name or subject alternative name and subject 2487 public key, as represented in the end entity certificate, based on 2488 the public key of the trust anchor. This requires obtaining a 2489 sequence of certificates that support that binding. The procedure 2490 performed to obtain this sequence of certificates is outside the 2491 scope of this section. 2493 To meet this goal, the path validation process verifies, among other 2494 things, that a prospective certification path (a sequence of n certi- 2495 ficates) satisfies the following conditions: 2496 (i) for all x in {1, ..., n-1}, the subject of certificate x is 2497 the issuer of certificate x+1; 2498 (ii) certificate 1 is issued by the trust anchor; 2499 (iii) certificate n is the end entity certificate; and 2500 (iv) for all x in {1, ..., n}, the certificate was valid at the 2501 time in question. 2503 A particular certification path may not, however, be appropriate for 2504 all applications. The path validation process also determines the 2505 set of certificate policies that are valid for this path, based on 2506 the certificate policies extension, policy mapping extension, policy 2507 constraints extension, and inhibit any-policy extension. To achieve 2508 this, the path validation algorithm constructs a "valid policy tree." 2509 If the set of certificate policies that are valid for this path is 2510 not empty, then the result will be a valid policy tree of depth n, 2511 otherwise the result will be a NULL valid policy tree. 2513 This section presents the algorithm in four basic steps: (1) initial- 2514 ization, (2) basic certificate processing, (3) preparation for the 2515 next certificate, and (4) wrap-up. Steps (1) and (4) are performed 2516 exactly once. Step (2) is performed for all certificates in the 2517 path. Step (3) is performed for all certificates in the path except 2518 the final certificate. Figure 2 provides a high-level flowchart of 2519 this algorithm. 2521 +-------+ 2522 | START | 2523 +-------+ 2524 | 2525 V 2526 +----------------+ 2527 | Initialization | 2528 +----------------+ 2529 | 2530 +<--------------------+ 2531 | | 2532 V | 2533 +----------------+ | 2534 | Process Cert | | 2535 +----------------+ | 2536 | | 2537 V | 2538 +================+ | 2539 | IF Last Cert | | 2540 | in Path | | 2541 +================+ | 2542 | | | 2543 THEN | | ELSE | 2544 V V | 2545 +----------------+ +----------------+ | 2546 | Wrap up | | Prepare for | | 2547 +----------------+ | Next Cert | | 2548 | +----------------+ | 2549 V | | 2550 +-------+ +--------------+ 2551 | STOP | 2552 +-------+ 2554 Figure 2. Path Processing Flowchart 2556 6.1.1 Inputs 2558 This algorithm assumes the following seven inputs are provided to the 2559 path processing logic: 2561 (a) a prospective certification path of length n; 2563 (b) the time, T, for which the validity of the path should be 2564 determined. This may be the current date/time, or some point in 2565 the past. 2567 (c) user_initial_policy_set: A set of certificate policy identif- 2568 iers naming the policies that are acceptable to the certificate 2569 user. The user_initial_policy_set has the special value "any- 2570 policy" if the user is not concerned about certificate policy. 2572 (d) trust anchor information, describing a CA that serves as a 2573 trust anchor for the certification path. The trust anchor infor- 2574 mation includes: 2575 (1) the trusted issuer name, 2576 (2) optionally, the trusted issuer unique identifier, 2577 (3) the trusted public key algorithm, 2578 (4) the trusted public key, and 2579 (5) optionally, the trusted public key parameters associated 2580 with the public key. 2582 The trust anchor information may be provided to the path process- 2583 ing procedure in the form of a self-signed certificate. The 2584 trusted anchor information is trusted because it was delivered to 2585 the path processing procedure by some trustworthy "out-of-band" 2586 procedure. If the trusted public key algorithm requires parame- 2587 ters, then the parameters are provided along with the trusted pub- 2588 lic key. 2590 (e) initial-policy-mapping-inhibit, which indicates if policy map- 2591 ping is allowed in the certification path. 2593 (f) initial-explicit-policy, which indicates if the path must be 2594 valid for at least one of the certificate policies in the 2595 user_initial_policy_set. 2597 (g) initial-any-policy-inhibit, which indicates whether the any- 2598 policy OID should be processed if it is included in a certificate. 2600 6.1.2 Initialization 2602 The initialization phase establishes twelve state variables based 2603 upon the seven inputs: 2605 (a) valid_policy_tree: A tree of certificate policies with their 2606 optional qualifiers; each of the leaves of the tree represents a 2607 valid policy at this stage in the certification path validation. 2608 If valid policies exist at this stage in the certification path 2609 validation, the depth of the tree is equal to the number of certi- 2610 ficates in the chain that have been processed. If valid policies 2611 do not exist at this stage in the certification path validation, 2612 the tree is set to NULL. Once the tree is set to NULL, policy pro- 2613 cessing ceases. 2615 Each node in the valid_policy_tree includes four data objects: the 2616 valid policy, a set of associated policy qualifiers, a set of one 2617 or more expected policy values, and a criticality indicator. If 2618 the node is at depth x, the components of the node have the fol- 2619 lowing semantics: 2620 (i) The valid_policy is a single policy OID representing a 2621 valid policy for the path of length x. 2622 (ii) The qualifier_set is a set of policy qualifiers associated 2623 with the valid policy in certificate x. 2624 (iii) The criticality_indicator indicates whether the certifi- 2625 cate policy extension in certificate x was marked as critical. 2626 (iv) The expected_policy_set contains one or more policy OIDs 2627 that would satisfy this policy in the certificate x+1. 2629 The initial value of the valid_policy_tree is a single node with 2630 valid_policy "any-policy", an empty qualifier_set, an 2631 expected_policy_set with the single value "any-policy", and a 2632 criticality_indicator of FALSE. This node is considered to be at 2633 depth zero. 2635 Figure 3 is a graphic representation of the initial state of the 2636 valid_policy_tree. Additional figures will use this format to 2637 describe changes in the valid_policy_tree during path processing. 2639 +-----------------+ 2640 | "any-policy" | <---- valid_policy 2641 +-----------------+ 2642 | {} | <---- qualifier_set 2643 +-----------------+ 2644 | FALSE | <---- criticality_indicator 2645 +-----------------+ 2646 | {"any-policy"} | <---- expected_policy_set 2647 +-----------------+ 2649 Figure 3. Initial value of the valid_policy_tree state variable 2651 (b) permitted_subtrees: A set of root names for each name type 2652 (e.g., X.500 distinguished names, email addresses, or ip 2653 addresses) defining a set of subtrees within which all subject 2654 names in subsequent certificates in the certification path shall 2655 fall. This variable includes a set for each name type: the initial 2656 value for the set for Distinguished Names is the set of all Dis- 2657 tinguished names; the initial value for the set of RFC822 names is 2658 the set of all RFC822 names, etc. 2660 (c) excluded_subtrees: A set of root names for each name type 2661 (e.g., X.500 distinguished names, email addresses, or ip 2662 addresses) defining a set of subtrees within which no subject name 2663 in subsequent certificates in the certification path may fall. 2664 This variable includes a set for each name type, and the initial 2665 value for each set is "empty". 2667 (d) explicit_policy: an integer which indicates if a non-NULL 2668 valid_policy_tree is required. The integer indicates the number of 2669 non-self-issued certificates to be processed before this require- 2670 ment is imposed. Once set, this variable may be decreased, but may 2671 not be increased. That is, if a certificate in the path requires a 2672 non-NULL valid_policy_tree, a later certificate can not remove 2673 this requirement. If initial-explicit-policy is set, then the ini- 2674 tial value is 0, otherwise the initial value is n+1. 2676 (e) inhibit_any-policy: an integer which indicates whether the 2677 "any-policy" policy identifier is considered a match. The integer 2678 indicates the number of non-self-issued certificates to be pro- 2679 cessed before the "any-policy" OID, if asserted in a certificate, 2680 is ignored. Once set, this variable may be decreased, but may not 2681 be increased. That is, if a certificate in the path inhibits pro- 2682 cessing of "any-policy", a later certificate can not permit it. If 2683 initial-any-policy-inhibit is set, then the initial value is 0, 2684 otherwise the initial value is n+1. 2686 (f) policy_mapping: an integer which indicates if policy mapping 2687 is permitted. The integer indicates the number of non-self-issued 2688 certificates to be processed before policy mapping is inhibited. 2689 Once set, this variable may be decreased, but may not be 2690 increased. That is, if a certificate in the path specifies policy 2691 mapping is not permitted, it can not be overridden by a later cer- 2692 tificate. If initial-policy-mapping-inhibit is set, then the ini- 2693 tial value is 0, otherwise the initial value is n+1. 2695 (g) working_public_key_algorithm: the digital signature algorithm 2696 used to verify the signature of a certificate. The 2697 working_public_key_algorithm is initialized from the trusted pub- 2698 lic key algorithm provided in the trust anchor information. 2700 (h) working_public_key: the public key used to verify the signa- 2701 ture of a certificate. The working_public_key is initialized from 2702 the trusted public key provided in the trust anchor information. 2704 (i) working_public_key_parameters: parameters associated with the 2705 current public key, that may required to verify a signature 2706 (depending upon the algorithm). The working_public_key_parameters 2707 variable is initialized from the trusted public key parameters 2708 provided in the trust anchor information. 2710 (j) working_issuer_name: the issuer distinguished name expected 2711 in the next certificate in the chain. The working_issuer_name is 2712 initialized to the trusted issuer provided in the trust anchor 2713 information. 2715 (k) working_issuer_UID: a distinguished name may be associated 2716 with an optional unique identifier. The working_issuer_UID is the 2717 unique identifier that is expected in the next certificate, or the 2718 value NULL. The working_issuer_UID is initialized to the trusted 2719 issuer's unique identifier provided in the trust anchor informa- 2720 tion. 2722 (l) max_path_length: this integer is initialized to n, and is 2723 reset by the path length constraint field within the basic con- 2724 straints extension of a CA certificate. 2726 Upon completion of the initialization steps, perform the basic certi- 2727 ficate processing steps specified in 6.1.3. 2729 6.1.3 Basic Certificate Processing 2731 The basic path processing actions to be performed for certificate i 2732 are listed below. 2734 (a) Verify the basic certificate information. The certificate 2735 must satisfy each of the following: 2737 (1) The certificate was signed with the 2738 working_public_key_algorithm using the working_public_key and 2739 the working_public_key_parameters. 2741 (2) The certificate validity period includes time T. 2743 (3) At time T, the certificate is not revoked and is not on 2744 hold status. This may be determined by obtaining the appropri- 2745 ate CRL (see section 6.4), status information, or by out-of- 2746 band mechanisms. 2748 (4) The certificate issuer name is the working_issuer_name. 2750 (5) The certificate issuer unique identifier is the 2751 working_issuer_UID, meaning: 2752 (i) working_issuer_UID is non-null and matches the value in 2753 the issuerUID field, or 2754 (ii) working_issuer_UID is null and the issuerUID field is 2755 not present. 2757 (b) If certificate i is not self-issued, verify that the subject 2758 name is within one of the permitted_subtrees for X.500 dis- 2759 tinguished names, and verify that each of the alternative names in 2760 the subjectAltName extension (critical or non-critical) is within 2761 one of the permitted_subtrees for that name type. 2763 (c) If certificate i is not self-issued, verify that the subject 2764 name is not within one of the excluded_subtrees for X.500 dis- 2765 tinguished names, and verify that each of the alternative names in 2766 the subjectAltName extension (critical or non-critical) is not 2767 within one of the excluded_subtrees for that name type. 2769 (d) If the certificate policies extension is present in the certi- 2770 ficiate and the valid_policy_tree is not NULL, process the policy 2771 information by performing the following steps in order: 2773 (1) For each policy P not equal to "any-policy" in the certifi- 2774 cate policies extension, let P-OID denote the OID in policy P 2775 and P-Q denote the qualifier set for policy P. Perform the 2776 following steps in order: 2778 (i) If the valid_policy_tree includes a node of depth i-1 2779 where P-OID is in the expected_policy_set, create a child 2780 node as follows: set the valid_policy to OID- P; set the 2781 qualifier_set to P-Q, and set the expected_policy_set to 2782 {P-OID}. 2784 For example, consider a valid_policy_tree with a node of 2785 depth i-1 where the expected_policy_set is {Gold, White}. 2786 Assume the certificate policies Gold and Silver appear in 2787 the certificate policies extension of certificate i. The 2788 Gold policy is matched but the Silver policy is not. This 2789 rule will generate a child node of depth i for the Gold pol- 2790 icy. The result is shown as Figure 4. 2792 |-----------------| 2793 | Red | 2794 |-----------------| 2795 | {} | 2796 |-----------------| node of depth i-1 2797 | FALSE | 2798 |-----------------| 2799 | {Gold, White} | 2800 |-----------------| 2801 | 2802 | 2803 | 2804 V 2805 |-----------------| 2806 | Gold | 2807 |-----------------| 2808 | {} | 2809 |-----------------| node of depth i 2810 | uninitialized | 2811 |-----------------| 2812 | {Gold} | 2813 |-----------------| 2815 Figure 4. Processing an exact match 2817 (ii) If there was no match in step (i) and the 2818 valid_policy_tree includes a node of depth i-1 with the 2819 valid policy "any-policy", generate a child node with the 2820 following values: set the valid_policy to P-OID; set the 2821 qualifier_set to P-Q, and set the expected_policy_set to 2822 {P-OID}. 2824 For example, consider a valid_policy_tree with a node of 2825 depth i-1 where the valid_policy is "any-policy". Assume the 2826 certificate policies Gold and Silver appear in the certifi- 2827 cate policies extension of certificate i. The Gold policy 2828 does not have a qualifier, but the Silver policy has the 2829 qualifier Q-Silver. If Gold and Silver were not matched in 2830 (i) above, this rule will generate two child nodes of depth 2831 i, one for each policy. The result is shown as Figure 5. 2833 |-----------------| 2834 | "any-policy" | 2835 |-----------------| 2836 | {} | 2837 |-----------------| node of depth i-1 2838 | FALSE | 2839 |-----------------| 2840 | {"any-policy"} | 2841 |-----------------| 2842 / \ 2843 / \ 2844 / \ 2845 / \ 2846 |-----------------| |-----------------| 2847 | Gold | | Silver | 2848 |-----------------| |-----------------| 2849 | {} | | {Q-Silver} | 2850 |-----------------| nodes of |-----------------| 2851 | uninitialized | depth i | uninitialized | 2852 |-----------------| |-----------------| 2853 | {Gold} | | {Silver} | 2854 |-----------------| |-----------------| 2856 Figure 5. Processing unmatched policies when a leaf node 2857 specifies "any-policy" 2859 (2) If the certificate policies extension includes the pol- 2860 icy "any-policy" with the qualifier set AP-Q and 2861 inhibit_any-policy is greater than 0, then: 2863 For each node in the valid_policy_tree of depth i-1, for 2864 each value in the expected_policy_set (including "any- 2865 policy") that does not appear in a child node, create a 2866 child node with the following values: set the valid_policy 2867 to the value from the expected_policy_set in the parent 2868 node; set the qualifier_set to AP-Q, and set the 2869 expected_policy_set to the value in the valid_policy from 2870 this node. 2872 For example, consider a valid_policy_tree with a node of 2873 depth i-1 where the expected_policy_set = {Gold, Silver}. 2874 Assume "any-policy" appears in the certificate policies 2875 extension of certificate i, but Gold and Silver do not. 2876 This rule will generate two child nodes of depth i, one for 2877 each policy. The result is shown below as Figure 6. 2879 |-----------------| 2880 | Red | 2881 |-----------------| 2882 | {} | 2883 |-----------------| node of depth i-1 2884 | FALSE | 2885 |-----------------| 2886 | {Gold, Silver} | 2887 |-----------------| 2888 / \ 2889 / \ 2890 / \ 2891 / \ 2892 |-----------------| |-----------------| 2893 | Gold | | Silver | 2894 |-----------------| |-----------------| 2895 | {} | | {} | 2896 |-----------------| nodes of |-----------------| 2897 | uninitialized | depth i | uninitialized | 2898 |-----------------| |-----------------| 2899 | {Gold} | | {Silver} | 2900 |-----------------| |-----------------| 2902 Figure 6. Processing unmatched policies when the certificate 2903 policies extension specifies "any-policy" 2905 (3) If there is a node in the valid_policy_tree of depth i-1 2906 or less without any child nodes, delete that node. Repeat 2907 this step until there are no nodes of depth i-1 or less 2908 without children. 2910 For example, consider the valid_policy_tree shown in Figure 2911 7 below. The two nodes at depth i-1 that are marked with an 2912 to the resulting tree will cause the node at depth i-2 that 2913 is marked with an 'Y' to be deleted. The following applica- 2914 tion of the rule does not cause any nodes to be deleted, and 2915 this step is complete. 2917 +-----------+ 2918 | | node of depth i-3 2919 +-----------+ 2920 / | \ 2921 / | \ 2922 / | \ 2923 / | \ 2924 +-----------+ +-----------+ +-----------+ 2925 | | | | | Y | nodes of 2926 +-----------+ +-----------+ +-----------+ depth i-2 2927 / \ \ \ 2928 / \ \ \ 2929 +-----------+ +-----------+ +-----------+ +-----------+ nodes of 2930 | | | X | | | | X | depth 2931 +-----------+ +-----------+ +-----------+ +-----------+ i-1 2932 | / | \ 2933 | / | \ 2934 | / | \ 2935 +-----------+ +-----------+ +-----------+ +-----------+ nodes of 2936 | | | | | | | | depth 2937 +-----------+ +-----------+ +-----------+ +-----------+ i 2939 Figure 7. Pruning the valid_policy_tree 2941 (4) If the certificate policies extension was marked as criti- 2942 cal, set the criticality_indicator in all nodes of depth i to 2943 TRUE. If the certificate policies extension was not marked 2944 critical, set the criticality_indicator in all nodes of depth i 2945 to FALSE. 2947 (e) If the certificate policies extension is not present, set the 2948 valid_policy_tree to NULL. 2950 (f) verify that either explicit_policy is greater than 0 or the 2951 valid_policy_tree is not equal to NULL; 2953 If any of steps (a), (b), (c), or (f) fails, the procedure ter- 2954 minates, returning a failure indication and an appropriate reason. 2956 If i is not equal to n, continue by performing the preparatory steps 2957 listed in 6.1.4. If i is equal to n, perform the wrap-up steps 2958 listed in 6.1.5. 2960 6.1.4 Preparation for Certificate i+1 2962 To prepare for processing of certificate i+1, perform the following 2963 steps for certificate i: 2965 (a) If a policy mapping extension is present, verify that the spe- 2966 cial value "any-policy" does not appear as an issuerDomainPolicy 2967 or a subjectDomainPolicy. 2969 (b) If a policy mapping extension is present, then for each 2970 issuerDomainPolicy ID-P in the policy mapping extension: 2972 (1) If the policy_mapping variable is greater than 0, for each 2973 node in the valid_policy_tree of depth i where ID-P is the 2974 valid_policy, set expected_policy_set to the set of sub- 2975 jectDomainPolicy values that are specified as equivalent to 2976 ID-P by the policy mapping extension. 2978 (2) If the policy_mapping variable is equal to 0: 2980 (i) delete each node of depth i in the valid_policy_tree 2981 where ID-P is the valid_policy. 2982 (ii) If there is a node in the valid_policy_tree of depth 2983 i-1 or less without any child nodes, delete that node. 2984 Repeat this step until there are no nodes of depth i-1 or 2985 less without children. 2987 (c) Assign the certificate subject name to working_issuer_name. 2989 (d) Assign the certificate subjectPublicKey to working_public_key. 2991 (e) If the subjectPublicKeyInfo field of the certificate contains 2992 an algorithm field with non-null parameters, assign the parameters 2993 to the working_public_key_parameters variable. 2995 If the subjectPublicKeyInfo field of the certificate contains an 2996 algorithm field with null parameters, compare the certificate sub- 2997 jectPublicKey algorithm to the working_public_key_algorithm. If 2998 the certificate subjectPublicKey algorithm and the 2999 working_public_key_algorithm are different, set the 3000 working_public_key_parameters to null. 3002 (f) Assign the certificate subjectPublicKey algorithm to the 3003 working_public_key_algorithm variable. 3005 (g) If a name constraints extension is included in the certifi- 3006 cate, modify the permitted_subtrees and excluded_subtrees state 3007 variables as follows: 3009 (1) If permittedSubtrees is present in the certificate, set the 3010 permitted_subtrees state variable to the intersection of its 3011 previous value and the value indicated in the extension field. If 3012 permittedSubtrees does not include a particular name type, the 3013 permitted_subtrees state variable is unchanged for that name type. 3015 (2) If excludedSubtrees is present in the certificate, set the 3016 excluded_subtrees state variable to the union of its previous 3017 value and the value indicated in the extension field. If exclu- 3018 dedSubtrees does not include a particular name type, the 3019 excluded_subtrees state variable is unchanged for that name type. 3021 (h) If the issuer and subject names are not identical: 3023 (1) If explicit_policy is not 0, decrement explicit_policy by 3024 1. 3026 (2) If policy_mapping is not 0, decrement policy_mapping by 1. 3028 (3) If inhibit_any-policy is not 0, decrement inhibit_any- pol- 3029 icy by 1. 3031 (i) If a policy constraints extension is included in the certifi- 3032 cate, modify the explicit_policy and policy_mapping state vari- 3033 ables as follows: 3035 (1) If requireExplicitPolicy is present and is less than 3036 explicit_policy, set explicit_policy to the value of requireEx- 3037 plicitPolicy. 3039 (2) If inhibitPolicyMapping is present and is less than 3040 policy_mapping, set policy_mapping to the value of inhibitPoli- 3041 cyMapping. 3043 (j) If the inhibitAnyPolicy extension is included in the certifi- 3044 cate and is less than inhibit_any-policy, set inhibit_any- policy 3045 to the value of inhibitAnyPolicy. 3047 (k) Verify that the certificate is a CA certificate (as specified 3048 in a basicConstraints extension or as verified out-of-band). 3050 (l) If the certificate was not self-issued, verify that 3051 max_path_length is greater than zero and decrement max_path_length 3052 by 1. 3054 (m) If pathLengthConstraint is present in the certificate and is 3055 less than max_path_length, set max_path_length to the value of 3056 pathLengthConstraint. 3058 (n) If a key usage extension is present and marked critical, 3059 verify that the keyCertSign bit is set. 3061 (o) Recognize and process any other critical extension present in 3062 the certificate. 3064 If check (a), (k), (l), (n) or (o) fails, the procedure terminates, 3065 returning a failure indication and an appropriate reason. 3067 If (a), (k), (l), (n) and (o) have completed successfully, increment 3068 i and perform the basic certificate processing specified in 6.1.2. 3070 6.1.5 Wrap-up procedure 3072 To complete the processing of the end entity certificate, perform the 3073 following steps for certificate n: 3075 (a) If certificate n was not self-issued and explicit_policy is 3076 not 0, decrement explicit_policy by 1. 3078 (b) If a policy constraints extension is included in the certifi- 3079 cate and requireExplicitPolicy is present and has a value of 0, 3080 set the explicit_policy state variable to 0. 3082 (c) Assign the certificate subjectPublicKey to working_public_key. 3084 (d) If the subjectPublicKeyInfo field of the certificate contains 3085 an algorithm field with non-null parameters, assign the parameters 3086 to the working_public_key_parameters variable. 3088 (e) Assign the certificate subjectPublicKey algorithm to the 3089 working_public_key_algorithm variable. 3091 (f) Recognize and process any other critical extension present in 3092 the certificate n. 3094 (g) Calculate the intersection of the valid_policy_tree and the 3095 user_initial_policy_set, as follows: 3097 (i) If the valid_policy_tree is NULL, the intersection is NULL. 3099 (ii) If the valid_policy_tree is not NULL and the 3100 user_initial_policy_set is "any-policy", the intersection is 3101 the entire valid_policy_tree. 3103 (iii) If the valid_policy_tree is not NULL and the 3104 user_initial_policy_set is not "any-policy", calculate the 3105 intersection of the valid_policy_tree and the 3106 user_initial_policy_set as follows: 3108 1. Determine the set of policy nodes whose parent nodes have 3109 a valid_policy of "any-policy". This is the 3110 valid_policy_node_set. 3111 2. If the valid_policy of any node in the 3112 valid_policy_node_set is not in the user_initial_policy_set 3113 and is not "any-policy", delete this node and all its chil- 3114 dren. 3115 3. If there is a node in the valid_policy_tree of depth n-1 3116 or less without any child nodes, delete that node. Repeat 3117 this step until there are no nodes of depth n-1 or less 3118 without children. 3120 Upon completion of all steps, path processing has succeeded if the 3121 value of explicit_policy variable is greater than zero, or the 3122 valid_policy_tree is not NULL. 3124 6.1.6 Outputs 3126 If path processing succeeds, the procedure terminates, returning a 3127 success indication together with final value of the 3128 valid_policy_tree, the working_public_key, the 3129 working_public_key_algorithm, and the working_public_key_parameters. 3131 6.2 Extending Path Validation 3133 The path validation algorithm presented in 6.1 is based on several 3134 simplifying assumptions (e.g., a single trusted CA that starts all 3135 valid paths). This algorithm may be extended for cases where the 3136 assumptions do not hold. 3138 This procedure may be extended for multiple trusted CAs by providing 3139 a set of self-signed certificates to the validation module. In this 3140 case, a valid path could begin with any one of the self-signed certi- 3141 ficates. Limitations in the trust paths for any particular key may 3142 be incorporated into the self-signed certificate's extensions. In 3143 this way, the self-signed certificates permit the path validation 3144 module to automatically incorporate local security policy and 3145 requirements. 3147 It is also possible to specify an extended version of the above cer- 3148 tification path processing procedure which results in default 3149 behavior identical to the rules of PEM [RFC 1422]. In this extended 3150 version, additional inputs to the procedure are a list of one or more 3151 Policy Certification Authorities (PCAs) names and an indicator of the 3152 position in the certification path where the PCA is expected. At the 3153 nominated PCA position, the CA name is compared against this list. 3154 If a recognized PCA name is found, then a constraint of Subordina- 3155 teToCA is implicitly assumed for the remainder of the certification 3156 path and processing continues. If no valid PCA name is found, and if 3157 the certification path cannot be validated on the basis of identified 3158 policies, then the certification path is considered invalid. 3160 6.3 CRL Validation 3162 This section augments section 6.1, Basic Path Validation. In that 3163 section 6.1.3, Basic Certificate Processing, each certificate i must 3164 satisfy the condition (a), (3): "At time T, the certificate is not 3165 revoked and is not on hold status." Section 6.1 is independent of 3166 the mechanism(s) used to verify certificate status. This section 3167 describes the inputs, state variables, and processing steps required 3168 to perform 6.1 using CRLs. 3170 The section is organized in parallel with section 6.1. Section 6.3.1 3171 supplements section 6.1.1, and so on. There are no sections 6.3.5 or 3172 6.3.6; this section does not modify the wrap-up procedure or output 3173 procedure of path validation. 3175 6.3.1 Revocation Inputs 3177 To support revocation processing, the algorithm requires the intro- 3178 duction of three additional state variables: 3180 (h) which-reasons: This input contains the set of reasons for 3181 revocation that are of interest, or the special value "any- 3182 reason." The legal members of the set are the possible values for 3183 reasonflags: keyCompromise; caCompromise; affiliationChanged; 3184 superseded; cessationOfOperation; and certificateHold. 3186 (i) required-freshness: This input defines the oldest acceptable 3187 revocation data. This input is a relative time, or the special 3188 value "best available". 3190 (j) current-time: This input specifies the current date and time. 3192 6.3.2 Initialization and Revocation State Variables 3194 To support CRL processing, the algorithm requires five new state 3195 variables: 3197 (m) CRL_sign_flag: This flag indicates that the previous certifi- 3198 cate in the path can be used to validate the signature on a CRL. 3199 (This is true if the certificate was a CA certificate and either 3200 (a) the keyUsage extension did not appear or (b) the key usage 3201 extension asserted the cRLSign bit.) The initial value of this 3202 variable is TRUE. 3204 (n) possible_CRLs: This variable contains the set of prospective 3205 CRLs that may be useful for verifying the status of this certifi- 3206 cate. 3208 (o) approved_CRLs: This variable contains the set of CRLs that may 3209 be used to verify the status of this certificate. The initial 3210 value for this variable is "empty." 3212 (p) oldest_CRL: This constant specifies the earliest acceptable 3213 issue date for a CRL. It is set to the value current-time minus 3214 required-freshness. If required_freshness is "best_available", 3215 oldest_CRL is set to the issue date of certificate i. 3217 (q) approved_reasons: This variable contains the set of revocation 3218 reasons supported by the approved_CRLs. This variable is initial- 3219 ized to the empty set. 3221 6.3.3 Basic Certificate Processing 3223 This algorithm attempts to satisfy the requirements using CRLs that 3224 can be validated using certificate i-1. Such CRLs are most efficient 3225 to process, since no additional certification paths need be pro- 3226 cessed. If this cannot be achieved, other CRLs issued by the 3227 working_issuer_name and indirect CRLs are added. In both cases, 3228 additional certification paths must be constructed and validated. 3230 In the second step, this algorithm determines if the certificate 3231 should be accepted or rejected. 3233 Step 1. 3235 (a) For each CRL in possible_CRLs, verify that the issuer name is 3236 the working_issuer_name or that certificate i contains a distribu- 3237 tion points extension and the issuer name is specified a cRLIssuer 3238 field. 3240 (b) For each CRL X in possible_CRLs, perform the following steps: 3242 (1) Verify that the value of the thisUpdate field is equal to 3243 or after oldest_CRL. (2) If the required_freshness is "best 3244 available", verify that the value of the nextUpdate field is 3245 after current-time. 3247 (3) If the CRL includes an issuing distribution point exten- 3248 sion, and the onlySomeReasons field is present, verify that the 3249 intersection of onlySomeReasons and which-reasons is not empty. 3251 (4) If the CRL includes an issuing distribution point 3252 extension, and the onlyContainsUserCerts is asserted, verify 3253 that certificate i is not a CA certificate. 3255 (5) If the CRL includes an issuing distribution point exten- 3256 sion, and the onlyContainsCACerts is asserted, verify that cer- 3257 tificate i is a CA certificate. 3259 If any of the checks (1), (2), (3), (4) or (5) fail, delete CRL X 3260 from possible_CRLs. 3262 (b) If CRL_sign_flag is TRUE, repeat the following steps until 3263 approved the approved_reasons = "all reasons" or approved_reasons 3264 is a superset of which_reasons or possible_CRLs is exhausted: 3266 (1) For each CRL X in possible_CRLs that was issued by the 3267 working_issuer_name and signed with the 3268 working_public_key_algorithm using the working_public_key and 3269 working_public_key_parameters: 3271 (i) Delete CRL X from possible_CRLs and add it to 3272 approved_CRLs. 3274 (ii) If CRL X did not include an issuing distribution point 3275 extension, or the onlySomeReasons field was not present in 3276 that extension, set approved_reasons to "all_reasons." If 3277 CRL X includes an issuing distribution point extension, and 3278 the onlySomeReasons field is present, assign 3279 approved_reasons the intersection of approved reasons and 3280 the onlySomeReasons field. 3282 If approved_reasons is "all reasons", or is a superset of 3283 which-reasons, go to step 2. 3285 (c) For each CRL X in possible_CRLs: 3287 (1) If CRL X is valid for all reasons, or the intersection of 3288 onlySomeReasons and which-reasons is not a subset of 3289 approved_reasons and you can construct and validate a certifi- 3290 cation path where cRLSigning is assserted in certificate n-1 or 3291 the key usage extension is omitted from certificate n-1. These 3292 paths may use certificate i-1 to specify the trust anchor. 3293 (The path from the normal trust anchor through certificate i-1 3294 has already been validated at this stage in the algorithm in 3295 Section 6.1) 3297 (i) Add CRL X to approved_CRLs. 3299 (ii) If CRL X did not include an issuing distribution point 3300 extension, or the onlySomeReasons field was not present in 3301 that extension, set approved_reasons to "all_reasons." If 3302 CRL X includes an issuing distribution point extension, and 3303 the onlySomeReasons field is present, assign 3304 approved_reasons the intersection of approved reasons and 3305 the onlySomeReasons field. 3307 If approved_reasons is "all reasons", or is a superset of 3308 which-reasons, go to step 2. 3310 (2) If such a path cannot be constructed or it doesn't add 3311 value, delete it from the possible_CRLs. 3313 (d) If approved_reasons is still not a superset of which-reasons, 3314 reject the certificate due to insufficient information. 3316 Step 2. 3318 Determine if certificate i is on any of the CRLs. If the certifi- 3319 cate is listed as certificatehold on one CRL and revoked on 3320 another, ignore the certificatehold. If the reasonCode is in 3321 which-reasons, the certificate must be rejected. If the certifi- 3322 cate is not on any of the CRLs, or the reasonCode is not in 3323 which-reasons, the certificate is accepted. 3325 6.3.4 Preparation for Certificate i+1 3327 Add the following four steps to the steps in section 6.1.X: 3329 (p) If certificate i does not include the key usage extenion, or 3330 the key usage extension asserts the value cRLSigning, set 3331 CRL_sign_flag to TRUE, otherwise set CRL_sign_flag to FALSE. 3333 (q) Set possible_CRLs to the empty set. 3335 (r) Set approved_CRLs to the empty set. 3337 (s) Set approved_reasons to the empty set. 3339 7 Algorithm Support 3341 This section describes cryptographic algorithms which may be used 3342 with this profile. The section describes one-way hash functions and 3343 digital signature algorithms which may be used to sign certificates 3344 and CRLs, and identifies OIDs for public keys contained in a certifi- 3345 cate. 3347 Conforming CAs and applications are not required to support the 3348 algorithms or algorithm identifiers described in this section. How- 3349 ever, conforming CAs and applications that use the algorithms identi- 3350 fied here MUST support them as specified. 3352 7.1 One-way Hash Functions 3354 This section identifies one-way hash functions for use in the Inter- 3355 net PKI. One-way hash functions are also called message digest algo- 3356 rithms. SHA-1 is the preferred one-way hash function for the Internet 3357 PKI. However, PEM uses MD2 for certificates [RFC 1422] [RFC 1423] 3358 and MD5 is used in other legacy applications. For this reason, MD2 3359 and MD5 are included in this profile. 3361 7.1.1 MD2 One-way Hash Function 3363 MD2 was developed by Ron Rivest for RSA Data Security. RSA Data Secu- 3364 rity has not placed the MD2 algorithm in the public domain. Rather, 3365 RSA Data Security has granted license to use MD2 for non-commercial 3366 Internet Privacy-Enhanced Mail. For this reason, MD2 may continue to 3367 be used with PEM certificates, but SHA-1 is preferred. MD2 produces 3368 a 128-bit "hash" of the input. MD2 is fully described in RFC 1319 3369 [RFC 1319]. 3371 At the Selected Areas in Cryptography '95 conference in May 1995, 3372 Rogier and Chauvaud presented an attack on MD2 that can nearly find 3373 collisions [RC95]. Collisions occur when one can find two different 3374 messages that generate the same message digest. A checksum operation 3375 in MD2 is the only remaining obstacle to the success of the attack. 3376 For this reason, the use of MD2 for new applications is discouraged. 3377 It is still reasonable to use MD2 to verify existing signatures, as 3378 the ability to find collisions in MD2 does not enable an attacker to 3379 find new messages having a previously computed hash value. 3381 7.1.2 MD5 One-way Hash Function 3383 MD5 was developed by Ron Rivest for RSA Data Security. RSA Data Secu- 3384 rity has placed the MD5 algorithm in the public domain. MD5 produces 3385 a 128-bit "hash" of the input. MD5 is fully described in RFC 1321 3386 [RFC 1321]. 3388 Den Boer and Bosselaers [DB94] have found pseudo-collisions for MD5, 3389 but there are no other known cryptanalytic results. The use of MD5 3390 for new applications is discouraged. It is still reasonable to use 3391 MD5 to verify existing signatures. 3393 7.1.3 SHA-1 One-way Hash Function 3395 SHA-1 was developed by the U.S. Government. SHA-1 produces a 160-bit 3396 "hash" of the input. SHA-1 is fully described in FIPS 180-1 [FIPS 3397 180-1]. 3399 SHA-1 is the one-way hash function of choice for use with both the 3400 RSA and DSA signature algorithms (see sec. 7.2). 3402 7.2 Signature Algorithms 3404 Certificates and CRLs described by this standard may be signed with 3405 any public key signature algorithm. The certificate or CRL indicates 3406 the algorithm through an algorithm identifier which appears in the 3407 signatureAlgorithm field in a Certificate or CertificateList. This 3408 algorithm identifier is an OID and has optionally associated parame- 3409 ters. This section identifies algorithm identifiers and parameters 3410 that shall be used in the signatureAlgorithm field in a Certificate 3411 or CertificateList. 3413 RSA and DSA are the most popular signature algorithms used in the 3414 Internet. Signature algorithms are always used in conjunction with a 3415 one-way hash function identified in section 7.1. 3417 The signature algorithm and one-way hash function used to sign a cer- 3418 tificate or CRL is indicated by use of an algorithm identifier. An 3419 algorithm identifier is an OID, and may include associated parame- 3420 ters. This section identifies OIDS for RSA and DSA. The contents of 3421 the parameters component for each algorithm vary; details are pro- 3422 vided for each algorithm. 3424 The data to be signed (e.g., the one-way hash function output value) 3425 is formatted for the signature algorithm to be used. Then, a private 3426 key operation (e.g., RSA encryption) is performed to generate the 3427 signature value. This signature value is then ASN.1 encoded as a BIT 3428 STRING and included in the Certificate or CertificateList in the sig- 3429 nature field. 3431 7.2.1 RSA Signature Algorithm 3433 A patent statement regarding the RSA algorithm can be found at the 3434 end of this profile. 3436 The RSA algorithm is named for its inventors: Rivest, Shamir, and 3437 Adleman. This profile includes three signature algorithms based on 3438 the RSA asymmetric encryption algorithm. The signature algorithms 3439 combine RSA with either the MD2, MD5, or the SHA-1 one-way hash func- 3440 tions. 3442 The signature algorithm with MD2 and the RSA encryption algorithm is 3443 defined in PKCS #1 [RFC 2313]. As defined in RFC 2313, the ASN.1 OID 3444 used to identify this signature algorithm is: 3446 md2WithRSAEncryption OBJECT IDENTIFIER ::= { 3447 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 3448 pkcs-1(1) 2 } 3450 The signature algorithm with MD5 and the RSA encryption algorithm is 3451 defined in PKCS #1 [RFC 2313]. As defined in RFC 2313, the ASN.1 OID 3452 used to identify this signature algorithm is: 3454 md5WithRSAEncryption OBJECT IDENTIFIER ::= { 3455 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 3456 pkcs-1(1) 4 } 3458 The signature algorithm with SHA-1 and the RSA encryption algorithm 3459 is implemented using the padding and encoding conventions described 3460 in PKCS #1 [RFC 2313]. The message digest is computed using the SHA-1 3461 hash algorithm. The ASN.1 object identifier used to identify this 3462 signature algorithm is: 3464 sha-1WithRSAEncryption OBJECT IDENTIFIER ::= { 3465 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 3466 pkcs-1(1) 5 } 3468 When any of these three OIDs appears within the ASN.1 type Algorith- 3469 mIdentifier, the parameters component of that type shall be the ASN.1 3470 type NULL. 3472 The RSA signature generation process and the encoding of the result 3473 is described in detail in RFC 2313. 3475 7.2.2 DSA Signature Algorithm 3477 A patent statement regarding the DSA can be found at the end of this 3478 profile. 3480 The Digital Signature Algorithm (DSA) is also called the Digital Sig- 3481 nature Standard (DSS). DSA was developed by the U.S. Government, and 3482 DSA is used in conjunction with the the SHA-1 one-way hash function. 3483 DSA is fully described in FIPS 186 [FIPS 186]. The ASN.1 OIDs used 3484 to identify this signature algorithm are: 3486 id-dsa-with-sha1 ID ::= { 3487 iso(1) member-body(2) us(840) x9-57 (10040) 3488 x9cm(4) 3 } 3490 Where the id-dsa-with-sha1 algorithm identifier appears as the algo- 3491 rithm field in an AlgorithmIdentifier, the encoding shall omit the 3492 parameters field. That is, the AlgorithmIdentifier shall be a 3493 SEQUENCE of one component - the OBJECT IDENTIFIER id-dsa-with-sha1. 3495 The DSA parameters in the subjectPublicKeyInfo field of the certifi- 3496 cate of the issuer shall apply to the verification of the signature. 3498 When signing, the DSA algorithm generates two values. These values 3499 are commonly referred to as r and s. To easily transfer these two 3500 values as one signature, they shall be ASN.1 encoded using the fol- 3501 lowing ASN.1 structure: 3503 Dss-Sig-Value ::= SEQUENCE { 3504 r INTEGER, 3505 s INTEGER } 3507 7.3 Subject Public Key Algorithms 3509 Certificates described by this profile may convey a public key for 3510 any public key algorithm. The certificate indicates the algorithm 3511 through an algorithm identifier. This algorithm identifier is an OID 3512 and optionally associated parameters. 3514 This section identifies preferred OIDs and parameters for the RSA, 3515 DSA, and Diffie-Hellman algorithms. Conforming CAs shall use the 3516 identified OIDs when issuing certificates containing public keys for 3517 these algorithms. Conforming applications supporting any of these 3518 algorithms shall, at a minimum, recognize the OID identified in this 3519 section. 3521 7.3.1 RSA Keys 3523 The OID rsaEncryption identifies RSA public keys. 3525 pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 3526 rsadsi(113549) pkcs(1) 1 } 3528 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1} 3530 The rsaEncryption OID is intended to be used in the algorithm field 3531 of a value of type AlgorithmIdentifier. The parameters field shall 3532 have ASN.1 type NULL for this algorithm identifier. 3534 The RSA public key shall be encoded using the ASN.1 type RSAPub- 3535 licKey: 3537 RSAPublicKey ::= SEQUENCE { 3538 modulus INTEGER, -- n 3539 publicExponent INTEGER -- e -- } 3541 where modulus is the modulus n, and publicExponent is the public 3542 exponent e. The DER encoded RSAPublicKey is the value of the BIT 3543 STRING subjectPublicKey. 3545 This OID is used in public key certificates for both RSA signature 3546 keys and RSA encryption keys. The intended application for the key 3547 may be indicated in the key usage field (see sec. 4.2.1.3). The use 3548 of a single key for both signature and encryption purposes is not 3549 recommended, but is not forbidden. 3551 If the keyUsage extension is present in an end entity certificate 3552 which conveys an RSA public key, any combination of the following 3553 values may be present: digitalSignature; nonRepudiation; keyEnci- 3554 pherment; and dataEncipherment. If the keyUsage extension is present 3555 in a CA certificate which conveys an RSA public key, any combination 3556 of the following values may be present: digitalSignature; nonRepudi- 3557 ation; keyEncipherment; dataEncipherment; keyCertSign; and cRLSign. 3558 However, this specification RECOMMENDS that if keyCertSign or cRLSign 3559 is present, both keyEncipherment and dataEncipherment should not be 3560 present. 3562 7.3.2 Diffie-Hellman Key Exchange Key 3564 The Diffie-Hellman OID supported by this profile is defined by ANSI 3565 X9.42 [X9.42]. 3567 dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3568 us(840) ansi-x942(10046) number-type(2) 1 } 3570 The dhpublicnumber OID is intended to be used in the algorithm field 3571 of a value of type AlgorithmIdentifier. The parameters field of that 3572 type, which has the algorithm-specific syntax ANY DEFINED BY algo- 3573 rithm, have the ASN.1 type GroupParameters for this algorithm. 3575 DomainParameters ::= SEQUENCE { 3576 p INTEGER, -- odd prime, p=jq +1 3577 g INTEGER, -- generator, g 3578 q INTEGER, -- factor of p-1 3579 j INTEGER OPTIONAL, -- subgroup factor 3580 validationParms ValidationParms OPTIONAL } 3582 ValidationParms ::= SEQUENCE { 3583 seed BIT STRING, 3584 pgenCounter INTEGER } 3586 The fields of type DomainParameters have the following meanings: 3588 p identifies the prime p defining the Galois field; 3590 g specifies the generator of the multiplicative subgroup of order 3591 g; 3593 q specifies the prime factor of p-1; 3595 j optionally specifies the value that satisfies the equation 3596 p=jq+1 to support the optional verification of group parameters; 3598 seed optionally specifies the bit string parameter used as the 3599 seed for the system parameter generation process; and 3601 pgenCounter optionally specifies the integer value output as part 3602 of the of the system parameter prime generation process. 3604 If either of the parameter generation components (pgencounter or 3605 seed) is provided, the other shall be present as well. 3607 The Diffie-Hellman public key shall be ASN.1 encoded as an INTEGER; 3608 this encoding shall be used as the contents (i.e., the value) of the 3609 subjectPublicKey component (a BIT STRING) of the subjectPublicKeyInfo 3610 data element. 3612 DHPublicKey ::= INTEGER -- public key, y = g^x mod p 3614 If the keyUsage extension is present in a certificate which conveys a 3615 DH public key, the following values may be present: keyAgreement; 3616 encipherOnly; and decipherOnly. At most one of encipherOnly and 3617 decipherOnly shall be asserted in keyUsage extension. 3619 7.3.3 DSA Signature Keys 3621 The Digital Signature Algorithm (DSA) is also known as the Digital 3622 Signature Standard (DSS). The DSA OID supported by this profile is 3624 id-dsa ID ::= { iso(1) member-body(2) us(840) x9-57(10040) 3625 x9cm(4) 1 } 3627 The id-dsa algorithm syntax includes optional parameters. These 3628 parameters are commonly referred to as p, q, and g. When omitted, 3629 the parameters component shall be omitted entirely. That is, the 3630 AlgorithmIdentifier shall be a SEQUENCE of one component - the OBJECT 3631 IDENTIFIER id-dsa. 3633 If the DSA algorithm parameters are present in the 3634 subjectPublicKeyInfo AlgorithmIdentifier, the parameters are included 3635 using the following ASN.1 structure: 3637 Dss-Parms ::= SEQUENCE { 3638 p INTEGER, 3639 q INTEGER, 3640 g INTEGER } 3642 If the DSA algorithm parameters are absent from the subjectPublicKey- 3643 Info AlgorithmIdentifier and the CA signed the subject certificate 3644 using DSA, then the certificate issuer's DSA parameters apply to the 3645 subject's DSA key. If the DSA algorithm parameters are absent from 3646 the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the 3647 subject certificate using a signature algorithm other than DSA, then 3648 the subject's DSA parameters are distributed by other means. If the 3649 subjectPublicKeyInfo AlgorithmIdentifier field omits the parameters 3650 component and the CA signed the subject with a signature algorithm 3651 other than DSA, then clients shall reject the certificate. 3653 When signing, DSA algorithm generates two values. These values are 3654 commonly referred to as r and s. To easily transfer these two values 3655 as one signature, they are ASN.1 encoded using the following ASN.1 3656 structure: 3658 Dss-Sig-Value ::= SEQUENCE { 3659 r INTEGER, 3660 s INTEGER } 3662 The encoded signature is conveyed as the value of the BIT STRING sig- 3663 nature in a Certificate or CertificateList. 3665 The DSA public key shall be ASN.1 DER encoded as an INTEGER; this 3666 encoding shall be used as the contents (i.e., the value) of the sub- 3667 jectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo 3668 data element. 3670 DSAPublicKey ::= INTEGER -- public key, Y 3672 If the keyUsage extension is present in an end entity certificate 3673 which conveys a DSA public key, any combination of the following 3674 values may be present: digitalSignature; and nonRepudiation. 3676 If the keyUsage extension is present in an CA certificate which con- 3677 veys a DSA public key, any combination of the following values may be 3678 present: digitalSignature; nonRepudiation; keyCertSign; and cRLSign. 3680 8 References 3682 [FIPS 180-1] Federal Information Processing Standards Publication 3683 (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995. 3684 [Supersedes FIPS PUB 180 dated 11 May 1993.] 3686 [FIPS 186] Federal Information Processing Standards Publication 3687 (FIPS PUB) 186, Digital Signature Standard, 18 May 1994. 3689 [RC95] Rogier, N. and Chauvaud, P., "The compression function of 3690 MD2 is not collision free," Presented at Selected Areas in 3691 Cryptography '95, May 1995. 3693 [RFC 791] J. Postel, "Internet Protocol", September 1981. 3695 [RFC 822] D. Crocker, "Standard for the format of ARPA Internet text 3696 messages", August 1982. 3698 [RFC 1034] P.V. Mockapetris, "Domain names - concepts and 3699 facilities", November 1987. 3701 [RFC 1319] Kaliski, B., "The MD2 Message-Digest Algorithm," RFC 1319, 3702 RSA Laboratories, April 1992. 3704 [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321, 3705 MIT and RSA Data Security, April 1992. 3707 [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic 3708 Mail: Part II: Certificate-Based Key Management," RFC 3709 1422, BBN Communications, February 1993. 3711 [RFC 1423] Balenson, D., "Privacy Enhancement for Internet Electronic 3712 Mail: Part III: Algorithms, Modes, and Identifiers," 3713 RFC 1423, Trusted Information Systems, February 1993. 3715 [RFC 1519] V. Fuller, T. Li, J. Yu, and K. Varadhan. "Classless 3716 Inter-Domain Routing (CIDR): an Address Assignment and 3717 Aggregation Strategy", September 1993. 3719 [RFC 1738] Berners-Lee, T., Masinter L., and M. McCahill. 3720 "Uniform Resource Locators (URL)", RFC 1738, December 1994. 3722 [RFC 1778] Howes, T., Kille S., Yeong, W. and C. Robbins. "The 3723 String Representation of Standard Attribute Syntaxes," 3724 RFC 1778, March 1995. 3726 [RFC 1883] S. Deering and R. Hinden. "Internet Protocol, Version 6 3727 (IPv6) Specification", December 1995. 3729 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 3730 Requirement Levels", March 1997. 3732 [RFC 2247] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. 3733 Sataluri. "Using Domains in LDAP/X.500 Distinguished Names", 3734 RFC 2247, January 1998. 3736 [RFC 2277] H. Alvestrand, "IETF Policy on Character Sets and 3737 Languages", January 1998. 3739 [RFC 2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646", 3740 January 1998. 3742 [RFC 2313] B. Kaliski, "PKCS #1: RSA Encryption Version 1.5", 3743 March 1998. 3745 [SDN.701] SDN.701, "Message Security Protocol 4.0", Revision A 3746 1997-02-06. 3748 [X.208] CCITT Recommendation X.208: Specification of Abstract 3749 Syntax Notation One (ASN.1), 1988. 3751 [X.501] ITU-T Recommendation X.501: Information 3752 Technology - Open Systems Interconnection - The 3753 Directory: Models, 1993. 3755 [X.509] ITU-T Recommendation X.509 (1997 E): Information 3756 Technology - Open Systems Interconnection - The 3757 Directory: Authentication Framework, June 1997. 3759 [X.520] ITU-T Recommendation X.520: Information 3760 Technology - Open Systems Interconnection - The 3761 Directory: Selected Attribute Types, 1993. 3763 [X9.42] ANSI X9.42-199x, Public Key Cryptography for The Financial 3764 Services Industry: Agreement of Symmetric Algorithm Keys 3765 Using Diffie-Hellman (Working Draft), December 1997. 3767 [X9.55] ANSI X9.55-1995, Public Key Cryptography For The Financial 3768 Services Industry: Extensions To Public Key Certificates 3769 And Certificate Revocation Lists, 8 December, 1995. 3771 [X9.57] ANSI X9.57-199x, Public Key Cryptography For The Financial 3772 Services Industry: Certificate Management (Working Draft), 3773 21 June, 1996. 3775 9 Intellectual Property Rights 3777 The IETF has been notified of intellectual property rights claimed in 3778 regard to some or all of the specification contained in this docu- 3779 ment. For more information consult the online list of claimed 3780 rights. 3782 The IETF takes no position regarding the validity or scope of any 3783 intellectual property or other rights that might be claimed to per- 3784 tain to the implementation or use of the technology described in this 3785 document or the extent to which any license under such rights might 3786 or might not be available; neither does it represent that it has made 3787 any effort to identify any such rights. Information on the IETF's 3788 procedures with respect to rights in standards-track and standards- 3789 related documentation can be found in BCP-11. Copies of claims of 3790 rights made available for publication and any assurances of licenses 3791 to be made available, or the result of an attempt made to obtain a 3792 general license or permission for the use of such proprietary rights 3793 by implementors or users of this specification can be obtained from 3794 the IETF Secretariat. 3796 10 Security Considerations 3798 The majority of this specification is devoted to the format and con- 3799 tent of certificates and CRLs. Since certificates and CRLs are digi- 3800 tally signed, no additional integrity service is necessary. Neither 3801 certificates nor CRLs need be kept secret, and unrestricted and 3802 anonymous access to certificates and CRLs has no security implica- 3803 tions. 3805 However, security factors outside the scope of this specification 3806 will affect the assurance provided to certificate users. This sec- 3807 tion highlights critical issues that should be considered by imple- 3808 mentors, administrators, and users. 3810 The procedures performed by CAs and RAs to validate the binding of 3811 the subject's identity of their public key greatly affect the 3812 assurance that should be placed in the certificate. Relying parties 3813 may wish to review the CA's certificate practice statement. This may 3814 be particularly important when issuing certificates to other CAs. 3816 The use of a single key pair for both signature and other purposes is 3817 strongly discouraged. Use of separate key pairs for signature and key 3818 management provides several benefits to the users. The ramifications 3819 associated with loss or disclosure of a signature key are different 3820 from loss or disclosure of a key management key. Using separate key 3821 pairs permits a balanced and flexible response. Similarly, different 3822 validity periods or key lengths for each key pair may be appropriate 3823 in some application environments. Unfortunately, some legacy applica- 3824 tions (e.g., SSL) use a single key pair for signature and key manage- 3825 ment. 3827 The protection afforded private keys is a critical factor in main- 3828 taining security. On a small scale, failure of users to protect 3829 their private keys will permit an attacker to masquerade as them, or 3830 decrypt their personal information. On a larger scale, compromise of 3831 a CA's private signing key may have a catastrophic effect. If an 3832 attacker obtains the private key unnoticed, the attacker may issue 3833 bogus certificates and CRLs. Existence of bogus certificates and 3834 CRLs will undermine confidence in the system. If the compromise is 3835 detected, all certificates issued to the CA shall be revoked, 3836 preventing services between its users and users of other CAs. 3837 Rebuilding after such a compromise will be problematic, so CAs are 3838 advised to implement a combination of strong technical measures 3839 (e.g., tamper-resistant cryptographic modules) and appropriate 3840 management procedures (e.g., separation of duties) to avoid such an 3841 incident. 3843 Loss of a CA's private signing key may also be problematic. The CA 3844 would not be able to produce CRLs or perform normal key rollover. 3845 CAs are advised to maintain secure backup for signing keys. The 3846 security of the key backup procedures is a critical factor in avoid- 3847 ing key compromise. 3849 The availability and freshness of revocation information will affect 3850 the degree of assurance that should be placed in a certificate. 3851 While certificates expire naturally, events may occur during its 3852 natural lifetime which negate the binding between the subject and 3853 public key. If revocation information is untimely or unavailable, 3854 the assurance associated with the binding is clearly reduced. Simi- 3855 larly, implementations of the Path Validation mechanism described in 3856 section 6 that omit revocation checking provide less assurance than 3857 those that support it. 3859 The path validation algorithm depends on the certain knowledge of the 3860 public keys (and other information) about one or more trusted CAs. 3861 The decision to trust a CA is an important decision as it ultimately 3862 determines the trust afforded a certificate. The authenticated dis- 3863 tribution of trusted CA public keys (usually in the form of a "self- 3864 signed" certificate) is a security critical out of band process that 3865 is beyond the scope of this specification. 3867 In addition, where a key compromise or CA failure occurs for a 3868 trusted CA, the user will need to modify the information provided to 3869 the path validation routine. Selection of too many trusted CAs will 3870 make the trusted CA information difficult to maintain. On the other 3871 hand, selection of only one trusted CA may limit users to a closed 3872 community of users until a global PKI emerges. 3874 The quality of implementations that process certificates may also 3875 affect the degree of assurance provided. The path validation algo- 3876 rithm described in section 6 relies upon the integrity of the trusted 3877 CA information, and especially the integrity of the public keys asso- 3878 ciated with the trusted CAs. By substituting public keys for which 3879 an attacker has the private key, an attacker could trick the user 3880 into accepting false certificates. 3882 The binding between a key and certificate subject cannot be stronger 3883 than the cryptographic module implementation and algorithms used to 3884 generate the signature. Short key lengths or weak hash algorithms 3885 will limit the utility of a certificate. CAs are encouraged to note 3886 advances in cryptology so they can employ strong cryptographic tech- 3887 niques. In addition, CAs should decline to issue certificates to CAs 3888 or end entities that generate weak signatures. 3890 Inconsistent application of name comparison rules may result in 3891 acceptance of invalid X.509 certification paths, or rejection of 3892 valid ones. The X.500 series of specifications defines rules for 3893 comparing distinguished names require comparison of strings without 3894 regard to case, character set, multi-character white space substring, 3895 or leading and trailing white space. This specification relaxes 3896 these requirements, requiring support for binary comparison at a 3897 minimum. 3899 CAs shall encode the distinguished name in the subject field of a CA 3900 certificate identically to the distinguished name in the issuer field 3901 in certificates issued by the latter CA. If CAs use different encod- 3902 ings, implementations of this specification may fail to recognize 3903 name chains for paths that include this certificate. As a conse- 3904 quence, valid paths could be rejected. 3906 In addition, name constraints for distinguished names shall be stated 3907 identically to the encoding used in the subject field or subjectAlt- 3908 Name extension. If not, (1) name constraints stated as excludedSub- 3909 Trees will not match and invalid paths will be accepted and (2) name 3910 constraints expressed as permittedSubtrees will not match and valid 3911 paths will be rejected. To avoid acceptance of invalid paths, CAs 3912 should state name constraints for distinguished names as permit- 3913 tedSubtrees where ever possible. 3915 Appendix A. Psuedo-ASN.1 Structures and OIDs 3917 This section describes data objects used by conforming PKI components 3918 in an "ASN.1-like" syntax. This syntax is a hybrid of the 1988 and 3919 1993 ASN.1 syntaxes. The 1988 ASN.1 syntax is augmented with 1993 3920 UNIVERSAL Types UniversalString, BMPString and UTF8String. 3922 The ASN.1 syntax does not permit the inclusion of type statements in 3923 the ASN.1 module, and the 1993 ASN.1 standard does not permit use of 3924 the new UNIVERSAL types in modules using the 1988 syntax. As a 3925 result, this module does not conform to either version of the ASN.1 3926 standard. 3928 This appendix may be converted into 1988 ASN.1 by replacing the 3929 defintions for the UNIVERSAL Types with the 1988 catch-all "ANY". 3931 A.1 Explicitly Tagged Module, 1988 Syntax 3933 PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) 3934 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)} 3936 DEFINITIONS EXPLICIT TAGS ::= 3938 BEGIN 3940 -- EXPORTS ALL -- 3942 -- IMPORTS NONE -- 3944 -- UNIVERSAL Types defined in '93 and '98 ASN.1 3945 -- but required by this specification 3947 UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING 3948 -- UniversalString is defined in ASN.1:1993 3950 BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING 3951 -- BMPString is the subtype of UniversalString and models 3952 -- the Basic Multilingual Plane of ISO/IEC/ITU 10646-1 3954 UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 3955 -- The content of this type conforms to RFC 2279. 3957 -- 3958 -- PKIX specific OIDs 3960 id-pkix OBJECT IDENTIFIER ::= 3961 { iso(1) identified-organization(3) dod(6) internet(1) 3962 security(5) mechanisms(5) pkix(7) } 3963 -- PKIX arcs 3965 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 3966 -- arc for private certificate extensions 3967 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 3968 -- arc for policy qualifier types 3969 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 3970 -- arc for extended key purpose OIDS 3971 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 3972 -- arc for access descriptors 3974 -- policyQualifierIds for Internet policy qualifiers 3976 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 3977 -- OID for CPS qualifier 3978 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 3979 -- OID for user notice qualifier 3981 -- access descriptor definitions 3983 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 3984 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 3986 -- attribute data types -- 3988 Attribute ::= SEQUENCE { 3989 type AttributeType, 3990 values SET OF AttributeValue 3991 -- at least one value is required -- } 3993 AttributeType ::= OBJECT IDENTIFIER 3995 AttributeValue ::= ANY 3997 AttributeTypeAndValue ::= SEQUENCE { 3998 type AttributeType, 3999 value AttributeValue } 4001 -- suggested naming attributes: Definition of the following 4002 -- information object set may be augmented to meet local 4003 -- requirements. Note that deleting members of the set may 4004 -- prevent interoperability with conforming implementations. 4005 -- presented in pairs: the AttributeType followed by the 4006 -- type definition for the corresponding AttributeValue 4008 --Arc for standard naming attributes 4009 id-at OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 4} 4010 -- Attributes of type NameDirectoryString 4011 id-at-name AttributeType ::= {id-at 41} 4012 id-at-surname AttributeType ::= {id-at 4} 4013 id-at-givenName AttributeType ::= {id-at 42} 4014 id-at-initials AttributeType ::= {id-at 43} 4015 id-at-generationQualifier AttributeType ::= {id-at 44} 4017 X520name ::= CHOICE { 4018 teletexString TeletexString (SIZE (1..ub-name)), 4019 printableString PrintableString (SIZE (1..ub-name)), 4020 universalString UniversalString (SIZE (1..ub-name)), 4021 utf8String UTF8String (SIZE (1..ub-name)), 4022 bmpString BMPString (SIZE(1..ub-name)) } 4024 -- 4026 id-at-commonName AttributeType ::= {id-at 3} 4028 X520CommonName ::= CHOICE { 4029 teletexString TeletexString (SIZE (1..ub-common-name)), 4030 printableString PrintableString (SIZE (1..ub-common-name)), 4031 universalString UniversalString (SIZE (1..ub-common-name)), 4032 utf8String UTF8String (SIZE (1..ub-common-name)), 4033 bmpString BMPString (SIZE(1..ub-common-name)) } 4035 -- 4037 id-at-localityName AttributeType ::= {id-at 7} 4039 X520LocalityName ::= CHOICE { 4040 teletexString TeletexString (SIZE (1..ub-locality-name)), 4041 printableString PrintableString (SIZE (1..ub-locality-name)), 4042 universalString UniversalString (SIZE (1..ub-locality-name)), 4043 utf8String UTF8String (SIZE (1..ub-locality-name)), 4044 bmpString BMPString (SIZE(1..ub-locality-name)) } 4046 -- 4048 id-at-stateOrProvinceName AttributeType ::= {id-at 8} 4050 X520StateOrProvinceName ::= CHOICE { 4051 teletexString TeletexString (SIZE (1..ub-state-name)), 4052 printableString PrintableString (SIZE (1..ub-state-name)), 4053 universalString UniversalString (SIZE (1..ub-state-name)), 4054 utf8String UTF8String (SIZE (1..ub-state-name)), 4055 bmpString BMPString (SIZE(1..ub-state-name)) } 4057 -- 4058 id-at-organizationName AttributeType ::= {id-at 10} 4060 X520OrganizationName ::= CHOICE { 4061 teletexString TeletexString (SIZE (1..ub-organization-name)), 4062 printableString PrintableString (SIZE (1..ub-organization-name)), 4063 universalString UniversalString (SIZE (1..ub-organization-name)), 4064 utf8String UTF8String (SIZE (1..ub-organization-name)), 4065 bmpString BMPString (SIZE(1..ub-organization-name)) } 4067 -- 4069 id-at-organizationalUnitName AttributeType ::= {id-at 11} 4071 X520OrganizationalUnitName ::= CHOICE { 4072 teletexString TeletexString (SIZE (1..ub-organizational-unit-name)), 4073 printableString PrintableString 4074 (SIZE (1..ub-organizational-unit-name)), 4075 universalString UniversalString 4076 (SIZE (1..ub-organizational-unit-name)), 4077 utf8String UTF8String (SIZE (1..ub-organizational-unit-name)), 4078 bmpString BMPString (SIZE(1..ub-organizational-unit-name)) } 4080 -- 4082 id-at-title AttributeType ::= {id-at 12} 4084 X520Title ::= CHOICE { 4085 teletexString TeletexString (SIZE (1..ub-title)), 4086 printableString PrintableString (SIZE (1..ub-title)), 4087 universalString UniversalString (SIZE (1..ub-title)), 4088 utf8String UTF8String (SIZE (1..ub-title)), 4089 bmpString BMPString (SIZE(1..ub-title)) } 4091 -- 4093 id-at-dnQualifier AttributeType ::= {id-at 46} 4094 X520dnQualifier ::= PrintableString 4096 id-at-countryName AttributeType ::= {id-at 6} 4097 X520countryName ::= PrintableString (SIZE (2)) -- IS 3166 codes 4099 -- Legacy attributes 4101 pkcs-9 OBJECT IDENTIFIER ::= 4102 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 } 4104 emailAddress AttributeType ::= { pkcs-9 1 } 4105 Pkcs9email ::= IA5String (SIZE (1..ub-emailaddress-length)) 4107 -- naming data types -- 4109 Name ::= CHOICE { -- only one possibility for now -- 4110 rdnSequence RDNSequence } 4112 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 4114 DistinguishedName ::= RDNSequence 4116 RelativeDistinguishedName ::= 4117 SET SIZE (1 .. MAX) OF AttributeTypeAndValue 4119 -- Directory string type -- 4121 DirectoryString ::= CHOICE { 4122 teletexString TeletexString (SIZE (1..MAX)), 4123 printableString PrintableString (SIZE (1..MAX)), 4124 universalString UniversalString (SIZE (1..MAX)), 4125 utf8String UTF8String (SIZE (1..MAX)), 4126 bmpString BMPString (SIZE(1..MAX)) } 4128 -- certificate and CRL specific structures begin here 4130 Certificate ::= SEQUENCE { 4131 tbsCertificate TBSCertificate, 4132 signatureAlgorithm AlgorithmIdentifier, 4133 signature BIT STRING } 4135 TBSCertificate ::= SEQUENCE { 4136 version [0] Version DEFAULT v1, 4137 serialNumber CertificateSerialNumber, 4138 signature AlgorithmIdentifier, 4139 issuer Name, 4140 validity Validity, 4141 subject Name, 4142 subjectPublicKeyInfo SubjectPublicKeyInfo, 4143 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 4144 -- If present, version shall be v2 or v3 4145 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 4146 -- If present, version shall be v2 or v3 4147 extensions [3] Extensions OPTIONAL 4148 -- If present, version shall be v3 -- } 4150 Version ::= INTEGER { v1(0), v2(1), v3(2) } 4152 CertificateSerialNumber ::= INTEGER 4153 Validity ::= SEQUENCE { 4154 notBefore Time, 4155 notAfter Time } 4157 Time ::= CHOICE { 4158 utcTime UTCTime, 4159 generalTime GeneralizedTime } 4161 UniqueIdentifier ::= BIT STRING 4163 SubjectPublicKeyInfo ::= SEQUENCE { 4164 algorithm AlgorithmIdentifier, 4165 subjectPublicKey BIT STRING } 4167 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 4169 Extension ::= SEQUENCE { 4170 extnID OBJECT IDENTIFIER, 4171 critical BOOLEAN DEFAULT FALSE, 4172 extnValue OCTET STRING } 4174 -- CRL structures 4176 CertificateList ::= SEQUENCE { 4177 tbsCertList TBSCertList, 4178 signatureAlgorithm AlgorithmIdentifier, 4179 signature BIT STRING } 4181 TBSCertList ::= SEQUENCE { 4182 version Version OPTIONAL, 4183 -- if present, shall be v2 4184 signature AlgorithmIdentifier, 4185 issuer Name, 4186 thisUpdate Time, 4187 nextUpdate Time OPTIONAL, 4188 revokedCertificates SEQUENCE OF SEQUENCE { 4189 userCertificate CertificateSerialNumber, 4190 revocationDate Time, 4191 crlEntryExtensions Extensions OPTIONAL 4192 -- if present, shall be v2 4193 } OPTIONAL, 4194 crlExtensions [0] Extensions OPTIONAL 4195 -- if present, shall be v2 -- } 4197 -- Version, Time, CertificateSerialNumber, and Extensions were 4198 -- defined earlier for use in the certificate structure 4200 AlgorithmIdentifier ::= SEQUENCE { 4201 algorithm OBJECT IDENTIFIER, 4202 parameters ANY DEFINED BY algorithm OPTIONAL } 4203 -- contains a value of the type 4204 -- registered for use with the 4205 -- algorithm object identifier value 4207 -- Algorithm OIDs and parameter structures 4209 pkcs-1 OBJECT IDENTIFIER ::= { 4210 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 } 4212 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } 4214 md2WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 2 } 4216 md5WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 4 } 4218 sha1WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 5 } 4220 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { 4221 iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 3 } 4223 Dss-Sig-Value ::= SEQUENCE { 4224 r INTEGER, 4225 s INTEGER } 4227 dhpublicnumber OBJECT IDENTIFIER ::= { 4228 iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 } 4230 DomainParameters ::= SEQUENCE { 4231 p INTEGER, -- odd prime, p=jq +1 4232 g INTEGER, -- generator, g 4233 q INTEGER, -- factor of p-1 4234 j INTEGER OPTIONAL, -- subgroup factor, j>= 2 4235 validationParms ValidationParms OPTIONAL } 4237 ValidationParms ::= SEQUENCE { 4238 seed BIT STRING, 4239 pgenCounter INTEGER } 4241 id-dsa OBJECT IDENTIFIER ::= { 4242 iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 } 4244 Dss-Parms ::= SEQUENCE { 4245 p INTEGER, 4246 q INTEGER, 4247 g INTEGER } 4249 -- x400 address syntax starts here 4250 -- OR Names 4252 ORAddress ::= SEQUENCE { 4253 built-in-standard-attributes BuiltInStandardAttributes, 4254 built-in-domain-defined-attributes 4255 BuiltInDomainDefinedAttributes OPTIONAL, 4256 -- see also teletex-domain-defined-attributes 4257 extension-attributes ExtensionAttributes OPTIONAL } 4258 -- The OR-address is semantically absent from the OR-name if the 4259 -- built-in-standard-attribute sequence is empty and the 4260 -- built-in-domain-defined-attributes and extension-attributes are 4261 -- both omitted. 4263 -- Built-in Standard Attributes 4265 BuiltInStandardAttributes ::= SEQUENCE { 4266 country-name CountryName OPTIONAL, 4267 administration-domain-name AdministrationDomainName OPTIONAL, 4268 network-address [0] NetworkAddress OPTIONAL, 4269 -- see also extended-network-address 4270 terminal-identifier [1] TerminalIdentifier OPTIONAL, 4271 private-domain-name [2] PrivateDomainName OPTIONAL, 4272 organization-name [3] OrganizationName OPTIONAL, 4273 -- see also teletex-organization-name 4274 numeric-user-identifier [4] NumericUserIdentifier OPTIONAL, 4275 personal-name [5] PersonalName OPTIONAL, 4276 -- see also teletex-personal-name 4277 organizational-unit-names [6] OrganizationalUnitNames OPTIONAL 4278 -- see also teletex-organizational-unit-names -- } 4280 CountryName ::= [APPLICATION 1] CHOICE { 4281 x121-dcc-code NumericString 4282 (SIZE (ub-country-name-numeric-length)), 4283 iso-3166-alpha2-code PrintableString 4284 (SIZE (ub-country-name-alpha-length)) } 4286 AdministrationDomainName ::= [APPLICATION 2] CHOICE { 4287 numeric NumericString (SIZE (0..ub-domain-name-length)), 4288 printable PrintableString (SIZE (0..ub-domain-name-length)) } 4290 NetworkAddress ::= X121Address -- see also extended-network-address 4292 X121Address ::= NumericString (SIZE (1..ub-x121-address-length)) 4294 TerminalIdentifier ::= PrintableString (SIZE (1..ub-terminal-id-length)) 4296 PrivateDomainName ::= CHOICE { 4297 numeric NumericString (SIZE (1..ub-domain-name-length)), 4298 printable PrintableString (SIZE (1..ub-domain-name-length)) } 4300 OrganizationName ::= PrintableString 4301 (SIZE (1..ub-organization-name-length)) 4302 -- see also teletex-organization-name 4304 NumericUserIdentifier ::= NumericString 4305 (SIZE (1..ub-numeric-user-id-length)) 4307 PersonalName ::= SET { 4308 surname [0] PrintableString (SIZE (1..ub-surname-length)), 4309 given-name [1] PrintableString 4310 (SIZE (1..ub-given-name-length)) OPTIONAL, 4311 initials [2] PrintableString (SIZE (1..ub-initials-length)) OPTIONAL, 4312 generation-qualifier [3] PrintableString 4313 (SIZE (1..ub-generation-qualifier-length)) OPTIONAL } 4314 -- see also teletex-personal-name 4316 OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units) 4317 OF OrganizationalUnitName 4318 -- see also teletex-organizational-unit-names 4320 OrganizationalUnitName ::= PrintableString (SIZE 4321 (1..ub-organizational-unit-name-length)) 4323 -- Built-in Domain-defined Attributes 4325 BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE 4326 (1..ub-domain-defined-attributes) OF 4327 BuiltInDomainDefinedAttribute 4329 BuiltInDomainDefinedAttribute ::= SEQUENCE { 4330 type PrintableString (SIZE 4331 (1..ub-domain-defined-attribute-type-length)), 4332 value PrintableString (SIZE 4333 (1..ub-domain-defined-attribute-value-length))} 4335 -- Extension Attributes 4337 ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF 4338 ExtensionAttribute 4340 ExtensionAttribute ::= SEQUENCE { 4341 extension-attribute-type [0] INTEGER (0..ub-extension-attributes), 4342 extension-attribute-value [1] 4343 ANY DEFINED BY extension-attribute-type } 4345 -- Extension types and attribute values 4346 -- 4348 common-name INTEGER ::= 1 4350 CommonName ::= PrintableString (SIZE (1..ub-common-name-length)) 4352 teletex-common-name INTEGER ::= 2 4354 TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length)) 4356 teletex-organization-name INTEGER ::= 3 4358 TeletexOrganizationName ::= 4359 TeletexString (SIZE (1..ub-organization-name-length)) 4361 teletex-personal-name INTEGER ::= 4 4363 TeletexPersonalName ::= SET { 4364 surname [0] TeletexString (SIZE (1..ub-surname-length)), 4365 given-name [1] TeletexString 4366 (SIZE (1..ub-given-name-length)) OPTIONAL, 4367 initials [2] TeletexString (SIZE (1..ub-initials-length)) OPTIONAL, 4368 generation-qualifier [3] TeletexString (SIZE 4369 (1..ub-generation-qualifier-length)) OPTIONAL } 4371 teletex-organizational-unit-names INTEGER ::= 5 4373 TeletexOrganizationalUnitNames ::= SEQUENCE SIZE 4374 (1..ub-organizational-units) OF TeletexOrganizationalUnitName 4376 TeletexOrganizationalUnitName ::= TeletexString 4377 (SIZE (1..ub-organizational-unit-name-length)) 4379 pds-name INTEGER ::= 7 4381 PDSName ::= PrintableString (SIZE (1..ub-pds-name-length)) 4383 physical-delivery-country-name INTEGER ::= 8 4385 PhysicalDeliveryCountryName ::= CHOICE { 4386 x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)), 4387 iso-3166-alpha2-code PrintableString 4388 (SIZE (ub-country-name-alpha-length)) } 4390 postal-code INTEGER ::= 9 4392 PostalCode ::= CHOICE { 4393 numeric-code NumericString (SIZE (1..ub-postal-code-length)), 4394 printable-code PrintableString (SIZE (1..ub-postal-code-length)) } 4396 physical-delivery-office-name INTEGER ::= 10 4398 PhysicalDeliveryOfficeName ::= PDSParameter 4400 physical-delivery-office-number INTEGER ::= 11 4402 PhysicalDeliveryOfficeNumber ::= PDSParameter 4404 extension-OR-address-components INTEGER ::= 12 4406 ExtensionORAddressComponents ::= PDSParameter 4408 physical-delivery-personal-name INTEGER ::= 13 4410 PhysicalDeliveryPersonalName ::= PDSParameter 4412 physical-delivery-organization-name INTEGER ::= 14 4414 PhysicalDeliveryOrganizationName ::= PDSParameter 4416 extension-physical-delivery-address-components INTEGER ::= 15 4418 ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter 4420 unformatted-postal-address INTEGER ::= 16 4422 UnformattedPostalAddress ::= SET { 4423 printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) OF 4424 PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL, 4425 teletex-string TeletexString 4426 (SIZE (1..ub-unformatted-address-length)) OPTIONAL } 4428 street-address INTEGER ::= 17 4430 StreetAddress ::= PDSParameter 4432 post-office-box-address INTEGER ::= 18 4434 PostOfficeBoxAddress ::= PDSParameter 4436 poste-restante-address INTEGER ::= 19 4438 PosteRestanteAddress ::= PDSParameter 4440 unique-postal-name INTEGER ::= 20 4441 UniquePostalName ::= PDSParameter 4443 local-postal-attributes INTEGER ::= 21 4445 LocalPostalAttributes ::= PDSParameter 4447 PDSParameter ::= SET { 4448 printable-string PrintableString 4449 (SIZE(1..ub-pds-parameter-length)) OPTIONAL, 4450 teletex-string TeletexString 4451 (SIZE(1..ub-pds-parameter-length)) OPTIONAL } 4453 extended-network-address INTEGER ::= 22 4455 ExtendedNetworkAddress ::= CHOICE { 4456 e163-4-address SEQUENCE { 4457 number [0] NumericString (SIZE (1..ub-e163-4-number-length)), 4458 sub-address [1] NumericString 4459 (SIZE (1..ub-e163-4-sub-address-length)) OPTIONAL }, 4460 psap-address [0] PresentationAddress } 4462 PresentationAddress ::= SEQUENCE { 4463 pSelector [0] EXPLICIT OCTET STRING OPTIONAL, 4464 sSelector [1] EXPLICIT OCTET STRING OPTIONAL, 4465 tSelector [2] EXPLICIT OCTET STRING OPTIONAL, 4466 nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING } 4468 terminal-type INTEGER ::= 23 4470 TerminalType ::= INTEGER { 4471 telex (3), 4472 teletex (4), 4473 g3-facsimile (5), 4474 g4-facsimile (6), 4475 ia5-terminal (7), 4476 videotex (8) } (0..ub-integer-options) 4478 -- Extension Domain-defined Attributes 4480 teletex-domain-defined-attributes INTEGER ::= 6 4482 TeletexDomainDefinedAttributes ::= SEQUENCE SIZE 4483 (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute 4485 TeletexDomainDefinedAttribute ::= SEQUENCE { 4486 type TeletexString 4487 (SIZE (1..ub-domain-defined-attribute-type-length)), 4488 value TeletexString 4489 (SIZE (1..ub-domain-defined-attribute-value-length)) } 4491 -- specifications of Upper Bounds shall be regarded as mandatory 4492 -- from Annex B of ITU-T X.411 Reference Definition of MTS Parameter 4493 -- Upper Bounds 4495 -- Upper Bounds 4496 ub-name INTEGER ::= 32768 4497 ub-common-name INTEGER ::= 64 4498 ub-locality-name INTEGER ::= 128 4499 ub-state-name INTEGER ::= 128 4500 ub-organization-name INTEGER ::= 64 4501 ub-organizational-unit-name INTEGER ::= 64 4502 ub-title INTEGER ::= 64 4503 ub-match INTEGER ::= 128 4505 ub-emailaddress-length INTEGER ::= 128 4507 ub-common-name-length INTEGER ::= 64 4508 ub-country-name-alpha-length INTEGER ::= 2 4509 ub-country-name-numeric-length INTEGER ::= 3 4510 ub-domain-defined-attributes INTEGER ::= 4 4511 ub-domain-defined-attribute-type-length INTEGER ::= 8 4512 ub-domain-defined-attribute-value-length INTEGER ::= 128 4513 ub-domain-name-length INTEGER ::= 16 4514 ub-extension-attributes INTEGER ::= 256 4515 ub-e163-4-number-length INTEGER ::= 15 4516 ub-e163-4-sub-address-length INTEGER ::= 40 4517 ub-generation-qualifier-length INTEGER ::= 3 4518 ub-given-name-length INTEGER ::= 16 4519 ub-initials-length INTEGER ::= 5 4520 ub-integer-options INTEGER ::= 256 4521 ub-numeric-user-id-length INTEGER ::= 32 4522 ub-organization-name-length INTEGER ::= 64 4523 ub-organizational-unit-name-length INTEGER ::= 32 4524 ub-organizational-units INTEGER ::= 4 4525 ub-pds-name-length INTEGER ::= 16 4526 ub-pds-parameter-length INTEGER ::= 30 4527 ub-pds-physical-address-lines INTEGER ::= 6 4528 ub-postal-code-length INTEGER ::= 16 4529 ub-surname-length INTEGER ::= 40 4530 ub-terminal-id-length INTEGER ::= 24 4531 ub-unformatted-address-length INTEGER ::= 180 4532 ub-x121-address-length INTEGER ::= 16 4534 -- Note - upper bounds on string types, such as TeletexString, are 4535 -- measured in characters. Excepting PrintableString or IA5String, a 4536 -- significantly greater number of octets will be required to hold 4537 -- such a value. As a minimum, 16 octets, or twice the specified upper 4538 -- bound, whichever is the larger, should be allowed for TeletexString. 4539 -- For UTF8String or UniversalString at least four times the upper 4540 -- bound should be allowed. 4542 END 4543 A.2 Implicitly Tagged Module, 1988 Syntax 4545 PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) 4546 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)} 4548 DEFINITIONS IMPLICIT TAGS ::= 4550 BEGIN 4552 -- EXPORTS ALL -- 4554 IMPORTS 4555 id-pkix, id-pe, id-qt, id-kp, id-qt-unotice, id-qt-cps, 4556 id-ad, id-ad-ocsp, id-ad-caIssuers, 4557 -- delete following line if "new" types are supported -- 4558 BMPString, UniversalString, UTF8String, -- end "new" types 4559 ORAddress, Name, RelativeDistinguishedName, 4560 CertificateSerialNumber, 4561 CertificateList, AlgorithmIdentifier, ub-name, 4562 Attribute, DirectoryString 4563 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 4564 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 4565 id-mod(0) id-pkix1-explicit(1)}; 4567 -- ISO arc for standard certificate and CRL extensions 4569 id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 4571 -- authority key identifier OID and syntax 4573 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 4575 AuthorityKeyIdentifier ::= SEQUENCE { 4576 keyIdentifier [0] KeyIdentifier OPTIONAL, 4577 authorityCertIssuer [1] GeneralNames OPTIONAL, 4578 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 4579 -- authorityCertIssuer and authorityCertSerialNumber shall both 4580 -- be present or both be absent 4582 KeyIdentifier ::= OCTET STRING 4584 -- subject key identifier OID and syntax 4586 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 4588 SubjectKeyIdentifier ::= KeyIdentifier 4589 -- key usage extension OID and syntax 4591 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 4593 KeyUsage ::= BIT STRING { 4594 digitalSignature (0), 4595 nonRepudiation (1), 4596 keyEncipherment (2), 4597 dataEncipherment (3), 4598 keyAgreement (4), 4599 keyCertSign (5), 4600 cRLSign (6), 4601 encipherOnly (7), 4602 decipherOnly (8) } 4604 -- private key usage period extension OID and syntax 4606 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 4608 PrivateKeyUsagePeriod ::= SEQUENCE { 4609 notBefore [0] GeneralizedTime OPTIONAL, 4610 notAfter [1] GeneralizedTime OPTIONAL } 4611 -- either notBefore or notAfter shall be present 4613 -- certificate policies extension OID and syntax 4615 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 4617 anyPolicy OBJECT IDENTIFIER ::= {id-ce-certificate-policies 0} 4619 CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 4621 PolicyInformation ::= SEQUENCE { 4622 policyIdentifier CertPolicyId, 4623 policyQualifiers SEQUENCE SIZE (1..MAX) OF 4624 PolicyQualifierInfo OPTIONAL } 4626 CertPolicyId ::= OBJECT IDENTIFIER 4628 PolicyQualifierInfo ::= SEQUENCE { 4629 policyQualifierId PolicyQualifierId, 4630 qualifier ANY DEFINED BY policyQualifierId } 4632 -- Implementations that recognize additional policy qualifiers shall 4633 -- augment the following definition for PolicyQualifierId 4635 PolicyQualifierId ::= 4636 OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) 4638 -- CPS pointer qualifier 4640 CPSuri ::= IA5String 4642 -- user notice qualifier 4644 UserNotice ::= SEQUENCE { 4645 noticeRef NoticeReference OPTIONAL, 4646 explicitText DisplayText OPTIONAL} 4648 NoticeReference ::= SEQUENCE { 4649 organization DisplayText, 4650 noticeNumbers SEQUENCE OF INTEGER } 4652 DisplayText ::= CHOICE { 4653 ia5String IA5String (SIZE (1..200)), 4654 visibleString VisibleString (SIZE (1..200)), 4655 bmpString BMPString (SIZE (1..200)), 4656 utf8String UTF8String (SIZE (1..200)) } 4658 -- policy mapping extension OID and syntax 4660 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 4662 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 4663 issuerDomainPolicy CertPolicyId, 4664 subjectDomainPolicy CertPolicyId } 4666 -- subject alternative name extension OID and syntax 4668 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 4670 SubjectAltName ::= GeneralNames 4672 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 4674 GeneralName ::= CHOICE { 4675 otherName [0] AnotherName, 4676 rfc822Name [1] IA5String, 4677 dNSName [2] IA5String, 4678 x400Address [3] ORAddress, 4679 directoryName [4] Name, 4680 ediPartyName [5] EDIPartyName, 4681 uniformResourceIdentifier [6] IA5String, 4682 iPAddress [7] OCTET STRING, 4683 registeredID [8] OBJECT IDENTIFIER } 4685 -- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as 4686 -- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax 4688 AnotherName ::= SEQUENCE { 4689 type-id OBJECT IDENTIFIER, 4690 value [0] EXPLICIT ANY DEFINED BY type-id } 4692 EDIPartyName ::= SEQUENCE { 4693 nameAssigner [0] DirectoryString OPTIONAL, 4694 partyName [1] DirectoryString } 4696 -- issuer alternative name extension OID and syntax 4698 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 4700 IssuerAltName ::= GeneralNames 4702 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 4704 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 4706 -- basic constraints extension OID and syntax 4708 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 4710 BasicConstraints ::= SEQUENCE { 4711 cA BOOLEAN DEFAULT FALSE, 4712 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 4714 -- name constraints extension OID and syntax 4716 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 4718 NameConstraints ::= SEQUENCE { 4719 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 4720 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 4722 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 4724 GeneralSubtree ::= SEQUENCE { 4725 base GeneralName, 4726 minimum [0] BaseDistance DEFAULT 0, 4727 maximum [1] BaseDistance OPTIONAL } 4729 BaseDistance ::= INTEGER (0..MAX) 4731 -- policy constraints extension OID and syntax 4733 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } 4734 PolicyConstraints ::= SEQUENCE { 4735 requireExplicitPolicy [0] SkipCerts OPTIONAL, 4736 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 4738 SkipCerts ::= INTEGER (0..MAX) 4740 -- CRL distribution points extension OID and syntax 4742 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31} 4744 CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 4746 DistributionPoint ::= SEQUENCE { 4747 distributionPoint [0] DistributionPointName OPTIONAL, 4748 reasons [1] ReasonFlags OPTIONAL, 4749 cRLIssuer [2] GeneralNames OPTIONAL } 4751 DistributionPointName ::= CHOICE { 4752 fullName [0] GeneralNames, 4753 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 4755 ReasonFlags ::= BIT STRING { 4756 unused (0), 4757 keyCompromise (1), 4758 cACompromise (2), 4759 affiliationChanged (3), 4760 superseded (4), 4761 cessationOfOperation (5), 4762 certificateHold (6) } 4764 -- extended key usage extension OID and syntax 4766 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 4768 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 4770 KeyPurposeId ::= OBJECT IDENTIFIER 4772 -- extended key purpose OIDs 4773 id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } 4774 id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } 4775 id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } 4776 id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } 4777 id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 } 4778 id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 } 4779 id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 } 4780 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 4781 -- authority info access 4783 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 4785 AuthorityInfoAccessSyntax ::= 4786 SEQUENCE SIZE (1..MAX) OF AccessDescription 4788 AccessDescription ::= SEQUENCE { 4789 accessMethod OBJECT IDENTIFIER, 4790 accessLocation GeneralName } 4792 -- CRL number extension OID and syntax 4794 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 4796 CRLNumber ::= INTEGER (0..MAX) 4798 -- issuing distribution point extension OID and syntax 4800 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 4802 IssuingDistributionPoint ::= SEQUENCE { 4803 distributionPoint [0] DistributionPointName OPTIONAL, 4804 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 4805 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 4806 onlySomeReasons [3] ReasonFlags OPTIONAL, 4807 indirectCRL [4] BOOLEAN DEFAULT FALSE } 4809 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 4811 -- deltaCRLIndicator ::= BaseCRLNumber 4813 BaseCRLNumber ::= CRLNumber 4815 -- CRL reasons extension OID and syntax 4817 id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 } 4819 CRLReason ::= ENUMERATED { 4820 unspecified (0), 4821 keyCompromise (1), 4822 cACompromise (2), 4823 affiliationChanged (3), 4824 superseded (4), 4825 cessationOfOperation (5), 4826 certificateHold (6), 4827 removeFromCRL (8) } 4829 -- certificate issuer CRL entry extension OID and syntax 4831 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } 4833 CertificateIssuer ::= GeneralNames 4835 -- hold instruction extension OID and syntax 4837 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 4839 HoldInstructionCode ::= OBJECT IDENTIFIER 4841 -- ANSI x9 holdinstructions 4843 -- ANSI x9 arc holdinstruction arc 4844 holdInstruction OBJECT IDENTIFIER ::= 4845 {joint-iso-itu-t(2) member-body(2) us(840) x9cm(10040) 2} 4847 -- ANSI X9 holdinstructions referenced by this standard 4848 id-holdinstruction-none OBJECT IDENTIFIER ::= 4849 {holdInstruction 1} -- deprecated 4850 id-holdinstruction-callissuer OBJECT IDENTIFIER ::= 4851 {holdInstruction 2} 4852 id-holdinstruction-reject OBJECT IDENTIFIER ::= 4853 {holdInstruction 3} 4855 -- invalidity date CRL entry extension OID and syntax 4857 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 4859 InvalidityDate ::= GeneralizedTime 4861 END 4862 Appendix B. 1993 ASN.1 Structures and OIDs 4864 B.1 Explicitly Tagged Module, 1993 Syntax 4866 PKIX1Explicit93 {iso(1) identified-organization(3) dod(6) internet(1) 4867 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-93(3)} 4869 DEFINITIONS EXPLICIT TAGS ::= 4871 BEGIN 4873 -- EXPORTS ALL -- 4875 IMPORTS 4876 authorityKeyIdentifier, subjectKeyIdentifier, keyUsage, 4877 extendedKeyUsage, privateKeyUsagePeriod, certificatePolicies, 4878 policyMappings, subjectAltName, issuerAltName, 4879 basicConstraints, nameConstraints, policyConstraints, 4880 cRLDistributionPoints, subjectDirectoryAttributes, 4881 cRLNumber, reasonCode, instructionCode, invalidityDate, 4882 issuingDistributionPoint, certificateIssuer, 4883 deltaCRLIndicator, authorityInfoAccess, id-ce 4884 FROM PKIX1Implicit93 {iso(1) identified-organization(3) 4885 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 4886 id-mod(0) id-pkix1-implicit-93(4)} ; 4888 -- 4889 -- Locally defined OIDs -- 4891 id-pkix OBJECT IDENTIFIER ::= 4892 { iso(1) identified-organization(3) dod(6) internet(1) 4893 security(5) mechanisms(5) pkix(7) } 4895 -- PKIX arcs 4896 -- arc for private certificate extensions 4897 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 4898 -- arc for policy qualifier types 4899 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 4900 -- arc for extended key purpose OIDS 4901 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 4902 -- arc for access descriptors 4903 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 4905 -- policyQualifierIds for Internet policy qualifiers 4906 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 4907 -- OID for CPS qualifier 4909 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 4910 -- OID for user notice qualifier 4912 -- based on excerpts from AuthenticationFramework 4913 -- {joint-iso-ccitt ds(5) modules(1) authenticationFramework(7) 2} 4915 -- Public Key Certificate -- 4917 Certificate ::= SIGNED { SEQUENCE { 4918 version [0] Version DEFAULT v1, 4919 serialNumber CertificateSerialNumber, 4920 signature AlgorithmIdentifier, 4921 issuer Name, 4922 validity Validity, 4923 subject Name, 4924 subjectPublicKeyInfo SubjectPublicKeyInfo, 4925 issuerUniqueIdentifier [1] IMPLICIT UniqueIdentifier OPTIONAL, 4926 ---if present, version shall be v2 or v3-- 4927 subjectUniqueIdentifier [2] IMPLICIT UniqueIdentifier OPTIONAL, 4928 ---if present, version shall be v2 or v3-- 4929 extensions [3] Extensions OPTIONAL 4930 --if present, version shall be v3--} } 4932 UniqueIdentifier ::= BIT STRING 4934 Version ::= INTEGER { v1(0), v2(1), v3(2) } 4936 CertificateSerialNumber ::= INTEGER 4938 Validity ::= SEQUENCE { 4939 notBefore Time, 4940 notAfter Time } 4942 Time ::= CHOICE { 4943 utcTime UTCTime, 4944 generalTime GeneralizedTime } 4946 SubjectPublicKeyInfo ::= SEQUENCE{ 4947 algorithm AlgorithmIdentifier, 4948 subjectPublicKey BIT STRING} 4950 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 4952 Extension ::= SEQUENCE { 4953 extnId EXTENSION.&id ({ExtensionSet}), 4954 critical BOOLEAN DEFAULT FALSE, 4955 extnValue OCTET STRING } 4956 -- contains a DER encoding of a value of type 4957 -- &ExtnType for the 4958 -- extension object identified by extnId -- 4960 -- The following information object set is defined to constrain the 4961 -- set of legal certificate extensions. 4963 ExtensionSet EXTENSION ::= { authorityKeyIdentifier | 4964 subjectKeyIdentifier | 4965 keyUsage | 4966 extendedKeyUsage | 4967 privateKeyUsagePeriod | 4968 certificatePolicies | 4969 policyMappings | 4970 subjectAltName | 4971 issuerAltName | 4972 basicConstraints | 4973 nameConstraints | 4974 policyConstraints | 4975 cRLDistributionPoints | 4976 subjectDirectoryAttributes | 4977 authorityInfoAccess } 4979 EXTENSION ::= CLASS { 4980 &id OBJECT IDENTIFIER UNIQUE, 4981 &ExtnType } 4982 WITH SYNTAX { 4983 SYNTAX &ExtnType 4984 IDENTIFIED BY &id } 4986 -- Certificate Revocation List -- 4988 CertificateList ::= SIGNED { SEQUENCE { 4989 version Version OPTIONAL, -- if present, shall be v2 4990 signature AlgorithmIdentifier, 4991 issuer Name, 4992 thisUpdate Time, 4993 nextUpdate Time OPTIONAL, 4994 revokedCertificates SEQUENCE OF SEQUENCE { 4995 userCertificate CertificateSerialNumber, 4996 revocationDate Time, 4997 crlEntryExtensions EntryExtensions OPTIONAL } OPTIONAL, 4998 crlExtensions [0] CRLExtensions OPTIONAL }} 5000 CRLExtensions ::= SEQUENCE SIZE (1..MAX) OF CRLExtension 5002 CRLExtension ::= SEQUENCE { 5003 extnId EXTENSION.&id ({CRLExtensionSet}), 5004 critical BOOLEAN DEFAULT FALSE, 5005 extnValue OCTET STRING } 5006 -- contains a DER encoding of a value of type 5007 -- &ExtnType for the 5008 -- extension object identified by extnId -- 5010 -- The following information object set is defined to constrain the 5011 -- set of legal CRL extensions. 5013 CRLExtensionSet EXTENSION ::= { authorityKeyIdentifier | 5014 issuerAltName | 5015 cRLNumber | 5016 deltaCRLIndicator | 5017 issuingDistributionPoint } 5019 -- EXTENSION defined above for certificates 5021 EntryExtensions ::= SEQUENCE SIZE (1..MAX) OF EntryExtension 5023 EntryExtension ::= SEQUENCE { 5024 extnId EXTENSION.&id ({EntryExtensionSet}), 5025 critical BOOLEAN DEFAULT FALSE, 5026 extnValue OCTET STRING } 5027 -- contains a DER encoding of a value of type 5028 -- &ExtnType for the 5029 -- extension object identified by extnId -- 5031 -- The following information object set is defined to constrain the 5032 -- set of legal CRL entry extensions. 5034 EntryExtensionSet EXTENSION ::= { reasonCode | 5035 instructionCode | 5036 invalidityDate | 5037 certificateIssuer } 5039 -- information object classes used in the defintion -- 5040 -- of certificates and CRLs -- 5042 -- Parameterized Type SIGNED -- 5044 SIGNED { ToBeSigned } ::= SEQUENCE { 5045 toBeSigned ToBeSigned, 5046 algorithm AlgorithmIdentifier, 5047 signature BIT STRING 5048 } 5050 -- Definition of AlgorithmIdentifier 5051 -- ISO definition was: 5052 -- 5053 -- AlgorithmIdentifier ::= SEQUENCE { 5054 -- algorithm ALGORITHM.&id({SupportedAlgorithms}), 5055 -- parameters ALGORITHM.&Type({SupportedAlgorithms} 5056 -- { @algorithm}) OPTIONAL } 5057 -- Definition of ALGORITHM 5058 -- ALGORITHM ::= TYPE-IDENTIFIER 5060 -- The following PKIX definition replaces the X.509 definition 5061 -- 5063 AlgorithmIdentifier ::= SEQUENCE { 5064 algorithm ALGORITHM-ID.&id({SupportedAlgorithms}), 5065 parameters ALGORITHM-ID.&Type({SupportedAlgorithms} 5066 { @algorithm}) OPTIONAL } 5068 -- Definition of ALGORITHM-ID 5070 ALGORITHM-ID ::= CLASS { 5071 &id OBJECT IDENTIFIER UNIQUE, 5072 &Type OPTIONAL 5073 } 5074 WITH SYNTAX { OID &id [PARMS &Type] } 5076 -- The definition of SupportedAlgorithms may be modified as this 5077 -- document does not specify a mandatory algorithm set. In addition, 5078 -- the set is specified as extensible, since additional algorithms 5079 -- may be supported 5081 SupportedAlgorithms ALGORITHM-ID ::= { ..., -- extensible 5082 rsaPublicKey | 5083 rsaSHA-1 | 5084 rsaMD5 | 5085 rsaMD2 | 5086 dssPublicKey | 5087 dsaSHA-1 | 5088 dhPublicKey } 5090 -- OIDs and parameter structures for ALGORITHM-IDs used 5091 -- in this specification 5093 rsaPublicKey ALGORITHM-ID ::= { OID rsaEncryption PARMS NULL } 5095 rsaSHA-1 ALGORITHM-ID ::= { OID sha1WithRSAEncryption PARMS NULL } 5097 rsaMD5 ALGORITHM-ID ::= { OID md5WithRSAEncryption PARMS NULL } 5099 rsaMD2 ALGORITHM-ID ::= { OID md2WithRSAEncryption PARMS NULL } 5100 dssPublicKey ALGORITHM-ID ::= { OID id-dsa PARMS Dss-Parms } 5102 dsaSHA-1 ALGORITHM-ID ::= { OID id-dsa-with-sha1 } 5104 dhPublicKey ALGORITHM-ID ::= {OID dhpublicnumber PARMS DomainParameters} 5106 -- algorithm identifiers and parameter structures 5108 pkcs-1 OBJECT IDENTIFIER ::= { 5109 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 } 5111 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } 5113 md2WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 2 } 5115 md5WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 4 } 5117 sha1WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 5 } 5119 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { 5120 iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 3 } 5122 Dss-Sig-Value ::= SEQUENCE { 5123 r INTEGER, 5124 s INTEGER } 5126 dhpublicnumber OBJECT IDENTIFIER ::= { 5127 iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 } 5129 DomainParameters ::= SEQUENCE { 5130 p INTEGER, -- odd prime, p=jq +1 5131 g INTEGER, -- generator, g 5132 q INTEGER, -- factor of p-1 5133 j INTEGER OPTIONAL, -- subgroup factor, j>= 2 5134 validationParms ValidationParms OPTIONAL } 5136 ValidationParms ::= SEQUENCE { 5137 seed BIT STRING, 5138 pgenCounter INTEGER } 5140 id-dsa OBJECT IDENTIFIER ::= { 5141 iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 } 5143 Dss-Parms ::= SEQUENCE { 5144 p INTEGER, 5145 q INTEGER, 5146 g INTEGER } 5147 -- The ASN.1 in this section supports the Name type 5148 -- and the directoryAttribute extension 5150 -- attribute data types -- 5152 Attribute ::= SEQUENCE { 5153 type ATTRIBUTE.&id ({SupportedAttributes}), 5154 values SET SIZE (1 .. MAX) OF ATTRIBUTE.&Type 5155 ({SupportedAttributes}{@type})} 5157 AttributeTypeAndValue ::= SEQUENCE { 5158 type ATTRIBUTE.&id ({SupportedAttributes}), 5159 value ATTRIBUTE.&Type ({SupportedAttributes}{@type})} 5161 -- naming data types -- 5163 Name ::= CHOICE { -- only one possibility for now -- 5164 rdnSequence RDNSequence } 5166 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 5168 RelativeDistinguishedName ::= 5169 SET SIZE (1 .. MAX) OF AttributeTypeAndValue 5171 ID ::= OBJECT IDENTIFIER 5173 -- ATTRIBUTE information object class specification 5174 -- Note: This has been greatly simplified for PKIX !! 5176 ATTRIBUTE ::= CLASS { 5177 &Type, 5178 &id OBJECT IDENTIFIER UNIQUE } 5179 WITH SYNTAX { 5180 WITH SYNTAX &Type ID &id } 5182 -- suggested naming attributes 5183 -- Definition of the following information object set may be 5184 -- augmented to meet local requirements. Note that deleting 5185 -- members of the set may prevent interoperability with 5186 -- conforming implementations. 5188 SupportedAttributes ATTRIBUTE ::= { 5189 name | commonName | surname | givenName | initials | 5190 generationQualifier | dnQualifier | countryName | 5191 localityName | stateOrProvinceName | organizationName | 5192 organizationalUnitName | title | pkcs9email } 5194 name ATTRIBUTE ::= { 5195 WITH SYNTAX DirectoryString { ub-name } 5196 ID id-at-name } 5198 commonName ATTRIBUTE ::= { 5199 WITH SYNTAX DirectoryString {ub-common-name} 5200 ID id-at-commonName } 5202 surname ATTRIBUTE ::= { 5203 WITH SYNTAX DirectoryString {ub-name} 5204 ID id-at-surname } 5206 givenName ATTRIBUTE ::= { 5207 WITH SYNTAX DirectoryString {ub-name} 5208 ID id-at-givenName } 5210 initials ATTRIBUTE ::= { 5211 WITH SYNTAX DirectoryString {ub-name} 5212 ID id-at-initials } 5214 generationQualifier ATTRIBUTE ::= { 5215 WITH SYNTAX DirectoryString {ub-name} 5216 ID id-at-generationQualifier} 5218 dnQualifier ATTRIBUTE ::= { 5219 WITH SYNTAX PrintableString 5220 ID id-at-dnQualifier } 5222 countryName ATTRIBUTE ::= { 5223 WITH SYNTAX PrintableString (SIZE (2)) 5224 -- IS 3166 codes only 5225 ID id-at-countryName } 5227 localityName ATTRIBUTE ::= { 5228 WITH SYNTAX DirectoryString {ub-locality-name} 5229 ID id-at-localityName } 5231 stateOrProvinceName ATTRIBUTE ::= { 5232 WITH SYNTAX DirectoryString {ub-state-name} 5233 ID id-at-stateOrProvinceName } 5235 organizationName ATTRIBUTE ::= { 5236 WITH SYNTAX DirectoryString {ub-organization-name} 5237 ID id-at-organizationName } 5239 organizationalUnitName ATTRIBUTE ::= { 5240 WITH SYNTAX DirectoryString {ub-organizational-unit-name} 5241 ID id-at-organizationalUnitName } 5243 title ATTRIBUTE ::= { 5244 WITH SYNTAX DirectoryString {ub-title} 5245 ID id-at-title } 5247 -- Legacy attributes 5249 pkcs9email ATTRIBUTE ::= { 5250 WITH SYNTAX PHGString, 5251 ID emailAddress } 5253 PHGString ::= IA5String (SIZE(1..ub-emailaddress-length)) 5255 pkcs-9 OBJECT IDENTIFIER ::= 5256 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 } 5258 emailAddress OBJECT IDENTIFIER ::= { pkcs-9 1 } 5260 -- object identifiers for Name type and directory attribute support 5262 -- Object identifier assignments -- 5264 id-at OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 4} 5266 -- Attributes -- 5268 id-at-commonName OBJECT IDENTIFIER ::= {id-at 3} 5269 id-at-surname OBJECT IDENTIFIER ::= {id-at 4} 5270 id-at-countryName OBJECT IDENTIFIER ::= {id-at 6} 5271 id-at-localityName OBJECT IDENTIFIER ::= {id-at 7} 5272 id-at-stateOrProvinceName OBJECT IDENTIFIER ::= {id-at 8} 5273 id-at-organizationName OBJECT IDENTIFIER ::= {id-at 10} 5274 id-at-organizationalUnitName OBJECT IDENTIFIER ::= {id-at 11} 5275 id-at-title OBJECT IDENTIFIER ::= {id-at 12} 5276 id-at-name OBJECT IDENTIFIER ::= {id-at 41} 5277 id-at-givenName OBJECT IDENTIFIER ::= {id-at 42} 5278 id-at-initials OBJECT IDENTIFIER ::= {id-at 43} 5279 id-at-generationQualifier OBJECT IDENTIFIER ::= {id-at 44} 5280 id-at-dnQualifier OBJECT IDENTIFIER ::= {id-at 46} 5282 -- Directory string type, used extensively in Name types -- 5284 DirectoryString { INTEGER:maxSize } ::= CHOICE { 5285 teletexString TeletexString (SIZE (1..maxSize)), 5286 printableString PrintableString (SIZE (1..maxSize)), 5287 universalString UniversalString (SIZE (1..maxSize)), 5288 bmpString BMPString (SIZE(1..maxSize)), 5289 utf8String UTF8String (SIZE(1..maxSize)) 5290 } 5292 -- End of ASN.1 for Name type and directory attribute support -- 5294 -- The ASN.1 in this section supports X.400 style names -- 5295 -- for implementations that use the x400Address component -- 5296 -- of GeneralName. -- 5298 ORAddress ::= SEQUENCE { 5299 built-in-standard-attributes BuiltInStandardAttributes, 5300 built-in-domain-defined-attributes 5301 BuiltInDomainDefinedAttributes OPTIONAL, 5302 -- see also teletex-domain-defined-attributes 5303 extension-attributes ExtensionAttributes OPTIONAL } 5305 -- The OR-address is semantically absent from the OR-name if the 5306 -- built-in-standard-attribute sequence is empty and the 5307 -- built-in-domain-defined-attributes and extension-attributes are 5308 -- both omitted. 5310 -- Built-in Standard Attributes 5312 BuiltInStandardAttributes ::= SEQUENCE { 5313 country-name CountryName OPTIONAL, 5314 administration-domain-name AdministrationDomainName OPTIONAL, 5315 network-address [0] NetworkAddress OPTIONAL, 5316 -- see also extended-network-address 5317 terminal-identifier [1] TerminalIdentifier OPTIONAL, 5318 private-domain-name [2] PrivateDomainName OPTIONAL, 5319 organization-name [3] OrganizationName OPTIONAL, 5320 -- see also teletex-organization-name 5321 numeric-user-identifier [4] NumericUserIdentifier OPTIONAL, 5322 personal-name [5] PersonalName OPTIONAL, 5323 -- see also teletex-personal-name 5324 organizational-unit-names [6] OrganizationalUnitNames OPTIONAL 5325 -- see also teletex-organizational-unit-names -- } 5327 CountryName ::= [APPLICATION 1] CHOICE { 5328 x121-dcc-code NumericString 5329 (SIZE (ub-country-name-numeric-length)), 5330 iso-3166-alpha2-code PrintableString 5331 (SIZE (ub-country-name-alpha-length)) } 5333 AdministrationDomainName ::= [APPLICATION 2] CHOICE { 5334 numeric NumericString (SIZE (0..ub-domain-name-length)), 5335 printable PrintableString (SIZE (0..ub-domain-name-length)) } 5337 NetworkAddress ::= X121Address 5338 -- see also extended-network-address 5339 X121Address ::= NumericString (SIZE (1..ub-x121-address-length)) 5341 TerminalIdentifier ::= PrintableString (SIZE (1..ub-terminal-id-length)) 5343 PrivateDomainName ::= CHOICE { 5344 numeric NumericString (SIZE (1..ub-domain-name-length)), 5345 printable PrintableString (SIZE (1..ub-domain-name-length)) } 5347 OrganizationName ::= PrintableString 5348 (SIZE (1..ub-organization-name-length)) 5349 -- see also teletex-organization-name 5351 NumericUserIdentifier ::= NumericString 5352 (SIZE (1..ub-numeric-user-id-length)) 5354 PersonalName ::= SET { 5355 surname [0] PrintableString (SIZE (1..ub-surname-length)), 5356 given-name [1] PrintableString 5357 (SIZE (1..ub-given-name-length)) OPTIONAL, 5358 initials [2] PrintableString 5359 (SIZE (1..ub-initials-length)) OPTIONAL, 5360 generation-qualifier [3] PrintableString 5361 (SIZE (1..ub-generation-qualifier-length)) OPTIONAL} 5362 -- see also teletex-personal-name 5364 OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units) 5365 OF OrganizationalUnitName 5366 -- see also teletex-organizational-unit-names 5368 OrganizationalUnitName ::= PrintableString (SIZE 5369 (1..ub-organizational-unit-name-length)) 5371 -- Built-in Domain-defined Attributes 5372 BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE 5373 (1..ub-domain-defined-attributes) OF 5374 BuiltInDomainDefinedAttribute 5376 BuiltInDomainDefinedAttribute ::= SEQUENCE { 5377 type PrintableString (SIZE 5378 (1..ub-domain-defined-attribute-type-length)), 5379 value PrintableString (SIZE 5380 (1..ub-domain-defined-attribute-value-length)) } 5382 -- Extension Attributes 5384 ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) 5385 OF ExtensionAttribute 5386 ExtensionAttribute ::= SEQUENCE { 5387 extension-attribute-type [0] EXTENSION-ATTRIBUTE.&id 5388 ({ExtensionAttributeTable}), 5389 extension-attribute-value [1] EXTENSION-ATTRIBUTE.&Type 5390 ({ExtensionAttributeTable} {@extension-attribute-type}) } 5392 EXTENSION-ATTRIBUTE ::= CLASS { 5393 &id INTEGER (0..ub-extension-attributes) UNIQUE, 5394 &Type } 5395 WITH SYNTAX {&Type IDENTIFIED BY &id} 5397 ExtensionAttributeTable EXTENSION-ATTRIBUTE ::= { 5398 common-name | 5399 teletex-common-name | 5400 teletex-organization-name | 5401 teletex-personal-name | 5402 teletex-organizational-unit-names | 5403 teletex-domain-defined-attributes | 5404 pds-name | 5405 physical-delivery-country-name | 5406 postal-code | 5407 physical-delivery-office-name | 5408 physical-delivery-office-number | 5409 extension-OR-address-components | 5410 physical-delivery-personal-name | 5411 physical-delivery-organization-name | 5412 extension-physical-delivery-address-components | 5413 unformatted-postal-address | 5414 street-address | 5415 post-office-box-address | 5416 poste-restante-address | 5417 unique-postal-name | 5418 local-postal-attributes | 5419 extended-network-address | 5420 terminal-type } 5422 -- Extension Standard Attributes 5424 common-name EXTENSION-ATTRIBUTE ::= {CommonName IDENTIFIED BY 1} 5426 CommonName ::= PrintableString (SIZE (1..ub-common-name-length)) 5428 teletex-common-name EXTENSION-ATTRIBUTE ::= 5429 {TeletexCommonName IDENTIFIED BY 2} 5431 TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length)) 5433 teletex-organization-name EXTENSION-ATTRIBUTE ::= 5434 {TeletexOrganizationName IDENTIFIED BY 3} 5436 TeletexOrganizationName ::= 5437 TeletexString (SIZE (1..ub-organization-name-length)) 5439 teletex-personal-name EXTENSION-ATTRIBUTE ::= 5440 {TeletexPersonalName IDENTIFIED BY 4} 5442 TeletexPersonalName ::= SET { 5443 surname [0] TeletexString (SIZE (1..ub-surname-length)), 5444 given-name [1] TeletexString 5445 (SIZE (1..ub-given-name-length)) OPTIONAL, 5446 initials [2] TeletexString (SIZE (1..ub-initials-length)) OPTIONAL, 5447 generation-qualifier [3] TeletexString (SIZE 5448 (1..ub-generation-qualifier-length)) OPTIONAL } 5450 teletex-organizational-unit-names EXTENSION-ATTRIBUTE ::= 5451 {TeletexOrganizationalUnitNames IDENTIFIED BY 5} 5453 TeletexOrganizationalUnitNames ::= SEQUENCE SIZE 5454 (1..ub-organizational-units) OF TeletexOrganizationalUnitName 5456 TeletexOrganizationalUnitName ::= TeletexString 5457 (SIZE (1..ub-organizational-unit-name-length)) 5459 pds-name EXTENSION-ATTRIBUTE ::= {PDSName IDENTIFIED BY 7} 5461 PDSName ::= PrintableString (SIZE (1..ub-pds-name-length)) 5463 physical-delivery-country-name EXTENSION-ATTRIBUTE ::= 5464 {PhysicalDeliveryCountryName IDENTIFIED BY 8} 5466 PhysicalDeliveryCountryName ::= CHOICE { 5467 x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)), 5468 iso-3166-alpha2-code PrintableString 5469 (SIZE (ub-country-name-alpha-length)) } 5471 postal-code EXTENSION-ATTRIBUTE ::= {PostalCode IDENTIFIED BY 9} 5473 PostalCode ::= CHOICE { 5474 numeric-code NumericString (SIZE (1..ub-postal-code-length)), 5475 printable-code PrintableString (SIZE (1..ub-postal-code-length)) } 5477 physical-delivery-office-name EXTENSION-ATTRIBUTE ::= 5478 {PhysicalDeliveryOfficeName IDENTIFIED BY 10} 5480 PhysicalDeliveryOfficeName ::= PDSParameter 5482 physical-delivery-office-number EXTENSION-ATTRIBUTE ::= 5483 {PhysicalDeliveryOfficeNumber IDENTIFIED BY 11} 5485 PhysicalDeliveryOfficeNumber ::= PDSParameter 5487 extension-OR-address-components EXTENSION-ATTRIBUTE ::= 5488 {ExtensionORAddressComponents IDENTIFIED BY 12} 5490 ExtensionORAddressComponents ::= PDSParameter 5492 physical-delivery-personal-name EXTENSION-ATTRIBUTE ::= 5493 {PhysicalDeliveryPersonalName IDENTIFIED BY 13} 5495 PhysicalDeliveryPersonalName ::= PDSParameter 5497 physical-delivery-organization-name EXTENSION-ATTRIBUTE ::= 5498 {PhysicalDeliveryOrganizationName IDENTIFIED BY 14} 5500 PhysicalDeliveryOrganizationName ::= PDSParameter 5502 extension-physical-delivery-address-components EXTENSION-ATTRIBUTE ::= 5503 {ExtensionPhysicalDeliveryAddressComponents IDENTIFIED BY 15} 5505 ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter 5507 unformatted-postal-address EXTENSION-ATTRIBUTE ::= 5508 {UnformattedPostalAddress IDENTIFIED BY 16} 5510 UnformattedPostalAddress ::= SET { 5511 printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) OF 5512 PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL, 5513 teletex-string TeletexString (SIZE 5514 (1..ub-unformatted-address-length)) OPTIONAL } 5516 street-address EXTENSION-ATTRIBUTE ::= 5517 {StreetAddress IDENTIFIED BY 17} 5519 StreetAddress ::= PDSParameter 5521 post-office-box-address EXTENSION-ATTRIBUTE ::= 5522 {PostOfficeBoxAddress IDENTIFIED BY 18} 5524 PostOfficeBoxAddress ::= PDSParameter 5526 poste-restante-address EXTENSION-ATTRIBUTE ::= 5527 {PosteRestanteAddress IDENTIFIED BY 19} 5529 PosteRestanteAddress ::= PDSParameter 5531 unique-postal-name EXTENSION-ATTRIBUTE ::= 5532 {UniquePostalName IDENTIFIED BY 20} 5534 UniquePostalName ::= PDSParameter 5536 local-postal-attributes EXTENSION-ATTRIBUTE ::= 5537 {LocalPostalAttributes IDENTIFIED BY 21} 5539 LocalPostalAttributes ::= PDSParameter 5541 PDSParameter ::= SET { 5542 printable-string PrintableString 5543 (SIZE(1..ub-pds-parameter-length)) OPTIONAL, 5544 teletex-string TeletexString 5545 (SIZE(1..ub-pds-parameter-length)) OPTIONAL } 5547 extended-network-address EXTENSION-ATTRIBUTE ::= 5548 {ExtendedNetworkAddress IDENTIFIED BY 22} 5550 ExtendedNetworkAddress ::= CHOICE { 5551 e163-4-address SEQUENCE { 5552 number [0] NumericString 5553 (SIZE (1..ub-e163-4-number-length)), 5554 sub-address [1] NumericString 5555 (SIZE (1..ub-e163-4-sub-address-length)) OPTIONAL}, 5556 psap-address [0] PresentationAddress } 5558 PresentationAddress ::= SEQUENCE { 5559 pSelector [0] EXPLICIT OCTET STRING OPTIONAL, 5560 sSelector [1] EXPLICIT OCTET STRING OPTIONAL, 5561 tSelector [2] EXPLICIT OCTET STRING OPTIONAL, 5562 nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING} 5564 terminal-type EXTENSION-ATTRIBUTE ::= {TerminalType IDENTIFIED BY 23} 5566 TerminalType ::= INTEGER { 5567 telex (3), 5568 teletex (4), 5569 g3-facsimile (5), 5570 g4-facsimile (6), 5571 ia5-terminal (7), 5572 videotex (8) } (0..ub-integer-options) 5574 -- Extension Domain-defined Attributes 5576 teletex-domain-defined-attributes EXTENSION-ATTRIBUTE ::= 5577 {TeletexDomainDefinedAttributes IDENTIFIED BY 6} 5579 TeletexDomainDefinedAttributes ::= SEQUENCE SIZE 5580 (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute 5582 TeletexDomainDefinedAttribute ::= SEQUENCE { 5583 type TeletexString 5584 (SIZE (1..ub-domain-defined-attribute-type-length)), 5585 value TeletexString 5586 (SIZE (1..ub-domain-defined-attribute-value-length)) } 5588 -- specifications of Upper Bounds 5589 -- shall be regarded as mandatory 5590 -- from Annex B of ITU-T X.411 5591 -- Reference Definition of MTS Parameter Upper Bounds 5593 -- Upper Bounds 5594 ub-name INTEGER ::= 32768 5595 ub-common-name INTEGER ::= 64 5596 ub-locality-name INTEGER ::= 128 5597 ub-state-name INTEGER ::= 128 5598 ub-organization-name INTEGER ::= 64 5599 ub-organizational-unit-name INTEGER ::= 64 5600 ub-title INTEGER ::= 64 5601 ub-match INTEGER ::= 128 5603 ub-emailaddress-length INTEGER ::= 128 5605 ub-common-name-length INTEGER ::= 64 5606 ub-country-name-alpha-length INTEGER ::= 2 5607 ub-country-name-numeric-length INTEGER ::= 3 5608 ub-domain-defined-attributes INTEGER ::= 4 5609 ub-domain-defined-attribute-type-length INTEGER ::= 8 5610 ub-domain-defined-attribute-value-length INTEGER ::= 128 5611 ub-domain-name-length INTEGER ::= 16 5612 ub-extension-attributes INTEGER ::= 256 5613 ub-e163-4-number-length INTEGER ::= 15 5614 ub-e163-4-sub-address-length INTEGER ::= 40 5615 ub-generation-qualifier-length INTEGER ::= 3 5616 ub-given-name-length INTEGER ::= 16 5617 ub-initials-length INTEGER ::= 5 5618 ub-integer-options INTEGER ::= 256 5619 ub-numeric-user-id-length INTEGER ::= 32 5620 ub-organization-name-length INTEGER ::= 64 5621 ub-organizational-unit-name-length INTEGER ::= 32 5622 ub-organizational-units INTEGER ::= 4 5623 ub-pds-name-length INTEGER ::= 16 5624 ub-pds-parameter-length INTEGER ::= 30 5625 ub-pds-physical-address-lines INTEGER ::= 6 5626 ub-postal-code-length INTEGER ::= 16 5627 ub-surname-length INTEGER ::= 40 5628 ub-terminal-id-length INTEGER ::= 24 5629 ub-unformatted-address-length INTEGER ::= 180 5630 ub-x121-address-length INTEGER ::= 16 5632 -- Note - upper bounds on TeletexString are measured in characters. 5633 -- A significantly greater number of octets will be required to hold 5634 -- such a value. As a minimum, 16 octets, or twice the specified upper 5635 -- bound, whichever is the larger, should be allowed. 5637 END 5638 B.2 Implicitly Tagged Module, 1993 Syntax 5640 PKIX1Implicit93 {iso(1) identified-organization(3) dod(6) internet(1) 5641 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-93(4)} 5643 DEFINITIONS IMPLICIT TAGS::= 5645 BEGIN 5647 --EXPORTS ALL -- 5649 IMPORTS 5650 id-pe, id-qt, id-kp, id-ad, id-qt-unotice, 5651 ORAddress, Name, RelativeDistinguishedName, 5652 CertificateSerialNumber, CertificateList, 5653 AlgorithmIdentifier, ub-name, DirectoryString, 5654 Attribute, EXTENSION 5655 FROM PKIX1Explicit93 {iso(1) identified-organization(3) 5656 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 5657 id-mod(0) id-pkix1-explicit-93(3)}; 5659 -- Key and policy information extensions -- 5661 authorityKeyIdentifier EXTENSION ::= { 5662 SYNTAX AuthorityKeyIdentifier 5663 IDENTIFIED BY id-ce-authorityKeyIdentifier } 5665 AuthorityKeyIdentifier ::= SEQUENCE { 5666 keyIdentifier [0] KeyIdentifier OPTIONAL, 5667 authorityCertIssuer [1] GeneralNames OPTIONAL, 5668 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 5669 ( WITH COMPONENTS {..., authorityCertIssuer PRESENT, 5670 authorityCertSerialNumber PRESENT} | 5671 WITH COMPONENTS {..., authorityCertIssuer ABSENT, 5672 authorityCertSerialNumber ABSENT} ) 5674 KeyIdentifier ::= OCTET STRING 5676 subjectKeyIdentifier EXTENSION ::= { 5677 SYNTAX SubjectKeyIdentifier 5678 IDENTIFIED BY id-ce-subjectKeyIdentifier } 5680 SubjectKeyIdentifier ::= KeyIdentifier 5682 keyUsage EXTENSION ::= { 5683 SYNTAX KeyUsage 5684 IDENTIFIED BY id-ce-keyUsage } 5686 KeyUsage ::= BIT STRING { 5687 digitalSignature (0), 5688 nonRepudiation (1), 5689 keyEncipherment (2), 5690 dataEncipherment (3), 5691 keyAgreement (4), 5692 keyCertSign (5), 5693 cRLSign (6), 5694 encipherOnly (7), 5695 decipherOnly (8) } 5697 extendedKeyUsage EXTENSION ::= { 5698 SYNTAX SEQUENCE SIZE (1..MAX) OF KeyPurposeId 5699 IDENTIFIED BY id-ce-extKeyUsage } 5701 KeyPurposeId ::= OBJECT IDENTIFIER 5703 -- PKIX-defined extended key purpose OIDs 5704 id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } 5705 id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } 5706 id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } 5707 id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } 5708 id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 } 5709 id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 } 5710 id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 } 5711 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 5713 privateKeyUsagePeriod EXTENSION ::= { 5714 SYNTAX PrivateKeyUsagePeriod 5715 IDENTIFIED BY { id-ce-privateKeyUsagePeriod } } 5717 PrivateKeyUsagePeriod ::= SEQUENCE { 5718 notBefore [0] GeneralizedTime OPTIONAL, 5719 notAfter [1] GeneralizedTime OPTIONAL } 5720 ( WITH COMPONENTS {..., notBefore PRESENT} | 5721 WITH COMPONENTS {..., notAfter PRESENT} ) 5723 certificatePolicies EXTENSION ::= { 5724 SYNTAX CertificatePoliciesSyntax 5725 IDENTIFIED BY id-ce-certificatePolicies } 5727 CertificatePoliciesSyntax ::= 5728 SEQUENCE SIZE (1..MAX) OF PolicyInformation 5730 PolicyInformation ::= SEQUENCE { 5731 policyIdentifier CertPolicyId, 5732 policyQualifiers SEQUENCE SIZE (1..MAX) OF 5733 PolicyQualifierInfo OPTIONAL } 5735 CertPolicyId ::= OBJECT IDENTIFIER 5737 PolicyQualifierInfo ::= SEQUENCE { 5738 policyQualifierId CERT-POLICY-QUALIFIER.&id 5739 ({SupportedPolicyQualifiers}), 5740 qualifier CERT-POLICY-QUALIFIER.&Qualifier 5741 ({SupportedPolicyQualifiers} 5742 {@policyQualifierId})OPTIONAL } 5744 SupportedPolicyQualifiers CERT-POLICY-QUALIFIER ::= { noticeToUser | 5745 pointerToCPS } 5747 CERT-POLICY-QUALIFIER ::= CLASS { 5748 &id OBJECT IDENTIFIER UNIQUE, 5749 &Qualifier OPTIONAL } 5750 WITH SYNTAX { 5751 POLICY-QUALIFIER-ID &id 5752 [QUALIFIER-TYPE &Qualifier] } 5754 policyMappings EXTENSION ::= { 5755 SYNTAX PolicyMappingsSyntax 5756 IDENTIFIED BY id-ce-policyMappings } 5758 PolicyMappingsSyntax ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 5759 issuerDomainPolicy CertPolicyId, 5760 subjectDomainPolicy CertPolicyId } 5762 -- Certificate subject and certificate issuer attributes extensions -- 5764 subjectAltName EXTENSION ::= { 5765 SYNTAX GeneralNames 5766 IDENTIFIED BY id-ce-subjectAltName } 5768 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 5770 GeneralName ::= CHOICE { 5771 otherName [0] INSTANCE OF OTHER-NAME, 5772 rfc822Name [1] IA5String, 5773 dNSName [2] IA5String, 5774 x400Address [3] ORAddress, 5775 directoryName [4] Name, 5776 ediPartyName [5] EDIPartyName, 5777 uniformResourceIdentifier [6] IA5String, 5778 iPAddress [7] OCTET STRING, 5779 registeredID [8] OBJECT IDENTIFIER } 5781 OTHER-NAME ::= TYPE-IDENTIFIER 5782 EDIPartyName ::= SEQUENCE { 5783 nameAssigner [0] DirectoryString {ub-name} OPTIONAL, 5784 partyName [1] DirectoryString {ub-name} } 5786 issuerAltName EXTENSION ::= { 5787 SYNTAX GeneralNames 5788 IDENTIFIED BY id-ce-issuerAltName } 5790 subjectDirectoryAttributes EXTENSION ::= { 5791 SYNTAX AttributesSyntax 5792 IDENTIFIED BY id-ce-subjectDirectoryAttributes } 5794 AttributesSyntax ::= SEQUENCE SIZE (1..MAX) OF Attribute 5796 -- Certification path constraints extensions -- 5798 basicConstraints EXTENSION ::= { 5799 SYNTAX BasicConstraintsSyntax 5800 IDENTIFIED BY id-ce-basicConstraints } 5802 BasicConstraintsSyntax ::= SEQUENCE { 5803 cA BOOLEAN DEFAULT FALSE, 5804 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 5806 nameConstraints EXTENSION ::= { 5807 SYNTAX NameConstraintsSyntax 5808 IDENTIFIED BY id-ce-nameConstraints } 5810 NameConstraintsSyntax ::= SEQUENCE { 5811 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 5812 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 5814 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 5816 GeneralSubtree ::= SEQUENCE { 5817 base GeneralName, 5818 minimum [0] BaseDistance DEFAULT 0, 5819 maximum [1] BaseDistance OPTIONAL } 5821 BaseDistance ::= INTEGER (0..MAX) 5823 policyConstraints EXTENSION ::= { 5824 SYNTAX PolicyConstraintsSyntax 5825 IDENTIFIED BY id-ce-policyConstraints } 5827 PolicyConstraintsSyntax ::= SEQUENCE { 5828 requireExplicitPolicy [0] SkipCerts OPTIONAL, 5829 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 5831 SkipCerts ::= INTEGER (0..MAX) 5833 -- Basic CRL extensions -- 5835 cRLNumber EXTENSION ::= { 5836 SYNTAX CRLNumber 5837 IDENTIFIED BY id-ce-cRLNumber } 5839 CRLNumber ::= INTEGER (0..MAX) 5841 reasonCode EXTENSION ::= { 5842 SYNTAX CRLReason 5843 IDENTIFIED BY id-ce-reasonCode } 5845 CRLReason ::= ENUMERATED { 5846 unspecified (0), 5847 keyCompromise (1), 5848 cACompromise (2), 5849 affiliationChanged (3), 5850 superseded (4), 5851 cessationOfOperation (5), 5852 certificateHold (6), 5853 removeFromCRL (8) } 5855 instructionCode EXTENSION ::= { 5856 SYNTAX HoldInstruction 5857 IDENTIFIED BY id-ce-instructionCode } 5859 HoldInstruction ::= OBJECT IDENTIFIER 5861 -- holdinstructions described in this specification, from ANSI x9 5863 -- ANSI x9 arc holdinstruction arc 5864 holdInstruction OBJECT IDENTIFIER ::= { 5865 joint-iso-ccitt(2) member-body(2) us(840) x9cm(10040) 2} 5867 -- ANSI X9 holdinstructions referenced by this standard 5868 id-holdinstruction-none OBJECT IDENTIFIER ::= {holdInstruction 1} 5869 id-holdinstruction-callissuer OBJECT IDENTIFIER ::= {holdInstruction 2} 5870 id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3} 5872 invalidityDate EXTENSION ::= { 5873 SYNTAX GeneralizedTime 5874 IDENTIFIED BY id-ce-invalidityDate } 5876 -- CRL distribution points and delta-CRL extensions -- 5878 cRLDistributionPoints EXTENSION ::= { 5879 SYNTAX CRLDistPointsSyntax 5880 IDENTIFIED BY id-ce-cRLDistributionPoints } 5882 CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 5884 DistributionPoint ::= SEQUENCE { 5885 distributionPoint [0] DistributionPointName OPTIONAL, 5886 reasons [1] ReasonFlags OPTIONAL, 5887 cRLIssuer [2] GeneralNames OPTIONAL } 5889 DistributionPointName ::= CHOICE { 5890 fullName [0] GeneralNames, 5891 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 5893 ReasonFlags ::= BIT STRING { 5894 unused (0), 5895 keyCompromise (1), 5896 caCompromise (2), 5897 affiliationChanged (3), 5898 superseded (4), 5899 cessationOfOperation (5), 5900 certificateHold (6) } 5902 issuingDistributionPoint EXTENSION ::= { 5903 SYNTAX IssuingDistPointSyntax 5904 IDENTIFIED BY id-ce-issuingDistributionPoint } 5906 IssuingDistPointSyntax ::= SEQUENCE { 5907 distributionPoint [0] DistributionPointName OPTIONAL, 5908 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 5909 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 5910 onlySomeReasons [3] ReasonFlags OPTIONAL, 5911 indirectCRL [4] BOOLEAN DEFAULT FALSE } 5913 certificateIssuer EXTENSION ::= { 5914 SYNTAX GeneralNames 5915 IDENTIFIED BY id-ce-certificateIssuer } 5917 deltaCRLIndicator EXTENSION ::= { 5918 SYNTAX BaseCRLNumber 5919 IDENTIFIED BY id-ce-deltaCRLIndicator } 5921 BaseCRLNumber ::= CRLNumber 5923 -- Object identifier assignments for ISO certificate extensions -- 5924 id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 5926 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= {id-ce 9} 5927 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= {id-ce 14} 5928 id-ce-keyUsage OBJECT IDENTIFIER ::= {id-ce 15} 5929 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= {id-ce 16} 5930 id-ce-subjectAltName OBJECT IDENTIFIER ::= {id-ce 17} 5931 id-ce-issuerAltName OBJECT IDENTIFIER ::= {id-ce 18} 5932 id-ce-basicConstraints OBJECT IDENTIFIER ::= {id-ce 19} 5933 id-ce-cRLNumber OBJECT IDENTIFIER ::= {id-ce 20} 5934 id-ce-reasonCode OBJECT IDENTIFIER ::= {id-ce 21} 5935 id-ce-instructionCode OBJECT IDENTIFIER ::= {id-ce 23} 5936 id-ce-invalidityDate OBJECT IDENTIFIER ::= {id-ce 24} 5937 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= {id-ce 27} 5938 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= {id-ce 28} 5939 id-ce-certificateIssuer OBJECT IDENTIFIER ::= {id-ce 29} 5940 id-ce-nameConstraints OBJECT IDENTIFIER ::= {id-ce 30} 5941 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31} 5942 id-ce-certificatePolicies OBJECT IDENTIFIER ::= {id-ce 32} 5943 id-ce-policyMappings OBJECT IDENTIFIER ::= {id-ce 33} 5944 id-ce-policyConstraints OBJECT IDENTIFIER ::= {id-ce 36} 5945 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= {id-ce 35} 5946 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 5947 anyPolicy OBJECT IDENTIFIER ::= {id-ce-certificate-policies 0} 5949 -- PKIX 1 extensions 5951 authorityInfoAccess EXTENSION ::= { 5952 SYNTAX AuthorityInfoAccessSyntax 5953 IDENTIFIED BY id-pe-authorityInfoAccess } 5955 AuthorityInfoAccessSyntax ::= 5956 SEQUENCE SIZE (1..MAX) OF AccessDescription 5958 AccessDescription ::= SEQUENCE { 5959 accessMethod OBJECT IDENTIFIER, 5960 accessLocation GeneralName } 5962 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 5964 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 5965 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 5967 -- PKIX policy qualifier definitions 5969 noticeToUser CERT-POLICY-QUALIFIER ::= { 5970 POLICY-QUALIFIER-ID id-qt-cps QUALIFIER-TYPE CPSuri} 5972 pointerToCPS CERT-POLICY-QUALIFIER ::= { 5973 POLICY-QUALIFIER-ID id-qt-unotice QUALIFIER-TYPE UserNotice} 5975 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 5976 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 5978 CPSuri ::= IA5String 5980 UserNotice ::= SEQUENCE { 5981 noticeRef NoticeReference OPTIONAL, 5982 explicitText DisplayText OPTIONAL} 5984 NoticeReference ::= SEQUENCE { 5985 organization DisplayText, 5986 noticeNumbers SEQUENCE OF INTEGER } 5988 DisplayText ::= CHOICE { 5989 ia5String IA5String (SIZE (1..200)), 5990 visibleString VisibleString (SIZE (1..200)), 5991 bmpString BMPString (SIZE (1..200)), 5992 utf8String UTF8String (SIZE (1..200)) } 5994 END 5996 Appendix C. ASN.1 Notes 5998 The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 5999 constructs. A valid ASN.1 sequence will have zero or more entries. 6000 The SIZE (1..MAX) construct constrains the sequence to have at least 6001 one entry. MAX indicates the upper bound is unspecified. Implementa- 6002 tions are free to choose an upper bound that suits their environment. 6004 The construct "positiveInt ::= INTEGER (0..MAX)" defines positiveInt 6005 as a subtype of INTEGER containing integers greater than or equal to 6006 zero. The upper bound is unspecified. Implementations are free to 6007 select an upper bound that suits their environment. 6009 The character string type PrintableString supports a very basic Latin 6010 character set: the lower case letters 'a' through 'z', upper case 6011 letters 'A' through 'Z', the digits '0' through '9', eleven special 6012 characters ' " ( ) + , - . / : ? and space. 6014 The character string type TeletexString is a superset of Printable- 6015 String. TeletexString supports a fairly standard (ascii-like) Latin 6016 character set, Latin characters with non-spacing accents and Japanese 6017 characters. 6019 The character string type UniversalString supports any of the 6020 characters allowed by ISO 10646-1. ISO 10646 is the Universal 6021 multiple-octet coded Character Set (UCS). ISO 10646-1 specifes the 6022 architecture and the "basic multilingual plane" - a large standard 6023 character set which includes all major world character standards. 6025 The character string type UTF8String will be introduced in the 1998 6026 version of ASN.1. UTF8String is a universal type and has been 6027 assigned tag number 12. The content of UTF8String was defined by RFC 6028 2044 and updated in RFC 2279, "UTF-8, a transformation Format of ISO 6029 10646." ISO is expected to formally add UTF8String to the list of 6030 choices for DirectoryString in 1998 as well. 6032 In anticipation of these changes, and in conformance with IETF Best 6033 Practices codified in RFC 2277, IETF Policy on Character Sets and 6034 Languages, this document includes UTF8String as a choice in Directo- 6035 ryString and the CPS qualifier extensions. 6037 Appendix D. Examples 6039 This section contains four examples: three certificates and a CRL. 6040 The first two certificates and the CRL comprise a minimal certifica- 6041 tion path. 6043 Section D.1 contains an annotated hex dump of a "self-signed" certi- 6044 ficate issued by a CA whose distinguished name is 6045 cn=us,o=gov,ou=nist. The certificate contains a DSA public key with 6046 parameters, and is signed by the corresponding DSA private key. 6048 Section D.2 contains an annotated hex dump of an end-entity certifi- 6049 cate. The end entity certificate contains a DSA public key, and is 6050 signed by the private key corresponding to the "self-signed" certifi- 6051 cate in section D.1. 6053 Section D.3 contains a dump of an end entity certificate which con- 6054 tains an RSA public key and is signed with RSA and MD5. This certi- 6055 ficate is not part of the minimal certification path. 6057 Section D.4 contains an annotated hex dump of a CRL. The CRL is 6058 issued by the CA whose distinguished name is cn=us,o=gov,ou=nist and 6059 the list of revoked certificates includes the end entity certificate 6060 presented in D.2. 6062 D.1 Certificate 6064 This section contains an annotated hex dump of a 699 byte version 3 6065 certificate. The certificate contains the following information: 6066 (a) the serial number is 17 (11 hex); 6067 (b) the certificate is signed with DSA and the SHA-1 hash algorithm; 6068 (c) the issuer's distinguished name is OU=nist; O=gov; C=US 6069 (d) and the subject's distinguished name is OU=nist; O=gov; C=US 6070 (e) the certificate was issued on June 30, 1997 and will expire on 6071 December 31, 1997; 6072 (f) the certificate contains a 1024 bit DSA public key with parame- 6073 ters; 6074 (g) the certificate contains a subject key identifier extension; and 6075 (h) the certificate is a CA certificate (as indicated through the 6076 basic constraints extension.) 6078 0000 30 82 02 b7 695: SEQUENCE 6079 0004 30 82 02 77 631: . SEQUENCE tbscertificate 6080 0008 a0 03 3: . . [0] 6081 0010 02 01 1: . . . INTEGER 2 6082 : 02 6083 0013 02 01 1: . . INTEGER 17 6084 : 11 6085 0016 30 09 9: . . SEQUENCE 6086 0018 06 07 7: . . . OID 1.2.840.10040.4.3: dsa-with-sha 6087 : 2a 86 48 ce 38 04 03 6088 0027 30 2a 42: . . SEQUENCE 6089 0029 31 0b 11: . . . SET 6090 0031 30 09 9: . . . . SEQUENCE 6091 0033 06 03 3: . . . . . OID 2.5.4.6: C 6092 : 55 04 06 6093 0038 13 02 2: . . . . . PrintableString 'US' 6094 : 55 53 6095 0042 31 0c 12: . . . SET 6096 0044 30 0a 10: . . . . SEQUENCE 6097 0046 06 03 3: . . . . . OID 2.5.4.10: O 6098 : 55 04 0a 6099 0051 13 03 3: . . . . . PrintableString 'gov' 6100 : 67 6f 76 6101 0056 31 0d 13: . . . SET 6102 0058 30 0b 11: . . . . SEQUENCE 6103 0060 06 03 3: . . . . . OID 2.5.4.11: OU 6104 : 55 04 0b 6105 0065 13 04 4: . . . . . PrintableString 'nist' 6106 : 6e 69 73 74 6107 0071 30 1e 30: . . SEQUENCE 6108 0073 17 0d 13: . . . UTCTime '970630000000Z' 6109 : 39 37 30 36 33 30 30 30 30 30 30 30 5a 6110 0088 17 0d 13: . . . UTCTime '971231000000Z' 6111 : 39 37 31 32 33 31 30 30 30 30 30 30 5a 6112 0103 30 2a 42: . . SEQUENCE 6113 0105 31 0b 11: . . . SET 6114 0107 30 09 9: . . . . SEQUENCE 6115 0109 06 03 3: . . . . . OID 2.5.4.6: C 6116 : 55 04 06 6117 0114 13 02 2: . . . . . PrintableString 'US' 6118 : 55 53 6119 0118 31 0c 12: . . . SET 6120 0120 30 0a 10: . . . . SEQUENCE 6121 0122 06 03 3: . . . . . OID 2.5.4.10: O 6122 : 55 04 0a 6123 0127 13 03 3: . . . . . PrintableString 'gov' 6124 : 67 6f 76 6125 0132 31 0d 13: . . . SET 6126 0134 30 0b 11: . . . . SEQUENCE 6127 0136 06 03 3: . . . . . OID 2.5.4.11: OU 6128 : 55 04 0b 6129 0141 13 04 4: . . . . . PrintableString 'nist' 6130 : 6e 69 73 74 6131 0147 30 82 01 b4 436: . . SEQUENCE 6132 0151 30 82 01 29 297: . . . SEQUENCE 6133 0155 06 07 7: . . . . OID 1.2.840.10040.4.1: dsa 6134 : 2a 86 48 ce 38 04 01 6135 0164 30 82 01 1c 284: . . . . SEQUENCE 6136 0168 02 81 80 128: . . . . . INTEGER 6137 : d4 38 02 c5 35 7b d5 0b a1 7e 5d 72 59 63 55 d3 6138 : 45 56 ea e2 25 1a 6b c5 a4 ab aa 0b d4 62 b4 d2 6139 : 21 b1 95 a2 c6 01 c9 c3 fa 01 6f 79 86 83 3d 03 6140 : 61 e1 f1 92 ac bc 03 4e 89 a3 c9 53 4a f7 e2 a6 6141 : 48 cf 42 1e 21 b1 5c 2b 3a 7f ba be 6b 5a f7 0a 6142 : 26 d8 8e 1b eb ec bf 1e 5a 3f 45 c0 bd 31 23 be 6143 : 69 71 a7 c2 90 fe a5 d6 80 b5 24 dc 44 9c eb 4d 6144 : f9 da f0 c8 e8 a2 4c 99 07 5c 8e 35 2b 7d 57 8d 6145 0299 02 14 20: . . . . . INTEGER 6146 : a7 83 9b f3 bd 2c 20 07 fc 4c e7 e8 9f f3 39 83 6147 : 51 0d dc dd 6148 0321 02 81 80 128: . . . . . INTEGER 6149 : 0e 3b 46 31 8a 0a 58 86 40 84 e3 a1 22 0d 88 ca 6150 : 90 88 57 64 9f 01 21 e0 15 05 94 24 82 e2 10 90 6151 : d9 e1 4e 10 5c e7 54 6b d4 0c 2b 1b 59 0a a0 b5 6152 : a1 7d b5 07 e3 65 7c ea 90 d8 8e 30 42 e4 85 bb 6153 : ac fa 4e 76 4b 78 0e df 6c e5 a6 e1 bd 59 77 7d 6154 : a6 97 59 c5 29 a7 b3 3f 95 3e 9d f1 59 2d f7 42 6155 : 87 62 3f f1 b8 6f c7 3d 4b b8 8d 74 c4 ca 44 90 6156 : cf 67 db de 14 60 97 4a d1 f7 6d 9e 09 94 c4 0d 6157 0452 03 81 84 132: . . . BIT STRING (0 unused bits) 6158 : 02 81 80 aa 98 ea 13 94 a2 db f1 5b 7f 98 2f 78 6159 : e7 d8 e3 b9 71 86 f6 80 2f 40 39 c3 da 3b 4b 13 6160 : 46 26 ee 0d 56 c5 a3 3a 39 b7 7d 33 c2 6b 5c 77 6161 : 92 f2 55 65 90 39 cd 1a 3c 86 e1 32 eb 25 bc 91 6162 : c4 ff 80 4f 36 61 bd cc e2 61 04 e0 7e 60 13 ca 6163 : c0 9c dd e0 ea 41 de 33 c1 f1 44 a9 bc 71 de cf 6164 : 59 d4 6e da 44 99 3c 21 64 e4 78 54 9d d0 7b ba 6165 : 4e f5 18 4d 5e 39 30 bf e0 d1 f6 f4 83 25 4f 14 6166 : aa 71 e1 6167 0587 a3 32 50: . . [3] 6168 0589 30 30 48: . . . SEQUENCE 6169 0591 30 0f 9: . . . . SEQUENCE 6170 0593 06 03 3: . . . . . OID 2.5.29.19: basicConstraints 6171 : 55 1d 13 6172 0598 01 01 1: . . . . . TRUE 6173 : ff 6174 0601 04 05 5: . . . . . OCTET STRING 6175 : 30 03 01 01 ff 6176 0608 30 1d 29: . SEQUENCE 6177 0610 06 03 3: . . . . . OID 2.5.29.14: subjectKeyIdentifier 6178 : 55 1d 0e 6179 0615 04 16 22: . . . . . OCTET STRING 6180 : 04 14 e7 26 c5 54 cd 5b a3 6f 35 68 95 aa d5 ff 6181 : 1c 21 e4 22 75 d6 6182 0639 30 09 9: . SEQUENCE 6183 0641 06 07 7: . . OID 1.2.840.10040.4.3: dsa-with-sha 6184 : 2a 86 48 ce 38 04 03 6185 0650 03 2f 47: . BIT STRING (0 unused bits) 6186 : 30 2c 02 14 a0 66 c1 76 33 99 13 51 8d 93 64 2f 6187 : ca 13 73 de 79 1a 7d 33 02 14 5d 90 f6 ce 92 4a 6188 : bf 29 11 24 80 28 a6 5a 8e 73 b6 76 02 68 6190 D.2 Certificate 6192 This section contains an annotated hex dump of a 730 byte version 3 6193 certificate. The certificate contains the following information: 6194 (a) the serial number is 18 (12 hex); 6195 (b) the certificate is signed with DSA and the SHA-1 hash algorithm; 6196 (c) the issuer's distinguished name is OU=nist; O=gov; C=US 6197 (d) and the subject's distinguished name is CN=Tim Polk; OU=nist; 6198 O=gov; C=US 6199 (e) the certificate was valid from July 30, 1997 through December 1, 6200 1997; 6201 (f) the certificate contains a 1024 bit DSA public key; 6202 (g) the certificate is an end entity certificate, as the basic con- 6203 straints extension is not present; 6204 (h) the certificate contains an authority key identifier extension; 6205 and 6206 (i) the certificate includes one alternative name - an RFC 822 6207 address. 6209 0000 30 82 02 d6 726: SEQUENCE 6210 0004 30 82 02 96 662: . SEQUENCE 6211 0008 a0 03 3: . . [0] 6212 0010 02 01 1: . . . INTEGER 2 6213 : 02 6214 0013 02 01 1: . . INTEGER 18 6215 : 12 6216 0016 30 09 9: . . SEQUENCE 6217 0018 06 07 7: . . . OID 1.2.840.10040.4.3: dsa-with-sha 6218 : 2a 86 48 ce 38 04 03 6219 0027 30 2a 42: . . SEQUENCE 6220 0029 31 0b 11: . . . SET 6221 0031 30 09 9: . . . . SEQUENCE 6222 0033 06 03 3: . . . . . OID 2.5.4.6: C 6223 : 55 04 06 6224 0038 13 02 2: . . . . . PrintableString 'US' 6225 : 55 53 6226 0042 31 0c 12: . . . SET 6227 0044 30 0a 10: . . . . SEQUENCE 6228 0046 06 03 3: . . . . . OID 2.5.4.10: O 6229 : 55 04 0a 6230 0051 13 03 3: . . . . . PrintableString 'gov' 6231 : 67 6f 76 6232 0056 31 0d 13: . . . SET 6233 0058 30 0b 11: . . . . SEQUENCE 6234 0060 06 03 3: . . . . . OID 2.5.4.11: OU 6235 : 55 04 0b 6236 0065 13 04 4: . . . . . PrintableString 'nist' 6237 : 6e 69 73 74 6238 0071 30 1e 30: . . SEQUENCE 6239 0073 17 0d 13: . . . UTCTime '970730000000Z' 6240 : 39 37 30 37 33 30 30 30 30 30 30 30 5a 6241 0088 17 0d 13: . . . UTCTime '971201000000Z' 6242 : 39 37 31 32 30 31 30 30 30 30 30 30 5a 6243 0103 30 3d 61: . . SEQUENCE 6244 0105 31 0b 11: . . . SET 6245 0107 30 09 9: . . . . SEQUENCE 6246 0109 06 03 3: . . . . . OID 2.5.4.6: C 6247 : 55 04 06 6248 0114 13 02 2: . . . . . PrintableString 'US' 6249 : 55 53 6250 0118 31 0c 12: . . . SET 6251 0120 30 0a 10: . . . . SEQUENCE 6252 0122 06 03 3: . . . . . OID 2.5.4.10: O 6253 : 55 04 0a 6254 0127 13 03 3: . . . . . PrintableString 'gov' 6255 : 67 6f 76 6256 0132 31 0d 13: . . . SET 6257 0134 30 0b 11: . . . . SEQUENCE 6258 0136 06 03 3: . . . . . OID 2.5.4.11: OU 6259 : 55 04 0b 6261 0141 13 04 4: . . . . . PrintableString 'nist' 6262 : 6e 69 73 74 6263 0147 31 11 17: . . . SET 6264 0149 30 0f 15: . . . . SEQUENCE 6265 0151 06 03 3: . . . . . OID 2.5.4.3: CN 6266 : 55 04 03 6267 0156 13 08 8: . . . . . PrintableString 'Tim Polk' 6268 : 54 69 6d 20 50 6f 6c 6b 6269 0166 30 82 01 b4 436: . . SEQUENCE 6270 0170 30 82 01 29 297: . . . SEQUENCE 6271 0174 06 07 7: . . . . OID 1.2.840.10040.4.1: dsa 6272 : 2a 86 48 ce 38 04 01 6273 0183 30 82 01 1c 284: . . . . SEQUENCE 6274 0187 02 81 80 128: . . . . . INTEGER 6275 : d4 38 02 c5 35 7b d5 0b a1 7e 5d 72 59 63 55 d3 6276 : 45 56 ea e2 25 1a 6b c5 a4 ab aa 0b d4 62 b4 d2 6277 : 21 b1 95 a2 c6 01 c9 c3 fa 01 6f 79 86 83 3d 03 6278 : 61 e1 f1 92 ac bc 03 4e 89 a3 c9 53 4a f7 e2 a6 6279 : 48 cf 42 1e 21 b1 5c 2b 3a 7f ba be 6b 5a f7 0a 6280 : 26 d8 8e 1b eb ec bf 1e 5a 3f 45 c0 bd 31 23 be 6281 : 69 71 a7 c2 90 fe a5 d6 80 b5 24 dc 44 9c eb 4d 6282 : f9 da f0 c8 e8 a2 4c 99 07 5c 8e 35 2b 7d 57 8d 6283 0318 02 14 20: . . . . . INTEGER 6284 : a7 83 9b f3 bd 2c 20 07 fc 4c e7 e8 9f f3 39 83 6285 : 51 0d dc dd 6286 0340 02 81 80 128: . . . . . INTEGER 6287 : 0e 3b 46 31 8a 0a 58 86 40 84 e3 a1 22 0d 88 ca 6288 : 90 88 57 64 9f 01 21 e0 15 05 94 24 82 e2 10 90 6289 : d9 e1 4e 10 5c e7 54 6b d4 0c 2b 1b 59 0a a0 b5 6290 : a1 7d b5 07 e3 65 7c ea 90 d8 8e 30 42 e4 85 bb 6291 : ac fa 4e 76 4b 78 0e df 6c e5 a6 e1 bd 59 77 7d 6292 : a6 97 59 c5 29 a7 b3 3f 95 3e 9d f1 59 2d f7 42 6293 : 87 62 3f f1 b8 6f c7 3d 4b b8 8d 74 c4 ca 44 90 6294 : cf 67 db de 14 60 97 4a d1 f7 6d 9e 09 94 c4 0d 6295 0471 03 81 84 132: . . . BIT STRING (0 unused bits) 6296 : 02 81 80 a8 63 b1 60 70 94 7e 0b 86 08 93 0c 0d 6297 : 08 12 4a 58 a9 af 9a 09 38 54 3b 46 82 fb 85 0d 6298 : 18 8b 2a 77 f7 58 e8 f0 1d d2 18 df fe e7 e9 35 6299 : c8 a6 1a db 8d 3d 3d f8 73 14 a9 0b 39 c7 95 f6 6300 : 52 7d 2d 13 8c ae 03 29 3c 4e 8c b0 26 18 b6 d8 6301 : 11 1f d4 12 0c 13 ce 3f f1 c7 05 4e df e1 fc 44 6302 : fd 25 34 19 4a 81 0d dd 98 42 ac d3 b6 91 0c 7f 6303 : 16 72 a3 a0 8a d7 01 7f fb 9c 93 e8 99 92 c8 42 6304 : 47 c6 43 6305 0606 a3 3e 62: . . [3] 6306 0608 30 3c 60: . . . SEQUENCE 6307 0610 30 19 25: . . . . SEQUENCE 6308 0612 06 03 3: . . . . . OID 2.5.29.17: subjectAltName 6309 : 55 1d 11 6310 0617 04 12 18: . . . . . OCTET STRING 6311 : 30 10 81 0e 77 70 6f 6c 6b 40 6e 69 73 74 2e 67 6312 : 6f 76 6313 0637 30 1f 31: . . . . SEQUENCE 6314 0639 06 03 3: . . . . . OID 2.5.29.35: subjectAltName 6315 : 55 1d 23 6316 0644 04 18 24: . . . . . OCTET STRING 6317 : 30 16 80 14 e7 26 c5 54 cd 5b a3 6f 35 68 95 aa 6318 : d5 ff 1c 21 e4 22 75 d6 6319 0670 30 09 9: . SEQUENCE 6320 0672 06 07 7: . . OID 1.2.840.10040.4.3: dsa-with-sha 6321 : 2a 86 48 ce 38 04 03 6322 0681 03 2f 47: . BIT STRING (0 unused bits) 6323 : 30 2c 02 14 3c 02 e0 ab d9 5d 05 77 75 15 71 58 6324 : 92 29 48 c4 1c 54 df fc 02 14 5b da 53 98 7f c5 6325 : 33 df c6 09 b2 7a e3 6f 97 70 1e 14 ed 94 6327 D.3 End-Entity Certificate Using RSA 6329 This section contains an annotated hex dump of a 675 byte version 3 6330 certificate. The certificate contains the following information: 6331 (a) the serial number is 256; 6332 (b) the certificate is signed with RSA and the MD2 hash algorithm; 6333 (c) the issuer's distinguished name is OU=Dept. Arquitectura de Com- 6334 putadors; O=Universitat Politecnica de Catalunya; C=ES 6335 (d) and the subject's distinguished name is CN=Francisco Jordan; 6336 OU=Dept. Arquitectura de Computadors; O=Universitat Politecnica de 6337 Catalunya; C=ES 6338 (e) the certificate was issued on May 21, 1996 and expired on May 21, 6339 1997; 6340 (f) the certificate contains a 768 bit RSA public key; 6341 (g) the certificate is an end entity certificate (not a CA certifi- 6342 cate); 6343 (h) the certificate includes an alternative subject name and an 6344 alternative issuer name - bothe are URLs; 6345 (i) the certificate include an authority key identifier and certifi- 6346 cate policies extensions; and 6347 (j) the certificate includes a critical key usage extension specify- 6348 ing the public is intended for generation of digital signatures. 6350 0000 30 80 : SEQUENCE (size undefined) 6351 0002 30 82 02 40 576: . SEQUENCE 6352 0006 a0 03 3: . . [0] 6353 0008 02 01 1: . . . INTEGER 2 6354 : 02 6355 0011 02 02 2: . . INTEGER 256 6356 : 01 00 6358 0015 30 0d 13: . . SEQUENCE 6359 0017 06 09 9: . . . OID 1.2.840.113549.1.1.2: 6360 MD2WithRSAEncryption 6361 : 2a 86 48 86 f7 0d 01 01 02 6362 0028 05 00 0: . . . NULL 6363 0030 30 68 88: . . SEQUENCE 6364 0032 31 0b 11: . . . SET 6365 0034 30 09 9: . . . . SEQUENCE 6366 0036 06 03 3: . . . . . OID 2.5.4.6: C 6367 : 55 04 06 6368 0041 13 02 2: . . . . . PrintableString 'ES' 6369 : 45 53 6370 0045 31 2d 45: . . . SET 6371 0047 30 2b 43: . . . . SEQUENCE 6372 0049 06 03 3: . . . . . OID 2.5.4.10: O 6373 : 55 04 0a 6374 0054 13 24 36: . . . . . PrintableString 6375 'Universitat Politecnica de Catalunya' 6376 : 55 6e 69 76 65 72 73 69 74 61 74 20 50 6f 6c 69 6377 : 74 65 63 6e 69 63 61 20 64 65 20 43 61 74 61 6c 6378 : 75 6e 79 61 6379 0092 31 2a 42: . . . SET 6380 0094 30 28 40: . . . . SEQUENCE 6381 0096 06 03 3: . . . . . OID 2.5.4.11: OU 6382 : 55 04 0b 6383 0101 13 21 33: . . . . . PrintableString 6384 'OU=Dept. Arquitectura de Computadors' 6385 : 44 65 70 74 2e 20 41 72 71 75 69 74 65 63 74 75 6386 : 72 61 20 64 65 20 43 6f 6d 70 75 74 61 64 6f 72 6387 : 73 6388 0136 30 1e 30: . . SEQUENCE 6389 0138 17 0d 13: . . . UTCTime '960521095826Z' 6390 : 39 36 30 37 32 32 31 37 33 38 30 32 5a 6391 0153 17 0d 13: . . . UTCTime '979521095826Z' 6392 : 39 37 30 37 32 32 31 37 33 38 30 32 5a 6393 0168 30 81 83 112: . . SEQUENCE 6394 0171 31 0b 11: . . . SET 6395 0173 30 09 9: . . . . SEQUENCE 6396 0175 06 03 3: . . . . . OID 2.5.4.6: C 6397 : 55 04 06 6398 0180 13 02 2: . . . . . PrintableString 'ES' 6399 : 45 53 6400 0184 31 2d 12: . . . SET 6401 0186 30 2b 16: . . . . SEQUENCE 6402 0188 06 03 3: . . . . . OID 2.5.4.10: O 6403 : 55 04 0a 6404 0193 13 24 36: . . . . . PrintableString 6405 'Universitat Politecnica de Catalunya' 6406 : 55 6e 69 76 65 72 73 69 74 61 74 20 50 6f 6c 69 6407 : 74 65 63 6e 69 63 61 20 64 65 20 43 61 74 61 6c 6408 : 75 6e 79 61 6409 0231 31 2a 42: . . . SET 6410 0233 30 28 40: . . . . SEQUENCE 6411 0235 06 03 3: . . . . . OID 2.5.4.11: OU 6412 : 55 04 0b 6413 0240 13 21 33: . . . . . PrintableString 6414 'Dept. Arquitectura de Computadors' 6415 : 44 65 70 74 2e 20 41 72 71 75 69 74 65 63 74 75 6416 : 72 61 20 64 65 20 43 6f 6d 70 75 74 61 64 6f 72 6417 : 73 6418 0275 31 19 22: . . . SET 6419 0277 30 17 20: . . . . SEQUENCE 6420 0279 06 03 3: . . . . . OID 2.5.4.3: CN 6421 : 55 04 03 6422 0284 13 10 16: . . . . . PrintableString 'Francisco Jordan' 6423 : 46 72 61 6e 63 69 73 63 6f 20 4a 6f 72 64 61 6e 6424 0302 30 7c 2: . . SEQUENCE 6425 0304 30 0d 13: . . . SEQUENCE 6426 0306 06 09 9: . . . . OID 1.2.840.113549.1.1.1: RSAEncryption 6427 : 2a 86 48 86 f7 0d 01 01 01 6428 0317 05 00 0: . . . . NULL 6429 0319 03 6b 107: . . . BIT STRING 6430 : 00 (0 unused bits) 6431 : 30 68 02 61 00 be aa 8b 77 54 a3 af ca 77 9f 2f 6432 : b0 cf 43 88 ff a6 6d 79 55 5b 61 8c 68 ec 48 1e 6433 : 8a 86 38 a4 fe 19 b8 62 17 1d 9d 0f 47 2c ff 63 6434 : 8f 29 91 04 d1 52 bc 7f 67 b6 b2 8f 74 55 c1 33 6435 : 21 6c 8f ab 01 95 24 c8 b2 73 93 9d 22 61 50 a9 6436 : 35 fb 9d 57 50 32 ef 56 52 50 93 ab b1 88 94 78 6437 : 56 15 c6 1c 8b 02 03 01 00 01 6438 0428 a3 81 97 151: . . [3] 6439 0431 30 3c 60: . . . SEQUENCE 6440 0433 30 1f 31: . . . . SEQUENCE 6441 0435 06 03 3: . . . . . OID 2.5.29.35: authorityKeyIdentifier 6442 : 55 1d 23 6443 0440 04 14 22: . . . . . OCTET STRING 6444 : 30 12 80 10 0e 6b 3a bf 04 ea 04 c3 0e 6b 3a bf 6445 : 04 ea 04 c3 6446 0464 30 19 25: . . . . SEQUENCE 6447 0466 06 03 3: . . . . . OID 2.5.29.15: keyUsage 6448 : 55 1d 0f 6449 0471 01 01 1: . . . . . TRUE 6450 0474 04 04 4: . . . . . OCTET STRING 6451 : 03 02 07 80 6452 0480 30 19 25: . . . . SEQUENCE 6453 0482 06 03 3: . . . . . OID 2.5.29.32: certificatePolicies 6454 : 55 1d 20 6455 0487 04 21 33: . . . . . OCTET STRING 6456 : 30 1f 30 1d 06 04 2a 84 80 00 30 15 30 07 06 05 6457 : 2a 84 80 00 01 30 0a 06 05 2a 84 80 00 02 02 01 6458 : 0a 6459 0522 30 1c 28: . . . . SEQUENCE 6460 0524 06 03 3: . . . . . OID 2.5.29.17: subjectAltName 6461 : 55 1d 11 6462 0529 04 15 21: . . . . . OCTET STRING 6463 : 30 13 86 11 68 74 74 70 3a 2f 2f 61 63 2e 75 70 6464 : 63 2e 65 73 2f 6465 0552 30 19 25: . . . . SEQUENCE 6466 0554 06 03 3: . . . . . OID 2.5.29.18: issuerAltName 6467 : 55 1d 12 6468 0559 04 12 18: . . . . . OCTET STRING 6469 : 30 14 86 12 68 74 74 70 3a 2f 2f 77 77 77 2e 75 6470 : 70 63 2e 65 6471 0579 30 80 : . SEQUENCE (indefinite length) 6472 0581 06 07 7: . . OID 6473 0583 05 00 0: . . NULL 6474 0585 00 00 0: . . end of contents marker 6475 0587 03 81 81 47: . BIT STRING 6476 : 00 (0 unused bits) 6477 : 5c 01 bd b5 41 88 87 7a 0e d3 0e 6b 3a bf 04 ea 6478 : 04 cb 5f 61 72 3c a3 bd 78 f5 66 17 fe 37 3a ab 6479 : eb 67 bf b7 da a8 38 f6 33 15 71 75 2f b9 8c 91 6480 : a0 e4 87 ba 4b 43 a0 22 8f d3 a9 86 43 89 e6 50 6481 : 5c 01 bd b5 41 88 87 7a 0e d3 0e 6b 3a bf 04 ea 6482 : 04 cb 5f 61 72 3c a3 bd 78 f5 66 17 fe 37 3a ab 6483 : eb 67 bf b7 da a8 38 f6 33 15 71 75 2f b9 8c 91 6484 : a0 e4 87 ba 4b 43 a0 22 8f d3 a9 86 43 89 e6 50 6485 0637 00 00 0: . . end of contents marker 6487 D.4 Certificate Revocation List 6489 This section contains an annotated hex dump of a version 2 CRL with 6490 one extension (cRLNumber). The CRL was issued by OU=nist;O=gov;C=us 6491 on July 7, 1996; the next scheduled issuance was August 7, 1996. The 6492 CRL includes one revoked certificates: serial number 18 (12 hex). 6493 The CRL itself is number 18, and it was signed with DSA and SHA-1. 6495 0000 30 81 ba 186: SEQUENCE 6496 0003 30 7c 124: . SEQUENCE 6497 0005 02 01 1: . . INTEGER 1 6498 : 01 6499 0008 30 09 9: . . SEQUENCE 6500 0010 06 07 7: . . . OID 1.2.840.10040.4.3: dsa-with-sha 6501 : 2a 86 48 ce 38 04 03 6503 0019 30 2a 42: . . SEQUENCE 6504 0021 31 0b 11: . . . SET 6505 0023 30 09 9: . . . . SEQUENCE 6506 0025 06 03 3: . . . . . OID 2.5.4.6: C 6507 : 55 04 06 6508 0030 13 02 2: . . . . . PrintableString 'US' 6509 : 55 53 6510 0034 31 0c 12: . . . SET 6511 0036 30 0a 10: . . . . SEQUENCE 6512 0038 06 03 3: . . . . . OID 2.5.4.10: O 6513 : 55 04 0a 6514 0043 13 03 3: . . . . . PrintableString 'gov' 6515 : 67 6f 76 6516 0048 31 0d 13: . . . SET 6517 0050 30 0b 11: . . . . SEQUENCE 6518 0052 06 03 3: . . . . . OID 2.5.4.11: OU 6519 : 55 04 0b 6520 0057 13 04 4: . . . . . PrintableString 'nist' 6521 : 6e 69 73 74 6522 0063 17 0d 13: . . UTCTime '970801000000Z' 6523 : 39 37 30 38 30 31 30 30 30 30 30 30 5a 6524 0078 17 0d 13: . . UTCTime '970808000000Z' 6525 : 39 37 30 38 30 38 30 30 30 30 30 30 5a 6526 0093 30 22 34: . . SEQUENCE 6527 0095 30 20 32: . . . SEQUENCE 6528 0097 02 01 1: . . . . INTEGER 18 6529 : 12 6530 0100 17 0d 13: . . . . UTCTime '970731000000Z' 6531 : 39 37 30 37 33 31 30 30 30 30 30 30 5a 6532 0115 30 0c 12: . . . . SEQUENCE 6533 0117 30 0a 10: . . . . . SEQUENCE 6534 0119 06 03 3: . . . . . . OID 2.5.29.21: reasonCode 6535 : 55 1d 15 6536 0124 04 03 3: . . . . . . OCTET STRING 6537 : 0a 01 01 6538 0129 30 09 9: . SEQUENCE 6539 0131 06 07 7: . . OID 1.2.840.10040.4.3: dsa-with-sha 6540 : 2a 86 48 ce 38 04 03 6541 0140 03 2f 47: . BIT STRING (0 unused bits) 6542 : 30 2c 02 14 9e d8 6b c1 7d c2 c4 02 f5 17 84 f9 6543 : 9f 46 7a ca cf b7 05 8a 02 14 9e 43 39 85 dc ea 6544 : 14 13 72 93 54 5d 44 44 e5 05 fe 73 9a b2 6546 Appendix E. Author Addresses: 6548 Russell Housley 6549 SPYRUS 6550 381 Elden Street 6551 Suite 1120 6552 Herndon, VA 20170 6553 USA 6554 housley@spyrus.com 6556 Warwick Ford 6557 VeriSign, Inc. 6558 One Alewife Center 6559 Cambridge, MA 02140 6560 USA 6561 wford@verisign.com 6563 Tim Polk 6564 NIST 6565 Building 820, Room 426 6566 Gaithersburg, MD 20899 6567 USA 6568 wpolk@nist.gov 6570 David Solo 6571 Citicorp 6572 666 Fifth Ave, 3rd Floor 6573 New York, NY 10103 6574 USA 6575 david.solo@citicorp.com 6577 Appendix F. Full Copyright Statement 6579 Copyright (C) The Internet Society (date). All Rights Reserved. 6581 This document and translations of it may be copied and furnished to 6582 others, and derivative works that comment on or otherwise explain it 6583 or assist in its implementation may be prepared, copied, published 6584 and distributed, in whole or in part, without restriction of any 6585 kind, provided that the above copyright notice and this paragraph are 6586 included on all such copies and derivative works. In addition, the 6587 ASN.1 modules presented in Appendices A and B may be used in whole or 6588 in part without inclusion of the copyright notice. However, this 6589 document itself may not be modified in any way, such as by removing 6590 the copyright notice or references to the Internet Society or other 6591 Internet organizations, except as needed for the purpose of develop- 6592 ing Internet standards in which case the procedures for copyrights 6593 defined in the Internet Standards process shall be followed, or as 6594 required to translate it into languages other than English. 6596 The limited permissions granted above are perpetual and will not be 6597 revoked by the Internet Society or its successors or assigns. This 6598 document and the information contained herein is provided on an "AS 6599 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 6600 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 6601 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 6602 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 6603 OR FITNESS FOR A PARTICULAR PURPOSE.