idnits 2.17.00 (12 Aug 2021) /tmp/idnits46048/draft-ietf-pkix-new-part1-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 146 longer pages, the longest (page 1) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 146 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 56 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...' -- 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 (March 10, 2000) is 8106 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 6528 -- Looks like a reference, but probably isn't: '1' on line 6051 -- Looks like a reference, but probably isn't: '2' on line 6052 -- Looks like a reference, but probably isn't: '3' on line 6614 == Missing Reference: 'ISO 8859-1' is mentioned on line 908, but not defined == Missing Reference: 'KRB' is mentioned on line 1586, but not defined == Missing Reference: 'PKINIT' is mentioned on line 1588, but not defined -- Looks like a reference, but probably isn't: '4' on line 6054 -- Looks like a reference, but probably isn't: '5' on line 5915 -- Looks like a reference, but probably isn't: '6' on line 5916 -- Looks like a reference, but probably isn't: '7' on line 5917 -- Looks like a reference, but probably isn't: '8' on line 5918 == Missing Reference: 'RFC1738' is mentioned on line 2415, but not defined ** Obsolete undefined reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) == Missing Reference: 'RFC1778' is mentioned on line 2415, but not defined ** Obsolete undefined reference: RFC 1778 (Obsoleted by RFC 3494) == Missing Reference: 'DB94' is mentioned on line 3487, but not defined == Missing Reference: 'UNIVERSAL 28' is mentioned on line 4047, but not defined == Missing Reference: 'UNIVERSAL 30' is mentioned on line 4050, but not defined == Missing Reference: 'UNIVERSAL 12' is mentioned on line 4054, but not defined == Missing Reference: 'APPLICATION 1' is mentioned on line 5462, but not defined == Missing Reference: 'APPLICATION 2' is mentioned on line 5468, but not defined == Missing Reference: 'LDAP' is mentioned on line 6206, but not defined == Unused Reference: 'FIPS 180-1' is defined on line 3782, but no explicit reference was found in the text == Unused Reference: 'RFC 1778' is defined on line 3822, but no explicit reference was found in the text == Unused Reference: 'RFC 1883' is defined on line 3826, but no explicit reference was found in the text == Unused Reference: 'RFC 2119' is defined on line 3829, but no explicit reference was found in the text == Unused Reference: 'RFC 2277' is defined on line 3836, but no explicit reference was found in the text == Unused Reference: 'RFC 2279' is defined on line 3839, 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: 19 errors (**), 0 flaws (~~), 27 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 (Citigroup) 5 expires in six months March 10, 2000 7 Internet X.509 Public Key Infrastructure 9 Certificate and CRL Profile 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 To view the entire list of current Internet-Drafts, please check the 33 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 34 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 35 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 36 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 38 Copyright (C) The Internet Society (1998). All Rights Reserved. 40 Abstract 42 This is the first draft of a specification based upon RFC 2459. When 43 complete, this specification will obsolete RFC 2459. This 44 specification includes numerous edits and clarifications. The most 45 notable departures from RFC 2459 are found in Section 6, Path 46 Validation. In RFC 2459, the reader was expected to augment the path 47 validation algorithm, which concentrated upon policy processing, with 48 information embedded in earlier sections. For example, parameter 49 inheritance is discussed in Section 7, Algorithm Support, and can 50 certainly affect the validity of a certification path. However, 51 parameter inheritance was omitted from the path validation algorithm 52 in RFC 2459. In this draft, the path validation algorithm has a 53 comprehensive and extremely detailed description. Details such as 54 parameter inheritance are covered thoroughly. In addition, this 55 draft anticipates certain corrections proposed in the X.509 standard 56 for the policy processing aspects of path validation. 58 A new section 6.3, CRL validation, has been added as well. This 59 section provides a supplement to the path validation algorithm that 60 determines if a particular CRL may be used to verify the status of a 61 particular certificate. (The basic path validation algorithm is, by 62 design, independent of the type and format of status information.) 64 This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use 65 in the Internet. An overview of the approach and model are provided 66 as an introduction. The X.509 v3 certificate format is described in 67 detail, with additional information regarding the format and 68 semantics of Internet name forms (e.g., IP addresses). Standard 69 certificate extensions are described and one new Internet-specific 70 extension is defined. A required set of certificate extensions is 71 specified. The X.509 v2 CRL format is described and a required 72 extension set is defined as well. An algorithm for X.509 certificate 73 path validation is described. Supplemental information is provided 74 describing the format of public keys and digital signatures in X.509 75 certificates for common Internet public key encryption algorithms 76 (i.e., RSA, DSA, and Diffie-Hellman). ASN.1 modules and examples are 77 provided in the appendices. 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in RFC 2119. 83 Please send comments on this document to the ietf-pkix@imc.org mail 84 list. 86 Table of Contents 88 1 Introduction ................................................ 6 89 2 Requirements and Assumptions ................................ 7 90 2.1 Communication and Topology ................................ 7 91 2.2 Acceptability Criteria .................................... 8 92 2.3 User Expectations ......................................... 8 93 2.4 Administrator Expectations ................................ 8 94 3 Overview of Approach ........................................ 8 95 3.1 X.509 Version 3 Certificate ............................... 10 96 3.2 Certification Paths and Trust ............................. 11 97 3.3 Revocation ................................................ 13 98 3.4 Operational Protocols ..................................... 14 99 3.5 Management Protocols ...................................... 14 100 4 Certificate and Certificate Extensions Profile .............. 15 101 4.1 Basic Certificate Fields .................................. 16 102 4.1.1 Certificate Fields ...................................... 17 103 4.1.1.1 tbsCertificate ........................................ 17 104 4.1.1.2 signatureAlgorithm .................................... 17 105 4.1.1.3 signatureValue ........................................ 18 106 4.1.2 TBSCertificate .......................................... 18 107 4.1.2.1 Version ............................................... 18 108 4.1.2.2 Serial number ......................................... 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 ....................................... 33 126 4.2.1.7 Subject Alternative Name .............................. 33 127 4.2.1.8 Issuer Alternative Name ............................... 36 128 4.2.1.9 Subject Directory Attributes .......................... 36 129 4.2.1.10 Basic Constraints .................................... 36 130 4.2.1.11 Name Constraints ..................................... 37 131 4.2.1.12 Policy Constraints ................................... 39 132 4.2.1.13 Extended key usage field ............................. 40 133 4.2.1.14 CRL Distribution Points .............................. 42 134 4.2.1.15 Inhibit Any-Policy ................................... 42 135 4.2.2 Internet Certificate Extensions ......................... 43 136 4.2.2.1 Authority Information Access .......................... 43 137 5 CRL and CRL Extensions Profile .............................. 44 138 5.1 CRL Fields ................................................ 45 139 5.1.1 CertificateList Fields .................................. 46 140 5.1.1.1 tbsCertList ........................................... 46 141 5.1.1.2 signatureAlgorithm .................................... 46 142 5.1.1.3 signatureValue ........................................ 46 143 5.1.2 Certificate List "To Be Signed" ......................... 46 144 5.1.2.1 Version ............................................... 47 145 5.1.2.2 Signature ............................................. 47 146 5.1.2.3 Issuer Name ........................................... 47 147 5.1.2.4 This Update ........................................... 47 148 5.1.2.5 Next Update ........................................... 48 149 5.1.2.6 Revoked Certificates .................................. 48 150 5.1.2.7 Extensions ............................................ 48 151 5.2 CRL Extensions ............................................ 48 152 5.2.1 Authority Key Identifier ................................ 49 153 5.2.2 Issuer Alternative Name ................................. 49 154 5.2.3 CRL Number .............................................. 49 155 5.2.4 Delta CRL Indicator ..................................... 50 156 5.2.5 Issuing Distribution Point .............................. 51 157 5.3 CRL Entry Extensions ...................................... 52 158 5.3.1 Reason Code ............................................. 53 159 5.3.2 Hold Instruction Code ................................... 53 160 5.3.3 Invalidity Date ......................................... 54 161 5.3.4 Certificate Issuer ...................................... 54 162 6 Certificate Path Validation ................................. 55 163 6.1 Basic Path Validation ..................................... 55 164 6.1.1 Inputs ................................................... 57 165 6.1.2 Initialization ........................................... 58 166 6.1.3 Basic Certificate Processing ............................. 61 167 6.1.4 Preparation for Certificate i+1 .......................... 66 168 6.1.5 Wrap-up procedure ........................................ 69 169 6.1.6 Outputs .................................................. 70 170 6.2 Extending Path Validation ................................. 70 171 6.3 CRL Validation ............................................ 71 172 6.3.1 Revocation Inputs ....................................... 71 173 6.3.2 Initialization and Revocation State Variables ........... 71 174 6.3.3 CRL Processing .......................................... 72 175 7 Algorithm Support ........................................... 72 176 7.1 One-way Hash Functions .................................... 74 177 7.1.1 MD2 One-way Hash Function ............................... 75 178 7.1.2 MD5 One-way Hash Function ............................... 75 179 7.1.3 SHA-1 One-way Hash Function ............................. 75 180 7.2 Signature Algorithms ...................................... 76 181 7.2.1 RSA Signature Algorithm ................................. 76 182 7.2.2 DSA Signature Algorithm ................................. 77 183 7.3 Subject Public Key Algorithms ............................. 78 184 7.3.1 RSA Keys ................................................ 78 185 7.3.2 Diffie-Hellman Key Exchange Key ......................... 79 186 7.3.3 DSA Signature Keys ...................................... 80 187 8 References .................................................. 81 188 9 Intellectual Property Rights ................................ 83 189 10 Security Considerations .................................... 84 190 Appendix A. ASN.1 Structures and OIDs ......................... 87 191 A.1 Explicitly Tagged Module, 1988 Syntax ...................... 87 192 A.2 Implicitly Tagged Module, 1988 Syntax ...................... 101 193 Appendix B. 1993 ASN.1 Structures and OIDs .................... 108 194 B.1 Explicitly Tagged Module, 1993 Syntax ...................... 108 195 B.2 Implicitly Tagged Module, 1993 Syntax ...................... 125 196 Appendix C. ASN.1 Notes ....................................... 132 197 Appendix D. Examples .......................................... 134 198 D.1 Certificate ............................................... 134 199 D.2 Certificate ............................................... 137 200 D.3 End-Entity Certificate Using RSA .......................... 140 201 D.4 Certificate Revocation List ............................... 143 202 Appendix E. Author Addresses .................................. 145 203 Appendix F. Full Copyright Statement .......................... 145 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 a positive integer assigned by the CA to each 816 certificate. It MUST be unique for each certificate issued by a 817 given CA (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, 927 * common name (e.g., "Susan Housley"), and 928 * serial number. 930 In addition, implementations of this specification SHOULD be prepared 931 to receive the following standard attribute types in issuer and sub- 932 ject names: 934 * locality, 935 * title, 936 * surname, 937 * given name, 938 * initials, and 939 * generation qualifier (e.g., "Jr.", "3rd", or "IV"). 941 The syntax and associated object identifiers (OIDs) for these attri- 942 bute types are provided in the ASN.1 modules in Appendices A and B. 944 In addition, implementations of this specification MUST be prepared 945 to receive the domainComponent attribute, as defined in [RFC 2247]. 946 The Domain (Nameserver) System (DNS) provides a hierarchical resource 947 labeling system. This attribute provides is a convenient mechanism 948 for organizations that wish to use DNs that parallel their DNS names. 949 This is not a replacement for the dNSName component of the alterna- 950 tive name field. Implementations are not required to convert such 951 names into DNS names. The syntax and associated OID for this attri- 952 bute type is provided in the ASN.1 modules in Appendices A and B. 954 Certificate users MUST be prepared to process the issuer dis- 955 tinguished name and subject distinguished name (see sec. 4.1.2.6) 956 fields to perform name chaining for certification path validation 957 (see section 6). Name chaining is performed by matching the issuer 958 distinguished name in one certificate with the subject name in a CA 959 certificate. 961 This specification requires only a subset of the name comparison 962 functionality specified in the X.500 series of specifications. The 963 requirements for conforming implementations are as follows: 965 (a) attribute values encoded in different types (e.g., Printable- 966 String and BMPString) may be assumed to represent different 967 strings; 969 (b) attribute values in types other than PrintableString are case 970 sensitive (this permits matching of attribute values as binary 971 objects); 973 (c) attribute values in PrintableString are not case sensitive 974 (e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and 976 (d) attribute values in PrintableString are compared after remov- 977 ing leading and trailing white space and converting internal sub- 978 strings of one or more consecutive white space characters to a 979 single space. 981 These name comparison rules permit a certificate user to validate 982 certificates issued using languages or encodings unfamiliar to the 983 certificate user. 985 In addition, implementations of this specification MAY use these com- 986 parison rules to process unfamiliar attribute types for name chain- 987 ing. This allows implementations to process certificates with unfami- 988 liar attributes in the issuer name. 990 Note that the comparison rules defined in the X.500 series of specif- 991 ications indicate that the character sets used to encode data in dis- 992 tinguished names are irrelevant. The characters themselves are com- 993 pared without regard to encoding. Implementations of the profile are 994 permitted to use the comparison algorithm defined in the X.500 995 series. Such an implementation will recognize a superset of name 996 matches recognized by the algorithm specified above. 998 4.1.2.5 Validity 1000 The certificate validity period is the time interval during which the 1001 CA warrants that it will maintain information about the status of the 1002 certificate. The field is represented as a SEQUENCE of two dates: 1003 the date on which the certificate validity period begins (notBefore) 1004 and the date on which the certificate validity period ends 1005 (notAfter). Both notBefore and notAfter may be encoded as UTCTime or 1006 GeneralizedTime. 1008 CAs conforming to this profile MUST always encode certificate vali- 1009 dity dates through the year 2049 as UTCTime; certificate validity 1010 dates in 2050 or later MUST be encoded as GeneralizedTime. 1012 The validity period for a certificate is the period of time from 1013 notBefore through notAfter, inclusive. 1015 4.1.2.5.1 UTCTime 1017 The universal time type, UTCTime, is a standard ASN.1 type intended 1018 for representation of dates and time. UTCTime specifies the year 1019 through the two low order digits and time is specified to the preci- 1020 sion of one minute or one second. UTCTime includes either Z (for 1021 Zulu, or Greenwich Mean Time) or a time differential. 1023 For the purposes of this profile, UTCTime values MUST be expressed 1024 Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are 1025 YYMMDDHHMMSSZ), even where the number of seconds is zero. Conforming 1026 systems MUST interpret the year field (YY) as follows: 1028 Where YY is greater than or equal to 50, the year shall be inter- 1029 preted as 19YY; and 1031 Where YY is less than 50, the year shall be interpreted as 20YY. 1033 4.1.2.5.2 GeneralizedTime 1035 The generalized time type, GeneralizedTime, is a standard ASN.1 type 1036 for variable precision representation of time. Optionally, the Gen- 1037 eralizedTime field can include a representation of the time differen- 1038 tial between local and Greenwich Mean Time. 1040 For the purposes of this profile, GeneralizedTime values MUST be 1041 expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e., 1042 times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. 1043 GeneralizedTime values MUST NOT include fractional seconds. 1045 4.1.2.6 Subject 1047 The subject field identifies the entity associated with the public 1048 key stored in the subject public key field. The subject name may be 1049 carried in the subject field and/or the subjectAltName extension. If 1050 the subject is a CA (e.g., the basic constraints extension, as dis- 1051 cussed in 4.2.1.10, is present and the value of cA is TRUE,) then the 1052 subject field MUST be populated with a non-empty distinguished name 1053 matching the contents of the issuer field (see sec. 4.1.2.4) in all 1054 certificates issued by the subject CA. If subject naming information 1055 is present only in the subjectAltName extension (e.g., a key bound 1056 only to an email address or URI), then the subject name MUST be an 1057 empty sequence and the subjectAltName extension MUST be critical. 1059 Where it is non-empty, the subject field MUST contain an X.500 dis- 1060 tinguished name (DN). The DN MUST be unique for each subject entity 1061 certified by the one CA as defined by the issuer name field. A CA may 1062 issue more than one certificate with the same DN to the same subject 1063 entity. 1065 The subject name field is defined as the X.501 type Name. Implemen- 1066 tation requirements for this field are those defined for the issuer 1067 field (see sec. 4.1.2.4). When encoding attribute values of type 1068 DirectoryString, the encoding rules for the issuer field MUST be 1069 implemented. Implementations of this specification MUST be prepared 1070 to receive subject names containing the attribute types required for 1071 the issuer field. Implementations of this specification SHOULD be 1072 prepared to receive subject names containing the recommended attri- 1073 bute types for the issuer field. The syntax and associated object 1074 identifiers (OIDs) for these attribute types are provided in the 1075 ASN.1 modules in Appendices A and B. Implementations of this specif- 1076 ication MAY use these comparison rules to process unfamiliar attri- 1077 bute types (i.e., for name chaining). This allows implementations to 1078 process certificates with unfamiliar attributes in the subject name. 1080 In addition, legacy implementations exist where an RFC 822 name is 1081 embedded in the subject distinguished name as an EmailAddress attri- 1082 bute. The attribute value for EmailAddress is of type IA5String to 1083 permit inclusion of the character '@', which is not part of the 1084 PrintableString character set. EmailAddress attribute values are not 1085 case sensitive (e.g., "fanfeedback@redsox.com" is the same as 1086 "FANFEEDBACK@REDSOX.COM"). 1088 Conforming implementations generating new certificates with elec- 1089 tronic mail addresses MUST use the rfc822Name in the subject alterna- 1090 tive name field (see sec. 4.2.1.7) to describe such identities. 1091 Simultaneous inclusion of the EmailAddress attribute in the subject 1092 distinguished name to support legacy implementations is deprecated 1093 but permitted. 1095 4.1.2.7 Subject Public Key Info 1097 This field is used to carry the public key and identify the algorithm 1098 with which the key is used. The algorithm is identified using the 1099 AlgorithmIdentifier structure specified in section 4.1.1.2. The 1100 object identifiers for the supported algorithms and the methods for 1101 encoding the public key materials (public key and parameters) are 1102 specified in section 7.3. 1104 4.1.2.8 Unique Identifiers 1106 These fields may only appear if the version is 2 or 3 (see sec. 1107 4.1.2.1). The subject and issuer unique identifiers are present in 1108 the certificate to handle the possibility of reuse of subject and/or 1109 issuer names over time. This profile recommends that names not be 1110 reused for different entities and that Internet certificates not make 1111 use of unique identifiers. CAs conforming to this profile SHOULD NOT 1112 generate certificates with unique identifiers. Applications conform- 1113 ing to this profile SHOULD be capable of parsing unique identifiers 1114 and making comparisons. 1116 4.1.2.9 Extensions 1118 This field may only appear if the version is 3 (see sec. 4.1.2.1). 1119 If present, this field is a SEQUENCE of one or more certificate 1120 extensions. The format and content of certificate extensions in the 1121 Internet PKI is defined in section 4.2. 1123 4.2 Standard Certificate Extensions 1125 The extensions defined for X.509 v3 certificates provide methods for 1126 associating additional attributes with users or public keys and for 1127 managing the certification hierarchy. The X.509 v3 certificate for- 1128 mat also allows communities to define private extensions to carry 1129 information unique to those communities. Each extension in a certi- 1130 ficate may be designated as critical or non-critical. A certificate 1131 using system MUST reject the certificate if it encounters a critical 1132 extension it does not recognize; however, a non-critical extension 1133 may be ignored if it is not recognized. The following sections 1134 present recommended extensions used within Internet certificates and 1135 standard locations for information. Communities may elect to use 1136 additional extensions; however, caution should be exercised in adopt- 1137 ing any critical extensions in certificates which might prevent use 1138 in a general context. 1140 Each extension includes an OID and an ASN.1 structure. When an 1141 extension appears in a certificate, the OID appears as the field 1142 extnID and the corresponding ASN.1 encoded structure is the value of 1143 the octet string extnValue. Only one instance of a particular exten- 1144 sion may appear in a particular certificate. For example, a certifi- 1145 cate may contain only one authority key identifier extension (see 1146 sec. 4.2.1.1). An extension includes the boolean critical, with a 1147 default value of FALSE. The text for each extension specifies the 1148 acceptable values for the critical field. 1150 Conforming CAs MUST support key identifiers (see sec. 4.2.1.1 and 1151 4.2.1.2), basic constraints (see sec. 4.2.1.10), key usage (see sec. 1153 4.2.1.3), and certificate policies (see sec. 4.2.1.5) extensions. If 1154 the CA issues certificates with an empty sequence for the subject 1155 field, the CA MUST support the subject alternative name extension 1156 (see sec. 4.2.1.7). Support for the remaining extensions is 1157 OPTIONAL. Conforming CAs may support extensions that are not identi- 1158 fied within this specification; certificate issuers are cautioned 1159 that marking such extensions as critical may inhibit interoperabil- 1160 ity. 1162 At a minimum, applications conforming to this profile MUST recognize 1163 the following extensions: key usage (see sec. 4.2.1.3), certificate 1164 policies (see sec. 4.2.1.5), the subject alternative name (see sec. 1165 4.2.1.7), basic constraints (see sec. 4.2.1.10), name constraints 1166 (see sec. 4.2.1.11), policy constraints (see sec. 4.2.1.12), and 1167 extended key usage (see sec. 4.2.1.13). 1169 In addition, this profile RECOMMENDS application support for the 1170 authority and subject key identifier (see sec. 4.2.1.1 and 4.2.1.2), 1171 and inhibit any-policy (see sec. 4.2.1.15) extensions. 1173 4.2.1 Standard Extensions 1175 This section identifies standard certificate extensions defined in 1176 [X.509] for use in the Internet PKI. Each extension is associated 1177 with an OID defined in [X.509]. These OIDs are members of the id-ce 1178 arc, which is defined by the following: 1180 id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 1182 4.2.1.1 Authority Key Identifier 1184 The authority key identifier extension provides a means of identify- 1185 ing the public key corresponding to the private key used to sign a 1186 certificate. This extension is used where an issuer has multiple 1187 signing keys (either due to multiple concurrent key pairs or due to 1188 changeover). The identification may be based on either the key iden- 1189 tifier (the subject key identifier in the issuer's certificate) or on 1190 the issuer name and serial number. 1192 The keyIdentifier field of the authorityKeyIdentifier extension MUST 1193 be included in all certificates generated by conforming CAs to facil- 1194 itate chain building. There is one exception; where a CA distributes 1195 its public key in the form of a "self-signed" certificate, the 1196 authority key identifier may be omitted. In this case, the subject 1197 and authority key identifiers would be identical. 1199 The value of the keyIdentifier field SHOULD be derived from the pub- 1200 lic key used to verify the certificate's signature or a method that 1201 generates unique values. Two common methods for generating key iden- 1202 tifiers from the public key are described in (sec. 4.2.1.2). One com- 1203 mon method for generating unique values is described in (sec. 1204 4.2.1.2). Where a key identifier has not been previously esta- 1205 blished, this specification recommends use of one of these methods 1206 for generating keyIdentifiers. 1208 This profile recommends support for the key identifier method by all 1209 certificate users. 1211 This extension MUST NOT be marked critical. 1213 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 1215 AuthorityKeyIdentifier ::= SEQUENCE { 1216 keyIdentifier [0] KeyIdentifier OPTIONAL, 1217 authorityCertIssuer [1] GeneralNames OPTIONAL, 1218 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 1220 KeyIdentifier ::= OCTET STRING 1222 4.2.1.2 Subject Key Identifier 1224 The subject key identifier extension provides a means of identifying 1225 certificates that contain a particular public key. 1227 To facilitate chain building, this extension MUST appear in all con- 1228 forming CA certificates, that is, all certificates including the 1229 basic constraints extension (see sec. 4.2.1.10) where the value of cA 1230 is TRUE. The value of the subject key identifier MUST be the value 1231 placed in the key identifier field of the Authority Key Identifier 1232 extension (see sec. 4.2.1.1) of certificates issued by the subject of 1233 this certificate. 1235 For CA certificates, subject key identifiers SHOULD be derived from 1236 the public key or a method that generates unique values. Two common 1237 methods for generating key identifiers from the public key are: 1239 (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the 1240 value of the BIT STRING subjectPublicKey (excluding the tag, 1241 length, and number of unused bits). 1243 (2) The keyIdentifier is composed of a four bit type field with 1244 the value 0100 followed by the least significant 60 bits of the 1245 SHA-1 hash of the value of the BIT STRING subjectPublicKey. 1247 One common method for generating unique values is a monotomically 1248 increasing sequence of integers. 1250 For end entity certificates, the subject key identifier extension 1251 provides a means for identifying certificates containing the particu- 1252 lar public key used in an application. Where an end entity has 1253 obtained multiple certificates, especially from multiple CAs, the 1254 subject key identifier provides a means to quickly identify the set 1255 of certificates containing a particular public key. To assist appli- 1256 cations in identificiation the appropriate end entity certificate, 1257 this extension SHOULD be included in all end entity certificates. 1259 For end entity certificates, subject key identifiers SHOULD be 1260 derived from the public key. Two common methods for generating key 1261 identifiers from the public key are identifed above. 1263 Where a key identifier has not been previously established, this 1264 specification recommends use of one of these methods for generating 1265 keyIdentifiers. 1267 This extension MUST NOT be marked critical. 1269 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 1271 SubjectKeyIdentifier ::= KeyIdentifier 1273 4.2.1.3 Key Usage 1275 The key usage extension defines the purpose (e.g., encipherment, sig- 1276 nature, certificate signing) of the key contained in the certificate. 1277 The usage restriction might be employed when a key that could be used 1278 for more than one operation is to be restricted. For example, when 1279 an RSA key should be used only for signing, the digitalSignature 1280 and/or nonRepudiation bits would be asserted. Likewise, when an RSA 1281 key should be used only for key management, the keyEncipherment bit 1282 would be asserted. When used, this extension SHOULD be marked criti- 1283 cal. 1285 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 1287 KeyUsage ::= BIT STRING { 1288 digitalSignature (0), 1289 nonRepudiation (1), 1290 keyEncipherment (2), 1291 dataEncipherment (3), 1292 keyAgreement (4), 1293 keyCertSign (5), 1294 cRLSign (6), 1295 encipherOnly (7), 1296 decipherOnly (8) } 1298 Bits in the KeyUsage type are used as follows: 1300 The digitalSignature bit is asserted when the subject public key 1301 is used with a digital signature mechanism to support security 1302 services other than non-repudiation (bit 1), certificate signing 1303 (bit 5), or revocation information signing (bit 6). Digital signa- 1304 ture mechanisms are often used for entity authentication and data 1305 origin authentication with integrity. 1307 The nonRepudiation bit is asserted when the subject public key is 1308 used to verify digital signatures used to provide a non- 1309 repudiation service which protects against the signing entity 1310 falsely denying some action, excluding certificate or CRL signing. 1311 In the case of later conflict, a reliable third party may deter- 1312 mine the authenticity of the signed data. 1314 Further distinctions between the digitalSignature and nonRepudia- 1315 tion bits may be provided in specific certificate policies. 1317 The keyEncipherment bit is asserted when the subject public key is 1318 used for key transport. For example, when an RSA key is to be 1319 used for key management, then this bit shall asserted. 1321 The dataEncipherment bit is asserted when the subject public key 1322 is used for enciphering user data, other than cryptographic keys. 1324 The keyAgreement bit is asserted when the subject public key is 1325 used for key agreement. For example, when a Diffie-Hellman key is 1326 to be used for key management, then this bit shall asserted. 1328 The keyCertSign bit is asserted when the subject public key is 1329 used for verifying a signature on certificates. This bit may only 1330 be asserted in CA certificates. If the keyCertSign bit is 1331 asserted, then the cA bit in the basic constraints extension (see 1332 4.2.1.10) MUST also be asserted. If the keyCertSign bit is not 1333 asserted, then the cA bit in the basic constraints extension MUST 1334 NOT be asserted. 1336 The cRLSign bit is asserted when the subject public key is used 1337 for verifying a signature on revocation information (e.g., a CRL). 1339 The meaning of the encipherOnly bit is undefined in the absence of 1340 the keyAgreement bit. When the encipherOnly bit is asserted and 1341 the keyAgreement bit is also set, the subject public key may be 1342 used only for enciphering data while performing key agreement. 1344 The meaning of the decipherOnly bit is undefined in the absence of 1345 the keyAgreement bit. When the decipherOnly bit is asserted and 1346 the keyAgreement bit is also set, the subject public key may be 1347 used only for deciphering data while performing key agreement. 1349 This profile does not restrict the combinations of bits that may be 1350 set in an instantiation of the keyUsage extension. However, 1351 appropriate values for keyUsage extensions for particular algorithms 1352 are specified in section 7.3. 1354 4.2.1.4 Private Key Usage Period 1356 This profile recommends against the use of this extension. CAs con- 1357 forming to this profile MUST NOT generate certificates with critical 1358 private key usage period extensions. 1360 The private key usage period extension allows the certificate issuer 1361 to specify a different validity period for the private key than the 1362 certificate. This extension is intended for use with digital signa- 1363 ture keys. This extension consists of two optional components, 1364 notBefore and notAfter. The private key associated with the certifi- 1365 cate should not be used to sign objects before or after the times 1366 specified by the two components, respectively. CAs conforming to this 1367 profile MUST NOT generate certificates with private key usage period 1368 extensions unless at least one of the two components is present. 1370 Where used, notBefore and notAfter are represented as GeneralizedTime 1371 and MUST be specified and interpreted as defined in section 1372 4.1.2.5.2. 1374 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 1376 PrivateKeyUsagePeriod ::= SEQUENCE { 1377 notBefore [0] GeneralizedTime OPTIONAL, 1378 notAfter [1] GeneralizedTime OPTIONAL } 1380 4.2.1.5 Certificate Policies 1382 The certificate policies extension contains a sequence of one or more 1383 policy information terms, each of which consists of an object iden- 1384 tifier (OID) and optional qualifiers. Optional qualifiers, which may 1385 be present, are not expected to change the definition of the policy. 1387 In an end-entity certificate, these policy information terms indicate 1388 the policy under which the certificate has been issued and the pur- 1389 poses for which the certificate may be used. In a CA certificate, 1390 these policy information terms limit the set of policies for certifi- 1391 cation paths which include this certificate. When a CA does not wish 1392 to limit the set of policies for certification paths which include 1393 this certificate, they may assert the special policy anyPolicy, with 1394 a value of {2 5 29 32 0}. 1396 Applications with specific policy requirements are expected to have a 1397 list of those policies which they will accept and to compare the pol- 1398 icy OIDs in the certificate to that list. If this extension is crit- 1399 ical, the path validation software MUST be able to interpret this 1400 extension (including the optional qualifier), or MUST reject the cer- 1401 tificate. 1403 To promote interoperability, this profile RECOMMENDS that policy 1404 information terms consist of only an OID. Where an OID alone is 1405 insufficient, this profile strongly recommends that use of qualifiers 1406 be limited to those identified in this section. When qualifiers are 1407 used with the special policy anyPolicy, they MUST be limited to the 1408 qualifers identified in this section. 1410 This specification defines two policy qualifier types for use by cer- 1411 tificate policy writers and certificate issuers. The qualifier types 1412 are the CPS Pointer and User Notice qualifiers. 1414 The CPS Pointer qualifier contains a pointer to a Certification Prac- 1415 tice Statement (CPS) published by the CA. The pointer is in the form 1416 of a URI. 1418 User notice is intended for display to a relying party when a certi- 1419 ficate is used. The application software SHOULD display all user 1420 notices in all certificates of the certification path used, except 1421 that if a notice is duplicated only one copy need be displayed. To 1422 prevent such duplication, this qualifier SHOULD only be present in 1423 end-entity certificates and CA certificates issued to other organiza- 1424 tions. 1426 The user notice has two optional fields: the noticeRef field and the 1427 explicitText field. 1429 The noticeRef field, if used, names an organization and identi- 1430 fies, by number, a particular textual statement prepared by that 1431 organization. For example, it might identify the organization 1432 "CertsRUs" and notice number 1. In a typical implementation, the 1433 application software will have a notice file containing the 1434 current set of notices for CertsRUs; the application will extract 1435 the notice text from the file and display it. Messages may be 1436 multilingual, allowing the software to select the particular 1437 language message for its own environment. 1439 An explicitText field includes the textual statement directly in 1440 the certificate. The explicitText field is a string with a max- 1441 imum size of 200 characters. 1443 If both the noticeRef and explicitText options are included in the 1444 one qualifier and if the application software can locate the notice 1445 text indicated by the noticeRef option then that text should be 1446 displayed; otherwise, the explicitText string should be displayed. 1448 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 1450 anyPolicy OBJECT IDENTIFIER ::= {id-ce-certificate-policies 0} 1452 certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 1454 PolicyInformation ::= SEQUENCE { 1455 policyIdentifier CertPolicyId, 1456 policyQualifiers SEQUENCE SIZE (1..MAX) OF 1457 PolicyQualifierInfo OPTIONAL } 1459 CertPolicyId ::= OBJECT IDENTIFIER 1461 PolicyQualifierInfo ::= SEQUENCE { 1462 policyQualifierId PolicyQualifierId, 1463 qualifier ANY DEFINED BY policyQualifierId } 1465 -- policyQualifierIds for Internet policy qualifiers 1467 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 1468 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 1469 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 1471 PolicyQualifierId ::= 1472 OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) 1474 Qualifier ::= CHOICE { 1475 cPSuri CPSuri, 1476 userNotice UserNotice } 1478 CPSuri ::= IA5String 1480 UserNotice ::= SEQUENCE { 1481 noticeRef NoticeReference OPTIONAL, 1482 explicitText DisplayText OPTIONAL} 1484 NoticeReference ::= SEQUENCE { 1485 organization DisplayText, 1486 noticeNumbers SEQUENCE OF INTEGER } 1488 DisplayText ::= CHOICE { 1489 ia5String IA5String (SIZE (1..200)), 1490 visibleString VisibleString (SIZE (1..200)), 1491 bmpString BMPString (SIZE (1..200)), 1492 utf8String UTF8String (SIZE (1..200)) } 1494 4.2.1.6 Policy Mappings 1496 This extension is used in CA certificates. It lists one or more 1497 pairs of OIDs; each pair includes an issuerDomainPolicy and a sub- 1498 jectDomainPolicy. The pairing indicates the issuing CA considers its 1499 issuerDomainPolicy equivalent to the subject CA's subjectDomainPol- 1500 icy. 1502 The issuing CA's users may accept an issuerDomainPolicy for certain 1503 applications. The policy mapping tells the issuing CA's users which 1504 policies associated with the subject CA are comparable to the policy 1505 they accept. 1507 Policies should not be mapped either to or from the special value 1508 anyPolicy. (see 4.2.1.5 certificate policies). 1510 This extension may be supported by CAs and/or applications, and it 1511 MUST be non-critical. 1513 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 1515 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 1516 issuerDomainPolicy CertPolicyId, 1517 subjectDomainPolicy CertPolicyId } 1519 4.2.1.7 Subject Alternative Name 1521 The subject alternative names extension allows additional identities 1522 to be bound to the subject of the certificate. Defined options 1523 include an Internet electronic mail address, a DNS name, an IP 1524 address, and a uniform resource identifier (URI). Other options 1525 exist, including completely local definitions. Multiple name forms, 1526 and multiple instances of each name form, may be included. Whenever 1527 such identities are to be bound into a certificate, the subject 1528 alternative name (or issuer alternative name) extension MUST be used. 1530 Because the subject alternative name is considered to be definitively 1531 bound to the public key, all parts of the subject alternative name 1532 MUST be verified by the CA. 1534 Further, if the only subject identity included in the certificate is 1535 an alternative name form (e.g., an electronic mail address), then the 1536 subject distinguished name MUST be empty (an empty sequence), and the 1537 subjectAltName extension MUST be present. If the subject field con- 1538 tains an empty sequence, the subjectAltName extension MUST be marked 1539 critical. 1541 When the subjectAltName extension contains an Internet mail address, 1542 the address MUST be included as an rfc822Name. The format of an 1543 rfc822Name is an "addr-spec" as defined in RFC 822 [RFC 822]. An 1544 addr-spec has the form "local-part@domain". Note that an addr-spec 1545 has no phrase (such as a common name) before it, has no comment (text 1546 surrounded in parentheses) after it, and is not surrounded by "<" and 1547 ">". Note that while upper and lower case letters are allowed in an 1548 RFC 822 addr-spec, no significance is attached to the case. 1550 When the subjectAltName extension contains a iPAddress, the address 1551 MUST be stored in the octet string in "network byte order," as speci- 1552 fied in RFC 791 [RFC 791]. The least significant bit (LSB) of each 1553 octet is the LSB of the corresponding byte in the network address. 1554 For IP Version 4, as specified in RFC 791, the octet string MUST con- 1555 tain exactly four octets. For IP Version 6, as specified in RFC 1556 1883, the octet string MUST contain exactly sixteen octets [RFC 1557 1883]. 1559 When the subjectAltName extension contains a domain name service 1560 label, the domain name MUST be stored in the dNSName (an IA5String). 1561 The name MUST be in the "preferred name syntax," as specified by RFC 1562 1034 [RFC 1034]. Note that while upper and lower case letters are 1563 allowed in domain names, no signifigance is attached to the case. In 1564 addition, while the string " " is a legal domain name, subjectAltName 1565 extensions with a dNSName " " are not permitted. Finally, the use of 1566 the DNS representation for Internet mail addresses (wpolk.nist.gov 1567 instead of wpolk@nist.gov) is not permitted; such identities are to 1568 be encoded as rfc822Name. 1570 When the subjectAltName extension contains a URI, the name MUST be 1571 stored in the uniformResourceIdentifier (an IA5String). The name MUST 1572 be a non-relative URL, and MUST follow the URL syntax and encoding 1573 rules specified in [RFC 1738]. The name must include both a scheme 1574 (e.g., "http" or "ftp") and a scheme-specific-part. The scheme- 1575 specific-part must include a fully qualified domain name or IP 1576 address as the host. 1578 As specified in [RFC 1738], the scheme name is not case-sensitive 1579 (e.g., "http" is equivalent to "HTTP"). The host part is also not 1580 case-sensitive, but other components of the scheme-specific-part may 1581 be case-sensitive. When comparing URIs, conforming implementations 1582 MUST compare the scheme and host without regard to case, but assume 1583 the remainder of the scheme-specific-part is case sensitive. 1585 The subjectAltName may carry additional name types through the use of 1586 the otherName field. For example, Kerberos [KRB] format names can be 1587 encoded into the otherName, using the krb5PrincipalName OID and the 1588 KerberosName syntax as defined in [PKINIT]. 1590 Subject alternative names may be constrained in the same manner as 1591 subject distinguished names using the name constraints extension as 1592 described in section 4.2.1.11. 1594 If the subjectAltName extension is present, the sequence MUST contain 1595 at least one entry. Unlike the subject field, conforming CAs MUST 1596 NOT issue certificates with subjectAltNames containing empty General- 1597 Name fields. For example, an rfc822Name is represented as an 1598 IA5String. While an empty string is a valid IA5String, such an 1599 rfc822Name is not permitted by this profile. The behavior of clients 1600 that encounter such a certificate when processing a certificication 1601 path is not defined by this profile. 1603 Finally, the semantics of subject alternative names that include 1604 wildcard characters (e.g., as a placeholder for a set of names) are 1605 not addressed by this specification. Applications with specific 1606 requirements may use such names but shall define the semantics. 1608 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 1610 SubjectAltName ::= GeneralNames 1612 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 1614 GeneralName ::= CHOICE { 1615 otherName [0] OtherName, 1616 rfc822Name [1] IA5String, 1617 dNSName [2] IA5String, 1618 x400Address [3] ORAddress, 1619 directoryName [4] Name, 1620 ediPartyName [5] EDIPartyName, 1621 uniformResourceIdentifier [6] IA5String, 1622 iPAddress [7] OCTET STRING, 1623 registeredID [8] OBJECT IDENTIFIER} 1625 OtherName ::= SEQUENCE { 1626 type-id OBJECT IDENTIFIER, 1627 value [0] EXPLICIT ANY DEFINED BY type-id } 1629 EDIPartyName ::= SEQUENCE { 1630 nameAssigner [0] DirectoryString OPTIONAL, 1631 partyName [1] DirectoryString } 1633 4.2.1.8 Issuer Alternative Names 1635 As with 4.2.1.7, this extension is used to associate Internet style 1636 identities with the certificate issuer. Issuer alternative names MUST 1637 be encoded as in 4.2.1.7. 1639 Where present, this extension SHOULD NOT be marked critical. 1641 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 1643 IssuerAltName ::= GeneralNames 1645 4.2.1.9 Subject Directory Attributes 1647 The subject directory attributes extension is not recommended as an 1648 essential part of this profile, but it may be used in local environ- 1649 ments. This extension MUST be non-critical. 1651 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 1653 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 1655 4.2.1.10 Basic Constraints 1657 The basic constraints extension identifies whether the subject of the 1658 certificate is a CA and how deep a certification path may exist 1659 through that CA. 1661 The cA bit indicates if the certified public key may be used to ver- 1662 ify signatures on other certificates. If the cA bit is asserted, then 1663 the keyCertSign bit in the key usage extension (see 4.2.1.3) MUST 1664 also be asserted. If the cA bit is not asserted, then the keyCertSign 1665 bit in the key usage extension MUST NOT be asserted. 1667 The pathLenConstraint field is meaningful only if cA is set to TRUE. 1668 In this case, it gives the maximum number of CA certificates that may 1669 follow this certificate in a certification path. A value of zero 1670 indicates that only an end-entity certificate may follow in the path. 1671 Where it appears, the pathLenConstraint field MUST be greater than or 1672 equal to zero. Where pathLenConstraint does not appear, there is no 1673 limit to the allowed length of the certification path. 1675 This extension MUST appear as a critical extension in all CA certifi- 1676 cates. This extension MAY appear as a critical or non-critical 1677 extension in end entity certificates. 1679 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 1680 BasicConstraints ::= SEQUENCE { 1681 cA BOOLEAN DEFAULT FALSE, 1682 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 1684 4.2.1.11 Name Constraints 1686 The name constraints extension, which MUST be used only in a CA cer- 1687 tificate, indicates a name space within which all subject names in 1688 subsequent certificates in a certification path shall be located. 1689 Restrictions may apply to the subject distinguished name or subject 1690 alternative names. Restrictions apply only when the specified name 1691 form is present. If no name of the type is in the certificate, the 1692 certificate is acceptable. 1694 Name constraints are not applied to certificates whose issuer and 1695 subject are identical. (This could prevent CAs that utilize name 1696 constraints from issuing self-signed certificates to implement key 1697 rollover.) 1699 Restrictions are defined in terms of permitted or excluded name sub- 1700 trees. Any name matching a restriction in the excludedSubtrees field 1701 is invalid regardless of information appearing in the permittedSub- 1702 trees. This extension MUST be critical. 1704 Within this profile, the minimum and maximum fields are not used with 1705 any name forms, thus minimum is always zero, and maximum is always 1706 absent. 1708 For URIs, the constraint applies to the host part of the name. The 1709 constraint may specify a host or a domain. Examples would be 1710 "foo.bar.com"; and ".xyz.com". When the the constraint begins with 1711 a period, it may be expanded with one or more subdomains. That is, 1712 the constraint ".xyz.com" is satisfied by both abc.xyz.com and 1713 abc.def.xyz.com. However, the constraint ".xyz.com" is not satisfied 1714 by "xyz.com". When the constraint does not begin with a period, it 1715 specifies a host. 1717 A name constraint for Internat mail addresses may specify a particu- 1718 lar mailbox, all addresses at a particular host, or all mailboxes in 1719 a domain. To indicate a particular mailbox, the constraint is the 1720 complete mail address. For example, "root@xyz.com" indicates the 1721 root mailbox on the host "xyz.com". To indicate all Internet mail 1722 addresses on a particular host, the constraint is specified as the 1723 host name. For example, the constraint "xyz.com" is satisfied by any 1724 mail address at the host "xyz.com". To specify any address within a 1725 domain, the constraint is specified with a leading period (as with 1726 URIs). For example, ".xyz.com" indicates all the Internet mail 1727 addresses in the domain "xyz.com", but not Internet mail addresses on 1728 the host "xyz.com". 1730 DNS name restrictions are expressed as foo.bar.com. Any DNS name that 1731 can be constructed by simply adding to the left hand side of the name 1732 satisfies the name constraint. For example, www.foo.bar.com would 1733 satisfy the constraint but foo1.bar.com would not. 1735 Legacy implementations exist where an RFC 822 name is embedded in the 1736 subject distinguished name in an attribute of type EmailAddress (see 1737 sec. 4.1.2.6). When rfc822 names are constrained, but the certificate 1738 does not include a subject alternative name, the rfc822 name con- 1739 straint MUST be applied to the attribute of type EmailAddress in the 1740 subject distinguished name. The ASN.1 syntax for EmailAddress and 1741 the corresponding OID are supplied in Appendix A and B. 1743 Restrictions of the form directoryName MUST be applied to the subject 1744 field in the certificate and to the subjectAltName extensions of type 1745 directoryName. Restrictions of the form x400Address MUST be applied 1746 to subjectAltName extensions of type x400Address. 1748 When applying restrictions of the form directoryName, an implementa- 1749 tion MUST compare DN attributes. At a minimum, implementations MUST 1750 perform the DN comparison rules specified in Section 4.1.2.4. CAs 1751 issuing certificates with a restriction of the form directoryName 1752 SHOULD NOT rely on implementation of the full ISO DN name comparison 1753 algorithm. This implies name restrictions shall be stated identi- 1754 cally to the encoding used in the subject field or subjectAltName 1755 extension. 1757 The syntax of iPAddress MUST be as described in section 4.2.1.7 with 1758 the following additions specifically for Name Constraints. For IPv4 1759 addresses, the ipAddress field of generalName MUST contain eight (8) 1760 octets, encoded in the style of RFC 1519 (CIDR) to represent an 1761 address range.[RFC 1519] For IPv6 addresses, the ipAddress field 1762 MUST contain 32 octets similarly encoded. For example, a name con- 1763 straint for "class C" subnet 10.9.8.0 shall be represented as the 1764 octets 0A 09 08 00 FF FF FF 00, representing the CIDR notation 1765 10.9.8.0/255.255.255.0. 1767 The syntax and semantics for name constraints for otherName, ediPar- 1768 tyName, and registeredID are not defined by this specification. 1770 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 1772 NameConstraints ::= SEQUENCE { 1773 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 1774 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 1776 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 1778 GeneralSubtree ::= SEQUENCE { 1779 base GeneralName, 1780 minimum [0] BaseDistance DEFAULT 0, 1781 maximum [1] BaseDistance OPTIONAL } 1783 BaseDistance ::= INTEGER (0..MAX) 1785 4.2.1.12 Policy Constraints 1787 The policy constraints extension can be used in certificates issued 1788 to CAs. The policy constraints extension constrains path validation 1789 in two ways. It can be used to prohibit policy mapping or require 1790 that each certificate in a path contain an acceptable policy identif- 1791 ier. 1793 If the inhibitPolicyMapping field is present, the value indicates the 1794 number of additional certificates that may appear in the path before 1795 policy mapping is no longer permitted. For example, a value of one 1796 indicates that policy mapping may be processed in certificates issued 1797 by the subject of this certificate, but not in additional certifi- 1798 cates in the path. 1800 If the requireExplicitPolicy field is present, subsequent certifi- 1801 cates shall include an acceptable policy identifier. The value of 1802 requireExplicitPolicy indicates the number of additional certificates 1803 that may appear in the path before an explicit policy is required. 1804 An acceptable policy identifier is the identifier of a policy 1805 required by the user of the certification path or the identifier of a 1806 policy which has been declared equivalent through policy mapping. 1808 Conforming CAs MUST NOT issue certificates where policy constraints 1809 is a null sequence. That is, at least one of the inhibitPolicyMapping 1810 field or the requireExplicitPolicy field MUST be present. The 1811 behavior of clients that encounter a null policy constraints field is 1812 not addressed in this profile. 1814 This extension may be critical or non-critical. 1816 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } 1818 PolicyConstraints ::= SEQUENCE { 1819 requireExplicitPolicy [0] SkipCerts OPTIONAL, 1820 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 1822 SkipCerts ::= INTEGER (0..MAX) 1824 4.2.1.13 Extended key usage field 1826 This field indicates one or more purposes for which the certified 1827 public key may be used, in addition to or in place of the basic pur- 1828 poses indicated in the key usage extension field. This field is 1829 defined as follows: 1831 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 1833 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 1835 KeyPurposeId ::= OBJECT IDENTIFIER 1837 Key purposes may be defined by any organization with a need. Object 1838 identifiers used to identify key purposes shall be assigned in accor- 1839 dance with IANA or ITU-T Rec. X.660 | ISO/IEC/ITU 9834-1. 1841 This extension may, at the option of the certificate issuer, be 1842 either critical or non-critical. 1844 If the extension is flagged critical, then the certificate MUST be 1845 used only for one of the purposes indicated. 1847 If the extension is flagged non-critical, then it indicates the 1848 intended purpose or purposes of the key, and may be used in finding 1849 the correct key/certificate of an entity that has multiple 1850 keys/certificates. It is an advisory field and does not imply that 1851 usage of the key is restricted by the certification authority to the 1852 purpose indicated. Certificate using applications may nevertheless 1853 require that a particular purpose be indicated in order for the cer- 1854 tificate to be acceptable to that application. 1856 If a certificate contains both a critical key usage field and a crit- 1857 ical extended key usage field, then both fields MUST be processed 1858 independently and the certificate MUST only be used for a purpose 1859 consistent with both fields. If there is no purpose consistent with 1860 both fields, then the certificate MUST NOT be used for any purpose. 1862 The following key usage purposes are defined by this profile: 1864 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 1866 id-kp-serverAuth OBJECT IDENTIFIER ::= {id-kp 1} 1867 -- TLS Web server authentication 1868 -- Key usage bits that may be consistent: digitalSignature, 1869 -- keyEncipherment or keyAgreement 1870 -- 1871 id-kp-clientAuth OBJECT IDENTIFIER ::= {id-kp 2} 1872 -- TLS Web client authentication 1873 -- Key usage bits that may be consistent: digitalSignature and/or 1874 -- keyAgreement 1875 -- 1876 id-kp-codeSigning OBJECT IDENTIFIER ::= {id-kp 3} 1877 -- Signing of downloadable executable code 1878 -- Key usage bits that may be consistent: digitalSignature 1879 -- 1880 id-kp-emailProtection OBJECT IDENTIFIER ::= {id-kp 4} 1881 -- E-mail protection 1882 -- Key usage bits that may be consistent: digitalSignature, 1883 -- nonRepudiation, and/or (keyEncipherment 1884 -- or keyAgreement) 1885 -- 1886 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 1887 -- Binding the hash of an object to a time from an agreed-upon time 1888 -- source. Key usage bits that may be consistent: digitalSignature, 1889 -- nonRepudiation 1891 4.2.1.14 CRL Distribution Points 1893 The CRL distribution points extension identifies how CRL information 1894 is obtained. The extension SHOULD be non-critical, but this profile 1895 recommends support for this extension by CAs and applications. 1896 Further discussion of CRL management is contained in section 5. 1898 The cRLDistributionPoints extension is a SEQUENCE of Distribution- 1899 Point. A DistributionPoint consists of three fields, each of which 1900 is optional: the name of the DistributionPoint, ReasonsFlags, and the 1901 cRLIssuer. While each component is optional, a DistributionPoint 1902 MUST NOT consist of only the ReasonsFlags field. If the distribution- 1903 Point omits cRLIssuer, the CRL MUST be issued by the CA that issued 1904 the certificate. If the distributionPointName is absent, cRLIssuer 1905 MUST be present and include a Name corresponding to an X.500 or LDAP 1906 directory entry where the CRL is located. 1908 If the cRLDistributionPoints extension contains a Distribution- 1909 PointName of type URI, the following semantics MUST be assumed: the 1910 URI is a pointer to the current CRL for the associated reasons and 1911 will be issued by the associated cRLIssuer. The expected values for 1912 the URI are those defined in 4.2.1.7. Processing rules for other 1913 values are not defined by this specification. If the distribution- 1914 Point omits reasons, the CRL MUST include revocations for all rea- 1915 sons. 1917 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 } 1919 CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 1920 DistributionPoint ::= SEQUENCE { 1921 distributionPoint [0] DistributionPointName OPTIONAL, 1922 reasons [1] ReasonFlags OPTIONAL, 1923 cRLIssuer [2] GeneralNames OPTIONAL } 1925 DistributionPointName ::= CHOICE { 1926 fullName [0] GeneralNames, 1927 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 1929 ReasonFlags ::= BIT STRING { 1930 unused (0), 1931 keyCompromise (1), 1932 cACompromise (2), 1933 affiliationChanged (3), 1934 superseded (4), 1935 cessationOfOperation (5), 1936 certificateHold (6) } 1938 4.2.1.15 Inhibit Any-Policy 1940 The inhibit any-policy extension can be used in certificates issued 1941 to CAs. The inhibit any-policy indicates that the special any-policy 1942 OID, with the value {2 5 29 32 0}, is not considered an explicit 1943 match for other certificate policies. The value indicates the number 1944 of additional certificates that may appear in the path before any- 1945 policy is no longer permitted. For example, a value of one indicates 1946 that any-policy may be processed in certificates issued by the sub- 1947 ject of this certificate, but not in additional certificates in the 1948 path. 1950 This extension MUST be critical. 1952 id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 } 1954 InhibitAnyPolicy ::= SkipCerts 1956 SkipCerts ::= INTEGER (0..MAX) 1958 4.2.1.16 Freshest CRL (a.k.a. Delta CRL Distribution Point) 1960 The freshest CRL extension identifies how delta-CRL information is 1961 obtained. The extension MUST be non-critical, but this profile 1962 recommends support for this extension by CAs and applications. 1963 Further discussion of CRL management is contained in section 5. 1965 The same syntax is used for this extension and the 1966 cRLDistributionPoints extension, and is described in section 1967 4.2.1.14. The same conventions apply to both extensions. 1969 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } 1971 FreshestCRL ::= CRLDistributionPoints 1973 4.2.2 Private Internet Extensions 1975 This section defines one new extension for use in the Internet Public 1976 Key Infrastructure. This extension may be used to direct applica- 1977 tions to identify an on-line validation service supporting the issu- 1978 ing CA. As the information may be available in multiple forms, each 1979 extension is a sequence of IA5String values, each of which represents 1980 a URI. The URI implicitly specifies the location and format of the 1981 information and the method for obtaining the information. 1983 An object identifier is defined for the private extension. The 1984 object identifier associated with the private extension is defined 1985 under the arc id-pe within the id-pkix name space. Any future exten- 1986 sions defined for the Internet PKI will also be defined under the arc 1987 id-pe. 1989 id-pkix OBJECT IDENTIFIER ::= 1990 { iso(1) identified-organization(3) dod(6) internet(1) 1991 security(5) mechanisms(5) pkix(7) } 1993 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 1995 4.2.2.1 Authority Information Access 1997 The authority information access extension indicates how to access CA 1998 information and services for the issuer of the certificate in which 1999 the extension appears. Information and services may include on-line 2000 validation services and CA policy data. (The location of CRLs is not 2001 specified in this extension; that information is provided by the 2002 cRLDistributionPoints extension.) This extension may be included in 2003 subject or CA certificates, and it MUST be non-critical. 2005 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 2007 AuthorityInfoAccessSyntax ::= 2008 SEQUENCE SIZE (1..MAX) OF AccessDescription 2010 AccessDescription ::= SEQUENCE { 2011 accessMethod OBJECT IDENTIFIER, 2012 accessLocation GeneralName } 2014 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 2016 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 2018 Each entry in the sequence AuthorityInfoAccessSyntax describes the 2019 format and location of additional information provided by the CA who 2020 issued the certificate in which this extension appears. The type and 2021 format of the information is specified by the accessMethod field; the 2022 accessLocation field specifies the location of the information. The 2023 retrieval mechanism may be implied by the accessMethod or specified 2024 by accessLocation. 2026 <> This profile defines one OID for 2027 accessMethod. The id-ad-caIssuers OID is used when the additional 2028 information lists CAs that have issued certificates superior to the 2029 CA that issued the certificate containing this extension. The refer- 2030 enced CA Issuers description is intended to aid certificate users in 2031 the selection of a certification path that terminates at a point 2032 trusted by the certificate user. 2034 When id-ad-caIssuers appears as accessInfoType, the accessLocation 2035 field describes the referenced description server and the access pro- 2036 tocol to obtain the referenced description. The accessLocation field 2037 is defined as a GeneralName, which can take several forms. Where the 2038 information is available via http, ftp, or ldap, accessLocation MUST 2039 be a uniformResourceIdentifier. Where the information is available 2040 via the directory access protocol (dap), accessLocation MUST be a 2041 directoryName. When the information is available via electronic mail, 2042 accessLocation MUST be an rfc822Name. The semantics of other name 2043 forms of accessLocation (when accessMethod is id-ad-caIssuers) are 2044 not defined by this specification. The information 2046 Additional access descriptors may be defined in other PKIX specifica- 2047 tions. 2049 5 CRL and CRL Extensions Profile 2051 As described above, one goal of this X.509 v2 CRL profile is to 2052 foster the creation of an interoperable and reusable Internet PKI. 2053 To achieve this goal, guidelines for the use of extensions are speci- 2054 fied, and some assumptions are made about the nature of information 2055 included in the CRL. 2057 CRLs may be used in a wide range of applications and environments 2058 covering a broad spectrum of interoperability goals and an even 2059 broader spectrum of operational and assurance requirements. This 2060 profile establishes a common baseline for generic applications 2061 requiring broad interoperability. The profile defines a baseline set 2062 of information that can be expected in every CRL. Also, the profile 2063 defines common locations within the CRL for frequently used attri- 2064 butes as well as common representations for these attributes. 2066 This profile does not define any private Internet CRL extensions or 2067 CRL entry extensions. 2069 Environments with additional or special purpose requirements may 2070 build on this profile or may replace it. 2072 Conforming CAs are not required to issue CRLs if other revocation or 2073 certificate status mechanisms are provided. Conforming CAs that 2074 issue CRLs MUST issue version 2 CRLs, and CAs MUST include the date 2075 by which the next CRL will be issued in the nextUpdate field (see 2076 sec. 5.1.2.5), the CRL number extension (see sec. 5.2.3) and the 2077 authority key identifier extension (see sec. 5.2.1). Conforming 2078 applications are required to process version 1 and 2 CRLs. 2080 5.1 CRL Fields 2082 The X.509 v2 CRL syntax is as follows. For signature calculation, 2083 the data that is to be signed is ASN.1 DER encoded. ASN.1 DER encod- 2084 ing is a tag, length, value encoding system for each element. 2086 CertificateList ::= SEQUENCE { 2087 tbsCertList TBSCertList, 2088 signatureAlgorithm AlgorithmIdentifier, 2089 signatureValue BIT STRING } 2091 TBSCertList ::= SEQUENCE { 2092 version Version OPTIONAL, 2093 -- if present, shall be v2 2094 signature AlgorithmIdentifier, 2095 issuer Name, 2096 thisUpdate Time, 2097 nextUpdate Time OPTIONAL, 2098 revokedCertificates SEQUENCE OF SEQUENCE { 2099 userCertificate CertificateSerialNumber, 2100 revocationDate Time, 2101 crlEntryExtensions Extensions OPTIONAL 2102 -- if present, shall be v2 2103 } OPTIONAL, 2104 crlExtensions [0] EXPLICIT Extensions OPTIONAL 2105 -- if present, shall be v2 2106 } 2108 -- Version, Time, CertificateSerialNumber, and Extensions 2109 -- are all defined in the ASN.1 in section 4.1 2110 -- AlgorithmIdentifier is defined in section 4.1.1.2 2112 The following items describe the use of the X.509 v2 CRL in the 2113 Internet PKI. 2115 5.1.1 CertificateList Fields 2117 The CertificateList is a SEQUENCE of three required fields. The 2118 fields are described in detail in the following subsections. 2120 5.1.1.1 tbsCertList 2122 The first field in the sequence is the tbsCertList. This field is 2123 itself a sequence containing the name of the issuer, issue date, 2124 issue date of the next list, the optional list of revoked certifi- 2125 cates, and optional CRL extensions. When there are no revoked certi- 2126 ficates, the revoked certificates list is absent. When one or more 2127 certificates are revoked, each entry on the revoked certificate list 2128 is defined by a sequence of user certificate serial number, revoca- 2129 tion date, and optional CRL entry extensions. 2131 5.1.1.2 signatureAlgorithm 2133 The signatureAlgorithm field contains the algorithm identifier for 2134 the algorithm used by the CA to sign the CertificateList. The field 2135 is of type AlgorithmIdentifier, which is defined in section 4.1.1.2. 2136 Section 7.2 lists the supported algorithms for this specification. 2137 Conforming CAs MUST use the algorithm identifiers presented in sec- 2138 tion 7.2 when signing with a supported signature algorithm. 2140 This field MUST contain the same algorithm identifier as the signa- 2141 ture field in the sequence tbsCertList (see sec. 5.1.2.2). 2143 5.1.1.3 signatureValue 2145 The signatureValue field contains a digital signature computed upon 2146 the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded tbsCertList 2147 is used as the input to the signature function. This signature value 2148 is then ASN.1 encoded as a BIT STRING and included in the CRL's sig- 2149 natureValue field. The details of this process are specified for each 2150 of the supported algorithms in section 7.2. 2152 5.1.2 Certificate List "To Be Signed" 2154 The certificate list to be signed, or TBSCertList, is a SEQUENCE of 2155 required and optional fields. The required fields identify the CRL 2156 issuer, the algorithm used to sign the CRL, the date and time the CRL 2157 was issued, and the date and time by which the CA will issue the next 2158 CRL. 2160 Optional fields include lists of revoked certificates and CRL exten- 2161 sions. The revoked certificate list is optional to support the case 2162 where a CA has not revoked any unexpired certificates that it has 2163 issued. The profile requires conforming CAs to use the CRL extension 2164 cRLNumber in all CRLs issued. 2166 5.1.2.1 Version 2168 This optional field describes the version of the encoded CRL. When 2169 extensions are used, as required by this profile, this field MUST be 2170 present and MUST specify version 2 (the integer value is 1). 2172 5.1.2.2 Signature 2174 This field contains the algorithm identifier for the algorithm used 2175 to sign the CRL. Section 7.2 lists OIDs for the most popular signa- 2176 ture algorithms used in the Internet PKI. 2178 This field MUST contain the same algorithm identifier as the signa- 2179 tureAlgorithm field in the sequence CertificateList (see section 2180 5.1.1.2). 2182 5.1.2.3 Issuer Name 2184 The issuer name identifies the entity who has signed and issued the 2185 CRL. The issuer identity is carried in the issuer name field. Alter- 2186 native name forms may also appear in the issuerAltName extension (see 2187 sec. 5.2.2). The issuer name field MUST contain an X.500 dis- 2188 tinguished name (DN). The issuer name field is defined as the X.501 2189 type Name, and MUST follow the encoding rules for the issuer name 2190 field in the certificate (see sec. 4.1.2.4). 2192 5.1.2.4 This Update 2194 This field indicates the issue date of this CRL. ThisUpdate may be 2195 encoded as UTCTime or GeneralizedTime. 2197 CAs conforming to this profile that issue CRLs MUST encode thisUpdate 2198 as UTCTime for dates through the year 2049. CAs conforming to this 2199 profile that issue CRLs MUST encode thisUpdate as GeneralizedTime for 2200 dates in the year 2050 or later. 2202 Where encoded as UTCTime, thisUpdate MUST be specified and inter- 2203 preted as defined in section 4.1.2.5.1. Where encoded as General- 2204 izedTime, thisUpdate MUST be specified and interpreted as defined in 2205 section 4.1.2.5.2. 2207 5.1.2.5 Next Update 2209 This field indicates the date by which the next CRL will be issued. 2210 The next CRL could be issued before the indicated date, but it will 2211 not be issued any later than the indicated date. CAs SHOULD issue 2212 CRLs with a nextUpdate time equal to or later than all previous CRLs. 2213 nextUpdate may be encoded as UTCTime or GeneralizedTime. 2215 This profile requires inclusion of nextUpdate in all CRLs issued by 2216 conforming CAs. Note that the ASN.1 syntax of TBSCertList describes 2217 this field as OPTIONAL, which is consistent with the ASN.1 structure 2218 defined in [X.509]. The behavior of clients processing CRLs which 2219 omit nextUpdate is not specified by this profile. 2221 CAs conforming to this profile that issue CRLs MUST encode nextUpdate 2222 as UTCTime for dates through the year 2049. CAs conforming to this 2223 profile that issue CRLs MUST encode nextUpdate as GeneralizedTime for 2224 dates in the year 2050 or later. 2226 Where encoded as UTCTime, nextUpdate MUST be specified and inter- 2227 preted as defined in section 4.1.2.5.1. Where encoded as General- 2228 izedTime, nextUpdate MUST be specified and interpreted as defined in 2229 section 4.1.2.5.2. 2231 5.1.2.6 Revoked Certificates 2233 When there are no revoked certificates, the revoked certificates list 2234 is absent. Otherwise, revoked certificates are listed by their 2235 serial numbers. Certificates revoked by the CA are uniquely identi- 2236 fied by the certificate serial number. The date on which the revoca- 2237 tion occurred is specified. The time for revocationDate MUST be 2238 expressed as described in section 5.1.2.4. Additional information may 2239 be supplied in CRL entry extensions; CRL entry extensions are dis- 2240 cussed in section 5.3. 2242 5.1.2.7 Extensions 2244 This field may only appear if the version is 2 (see sec. 5.1.2.1). 2245 If present, this field is a SEQUENCE of one or more CRL extensions. 2246 CRL extensions are discussed in section 5.2. 2248 5.2 CRL Extensions 2250 The extensions defined by ANSI X9 and ISO/IEC/ITU for X.509 v2 CRLs 2251 [X.509] [X9.55] provide methods for associating additional attributes 2252 with CRLs. The X.509 v2 CRL format also allows communities to define 2253 private extensions to carry information unique to those communities. 2254 Each extension in a CRL may be designated as critical or non- 2255 critical. A CRL validation MUST fail if it encounters a critical 2256 extension which it does not know how to process. However, an 2257 unrecognized non-critical extension may be ignored. The following 2258 subsections present those extensions used within Internet CRLs. Com- 2259 munities may elect to include extensions in CRLs which are not 2260 defined in this specification. However, caution should be exercised 2261 in adopting any critical extensions in CRLs which might be used in a 2262 general context. 2264 Conforming CAs that issue CRLs are required to include the authority 2265 key identifier (see sec. 5.2.1) and the CRL number (see sec. 5.2.3) 2266 extensions in all CRLs issued. 2268 5.2.1 Authority Key Identifier 2270 The authority key identifier extension provides a means of identify- 2271 ing the public key corresponding to the private key used to sign a 2272 CRL. The identification can be based on either the key identifier 2273 (the subject key identifier in the CRL signer's certificate) or on 2274 the issuer name and serial number. This extension is especially use- 2275 ful where an issuer has more than one signing key, either due to mul- 2276 tiple concurrent key pairs or due to changeover. 2278 Conforming CAs MUST use the key identifier method, and MUST include 2279 this extension in all CRLs issued. 2281 The syntax for this CRL extension is defined in section 4.2.1.1. 2283 5.2.2 Issuer Alternative Name 2285 The issuer alternative names extension allows additional identities 2286 to be associated with the issuer of the CRL. Defined options include 2287 an rfc822 name (electronic mail address), a DNS name, an IP address, 2288 and a URI. Multiple instances of a name and multiple name forms may 2289 be included. Whenever such identities are used, the issuer alterna- 2290 tive name extension MUST be used. 2292 The issuerAltName extension SHOULD NOT be marked critical. 2294 The OID and syntax for this CRL extension are defined in section 2295 4.2.1.8. 2297 5.2.3 CRL Number 2299 The CRL number is a non-critical CRL extension which conveys a mono- 2300 tonically increasing sequence number for each CRL issued by a CA. 2301 This extension allows users to easily determine when a particular CRL 2302 supersedes another CRL. CAs conforming to this profile MUST include 2303 this extension in all CRLs. 2305 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 2307 cRLNumber ::= INTEGER (0..MAX) 2309 5.2.4 Delta CRL Indicator 2311 The delta CRL indicator is a critical CRL extension that identifies a 2312 CRL as being a delta CRL. Delta CRLs contain updates to revocation 2313 information previously distributed, rather than all the information 2314 that would appear in a complete CRL. The use of delta CRLs can sig- 2315 nificantly reduce network load and processing time in some environ- 2316 ments. Delta CRLs are generally smaller than the CRLs they update, 2317 so applications that obtain delta CRLs consume less network bandwidth 2318 than applications that obtain the corresponding complete CRLs. 2319 Applications which store revocation information in a format other 2320 than the CRL structure can add new revocation information to the 2321 local database without reprocessing information. 2323 The delta CRL indicator extension contains a single value of type 2324 BaseCRLNumber. This value identifies the CRL number of the base CRL 2325 that was used as the foundation in the generation of this delta CRL. 2326 The referenced base CRL is a CRL that was explicitly issued as a CRL 2327 that is complete for a given scope (e.g., a set of revocation reasons 2328 or a particular distribution point.) The CRL containing the delta CRL 2329 indicator extension contains all updates to the certificate revoca- 2330 tion status for that same scope. The combination of a CRL containing 2331 the delta CRL indicator extension plus the CRL referenced in the 2332 BaseCRLNumber component of this extension is equivalent to a full 2333 CRL, for the applicable scope, at the time of publication of the 2334 delta CRL. 2336 When a conforming CA issues a delta CRL, the CA MUST also issue a CRL 2337 that is complete for the given scope. The CRL number extension in 2338 the delta CRL and the complete CRL MUST contain the same value. When 2339 a delta CRL is issued, it MUST cover the same set of reasons and same 2340 set of certificates that were covered by the base CRL it references. 2342 An application can construct a CRL that is complete for a given 2343 scope, at the current time, in either of the following ways: 2344 (a) by retrieving the current delta CRL for that scope, and com- 2345 bining it with an issued CRL that is complete for that scope and 2346 that has a cRLNumber greater than or equal to the cRLNumber of the 2347 base CRL referenced in the delta CRL; or 2348 (b) by retrieving the current delta CRL for that scope and combin- 2349 ing it with a locally constructed CRL whose cRLNumber is greater 2350 than or equal to the cRLNumber of the base CRL referenced in the 2351 current delta CRL. 2353 The constructed CRL has the CRL number specified in the CRL number 2354 extension found in the delta CRL used in its construction. 2356 CAs must ensure that application of a delta CRL to the referenced 2357 base revocation information accurately reflects the current status of 2358 revocation. If a CA supports the certificateHold revocation reason 2359 the following rules must be applied when generating delta CRLs: 2361 (a) If a certificate was listed as revoked with revocation reason 2362 certificateHold on a CRL (either a delta CRL or a CRL that is com- 2363 plete for a given scope), whose cRLNumber is n, and the hold is 2364 subsequently released, the certificate must be included in all 2365 delta CRLs issued after the hold is released where the cRLNumber 2366 of the referenced base CRL is less than or equal to n. The certi- 2367 ficate must be listed with revocation reason removeFromCRL unless 2368 the certificate is subsequently revoked again for one of the revo- 2369 cation reasons covered by the delta CRL, in which case the certi- 2370 ficate must be listed with the revocation reason appropriate for 2371 the subsequent revocation. 2373 (b) If the certificate was not removed from hold, but was per- 2374 manently revoked, then it must be listed on all subsequent delta 2375 CRLs where the cRLNumber of the referenced base CRL is less than 2376 the cRLNumber of the CRL (either a delta CRL or a CRL that is com- 2377 plete for the given scope) on which the permanent revocation 2378 notice first appeared. 2380 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 2382 deltaCRLIndicator EXTENSION ::= { 2383 SYNTAX BaseCRLNumber 2384 IDENTIFIED BY id-ce-deltaCRLIndicator } 2386 BaseCRLNumber ::= CRLNumber 2388 5.2.5 Issuing Distribution Point 2390 The issuing distribution point is a critical CRL extension that iden- 2391 tifies the CRL distribution point for a particular CRL, and it indi- 2392 cates whether the CRL covers revocation for end entity certificates 2393 only, CA certificates only, or a limited set of reason codes. 2394 Although the extension is critical, conforming implementations are 2395 not required to support this extension. 2397 The CRL is signed using the CA's private key. CRL Distribution 2398 Points do not have their own key pairs. If the CRL is stored in the 2399 X.500 Directory, it is stored in the Directory entry corresponding to 2400 the CRL distribution point, which may be different than the Directory 2401 entry of the CA. 2403 The reason codes associated with a distribution point shall be speci- 2404 fied in onlySomeReasons. If onlySomeReasons does not appear, the dis- 2405 tribution point shall contain revocations for all reason codes. CAs 2406 may use CRL distribution points to partition the CRL on the basis of 2407 compromise and routine revocation. In this case, the revocations 2408 with reason code keyCompromise (1) and cACompromise (2) appear in one 2409 distribution point, and the revocations with other reason codes 2410 appear in another distribution point. 2412 Where the issuingDistributionPoint extension contains a URL, the fol- 2413 lowing semantics MUST be assumed: the object is a pointer to the most 2414 current CRL issued by this CA. The URI schemes ftp, http, mailto 2415 [RFC1738] and ldap [RFC1778] are defined for this purpose. The URI 2416 MUST be an absolute, not relative, pathname and MUST specify the 2417 host. 2419 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 2421 issuingDistributionPoint ::= SEQUENCE { 2422 distributionPoint [0] DistributionPointName OPTIONAL, 2423 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 2424 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 2425 onlySomeReasons [3] ReasonFlags OPTIONAL, 2426 indirectCRL [4] BOOLEAN DEFAULT FALSE } 2428 5.3 CRL Entry Extensions 2430 The CRL entry extensions already defined by ANSI X9 and ISO/IEC/ITU 2431 for X.509 v2 CRLs provide methods for associating additional attri- 2432 butes with CRL entries [X.509] [X9.55]. The X.509 v2 CRL format also 2433 allows communities to define private CRL entry extensions to carry 2434 information unique to those communities. Each extension in a CRL 2435 entry may be designated as critical or non-critical. A CRL valida- 2436 tion MUST fail if it encounters a critical CRL entry extension which 2437 it does not know how to process. However, an unrecognized non- 2438 critical CRL entry extension may be ignored. The following subsec- 2439 tions present recommended extensions used within Internet CRL entries 2440 and standard locations for information. Communities may elect to use 2441 additional CRL entry extensions; however, caution should be exercised 2442 in adopting any critical extensions in CRL entries which might be 2443 used in a general context. 2445 All CRL entry extensions used in this specification are non-critical. 2446 Support for these extensions is optional for conforming CAs and 2447 applications. However, CAs that issue CRLs SHOULD include reason 2448 codes (see sec. 5.3.1) and invalidity dates (see sec. 5.3.3) whenever 2449 this information is available. 2451 5.3.1 Reason Code 2453 The reasonCode is a non-critical CRL entry extension that identifies 2454 the reason for the certificate revocation. CAs are strongly 2455 encouraged to include meaningful reason codes in CRL entries; how- 2456 ever, the reason code CRL entry extension SHOULD be absent instead of 2457 using the unspecified (0) reasonCode value. 2459 id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 } 2461 -- reasonCode ::= { CRLReason } 2463 CRLReason ::= ENUMERATED { 2464 unspecified (0), 2465 keyCompromise (1), 2466 cACompromise (2), 2467 affiliationChanged (3), 2468 superseded (4), 2469 cessationOfOperation (5), 2470 certificateHold (6), 2471 removeFromCRL (8) } 2473 5.3.2 Hold Instruction Code 2475 The hold instruction code is a non-critical CRL entry extension that 2476 provides a registered instruction identifier which indicates the 2477 action to be taken after encountering a certificate that has been 2478 placed on hold. 2480 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 2482 holdInstructionCode ::= OBJECT IDENTIFIER 2484 The following instruction codes have been defined. Conforming appli- 2485 cations that process this extension MUST recognize the following 2486 instruction codes. 2488 holdInstruction OBJECT IDENTIFIER ::= 2489 { iso(1) member-body(2) us(840) x9-57(10040) 2 } 2491 id-holdinstruction-none OBJECT IDENTIFIER ::= {holdInstruction 1} 2492 id-holdinstruction-callissuer 2493 OBJECT IDENTIFIER ::= {holdInstruction 2} 2494 id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3} 2495 Conforming applications which encounter an id-holdinstruction- 2496 callissuer MUST call the certificate issuer or reject the certifi- 2497 cate. Conforming applications which encounter an id- 2498 holdinstruction-reject MUST reject the certificate. The hold instruc- 2499 tion id-holdinstruction-none is semantically equivalent to the 2500 absence of a holdInstructionCode, and its use is strongly deprecated 2501 for the Internet PKI. 2503 5.3.3 Invalidity Date 2505 The invalidity date is a non-critical CRL entry extension that pro- 2506 vides the date on which it is known or suspected that the private key 2507 was compromised or that the certificate otherwise became invalid. 2508 This date may be earlier than the revocation date in the CRL entry, 2509 which is the date at which the CA processed the revocation. When a 2510 revocation is first posted by a CA in a CRL, the invalidity date may 2511 precede the date of issue of earlier CRLs, but the revocation date 2512 SHOULD NOT precede the date of issue of earlier CRLs. Whenever this 2513 information is available, CAs are strongly encouraged to share it 2514 with CRL users. 2516 The GeneralizedTime values included in this field MUST be expressed 2517 in Greenwich Mean Time (Zulu), and MUST be specified and interpreted 2518 as defined in section 4.1.2.5.2. 2520 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 2522 invalidityDate ::= GeneralizedTime 2524 5.3.4 Certificate Issuer 2526 This CRL entry extension identifies the certificate issuer associated 2527 with an entry in an indirect CRL, i.e. a CRL that has the indirectCRL 2528 indicator set in its issuing distribution point extension. If this 2529 extension is not present on the first entry in an indirect CRL, the 2530 certificate issuer defaults to the CRL issuer. On subsequent entries 2531 in an indirect CRL, if this extension is not present, the certificate 2532 issuer for the entry is the same as that for the preceding entry. 2533 This field is defined as follows: 2535 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } 2537 certificateIssuer ::= GeneralNames 2539 If used by conforming CAs that issue CRLs, this extension is always 2540 critical. If an implementation ignored this extension it could not 2541 correctly attribute CRL entries to certificates. This specification 2542 RECOMMENDS that implementations recognize this extension. 2544 6 Certification Path Validation 2546 Certification path validation procedures for the Internet PKI are 2547 based on section 12.4.3 of [X.509]. Certification path processing 2548 verifies the binding between the subject distinguished name and/or 2549 subject alternative name and subject public key. The binding is lim- 2550 ited by constraints which are specified in the certificates which 2551 comprise the path. The basic constraints and policy constraints 2552 extensions allow the certification path processing logic to automate 2553 the decision making process. 2555 This section describes an algorithm for validating certification 2556 paths. Conforming implementations of this specification are not 2557 required to implement this algorithm, but MUST be functionally 2558 equivalent to the external behavior resulting from this procedure. 2559 Any algorithm may be used by a particular implementation so long as 2560 it derives the correct result. 2562 In section 6.1, the text describes basic path validation. This text 2563 assumes that all valid paths begin with certificates issued by a sin- 2564 gle "most-trusted CA". The algorithm requires the public key of the 2565 CA, the CA's name, the validity period of the public key, and any 2566 constraints upon the set of paths which may be validated using this 2567 key. 2569 The "most-trusted CA" is a matter of policy: it could be a root CA in 2570 a hierarchical PKI; the CA that issued the verifier's own 2571 certificate(s); or any other CA in a network PKI. The path valida- 2572 tion procedure is the same regardless of the choice of "most-trusted 2573 CA." 2575 section 6.2 describes extensions to the basic path validation algo- 2576 rithm. Two specific cases are discussed: the case where paths may 2577 begin with one of several trusted CAs; and where compatibility with 2578 the PEM architecture is required. 2580 6.1 Basic Path Validation 2582 This text describes an algorithm for X.509 path processing. A con- 2583 formant implementation MUST include an X.509 path processing pro- 2584 cedure that is functionally equivalent to the external behavior of 2585 this algorithm. 2587 This text assumes that there is a single trust anchor for certifica- 2588 tion path processing, which simplifies the description of the path 2589 processing procedure. This procedure can be extended to address mul- 2590 tiple trust anchors, as discussed further in Section 6.2. 2592 The primary goal of path validation is to verify the binding between 2593 a subject distinguished name or subject alternative name and subject 2594 public key, as represented in the end entity certificate, based on 2595 the public key of the trust anchor. This requires obtaining a 2596 sequence of certificates that support that binding. The procedure 2597 performed to obtain this sequence of certificates is outside the 2598 scope of this section. 2600 To meet this goal, the path validation process verifies, among other 2601 things, that a prospective certification path (a sequence of n certi- 2602 ficates) satisfies the following conditions: 2603 (i) for all x in {1, ..., n-1}, the subject of certificate x is 2604 the issuer of certificate x+1; 2605 (ii) certificate 1 is issued by the trust anchor; 2606 (iii) certificate n is the end entity certificate; and 2607 (iv) for all x in {1, ..., n}, the certificate was valid at the 2608 time in question. 2610 A particular certification path may not, however, be appropriate for 2611 all applications. The path validation process also determines the 2612 set of certificate policies that are valid for this path, based on 2613 the certificate policies extension, policy mapping extension, policy 2614 constraints extension, and inhibit any-policy extension. To achieve 2615 this, the path validation algorithm constructs a "valid policy tree." 2616 If the set of certificate policies that are valid for this path is 2617 not empty, then the result will be a valid policy tree of depth n, 2618 otherwise the result will be a NULL valid policy tree. 2620 This section presents the algorithm in four basic steps: (1) initial- 2621 ization, (2) basic certificate processing, (3) preparation for the 2622 next certificate, and (4) wrap-up. Steps (1) and (4) are performed 2623 exactly once. Step (2) is performed for all certificates in the 2624 path. Step (3) is performed for all certificates in the path except 2625 the final certificate. Figure 2 provides a high-level flowchart of 2626 this algorithm. 2628 +-------+ 2629 | START | 2630 +-------+ 2631 | 2632 V 2633 +----------------+ 2634 | Initialization | 2635 +----------------+ 2636 | 2637 +<--------------------+ 2638 | | 2639 V | 2640 +----------------+ | 2641 | Process Cert | | 2642 +----------------+ | 2643 | | 2644 V | 2645 +================+ | 2646 | IF Last Cert | | 2647 | in Path | | 2648 +================+ | 2649 | | | 2650 THEN | | ELSE | 2651 V V | 2652 +----------------+ +----------------+ | 2653 | Wrap up | | Prepare for | | 2654 +----------------+ | Next Cert | | 2655 | +----------------+ | 2656 V | | 2657 +-------+ +--------------+ 2658 | STOP | 2659 +-------+ 2661 Figure 2. Path Processing Flowchart 2663 6.1.1 Inputs 2665 This algorithm assumes the following seven inputs are provided to the 2666 path processing logic: 2668 (a) a prospective certification path of length n; 2670 (b) the time, T, for which the validity of the path should be 2671 determined. This may be the current date/time, or some point in 2672 the past. 2674 (c) user_initial_policy_set: A set of certificate policy identif- 2675 iers naming the policies that are acceptable to the certificate 2676 user. The user_initial_policy_set has the special value "any- 2677 policy" if the user is not concerned about certificate policy. 2679 (d) trust anchor information, describing a CA that serves as a 2680 trust anchor for the certification path. The trust anchor infor- 2681 mation includes: 2682 (1) the trusted issuer name, 2683 (2) optionally, the trusted issuer unique identifier, 2684 (3) the trusted public key algorithm, 2685 (4) the trusted public key, and 2686 (5) optionally, the trusted public key parameters associated 2687 with the public key. 2689 The trust anchor information may be provided to the path process- 2690 ing procedure in the form of a self-signed certificate. The 2691 trusted anchor information is trusted because it was delivered to 2692 the path processing procedure by some trustworthy "out-of-band" 2693 procedure. If the trusted public key algorithm requires parame- 2694 ters, then the parameters are provided along with the trusted pub- 2695 lic key. 2697 (e) initial-policy-mapping-inhibit, which indicates if policy map- 2698 ping is allowed in the certification path. 2700 (f) initial-explicit-policy, which indicates if the path must be 2701 valid for at least one of the certificate policies in the 2702 user_initial_policy_set. 2704 (g) initial-any-policy-inhibit, which indicates whether the any- 2705 policy OID should be processed if it is included in a certificate. 2707 6.1.2 Initialization 2709 The initialization phase establishes twelve state variables based 2710 upon the seven inputs: 2712 (a) valid_policy_tree: A tree of certificate policies with their 2713 optional qualifiers; each of the leaves of the tree represents a 2714 valid policy at this stage in the certification path validation. 2715 If valid policies exist at this stage in the certification path 2716 validation, the depth of the tree is equal to the number of certi- 2717 ficates in the chain that have been processed. If valid policies 2718 do not exist at this stage in the certification path validation, 2719 the tree is set to NULL. Once the tree is set to NULL, policy pro- 2720 cessing ceases. 2722 Each node in the valid_policy_tree includes four data objects: the 2723 valid policy, a set of associated policy qualifiers, a set of one 2724 or more expected policy values, and a criticality indicator. If 2725 the node is at depth x, the components of the node have the fol- 2726 lowing semantics: 2727 (i) The valid_policy is a single policy OID representing a 2728 valid policy for the path of length x. 2729 (ii) The qualifier_set is a set of policy qualifiers associated 2730 with the valid policy in certificate x. 2731 (iii) The criticality_indicator indicates whether the certifi- 2732 cate policy extension in certificate x was marked as critical. 2733 (iv) The expected_policy_set contains one or more policy OIDs 2734 that would satisfy this policy in the certificate x+1. 2736 The initial value of the valid_policy_tree is a single node with 2737 valid_policy "any-policy", an empty qualifier_set, an 2738 expected_policy_set with the single value "any-policy", and a 2739 criticality_indicator of FALSE. This node is considered to be at 2740 depth zero. 2742 Figure 3 is a graphic representation of the initial state of the 2743 valid_policy_tree. Additional figures will use this format to 2744 describe changes in the valid_policy_tree during path processing. 2746 +-----------------+ 2747 | "any-policy" | <---- valid_policy 2748 +-----------------+ 2749 | {} | <---- qualifier_set 2750 +-----------------+ 2751 | FALSE | <---- criticality_indicator 2752 +-----------------+ 2753 | {"any-policy"} | <---- expected_policy_set 2754 +-----------------+ 2756 Figure 3. Initial value of the valid_policy_tree state variable 2758 (b) permitted_subtrees: A set of root names for each name type 2759 (e.g., X.500 distinguished names, email addresses, or ip 2760 addresses) defining a set of subtrees within which all subject 2761 names in subsequent certificates in the certification path shall 2762 fall. This variable includes a set for each name type: the initial 2763 value for the set for Distinguished Names is the set of all Dis- 2764 tinguished names; the initial value for the set of RFC822 names is 2765 the set of all RFC822 names, etc. 2767 (c) excluded_subtrees: A set of root names for each name type 2768 (e.g., X.500 distinguished names, email addresses, or ip 2769 addresses) defining a set of subtrees within which no subject name 2770 in subsequent certificates in the certification path may fall. 2771 This variable includes a set for each name type, and the initial 2772 value for each set is "empty". 2774 (d) explicit_policy: an integer which indicates if a non-NULL 2775 valid_policy_tree is required. The integer indicates the number of 2776 non-self-issued certificates to be processed before this require- 2777 ment is imposed. Once set, this variable may be decreased, but may 2778 not be increased. That is, if a certificate in the path requires a 2779 non-NULL valid_policy_tree, a later certificate can not remove 2780 this requirement. If initial-explicit-policy is set, then the ini- 2781 tial value is 0, otherwise the initial value is n+1. 2783 (e) inhibit_any-policy: an integer which indicates whether the 2784 "any-policy" policy identifier is considered a match. The integer 2785 indicates the number of non-self-issued certificates to be pro- 2786 cessed before the "any-policy" OID, if asserted in a certificate, 2787 is ignored. Once set, this variable may be decreased, but may not 2788 be increased. That is, if a certificate in the path inhibits pro- 2789 cessing of "any-policy", a later certificate can not permit it. If 2790 initial-any-policy-inhibit is set, then the initial value is 0, 2791 otherwise the initial value is n+1. 2793 (f) policy_mapping: an integer which indicates if policy mapping 2794 is permitted. The integer indicates the number of non-self-issued 2795 certificates to be processed before policy mapping is inhibited. 2796 Once set, this variable may be decreased, but may not be 2797 increased. That is, if a certificate in the path specifies policy 2798 mapping is not permitted, it can not be overridden by a later cer- 2799 tificate. If initial-policy-mapping-inhibit is set, then the ini- 2800 tial value is 0, otherwise the initial value is n+1. 2802 (g) working_public_key_algorithm: the digital signature algorithm 2803 used to verify the signature of a certificate. The 2804 working_public_key_algorithm is initialized from the trusted pub- 2805 lic key algorithm provided in the trust anchor information. 2807 (h) working_public_key: the public key used to verify the signa- 2808 ture of a certificate. The working_public_key is initialized from 2809 the trusted public key provided in the trust anchor information. 2811 (i) working_public_key_parameters: parameters associated with the 2812 current public key, that may required to verify a signature 2813 (depending upon the algorithm). The working_public_key_parameters 2814 variable is initialized from the trusted public key parameters 2815 provided in the trust anchor information. 2817 (j) working_issuer_name: the issuer distinguished name expected 2818 in the next certificate in the chain. The working_issuer_name is 2819 initialized to the trusted issuer provided in the trust anchor 2820 information. 2822 (k) working_issuer_UID: a distinguished name may be associated 2823 with an optional unique identifier. The working_issuer_UID is the 2824 unique identifier that is expected in the next certificate, or the 2825 value NULL. The working_issuer_UID is initialized to the trusted 2826 issuer's unique identifier provided in the trust anchor informa- 2827 tion. 2829 (l) max_path_length: this integer is initialized to n, and is 2830 reset by the path length constraint field within the basic con- 2831 straints extension of a CA certificate. 2833 Upon completion of the initialization steps, perform the basic certi- 2834 ficate processing steps specified in 6.1.3. 2836 6.1.3 Basic Certificate Processing 2838 The basic path processing actions to be performed for certificate i 2839 are listed below. 2841 (a) Verify the basic certificate information. The certificate 2842 must satisfy each of the following: 2844 (1) The certificate was signed with the 2845 working_public_key_algorithm using the working_public_key and 2846 the working_public_key_parameters. 2848 (2) The certificate validity period includes time T. 2850 (3) At time T, the certificate is not revoked and is not on 2851 hold status. This may be determined by obtaining the appropri- 2852 ate CRL (see section 6.3), status information, or by out-of- 2853 band mechanisms. 2855 (4) The certificate issuer name is the working_issuer_name. 2857 (5) The certificate issuer unique identifier is the 2858 working_issuer_UID, meaning: 2859 (i) working_issuer_UID is non-null and matches the value in 2860 the issuerUID field, or 2861 (ii) working_issuer_UID is null and the issuerUID field is 2862 not present. 2864 (b) If certificate i is not self-issued, verify that the subject 2865 name is within one of the permitted_subtrees for X.500 dis- 2866 tinguished names, and verify that each of the alternative names in 2867 the subjectAltName extension (critical or non-critical) is within 2868 one of the permitted_subtrees for that name type. 2870 (c) If certificate i is not self-issued, verify that the subject 2871 name is not within one of the excluded_subtrees for X.500 dis- 2872 tinguished names, and verify that each of the alternative names in 2873 the subjectAltName extension (critical or non-critical) is not 2874 within one of the excluded_subtrees for that name type. 2876 (d) If the certificate policies extension is present in the certi- 2877 ficiate and the valid_policy_tree is not NULL, process the policy 2878 information by performing the following steps in order: 2880 (1) For each policy P not equal to "any-policy" in the certifi- 2881 cate policies extension, let P-OID denote the OID in policy P 2882 and P-Q denote the qualifier set for policy P. Perform the 2883 following steps in order: 2885 (i) If the valid_policy_tree includes a node of depth i-1 2886 where P-OID is in the expected_policy_set, create a child 2887 node as follows: set the valid_policy to OID- P; set the 2888 qualifier_set to P-Q, and set the expected_policy_set to 2889 {P-OID}. 2891 For example, consider a valid_policy_tree with a node of 2892 depth i-1 where the expected_policy_set is {Gold, White}. 2893 Assume the certificate policies Gold and Silver appear in 2894 the certificate policies extension of certificate i. The 2895 Gold policy is matched but the Silver policy is not. This 2896 rule will generate a child node of depth i for the Gold pol- 2897 icy. The result is shown as Figure 4. 2899 |-----------------| 2900 | Red | 2901 |-----------------| 2902 | {} | 2903 |-----------------| node of depth i-1 2904 | FALSE | 2905 |-----------------| 2906 | {Gold, White} | 2907 |-----------------| 2908 | 2909 | 2910 | 2911 V 2912 |-----------------| 2913 | Gold | 2914 |-----------------| 2915 | {} | 2916 |-----------------| node of depth i 2917 | uninitialized | 2918 |-----------------| 2919 | {Gold} | 2920 |-----------------| 2922 Figure 4. Processing an exact match 2924 (ii) If there was no match in step (i) and the 2925 valid_policy_tree includes a node of depth i-1 with the 2926 valid policy "any-policy", generate a child node with the 2927 following values: set the valid_policy to P-OID; set the 2928 qualifier_set to P-Q, and set the expected_policy_set to 2929 {P-OID}. 2931 For example, consider a valid_policy_tree with a node of 2932 depth i-1 where the valid_policy is "any-policy". Assume the 2933 certificate policies Gold and Silver appear in the certifi- 2934 cate policies extension of certificate i. The Gold policy 2935 does not have a qualifier, but the Silver policy has the 2936 qualifier Q-Silver. If Gold and Silver were not matched in 2937 (i) above, this rule will generate two child nodes of depth 2938 i, one for each policy. The result is shown as Figure 5. 2940 |-----------------| 2941 | "any-policy" | 2942 |-----------------| 2943 | {} | 2944 |-----------------| node of depth i-1 2945 | FALSE | 2946 |-----------------| 2947 | {"any-policy"} | 2948 |-----------------| 2949 / \ 2950 / \ 2951 / \ 2952 / \ 2953 |-----------------| |-----------------| 2954 | Gold | | Silver | 2955 |-----------------| |-----------------| 2956 | {} | | {Q-Silver} | 2957 |-----------------| nodes of |-----------------| 2958 | uninitialized | depth i | uninitialized | 2959 |-----------------| |-----------------| 2960 | {Gold} | | {Silver} | 2961 |-----------------| |-----------------| 2963 Figure 5. Processing unmatched policies when a leaf node 2964 specifies "any-policy" 2966 (2) If the certificate policies extension includes the pol- 2967 icy "any-policy" with the qualifier set AP-Q and 2968 inhibit_any-policy is greater than 0, then: 2970 For each node in the valid_policy_tree of depth i-1, for 2971 each value in the expected_policy_set (including "any- 2972 policy") that does not appear in a child node, create a 2973 child node with the following values: set the valid_policy 2974 to the value from the expected_policy_set in the parent 2975 node; set the qualifier_set to AP-Q, and set the 2976 expected_policy_set to the value in the valid_policy from 2977 this node. 2979 For example, consider a valid_policy_tree with a node of 2980 depth i-1 where the expected_policy_set = {Gold, Silver}. 2981 Assume "any-policy" appears in the certificate policies 2982 extension of certificate i, but Gold and Silver do not. 2983 This rule will generate two child nodes of depth i, one for 2984 each policy. The result is shown below as Figure 6. 2986 |-----------------| 2987 | Red | 2988 |-----------------| 2989 | {} | 2990 |-----------------| node of depth i-1 2991 | FALSE | 2992 |-----------------| 2993 | {Gold, Silver} | 2994 |-----------------| 2995 / \ 2996 / \ 2997 / \ 2998 / \ 2999 |-----------------| |-----------------| 3000 | Gold | | Silver | 3001 |-----------------| |-----------------| 3002 | {} | | {} | 3003 |-----------------| nodes of |-----------------| 3004 | uninitialized | depth i | uninitialized | 3005 |-----------------| |-----------------| 3006 | {Gold} | | {Silver} | 3007 |-----------------| |-----------------| 3009 Figure 6. Processing unmatched policies when the certificate 3010 policies extension specifies "any-policy" 3012 (3) If there is a node in the valid_policy_tree of depth i-1 3013 or less without any child nodes, delete that node. Repeat 3014 this step until there are no nodes of depth i-1 or less 3015 without children. 3017 For example, consider the valid_policy_tree shown in Figure 3018 7 below. The two nodes at depth i-1 that are marked with an 3019 to the resulting tree will cause the node at depth i-2 that 3020 is marked with an 'Y' to be deleted. The following applica- 3021 tion of the rule does not cause any nodes to be deleted, and 3022 this step is complete. 3024 +-----------+ 3025 | | node of depth i-3 3026 +-----------+ 3027 / | \ 3028 / | \ 3029 / | \ 3030 / | \ 3031 +-----------+ +-----------+ +-----------+ 3032 | | | | | Y | nodes of 3033 +-----------+ +-----------+ +-----------+ depth i-2 3034 / \ \ \ 3035 / \ \ \ 3036 +-----------+ +-----------+ +-----------+ +-----------+ nodes of 3037 | | | X | | | | X | depth 3038 +-----------+ +-----------+ +-----------+ +-----------+ i-1 3039 | / | \ 3040 | / | \ 3041 | / | \ 3042 +-----------+ +-----------+ +-----------+ +-----------+ nodes of 3043 | | | | | | | | depth 3044 +-----------+ +-----------+ +-----------+ +-----------+ i 3046 Figure 7. Pruning the valid_policy_tree 3048 (4) If the certificate policies extension was marked as criti- 3049 cal, set the criticality_indicator in all nodes of depth i to 3050 TRUE. If the certificate policies extension was not marked 3051 critical, set the criticality_indicator in all nodes of depth i 3052 to FALSE. 3054 (e) If the certificate policies extension is not present, set the 3055 valid_policy_tree to NULL. 3057 (f) verify that either explicit_policy is greater than 0 or the 3058 valid_policy_tree is not equal to NULL; 3060 If any of steps (a), (b), (c), or (f) fails, the procedure ter- 3061 minates, returning a failure indication and an appropriate reason. 3063 If i is not equal to n, continue by performing the preparatory steps 3064 listed in 6.1.4. If i is equal to n, perform the wrap-up steps 3065 listed in 6.1.5. 3067 6.1.4 Preparation for Certificate i+1 3069 To prepare for processing of certificate i+1, perform the following 3070 steps for certificate i: 3072 (a) If a policy mapping extension is present, verify that the spe- 3073 cial value "any-policy" does not appear as an issuerDomainPolicy 3074 or a subjectDomainPolicy. 3076 (b) If a policy mapping extension is present, then for each 3077 issuerDomainPolicy ID-P in the policy mapping extension: 3079 (1) If the policy_mapping variable is greater than 0, for each 3080 node in the valid_policy_tree of depth i where ID-P is the 3081 valid_policy, set expected_policy_set to the set of sub- 3082 jectDomainPolicy values that are specified as equivalent to 3083 ID-P by the policy mapping extension. 3085 (2) If the policy_mapping variable is equal to 0: 3087 (i) delete each node of depth i in the valid_policy_tree 3088 where ID-P is the valid_policy. 3089 (ii) If there is a node in the valid_policy_tree of depth 3090 i-1 or less without any child nodes, delete that node. 3091 Repeat this step until there are no nodes of depth i-1 or 3092 less without children. 3094 (c) Assign the certificate subject name to working_issuer_name. 3096 (d) Assign the certificate subjectPublicKey to working_public_key. 3098 (e) If the subjectPublicKeyInfo field of the certificate contains 3099 an algorithm field with non-null parameters, assign the parameters 3100 to the working_public_key_parameters variable. 3102 If the subjectPublicKeyInfo field of the certificate contains an 3103 algorithm field with null parameters or parameters are omitted, 3104 compare the certificate subjectPublicKey algorithm to the 3105 working_public_key_algorithm. If the certificate subjectPublicKey 3106 algorithm and the working_public_key_algorithm are different, set 3107 the working_public_key_parameters to null. 3109 (f) Assign the certificate subjectPublicKey algorithm to the 3110 working_public_key_algorithm variable. 3112 (g) If a name constraints extension is included in the certifi- 3113 cate, modify the permitted_subtrees and excluded_subtrees state 3114 variables as follows: 3116 (1) If permittedSubtrees is present in the certificate, set the 3117 permitted_subtrees state variable to the intersection of its 3118 previous value and the value indicated in the extension field. If 3119 permittedSubtrees does not include a particular name type, the 3120 permitted_subtrees state variable is unchanged for that name type. 3122 (2) If excludedSubtrees is present in the certificate, set the 3123 excluded_subtrees state variable to the union of its previous 3124 value and the value indicated in the extension field. If exclu- 3125 dedSubtrees does not include a particular name type, the 3126 excluded_subtrees state variable is unchanged for that name type. 3128 (h) If the issuer and subject names are not identical: 3130 (1) If explicit_policy is not 0, decrement explicit_policy by 3131 1. 3133 (2) If policy_mapping is not 0, decrement policy_mapping by 1. 3135 (3) If inhibit_any-policy is not 0, decrement inhibit_any- pol- 3136 icy by 1. 3138 (i) If a policy constraints extension is included in the certifi- 3139 cate, modify the explicit_policy and policy_mapping state vari- 3140 ables as follows: 3142 (1) If requireExplicitPolicy is present and is less than 3143 explicit_policy, set explicit_policy to the value of requireEx- 3144 plicitPolicy. 3146 (2) If inhibitPolicyMapping is present and is less than 3147 policy_mapping, set policy_mapping to the value of inhibitPoli- 3148 cyMapping. 3150 (j) If the inhibitAnyPolicy extension is included in the certifi- 3151 cate and is less than inhibit_any-policy, set inhibit_any- policy 3152 to the value of inhibitAnyPolicy. 3154 (k) Verify that the certificate is a CA certificate (as specified 3155 in a basicConstraints extension or as verified out-of-band). 3157 (l) If the certificate was not self-issued, verify that 3158 max_path_length is greater than zero and decrement max_path_length 3159 by 1. 3161 (m) If pathLengthConstraint is present in the certificate and is 3162 less than max_path_length, set max_path_length to the value of 3163 pathLengthConstraint. 3165 (n) If a key usage extension is present and marked critical, 3166 verify that the keyCertSign bit is set. 3168 (o) Recognize and process any other critical extension present in 3169 the certificate. 3171 If check (a), (k), (l), (n) or (o) fails, the procedure terminates, 3172 returning a failure indication and an appropriate reason. 3174 If (a), (k), (l), (n) and (o) have completed successfully, increment 3175 i and perform the basic certificate processing specified in 6.1.2. 3177 6.1.5 Wrap-up procedure 3179 To complete the processing of the end entity certificate, perform the 3180 following steps for certificate n: 3182 (a) If certificate n was not self-issued and explicit_policy is 3183 not 0, decrement explicit_policy by 1. 3185 (b) If a policy constraints extension is included in the certifi- 3186 cate and requireExplicitPolicy is present and has a value of 0, 3187 set the explicit_policy state variable to 0. 3189 (c) Assign the certificate subjectPublicKey to working_public_key. 3191 (d) If the subjectPublicKeyInfo field of the certificate contains 3192 an algorithm field with non-null parameters, assign the parameters 3193 to the working_public_key_parameters variable. 3195 If the subjectPublicKeyInfo field of the certificate contains an 3196 algorithm field with null parameters or parameters are omitted, 3197 compare the certificate subjectPublicKey algorithm to the 3198 working_public_key_algorithm. If the certificate subjectPublicKey 3199 algorithm and the working_public_key_algorithm are different, set 3200 the working_public_key_parameters to null. 3202 (e) Assign the certificate subjectPublicKey algorithm to the 3203 working_public_key_algorithm variable. 3205 (f) Recognize and process any other critical extension present in 3206 the certificate n. 3208 (g) Calculate the intersection of the valid_policy_tree and the 3209 user_initial_policy_set, as follows: 3211 (i) If the valid_policy_tree is NULL, the intersection is NULL. 3213 (ii) If the valid_policy_tree is not NULL and the 3214 user_initial_policy_set is "any-policy", the intersection is 3215 the entire valid_policy_tree. 3217 (iii) If the valid_policy_tree is not NULL and the 3218 user_initial_policy_set is not "any-policy", calculate the 3219 intersection of the valid_policy_tree and the 3220 user_initial_policy_set as follows: 3221 1. Determine the set of policy nodes whose parent nodes have 3222 a valid_policy of "any-policy". This is the 3223 valid_policy_node_set. 3224 2. If the valid_policy of any node in the 3225 valid_policy_node_set is not in the user_initial_policy_set 3226 and is not "any-policy", delete this node and all its chil- 3227 dren. 3228 3. If there is a node in the valid_policy_tree of depth n-1 3229 or less without any child nodes, delete that node. Repeat 3230 this step until there are no nodes of depth n-1 or less 3231 without children. 3233 Upon completion of all steps, path processing has succeeded if the 3234 value of explicit_policy variable is greater than zero, or the 3235 valid_policy_tree is not NULL. 3237 6.1.6 Outputs 3239 If path processing succeeds, the procedure terminates, returning a 3240 success indication together with final value of the 3241 valid_policy_tree, the working_public_key, the 3242 working_public_key_algorithm, and the working_public_key_parameters. 3244 6.2 Extending Path Validation 3246 The path validation algorithm presented in 6.1 is based on several 3247 simplifying assumptions (e.g., a single trusted CA that starts all 3248 valid paths). This algorithm may be extended for cases where the 3249 assumptions do not hold. 3251 This procedure may be extended for multiple trusted CAs by providing 3252 a set of self-signed certificates to the validation module. In this 3253 case, a valid path could begin with any one of the self-signed certi- 3254 ficates. Limitations in the trust paths for any particular key may 3255 be incorporated into the self-signed certificate's extensions. In 3256 this way, the self-signed certificates permit the path validation 3257 module to automatically incorporate local security policy and 3258 requirements. 3260 It is also possible to specify an extended version of the above cer- 3261 tification path processing procedure which results in default 3262 behavior identical to the rules of PEM [RFC 1422]. In this extended 3263 version, additional inputs to the procedure are a list of one or more 3264 Policy Certification Authorities (PCAs) names and an indicator of the 3265 position in the certification path where the PCA is expected. At the 3266 nominated PCA position, the CA name is compared against this list. 3267 If a recognized PCA name is found, then a constraint of Subordina- 3268 teToCA is implicitly assumed for the remainder of the certification 3269 path and processing continues. If no valid PCA name is found, and if 3270 the certification path cannot be validated on the basis of identified 3271 policies, then the certification path is considered invalid. 3273 6.3 CRL Validation 3275 This section describes the steps necessary to determine if a certifi- 3276 cate is revoked or on hold status when CRLs are the revocation 3277 mechanism used by the certificate issuer. Conforming implementations 3278 of this specification are not required to implement this algorithm, 3279 but MUST be functionally equivalent to the external behavior result- 3280 ing from this procedure. Any algorithm may be used by a particular 3281 implementation so long as it derives the correct result. 3283 This algorithm defines a set of inputs, a set of state variables, and 3284 processing steps that are performed for each certificate in the path. 3286 6.3.1 Revocation Inputs 3288 To support revocation processing, the algorithm requires two inputs: 3290 (a) certificate: the algorithm requires the certificate serial 3291 number and issuer name to determine if a certificate is on a par- 3292 ticular CRL. The basicConstraints extension is used to determine 3293 whether the supplied certificate is associated with a CA or an 3294 end-entity. If present, the algorithm may use the cRLDistribu- 3295 tionsPoint and freshestCRL extensions to determine revocation 3296 status. 3298 (b) use-deltas: This boolean input determines if the delta needs 3299 to be checked if the CRL is still valid 3301 Note that implementations supporting legacy PKIs, such as RFC 1422 3302 and X.509 version 1, will need an additional input indicating 3303 whether the supplied certificate is associated with a CA or an 3304 end-entity. 3306 6.3.2 Initialization and Revocation State Variables 3308 To support CRL processing, the algorithm requires the following state 3309 variables: 3311 (a) reasons_mask: This variable contains the set of revocation 3312 reasons supported by the CRLs and delta CRLs processed so far. The 3313 legal members of the set are the possible values for reasonflags: 3314 unspecified; keyCompromise; caCompromise; affiliationChanged; 3315 superseded; cessationOfOperation; and certificateHold. The spe- 3316 cial value "all-reasons" is used to denote the set of all legal 3317 members. This variable is initialized to the empty set. 3319 (b) cert_status: This variable contains the status of the certifi- 3320 cate. Legal values are unspecified; keyCompromise; caCompromise; 3321 affiliationChanged; superseded; cessationOfOperation; and certifi- 3322 cateHold, the special value "UNREVOKED", or the special value 3323 "UNDETERMINED". This variable is initialized to the special value 3324 "UNREVOKED". 3326 (c) interim_reasons_mask: This contains the set of revocation rea- 3327 sons supported by the CRL or delta CRL currently being processed. 3329 Note: In some environments, it is not necessary to check all reason 3330 codes. For example, some envornments only are concerned with 3331 caCompromise and keyCompromise for CA certificates. This algorithnm 3332 checks all reason codes. Additional processing and state variables 3333 may be necessary to limit the checking to a subset of the reason 3334 codes. 3336 6.3.3 CRL Processing 3338 This algorithm begins by assuming the certificate is not revoked. 3339 The algorithm checks one or more CRLs until either the certificate 3340 status is determined to be revoked or sufficent CRLs have been 3341 checked to cover all reason codes. 3343 For each distribution point (DP) in the crl distribution points 3344 extension while ((reasons_mask is not "all-reasons") and (cert_status 3345 is UNREVOKED)) 3347 (1) locate the corresponding CRL in CRL cache, and perform the 3348 following verifications: 3350 (a) compute the interim_reasons_mask for this CRL as follows: 3352 1. if the CRL includes reasons and the DP includes reasons, 3353 then set interim_reasons_mask to the intersection of of rea- 3354 sons in the DP and reasons in CRL reasons extension. 3356 2. if the CRL includes reasons but the DP omits reasons, 3357 then set interim_reasons_mask to the value of CRL reasons. 3359 3. if the CRL omits reasons but the DP includes reasons, 3360 then set interim_reasons_mask to the value of DP reasons. 3362 4. if the CRL omits reasons and the DP omits reasons, then 3363 set interim_reasons_mask to the special value "all-reasons". 3365 Verify that interim_reasons_mask includes one or more reasons 3366 that is not included in the reasons_mask. 3368 (b) Verify the issuer of the CRL as follows: 3370 if the DP includes cRLIssuer, then verify that the CRL 3371 issuer matches cRLIssuer else verify that the CRL issuer 3372 matches the certificate issuer. 3374 (c) obtain and validate the certification path for the CRL 3375 issuer. 3377 (d) validate the signature on the CRL. 3379 (2) If each of the verifications (a) through (d) succeeds, then 3380 perform the following steps: 3382 (a) If the value of next update field is before the current- 3383 time, otain an appropriate delta CRL or discard the CRL. 3385 (b) If the user wants freshest available info AND the freshest 3386 CRL extension is present, check for a corresponding delta for 3387 this base. 3389 (c) If a delta was obtained in (a) or (b), verify that the 3390 delta CRL addresses the same set of certificates and the same 3391 set of reasons as the CRL. 3393 (d) Perform the checks in step 1 (b) and (c): 3395 1. obtain and validate the certification path for the delta 3396 issuer 3398 2. validate the signature on the delta CRL 3400 (e) If a delta CRL was obtained in (a) or (b), and the 3401 verifications (c) and (d) suceeded, combine the base and 3402 delta to form a complete CRL. 3404 (3) If steps and (1) and (2) succeed, then set reasons_mask to the 3405 union of reasons_mask and interim_reasons_mask 3406 (4) Search for the certificate on the CRL 3408 (a) search for the serial number on the CRL 3410 (b) if (a) succeeds, verify that (1) the CRL entry extension 3411 Certificate issuer is not present or (2) the issuer identified 3412 in the CRL entry extension Certificate issuer is the issuer of 3413 the certificate. 3415 (c) if (a) and (b) succeeded, set the cert_status variable as 3416 appropriate: 3418 1. if the reasons extension is present, set the cert_status 3419 variable to the value of the reasons extension 3421 2. if the reasons extension is not present, set the 3422 cert_status variable to the special value "not specified" 3424 if ((reasons_mask is "all-reasons") OR (if cert_status is not 3425 UNREVOKED) return cert_status 3427 If all CRLs named in the crl distribution points extension have 3428 been exhausted, and the reasons_mask is not "all-reasons" and the 3429 cert_status is still UNREVOKED, the verifier must obtain addi- 3430 tional CRLs. If the 3432 The verifier must repeat the process above with the additional 3433 CRLs not specified in a distribution point. 3435 If all CRLs are exhausted and the reasons_mask is not "all rea- 3436 sons" return the cert_status UNDETERMINED. 3438 7 Algorithm Support 3440 This section describes cryptographic algorithms which may be used 3441 with this profile. The section describes one-way hash functions and 3442 digital signature algorithms which may be used to sign certificates 3443 and CRLs, and identifies OIDs for public keys contained in a certifi- 3444 cate. 3446 Conforming CAs and applications are not required to support the algo- 3447 rithms or algorithm identifiers described in this section. However, 3448 conforming CAs and applications that use the algorithms identified 3449 here MUST support them as specified. 3451 7.1 One-way Hash Functions 3453 This section identifies one-way hash functions for use in the Inter- 3454 net PKI. One-way hash functions are also called message digest algo- 3455 rithms. SHA-1 is the preferred one-way hash function for the Internet 3456 PKI. However, PEM uses MD2 for certificates [RFC 1422] [RFC 1423] 3457 and MD5 is used in other legacy applications. For this reason, MD2 3458 and MD5 are included in this profile. 3460 7.1.1 MD2 One-way Hash Function 3462 MD2 was developed by Ron Rivest for RSA Data Security. RSA Data Secu- 3463 rity has not placed the MD2 algorithm in the public domain. Rather, 3464 RSA Data Security has granted license to use MD2 for non-commercial 3465 Internet Privacy-Enhanced Mail. For this reason, MD2 may continue to 3466 be used with PEM certificates, but SHA-1 is preferred. MD2 produces 3467 a 128-bit "hash" of the input. MD2 is fully described in RFC 1319 3468 [RFC 1319]. 3470 At the Selected Areas in Cryptography '95 conference in May 1995, 3471 Rogier and Chauvaud presented an attack on MD2 that can nearly find 3472 collisions [RC95]. Collisions occur when one can find two different 3473 messages that generate the same message digest. A checksum operation 3474 in MD2 is the only remaining obstacle to the success of the attack. 3475 For this reason, the use of MD2 for new applications is discouraged. 3476 It is still reasonable to use MD2 to verify existing signatures, as 3477 the ability to find collisions in MD2 does not enable an attacker to 3478 find new messages having a previously computed hash value. 3480 7.1.2 MD5 One-way Hash Function 3482 MD5 was developed by Ron Rivest for RSA Data Security. RSA Data Secu- 3483 rity has placed the MD5 algorithm in the public domain. MD5 produces 3484 a 128-bit "hash" of the input. MD5 is fully described in RFC 1321 3485 [RFC 1321]. 3487 Den Boer and Bosselaers [DB94] have found pseudo-collisions for MD5, 3488 but there are no other known cryptanalytic results. The use of MD5 3489 for new applications is discouraged. It is still reasonable to use 3490 MD5 to verify existing signatures. 3492 7.1.3 SHA-1 One-way Hash Function 3494 SHA-1 was developed by the U.S. Government. SHA-1 produces a 160-bit 3495 "hash" of the input. SHA-1 is fully described in FIPS 180-1 [FIPS 3496 180-1]. 3498 SHA-1 is the one-way hash function of choice for use with both the 3499 RSA and DSA signature algorithms (see sec. 7.2). 3501 7.2 Signature Algorithms 3503 Certificates and CRLs described by this standard may be signed with 3504 any public key signature algorithm. The certificate or CRL indicates 3505 the algorithm through an algorithm identifier which appears in the 3506 signatureAlgorithm field in a Certificate or CertificateList. This 3507 algorithm identifier is an OID and has optionally associated parame- 3508 ters. This section identifies algorithm identifiers and parameters 3509 that shall be used in the signatureAlgorithm field in a Certificate 3510 or CertificateList. 3512 RSA and DSA are the most popular signature algorithms used in the 3513 Internet. Signature algorithms are always used in conjunction with a 3514 one-way hash function identified in section 7.1. 3516 The signature algorithm and one-way hash function used to sign a cer- 3517 tificate or CRL is indicated by use of an algorithm identifier. An 3518 algorithm identifier is an OID, and may include associated parame- 3519 ters. This section identifies OIDS for RSA and DSA. The contents of 3520 the parameters component for each algorithm vary; details are pro- 3521 vided for each algorithm. 3523 The data to be signed (e.g., the one-way hash function output value) 3524 is formatted for the signature algorithm to be used. Then, a private 3525 key operation (e.g., RSA encryption) is performed to generate the 3526 signature value. This signature value is then ASN.1 encoded as a BIT 3527 STRING and included in the Certificate or CertificateList in the sig- 3528 nature field. 3530 7.2.1 RSA Signature Algorithm 3532 A patent statement regarding the RSA algorithm can be found at the 3533 end of this profile. 3535 The RSA algorithm is named for its inventors: Rivest, Shamir, and 3536 Adleman. This profile includes three signature algorithms based on 3537 the RSA asymmetric encryption algorithm. The signature algorithms 3538 combine RSA with either the MD2, MD5, or the SHA-1 one-way hash func- 3539 tions. 3541 The signature algorithm with MD2 and the RSA encryption algorithm is 3542 defined in PKCS #1 [RFC 2313]. As defined in RFC 2313, the ASN.1 OID 3543 used to identify this signature algorithm is: 3545 md2WithRSAEncryption OBJECT IDENTIFIER ::= { 3546 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 3547 pkcs-1(1) 2 } 3549 The signature algorithm with MD5 and the RSA encryption algorithm is 3550 defined in PKCS #1 [RFC 2313]. As defined in RFC 2313, the ASN.1 OID 3551 used to identify this signature algorithm is: 3553 md5WithRSAEncryption OBJECT IDENTIFIER ::= { 3554 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 3555 pkcs-1(1) 4 } 3557 The signature algorithm with SHA-1 and the RSA encryption algorithm 3558 is implemented using the padding and encoding conventions described 3559 in PKCS #1 [RFC 2313]. The message digest is computed using the SHA-1 3560 hash algorithm. The ASN.1 object identifier used to identify this 3561 signature algorithm is: 3563 sha-1WithRSAEncryption OBJECT IDENTIFIER ::= { 3564 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 3565 pkcs-1(1) 5 } 3567 When any of these three OIDs appears within the ASN.1 type Algorith- 3568 mIdentifier, the parameters component of that type shall be the ASN.1 3569 type NULL. 3571 The RSA signature generation process and the encoding of the result 3572 is described in detail in RFC 2313. 3574 7.2.2 DSA Signature Algorithm 3576 A patent statement regarding the DSA can be found at the end of this 3577 profile. 3579 The Digital Signature Algorithm (DSA) is also called the Digital Sig- 3580 nature Standard (DSS). DSA was developed by the U.S. Government, and 3581 DSA is used in conjunction with the the SHA-1 one-way hash function. 3582 DSA is fully described in FIPS 186 [FIPS 186]. The ASN.1 OIDs used 3583 to identify this signature algorithm are: 3585 id-dsa-with-sha1 ID ::= { 3586 iso(1) member-body(2) us(840) x9-57 (10040) 3587 x9cm(4) 3 } 3589 Where the id-dsa-with-sha1 algorithm identifier appears as the algo- 3590 rithm field in an AlgorithmIdentifier, the encoding shall omit the 3591 parameters field. That is, the AlgorithmIdentifier shall be a 3592 SEQUENCE of one component - the OBJECT IDENTIFIER id-dsa-with-sha1. 3594 The DSA parameters in the subjectPublicKeyInfo field of the 3595 certificate of the issuer shall apply to the verification of the sig- 3596 nature. 3598 When signing, the DSA algorithm generates two values. These values 3599 are commonly referred to as r and s. To easily transfer these two 3600 values as one signature, they shall be ASN.1 encoded using the fol- 3601 lowing ASN.1 structure: 3603 Dss-Sig-Value ::= SEQUENCE { 3604 r INTEGER, 3605 s INTEGER } 3607 7.3 Subject Public Key Algorithms 3609 Certificates described by this profile may convey a public key for 3610 any public key algorithm. The certificate indicates the algorithm 3611 through an algorithm identifier. This algorithm identifier is an OID 3612 and optionally associated parameters. 3614 This section identifies preferred OIDs and parameters for the RSA, 3615 DSA, and Diffie-Hellman algorithms. Conforming CAs shall use the 3616 identified OIDs when issuing certificates containing public keys for 3617 these algorithms. Conforming applications supporting any of these 3618 algorithms shall, at a minimum, recognize the OID identified in this 3619 section. 3621 7.3.1 RSA Keys 3623 The OID rsaEncryption identifies RSA public keys. 3625 pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 3626 rsadsi(113549) pkcs(1) 1 } 3628 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1} 3630 The rsaEncryption OID is intended to be used in the algorithm field 3631 of a value of type AlgorithmIdentifier. The parameters field shall 3632 have ASN.1 type NULL for this algorithm identifier. 3634 The RSA public key shall be encoded using the ASN.1 type RSAPub- 3635 licKey: 3637 RSAPublicKey ::= SEQUENCE { 3638 modulus INTEGER, -- n 3639 publicExponent INTEGER -- e -- } 3641 where modulus is the modulus n, and publicExponent is the public 3642 exponent e. The DER encoded RSAPublicKey is the value of the BIT 3643 STRING subjectPublicKey. 3645 This OID is used in public key certificates for both RSA signature 3646 keys and RSA encryption keys. The intended application for the key 3647 may be indicated in the key usage field (see sec. 4.2.1.3). The use 3648 of a single key for both signature and encryption purposes is not 3649 recommended, but is not forbidden. 3651 If the keyUsage extension is present in an end entity certificate 3652 which conveys an RSA public key, any combination of the following 3653 values may be present: digitalSignature; nonRepudiation; keyEnci- 3654 pherment; and dataEncipherment. If the keyUsage extension is present 3655 in a CA certificate which conveys an RSA public key, any combination 3656 of the following values may be present: digitalSignature; nonRepudi- 3657 ation; keyEncipherment; dataEncipherment; keyCertSign; and cRLSign. 3658 However, this specification RECOMMENDS that if keyCertSign or cRLSign 3659 is present, both keyEncipherment and dataEncipherment should not be 3660 present. 3662 7.3.2 Diffie-Hellman Key Exchange Key 3664 The Diffie-Hellman OID supported by this profile is defined by ANSI 3665 X9.42 [X9.42]. 3667 dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3668 us(840) ansi-x942(10046) number-type(2) 1 } 3670 The dhpublicnumber OID is intended to be used in the algorithm field 3671 of a value of type AlgorithmIdentifier. The parameters field of that 3672 type, which has the algorithm-specific syntax ANY DEFINED BY algo- 3673 rithm, have the ASN.1 type GroupParameters for this algorithm. 3675 DomainParameters ::= SEQUENCE { 3676 p INTEGER, -- odd prime, p=jq +1 3677 g INTEGER, -- generator, g 3678 q INTEGER, -- factor of p-1 3679 j INTEGER OPTIONAL, -- subgroup factor 3680 validationParms ValidationParms OPTIONAL } 3682 ValidationParms ::= SEQUENCE { 3683 seed BIT STRING, 3684 pgenCounter INTEGER } 3686 The fields of type DomainParameters have the following meanings: 3688 p identifies the prime p defining the Galois field; 3690 g specifies the generator of the multiplicative subgroup of order 3691 g; 3693 q specifies the prime factor of p-1; 3695 j optionally specifies the value that satisfies the equation 3696 p=jq+1 to support the optional verification of group parameters; 3698 seed optionally specifies the bit string parameter used as the 3699 seed for the system parameter generation process; and 3701 pgenCounter optionally specifies the integer value output as part 3702 of the of the system parameter prime generation process. 3704 If either of the parameter generation components (pgencounter or 3705 seed) is provided, the other shall be present as well. 3707 The Diffie-Hellman public key shall be ASN.1 encoded as an INTEGER; 3708 this encoding shall be used as the contents (i.e., the value) of the 3709 subjectPublicKey component (a BIT STRING) of the subjectPublicKeyInfo 3710 data element. 3712 DHPublicKey ::= INTEGER -- public key, y = g^x mod p 3714 If the keyUsage extension is present in a certificate which conveys a 3715 DH public key, the following values may be present: keyAgreement; 3716 encipherOnly; and decipherOnly. At most one of encipherOnly and 3717 decipherOnly shall be asserted in keyUsage extension. 3719 7.3.3 DSA Signature Keys 3721 The Digital Signature Algorithm (DSA) is also known as the Digital 3722 Signature Standard (DSS). The DSA OID supported by this profile is 3724 id-dsa ID ::= { iso(1) member-body(2) us(840) x9-57(10040) 3725 x9cm(4) 1 } 3727 The id-dsa algorithm syntax includes optional parameters. These 3728 parameters are commonly referred to as p, q, and g. When omitted, 3729 the parameters component shall be omitted entirely. That is, the 3730 AlgorithmIdentifier shall be a SEQUENCE of one component - the OBJECT 3731 IDENTIFIER id-dsa. 3733 If the DSA algorithm parameters are present in the subjectPublicKey- 3734 Info AlgorithmIdentifier, the parameters are included using the fol- 3735 lowing ASN.1 structure: 3737 Dss-Parms ::= SEQUENCE { 3738 p INTEGER, 3739 q INTEGER, 3740 g INTEGER } 3742 If the DSA algorithm parameters are absent from the subjectPublicKey- 3743 Info AlgorithmIdentifier and the CA signed the subject certificate 3744 using DSA, then the certificate issuer's DSA parameters apply to the 3745 subject's DSA key. If the DSA algorithm parameters are absent from 3746 the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the 3747 subject certificate using a signature algorithm other than DSA, then 3748 the subject's DSA parameters are distributed by other means. If the 3749 subjectPublicKeyInfo AlgorithmIdentifier field omits the parameters 3750 component and the CA signed the subject with a signature algorithm 3751 other than DSA, then clients shall reject the certificate. 3753 When signing, DSA algorithm generates two values. These values are 3754 commonly referred to as r and s. To easily transfer these two values 3755 as one signature, they are ASN.1 encoded using the following ASN.1 3756 structure: 3758 Dss-Sig-Value ::= SEQUENCE { 3759 r INTEGER, 3760 s INTEGER } 3762 The encoded signature is conveyed as the value of the BIT STRING sig- 3763 nature in a Certificate or CertificateList. 3765 The DSA public key shall be ASN.1 DER encoded as an INTEGER; this 3766 encoding shall be used as the contents (i.e., the value) of the sub- 3767 jectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo 3768 data element. 3770 DSAPublicKey ::= INTEGER -- public key, Y 3772 If the keyUsage extension is present in an end entity certificate 3773 which conveys a DSA public key, any combination of the following 3774 values may be present: digitalSignature; and nonRepudiation. 3776 If the keyUsage extension is present in an CA certificate which con- 3777 veys a DSA public key, any combination of the following values may be 3778 present: digitalSignature; nonRepudiation; keyCertSign; and cRLSign. 3780 8 References 3782 [FIPS 180-1] Federal Information Processing Standards Publication 3783 (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995. 3784 [Supersedes FIPS PUB 180 dated 11 May 1993.] 3786 [FIPS 186] Federal Information Processing Standards Publication 3787 (FIPS PUB) 186, Digital Signature Standard, 18 May 1994. 3789 [RC95] Rogier, N. and Chauvaud, P., "The compression function of 3790 MD2 is not collision free," Presented at Selected Areas in 3791 Cryptography '95, May 1995. 3793 [RFC 791] J. Postel, "Internet Protocol", September 1981. 3795 [RFC 822] D. Crocker, "Standard for the format of ARPA Internet text 3796 messages", August 1982. 3798 [RFC 1034] P.V. Mockapetris, "Domain names - concepts and 3799 facilities", November 1987. 3801 [RFC 1319] Kaliski, B., "The MD2 Message-Digest Algorithm," RFC 1319, 3802 RSA Laboratories, April 1992. 3804 [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321, 3805 MIT and RSA Data Security, April 1992. 3807 [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic 3808 Mail: Part II: Certificate-Based Key Management," RFC 3809 1422, BBN Communications, February 1993. 3811 [RFC 1423] Balenson, D., "Privacy Enhancement for Internet Electronic 3812 Mail: Part III: Algorithms, Modes, and Identifiers," 3813 RFC 1423, Trusted Information Systems, February 1993. 3815 [RFC 1519] V. Fuller, T. Li, J. Yu, and K. Varadhan. "Classless 3816 Inter-Domain Routing (CIDR): an Address Assignment and 3817 Aggregation Strategy", September 1993. 3819 [RFC 1738] Berners-Lee, T., Masinter L., and M. McCahill. 3820 "Uniform Resource Locators (URL)", RFC 1738, December 1994. 3822 [RFC 1778] Howes, T., Kille S., Yeong, W. and C. Robbins. "The 3823 String Representation of Standard Attribute Syntaxes," 3824 RFC 1778, March 1995. 3826 [RFC 1883] S. Deering and R. Hinden. "Internet Protocol, Version 6 3827 (IPv6) Specification", December 1995. 3829 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 3830 Requirement Levels", March 1997. 3832 [RFC 2247] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. 3833 Sataluri. "Using Domains in LDAP/X.500 Distinguished Names", 3834 RFC 2247, January 1998. 3836 [RFC 2277] H. Alvestrand, "IETF Policy on Character Sets and 3837 Languages", January 1998. 3839 [RFC 2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646", 3840 January 1998. 3842 [RFC 2313] B. Kaliski, "PKCS #1: RSA Encryption Version 1.5", 3843 March 1998. 3845 [SDN.701] SDN.701, "Message Security Protocol 4.0", Revision A 3846 1997-02-06. 3848 [X.208] CCITT Recommendation X.208: Specification of Abstract 3849 Syntax Notation One (ASN.1), 1988. 3851 [X.501] ITU-T Recommendation X.501: Information 3852 Technology - Open Systems Interconnection - The 3853 Directory: Models, 1993. 3855 [X.509] ITU-T Recommendation X.509 (1997 E): Information 3856 Technology - Open Systems Interconnection - The 3857 Directory: Authentication Framework, June 1997. 3859 [X.520] ITU-T Recommendation X.520: Information 3860 Technology - Open Systems Interconnection - The 3861 Directory: Selected Attribute Types, 1993. 3863 [X9.42] ANSI X9.42-199x, Public Key Cryptography for The Financial 3864 Services Industry: Agreement of Symmetric Algorithm Keys 3865 Using Diffie-Hellman (Working Draft), December 1997. 3867 [X9.55] ANSI X9.55-1995, Public Key Cryptography For The Financial 3868 Services Industry: Extensions To Public Key Certificates 3869 And Certificate Revocation Lists, 8 December, 1995. 3871 [X9.57] ANSI X9.57-199x, Public Key Cryptography For The Financial 3872 Services Industry: Certificate Management (Working Draft), 3873 21 June, 1996. 3875 9 Intellectual Property Rights 3877 The IETF has been notified of intellectual property rights claimed in 3878 regard to some or all of the specification contained in this docu- 3879 ment. For more information consult the online list of claimed 3880 rights. 3882 The IETF takes no position regarding the validity or scope of any 3883 intellectual property or other rights that might be claimed to per- 3884 tain to the implementation or use of the technology described in this 3885 document or the extent to which any license under such rights might 3886 or might not be available; neither does it represent that it has made 3887 any effort to identify any such rights. Information on the IETF's 3888 procedures with respect to rights in standards-track and standards- 3889 related documentation can be found in BCP-11. Copies of claims of 3890 rights made available for publication and any assurances of licenses 3891 to be made available, or the result of an attempt made to obtain a 3892 general license or permission for the use of such proprietary rights 3893 by implementors or users of this specification can be obtained from 3894 the IETF Secretariat. 3896 10 Security Considerations 3898 The majority of this specification is devoted to the format and con- 3899 tent of certificates and CRLs. Since certificates and CRLs are digi- 3900 tally signed, no additional integrity service is necessary. Neither 3901 certificates nor CRLs need be kept secret, and unrestricted and 3902 anonymous access to certificates and CRLs has no security implica- 3903 tions. 3905 However, security factors outside the scope of this specification 3906 will affect the assurance provided to certificate users. This sec- 3907 tion highlights critical issues that should be considered by imple- 3908 mentors, administrators, and users. 3910 The procedures performed by CAs and RAs to validate the binding of 3911 the subject's identity of their public key greatly affect the 3912 assurance that should be placed in the certificate. Relying parties 3913 may wish to review the CA's certificate practice statement. This may 3914 be particularly important when issuing certificates to other CAs. 3916 The use of a single key pair for both signature and other purposes is 3917 strongly discouraged. Use of separate key pairs for signature and key 3918 management provides several benefits to the users. The ramifications 3919 associated with loss or disclosure of a signature key are different 3920 from loss or disclosure of a key management key. Using separate key 3921 pairs permits a balanced and flexible response. Similarly, different 3922 validity periods or key lengths for each key pair may be appropriate 3923 in some application environments. Unfortunately, some legacy applica- 3924 tions (e.g., SSL) use a single key pair for signature and key manage- 3925 ment. 3927 The protection afforded private keys is a critical factor in main- 3928 taining security. On a small scale, failure of users to protect 3929 their private keys will permit an attacker to masquerade as them, or 3930 decrypt their personal information. On a larger scale, compromise of 3931 a CA's private signing key may have a catastrophic effect. If an 3932 attacker obtains the private key unnoticed, the attacker may issue 3933 bogus certificates and CRLs. Existence of bogus certificates and 3934 CRLs will undermine confidence in the system. If the compromise is 3935 detected, all certificates issued to the CA shall be revoked, 3936 preventing services between its users and users of other CAs. 3937 Rebuilding after such a compromise will be problematic, so CAs are 3938 advised to implement a combination of strong technical measures 3939 (e.g., tamper-resistant cryptographic modules) and appropriate 3940 management procedures (e.g., separation of duties) to avoid such an 3941 incident. 3943 Loss of a CA's private signing key may also be problematic. The CA 3944 would not be able to produce CRLs or perform normal key rollover. 3945 CAs are advised to maintain secure backup for signing keys. The 3946 security of the key backup procedures is a critical factor in avoid- 3947 ing key compromise. 3949 The availability and freshness of revocation information will affect 3950 the degree of assurance that should be placed in a certificate. 3951 While certificates expire naturally, events may occur during its 3952 natural lifetime which negate the binding between the subject and 3953 public key. If revocation information is untimely or unavailable, 3954 the assurance associated with the binding is clearly reduced. Simi- 3955 larly, implementations of the Path Validation mechanism described in 3956 section 6 that omit revocation checking provide less assurance than 3957 those that support it. 3959 The path validation algorithm depends on the certain knowledge of the 3960 public keys (and other information) about one or more trusted CAs. 3961 The decision to trust a CA is an important decision as it ultimately 3962 determines the trust afforded a certificate. The authenticated dis- 3963 tribution of trusted CA public keys (usually in the form of a "self- 3964 signed" certificate) is a security critical out of band process that 3965 is beyond the scope of this specification. 3967 In addition, where a key compromise or CA failure occurs for a 3968 trusted CA, the user will need to modify the information provided to 3969 the path validation routine. Selection of too many trusted CAs will 3970 make the trusted CA information difficult to maintain. On the other 3971 hand, selection of only one trusted CA may limit users to a closed 3972 community of users until a global PKI emerges. 3974 The quality of implementations that process certificates may also 3975 affect the degree of assurance provided. The path validation algo- 3976 rithm described in section 6 relies upon the integrity of the trusted 3977 CA information, and especially the integrity of the public keys 3978 associated with the trusted CAs. By substituting public keys for 3979 which an attacker has the private key, an attacker could trick the 3980 user into accepting false certificates. 3982 The binding between a key and certificate subject cannot be stronger 3983 than the cryptographic module implementation and algorithms used to 3984 generate the signature. Short key lengths or weak hash algorithms 3985 will limit the utility of a certificate. CAs are encouraged to note 3986 advances in cryptology so they can employ strong cryptographic tech- 3987 niques. In addition, CAs should decline to issue certificates to CAs 3988 or end entities that generate weak signatures. 3990 Inconsistent application of name comparison rules may result in 3991 acceptance of invalid X.509 certification paths, or rejection of 3992 valid ones. The X.500 series of specifications defines rules for 3993 comparing distinguished names require comparison of strings without 3994 regard to case, character set, multi-character white space substring, 3995 or leading and trailing white space. This specification relaxes 3996 these requirements, requiring support for binary comparison at a 3997 minimum. 3999 CAs shall encode the distinguished name in the subject field of a CA 4000 certificate identically to the distinguished name in the issuer field 4001 in certificates issued by the latter CA. If CAs use different encod- 4002 ings, implementations of this specification may fail to recognize 4003 name chains for paths that include this certificate. As a conse- 4004 quence, valid paths could be rejected. 4006 In addition, name constraints for distinguished names shall be stated 4007 identically to the encoding used in the subject field or subjectAlt- 4008 Name extension. If not, (1) name constraints stated as excludedSub- 4009 Trees will not match and invalid paths will be accepted and (2) name 4010 constraints expressed as permittedSubtrees will not match and valid 4011 paths will be rejected. To avoid acceptance of invalid paths, CAs 4012 should state name constraints for distinguished names as permit- 4013 tedSubtrees where ever possible. 4015 Appendix A. Psuedo-ASN.1 Structures and OIDs 4017 This section describes data objects used by conforming PKI components 4018 in an "ASN.1-like" syntax. This syntax is a hybrid of the 1988 and 4019 1993 ASN.1 syntaxes. The 1988 ASN.1 syntax is augmented with 1993 4020 UNIVERSAL Types UniversalString, BMPString and UTF8String. 4022 The ASN.1 syntax does not permit the inclusion of type statements in 4023 the ASN.1 module, and the 1993 ASN.1 standard does not permit use of 4024 the new UNIVERSAL types in modules using the 1988 syntax. As a 4025 result, this module does not conform to either version of the ASN.1 4026 standard. 4028 This appendix may be converted into 1988 ASN.1 by replacing the 4029 defintions for the UNIVERSAL Types with the 1988 catch-all "ANY". 4031 A.1 Explicitly Tagged Module, 1988 Syntax 4033 PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) 4034 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)} 4036 DEFINITIONS EXPLICIT TAGS ::= 4038 BEGIN 4040 -- EXPORTS ALL -- 4042 -- IMPORTS NONE -- 4044 -- UNIVERSAL Types defined in '93 and '98 ASN.1 4045 -- but required by this specification 4047 UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING 4048 -- UniversalString is defined in ASN.1:1993 4050 BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING 4051 -- BMPString is the subtype of UniversalString and models 4052 -- the Basic Multilingual Plane of ISO/IEC/ITU 10646-1 4054 UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 4055 -- The content of this type conforms to RFC 2279. 4057 -- 4058 -- PKIX specific OIDs 4060 id-pkix OBJECT IDENTIFIER ::= 4061 { iso(1) identified-organization(3) dod(6) internet(1) 4062 security(5) mechanisms(5) pkix(7) } 4063 -- PKIX arcs 4065 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 4066 -- arc for private certificate extensions 4067 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 4068 -- arc for policy qualifier types 4069 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 4070 -- arc for extended key purpose OIDS 4071 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 4072 -- arc for access descriptors 4074 -- policyQualifierIds for Internet policy qualifiers 4076 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 4077 -- OID for CPS qualifier 4078 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 4079 -- OID for user notice qualifier 4081 -- access descriptor definitions 4083 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 4084 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 4086 -- attribute data types -- 4088 Attribute ::= SEQUENCE { 4089 type AttributeType, 4090 values SET OF AttributeValue 4091 -- at least one value is required -- } 4093 AttributeType ::= OBJECT IDENTIFIER 4095 AttributeValue ::= ANY 4097 AttributeTypeAndValue ::= SEQUENCE { 4098 type AttributeType, 4099 value AttributeValue } 4101 -- suggested naming attributes: Definition of the following 4102 -- information object set may be augmented to meet local 4103 -- requirements. Note that deleting members of the set may 4104 -- prevent interoperability with conforming implementations. 4105 -- presented in pairs: the AttributeType followed by the 4106 -- type definition for the corresponding AttributeValue 4108 --Arc for standard naming attributes 4109 id-at OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 4} 4110 -- Attributes of type NameDirectoryString 4111 id-at-name AttributeType ::= {id-at 41} 4112 id-at-surname AttributeType ::= {id-at 4} 4113 id-at-givenName AttributeType ::= {id-at 42} 4114 id-at-initials AttributeType ::= {id-at 43} 4115 id-at-generationQualifier AttributeType ::= {id-at 44} 4117 X520name ::= CHOICE { 4118 teletexString TeletexString (SIZE (1..ub-name)), 4119 printableString PrintableString (SIZE (1..ub-name)), 4120 universalString UniversalString (SIZE (1..ub-name)), 4121 utf8String UTF8String (SIZE (1..ub-name)), 4122 bmpString BMPString (SIZE(1..ub-name)) } 4124 -- 4126 id-at-commonName AttributeType ::= {id-at 3} 4128 X520CommonName ::= CHOICE { 4129 teletexString TeletexString (SIZE (1..ub-common-name)), 4130 printableString PrintableString (SIZE (1..ub-common-name)), 4131 universalString UniversalString (SIZE (1..ub-common-name)), 4132 utf8String UTF8String (SIZE (1..ub-common-name)), 4133 bmpString BMPString (SIZE(1..ub-common-name)) } 4135 -- 4137 id-at-localityName AttributeType ::= {id-at 7} 4139 X520LocalityName ::= CHOICE { 4140 teletexString TeletexString (SIZE (1..ub-locality-name)), 4141 printableString PrintableString (SIZE (1..ub-locality-name)), 4142 universalString UniversalString (SIZE (1..ub-locality-name)), 4143 utf8String UTF8String (SIZE (1..ub-locality-name)), 4144 bmpString BMPString (SIZE(1..ub-locality-name)) } 4146 -- 4148 id-at-stateOrProvinceName AttributeType ::= {id-at 8} 4150 X520StateOrProvinceName ::= CHOICE { 4151 teletexString TeletexString (SIZE (1..ub-state-name)), 4152 printableString PrintableString (SIZE (1..ub-state-name)), 4153 universalString UniversalString (SIZE (1..ub-state-name)), 4154 utf8String UTF8String (SIZE (1..ub-state-name)), 4155 bmpString BMPString (SIZE(1..ub-state-name)) } 4157 -- 4159 id-at-organizationName AttributeType ::= {id-at 10} 4161 X520OrganizationName ::= CHOICE { 4162 teletexString TeletexString (SIZE (1..ub-organization-name)), 4163 printableString PrintableString (SIZE (1..ub-organization-name)), 4164 universalString UniversalString (SIZE (1..ub-organization-name)), 4165 utf8String UTF8String (SIZE (1..ub-organization-name)), 4166 bmpString BMPString (SIZE(1..ub-organization-name)) } 4168 -- 4170 id-at-organizationalUnitName AttributeType ::= {id-at 11} 4172 X520OrganizationalUnitName ::= CHOICE { 4173 teletexString TeletexString (SIZE (1..ub-organizational-unit-name)), 4174 printableString PrintableString 4175 (SIZE (1..ub-organizational-unit-name)), 4176 universalString UniversalString 4177 (SIZE (1..ub-organizational-unit-name)), 4178 utf8String UTF8String (SIZE (1..ub-organizational-unit-name)), 4179 bmpString BMPString (SIZE(1..ub-organizational-unit-name)) } 4181 -- 4183 id-at-title AttributeType ::= {id-at 12} 4185 X520Title ::= CHOICE { 4186 teletexString TeletexString (SIZE (1..ub-title)), 4187 printableString PrintableString (SIZE (1..ub-title)), 4188 universalString UniversalString (SIZE (1..ub-title)), 4189 utf8String UTF8String (SIZE (1..ub-title)), 4190 bmpString BMPString (SIZE(1..ub-title)) } 4192 -- 4194 id-at-dnQualifier AttributeType ::= {id-at 46} 4195 X520dnQualifier ::= PrintableString 4197 id-at-countryName AttributeType ::= {id-at 6} 4198 X520countryName ::= PrintableString (SIZE (2)) -- IS 3166 codes 4200 id-at-serialNumber AttributeType ::= { id-at 5 } 4201 X520SerialNumber PrintableString (SIZE (1..ub-serial-number)) 4203 -- domaincomponent and identifier from RFC 2247 4205 id-domainComponent OBJECT IDENTIFIER := 4206 { 0 9 2342 19200300 100 1 25 } 4208 id-domainComponent AttributeType ::= id-domainComponent 4209 domainComponent ::= IA5String 4211 -- Legacy attributes 4213 pkcs-9 OBJECT IDENTIFIER ::= 4214 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 } 4216 emailAddress AttributeType ::= { pkcs-9 1 } 4218 Pkcs9email ::= IA5String (SIZE (1..ub-emailaddress-length)) 4220 -- naming data types -- 4222 Name ::= CHOICE { -- only one possibility for now -- 4223 rdnSequence RDNSequence } 4225 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 4227 DistinguishedName ::= RDNSequence 4229 RelativeDistinguishedName ::= 4230 SET SIZE (1 .. MAX) OF AttributeTypeAndValue 4232 -- Directory string type -- 4234 DirectoryString ::= CHOICE { 4235 teletexString TeletexString (SIZE (1..MAX)), 4236 printableString PrintableString (SIZE (1..MAX)), 4237 universalString UniversalString (SIZE (1..MAX)), 4238 utf8String UTF8String (SIZE (1..MAX)), 4239 bmpString BMPString (SIZE(1..MAX)) } 4241 -- certificate and CRL specific structures begin here 4243 Certificate ::= SEQUENCE { 4244 tbsCertificate TBSCertificate, 4245 signatureAlgorithm AlgorithmIdentifier, 4246 signature BIT STRING } 4248 TBSCertificate ::= SEQUENCE { 4249 version [0] Version DEFAULT v1, 4250 serialNumber CertificateSerialNumber, 4251 signature AlgorithmIdentifier, 4252 issuer Name, 4253 validity Validity, 4254 subject Name, 4255 subjectPublicKeyInfo SubjectPublicKeyInfo, 4256 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 4257 -- If present, version shall be v2 or v3 4258 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 4259 -- If present, version shall be v2 or v3 4260 extensions [3] Extensions OPTIONAL 4261 -- If present, version shall be v3 -- } 4263 Version ::= INTEGER { v1(0), v2(1), v3(2) } 4265 CertificateSerialNumber ::= INTEGER 4267 Validity ::= SEQUENCE { 4268 notBefore Time, 4269 notAfter Time } 4271 Time ::= CHOICE { 4272 utcTime UTCTime, 4273 generalTime GeneralizedTime } 4275 UniqueIdentifier ::= BIT STRING 4277 SubjectPublicKeyInfo ::= SEQUENCE { 4278 algorithm AlgorithmIdentifier, 4279 subjectPublicKey BIT STRING } 4281 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 4283 Extension ::= SEQUENCE { 4284 extnID OBJECT IDENTIFIER, 4285 critical BOOLEAN DEFAULT FALSE, 4286 extnValue OCTET STRING } 4288 -- CRL structures 4290 CertificateList ::= SEQUENCE { 4291 tbsCertList TBSCertList, 4292 signatureAlgorithm AlgorithmIdentifier, 4293 signature BIT STRING } 4295 TBSCertList ::= SEQUENCE { 4296 version Version OPTIONAL, 4297 -- if present, shall be v2 4298 signature AlgorithmIdentifier, 4299 issuer Name, 4300 thisUpdate Time, 4301 nextUpdate Time OPTIONAL, 4302 revokedCertificates SEQUENCE OF SEQUENCE { 4303 userCertificate CertificateSerialNumber, 4304 revocationDate Time, 4305 crlEntryExtensions Extensions OPTIONAL 4306 -- if present, shall be v2 4307 } OPTIONAL, 4308 crlExtensions [0] Extensions OPTIONAL 4309 -- if present, shall be v2 -- } 4311 -- Version, Time, CertificateSerialNumber, and Extensions were 4312 -- defined earlier for use in the certificate structure 4314 AlgorithmIdentifier ::= SEQUENCE { 4315 algorithm OBJECT IDENTIFIER, 4316 parameters ANY DEFINED BY algorithm OPTIONAL } 4317 -- contains a value of the type 4318 -- registered for use with the 4319 -- algorithm object identifier value 4321 -- Algorithm OIDs and parameter structures 4323 pkcs-1 OBJECT IDENTIFIER ::= { 4324 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 } 4326 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } 4328 md2WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 2 } 4330 md5WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 4 } 4332 sha1WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 5 } 4334 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { 4335 iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 3 } 4337 Dss-Sig-Value ::= SEQUENCE { 4338 r INTEGER, 4339 s INTEGER } 4341 dhpublicnumber OBJECT IDENTIFIER ::= { 4342 iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 } 4344 DomainParameters ::= SEQUENCE { 4345 p INTEGER, -- odd prime, p=jq +1 4346 g INTEGER, -- generator, g 4347 q INTEGER, -- factor of p-1 4348 j INTEGER OPTIONAL, -- subgroup factor, j>= 2 4349 validationParms ValidationParms OPTIONAL } 4351 ValidationParms ::= SEQUENCE { 4352 seed BIT STRING, 4353 pgenCounter INTEGER } 4355 id-dsa OBJECT IDENTIFIER ::= { 4356 iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 } 4358 Dss-Parms ::= SEQUENCE { 4359 p INTEGER, 4360 q INTEGER, 4361 g INTEGER } 4363 -- x400 address syntax starts here 4364 -- OR Names 4366 ORAddress ::= SEQUENCE { 4367 built-in-standard-attributes BuiltInStandardAttributes, 4368 built-in-domain-defined-attributes 4369 BuiltInDomainDefinedAttributes OPTIONAL, 4370 -- see also teletex-domain-defined-attributes 4371 extension-attributes ExtensionAttributes OPTIONAL } 4372 -- The OR-address is semantically absent from the OR-name if the 4373 -- built-in-standard-attribute sequence is empty and the 4374 -- built-in-domain-defined-attributes and extension-attributes are 4375 -- both omitted. 4377 -- Built-in Standard Attributes 4379 BuiltInStandardAttributes ::= SEQUENCE { 4380 country-name CountryName OPTIONAL, 4381 administration-domain-name AdministrationDomainName OPTIONAL, 4382 network-address [0] NetworkAddress OPTIONAL, 4383 -- see also extended-network-address 4384 terminal-identifier [1] TerminalIdentifier OPTIONAL, 4385 private-domain-name [2] PrivateDomainName OPTIONAL, 4386 organization-name [3] OrganizationName OPTIONAL, 4387 -- see also teletex-organization-name 4388 numeric-user-identifier [4] NumericUserIdentifier OPTIONAL, 4389 personal-name [5] PersonalName OPTIONAL, 4390 -- see also teletex-personal-name 4391 organizational-unit-names [6] OrganizationalUnitNames OPTIONAL 4392 -- see also teletex-organizational-unit-names -- } 4394 CountryName ::= [APPLICATION 1] CHOICE { 4395 x121-dcc-code NumericString 4396 (SIZE (ub-country-name-numeric-length)), 4398 iso-3166-alpha2-code PrintableString 4399 (SIZE (ub-country-name-alpha-length)) } 4401 AdministrationDomainName ::= [APPLICATION 2] CHOICE { 4402 numeric NumericString (SIZE (0..ub-domain-name-length)), 4403 printable PrintableString (SIZE (0..ub-domain-name-length)) } 4405 NetworkAddress ::= X121Address -- see also extended-network-address 4407 X121Address ::= NumericString (SIZE (1..ub-x121-address-length)) 4409 TerminalIdentifier ::= PrintableString (SIZE (1..ub-terminal-id-length)) 4411 PrivateDomainName ::= CHOICE { 4412 numeric NumericString (SIZE (1..ub-domain-name-length)), 4413 printable PrintableString (SIZE (1..ub-domain-name-length)) } 4415 OrganizationName ::= PrintableString 4416 (SIZE (1..ub-organization-name-length)) 4417 -- see also teletex-organization-name 4419 NumericUserIdentifier ::= NumericString 4420 (SIZE (1..ub-numeric-user-id-length)) 4422 PersonalName ::= SET { 4423 surname [0] PrintableString (SIZE (1..ub-surname-length)), 4424 given-name [1] PrintableString 4425 (SIZE (1..ub-given-name-length)) OPTIONAL, 4426 initials [2] PrintableString (SIZE (1..ub-initials-length)) OPTIONAL, 4427 generation-qualifier [3] PrintableString 4428 (SIZE (1..ub-generation-qualifier-length)) OPTIONAL } 4429 -- see also teletex-personal-name 4431 OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units) 4432 OF OrganizationalUnitName 4433 -- see also teletex-organizational-unit-names 4435 OrganizationalUnitName ::= PrintableString (SIZE 4436 (1..ub-organizational-unit-name-length)) 4438 -- Built-in Domain-defined Attributes 4440 BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE 4441 (1..ub-domain-defined-attributes) OF 4442 BuiltInDomainDefinedAttribute 4444 BuiltInDomainDefinedAttribute ::= SEQUENCE { 4445 type PrintableString (SIZE 4446 (1..ub-domain-defined-attribute-type-length)), 4447 value PrintableString (SIZE 4448 (1..ub-domain-defined-attribute-value-length))} 4450 -- Extension Attributes 4452 ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF 4453 ExtensionAttribute 4455 ExtensionAttribute ::= SEQUENCE { 4456 extension-attribute-type [0] INTEGER (0..ub-extension-attributes), 4457 extension-attribute-value [1] 4458 ANY DEFINED BY extension-attribute-type } 4460 -- Extension types and attribute values 4461 -- 4463 common-name INTEGER ::= 1 4465 CommonName ::= PrintableString (SIZE (1..ub-common-name-length)) 4467 teletex-common-name INTEGER ::= 2 4469 TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length)) 4471 teletex-organization-name INTEGER ::= 3 4473 TeletexOrganizationName ::= 4474 TeletexString (SIZE (1..ub-organization-name-length)) 4476 teletex-personal-name INTEGER ::= 4 4478 TeletexPersonalName ::= SET { 4479 surname [0] TeletexString (SIZE (1..ub-surname-length)), 4480 given-name [1] TeletexString 4481 (SIZE (1..ub-given-name-length)) OPTIONAL, 4482 initials [2] TeletexString (SIZE (1..ub-initials-length)) OPTIONAL, 4483 generation-qualifier [3] TeletexString (SIZE 4484 (1..ub-generation-qualifier-length)) OPTIONAL } 4486 teletex-organizational-unit-names INTEGER ::= 5 4488 TeletexOrganizationalUnitNames ::= SEQUENCE SIZE 4489 (1..ub-organizational-units) OF TeletexOrganizationalUnitName 4491 TeletexOrganizationalUnitName ::= TeletexString 4492 (SIZE (1..ub-organizational-unit-name-length)) 4494 pds-name INTEGER ::= 7 4496 PDSName ::= PrintableString (SIZE (1..ub-pds-name-length)) 4498 physical-delivery-country-name INTEGER ::= 8 4500 PhysicalDeliveryCountryName ::= CHOICE { 4501 x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)), 4502 iso-3166-alpha2-code PrintableString 4503 (SIZE (ub-country-name-alpha-length)) } 4505 postal-code INTEGER ::= 9 4507 PostalCode ::= CHOICE { 4508 numeric-code NumericString (SIZE (1..ub-postal-code-length)), 4509 printable-code PrintableString (SIZE (1..ub-postal-code-length)) } 4511 physical-delivery-office-name INTEGER ::= 10 4513 PhysicalDeliveryOfficeName ::= PDSParameter 4515 physical-delivery-office-number INTEGER ::= 11 4517 PhysicalDeliveryOfficeNumber ::= PDSParameter 4519 extension-OR-address-components INTEGER ::= 12 4521 ExtensionORAddressComponents ::= PDSParameter 4523 physical-delivery-personal-name INTEGER ::= 13 4525 PhysicalDeliveryPersonalName ::= PDSParameter 4527 physical-delivery-organization-name INTEGER ::= 14 4529 PhysicalDeliveryOrganizationName ::= PDSParameter 4531 extension-physical-delivery-address-components INTEGER ::= 15 4533 ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter 4535 unformatted-postal-address INTEGER ::= 16 4537 UnformattedPostalAddress ::= SET { 4538 printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) OF 4539 PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL, 4540 teletex-string TeletexString 4541 (SIZE (1..ub-unformatted-address-length)) OPTIONAL } 4543 street-address INTEGER ::= 17 4545 StreetAddress ::= PDSParameter 4547 post-office-box-address INTEGER ::= 18 4549 PostOfficeBoxAddress ::= PDSParameter 4551 poste-restante-address INTEGER ::= 19 4553 PosteRestanteAddress ::= PDSParameter 4555 unique-postal-name INTEGER ::= 20 4557 UniquePostalName ::= PDSParameter 4559 local-postal-attributes INTEGER ::= 21 4561 LocalPostalAttributes ::= PDSParameter 4563 PDSParameter ::= SET { 4564 printable-string PrintableString 4565 (SIZE(1..ub-pds-parameter-length)) OPTIONAL, 4566 teletex-string TeletexString 4567 (SIZE(1..ub-pds-parameter-length)) OPTIONAL } 4569 extended-network-address INTEGER ::= 22 4571 ExtendedNetworkAddress ::= CHOICE { 4572 e163-4-address SEQUENCE { 4573 number [0] NumericString (SIZE (1..ub-e163-4-number-length)), 4574 sub-address [1] NumericString 4575 (SIZE (1..ub-e163-4-sub-address-length)) OPTIONAL }, 4576 psap-address [0] PresentationAddress } 4578 PresentationAddress ::= SEQUENCE { 4579 pSelector [0] EXPLICIT OCTET STRING OPTIONAL, 4580 sSelector [1] EXPLICIT OCTET STRING OPTIONAL, 4581 tSelector [2] EXPLICIT OCTET STRING OPTIONAL, 4582 nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING } 4584 terminal-type INTEGER ::= 23 4586 TerminalType ::= INTEGER { 4587 telex (3), 4588 teletex (4), 4589 g3-facsimile (5), 4590 g4-facsimile (6), 4591 ia5-terminal (7), 4592 videotex (8) } (0..ub-integer-options) 4594 -- Extension Domain-defined Attributes 4596 teletex-domain-defined-attributes INTEGER ::= 6 4598 TeletexDomainDefinedAttributes ::= SEQUENCE SIZE 4599 (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute 4601 TeletexDomainDefinedAttribute ::= SEQUENCE { 4602 type TeletexString 4603 (SIZE (1..ub-domain-defined-attribute-type-length)), 4604 value TeletexString 4605 (SIZE (1..ub-domain-defined-attribute-value-length)) } 4607 -- specifications of Upper Bounds shall be regarded as mandatory 4608 -- from Annex B of ITU-T X.411 Reference Definition of MTS Parameter 4609 -- Upper Bounds 4611 -- Upper Bounds 4612 ub-name INTEGER ::= 32768 4613 ub-common-name INTEGER ::= 64 4614 ub-locality-name INTEGER ::= 128 4615 ub-state-name INTEGER ::= 128 4616 ub-organization-name INTEGER ::= 64 4617 ub-organizational-unit-name INTEGER ::= 64 4618 ub-title INTEGER ::= 64 4619 ub-serialNumber INTEGER ::= 64 4620 ub-match INTEGER ::= 128 4622 ub-emailaddress-length INTEGER ::= 128 4624 ub-common-name-length INTEGER ::= 64 4625 ub-country-name-alpha-length INTEGER ::= 2 4626 ub-country-name-numeric-length INTEGER ::= 3 4627 ub-domain-defined-attributes INTEGER ::= 4 4628 ub-domain-defined-attribute-type-length INTEGER ::= 8 4629 ub-domain-defined-attribute-value-length INTEGER ::= 128 4630 ub-domain-name-length INTEGER ::= 16 4631 ub-extension-attributes INTEGER ::= 256 4632 ub-e163-4-number-length INTEGER ::= 15 4633 ub-e163-4-sub-address-length INTEGER ::= 40 4634 ub-generation-qualifier-length INTEGER ::= 3 4635 ub-given-name-length INTEGER ::= 16 4636 ub-initials-length INTEGER ::= 5 4637 ub-integer-options INTEGER ::= 256 4638 ub-numeric-user-id-length INTEGER ::= 32 4639 ub-organization-name-length INTEGER ::= 64 4640 ub-organizational-unit-name-length INTEGER ::= 32 4641 ub-organizational-units INTEGER ::= 4 4642 ub-pds-name-length INTEGER ::= 16 4643 ub-pds-parameter-length INTEGER ::= 30 4644 ub-pds-physical-address-lines INTEGER ::= 6 4645 ub-postal-code-length INTEGER ::= 16 4646 ub-surname-length INTEGER ::= 40 4647 ub-terminal-id-length INTEGER ::= 24 4648 ub-unformatted-address-length INTEGER ::= 180 4649 ub-x121-address-length INTEGER ::= 16 4651 -- Note - upper bounds on string types, such as TeletexString, are 4652 -- measured in characters. Excepting PrintableString or IA5String, a 4653 -- significantly greater number of octets will be required to hold 4654 -- such a value. As a minimum, 16 octets, or twice the specified upper 4655 -- bound, whichever is the larger, should be allowed for TeletexString. 4656 -- For UTF8String or UniversalString at least four times the upper 4657 -- bound should be allowed. 4659 END 4660 A.2 Implicitly Tagged Module, 1988 Syntax 4662 PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) 4663 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)} 4665 DEFINITIONS IMPLICIT TAGS ::= 4667 BEGIN 4669 -- EXPORTS ALL -- 4671 IMPORTS 4672 id-pkix, id-pe, id-qt, id-kp, id-qt-unotice, id-qt-cps, 4673 id-ad, id-ad-ocsp, id-ad-caIssuers, 4674 -- delete following line if "new" types are supported -- 4675 BMPString, UniversalString, UTF8String, -- end "new" types 4676 ORAddress, Name, RelativeDistinguishedName, 4677 CertificateSerialNumber, 4678 CertificateList, AlgorithmIdentifier, ub-name, 4679 Attribute, DirectoryString 4680 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 4681 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 4682 id-mod(0) id-pkix1-explicit(1)}; 4684 -- ISO arc for standard certificate and CRL extensions 4686 id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 4688 -- authority key identifier OID and syntax 4690 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 4692 AuthorityKeyIdentifier ::= SEQUENCE { 4693 keyIdentifier [0] KeyIdentifier OPTIONAL, 4694 authorityCertIssuer [1] GeneralNames OPTIONAL, 4695 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 4696 -- authorityCertIssuer and authorityCertSerialNumber shall both 4697 -- be present or both be absent 4699 KeyIdentifier ::= OCTET STRING 4701 -- subject key identifier OID and syntax 4703 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 4705 SubjectKeyIdentifier ::= KeyIdentifier 4706 -- key usage extension OID and syntax 4708 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 4710 KeyUsage ::= BIT STRING { 4711 digitalSignature (0), 4712 nonRepudiation (1), 4713 keyEncipherment (2), 4714 dataEncipherment (3), 4715 keyAgreement (4), 4716 keyCertSign (5), 4717 cRLSign (6), 4718 encipherOnly (7), 4719 decipherOnly (8) } 4721 -- private key usage period extension OID and syntax 4723 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 4725 PrivateKeyUsagePeriod ::= SEQUENCE { 4726 notBefore [0] GeneralizedTime OPTIONAL, 4727 notAfter [1] GeneralizedTime OPTIONAL } 4728 -- either notBefore or notAfter shall be present 4730 -- certificate policies extension OID and syntax 4732 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 4734 anyPolicy OBJECT IDENTIFIER ::= {id-ce-certificate-policies 0} 4736 CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 4738 PolicyInformation ::= SEQUENCE { 4739 policyIdentifier CertPolicyId, 4740 policyQualifiers SEQUENCE SIZE (1..MAX) OF 4741 PolicyQualifierInfo OPTIONAL } 4743 CertPolicyId ::= OBJECT IDENTIFIER 4745 PolicyQualifierInfo ::= SEQUENCE { 4746 policyQualifierId PolicyQualifierId, 4747 qualifier ANY DEFINED BY policyQualifierId } 4749 -- Implementations that recognize additional policy qualifiers shall 4750 -- augment the following definition for PolicyQualifierId 4752 PolicyQualifierId ::= 4753 OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) 4755 -- CPS pointer qualifier 4757 CPSuri ::= IA5String 4759 -- user notice qualifier 4761 UserNotice ::= SEQUENCE { 4762 noticeRef NoticeReference OPTIONAL, 4763 explicitText DisplayText OPTIONAL} 4765 NoticeReference ::= SEQUENCE { 4766 organization DisplayText, 4767 noticeNumbers SEQUENCE OF INTEGER } 4769 DisplayText ::= CHOICE { 4770 ia5String IA5String (SIZE (1..200)), 4771 visibleString VisibleString (SIZE (1..200)), 4772 bmpString BMPString (SIZE (1..200)), 4773 utf8String UTF8String (SIZE (1..200)) } 4775 -- policy mapping extension OID and syntax 4777 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 4779 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 4780 issuerDomainPolicy CertPolicyId, 4781 subjectDomainPolicy CertPolicyId } 4783 -- subject alternative name extension OID and syntax 4785 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 4787 SubjectAltName ::= GeneralNames 4789 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 4791 GeneralName ::= CHOICE { 4792 otherName [0] AnotherName, 4793 rfc822Name [1] IA5String, 4794 dNSName [2] IA5String, 4795 x400Address [3] ORAddress, 4796 directoryName [4] Name, 4797 ediPartyName [5] EDIPartyName, 4798 uniformResourceIdentifier [6] IA5String, 4799 iPAddress [7] OCTET STRING, 4800 registeredID [8] OBJECT IDENTIFIER } 4802 -- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as 4803 -- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax 4805 AnotherName ::= SEQUENCE { 4806 type-id OBJECT IDENTIFIER, 4807 value [0] EXPLICIT ANY DEFINED BY type-id } 4809 EDIPartyName ::= SEQUENCE { 4810 nameAssigner [0] DirectoryString OPTIONAL, 4811 partyName [1] DirectoryString } 4813 -- issuer alternative name extension OID and syntax 4815 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 4817 IssuerAltName ::= GeneralNames 4819 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 4821 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 4823 -- basic constraints extension OID and syntax 4825 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 4827 BasicConstraints ::= SEQUENCE { 4828 cA BOOLEAN DEFAULT FALSE, 4829 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 4831 -- name constraints extension OID and syntax 4833 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 4835 NameConstraints ::= SEQUENCE { 4836 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 4837 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 4839 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 4841 GeneralSubtree ::= SEQUENCE { 4842 base GeneralName, 4843 minimum [0] BaseDistance DEFAULT 0, 4844 maximum [1] BaseDistance OPTIONAL } 4846 BaseDistance ::= INTEGER (0..MAX) 4848 -- policy constraints extension OID and syntax 4850 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } 4851 PolicyConstraints ::= SEQUENCE { 4852 requireExplicitPolicy [0] SkipCerts OPTIONAL, 4853 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 4855 SkipCerts ::= INTEGER (0..MAX) 4857 -- CRL distribution points extension OID and syntax 4859 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31} 4861 CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 4863 DistributionPoint ::= SEQUENCE { 4864 distributionPoint [0] DistributionPointName OPTIONAL, 4865 reasons [1] ReasonFlags OPTIONAL, 4866 cRLIssuer [2] GeneralNames OPTIONAL } 4868 DistributionPointName ::= CHOICE { 4869 fullName [0] GeneralNames, 4870 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 4872 ReasonFlags ::= BIT STRING { 4873 unused (0), 4874 keyCompromise (1), 4875 cACompromise (2), 4876 affiliationChanged (3), 4877 superseded (4), 4878 cessationOfOperation (5), 4879 certificateHold (6) } 4881 -- extended key usage extension OID and syntax 4883 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 4885 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 4887 KeyPurposeId ::= OBJECT IDENTIFIER 4889 -- extended key purpose OIDs 4890 id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } 4891 id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } 4892 id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } 4893 id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } 4894 id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 } 4895 id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 } 4896 id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 } 4897 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 4898 -- inhibit any policy OID and syntax 4900 id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 } 4902 InhibitAnyPolicy ::= SkipCerts 4904 -- freshest (delta-)CRL extension OID and syntax 4906 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } 4908 FreshestCRL ::= CRLDistributionPoints 4910 -- authority info access 4912 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 4914 AuthorityInfoAccessSyntax ::= 4915 SEQUENCE SIZE (1..MAX) OF AccessDescription 4917 AccessDescription ::= SEQUENCE { 4918 accessMethod OBJECT IDENTIFIER, 4919 accessLocation GeneralName } 4921 -- CRL number extension OID and syntax 4923 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 4925 CRLNumber ::= INTEGER (0..MAX) 4927 -- issuing distribution point extension OID and syntax 4929 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 4931 IssuingDistributionPoint ::= SEQUENCE { 4932 distributionPoint [0] DistributionPointName OPTIONAL, 4933 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 4934 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 4935 onlySomeReasons [3] ReasonFlags OPTIONAL, 4936 indirectCRL [4] BOOLEAN DEFAULT FALSE } 4938 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 4940 -- deltaCRLIndicator ::= BaseCRLNumber 4942 BaseCRLNumber ::= CRLNumber 4944 -- CRL reasons extension OID and syntax 4945 id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 } 4947 CRLReason ::= ENUMERATED { 4948 unspecified (0), 4949 keyCompromise (1), 4950 cACompromise (2), 4951 affiliationChanged (3), 4952 superseded (4), 4953 cessationOfOperation (5), 4954 certificateHold (6), 4955 removeFromCRL (8) } 4957 -- certificate issuer CRL entry extension OID and syntax 4959 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } 4961 CertificateIssuer ::= GeneralNames 4963 -- hold instruction extension OID and syntax 4965 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 4967 HoldInstructionCode ::= OBJECT IDENTIFIER 4969 -- ANSI x9 holdinstructions 4971 -- ANSI x9 arc holdinstruction arc 4972 holdInstruction OBJECT IDENTIFIER ::= 4973 {joint-iso-itu-t(2) member-body(2) us(840) x9cm(10040) 2} 4975 -- ANSI X9 holdinstructions referenced by this standard 4976 id-holdinstruction-none OBJECT IDENTIFIER ::= 4977 {holdInstruction 1} -- deprecated 4978 id-holdinstruction-callissuer OBJECT IDENTIFIER ::= 4979 {holdInstruction 2} 4980 id-holdinstruction-reject OBJECT IDENTIFIER ::= 4981 {holdInstruction 3} 4983 -- invalidity date CRL entry extension OID and syntax 4985 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 4987 InvalidityDate ::= GeneralizedTime 4989 END 4990 Appendix B. 1993 ASN.1 Structures and OIDs 4992 B.1 Explicitly Tagged Module, 1993 Syntax 4994 PKIX1Explicit93 {iso(1) identified-organization(3) dod(6) internet(1) 4995 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-93(3)} 4997 DEFINITIONS EXPLICIT TAGS ::= 4999 BEGIN 5001 -- EXPORTS ALL -- 5003 IMPORTS 5004 authorityKeyIdentifier, subjectKeyIdentifier, keyUsage, 5005 extendedKeyUsage, privateKeyUsagePeriod, certificatePolicies, 5006 policyMappings, subjectAltName, issuerAltName, 5007 basicConstraints, nameConstraints, policyConstraints, 5008 cRLDistributionPoints, subjectDirectoryAttributes, 5009 cRLNumber, reasonCode, instructionCode, invalidityDate, 5010 issuingDistributionPoint, certificateIssuer, 5011 deltaCRLIndicator, authorityInfoAccess, id-ce 5012 FROM PKIX1Implicit93 {iso(1) identified-organization(3) 5013 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 5014 id-mod(0) id-pkix1-implicit-93(4)} ; 5016 -- 5017 -- Locally defined OIDs -- 5019 id-pkix OBJECT IDENTIFIER ::= 5020 { iso(1) identified-organization(3) dod(6) internet(1) 5021 security(5) mechanisms(5) pkix(7) } 5023 -- PKIX arcs 5024 -- arc for private certificate extensions 5025 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 5026 -- arc for policy qualifier types 5027 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 5028 -- arc for extended key purpose OIDS 5029 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 5030 -- arc for access descriptors 5031 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 5033 -- policyQualifierIds for Internet policy qualifiers 5034 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 5035 -- OID for CPS qualifier 5037 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 5038 -- OID for user notice qualifier 5040 -- based on excerpts from AuthenticationFramework 5041 -- {joint-iso-ccitt ds(5) modules(1) authenticationFramework(7) 2} 5043 -- Public Key Certificate -- 5045 Certificate ::= SIGNED { SEQUENCE { 5046 version [0] Version DEFAULT v1, 5047 serialNumber CertificateSerialNumber, 5048 signature AlgorithmIdentifier, 5049 issuer Name, 5050 validity Validity, 5051 subject Name, 5052 subjectPublicKeyInfo SubjectPublicKeyInfo, 5053 issuerUniqueIdentifier [1] IMPLICIT UniqueIdentifier OPTIONAL, 5054 ---if present, version shall be v2 or v3-- 5055 subjectUniqueIdentifier [2] IMPLICIT UniqueIdentifier OPTIONAL, 5056 ---if present, version shall be v2 or v3-- 5057 extensions [3] Extensions OPTIONAL 5058 --if present, version shall be v3--} } 5060 UniqueIdentifier ::= BIT STRING 5062 Version ::= INTEGER { v1(0), v2(1), v3(2) } 5064 CertificateSerialNumber ::= INTEGER 5066 Validity ::= SEQUENCE { 5067 notBefore Time, 5068 notAfter Time } 5070 Time ::= CHOICE { 5071 utcTime UTCTime, 5072 generalTime GeneralizedTime } 5074 SubjectPublicKeyInfo ::= SEQUENCE{ 5075 algorithm AlgorithmIdentifier, 5076 subjectPublicKey BIT STRING} 5078 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 5080 Extension ::= SEQUENCE { 5081 extnId EXTENSION.&id ({ExtensionSet}), 5082 critical BOOLEAN DEFAULT FALSE, 5083 extnValue OCTET STRING } 5084 -- contains a DER encoding of a value of type 5085 -- &ExtnType for the 5086 -- extension object identified by extnId -- 5088 -- The following information object set is defined to constrain the 5089 -- set of legal certificate extensions. 5091 ExtensionSet EXTENSION ::= { authorityKeyIdentifier | 5092 subjectKeyIdentifier | 5093 keyUsage | 5094 extendedKeyUsage | 5095 privateKeyUsagePeriod | 5096 certificatePolicies | 5097 policyMappings | 5098 subjectAltName | 5099 issuerAltName | 5100 basicConstraints | 5101 nameConstraints | 5102 policyConstraints | 5103 cRLDistributionPoints | 5104 subjectDirectoryAttributes | 5105 authorityInfoAccess } 5107 EXTENSION ::= CLASS { 5108 &id OBJECT IDENTIFIER UNIQUE, 5109 &ExtnType } 5110 WITH SYNTAX { 5111 SYNTAX &ExtnType 5112 IDENTIFIED BY &id } 5114 -- Certificate Revocation List -- 5116 CertificateList ::= SIGNED { SEQUENCE { 5117 version Version OPTIONAL, -- if present, shall be v2 5118 signature AlgorithmIdentifier, 5119 issuer Name, 5120 thisUpdate Time, 5121 nextUpdate Time OPTIONAL, 5122 revokedCertificates SEQUENCE OF SEQUENCE { 5123 userCertificate CertificateSerialNumber, 5124 revocationDate Time, 5125 crlEntryExtensions EntryExtensions OPTIONAL } OPTIONAL, 5126 crlExtensions [0] CRLExtensions OPTIONAL }} 5128 CRLExtensions ::= SEQUENCE SIZE (1..MAX) OF CRLExtension 5130 CRLExtension ::= SEQUENCE { 5131 extnId EXTENSION.&id ({CRLExtensionSet}), 5132 critical BOOLEAN DEFAULT FALSE, 5133 extnValue OCTET STRING } 5134 -- contains a DER encoding of a value of type 5135 -- &ExtnType for the 5136 -- extension object identified by extnId -- 5138 -- The following information object set is defined to constrain the 5139 -- set of legal CRL extensions. 5141 CRLExtensionSet EXTENSION ::= { authorityKeyIdentifier | 5142 issuerAltName | 5143 cRLNumber | 5144 deltaCRLIndicator | 5145 issuingDistributionPoint } 5147 -- EXTENSION defined above for certificates 5149 EntryExtensions ::= SEQUENCE SIZE (1..MAX) OF EntryExtension 5151 EntryExtension ::= SEQUENCE { 5152 extnId EXTENSION.&id ({EntryExtensionSet}), 5153 critical BOOLEAN DEFAULT FALSE, 5154 extnValue OCTET STRING } 5155 -- contains a DER encoding of a value of type 5156 -- &ExtnType for the 5157 -- extension object identified by extnId -- 5159 -- The following information object set is defined to constrain the 5160 -- set of legal CRL entry extensions. 5162 EntryExtensionSet EXTENSION ::= { reasonCode | 5163 instructionCode | 5164 invalidityDate | 5165 certificateIssuer } 5167 -- information object classes used in the defintion -- 5168 -- of certificates and CRLs -- 5170 -- Parameterized Type SIGNED -- 5172 SIGNED { ToBeSigned } ::= SEQUENCE { 5173 toBeSigned ToBeSigned, 5174 algorithm AlgorithmIdentifier, 5175 signature BIT STRING 5176 } 5178 -- Definition of AlgorithmIdentifier 5179 -- ISO definition was: 5180 -- 5181 -- AlgorithmIdentifier ::= SEQUENCE { 5182 -- algorithm ALGORITHM.&id({SupportedAlgorithms}), 5183 -- parameters ALGORITHM.&Type({SupportedAlgorithms} 5184 -- { @algorithm}) OPTIONAL } 5185 -- Definition of ALGORITHM 5186 -- ALGORITHM ::= TYPE-IDENTIFIER 5188 -- The following PKIX definition replaces the X.509 definition 5189 -- 5191 AlgorithmIdentifier ::= SEQUENCE { 5192 algorithm ALGORITHM-ID.&id({SupportedAlgorithms}), 5193 parameters ALGORITHM-ID.&Type({SupportedAlgorithms} 5194 { @algorithm}) OPTIONAL } 5196 -- Definition of ALGORITHM-ID 5198 ALGORITHM-ID ::= CLASS { 5199 &id OBJECT IDENTIFIER UNIQUE, 5200 &Type OPTIONAL 5201 } 5202 WITH SYNTAX { OID &id [PARMS &Type] } 5204 -- The definition of SupportedAlgorithms may be modified as this 5205 -- document does not specify a mandatory algorithm set. In addition, 5206 -- the set is specified as extensible, since additional algorithms 5207 -- may be supported 5209 SupportedAlgorithms ALGORITHM-ID ::= { ..., -- extensible 5210 rsaPublicKey | 5211 rsaSHA-1 | 5212 rsaMD5 | 5213 rsaMD2 | 5214 dssPublicKey | 5215 dsaSHA-1 | 5216 dhPublicKey } 5218 -- OIDs and parameter structures for ALGORITHM-IDs used 5219 -- in this specification 5221 rsaPublicKey ALGORITHM-ID ::= { OID rsaEncryption PARMS NULL } 5223 rsaSHA-1 ALGORITHM-ID ::= { OID sha1WithRSAEncryption PARMS NULL } 5225 rsaMD5 ALGORITHM-ID ::= { OID md5WithRSAEncryption PARMS NULL } 5227 rsaMD2 ALGORITHM-ID ::= { OID md2WithRSAEncryption PARMS NULL } 5228 dssPublicKey ALGORITHM-ID ::= { OID id-dsa PARMS Dss-Parms } 5230 dsaSHA-1 ALGORITHM-ID ::= { OID id-dsa-with-sha1 } 5232 dhPublicKey ALGORITHM-ID ::= {OID dhpublicnumber PARMS DomainParameters} 5234 -- algorithm identifiers and parameter structures 5236 pkcs-1 OBJECT IDENTIFIER ::= { 5237 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 } 5239 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } 5241 md2WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 2 } 5243 md5WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 4 } 5245 sha1WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 5 } 5247 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { 5248 iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 3 } 5250 Dss-Sig-Value ::= SEQUENCE { 5251 r INTEGER, 5252 s INTEGER } 5254 dhpublicnumber OBJECT IDENTIFIER ::= { 5255 iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 } 5257 DomainParameters ::= SEQUENCE { 5258 p INTEGER, -- odd prime, p=jq +1 5259 g INTEGER, -- generator, g 5260 q INTEGER, -- factor of p-1 5261 j INTEGER OPTIONAL, -- subgroup factor, j>= 2 5262 validationParms ValidationParms OPTIONAL } 5264 ValidationParms ::= SEQUENCE { 5265 seed BIT STRING, 5266 pgenCounter INTEGER } 5268 id-dsa OBJECT IDENTIFIER ::= { 5269 iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 } 5271 Dss-Parms ::= SEQUENCE { 5272 p INTEGER, 5273 q INTEGER, 5274 g INTEGER } 5275 -- The ASN.1 in this section supports the Name type 5276 -- and the directoryAttribute extension 5278 -- attribute data types -- 5280 Attribute ::= SEQUENCE { 5281 type ATTRIBUTE.&id ({SupportedAttributes}), 5282 values SET SIZE (1 .. MAX) OF ATTRIBUTE.&Type 5283 ({SupportedAttributes}{@type})} 5285 AttributeTypeAndValue ::= SEQUENCE { 5286 type ATTRIBUTE.&id ({SupportedAttributes}), 5287 value ATTRIBUTE.&Type ({SupportedAttributes}{@type})} 5289 -- naming data types -- 5291 Name ::= CHOICE { -- only one possibility for now -- 5292 rdnSequence RDNSequence } 5294 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 5296 RelativeDistinguishedName ::= 5297 SET SIZE (1 .. MAX) OF AttributeTypeAndValue 5299 ID ::= OBJECT IDENTIFIER 5301 -- ATTRIBUTE information object class specification 5302 -- Note: This has been greatly simplified for PKIX !! 5304 ATTRIBUTE ::= CLASS { 5305 &Type, 5306 &id OBJECT IDENTIFIER UNIQUE } 5307 WITH SYNTAX { 5308 WITH SYNTAX &Type ID &id } 5310 -- suggested naming attributes 5311 -- Definition of the following information object set may be 5312 -- augmented to meet local requirements. Note that deleting 5313 -- members of the set may prevent interoperability with 5314 -- conforming implementations. 5316 SupportedAttributes ATTRIBUTE ::= { 5317 name | commonName | surname | givenName | initials | 5318 generationQualifier | dnQualifier | countryName | 5319 localityName | stateOrProvinceName | organizationName | 5320 organizationalUnitName | title | pkcs9email } 5322 name ATTRIBUTE ::= { 5323 WITH SYNTAX DirectoryString { ub-name } 5324 ID id-at-name } 5326 commonName ATTRIBUTE ::= { 5327 WITH SYNTAX DirectoryString {ub-common-name} 5328 ID id-at-commonName } 5330 surname ATTRIBUTE ::= { 5331 WITH SYNTAX DirectoryString {ub-name} 5332 ID id-at-surname } 5334 givenName ATTRIBUTE ::= { 5335 WITH SYNTAX DirectoryString {ub-name} 5336 ID id-at-givenName } 5338 initials ATTRIBUTE ::= { 5339 WITH SYNTAX DirectoryString {ub-name} 5340 ID id-at-initials } 5342 generationQualifier ATTRIBUTE ::= { 5343 WITH SYNTAX DirectoryString {ub-name} 5344 ID id-at-generationQualifier} 5346 dnQualifier ATTRIBUTE ::= { 5347 WITH SYNTAX PrintableString 5348 ID id-at-dnQualifier } 5350 countryName ATTRIBUTE ::= { 5351 WITH SYNTAX PrintableString (SIZE (2)) 5352 -- IS 3166 codes only 5353 ID id-at-countryName } 5355 localityName ATTRIBUTE ::= { 5356 WITH SYNTAX DirectoryString {ub-locality-name} 5357 ID id-at-localityName } 5359 stateOrProvinceName ATTRIBUTE ::= { 5360 WITH SYNTAX DirectoryString {ub-state-name} 5361 ID id-at-stateOrProvinceName } 5363 organizationName ATTRIBUTE ::= { 5364 WITH SYNTAX DirectoryString {ub-organization-name} 5365 ID id-at-organizationName } 5367 organizationalUnitName ATTRIBUTE ::= { 5368 WITH SYNTAX DirectoryString {ub-organizational-unit-name} 5369 ID id-at-organizationalUnitName } 5371 title ATTRIBUTE ::= { 5372 WITH SYNTAX DirectoryString {ub-title} 5373 ID id-at-title } 5375 -- domainComponent from RFC 2247 5376 domainComponent ATTRIBUTE ::= { 5377 WITH SYNTAX IA5String 5378 ID id-domaincomponent } 5380 -- Legacy attributes 5382 pkcs9email ATTRIBUTE ::= { 5383 WITH SYNTAX PHGString, 5384 ID emailAddress } 5386 PHGString ::= IA5String (SIZE(1..ub-emailaddress-length)) 5388 pkcs-9 OBJECT IDENTIFIER ::= 5389 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 } 5391 emailAddress OBJECT IDENTIFIER ::= { pkcs-9 1 } 5393 -- object identifiers for Name type and directory attribute support 5395 -- Object identifier assignments -- 5397 id-at OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 4} 5399 -- Attributes -- 5401 id-at-commonName OBJECT IDENTIFIER ::= {id-at 3} 5402 id-at-surname OBJECT IDENTIFIER ::= {id-at 4} 5403 id-at-countryName OBJECT IDENTIFIER ::= {id-at 6} 5404 id-at-localityName OBJECT IDENTIFIER ::= {id-at 7} 5405 id-at-stateOrProvinceName OBJECT IDENTIFIER ::= {id-at 8} 5406 id-at-organizationName OBJECT IDENTIFIER ::= {id-at 10} 5407 id-at-organizationalUnitName OBJECT IDENTIFIER ::= {id-at 11} 5408 id-at-title OBJECT IDENTIFIER ::= {id-at 12} 5409 id-at-name OBJECT IDENTIFIER ::= {id-at 41} 5410 id-at-givenName OBJECT IDENTIFIER ::= {id-at 42} 5411 id-at-initials OBJECT IDENTIFIER ::= {id-at 43} 5412 id-at-generationQualifier OBJECT IDENTIFIER ::= {id-at 44} 5413 id-at-dnQualifier OBJECT IDENTIFIER ::= {id-at 46} 5414 id-at-serialNumber OBJECT IDENTIFIER ::= { id-at 5 } 5415 id-domainComponent OBJECT IDENTIFIER := 5416 { 0 9 2342 19200300 100 1 25 } 5418 -- Directory string type, used extensively in Name types -- 5419 DirectoryString { INTEGER:maxSize } ::= CHOICE { 5420 teletexString TeletexString (SIZE (1..maxSize)), 5421 printableString PrintableString (SIZE (1..maxSize)), 5422 universalString UniversalString (SIZE (1..maxSize)), 5423 bmpString BMPString (SIZE(1..maxSize)), 5424 utf8String UTF8String (SIZE(1..maxSize)) 5425 } 5427 -- End of ASN.1 for Name type and directory attribute support -- 5429 -- The ASN.1 in this section supports X.400 style names -- 5430 -- for implementations that use the x400Address component -- 5431 -- of GeneralName. -- 5433 ORAddress ::= SEQUENCE { 5434 built-in-standard-attributes BuiltInStandardAttributes, 5435 built-in-domain-defined-attributes 5436 BuiltInDomainDefinedAttributes OPTIONAL, 5437 -- see also teletex-domain-defined-attributes 5438 extension-attributes ExtensionAttributes OPTIONAL } 5440 -- The OR-address is semantically absent from the OR-name if the 5441 -- built-in-standard-attribute sequence is empty and the 5442 -- built-in-domain-defined-attributes and extension-attributes are 5443 -- both omitted. 5445 -- Built-in Standard Attributes 5447 BuiltInStandardAttributes ::= SEQUENCE { 5448 country-name CountryName OPTIONAL, 5449 administration-domain-name AdministrationDomainName OPTIONAL, 5450 network-address [0] NetworkAddress OPTIONAL, 5451 -- see also extended-network-address 5452 terminal-identifier [1] TerminalIdentifier OPTIONAL, 5453 private-domain-name [2] PrivateDomainName OPTIONAL, 5454 organization-name [3] OrganizationName OPTIONAL, 5455 -- see also teletex-organization-name 5456 numeric-user-identifier [4] NumericUserIdentifier OPTIONAL, 5457 personal-name [5] PersonalName OPTIONAL, 5458 -- see also teletex-personal-name 5459 organizational-unit-names [6] OrganizationalUnitNames OPTIONAL 5460 -- see also teletex-organizational-unit-names -- } 5462 CountryName ::= [APPLICATION 1] CHOICE { 5463 x121-dcc-code NumericString 5464 (SIZE (ub-country-name-numeric-length)), 5465 iso-3166-alpha2-code PrintableString 5466 (SIZE (ub-country-name-alpha-length)) } 5468 AdministrationDomainName ::= [APPLICATION 2] CHOICE { 5469 numeric NumericString (SIZE (0..ub-domain-name-length)), 5470 printable PrintableString (SIZE (0..ub-domain-name-length)) } 5472 NetworkAddress ::= X121Address 5473 -- see also extended-network-address 5475 X121Address ::= NumericString (SIZE (1..ub-x121-address-length)) 5477 TerminalIdentifier ::= PrintableString (SIZE (1..ub-terminal-id-length)) 5479 PrivateDomainName ::= CHOICE { 5480 numeric NumericString (SIZE (1..ub-domain-name-length)), 5481 printable PrintableString (SIZE (1..ub-domain-name-length)) } 5483 OrganizationName ::= PrintableString 5484 (SIZE (1..ub-organization-name-length)) 5485 -- see also teletex-organization-name 5487 NumericUserIdentifier ::= NumericString 5488 (SIZE (1..ub-numeric-user-id-length)) 5490 PersonalName ::= SET { 5491 surname [0] PrintableString (SIZE (1..ub-surname-length)), 5492 given-name [1] PrintableString 5493 (SIZE (1..ub-given-name-length)) OPTIONAL, 5494 initials [2] PrintableString 5495 (SIZE (1..ub-initials-length)) OPTIONAL, 5496 generation-qualifier [3] PrintableString 5497 (SIZE (1..ub-generation-qualifier-length)) OPTIONAL} 5498 -- see also teletex-personal-name 5500 OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units) 5501 OF OrganizationalUnitName 5502 -- see also teletex-organizational-unit-names 5504 OrganizationalUnitName ::= PrintableString (SIZE 5505 (1..ub-organizational-unit-name-length)) 5507 -- Built-in Domain-defined Attributes 5508 BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE 5509 (1..ub-domain-defined-attributes) OF 5510 BuiltInDomainDefinedAttribute 5512 BuiltInDomainDefinedAttribute ::= SEQUENCE { 5513 type PrintableString (SIZE 5514 (1..ub-domain-defined-attribute-type-length)), 5515 value PrintableString (SIZE 5516 (1..ub-domain-defined-attribute-value-length)) } 5518 -- Extension Attributes 5520 ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) 5521 OF ExtensionAttribute 5522 ExtensionAttribute ::= SEQUENCE { 5523 extension-attribute-type [0] EXTENSION-ATTRIBUTE.&id 5524 ({ExtensionAttributeTable}), 5525 extension-attribute-value [1] EXTENSION-ATTRIBUTE.&Type 5526 ({ExtensionAttributeTable} {@extension-attribute-type}) } 5528 EXTENSION-ATTRIBUTE ::= CLASS { 5529 &id INTEGER (0..ub-extension-attributes) UNIQUE, 5530 &Type } 5531 WITH SYNTAX {&Type IDENTIFIED BY &id} 5533 ExtensionAttributeTable EXTENSION-ATTRIBUTE ::= { 5534 common-name | 5535 teletex-common-name | 5536 teletex-organization-name | 5537 teletex-personal-name | 5538 teletex-organizational-unit-names | 5539 teletex-domain-defined-attributes | 5540 pds-name | 5541 physical-delivery-country-name | 5542 postal-code | 5543 physical-delivery-office-name | 5544 physical-delivery-office-number | 5545 extension-OR-address-components | 5546 physical-delivery-personal-name | 5547 physical-delivery-organization-name | 5548 extension-physical-delivery-address-components | 5549 unformatted-postal-address | 5550 street-address | 5551 post-office-box-address | 5552 poste-restante-address | 5553 unique-postal-name | 5554 local-postal-attributes | 5555 extended-network-address | 5556 terminal-type } 5558 -- Extension Standard Attributes 5560 common-name EXTENSION-ATTRIBUTE ::= {CommonName IDENTIFIED BY 1} 5561 CommonName ::= PrintableString (SIZE (1..ub-common-name-length)) 5563 teletex-common-name EXTENSION-ATTRIBUTE ::= 5564 {TeletexCommonName IDENTIFIED BY 2} 5566 TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length)) 5568 teletex-organization-name EXTENSION-ATTRIBUTE ::= 5569 {TeletexOrganizationName IDENTIFIED BY 3} 5571 TeletexOrganizationName ::= 5572 TeletexString (SIZE (1..ub-organization-name-length)) 5574 teletex-personal-name EXTENSION-ATTRIBUTE ::= 5575 {TeletexPersonalName IDENTIFIED BY 4} 5577 TeletexPersonalName ::= SET { 5578 surname [0] TeletexString (SIZE (1..ub-surname-length)), 5579 given-name [1] TeletexString 5580 (SIZE (1..ub-given-name-length)) OPTIONAL, 5581 initials [2] TeletexString (SIZE (1..ub-initials-length)) OPTIONAL, 5582 generation-qualifier [3] TeletexString (SIZE 5583 (1..ub-generation-qualifier-length)) OPTIONAL } 5585 teletex-organizational-unit-names EXTENSION-ATTRIBUTE ::= 5586 {TeletexOrganizationalUnitNames IDENTIFIED BY 5} 5588 TeletexOrganizationalUnitNames ::= SEQUENCE SIZE 5589 (1..ub-organizational-units) OF TeletexOrganizationalUnitName 5591 TeletexOrganizationalUnitName ::= TeletexString 5592 (SIZE (1..ub-organizational-unit-name-length)) 5594 pds-name EXTENSION-ATTRIBUTE ::= {PDSName IDENTIFIED BY 7} 5596 PDSName ::= PrintableString (SIZE (1..ub-pds-name-length)) 5598 physical-delivery-country-name EXTENSION-ATTRIBUTE ::= 5599 {PhysicalDeliveryCountryName IDENTIFIED BY 8} 5601 PhysicalDeliveryCountryName ::= CHOICE { 5602 x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)), 5603 iso-3166-alpha2-code PrintableString 5604 (SIZE (ub-country-name-alpha-length)) } 5606 postal-code EXTENSION-ATTRIBUTE ::= {PostalCode IDENTIFIED BY 9} 5608 PostalCode ::= CHOICE { 5609 numeric-code NumericString (SIZE (1..ub-postal-code-length)), 5610 printable-code PrintableString (SIZE (1..ub-postal-code-length)) } 5612 physical-delivery-office-name EXTENSION-ATTRIBUTE ::= 5613 {PhysicalDeliveryOfficeName IDENTIFIED BY 10} 5615 PhysicalDeliveryOfficeName ::= PDSParameter 5617 physical-delivery-office-number EXTENSION-ATTRIBUTE ::= 5618 {PhysicalDeliveryOfficeNumber IDENTIFIED BY 11} 5620 PhysicalDeliveryOfficeNumber ::= PDSParameter 5622 extension-OR-address-components EXTENSION-ATTRIBUTE ::= 5623 {ExtensionORAddressComponents IDENTIFIED BY 12} 5625 ExtensionORAddressComponents ::= PDSParameter 5627 physical-delivery-personal-name EXTENSION-ATTRIBUTE ::= 5628 {PhysicalDeliveryPersonalName IDENTIFIED BY 13} 5630 PhysicalDeliveryPersonalName ::= PDSParameter 5632 physical-delivery-organization-name EXTENSION-ATTRIBUTE ::= 5633 {PhysicalDeliveryOrganizationName IDENTIFIED BY 14} 5635 PhysicalDeliveryOrganizationName ::= PDSParameter 5637 extension-physical-delivery-address-components EXTENSION-ATTRIBUTE ::= 5638 {ExtensionPhysicalDeliveryAddressComponents IDENTIFIED BY 15} 5640 ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter 5642 unformatted-postal-address EXTENSION-ATTRIBUTE ::= 5643 {UnformattedPostalAddress IDENTIFIED BY 16} 5645 UnformattedPostalAddress ::= SET { 5646 printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) OF 5647 PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL, 5648 teletex-string TeletexString (SIZE 5649 (1..ub-unformatted-address-length)) OPTIONAL } 5651 street-address EXTENSION-ATTRIBUTE ::= 5652 {StreetAddress IDENTIFIED BY 17} 5654 StreetAddress ::= PDSParameter 5656 post-office-box-address EXTENSION-ATTRIBUTE ::= 5657 {PostOfficeBoxAddress IDENTIFIED BY 18} 5659 PostOfficeBoxAddress ::= PDSParameter 5661 poste-restante-address EXTENSION-ATTRIBUTE ::= 5662 {PosteRestanteAddress IDENTIFIED BY 19} 5664 PosteRestanteAddress ::= PDSParameter 5666 unique-postal-name EXTENSION-ATTRIBUTE ::= 5667 {UniquePostalName IDENTIFIED BY 20} 5669 UniquePostalName ::= PDSParameter 5671 local-postal-attributes EXTENSION-ATTRIBUTE ::= 5672 {LocalPostalAttributes IDENTIFIED BY 21} 5674 LocalPostalAttributes ::= PDSParameter 5676 PDSParameter ::= SET { 5677 printable-string PrintableString 5678 (SIZE(1..ub-pds-parameter-length)) OPTIONAL, 5679 teletex-string TeletexString 5680 (SIZE(1..ub-pds-parameter-length)) OPTIONAL } 5682 extended-network-address EXTENSION-ATTRIBUTE ::= 5683 {ExtendedNetworkAddress IDENTIFIED BY 22} 5685 ExtendedNetworkAddress ::= CHOICE { 5686 e163-4-address SEQUENCE { 5687 number [0] NumericString 5688 (SIZE (1..ub-e163-4-number-length)), 5689 sub-address [1] NumericString 5690 (SIZE (1..ub-e163-4-sub-address-length)) OPTIONAL}, 5691 psap-address [0] PresentationAddress } 5693 PresentationAddress ::= SEQUENCE { 5694 pSelector [0] EXPLICIT OCTET STRING OPTIONAL, 5695 sSelector [1] EXPLICIT OCTET STRING OPTIONAL, 5696 tSelector [2] EXPLICIT OCTET STRING OPTIONAL, 5697 nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING} 5699 terminal-type EXTENSION-ATTRIBUTE ::= {TerminalType IDENTIFIED BY 23} 5701 TerminalType ::= INTEGER { 5702 telex (3), 5703 teletex (4), 5704 g3-facsimile (5), 5705 g4-facsimile (6), 5706 ia5-terminal (7), 5707 videotex (8) } (0..ub-integer-options) 5709 -- Extension Domain-defined Attributes 5711 teletex-domain-defined-attributes EXTENSION-ATTRIBUTE ::= 5712 {TeletexDomainDefinedAttributes IDENTIFIED BY 6} 5714 TeletexDomainDefinedAttributes ::= SEQUENCE SIZE 5715 (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute 5717 TeletexDomainDefinedAttribute ::= SEQUENCE { 5718 type TeletexString 5719 (SIZE (1..ub-domain-defined-attribute-type-length)), 5720 value TeletexString 5721 (SIZE (1..ub-domain-defined-attribute-value-length)) } 5723 -- specifications of Upper Bounds 5724 -- shall be regarded as mandatory 5725 -- from Annex B of ITU-T X.411 5726 -- Reference Definition of MTS Parameter Upper Bounds 5728 -- Upper Bounds 5729 ub-name INTEGER ::= 32768 5730 ub-common-name INTEGER ::= 64 5731 ub-locality-name INTEGER ::= 128 5732 ub-state-name INTEGER ::= 128 5733 ub-organization-name INTEGER ::= 64 5734 ub-organizational-unit-name INTEGER ::= 64 5735 ub-title INTEGER ::= 64 5736 ub-match INTEGER ::= 128 5738 ub-emailaddress-length INTEGER ::= 128 5740 ub-common-name-length INTEGER ::= 64 5741 ub-country-name-alpha-length INTEGER ::= 2 5742 ub-country-name-numeric-length INTEGER ::= 3 5743 ub-domain-defined-attributes INTEGER ::= 4 5744 ub-domain-defined-attribute-type-length INTEGER ::= 8 5745 ub-domain-defined-attribute-value-length INTEGER ::= 128 5746 ub-domain-name-length INTEGER ::= 16 5747 ub-extension-attributes INTEGER ::= 256 5748 ub-e163-4-number-length INTEGER ::= 15 5749 ub-e163-4-sub-address-length INTEGER ::= 40 5750 ub-generation-qualifier-length INTEGER ::= 3 5751 ub-given-name-length INTEGER ::= 16 5752 ub-initials-length INTEGER ::= 5 5753 ub-integer-options INTEGER ::= 256 5754 ub-numeric-user-id-length INTEGER ::= 32 5755 ub-organization-name-length INTEGER ::= 64 5756 ub-organizational-unit-name-length INTEGER ::= 32 5757 ub-organizational-units INTEGER ::= 4 5758 ub-pds-name-length INTEGER ::= 16 5759 ub-pds-parameter-length INTEGER ::= 30 5760 ub-pds-physical-address-lines INTEGER ::= 6 5761 ub-postal-code-length INTEGER ::= 16 5762 ub-surname-length INTEGER ::= 40 5763 ub-terminal-id-length INTEGER ::= 24 5764 ub-unformatted-address-length INTEGER ::= 180 5765 ub-x121-address-length INTEGER ::= 16 5767 -- Note - upper bounds on TeletexString are measured in characters. 5768 -- A significantly greater number of octets will be required to hold 5769 -- such a value. As a minimum, 16 octets, or twice the specified upper 5770 -- bound, whichever is the larger, should be allowed. 5772 END 5773 B.2 Implicitly Tagged Module, 1993 Syntax 5775 PKIX1Implicit93 {iso(1) identified-organization(3) dod(6) internet(1) 5776 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-93(4)} 5778 DEFINITIONS IMPLICIT TAGS::= 5780 BEGIN 5782 --EXPORTS ALL -- 5784 IMPORTS 5785 id-pe, id-qt, id-kp, id-ad, id-qt-unotice, 5786 ORAddress, Name, RelativeDistinguishedName, 5787 CertificateSerialNumber, CertificateList, 5788 AlgorithmIdentifier, ub-name, DirectoryString, 5789 Attribute, EXTENSION 5790 FROM PKIX1Explicit93 {iso(1) identified-organization(3) 5791 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 5792 id-mod(0) id-pkix1-explicit-93(3)}; 5794 -- Key and policy information extensions -- 5796 authorityKeyIdentifier EXTENSION ::= { 5797 SYNTAX AuthorityKeyIdentifier 5798 IDENTIFIED BY id-ce-authorityKeyIdentifier } 5800 AuthorityKeyIdentifier ::= SEQUENCE { 5801 keyIdentifier [0] KeyIdentifier OPTIONAL, 5802 authorityCertIssuer [1] GeneralNames OPTIONAL, 5803 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 5804 ( WITH COMPONENTS {..., authorityCertIssuer PRESENT, 5805 authorityCertSerialNumber PRESENT} | 5806 WITH COMPONENTS {..., authorityCertIssuer ABSENT, 5807 authorityCertSerialNumber ABSENT} ) 5809 KeyIdentifier ::= OCTET STRING 5811 subjectKeyIdentifier EXTENSION ::= { 5812 SYNTAX SubjectKeyIdentifier 5813 IDENTIFIED BY id-ce-subjectKeyIdentifier } 5815 SubjectKeyIdentifier ::= KeyIdentifier 5817 keyUsage EXTENSION ::= { 5818 SYNTAX KeyUsage 5819 IDENTIFIED BY id-ce-keyUsage } 5821 KeyUsage ::= BIT STRING { 5822 digitalSignature (0), 5823 nonRepudiation (1), 5824 keyEncipherment (2), 5825 dataEncipherment (3), 5826 keyAgreement (4), 5827 keyCertSign (5), 5828 cRLSign (6), 5829 encipherOnly (7), 5830 decipherOnly (8) } 5832 extendedKeyUsage EXTENSION ::= { 5833 SYNTAX SEQUENCE SIZE (1..MAX) OF KeyPurposeId 5834 IDENTIFIED BY id-ce-extKeyUsage } 5836 KeyPurposeId ::= OBJECT IDENTIFIER 5838 -- PKIX-defined extended key purpose OIDs 5839 id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } 5840 id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } 5841 id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } 5842 id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } 5843 id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 } 5844 id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 } 5845 id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 } 5846 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 5848 privateKeyUsagePeriod EXTENSION ::= { 5849 SYNTAX PrivateKeyUsagePeriod 5850 IDENTIFIED BY { id-ce-privateKeyUsagePeriod } } 5852 PrivateKeyUsagePeriod ::= SEQUENCE { 5853 notBefore [0] GeneralizedTime OPTIONAL, 5854 notAfter [1] GeneralizedTime OPTIONAL } 5855 ( WITH COMPONENTS {..., notBefore PRESENT} | 5856 WITH COMPONENTS {..., notAfter PRESENT} ) 5858 certificatePolicies EXTENSION ::= { 5859 SYNTAX CertificatePoliciesSyntax 5860 IDENTIFIED BY id-ce-certificatePolicies } 5862 CertificatePoliciesSyntax ::= 5863 SEQUENCE SIZE (1..MAX) OF PolicyInformation 5865 PolicyInformation ::= SEQUENCE { 5866 policyIdentifier CertPolicyId, 5867 policyQualifiers SEQUENCE SIZE (1..MAX) OF 5868 PolicyQualifierInfo OPTIONAL } 5870 CertPolicyId ::= OBJECT IDENTIFIER 5872 PolicyQualifierInfo ::= SEQUENCE { 5873 policyQualifierId CERT-POLICY-QUALIFIER.&id 5874 ({SupportedPolicyQualifiers}), 5875 qualifier CERT-POLICY-QUALIFIER.&Qualifier 5876 ({SupportedPolicyQualifiers} 5877 {@policyQualifierId})OPTIONAL } 5879 SupportedPolicyQualifiers CERT-POLICY-QUALIFIER ::= { noticeToUser | 5880 pointerToCPS } 5882 CERT-POLICY-QUALIFIER ::= CLASS { 5883 &id OBJECT IDENTIFIER UNIQUE, 5884 &Qualifier OPTIONAL } 5885 WITH SYNTAX { 5886 POLICY-QUALIFIER-ID &id 5887 [QUALIFIER-TYPE &Qualifier] } 5889 -- the following OID describes the special policy "any-policy" 5891 anyPolicy OBJECT IDENTIFIER ::= {id-ce-certificate-policies 0} 5893 policyMappings EXTENSION ::= { 5894 SYNTAX PolicyMappingsSyntax 5895 IDENTIFIED BY id-ce-policyMappings } 5897 PolicyMappingsSyntax ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 5898 issuerDomainPolicy CertPolicyId, 5899 subjectDomainPolicy CertPolicyId } 5901 -- Certificate subject and certificate issuer attributes extensions -- 5903 subjectAltName EXTENSION ::= { 5904 SYNTAX GeneralNames 5905 IDENTIFIED BY id-ce-subjectAltName } 5907 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 5909 GeneralName ::= CHOICE { 5910 otherName [0] INSTANCE OF OTHER-NAME, 5911 rfc822Name [1] IA5String, 5912 dNSName [2] IA5String, 5913 x400Address [3] ORAddress, 5914 directoryName [4] Name, 5915 ediPartyName [5] EDIPartyName, 5916 uniformResourceIdentifier [6] IA5String, 5917 iPAddress [7] OCTET STRING, 5918 registeredID [8] OBJECT IDENTIFIER } 5920 OTHER-NAME ::= TYPE-IDENTIFIER 5922 EDIPartyName ::= SEQUENCE { 5923 nameAssigner [0] DirectoryString {ub-name} OPTIONAL, 5924 partyName [1] DirectoryString {ub-name} } 5926 issuerAltName EXTENSION ::= { 5927 SYNTAX GeneralNames 5928 IDENTIFIED BY id-ce-issuerAltName } 5930 subjectDirectoryAttributes EXTENSION ::= { 5931 SYNTAX AttributesSyntax 5932 IDENTIFIED BY id-ce-subjectDirectoryAttributes } 5934 AttributesSyntax ::= SEQUENCE SIZE (1..MAX) OF Attribute 5936 -- Certification path constraints extensions -- 5938 basicConstraints EXTENSION ::= { 5939 SYNTAX BasicConstraintsSyntax 5940 IDENTIFIED BY id-ce-basicConstraints } 5942 BasicConstraintsSyntax ::= SEQUENCE { 5943 cA BOOLEAN DEFAULT FALSE, 5944 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 5946 nameConstraints EXTENSION ::= { 5947 SYNTAX NameConstraintsSyntax 5948 IDENTIFIED BY id-ce-nameConstraints } 5950 NameConstraintsSyntax ::= SEQUENCE { 5951 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 5952 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 5954 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 5956 GeneralSubtree ::= SEQUENCE { 5957 base GeneralName, 5958 minimum [0] BaseDistance DEFAULT 0, 5959 maximum [1] BaseDistance OPTIONAL } 5961 BaseDistance ::= INTEGER (0..MAX) 5963 policyConstraints EXTENSION ::= { 5964 SYNTAX PolicyConstraintsSyntax 5965 IDENTIFIED BY id-ce-policyConstraints } 5967 PolicyConstraintsSyntax ::= SEQUENCE { 5968 requireExplicitPolicy [0] SkipCerts OPTIONAL, 5969 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 5971 SkipCerts ::= INTEGER (0..MAX) 5973 inhibitAnyPolicy EXTENSION ::= { 5974 SYNTAX SkipCerts 5975 IDENTIFIED BY id-ce-inhibitAnyPolicy} 5977 -- Basic CRL extensions -- 5979 cRLNumber EXTENSION ::= { 5980 SYNTAX CRLNumber 5981 IDENTIFIED BY id-ce-cRLNumber } 5983 CRLNumber ::= INTEGER (0..MAX) 5985 reasonCode EXTENSION ::= { 5986 SYNTAX CRLReason 5987 IDENTIFIED BY id-ce-reasonCode } 5989 CRLReason ::= ENUMERATED { 5990 unspecified (0), 5991 keyCompromise (1), 5992 cACompromise (2), 5993 affiliationChanged (3), 5994 superseded (4), 5995 cessationOfOperation (5), 5996 certificateHold (6), 5997 removeFromCRL (8) } 5999 instructionCode EXTENSION ::= { 6000 SYNTAX HoldInstruction 6001 IDENTIFIED BY id-ce-instructionCode } 6003 HoldInstruction ::= OBJECT IDENTIFIER 6005 -- holdinstructions described in this specification, from ANSI x9 6007 -- ANSI x9 arc holdinstruction arc 6008 holdInstruction OBJECT IDENTIFIER ::= { 6009 joint-iso-ccitt(2) member-body(2) us(840) x9cm(10040) 2} 6011 -- ANSI X9 holdinstructions referenced by this standard 6012 id-holdinstruction-none OBJECT IDENTIFIER ::= {holdInstruction 1} 6013 id-holdinstruction-callissuer OBJECT IDENTIFIER ::= {holdInstruction 2} 6014 id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3} 6015 invalidityDate EXTENSION ::= { 6016 SYNTAX GeneralizedTime 6017 IDENTIFIED BY id-ce-invalidityDate } 6019 -- CRL distribution points and delta-CRL extensions -- 6021 cRLDistributionPoints EXTENSION ::= { 6022 SYNTAX CRLDistPointsSyntax 6023 IDENTIFIED BY id-ce-cRLDistributionPoints } 6025 CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 6027 DistributionPoint ::= SEQUENCE { 6028 distributionPoint [0] DistributionPointName OPTIONAL, 6029 reasons [1] ReasonFlags OPTIONAL, 6030 cRLIssuer [2] GeneralNames OPTIONAL } 6032 DistributionPointName ::= CHOICE { 6033 fullName [0] GeneralNames, 6034 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 6036 ReasonFlags ::= BIT STRING { 6037 unused (0), 6038 keyCompromise (1), 6039 caCompromise (2), 6040 affiliationChanged (3), 6041 superseded (4), 6042 cessationOfOperation (5), 6043 certificateHold (6) } 6045 issuingDistributionPoint EXTENSION ::= { 6046 SYNTAX IssuingDistPointSyntax 6047 IDENTIFIED BY id-ce-issuingDistributionPoint } 6049 IssuingDistPointSyntax ::= SEQUENCE { 6050 distributionPoint [0] DistributionPointName OPTIONAL, 6051 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 6052 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 6053 onlySomeReasons [3] ReasonFlags OPTIONAL, 6054 indirectCRL [4] BOOLEAN DEFAULT FALSE } 6056 certificateIssuer EXTENSION ::= { 6057 SYNTAX GeneralNames 6058 IDENTIFIED BY id-ce-certificateIssuer } 6060 deltaCRLIndicator EXTENSION ::= { 6061 SYNTAX BaseCRLNumber 6062 IDENTIFIED BY id-ce-deltaCRLIndicator } 6064 BaseCRLNumber ::= CRLNumber 6066 freshestCRL EXTENSION ::= { 6067 SYNTAX CRLDistPointsSyntax 6068 IDENTIFIED BY id-ce-freshestCRL } 6070 -- Object identifier assignments for ISO certificate extensions -- 6071 id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 6073 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= {id-ce 9} 6074 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= {id-ce 14} 6075 id-ce-keyUsage OBJECT IDENTIFIER ::= {id-ce 15} 6076 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= {id-ce 16} 6077 id-ce-subjectAltName OBJECT IDENTIFIER ::= {id-ce 17} 6078 id-ce-issuerAltName OBJECT IDENTIFIER ::= {id-ce 18} 6079 id-ce-basicConstraints OBJECT IDENTIFIER ::= {id-ce 19} 6080 id-ce-cRLNumber OBJECT IDENTIFIER ::= {id-ce 20} 6081 id-ce-reasonCode OBJECT IDENTIFIER ::= {id-ce 21} 6082 id-ce-instructionCode OBJECT IDENTIFIER ::= {id-ce 23} 6083 id-ce-invalidityDate OBJECT IDENTIFIER ::= {id-ce 24} 6084 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= {id-ce 27} 6085 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= {id-ce 28} 6086 id-ce-certificateIssuer OBJECT IDENTIFIER ::= {id-ce 29} 6087 id-ce-nameConstraints OBJECT IDENTIFIER ::= {id-ce 30} 6088 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31} 6089 id-ce-certificatePolicies OBJECT IDENTIFIER ::= {id-ce 32} 6090 id-ce-policyMappings OBJECT IDENTIFIER ::= {id-ce 33} 6091 id-ce-policyConstraints OBJECT IDENTIFIER ::= {id-ce 36} 6092 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= {id-ce 35} 6093 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 6094 id-ce-freshestCRL OBJECT IDENTIFIER ::= {id-ce 46} 6095 id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= {id-ce 54} 6097 -- PKIX 1 extensions 6099 authorityInfoAccess EXTENSION ::= { 6100 SYNTAX AuthorityInfoAccessSyntax 6101 IDENTIFIED BY id-pe-authorityInfoAccess } 6103 AuthorityInfoAccessSyntax ::= 6104 SEQUENCE SIZE (1..MAX) OF AccessDescription 6106 AccessDescription ::= SEQUENCE { 6107 accessMethod OBJECT IDENTIFIER, 6108 accessLocation GeneralName } 6110 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 6111 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 6112 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 6114 -- PKIX policy qualifier definitions 6116 noticeToUser CERT-POLICY-QUALIFIER ::= { 6117 POLICY-QUALIFIER-ID id-qt-cps QUALIFIER-TYPE CPSuri} 6119 pointerToCPS CERT-POLICY-QUALIFIER ::= { 6120 POLICY-QUALIFIER-ID id-qt-unotice QUALIFIER-TYPE UserNotice} 6122 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 6123 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 6125 CPSuri ::= IA5String 6127 UserNotice ::= SEQUENCE { 6128 noticeRef NoticeReference OPTIONAL, 6129 explicitText DisplayText OPTIONAL} 6131 NoticeReference ::= SEQUENCE { 6132 organization DisplayText, 6133 noticeNumbers SEQUENCE OF INTEGER } 6135 DisplayText ::= CHOICE { 6136 ia5String IA5String (SIZE (1..200)), 6137 visibleString VisibleString (SIZE (1..200)), 6138 bmpString BMPString (SIZE (1..200)), 6139 utf8String UTF8String (SIZE (1..200)) } 6141 END 6143 Appendix C. ASN.1 Notes 6145 CAs MUST force the serialNumber to be a positive integer, that is, 6146 the sign bit in the DER encoding of the INTEGER value MUST be zero - 6147 this can be done by adding a leading (leftmost) `00'H octet if neces- 6148 sary. This removes a potential ambiguity in mapping between a string 6149 of octets and an integer value. 6151 Given the uniqueness requirements above serial numbers can be 6152 expected to contain long integers. Certificate users MUST be able to 6153 handle serialNumber values longer than 32 bits. Conformant CAs MUST 6154 NOT use serialNumber values longer than 20 octets. 6156 The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 6157 constructs. A valid ASN.1 sequence will have zero or more entries. 6158 The SIZE (1..MAX) construct constrains the sequence to have at least 6159 one entry. MAX indicates the upper bound is unspecified. Implementa- 6160 tions are free to choose an upper bound that suits their environment. 6162 The construct "positiveInt ::= INTEGER (0..MAX)" defines positiveInt 6163 as a subtype of INTEGER containing integers greater than or equal to 6164 zero. The upper bound is unspecified. Implementations are free to 6165 select an upper bound that suits their environment. 6167 The character string type PrintableString supports a very basic Latin 6168 character set: the lower case letters 'a' through 'z', upper case 6169 letters 'A' through 'Z', the digits '0' through '9', eleven special 6170 characters ' " ( ) + , - . / : ? and space. 6172 The character string type TeletexString is a superset of Printable- 6173 String. TeletexString supports a fairly standard (ascii-like) Latin 6174 character set, Latin characters with non-spacing accents and Japanese 6175 characters. 6177 The character string type UniversalString supports any of the charac- 6178 ters allowed by ISO 10646-1. ISO 10646 is the Universal multiple- 6179 octet coded Character Set (UCS). ISO 10646-1 specifes the architec- 6180 ture and the "basic multilingual plane" - a large standard character 6181 set which includes all major world character standards. 6183 The character string type UTF8String will be introduced in the 1998 6184 version of ASN.1. UTF8String is a universal type and has been 6185 assigned tag number 12. The content of UTF8String was defined by RFC 6186 2044 and updated in RFC 2279, "UTF-8, a transformation Format of ISO 6187 10646." ISO is expected to formally add UTF8String to the list of 6188 choices for DirectoryString in 1998 as well. 6190 In anticipation of these changes, and in conformance with IETF Best 6191 Practices codified in RFC 2277, IETF Policy on Character Sets and 6192 Languages, this document includes UTF8String as a choice in Directo- 6193 ryString and the CPS qualifier extensions. 6195 Implementers should note that the DER encoding of the SET OF values 6196 requires ordering of the encodings of the values. In particular, this 6197 issue arises with respect to distinguished names. 6199 Object Identifiers (OIDs) are used throught this specification to 6200 identify certificate policies, public key and signature algorithms, 6201 certificate extensions, etc. There is no maximum size for OIDs. 6202 This specification mandates support for OIDs which have arc elements 6203 with values that are less than 2^28, i.e. they MUST be between 0 and 6204 268,435,455 inclusive. This allows each arc element to be represented 6205 within a single 32 bit word. Implementations MUST also support OIDs 6206 where the length of the dotted decimal (see [LDAP], section 4.1.2) 6207 string representation can be up to 100 bytes (inclusive). Implementa- 6208 tions MUST be able to handle OIDs with up to 20 elements (inclusive). 6209 CAs SHOULD NOT issue certificates which contain OIDs that breach 6210 these requirements. 6212 Appendix D. Examples 6214 This section contains four examples: three certificates and a CRL. 6215 The first two certificates and the CRL comprise a minimal certifica- 6216 tion path. 6218 Section D.1 contains an annotated hex dump of a "self-signed" certi- 6219 ficate issued by a CA whose distinguished name is 6220 cn=us,o=gov,ou=nist. The certificate contains a DSA public key with 6221 parameters, and is signed by the corresponding DSA private key. 6223 Section D.2 contains an annotated hex dump of an end-entity certifi- 6224 cate. The end entity certificate contains a DSA public key, and is 6225 signed by the private key corresponding to the "self-signed" certifi- 6226 cate in section D.1. 6228 Section D.3 contains a dump of an end entity certificate which con- 6229 tains an RSA public key and is signed with RSA and MD5. This certi- 6230 ficate is not part of the minimal certification path. 6232 Section D.4 contains an annotated hex dump of a CRL. The CRL is 6233 issued by the CA whose distinguished name is cn=us,o=gov,ou=nist and 6234 the list of revoked certificates includes the end entity certificate 6235 presented in D.2. 6237 D.1 Certificate 6239 This section contains an annotated hex dump of a 699 byte version 3 6240 certificate. The certificate contains the following information: 6241 (a) the serial number is 17 (11 hex); 6242 (b) the certificate is signed with DSA and the SHA-1 hash algorithm; 6243 (c) the issuer's distinguished name is OU=nist; O=gov; C=US 6244 (d) and the subject's distinguished name is OU=nist; O=gov; C=US 6245 (e) the certificate was issued on June 30, 1997 and will expire on 6246 December 31, 1997; 6247 (f) the certificate contains a 1024 bit DSA public key with parame- 6248 ters; 6249 (g) the certificate contains a subject key identifier extension; and 6250 (h) the certificate is a CA certificate (as indicated through the 6251 basic constraints extension.) 6253 0000 30 82 02 b7 695: SEQUENCE 6254 0004 30 82 02 77 631: . SEQUENCE tbscertificate 6255 0008 a0 03 3: . . [0] 6256 0010 02 01 1: . . . INTEGER 2 6257 : 02 6258 0013 02 01 1: . . INTEGER 17 6259 : 11 6260 0016 30 09 9: . . SEQUENCE 6261 0018 06 07 7: . . . OID 1.2.840.10040.4.3: dsa-with-sha 6262 : 2a 86 48 ce 38 04 03 6263 0027 30 2a 42: . . SEQUENCE 6264 0029 31 0b 11: . . . SET 6265 0031 30 09 9: . . . . SEQUENCE 6266 0033 06 03 3: . . . . . OID 2.5.4.6: C 6267 : 55 04 06 6268 0038 13 02 2: . . . . . PrintableString 'US' 6269 : 55 53 6270 0042 31 0c 12: . . . SET 6271 0044 30 0a 10: . . . . SEQUENCE 6272 0046 06 03 3: . . . . . OID 2.5.4.10: O 6273 : 55 04 0a 6274 0051 13 03 3: . . . . . PrintableString 'gov' 6275 : 67 6f 76 6276 0056 31 0d 13: . . . SET 6277 0058 30 0b 11: . . . . SEQUENCE 6278 0060 06 03 3: . . . . . OID 2.5.4.11: OU 6279 : 55 04 0b 6280 0065 13 04 4: . . . . . PrintableString 'nist' 6281 : 6e 69 73 74 6282 0071 30 1e 30: . . SEQUENCE 6283 0073 17 0d 13: . . . UTCTime '970630000000Z' 6284 : 39 37 30 36 33 30 30 30 30 30 30 30 5a 6285 0088 17 0d 13: . . . UTCTime '971231000000Z' 6286 : 39 37 31 32 33 31 30 30 30 30 30 30 5a 6287 0103 30 2a 42: . . SEQUENCE 6288 0105 31 0b 11: . . . SET 6289 0107 30 09 9: . . . . SEQUENCE 6290 0109 06 03 3: . . . . . OID 2.5.4.6: C 6291 : 55 04 06 6292 0114 13 02 2: . . . . . PrintableString 'US' 6293 : 55 53 6294 0118 31 0c 12: . . . SET 6295 0120 30 0a 10: . . . . SEQUENCE 6296 0122 06 03 3: . . . . . OID 2.5.4.10: O 6297 : 55 04 0a 6298 0127 13 03 3: . . . . . PrintableString 'gov' 6299 : 67 6f 76 6300 0132 31 0d 13: . . . SET 6301 0134 30 0b 11: . . . . SEQUENCE 6302 0136 06 03 3: . . . . . OID 2.5.4.11: OU 6303 : 55 04 0b 6304 0141 13 04 4: . . . . . PrintableString 'nist' 6305 : 6e 69 73 74 6306 0147 30 82 01 b4 436: . . SEQUENCE 6307 0151 30 82 01 29 297: . . . SEQUENCE 6308 0155 06 07 7: . . . . OID 1.2.840.10040.4.1: dsa 6309 : 2a 86 48 ce 38 04 01 6310 0164 30 82 01 1c 284: . . . . SEQUENCE 6311 0168 02 81 80 128: . . . . . INTEGER 6312 : d4 38 02 c5 35 7b d5 0b a1 7e 5d 72 59 63 55 d3 6313 : 45 56 ea e2 25 1a 6b c5 a4 ab aa 0b d4 62 b4 d2 6314 : 21 b1 95 a2 c6 01 c9 c3 fa 01 6f 79 86 83 3d 03 6315 : 61 e1 f1 92 ac bc 03 4e 89 a3 c9 53 4a f7 e2 a6 6316 : 48 cf 42 1e 21 b1 5c 2b 3a 7f ba be 6b 5a f7 0a 6317 : 26 d8 8e 1b eb ec bf 1e 5a 3f 45 c0 bd 31 23 be 6318 : 69 71 a7 c2 90 fe a5 d6 80 b5 24 dc 44 9c eb 4d 6319 : f9 da f0 c8 e8 a2 4c 99 07 5c 8e 35 2b 7d 57 8d 6320 0299 02 14 20: . . . . . INTEGER 6321 : a7 83 9b f3 bd 2c 20 07 fc 4c e7 e8 9f f3 39 83 6322 : 51 0d dc dd 6323 0321 02 81 80 128: . . . . . INTEGER 6324 : 0e 3b 46 31 8a 0a 58 86 40 84 e3 a1 22 0d 88 ca 6325 : 90 88 57 64 9f 01 21 e0 15 05 94 24 82 e2 10 90 6326 : d9 e1 4e 10 5c e7 54 6b d4 0c 2b 1b 59 0a a0 b5 6327 : a1 7d b5 07 e3 65 7c ea 90 d8 8e 30 42 e4 85 bb 6328 : ac fa 4e 76 4b 78 0e df 6c e5 a6 e1 bd 59 77 7d 6329 : a6 97 59 c5 29 a7 b3 3f 95 3e 9d f1 59 2d f7 42 6330 : 87 62 3f f1 b8 6f c7 3d 4b b8 8d 74 c4 ca 44 90 6331 : cf 67 db de 14 60 97 4a d1 f7 6d 9e 09 94 c4 0d 6332 0452 03 81 84 132: . . . BIT STRING (0 unused bits) 6333 : 02 81 80 aa 98 ea 13 94 a2 db f1 5b 7f 98 2f 78 6334 : e7 d8 e3 b9 71 86 f6 80 2f 40 39 c3 da 3b 4b 13 6335 : 46 26 ee 0d 56 c5 a3 3a 39 b7 7d 33 c2 6b 5c 77 6336 : 92 f2 55 65 90 39 cd 1a 3c 86 e1 32 eb 25 bc 91 6337 : c4 ff 80 4f 36 61 bd cc e2 61 04 e0 7e 60 13 ca 6338 : c0 9c dd e0 ea 41 de 33 c1 f1 44 a9 bc 71 de cf 6339 : 59 d4 6e da 44 99 3c 21 64 e4 78 54 9d d0 7b ba 6340 : 4e f5 18 4d 5e 39 30 bf e0 d1 f6 f4 83 25 4f 14 6341 : aa 71 e1 6342 0587 a3 32 50: . . [3] 6343 0589 30 30 48: . . . SEQUENCE 6344 0591 30 0f 9: . . . . SEQUENCE 6345 0593 06 03 3: . . . . . OID 2.5.29.19: basicConstraints 6346 : 55 1d 13 6347 0598 01 01 1: . . . . . TRUE 6348 : ff 6350 0601 04 05 5: . . . . . OCTET STRING 6351 : 30 03 01 01 ff 6352 0608 30 1d 29: . SEQUENCE 6353 0610 06 03 3: . . . . . OID 2.5.29.14: subjectKeyIdentifier 6354 : 55 1d 0e 6355 0615 04 16 22: . . . . . OCTET STRING 6356 : 04 14 e7 26 c5 54 cd 5b a3 6f 35 68 95 aa d5 ff 6357 : 1c 21 e4 22 75 d6 6358 0639 30 09 9: . SEQUENCE 6359 0641 06 07 7: . . OID 1.2.840.10040.4.3: dsa-with-sha 6360 : 2a 86 48 ce 38 04 03 6361 0650 03 2f 47: . BIT STRING (0 unused bits) 6362 : 30 2c 02 14 a0 66 c1 76 33 99 13 51 8d 93 64 2f 6363 : ca 13 73 de 79 1a 7d 33 02 14 5d 90 f6 ce 92 4a 6364 : bf 29 11 24 80 28 a6 5a 8e 73 b6 76 02 68 6366 D.2 Certificate 6368 This section contains an annotated hex dump of a 730 byte version 3 6369 certificate. The certificate contains the following information: 6370 (a) the serial number is 18 (12 hex); 6371 (b) the certificate is signed with DSA and the SHA-1 hash algorithm; 6372 (c) the issuer's distinguished name is OU=nist; O=gov; C=US 6373 (d) and the subject's distinguished name is CN=Tim Polk; OU=nist; 6374 O=gov; C=US 6375 (e) the certificate was valid from July 30, 1997 through December 1, 6376 1997; 6377 (f) the certificate contains a 1024 bit DSA public key; 6378 (g) the certificate is an end entity certificate, as the basic con- 6379 straints extension is not present; 6380 (h) the certificate contains an authority key identifier extension; 6381 and 6382 (i) the certificate includes one alternative name - an RFC 822 6383 address. 6385 0000 30 82 02 d6 726: SEQUENCE 6386 0004 30 82 02 96 662: . SEQUENCE 6387 0008 a0 03 3: . . [0] 6388 0010 02 01 1: . . . INTEGER 2 6389 : 02 6390 0013 02 01 1: . . INTEGER 18 6391 : 12 6392 0016 30 09 9: . . SEQUENCE 6393 0018 06 07 7: . . . OID 1.2.840.10040.4.3: dsa-with-sha 6394 : 2a 86 48 ce 38 04 03 6395 0027 30 2a 42: . . SEQUENCE 6396 0029 31 0b 11: . . . SET 6397 0031 30 09 9: . . . . SEQUENCE 6398 0033 06 03 3: . . . . . OID 2.5.4.6: C 6399 : 55 04 06 6400 0038 13 02 2: . . . . . PrintableString 'US' 6401 : 55 53 6402 0042 31 0c 12: . . . SET 6403 0044 30 0a 10: . . . . SEQUENCE 6404 0046 06 03 3: . . . . . OID 2.5.4.10: O 6405 : 55 04 0a 6406 0051 13 03 3: . . . . . PrintableString 'gov' 6407 : 67 6f 76 6408 0056 31 0d 13: . . . SET 6409 0058 30 0b 11: . . . . SEQUENCE 6410 0060 06 03 3: . . . . . OID 2.5.4.11: OU 6411 : 55 04 0b 6412 0065 13 04 4: . . . . . PrintableString 'nist' 6413 : 6e 69 73 74 6414 0071 30 1e 30: . . SEQUENCE 6415 0073 17 0d 13: . . . UTCTime '970730000000Z' 6416 : 39 37 30 37 33 30 30 30 30 30 30 30 5a 6417 0088 17 0d 13: . . . UTCTime '971201000000Z' 6418 : 39 37 31 32 30 31 30 30 30 30 30 30 5a 6419 0103 30 3d 61: . . SEQUENCE 6420 0105 31 0b 11: . . . SET 6421 0107 30 09 9: . . . . SEQUENCE 6422 0109 06 03 3: . . . . . OID 2.5.4.6: C 6423 : 55 04 06 6424 0114 13 02 2: . . . . . PrintableString 'US' 6425 : 55 53 6426 0118 31 0c 12: . . . SET 6427 0120 30 0a 10: . . . . SEQUENCE 6428 0122 06 03 3: . . . . . OID 2.5.4.10: O 6429 : 55 04 0a 6430 0127 13 03 3: . . . . . PrintableString 'gov' 6431 : 67 6f 76 6432 0132 31 0d 13: . . . SET 6433 0134 30 0b 11: . . . . SEQUENCE 6434 0136 06 03 3: . . . . . OID 2.5.4.11: OU 6435 : 55 04 0b 6436 0141 13 04 4: . . . . . PrintableString 'nist' 6437 : 6e 69 73 74 6438 0147 31 11 17: . . . SET 6439 0149 30 0f 15: . . . . SEQUENCE 6440 0151 06 03 3: . . . . . OID 2.5.4.3: CN 6441 : 55 04 03 6442 0156 13 08 8: . . . . . PrintableString 'Tim Polk' 6443 : 54 69 6d 20 50 6f 6c 6b 6444 0166 30 82 01 b4 436: . . SEQUENCE 6445 0170 30 82 01 29 297: . . . SEQUENCE 6446 0174 06 07 7: . . . . OID 1.2.840.10040.4.1: dsa 6447 : 2a 86 48 ce 38 04 01 6448 0183 30 82 01 1c 284: . . . . SEQUENCE 6449 0187 02 81 80 128: . . . . . INTEGER 6450 : d4 38 02 c5 35 7b d5 0b a1 7e 5d 72 59 63 55 d3 6451 : 45 56 ea e2 25 1a 6b c5 a4 ab aa 0b d4 62 b4 d2 6452 : 21 b1 95 a2 c6 01 c9 c3 fa 01 6f 79 86 83 3d 03 6453 : 61 e1 f1 92 ac bc 03 4e 89 a3 c9 53 4a f7 e2 a6 6454 : 48 cf 42 1e 21 b1 5c 2b 3a 7f ba be 6b 5a f7 0a 6455 : 26 d8 8e 1b eb ec bf 1e 5a 3f 45 c0 bd 31 23 be 6456 : 69 71 a7 c2 90 fe a5 d6 80 b5 24 dc 44 9c eb 4d 6457 : f9 da f0 c8 e8 a2 4c 99 07 5c 8e 35 2b 7d 57 8d 6458 0318 02 14 20: . . . . . INTEGER 6459 : a7 83 9b f3 bd 2c 20 07 fc 4c e7 e8 9f f3 39 83 6460 : 51 0d dc dd 6461 0340 02 81 80 128: . . . . . INTEGER 6462 : 0e 3b 46 31 8a 0a 58 86 40 84 e3 a1 22 0d 88 ca 6463 : 90 88 57 64 9f 01 21 e0 15 05 94 24 82 e2 10 90 6464 : d9 e1 4e 10 5c e7 54 6b d4 0c 2b 1b 59 0a a0 b5 6465 : a1 7d b5 07 e3 65 7c ea 90 d8 8e 30 42 e4 85 bb 6466 : ac fa 4e 76 4b 78 0e df 6c e5 a6 e1 bd 59 77 7d 6467 : a6 97 59 c5 29 a7 b3 3f 95 3e 9d f1 59 2d f7 42 6468 : 87 62 3f f1 b8 6f c7 3d 4b b8 8d 74 c4 ca 44 90 6469 : cf 67 db de 14 60 97 4a d1 f7 6d 9e 09 94 c4 0d 6470 0471 03 81 84 132: . . . BIT STRING (0 unused bits) 6471 : 02 81 80 a8 63 b1 60 70 94 7e 0b 86 08 93 0c 0d 6472 : 08 12 4a 58 a9 af 9a 09 38 54 3b 46 82 fb 85 0d 6473 : 18 8b 2a 77 f7 58 e8 f0 1d d2 18 df fe e7 e9 35 6474 : c8 a6 1a db 8d 3d 3d f8 73 14 a9 0b 39 c7 95 f6 6475 : 52 7d 2d 13 8c ae 03 29 3c 4e 8c b0 26 18 b6 d8 6476 : 11 1f d4 12 0c 13 ce 3f f1 c7 05 4e df e1 fc 44 6477 : fd 25 34 19 4a 81 0d dd 98 42 ac d3 b6 91 0c 7f 6478 : 16 72 a3 a0 8a d7 01 7f fb 9c 93 e8 99 92 c8 42 6479 : 47 c6 43 6480 0606 a3 3e 62: . . [3] 6481 0608 30 3c 60: . . . SEQUENCE 6482 0610 30 19 25: . . . . SEQUENCE 6483 0612 06 03 3: . . . . . OID 2.5.29.17: subjectAltName 6484 : 55 1d 11 6485 0617 04 12 18: . . . . . OCTET STRING 6486 : 30 10 81 0e 77 70 6f 6c 6b 40 6e 69 73 74 2e 67 6487 : 6f 76 6488 0637 30 1f 31: . . . . SEQUENCE 6489 0639 06 03 3: . . . . . OID 2.5.29.35: subjectAltName 6490 : 55 1d 23 6491 0644 04 18 24: . . . . . OCTET STRING 6492 : 30 16 80 14 e7 26 c5 54 cd 5b a3 6f 35 68 95 aa 6493 : d5 ff 1c 21 e4 22 75 d6 6495 0670 30 09 9: . SEQUENCE 6496 0672 06 07 7: . . OID 1.2.840.10040.4.3: dsa-with-sha 6497 : 2a 86 48 ce 38 04 03 6498 0681 03 2f 47: . BIT STRING (0 unused bits) 6499 : 30 2c 02 14 3c 02 e0 ab d9 5d 05 77 75 15 71 58 6500 : 92 29 48 c4 1c 54 df fc 02 14 5b da 53 98 7f c5 6501 : 33 df c6 09 b2 7a e3 6f 97 70 1e 14 ed 94 6503 D.3 End-Entity Certificate Using RSA 6505 This section contains an annotated hex dump of a 675 byte version 3 6506 certificate. The certificate contains the following information: 6507 (a) the serial number is 256; 6508 (b) the certificate is signed with RSA and the MD2 hash algorithm; 6509 (c) the issuer's distinguished name is OU=Dept. Arquitectura de Com- 6510 putadors; O=Universitat Politecnica de Catalunya; C=ES 6511 (d) and the subject's distinguished name is CN=Francisco Jordan; 6512 OU=Dept. Arquitectura de Computadors; O=Universitat Politecnica de 6513 Catalunya; C=ES 6514 (e) the certificate was issued on May 21, 1996 and expired on May 21, 6515 1997; 6516 (f) the certificate contains a 768 bit RSA public key; 6517 (g) the certificate is an end entity certificate (not a CA certifi- 6518 cate); 6519 (h) the certificate includes an alternative subject name and an 6520 alternative issuer name - bothe are URLs; 6521 (i) the certificate include an authority key identifier and certifi- 6522 cate policies extensions; and 6523 (j) the certificate includes a critical key usage extension specify- 6524 ing the public is intended for generation of digital signatures. 6526 0000 30 80 : SEQUENCE (size undefined) 6527 0002 30 82 02 40 576: . SEQUENCE 6528 0006 a0 03 3: . . [0] 6529 0008 02 01 1: . . . INTEGER 2 6530 : 02 6531 0011 02 02 2: . . INTEGER 256 6532 : 01 00 6533 0015 30 0d 13: . . SEQUENCE 6534 0017 06 09 9: . . . OID 1.2.840.113549.1.1.2: 6535 MD2WithRSAEncryption 6536 : 2a 86 48 86 f7 0d 01 01 02 6537 0028 05 00 0: . . . NULL 6538 0030 30 68 88: . . SEQUENCE 6539 0032 31 0b 11: . . . SET 6540 0034 30 09 9: . . . . SEQUENCE 6541 0036 06 03 3: . . . . . OID 2.5.4.6: C 6542 : 55 04 06 6544 0041 13 02 2: . . . . . PrintableString 'ES' 6545 : 45 53 6546 0045 31 2d 45: . . . SET 6547 0047 30 2b 43: . . . . SEQUENCE 6548 0049 06 03 3: . . . . . OID 2.5.4.10: O 6549 : 55 04 0a 6550 0054 13 24 36: . . . . . PrintableString 6551 'Universitat Politecnica de Catalunya' 6552 : 55 6e 69 76 65 72 73 69 74 61 74 20 50 6f 6c 69 6553 : 74 65 63 6e 69 63 61 20 64 65 20 43 61 74 61 6c 6554 : 75 6e 79 61 6555 0092 31 2a 42: . . . SET 6556 0094 30 28 40: . . . . SEQUENCE 6557 0096 06 03 3: . . . . . OID 2.5.4.11: OU 6558 : 55 04 0b 6559 0101 13 21 33: . . . . . PrintableString 6560 'OU=Dept. Arquitectura de Computadors' 6561 : 44 65 70 74 2e 20 41 72 71 75 69 74 65 63 74 75 6562 : 72 61 20 64 65 20 43 6f 6d 70 75 74 61 64 6f 72 6563 : 73 6564 0136 30 1e 30: . . SEQUENCE 6565 0138 17 0d 13: . . . UTCTime '960521095826Z' 6566 : 39 36 30 37 32 32 31 37 33 38 30 32 5a 6567 0153 17 0d 13: . . . UTCTime '979521095826Z' 6568 : 39 37 30 37 32 32 31 37 33 38 30 32 5a 6569 0168 30 81 83 112: . . SEQUENCE 6570 0171 31 0b 11: . . . SET 6571 0173 30 09 9: . . . . SEQUENCE 6572 0175 06 03 3: . . . . . OID 2.5.4.6: C 6573 : 55 04 06 6574 0180 13 02 2: . . . . . PrintableString 'ES' 6575 : 45 53 6576 0184 31 2d 12: . . . SET 6577 0186 30 2b 16: . . . . SEQUENCE 6578 0188 06 03 3: . . . . . OID 2.5.4.10: O 6579 : 55 04 0a 6580 0193 13 24 36: . . . . . PrintableString 6581 'Universitat Politecnica de Catalunya' 6582 : 55 6e 69 76 65 72 73 69 74 61 74 20 50 6f 6c 69 6583 : 74 65 63 6e 69 63 61 20 64 65 20 43 61 74 61 6c 6584 : 75 6e 79 61 6585 0231 31 2a 42: . . . SET 6586 0233 30 28 40: . . . . SEQUENCE 6587 0235 06 03 3: . . . . . OID 2.5.4.11: OU 6588 : 55 04 0b 6589 0240 13 21 33: . . . . . PrintableString 6590 'Dept. Arquitectura de Computadors' 6591 : 44 65 70 74 2e 20 41 72 71 75 69 74 65 63 74 75 6592 : 72 61 20 64 65 20 43 6f 6d 70 75 74 61 64 6f 72 6593 : 73 6594 0275 31 19 22: . . . SET 6595 0277 30 17 20: . . . . SEQUENCE 6596 0279 06 03 3: . . . . . OID 2.5.4.3: CN 6597 : 55 04 03 6598 0284 13 10 16: . . . . . PrintableString 'Francisco Jordan' 6599 : 46 72 61 6e 63 69 73 63 6f 20 4a 6f 72 64 61 6e 6600 0302 30 7c 2: . . SEQUENCE 6601 0304 30 0d 13: . . . SEQUENCE 6602 0306 06 09 9: . . . . OID 1.2.840.113549.1.1.1: RSAEncryption 6603 : 2a 86 48 86 f7 0d 01 01 01 6604 0317 05 00 0: . . . . NULL 6605 0319 03 6b 107: . . . BIT STRING 6606 : 00 (0 unused bits) 6607 : 30 68 02 61 00 be aa 8b 77 54 a3 af ca 77 9f 2f 6608 : b0 cf 43 88 ff a6 6d 79 55 5b 61 8c 68 ec 48 1e 6609 : 8a 86 38 a4 fe 19 b8 62 17 1d 9d 0f 47 2c ff 63 6610 : 8f 29 91 04 d1 52 bc 7f 67 b6 b2 8f 74 55 c1 33 6611 : 21 6c 8f ab 01 95 24 c8 b2 73 93 9d 22 61 50 a9 6612 : 35 fb 9d 57 50 32 ef 56 52 50 93 ab b1 88 94 78 6613 : 56 15 c6 1c 8b 02 03 01 00 01 6614 0428 a3 81 97 151: . . [3] 6615 0431 30 3c 60: . . . SEQUENCE 6616 0433 30 1f 31: . . . . SEQUENCE 6617 0435 06 03 3: . . . . . OID 2.5.29.35: authorityKeyIdentifier 6618 : 55 1d 23 6619 0440 04 14 22: . . . . . OCTET STRING 6620 : 30 12 80 10 0e 6b 3a bf 04 ea 04 c3 0e 6b 3a bf 6621 : 04 ea 04 c3 6622 0464 30 19 25: . . . . SEQUENCE 6623 0466 06 03 3: . . . . . OID 2.5.29.15: keyUsage 6624 : 55 1d 0f 6625 0471 01 01 1: . . . . . TRUE 6626 0474 04 04 4: . . . . . OCTET STRING 6627 : 03 02 07 80 6628 0480 30 19 25: . . . . SEQUENCE 6629 0482 06 03 3: . . . . . OID 2.5.29.32: certificatePolicies 6630 : 55 1d 20 6631 0487 04 21 33: . . . . . OCTET STRING 6632 : 30 1f 30 1d 06 04 2a 84 80 00 30 15 30 07 06 05 6633 : 2a 84 80 00 01 30 0a 06 05 2a 84 80 00 02 02 01 6634 : 0a 6635 0522 30 1c 28: . . . . SEQUENCE 6636 0524 06 03 3: . . . . . OID 2.5.29.17: subjectAltName 6637 : 55 1d 11 6638 0529 04 15 21: . . . . . OCTET STRING 6639 : 30 13 86 11 68 74 74 70 3a 2f 2f 61 63 2e 75 70 6640 : 63 2e 65 73 2f 6641 0552 30 19 25: . . . . SEQUENCE 6642 0554 06 03 3: . . . . . OID 2.5.29.18: issuerAltName 6643 : 55 1d 12 6644 0559 04 12 18: . . . . . OCTET STRING 6645 : 30 14 86 12 68 74 74 70 3a 2f 2f 77 77 77 2e 75 6646 : 70 63 2e 65 6647 0579 30 80 : . SEQUENCE (indefinite length) 6648 0581 06 07 7: . . OID 6649 0583 05 00 0: . . NULL 6650 0585 00 00 0: . . end of contents marker 6651 0587 03 81 81 47: . BIT STRING 6652 : 00 (0 unused bits) 6653 : 5c 01 bd b5 41 88 87 7a 0e d3 0e 6b 3a bf 04 ea 6654 : 04 cb 5f 61 72 3c a3 bd 78 f5 66 17 fe 37 3a ab 6655 : eb 67 bf b7 da a8 38 f6 33 15 71 75 2f b9 8c 91 6656 : a0 e4 87 ba 4b 43 a0 22 8f d3 a9 86 43 89 e6 50 6657 : 5c 01 bd b5 41 88 87 7a 0e d3 0e 6b 3a bf 04 ea 6658 : 04 cb 5f 61 72 3c a3 bd 78 f5 66 17 fe 37 3a ab 6659 : eb 67 bf b7 da a8 38 f6 33 15 71 75 2f b9 8c 91 6660 : a0 e4 87 ba 4b 43 a0 22 8f d3 a9 86 43 89 e6 50 6661 0637 00 00 0: . . end of contents marker 6663 D.4 Certificate Revocation List 6665 This section contains an annotated hex dump of a version 2 CRL with 6666 one extension (cRLNumber). The CRL was issued by OU=nist;O=gov;C=us 6667 on July 7, 1996; the next scheduled issuance was August 7, 1996. The 6668 CRL includes one revoked certificates: serial number 18 (12 hex). 6669 The CRL itself is number 18, and it was signed with DSA and SHA-1. 6671 0000 30 81 ba 186: SEQUENCE 6672 0003 30 7c 124: . SEQUENCE 6673 0005 02 01 1: . . INTEGER 1 6674 : 01 6675 0008 30 09 9: . . SEQUENCE 6676 0010 06 07 7: . . . OID 1.2.840.10040.4.3: dsa-with-sha 6677 : 2a 86 48 ce 38 04 03 6678 0019 30 2a 42: . . SEQUENCE 6679 0021 31 0b 11: . . . SET 6680 0023 30 09 9: . . . . SEQUENCE 6681 0025 06 03 3: . . . . . OID 2.5.4.6: C 6682 : 55 04 06 6683 0030 13 02 2: . . . . . PrintableString 'US' 6684 : 55 53 6685 0034 31 0c 12: . . . SET 6686 0036 30 0a 10: . . . . SEQUENCE 6687 0038 06 03 3: . . . . . OID 2.5.4.10: O 6688 : 55 04 0a 6689 0043 13 03 3: . . . . . PrintableString 'gov' 6690 : 67 6f 76 6691 0048 31 0d 13: . . . SET 6692 0050 30 0b 11: . . . . SEQUENCE 6693 0052 06 03 3: . . . . . OID 2.5.4.11: OU 6694 : 55 04 0b 6695 0057 13 04 4: . . . . . PrintableString 'nist' 6696 : 6e 69 73 74 6697 0063 17 0d 13: . . UTCTime '970801000000Z' 6698 : 39 37 30 38 30 31 30 30 30 30 30 30 5a 6699 0078 17 0d 13: . . UTCTime '970808000000Z' 6700 : 39 37 30 38 30 38 30 30 30 30 30 30 5a 6701 0093 30 22 34: . . SEQUENCE 6702 0095 30 20 32: . . . SEQUENCE 6703 0097 02 01 1: . . . . INTEGER 18 6704 : 12 6705 0100 17 0d 13: . . . . UTCTime '970731000000Z' 6706 : 39 37 30 37 33 31 30 30 30 30 30 30 5a 6707 0115 30 0c 12: . . . . SEQUENCE 6708 0117 30 0a 10: . . . . . SEQUENCE 6709 0119 06 03 3: . . . . . . OID 2.5.29.21: reasonCode 6710 : 55 1d 15 6711 0124 04 03 3: . . . . . . OCTET STRING 6712 : 0a 01 01 6713 0129 30 09 9: . SEQUENCE 6714 0131 06 07 7: . . OID 1.2.840.10040.4.3: dsa-with-sha 6715 : 2a 86 48 ce 38 04 03 6716 0140 03 2f 47: . BIT STRING (0 unused bits) 6717 : 30 2c 02 14 9e d8 6b c1 7d c2 c4 02 f5 17 84 f9 6718 : 9f 46 7a ca cf b7 05 8a 02 14 9e 43 39 85 dc ea 6719 : 14 13 72 93 54 5d 44 44 e5 05 fe 73 9a b2 6721 Appendix E. Author Addresses: 6723 Russell Housley 6724 SPYRUS 6725 381 Elden Street 6726 Suite 1120 6727 Herndon, VA 20170 6728 USA 6729 housley@spyrus.com 6731 Warwick Ford 6732 VeriSign, Inc. 6733 One Alewife Center 6734 Cambridge, MA 02140 6735 USA 6736 wford@verisign.com 6738 Tim Polk 6739 NIST 6740 Building 820, Room 426 6741 Gaithersburg, MD 20899 6742 USA 6743 wpolk@nist.gov 6745 David Solo 6746 Citicorp 6747 666 Fifth Ave, 3rd Floor 6748 New York, NY 10103 6749 USA 6750 david.solo@citicorp.com 6752 Appendix F. Full Copyright Statement 6754 Copyright (C) The Internet Society (date). All Rights Reserved. 6756 This document and translations of it may be copied and furnished to 6757 others, and derivative works that comment on or otherwise explain it 6758 or assist in its implementation may be prepared, copied, published 6759 and distributed, in whole or in part, without restriction of any 6760 kind, provided that the above copyright notice and this paragraph are 6761 included on all such copies and derivative works. In addition, the 6762 ASN.1 modules presented in Appendices A and B may be used in whole or 6763 in part without inclusion of the copyright notice. However, this 6764 document itself may not be modified in any way, such as by removing 6765 the copyright notice or references to the Internet Society or other 6766 Internet organizations, except as needed for the purpose of develop- 6767 ing Internet standards in which case the procedures for copyrights 6768 defined in the Internet Standards process shall be followed, or as 6769 required to translate it into languages other than English. 6771 The limited permissions granted above are perpetual and will not be 6772 revoked by the Internet Society or its successors or assigns. This 6773 document and the information contained herein is provided on an "AS 6774 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 6775 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 6776 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 6777 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 6778 OR FITNESS FOR A PARTICULAR PURPOSE.