1 2 3 4 5 6 7Network Working Group R. Housley 8Request for Comments: 3280 RSA Laboratories 9Obsoletes: 2459 W. Polk 10Category: Standards Track NIST 11 W. Ford 12 VeriSign 13 D. Solo 14 Citigroup 15 April 2002 16 17 Internet X.509 Public Key Infrastructure 18 Certificate and Certificate Revocation List (CRL) Profile 19 20Status of this Memo 21 22 This document specifies an Internet standards track protocol for the 23 Internet community, and requests discussion and suggestions for 24 improvements. Please refer to the current edition of the "Internet 25 Official Protocol Standards" (STD 1) for the standardization state 26 and status of this protocol. Distribution of this memo is unlimited. 27 28Copyright Notice 29 30 Copyright (C) The Internet Society (2002). All Rights Reserved. 31 32Abstract 33 34 This memo profiles the X.509 v3 certificate and X.509 v2 Certificate 35 Revocation List (CRL) for use in the Internet. An overview of this 36 approach and model are provided as an introduction. The X.509 v3 37 certificate format is described in detail, with additional 38 information regarding the format and semantics of Internet name 39 forms. Standard certificate extensions are described and two 40 Internet-specific extensions are defined. A set of required 41 certificate extensions is specified. The X.509 v2 CRL format is 42 described in detail, and required extensions are defined. An 43 algorithm for X.509 certification path validation is described. An 44 ASN.1 module and examples are provided in the appendices. 45 46Table of Contents 47 48 1 Introduction . . . . . . . . . . . . . . . . . . . . . . 4 49 2 Requirements and Assumptions . . . . . . . . . . . . . . 5 50 2.1 Communication and Topology . . . . . . . . . . . . . . 6 51 2.2 Acceptability Criteria . . . . . . . . . . . . . . . . 6 52 2.3 User Expectations . . . . . . . . . . . . . . . . . . . 7 53 2.4 Administrator Expectations . . . . . . . . . . . . . . 7 54 3 Overview of Approach . . . . . . . . . . . . . . . . . . 7 55 56 57 58Housley, et. al. Standards Track [Page 1] 59 60RFC 3280 Internet X.509 Public Key Infrastructure April 2002 61 62 63 3.1 X.509 Version 3 Certificate . . . . . . . . . . . . . . 8 64 3.2 Certification Paths and Trust . . . . . . . . . . . . . 9 65 3.3 Revocation . . . . . . . . . . . . . . . . . . . . . . 11 66 3.4 Operational Protocols . . . . . . . . . . . . . . . . . 13 67 3.5 Management Protocols . . . . . . . . . . . . . . . . . 13 68 4 Certificate and Certificate Extensions Profile . . . . . 14 69 4.1 Basic Certificate Fields . . . . . . . . . . . . . . . 15 70 4.1.1 Certificate Fields . . . . . . . . . . . . . . . . . 16 71 4.1.1.1 tbsCertificate . . . . . . . . . . . . . . . . . . 16 72 4.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . 16 73 4.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . 16 74 4.1.2 TBSCertificate . . . . . . . . . . . . . . . . . . . 17 75 4.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . 17 76 4.1.2.2 Serial number . . . . . . . . . . . . . . . . . . . 17 77 4.1.2.3 Signature . . . . . . . . . . . . . . . . . . . . . 18 78 4.1.2.4 Issuer . . . . . . . . . . . . . . . . . . . . . . 18 79 4.1.2.5 Validity . . . . . . . . . . . . . . . . . . . . . 22 80 4.1.2.5.1 UTCTime . . . . . . . . . . . . . . . . . . . . . 22 81 4.1.2.5.2 GeneralizedTime . . . . . . . . . . . . . . . . . 22 82 4.1.2.6 Subject . . . . . . . . . . . . . . . . . . . . . . 23 83 4.1.2.7 Subject Public Key Info . . . . . . . . . . . . . . 24 84 4.1.2.8 Unique Identifiers . . . . . . . . . . . . . . . . 24 85 4.1.2.9 Extensions . . . . . . . . . . . . . . . . . . . . . 24 86 4.2 Certificate Extensions . . . . . . . . . . . . . . . . 24 87 4.2.1 Standard Extensions . . . . . . . . . . . . . . . . . 25 88 4.2.1.1 Authority Key Identifier . . . . . . . . . . . . . 26 89 4.2.1.2 Subject Key Identifier . . . . . . . . . . . . . . 27 90 4.2.1.3 Key Usage . . . . . . . . . . . . . . . . . . . . . 28 91 4.2.1.4 Private Key Usage Period . . . . . . . . . . . . . 29 92 4.2.1.5 Certificate Policies . . . . . . . . . . . . . . . 30 93 4.2.1.6 Policy Mappings . . . . . . . . . . . . . . . . . . 33 94 4.2.1.7 Subject Alternative Name . . . . . . . . . . . . . 33 95 4.2.1.8 Issuer Alternative Name . . . . . . . . . . . . . . 36 96 4.2.1.9 Subject Directory Attributes . . . . . . . . . . . 36 97 4.2.1.10 Basic Constraints . . . . . . . . . . . . . . . . 36 98 4.2.1.11 Name Constraints . . . . . . . . . . . . . . . . . 37 99 4.2.1.12 Policy Constraints . . . . . . . . . . . . . . . . 40 100 4.2.1.13 Extended Key Usage . . . . . . . . . . . . . . . . 40 101 4.2.1.14 CRL Distribution Points . . . . . . . . . . . . . 42 102 4.2.1.15 Inhibit Any-Policy . . . . . . . . . . . . . . . . 44 103 4.2.1.16 Freshest CRL . . . . . . . . . . . . . . . . . . . 44 104 4.2.2 Internet Certificate Extensions . . . . . . . . . . . 45 105 4.2.2.1 Authority Information Access . . . . . . . . . . . 45 106 4.2.2.2 Subject Information Access . . . . . . . . . . . . 46 107 5 CRL and CRL Extensions Profile . . . . . . . . . . . . . 48 108 5.1 CRL Fields . . . . . . . . . . . . . . . . . . . . . . 49 109 5.1.1 CertificateList Fields . . . . . . . . . . . . . . . 50 110 5.1.1.1 tbsCertList . . . . . . . . . . . . . . . . . . . . 50 111 112 113 114Housley, et. al. Standards Track [Page 2] 115 116RFC 3280 Internet X.509 Public Key Infrastructure April 2002 117 118 119 5.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . 50 120 5.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . 51 121 5.1.2 Certificate List "To Be Signed" . . . . . . . . . . . 51 122 5.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . 52 123 5.1.2.2 Signature . . . . . . . . . . . . . . . . . . . . . 52 124 5.1.2.3 Issuer Name . . . . . . . . . . . . . . . . . . . . 52 125 5.1.2.4 This Update . . . . . . . . . . . . . . . . . . . . 52 126 5.1.2.5 Next Update . . . . . . . . . . . . . . . . . . . . 53 127 5.1.2.6 Revoked Certificates . . . . . . . . . . . . . . . 53 128 5.1.2.7 Extensions . . . . . . . . . . . . . . . . . . . . 53 129 5.2 CRL Extensions . . . . . . . . . . . . . . . . . . . . 53 130 5.2.1 Authority Key Identifier . . . . . . . . . . . . . . 54 131 5.2.2 Issuer Alternative Name . . . . . . . . . . . . . . . 54 132 5.2.3 CRL Number . . . . . . . . . . . . . . . . . . . . . 55 133 5.2.4 Delta CRL Indicator . . . . . . . . . . . . . . . . . 55 134 5.2.5 Issuing Distribution Point . . . . . . . . . . . . . 58 135 5.2.6 Freshest CRL . . . . . . . . . . . . . . . . . . . . 59 136 5.3 CRL Entry Extensions . . . . . . . . . . . . . . . . . 60 137 5.3.1 Reason Code . . . . . . . . . . . . . . . . . . . . . 60 138 5.3.2 Hold Instruction Code . . . . . . . . . . . . . . . . 61 139 5.3.3 Invalidity Date . . . . . . . . . . . . . . . . . . . 62 140 5.3.4 Certificate Issuer . . . . . . . . . . . . . . . . . 62 141 6 Certificate Path Validation . . . . . . . . . . . . . . . 62 142 6.1 Basic Path Validation . . . . . . . . . . . . . . . . . 63 143 6.1.1 Inputs . . . . . . . . . . . . . . . . . . . . . . . 66 144 6.1.2 Initialization . . . . . . . . . . . . . . . . . . . 67 145 6.1.3 Basic Certificate Processing . . . . . . . . . . . . 70 146 6.1.4 Preparation for Certificate i+1 . . . . . . . . . . . 75 147 6.1.5 Wrap-up procedure . . . . . . . . . . . . . . . . . . 78 148 6.1.6 Outputs . . . . . . . . . . . . . . . . . . . . . . . 80 149 6.2 Extending Path Validation . . . . . . . . . . . . . . . 80 150 6.3 CRL Validation . . . . . . . . . . . . . . . . . . . . 81 151 6.3.1 Revocation Inputs . . . . . . . . . . . . . . . . . . 82 152 6.3.2 Initialization and Revocation State Variables . . . . 82 153 6.3.3 CRL Processing . . . . . . . . . . . . . . . . . . . 83 154 7 References . . . . . . . . . . . . . . . . . . . . . . . 86 155 8 Intellectual Property Rights . . . . . . . . . . . . . . 88 156 9 Security Considerations . . . . . . . . . . . . . . . . . 89 157 Appendix A. ASN.1 Structures and OIDs . . . . . . . . . . . 92 158 A.1 Explicitly Tagged Module, 1988 Syntax . . . . . . . . . 92 159 A.2 Implicitly Tagged Module, 1988 Syntax . . . . . . . . . 105 160 Appendix B. ASN.1 Notes . . . . . . . . . . . . . . . . . . 112 161 Appendix C. Examples . . . . . . . . . . . . . . . . . . . 115 162 C.1 DSA Self-Signed Certificate . . . . . . . . . . . . . . 115 163 C.2 End Entity Certificate Using DSA . . . . . . . . . . . 119 164 C.3 End Entity Certificate Using RSA . . . . . . . . . . . 122 165 C.4 Certificate Revocation List . . . . . . . . . . . . . . 126 166 Author Addresses . . . . . . . . . . . . . . . . . . . . . . 128 167 168 169 170Housley, et. al. Standards Track [Page 3] 171 172RFC 3280 Internet X.509 Public Key Infrastructure April 2002 173 174 175 Full Copyright Statement . . . . . . . . . . . . . . . . . . 129 176 1771 Introduction 178 179 This specification is one part of a family of standards for the X.509 180 Public Key Infrastructure (PKI) for the Internet. 181 182 This specification profiles the format and semantics of certificates 183 and certificate revocation lists (CRLs) for the Internet PKI. 184 Procedures are described for processing of certification paths in the 185 Internet environment. Finally, ASN.1 modules are provided in the 186 appendices for all data structures defined or referenced. 187 188 Section 2 describes Internet PKI requirements, and the assumptions 189 which affect the scope of this document. Section 3 presents an 190 architectural model and describes its relationship to previous IETF 191 and ISO/IEC/ITU-T standards. In particular, this document's 192 relationship with the IETF PEM specifications and the ISO/IEC/ITU-T 193 X.509 documents are described. 194 195 Section 4 profiles the X.509 version 3 certificate, and section 5 196 profiles the X.509 version 2 CRL. The profiles include the 197 identification of ISO/IEC/ITU-T and ANSI extensions which may be 198 useful in the Internet PKI. The profiles are presented in the 1988 199 Abstract Syntax Notation One (ASN.1) rather than the 1997 ASN.1 200 syntax used in the most recent ISO/IEC/ITU-T standards. 201 202 Section 6 includes certification path validation procedures. These 203 procedures are based upon the ISO/IEC/ITU-T definition. 204 Implementations are REQUIRED to derive the same results but are not 205 required to use the specified procedures. 206 207 Procedures for identification and encoding of public key materials 208 and digital signatures are defined in [PKIXALGS]. Implementations of 209 this specification are not required to use any particular 210 cryptographic algorithms. However, conforming implementations which 211 use the algorithms identified in [PKIXALGS] MUST identify and encode 212 the public key materials and digital signatures as described in that 213 specification. 214 215 Finally, three appendices are provided to aid implementers. Appendix 216 A contains all ASN.1 structures defined or referenced within this 217 specification. As above, the material is presented in the 1988 218 ASN.1. Appendix B contains notes on less familiar features of the 219 ASN.1 notation used within this specification. Appendix C contains 220 examples of a conforming certificate and a conforming CRL. 221 222 223 224 225 226Housley, et. al. Standards Track [Page 4] 227 228RFC 3280 Internet X.509 Public Key Infrastructure April 2002 229 230 231 This specification obsoletes RFC 2459. This specification differs 232 from RFC 2459 in five basic areas: 233 234 * To promote interoperable implementations, a detailed algorithm 235 for certification path validation is included in section 6.1 of 236 this specification; RFC 2459 provided only a high-level 237 description of path validation. 238 239 * An algorithm for determining the status of a certificate using 240 CRLs is provided in section 6.3 of this specification. This 241 material was not present in RFC 2459. 242 243 * To accommodate new usage models, detailed information describing 244 the use of delta CRLs is provided in Section 5 of this 245 specification. 246 247 * Identification and encoding of public key materials and digital 248 signatures are not included in this specification, but are now 249 described in a companion specification [PKIXALGS]. 250 251 * Four additional extensions are specified: three certificate 252 extensions and one CRL extension. The certificate extensions are 253 subject info access, inhibit any-policy, and freshest CRL. The 254 freshest CRL extension is also defined as a CRL extension. 255 256 * Throughout the specification, clarifications have been 257 introduced to enhance consistency with the ITU-T X.509 258 specification. X.509 defines the certificate and CRL format as 259 well as many of the extensions that appear in this specification. 260 These changes were introduced to improve the likelihood of 261 interoperability between implementations based on this 262 specification with implementations based on the ITU-T 263 specification. 264 265 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 266 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 267 document are to be interpreted as described in RFC 2119. 268 2692 Requirements and Assumptions 270 271 The goal of this specification is to develop a profile to facilitate 272 the use of X.509 certificates within Internet applications for those 273 communities wishing to make use of X.509 technology. Such 274 applications may include WWW, electronic mail, user authentication, 275 and IPsec. In order to relieve some of the obstacles to using X.509 276 277 278 279 280 281 282Housley, et. al. Standards Track [Page 5] 283 284RFC 3280 Internet X.509 Public Key Infrastructure April 2002 285 286 287 certificates, this document defines a profile to promote the 288 development of certificate management systems; development of 289 application tools; and interoperability determined by policy. 290 291 Some communities will need to supplement, or possibly replace, this 292 profile in order to meet the requirements of specialized application 293 domains or environments with additional authorization, assurance, or 294 operational requirements. However, for basic applications, common 295 representations of frequently used attributes are defined so that 296 application developers can obtain necessary information without 297 regard to the issuer of a particular certificate or certificate 298 revocation list (CRL). 299 300 A certificate user should review the certificate policy generated by 301 the certification authority (CA) before relying on the authentication 302 or non-repudiation services associated with the public key in a 303 particular certificate. To this end, this standard does not 304 prescribe legally binding rules or duties. 305 306 As supplemental authorization and attribute management tools emerge, 307 such as attribute certificates, it may be appropriate to limit the 308 authenticated attributes that are included in a certificate. These 309 other management tools may provide more appropriate methods of 310 conveying many authenticated attributes. 311 3122.1 Communication and Topology 313 314 The users of certificates will operate in a wide range of 315 environments with respect to their communication topology, especially 316 users of secure electronic mail. This profile supports users without 317 high bandwidth, real-time IP connectivity, or high connection 318 availability. In addition, the profile allows for the presence of 319 firewall or other filtered communication. 320 321 This profile does not assume the deployment of an X.500 Directory 322 system or a LDAP directory system. The profile does not prohibit the 323 use of an X.500 Directory or a LDAP directory; however, any means of 324 distributing certificates and certificate revocation lists (CRLs) may 325 be used. 326 3272.2 Acceptability Criteria 328 329 The goal of the Internet Public Key Infrastructure (PKI) is to meet 330 the needs of deterministic, automated identification, authentication, 331 access control, and authorization functions. Support for these 332 services determines the attributes contained in the certificate as 333 well as the ancillary control information in the certificate such as 334 policy data and certification path constraints. 335 336 337 338Housley, et. al. Standards Track [Page 6] 339 340RFC 3280 Internet X.509 Public Key Infrastructure April 2002 341 342 3432.3 User Expectations 344 345 Users of the Internet PKI are people and processes who use client 346 software and are the subjects named in certificates. These uses 347 include readers and writers of electronic mail, the clients for WWW 348 browsers, WWW servers, and the key manager for IPsec within a router. 349 This profile recognizes the limitations of the platforms these users 350 employ and the limitations in sophistication and attentiveness of the 351 users themselves. This manifests itself in minimal user 352 configuration responsibility (e.g., trusted CA keys, rules), explicit 353 platform usage constraints within the certificate, certification path 354 constraints which shield the user from many malicious actions, and 355 applications which sensibly automate validation functions. 356 3572.4 Administrator Expectations 358 359 As with user expectations, the Internet PKI profile is structured to 360 support the individuals who generally operate CAs. Providing 361 administrators with unbounded choices increases the chances that a 362 subtle CA administrator mistake will result in broad compromise. 363 Also, unbounded choices greatly complicate the software that process 364 and validate the certificates created by the CA. 365 3663 Overview of Approach 367 368 Following is a simplified view of the architectural model assumed by 369 the PKIX specifications. 370 371 The components in this model are: 372 373 end entity: user of PKI certificates and/or end user system that is 374 the subject of a certificate; 375 CA: certification authority; 376 RA: registration authority, i.e., an optional system to which 377 a CA delegates certain management functions; 378 CRL issuer: an optional system to which a CA delegates the 379 publication of certificate revocation lists; 380 repository: a system or collection of distributed systems that stores 381 certificates and CRLs and serves as a means of 382 distributing these certificates and CRLs to end entities. 383 384 Note that an Attribute Authority (AA) might also choose to delegate 385 the publication of CRLs to a CRL issuer. 386 387 388 389 390 391 392 393 394Housley, et. al. Standards Track [Page 7] 395 396RFC 3280 Internet X.509 Public Key Infrastructure April 2002 397 398 399 +---+ 400 | C | +------------+ 401 | e | <-------------------->| End entity | 402 | r | Operational +------------+ 403 | t | transactions ^ 404 | i | and management | Management 405 | f | transactions | transactions PKI 406 | i | | users 407 | c | v 408 | a | ======================= +--+------------+ ============== 409 | t | ^ ^ 410 | e | | | PKI 411 | | v | management 412 | & | +------+ | entities 413 | | <---------------------| RA |<----+ | 414 | C | Publish certificate +------+ | | 415 | R | | | 416 | L | | | 417 | | v v 418 | R | +------------+ 419 | e | <------------------------------| CA | 420 | p | Publish certificate +------------+ 421 | o | Publish CRL ^ ^ 422 | s | | | Management 423 | i | +------------+ | | transactions 424 | t | <--------------| CRL Issuer |<----+ | 425 | o | Publish CRL +------------+ v 426 | r | +------+ 427 | y | | CA | 428 +---+ +------+ 429 430 Figure 1 - PKI Entities 431 4323.1 X.509 Version 3 Certificate 433 434 Users of a public key require confidence that the associated private 435 key is owned by the correct remote subject (person or system) with 436 which an encryption or digital signature mechanism will be used. 437 This confidence is obtained through the use of public key 438 certificates, which are data structures that bind public key values 439 to subjects. The binding is asserted by having a trusted CA 440 digitally sign each certificate. The CA may base this assertion upon 441 technical means (a.k.a., proof of possession through a challenge- 442 response protocol), presentation of the private key, or on an 443 assertion by the subject. A certificate has a limited valid lifetime 444 which is indicated in its signed contents. Because a certificate's 445 signature and timeliness can be independently checked by a 446 certificate-using client, certificates can be distributed via 447 448 449 450Housley, et. al. Standards Track [Page 8] 451 452RFC 3280 Internet X.509 Public Key Infrastructure April 2002 453 454 455 untrusted communications and server systems, and can be cached in 456 unsecured storage in certificate-using systems. 457 458 ITU-T X.509 (formerly CCITT X.509) or ISO/IEC 9594-8, which was first 459 published in 1988 as part of the X.500 Directory recommendations, 460 defines a standard certificate format [X.509]. The certificate 461 format in the 1988 standard is called the version 1 (v1) format. 462 When X.500 was revised in 1993, two more fields were added, resulting 463 in the version 2 (v2) format. 464 465 The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993, 466 include specifications for a public key infrastructure based on X.509 467 v1 certificates [RFC 1422]. The experience gained in attempts to 468 deploy RFC 1422 made it clear that the v1 and v2 certificate formats 469 are deficient in several respects. Most importantly, more fields 470 were needed to carry information which PEM design and implementation 471 experience had proven necessary. In response to these new 472 requirements, ISO/IEC, ITU-T and ANSI X9 developed the X.509 version 473 3 (v3) certificate format. The v3 format extends the v2 format by 474 adding provision for additional extension fields. Particular 475 extension field types may be specified in standards or may be defined 476 and registered by any organization or community. In June 1996, 477 standardization of the basic v3 format was completed [X.509]. 478 479 ISO/IEC, ITU-T, and ANSI X9 have also developed standard extensions 480 for use in the v3 extensions field [X.509][X9.55]. These extensions 481 can convey such data as additional subject identification 482 information, key attribute information, policy information, and 483 certification path constraints. 484 485 However, the ISO/IEC, ITU-T, and ANSI X9 standard extensions are very 486 broad in their applicability. In order to develop interoperable 487 implementations of X.509 v3 systems for Internet use, it is necessary 488 to specify a profile for use of the X.509 v3 extensions tailored for 489 the Internet. It is one goal of this document to specify a profile 490 for Internet WWW, electronic mail, and IPsec applications. 491 Environments with additional requirements may build on this profile 492 or may replace it. 493 4943.2 Certification Paths and Trust 495 496 A user of a security service requiring knowledge of a public key 497 generally needs to obtain and validate a certificate containing the 498 required public key. If the public key user does not already hold an 499 assured copy of the public key of the CA that signed the certificate, 500 the CA's name, and related information (such as the validity period 501 or name constraints), then it might need an additional certificate to 502 obtain that public key. In general, a chain of multiple certificates 503 504 505 506Housley, et. al. Standards Track [Page 9] 507 508RFC 3280 Internet X.509 Public Key Infrastructure April 2002 509 510 511 may be needed, comprising a certificate of the public key owner (the 512 end entity) signed by one CA, and zero or more additional 513 certificates of CAs signed by other CAs. Such chains, called 514 certification paths, are required because a public key user is only 515 initialized with a limited number of assured CA public keys. 516 517 There are different ways in which CAs might be configured in order 518 for public key users to be able to find certification paths. For 519 PEM, RFC 1422 defined a rigid hierarchical structure of CAs. There 520 are three types of PEM certification authority: 521 522 (a) Internet Policy Registration Authority (IPRA): This 523 authority, operated under the auspices of the Internet Society, 524 acts as the root of the PEM certification hierarchy at level 1. 525 It issues certificates only for the next level of authorities, 526 PCAs. All certification paths start with the IPRA. 527 528 (b) Policy Certification Authorities (PCAs): PCAs are at level 2 529 of the hierarchy, each PCA being certified by the IPRA. A PCA 530 shall establish and publish a statement of its policy with respect 531 to certifying users or subordinate certification authorities. 532 Distinct PCAs aim to satisfy different user needs. For example, 533 one PCA (an organizational PCA) might support the general 534 electronic mail needs of commercial organizations, and another PCA 535 (a high-assurance PCA) might have a more stringent policy designed 536 for satisfying legally binding digital signature requirements. 537 538 (c) Certification Authorities (CAs): CAs are at level 3 of the 539 hierarchy and can also be at lower levels. Those at level 3 are 540 certified by PCAs. CAs represent, for example, particular 541 organizations, particular organizational units (e.g., departments, 542 groups, sections), or particular geographical areas. 543 544 RFC 1422 furthermore has a name subordination rule which requires 545 that a CA can only issue certificates for entities whose names are 546 subordinate (in the X.500 naming tree) to the name of the CA itself. 547 The trust associated with a PEM certification path is implied by the 548 PCA name. The name subordination rule ensures that CAs below the PCA 549 are sensibly constrained as to the set of subordinate entities they 550 can certify (e.g., a CA for an organization can only certify entities 551 in that organization's name tree). Certificate user systems are able 552 to mechanically check that the name subordination rule has been 553 followed. 554 555 The RFC 1422 uses the X.509 v1 certificate formats. The limitations 556 of X.509 v1 required imposition of several structural restrictions to 557 clearly associate policy information or restrict the utility of 558 certificates. These restrictions included: 559 560 561 562Housley, et. al. Standards Track [Page 10] 563 564RFC 3280 Internet X.509 Public Key Infrastructure April 2002 565 566 567 (a) a pure top-down hierarchy, with all certification paths 568 starting from IPRA; 569 570 (b) a naming subordination rule restricting the names of a CA's 571 subjects; and 572 573 (c) use of the PCA concept, which requires knowledge of 574 individual PCAs to be built into certificate chain verification 575 logic. Knowledge of individual PCAs was required to determine if 576 a chain could be accepted. 577 578 With X.509 v3, most of the requirements addressed by RFC 1422 can be 579 addressed using certificate extensions, without a need to restrict 580 the CA structures used. In particular, the certificate extensions 581 relating to certificate policies obviate the need for PCAs and the 582 constraint extensions obviate the need for the name subordination 583 rule. As a result, this document supports a more flexible 584 architecture, including: 585 586 (a) Certification paths start with a public key of a CA in a 587 user's own domain, or with the public key of the top of a 588 hierarchy. Starting with the public key of a CA in a user's own 589 domain has certain advantages. In some environments, the local 590 domain is the most trusted. 591 592 (b) Name constraints may be imposed through explicit inclusion of 593 a name constraints extension in a certificate, but are not 594 required. 595 596 (c) Policy extensions and policy mappings replace the PCA 597 concept, which permits a greater degree of automation. The 598 application can determine if the certification path is acceptable 599 based on the contents of the certificates instead of a priori 600 knowledge of PCAs. This permits automation of certification path 601 processing. 602 6033.3 Revocation 604 605 When a certificate is issued, it is expected to be in use for its 606 entire validity period. However, various circumstances may cause a 607 certificate to become invalid prior to the expiration of the validity 608 period. Such circumstances include change of name, change of 609 association between subject and CA (e.g., an employee terminates 610 employment with an organization), and compromise or suspected 611 compromise of the corresponding private key. Under such 612 circumstances, the CA needs to revoke the certificate. 613 614 615 616 617 618Housley, et. al. Standards Track [Page 11] 619 620RFC 3280 Internet X.509 Public Key Infrastructure April 2002 621 622 623 X.509 defines one method of certificate revocation. This method 624 involves each CA periodically issuing a signed data structure called 625 a certificate revocation list (CRL). A CRL is a time stamped list 626 identifying revoked certificates which is signed by a CA or CRL 627 issuer and made freely available in a public repository. Each 628 revoked certificate is identified in a CRL by its certificate serial 629 number. When a certificate-using system uses a certificate (e.g., 630 for verifying a remote user's digital signature), that system not 631 only checks the certificate signature and validity but also acquires 632 a suitably-recent CRL and checks that the certificate serial number 633 is not on that CRL. The meaning of "suitably-recent" may vary with 634 local policy, but it usually means the most recently-issued CRL. A 635 new CRL is issued on a regular periodic basis (e.g., hourly, daily, 636 or weekly). An entry is added to the CRL as part of the next update 637 following notification of revocation. An entry MUST NOT be removed 638 from the CRL until it appears on one regularly scheduled CRL issued 639 beyond the revoked certificate's validity period. 640 641 An advantage of this revocation method is that CRLs may be 642 distributed by exactly the same means as certificates themselves, 643 namely, via untrusted servers and untrusted communications. 644 645 One limitation of the CRL revocation method, using untrusted 646 communications and servers, is that the time granularity of 647 revocation is limited to the CRL issue period. For example, if a 648 revocation is reported now, that revocation will not be reliably 649 notified to certificate-using systems until all currently issued CRLs 650 are updated -- this may be up to one hour, one day, or one week 651 depending on the frequency that CRLs are issued. 652 653 As with the X.509 v3 certificate format, in order to facilitate 654 interoperable implementations from multiple vendors, the X.509 v2 CRL 655 format needs to be profiled for Internet use. It is one goal of this 656 document to specify that profile. However, this profile does not 657 require the issuance of CRLs. Message formats and protocols 658 supporting on-line revocation notification are defined in other PKIX 659 specifications. On-line methods of revocation notification may be 660 applicable in some environments as an alternative to the X.509 CRL. 661 On-line revocation checking may significantly reduce the latency 662 between a revocation report and the distribution of the information 663 to relying parties. Once the CA accepts a revocation report as 664 authentic and valid, any query to the on-line service will correctly 665 reflect the certificate validation impacts of the revocation. 666 However, these methods impose new security requirements: the 667 certificate validator needs to trust the on-line validation service 668 while the repository does not need to be trusted. 669 670 671 672 673 674Housley, et. al. Standards Track [Page 12] 675 676RFC 3280 Internet X.509 Public Key Infrastructure April 2002 677 678 6793.4 Operational Protocols 680 681 Operational protocols are required to deliver certificates and CRLs 682 (or status information) to certificate using client systems. 683 Provisions are needed for a variety of different means of certificate 684 and CRL delivery, including distribution procedures based on LDAP, 685 HTTP, FTP, and X.500. Operational protocols supporting these 686 functions are defined in other PKIX specifications. These 687 specifications may include definitions of message formats and 688 procedures for supporting all of the above operational environments, 689 including definitions of or references to appropriate MIME content 690 types. 691 6923.5 Management Protocols 693 694 Management protocols are required to support on-line interactions 695 between PKI user and management entities. For example, a management 696 protocol might be used between a CA and a client system with which a 697 key pair is associated, or between two CAs which cross-certify each 698 other. The set of functions which potentially need to be supported 699 by management protocols include: 700 701 (a) registration: This is the process whereby a user first makes 702 itself known to a CA (directly, or through an RA), prior to that 703 CA issuing a certificate or certificates for that user. 704 705 (b) initialization: Before a client system can operate securely 706 it is necessary to install key materials which have the 707 appropriate relationship with keys stored elsewhere in the 708 infrastructure. For example, the client needs to be securely 709 initialized with the public key and other assured information of 710 the trusted CA(s), to be used in validating certificate paths. 711 712 Furthermore, a client typically needs to be initialized with its 713 own key pair(s). 714 715 (c) certification: This is the process in which a CA issues a 716 certificate for a user's public key, and returns that certificate 717 to the user's client system and/or posts that certificate in a 718 repository. 719 720 (d) key pair recovery: As an option, user client key materials 721 (e.g., a user's private key used for encryption purposes) may be 722 backed up by a CA or a key backup system. If a user needs to 723 recover these backed up key materials (e.g., as a result of a 724 forgotten password or a lost key chain file), an on-line protocol 725 exchange may be needed to support such recovery. 726 727 728 729 730Housley, et. al. Standards Track [Page 13] 731 732RFC 3280 Internet X.509 Public Key Infrastructure April 2002 733 734 735 (e) key pair update: All key pairs need to be updated regularly, 736 i.e., replaced with a new key pair, and new certificates issued. 737 738 (f) revocation request: An authorized person advises a CA of an 739 abnormal situation requiring certificate revocation. 740 741 (g) cross-certification: Two CAs exchange information used in 742 establishing a cross-certificate. A cross-certificate is a 743 certificate issued by one CA to another CA which contains a CA 744 signature key used for issuing certificates. 745 746 Note that on-line protocols are not the only way of implementing the 747 above functions. For all functions there are off-line methods of 748 achieving the same result, and this specification does not mandate 749 use of on-line protocols. For example, when hardware tokens are 750 used, many of the functions may be achieved as part of the physical 751 token delivery. Furthermore, some of the above functions may be 752 combined into one protocol exchange. In particular, two or more of 753 the registration, initialization, and certification functions can be 754 combined into one protocol exchange. 755 756 The PKIX series of specifications defines a set of standard message 757 formats supporting the above functions. The protocols for conveying 758 these messages in different environments (e.g., e-mail, file 759 transfer, and WWW) are described in those specifications. 760 7614 Certificate and Certificate Extensions Profile 762 763 This section presents a profile for public key certificates that will 764 foster interoperability and a reusable PKI. This section is based 765 upon the X.509 v3 certificate format and the standard certificate 766 extensions defined in [X.509]. The ISO/IEC and ITU-T documents use 767 the 1997 version of ASN.1; while this document uses the 1988 ASN.1 768 syntax, the encoded certificate and standard extensions are 769 equivalent. This section also defines private extensions required to 770 support a PKI for the Internet community. 771 772 Certificates may be used in a wide range of applications and 773 environments covering a broad spectrum of interoperability goals and 774 a broader spectrum of operational and assurance requirements. The 775 goal of this document is to establish a common baseline for generic 776 applications requiring broad interoperability and limited special 777 purpose requirements. In particular, the emphasis will be on 778 supporting the use of X.509 v3 certificates for informal Internet 779 electronic mail, IPsec, and WWW applications. 780 781 782 783 784 785 786Housley, et. al. Standards Track [Page 14] 787 788RFC 3280 Internet X.509 Public Key Infrastructure April 2002 789 790 7914.1 Basic Certificate Fields 792 793 The X.509 v3 certificate basic syntax is as follows. For signature 794 calculation, the data that is to be signed is encoded using the ASN.1 795 distinguished encoding rules (DER) [X.690]. ASN.1 DER encoding is a 796 tag, length, value encoding system for each element. 797 798 Certificate ::= SEQUENCE { 799 tbsCertificate TBSCertificate, 800 signatureAlgorithm AlgorithmIdentifier, 801 signatureValue BIT STRING } 802 803 TBSCertificate ::= SEQUENCE { 804 version [0] EXPLICIT Version DEFAULT v1, 805 serialNumber CertificateSerialNumber, 806 signature AlgorithmIdentifier, 807 issuer Name, 808 validity Validity, 809 subject Name, 810 subjectPublicKeyInfo SubjectPublicKeyInfo, 811 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 812 -- If present, version MUST be v2 or v3 813 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 814 -- If present, version MUST be v2 or v3 815 extensions [3] EXPLICIT Extensions OPTIONAL 816 -- If present, version MUST be v3 817 } 818 819 Version ::= INTEGER { v1(0), v2(1), v3(2) } 820 821 CertificateSerialNumber ::= INTEGER 822 823 Validity ::= SEQUENCE { 824 notBefore Time, 825 notAfter Time } 826 827 Time ::= CHOICE { 828 utcTime UTCTime, 829 generalTime GeneralizedTime } 830 831 UniqueIdentifier ::= BIT STRING 832 833 SubjectPublicKeyInfo ::= SEQUENCE { 834 algorithm AlgorithmIdentifier, 835 subjectPublicKey BIT STRING } 836 837 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 838 839 840 841 842Housley, et. al. Standards Track [Page 15] 843 844RFC 3280 Internet X.509 Public Key Infrastructure April 2002 845 846 847 Extension ::= SEQUENCE { 848 extnID OBJECT IDENTIFIER, 849 critical BOOLEAN DEFAULT FALSE, 850 extnValue OCTET STRING } 851 852 The following items describe the X.509 v3 certificate for use in the 853 Internet. 854 8554.1.1 Certificate Fields 856 857 The Certificate is a SEQUENCE of three required fields. The fields 858 are described in detail in the following subsections. 859 8604.1.1.1 tbsCertificate 861 862 The field contains the names of the subject and issuer, a public key 863 associated with the subject, a validity period, and other associated 864 information. The fields are described in detail in section 4.1.2; 865 the tbsCertificate usually includes extensions which are described in 866 section 4.2. 867 8684.1.1.2 signatureAlgorithm 869 870 The signatureAlgorithm field contains the identifier for the 871 cryptographic algorithm used by the CA to sign this certificate. 872 [PKIXALGS] lists supported signature algorithms, but other signature 873 algorithms MAY also be supported. 874 875 An algorithm identifier is defined by the following ASN.1 structure: 876 877 AlgorithmIdentifier ::= SEQUENCE { 878 algorithm OBJECT IDENTIFIER, 879 parameters ANY DEFINED BY algorithm OPTIONAL } 880 881 The algorithm identifier is used to identify a cryptographic 882 algorithm. The OBJECT IDENTIFIER component identifies the algorithm 883 (such as DSA with SHA-1). The contents of the optional parameters 884 field will vary according to the algorithm identified. 885 886 This field MUST contain the same algorithm identifier as the 887 signature field in the sequence tbsCertificate (section 4.1.2.3). 888 8894.1.1.3 signatureValue 890 891 The signatureValue field contains a digital signature computed upon 892 the ASN.1 DER encoded tbsCertificate. The ASN.1 DER encoded 893 tbsCertificate is used as the input to the signature function. This 894 895 896 897 898Housley, et. al. Standards Track [Page 16] 899 900RFC 3280 Internet X.509 Public Key Infrastructure April 2002 901 902 903 signature value is encoded as a BIT STRING and included in the 904 signature field. The details of this process are specified for each 905 of algorithms listed in [PKIXALGS]. 906 907 By generating this signature, a CA certifies the validity of the 908 information in the tbsCertificate field. In particular, the CA 909 certifies the binding between the public key material and the subject 910 of the certificate. 911 9124.1.2 TBSCertificate 913 914 The sequence TBSCertificate contains information associated with the 915 subject of the certificate and the CA who issued it. Every 916 TBSCertificate contains the names of the subject and issuer, a public 917 key associated with the subject, a validity period, a version number, 918 and a serial number; some MAY contain optional unique identifier 919 fields. The remainder of this section describes the syntax and 920 semantics of these fields. A TBSCertificate usually includes 921 extensions. Extensions for the Internet PKI are described in Section 922 4.2. 923 9244.1.2.1 Version 925 926 This field describes the version of the encoded certificate. When 927 extensions are used, as expected in this profile, version MUST be 3 928 (value is 2). If no extensions are present, but a UniqueIdentifier 929 is present, the version SHOULD be 2 (value is 1); however version MAY 930 be 3. If only basic fields are present, the version SHOULD be 1 (the 931 value is omitted from the certificate as the default value); however 932 the version MAY be 2 or 3. 933 934 Implementations SHOULD be prepared to accept any version certificate. 935 At a minimum, conforming implementations MUST recognize version 3 936 certificates. 937 938 Generation of version 2 certificates is not expected by 939 implementations based on this profile. 940 9414.1.2.2 Serial number 942 943 The serial number MUST be a positive integer assigned by the CA to 944 each certificate. It MUST be unique for each certificate issued by a 945 given CA (i.e., the issuer name and serial number identify a unique 946 certificate). CAs MUST force the serialNumber to be a non-negative 947 integer. 948 949 950 951 952 953 954Housley, et. al. Standards Track [Page 17] 955 956RFC 3280 Internet X.509 Public Key Infrastructure April 2002 957 958 959 Given the uniqueness requirements above, serial numbers can be 960 expected to contain long integers. Certificate users MUST be able to 961 handle serialNumber values up to 20 octets. Conformant CAs MUST NOT 962 use serialNumber values longer than 20 octets. 963 964 Note: Non-conforming CAs may issue certificates with serial numbers 965 that are negative, or zero. Certificate users SHOULD be prepared to 966 gracefully handle such certificates. 967 9684.1.2.3 Signature 969 970 This field contains the algorithm identifier for the algorithm used 971 by the CA to sign the certificate. 972 973 This field MUST contain the same algorithm identifier as the 974 signatureAlgorithm field in the sequence Certificate (section 975 4.1.1.2). The contents of the optional parameters field will vary 976 according to the algorithm identified. [PKIXALGS] lists the 977 supported signature algorithms, but other signature algorithms MAY 978 also be supported. 979 9804.1.2.4 Issuer 981 982 The issuer field identifies the entity who has signed and issued the 983 certificate. The issuer field MUST contain a non-empty distinguished 984 name (DN). The issuer field is defined as the X.501 type Name 985 [X.501]. Name is defined by the following ASN.1 structures: 986 987 Name ::= CHOICE { 988 RDNSequence } 989 990 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 991 992 RelativeDistinguishedName ::= 993 SET OF AttributeTypeAndValue 994 995 AttributeTypeAndValue ::= SEQUENCE { 996 type AttributeType, 997 value AttributeValue } 998 999 AttributeType ::= OBJECT IDENTIFIER 1000 1001 AttributeValue ::= ANY DEFINED BY AttributeType 1002 1003 1004 1005 1006 1007 1008 1009 1010Housley, et. al. Standards Track [Page 18] 1011 1012RFC 3280 Internet X.509 Public Key Infrastructure April 2002 1013 1014 1015 DirectoryString ::= CHOICE { 1016 teletexString TeletexString (SIZE (1..MAX)), 1017 printableString PrintableString (SIZE (1..MAX)), 1018 universalString UniversalString (SIZE (1..MAX)), 1019 utf8String UTF8String (SIZE (1..MAX)), 1020 bmpString BMPString (SIZE (1..MAX)) } 1021 1022 The Name describes a hierarchical name composed of attributes, such 1023 as country name, and corresponding values, such as US. The type of 1024 the component AttributeValue is determined by the AttributeType; in 1025 general it will be a DirectoryString. 1026 1027 The DirectoryString type is defined as a choice of PrintableString, 1028 TeletexString, BMPString, UTF8String, and UniversalString. The 1029 UTF8String encoding [RFC 2279] is the preferred encoding, and all 1030 certificates issued after December 31, 2003 MUST use the UTF8String 1031 encoding of DirectoryString (except as noted below). Until that 1032 date, conforming CAs MUST choose from the following options when 1033 creating a distinguished name, including their own: 1034 1035 (a) if the character set is sufficient, the string MAY be 1036 represented as a PrintableString; 1037 1038 (b) failing (a), if the BMPString character set is sufficient the 1039 string MAY be represented as a BMPString; and 1040 1041 (c) failing (a) and (b), the string MUST be represented as a 1042 UTF8String. If (a) or (b) is satisfied, the CA MAY still choose 1043 to represent the string as a UTF8String. 1044 1045 Exceptions to the December 31, 2003 UTF8 encoding requirements are as 1046 follows: 1047 1048 (a) CAs MAY issue "name rollover" certificates to support an 1049 orderly migration to UTF8String encoding. Such certificates would 1050 include the CA's UTF8String encoded name as issuer and and the old 1051 name encoding as subject, or vice-versa. 1052 1053 (b) As stated in section 4.1.2.6, the subject field MUST be 1054 populated with a non-empty distinguished name matching the 1055 contents of the issuer field in all certificates issued by the 1056 subject CA regardless of encoding. 1057 1058 The TeletexString and UniversalString are included for backward 1059 compatibility, and SHOULD NOT be used for certificates for new 1060 subjects. However, these types MAY be used in certificates where the 1061 name was previously established. Certificate users SHOULD be 1062 prepared to receive certificates with these types. 1063 1064 1065 1066Housley, et. al. Standards Track [Page 19] 1067 1068RFC 3280 Internet X.509 Public Key Infrastructure April 2002 1069 1070 1071 In addition, many legacy implementations support names encoded in the 1072 ISO 8859-1 character set (Latin1String) [ISO 8859-1] but tag them as 1073 TeletexString. TeletexString encodes a larger character set than ISO 1074 8859-1, but it encodes some characters differently. Implementations 1075 SHOULD be prepared to handle both encodings. 1076 1077 As noted above, distinguished names are composed of attributes. This 1078 specification does not restrict the set of attribute types that may 1079 appear in names. However, conforming implementations MUST be 1080 prepared to receive certificates with issuer names containing the set 1081 of attribute types defined below. This specification RECOMMENDS 1082 support for additional attribute types. 1083 1084 Standard sets of attributes have been defined in the X.500 series of 1085 specifications [X.520]. Implementations of this specification MUST 1086 be prepared to receive the following standard attribute types in 1087 issuer and subject (section 4.1.2.6) names: 1088 1089 * country, 1090 * organization, 1091 * organizational-unit, 1092 * distinguished name qualifier, 1093 * state or province name, 1094 * common name (e.g., "Susan Housley"), and 1095 * serial number. 1096 1097 In addition, implementations of this specification SHOULD be prepared 1098 to receive the following standard attribute types in issuer and 1099 subject names: 1100 1101 * locality, 1102 * title, 1103 * surname, 1104 * given name, 1105 * initials, 1106 * pseudonym, and 1107 * generation qualifier (e.g., "Jr.", "3rd", or "IV"). 1108 1109 The syntax and associated object identifiers (OIDs) for these 1110 attribute types are provided in the ASN.1 modules in Appendix A. 1111 1112 In addition, implementations of this specification MUST be prepared 1113 to receive the domainComponent attribute, as defined in [RFC 2247]. 1114 The Domain Name System (DNS) provides a hierarchical resource 1115 labeling system. This attribute provides a convenient mechanism for 1116 organizations that wish to use DNs that parallel their DNS names. 1117 This is not a replacement for the dNSName component of the 1118 1119 1120 1121 1122Housley, et. al. Standards Track [Page 20] 1123 1124RFC 3280 Internet X.509 Public Key Infrastructure April 2002 1125 1126 1127 alternative name field. Implementations are not required to convert 1128 such names into DNS names. The syntax and associated OID for this 1129 attribute type is provided in the ASN.1 modules in Appendix A. 1130 1131 Certificate users MUST be prepared to process the issuer 1132 distinguished name and subject distinguished name (section 4.1.2.6) 1133 fields to perform name chaining for certification path validation 1134 (section 6). Name chaining is performed by matching the issuer 1135 distinguished name in one certificate with the subject name in a CA 1136 certificate. 1137 1138 This specification requires only a subset of the name comparison 1139 functionality specified in the X.500 series of specifications. 1140 Conforming implementations are REQUIRED to implement the following 1141 name comparison rules: 1142 1143 (a) attribute values encoded in different types (e.g., 1144 PrintableString and BMPString) MAY be assumed to represent 1145 different strings; 1146 1147 (b) attribute values in types other than PrintableString are case 1148 sensitive (this permits matching of attribute values as binary 1149 objects); 1150 1151 (c) attribute values in PrintableString are not case sensitive 1152 (e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and 1153 1154 (d) attribute values in PrintableString are compared after 1155 removing leading and trailing white space and converting internal 1156 substrings of one or more consecutive white space characters to a 1157 single space. 1158 1159 These name comparison rules permit a certificate user to validate 1160 certificates issued using languages or encodings unfamiliar to the 1161 certificate user. 1162 1163 In addition, implementations of this specification MAY use these 1164 comparison rules to process unfamiliar attribute types for name 1165 chaining. This allows implementations to process certificates with 1166 unfamiliar attributes in the issuer name. 1167 1168 Note that the comparison rules defined in the X.500 series of 1169 specifications indicate that the character sets used to encode data 1170 in distinguished names are irrelevant. The characters themselves are 1171 compared without regard to encoding. Implementations of this profile 1172 are permitted to use the comparison algorithm defined in the X.500 1173 series. Such an implementation will recognize a superset of name 1174 matches recognized by the algorithm specified above. 1175 1176 1177 1178Housley, et. al. Standards Track [Page 21] 1179 1180RFC 3280 Internet X.509 Public Key Infrastructure April 2002 1181 1182 11834.1.2.5 Validity 1184 1185 The certificate validity period is the time interval during which the 1186 CA warrants that it will maintain information about the status of the 1187 certificate. The field is represented as a SEQUENCE of two dates: 1188 the date on which the certificate validity period begins (notBefore) 1189 and the date on which the certificate validity period ends 1190 (notAfter). Both notBefore and notAfter may be encoded as UTCTime or 1191 GeneralizedTime. 1192 1193 CAs conforming to this profile MUST always encode certificate 1194 validity dates through the year 2049 as UTCTime; certificate validity 1195 dates in 2050 or later MUST be encoded as GeneralizedTime. 1196 1197 The validity period for a certificate is the period of time from 1198 notBefore through notAfter, inclusive. 1199 12004.1.2.5.1 UTCTime 1201 1202 The universal time type, UTCTime, is a standard ASN.1 type intended 1203 for representation of dates and time. UTCTime specifies the year 1204 through the two low order digits and time is specified to the 1205 precision of one minute or one second. UTCTime includes either Z 1206 (for Zulu, or Greenwich Mean Time) or a time differential. 1207 1208 For the purposes of this profile, UTCTime values MUST be expressed 1209 Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are 1210 YYMMDDHHMMSSZ), even where the number of seconds is zero. Conforming 1211 systems MUST interpret the year field (YY) as follows: 1212 1213 Where YY is greater than or equal to 50, the year SHALL be 1214 interpreted as 19YY; and 1215 1216 Where YY is less than 50, the year SHALL be interpreted as 20YY. 1217 12184.1.2.5.2 GeneralizedTime 1219 1220 The generalized time type, GeneralizedTime, is a standard ASN.1 type 1221 for variable precision representation of time. Optionally, the 1222 GeneralizedTime field can include a representation of the time 1223 differential between local and Greenwich Mean Time. 1224 1225 For the purposes of this profile, GeneralizedTime values MUST be 1226 expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e., 1227 times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. 1228 GeneralizedTime values MUST NOT include fractional seconds. 1229 1230 1231 1232 1233 1234Housley, et. al. Standards Track [Page 22] 1235 1236RFC 3280 Internet X.509 Public Key Infrastructure April 2002 1237 1238 12394.1.2.6 Subject 1240 1241 The subject field identifies the entity associated with the public 1242 key stored in the subject public key field. The subject name MAY be 1243 carried in the subject field and/or the subjectAltName extension. If 1244 the subject is a CA (e.g., the basic constraints extension, as 1245 discussed in 4.2.1.10, is present and the value of cA is TRUE), then 1246 the subject field MUST be populated with a non-empty distinguished 1247 name matching the contents of the issuer field (section 4.1.2.4) in 1248 all certificates issued by the subject CA. If the subject is a CRL 1249 issuer (e.g., the key usage extension, as discussed in 4.2.1.3, is 1250 present and the value of cRLSign is TRUE) then the subject field MUST 1251 be populated with a non-empty distinguished name matching the 1252 contents of the issuer field (section 4.1.2.4) in all CRLs issued by 1253 the subject CRL issuer. If subject naming information is present 1254 only in the subjectAltName extension (e.g., a key bound only to an 1255 email address or URI), then the subject name MUST be an empty 1256 sequence and the subjectAltName extension MUST be critical. 1257 1258 Where it is non-empty, the subject field MUST contain an X.500 1259 distinguished name (DN). The DN MUST be unique for each subject 1260 entity certified by the one CA as defined by the issuer name field. 1261 A CA MAY issue more than one certificate with the same DN to the same 1262 subject entity. 1263 1264 The subject name field is defined as the X.501 type Name. 1265 Implementation requirements for this field are those defined for the 1266 issuer field (section 4.1.2.4). When encoding attribute values of 1267 type DirectoryString, the encoding rules for the issuer field MUST be 1268 implemented. Implementations of this specification MUST be prepared 1269 to receive subject names containing the attribute types required for 1270 the issuer field. Implementations of this specification SHOULD be 1271 prepared to receive subject names containing the recommended 1272 attribute types for the issuer field. The syntax and associated 1273 object identifiers (OIDs) for these attribute types are provided in 1274 the ASN.1 modules in Appendix A. Implementations of this 1275 specification MAY use these comparison rules to process unfamiliar 1276 attribute types (i.e., for name chaining). This allows 1277 implementations to process certificates with unfamiliar attributes in 1278 the subject name. 1279 1280 In addition, legacy implementations exist where an RFC 822 name is 1281 embedded in the subject distinguished name as an EmailAddress 1282 attribute. The attribute value for EmailAddress is of type IA5String 1283 to permit inclusion of the character '@', which is not part of the 1284 PrintableString character set. EmailAddress attribute values are not 1285 case sensitive (e.g., "fanfeedback@redsox.com" is the same as 1286 "FANFEEDBACK@REDSOX.COM"). 1287 1288 1289 1290Housley, et. al. Standards Track [Page 23] 1291 1292RFC 3280 Internet X.509 Public Key Infrastructure April 2002 1293 1294 1295 Conforming implementations generating new certificates with 1296 electronic mail addresses MUST use the rfc822Name in the subject 1297 alternative name field (section 4.2.1.7) to describe such identities. 1298 Simultaneous inclusion of the EmailAddress attribute in the subject 1299 distinguished name to support legacy implementations is deprecated 1300 but permitted. 1301 13024.1.2.7 Subject Public Key Info 1303 1304 This field is used to carry the public key and identify the algorithm 1305 with which the key is used (e.g., RSA, DSA, or Diffie-Hellman). The 1306 algorithm is identified using the AlgorithmIdentifier structure 1307 specified in section 4.1.1.2. The object identifiers for the 1308 supported algorithms and the methods for encoding the public key 1309 materials (public key and parameters) are specified in [PKIXALGS]. 1310 13114.1.2.8 Unique Identifiers 1312 1313 These fields MUST only appear if the version is 2 or 3 (section 1314 4.1.2.1). These fields MUST NOT appear if the version is 1. The 1315 subject and issuer unique identifiers are present in the certificate 1316 to handle the possibility of reuse of subject and/or issuer names 1317 over time. This profile RECOMMENDS that names not be reused for 1318 different entities and that Internet certificates not make use of 1319 unique identifiers. CAs conforming to this profile SHOULD NOT 1320 generate certificates with unique identifiers. Applications 1321 conforming to this profile SHOULD be capable of parsing unique 1322 identifiers. 1323 13244.1.2.9 Extensions 1325 1326 This field MUST only appear if the version is 3 (section 4.1.2.1). 1327 If present, this field is a SEQUENCE of one or more certificate 1328 extensions. The format and content of certificate extensions in the 1329 Internet PKI is defined in section 4.2. 1330 13314.2 Certificate Extensions 1332 1333 The extensions defined for X.509 v3 certificates provide methods for 1334 associating additional attributes with users or public keys and for 1335 managing a certification hierarchy. The X.509 v3 certificate format 1336 also allows communities to define private extensions to carry 1337 information unique to those communities. Each extension in a 1338 certificate is designated as either critical or non-critical. A 1339 certificate using system MUST reject the certificate if it encounters 1340 a critical extension it does not recognize; however, a non-critical 1341 extension MAY be ignored if it is not recognized. The following 1342 sections present recommended extensions used within Internet 1343 1344 1345 1346Housley, et. al. Standards Track [Page 24] 1347 1348RFC 3280 Internet X.509 Public Key Infrastructure April 2002 1349 1350 1351 certificates and standard locations for information. Communities may 1352 elect to use additional extensions; however, caution ought to be 1353 exercised in adopting any critical extensions in certificates which 1354 might prevent use in a general context. 1355 1356 Each extension includes an OID and an ASN.1 structure. When an 1357 extension appears in a certificate, the OID appears as the field 1358 extnID and the corresponding ASN.1 encoded structure is the value of 1359 the octet string extnValue. A certificate MUST NOT include more than 1360 one instance of a particular extension. For example, a certificate 1361 may contain only one authority key identifier extension (section 1362 4.2.1.1). An extension includes the boolean critical, with a default 1363 value of FALSE. The text for each extension specifies the acceptable 1364 values for the critical field. 1365 1366 Conforming CAs MUST support key identifiers (sections 4.2.1.1 and 1367 4.2.1.2), basic constraints (section 4.2.1.10), key usage (section 1368 4.2.1.3), and certificate policies (section 4.2.1.5) extensions. If 1369 the CA issues certificates with an empty sequence for the subject 1370 field, the CA MUST support the subject alternative name extension 1371 (section 4.2.1.7). Support for the remaining extensions is OPTIONAL. 1372 Conforming CAs MAY support extensions that are not identified within 1373 this specification; certificate issuers are cautioned that marking 1374 such extensions as critical may inhibit interoperability. 1375 1376 At a minimum, applications conforming to this profile MUST recognize 1377 the following extensions: key usage (section 4.2.1.3), certificate 1378 policies (section 4.2.1.5), the subject alternative name (section 1379 4.2.1.7), basic constraints (section 4.2.1.10), name constraints 1380 (section 4.2.1.11), policy constraints (section 4.2.1.12), extended 1381 key usage (section 4.2.1.13), and inhibit any-policy (section 1382 4.2.1.15). 1383 1384 In addition, applications conforming to this profile SHOULD recognize 1385 the authority and subject key identifier (sections 4.2.1.1 and 1386 4.2.1.2), and policy mapping (section 4.2.1.6) extensions. 1387 13884.2.1 Standard Extensions 1389 1390 This section identifies standard certificate extensions defined in 1391 [X.509] for use in the Internet PKI. Each extension is associated 1392 with an OID defined in [X.509]. These OIDs are members of the id-ce 1393 arc, which is defined by the following: 1394 1395 id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 } 1396 1397 1398 1399 1400 1401 1402Housley, et. al. Standards Track [Page 25] 1403 1404RFC 3280 Internet X.509 Public Key Infrastructure April 2002 1405 1406 14074.2.1.1 Authority Key Identifier 1408 1409 The authority key identifier extension provides a means of 1410 identifying the public key corresponding to the private key used to 1411 sign a certificate. This extension is used where an issuer has 1412 multiple signing keys (either due to multiple concurrent key pairs or 1413 due to changeover). The identification MAY be based on either the 1414 key identifier (the subject key identifier in the issuer's 1415 certificate) or on the issuer name and serial number. 1416 1417 The keyIdentifier field of the authorityKeyIdentifier extension MUST 1418 be included in all certificates generated by conforming CAs to 1419 facilitate certification path construction. There is one exception; 1420 where a CA distributes its public key in the form of a "self-signed" 1421 certificate, the authority key identifier MAY be omitted. The 1422 signature on a self-signed certificate is generated with the private 1423 key associated with the certificate's subject public key. (This 1424 proves that the issuer possesses both the public and private keys.) 1425 In this case, the subject and authority key identifiers would be 1426 identical, but only the subject key identifier is needed for 1427 certification path building. 1428 1429 The value of the keyIdentifier field SHOULD be derived from the 1430 public key used to verify the certificate's signature or a method 1431 that generates unique values. Two common methods for generating key 1432 identifiers from the public key, and one common method for generating 1433 unique values, are described in section 4.2.1.2. Where a key 1434 identifier has not been previously established, this specification 1435 RECOMMENDS use of one of these methods for generating keyIdentifiers. 1436 Where a key identifier has been previously established, the CA SHOULD 1437 use the previously established identifier. 1438 1439 This profile RECOMMENDS support for the key identifier method by all 1440 certificate users. 1441 1442 This extension MUST NOT be marked critical. 1443 1444 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 1445 1446 AuthorityKeyIdentifier ::= SEQUENCE { 1447 keyIdentifier [0] KeyIdentifier OPTIONAL, 1448 authorityCertIssuer [1] GeneralNames OPTIONAL, 1449 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 1450 1451 KeyIdentifier ::= OCTET STRING 1452 1453 1454 1455 1456 1457 1458Housley, et. al. Standards Track [Page 26] 1459 1460RFC 3280 Internet X.509 Public Key Infrastructure April 2002 1461 1462 14634.2.1.2 Subject Key Identifier 1464 1465 The subject key identifier extension provides a means of identifying 1466 certificates that contain a particular public key. 1467 1468 To facilitate certification path construction, this extension MUST 1469 appear in all conforming CA certificates, that is, all certificates 1470 including the basic constraints extension (section 4.2.1.10) where 1471 the value of cA is TRUE. The value of the subject key identifier 1472 MUST be the value placed in the key identifier field of the Authority 1473 Key Identifier extension (section 4.2.1.1) of certificates issued by 1474 the subject of this certificate. 1475 1476 For CA certificates, subject key identifiers SHOULD be derived from 1477 the public key or a method that generates unique values. Two common 1478 methods for generating key identifiers from the public key are: 1479 1480 (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the 1481 value of the BIT STRING subjectPublicKey (excluding the tag, 1482 length, and number of unused bits). 1483 1484 (2) The keyIdentifier is composed of a four bit type field with 1485 the value 0100 followed by the least significant 60 bits of the 1486 SHA-1 hash of the value of the BIT STRING subjectPublicKey 1487 (excluding the tag, length, and number of unused bit string bits). 1488 1489 One common method for generating unique values is a monotonically 1490 increasing sequence of integers. 1491 1492 For end entity certificates, the subject key identifier extension 1493 provides a means for identifying certificates containing the 1494 particular public key used in an application. Where an end entity 1495 has obtained multiple certificates, especially from multiple CAs, the 1496 subject key identifier provides a means to quickly identify the set 1497 of certificates containing a particular public key. To assist 1498 applications in identifying the appropriate end entity certificate, 1499 this extension SHOULD be included in all end entity certificates. 1500 1501 For end entity certificates, subject key identifiers SHOULD be 1502 derived from the public key. Two common methods for generating key 1503 identifiers from the public key are identified above. 1504 1505 Where a key identifier has not been previously established, this 1506 specification RECOMMENDS use of one of these methods for generating 1507 keyIdentifiers. Where a key identifier has been previously 1508 established, the CA SHOULD use the previously established identifier. 1509 1510 This extension MUST NOT be marked critical. 1511 1512 1513 1514Housley, et. al. Standards Track [Page 27] 1515 1516RFC 3280 Internet X.509 Public Key Infrastructure April 2002 1517 1518 1519 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 1520 1521 SubjectKeyIdentifier ::= KeyIdentifier 1522 15234.2.1.3 Key Usage 1524 1525 The key usage extension defines the purpose (e.g., encipherment, 1526 signature, certificate signing) of the key contained in the 1527 certificate. The usage restriction might be employed when a key that 1528 could be used for more than one operation is to be restricted. For 1529 example, when an RSA key should be used only to verify signatures on 1530 objects other than public key certificates and CRLs, the 1531 digitalSignature and/or nonRepudiation bits would be asserted. 1532 Likewise, when an RSA key should be used only for key management, the 1533 keyEncipherment bit would be asserted. 1534 1535 This extension MUST appear in certificates that contain public keys 1536 that are used to validate digital signatures on other public key 1537 certificates or CRLs. When this extension appears, it SHOULD be 1538 marked critical. 1539 1540 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 1541 1542 KeyUsage ::= BIT STRING { 1543 digitalSignature (0), 1544 nonRepudiation (1), 1545 keyEncipherment (2), 1546 dataEncipherment (3), 1547 keyAgreement (4), 1548 keyCertSign (5), 1549 cRLSign (6), 1550 encipherOnly (7), 1551 decipherOnly (8) } 1552 1553 Bits in the KeyUsage type are used as follows: 1554 1555 The digitalSignature bit is asserted when the subject public key 1556 is used with a digital signature mechanism to support security 1557 services other than certificate signing (bit 5), or CRL signing 1558 (bit 6). Digital signature mechanisms are often used for entity 1559 authentication and data origin authentication with integrity. 1560 1561 The nonRepudiation bit is asserted when the subject public key is 1562 used to verify digital signatures used to provide a non- 1563 repudiation service which protects against the signing entity 1564 falsely denying some action, excluding certificate or CRL signing. 1565 In the case of later conflict, a reliable third party may 1566 determine the authenticity of the signed data. 1567 1568 1569 1570Housley, et. al. Standards Track [Page 28] 1571 1572RFC 3280 Internet X.509 Public Key Infrastructure April 2002 1573 1574 1575 Further distinctions between the digitalSignature and 1576 nonRepudiation bits may be provided in specific certificate 1577 policies. 1578 1579 The keyEncipherment bit is asserted when the subject public key is 1580 used for key transport. For example, when an RSA key is to be 1581 used for key management, then this bit is set. 1582 1583 The dataEncipherment bit is asserted when the subject public key 1584 is used for enciphering user data, other than cryptographic keys. 1585 1586 The keyAgreement bit is asserted when the subject public key is 1587 used for key agreement. For example, when a Diffie-Hellman key is 1588 to be used for key management, then this bit is set. 1589 1590 The keyCertSign bit is asserted when the subject public key is 1591 used for verifying a signature on public key certificates. If the 1592 keyCertSign bit is asserted, then the cA bit in the basic 1593 constraints extension (section 4.2.1.10) MUST also be asserted. 1594 1595 The cRLSign bit is asserted when the subject public key is used 1596 for verifying a signature on certificate revocation list (e.g., a 1597 CRL, delta CRL, or an ARL). This bit MUST be asserted in 1598 certificates that are used to verify signatures on CRLs. 1599 1600 The meaning of the encipherOnly bit is undefined in the absence of 1601 the keyAgreement bit. When the encipherOnly bit is asserted and 1602 the keyAgreement bit is also set, the subject public key may be 1603 used only for enciphering data while performing key agreement. 1604 1605 The meaning of the decipherOnly bit is undefined in the absence of 1606 the keyAgreement bit. When the decipherOnly bit is asserted and 1607 the keyAgreement bit is also set, the subject public key may be 1608 used only for deciphering data while performing key agreement. 1609 1610 This profile does not restrict the combinations of bits that may be 1611 set in an instantiation of the keyUsage extension. However, 1612 appropriate values for keyUsage extensions for particular algorithms 1613 are specified in [PKIXALGS]. 1614 16154.2.1.4 Private Key Usage Period 1616 1617 This extension SHOULD NOT be used within the Internet PKI. CAs 1618 conforming to this profile MUST NOT generate certificates that 1619 include a critical private key usage period extension. 1620 1621 1622 1623 1624 1625 1626Housley, et. al. Standards Track [Page 29] 1627 1628RFC 3280 Internet X.509 Public Key Infrastructure April 2002 1629 1630 1631 The private key usage period extension allows the certificate issuer 1632 to specify a different validity period for the private key than the 1633 certificate. This extension is intended for use with digital 1634 signature keys. This extension consists of two optional components, 1635 notBefore and notAfter. The private key associated with the 1636 certificate SHOULD NOT be used to sign objects before or after the 1637 times specified by the two components, respectively. CAs conforming 1638 to this profile MUST NOT generate certificates with private key usage 1639 period extensions unless at least one of the two components is 1640 present and the extension is non-critical. 1641 1642 Where used, notBefore and notAfter are represented as GeneralizedTime 1643 and MUST be specified and interpreted as defined in section 1644 4.1.2.5.2. 1645 1646 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 1647 1648 PrivateKeyUsagePeriod ::= SEQUENCE { 1649 notBefore [0] GeneralizedTime OPTIONAL, 1650 notAfter [1] GeneralizedTime OPTIONAL } 1651 16524.2.1.5 Certificate Policies 1653 1654 The certificate policies extension contains a sequence of one or more 1655 policy information terms, each of which consists of an object 1656 identifier (OID) and optional qualifiers. Optional qualifiers, which 1657 MAY be present, are not expected to change the definition of the 1658 policy. 1659 1660 In an end entity certificate, these policy information terms indicate 1661 the policy under which the certificate has been issued and the 1662 purposes for which the certificate may be used. In a CA certificate, 1663 these policy information terms limit the set of policies for 1664 certification paths which include this certificate. When a CA does 1665 not wish to limit the set of policies for certification paths which 1666 include this certificate, it MAY assert the special policy anyPolicy, 1667 with a value of { 2 5 29 32 0 }. 1668 1669 Applications with specific policy requirements are expected to have a 1670 list of those policies which they will accept and to compare the 1671 policy OIDs in the certificate to that list. If this extension is 1672 critical, the path validation software MUST be able to interpret this 1673 extension (including the optional qualifier), or MUST reject the 1674 certificate. 1675 1676 To promote interoperability, this profile RECOMMENDS that policy 1677 information terms consist of only an OID. Where an OID alone is 1678 insufficient, this profile strongly recommends that use of qualifiers 1679 1680 1681 1682Housley, et. al. Standards Track [Page 30] 1683 1684RFC 3280 Internet X.509 Public Key Infrastructure April 2002 1685 1686 1687 be limited to those identified in this section. When qualifiers are 1688 used with the special policy anyPolicy, they MUST be limited to the 1689 qualifiers identified in this section. 1690 1691 This specification defines two policy qualifier types for use by 1692 certificate policy writers and certificate issuers. The qualifier 1693 types are the CPS Pointer and User Notice qualifiers. 1694 1695 The CPS Pointer qualifier contains a pointer to a Certification 1696 Practice Statement (CPS) published by the CA. The pointer is in the 1697 form of a URI. Processing requirements for this qualifier are a 1698 local matter. No action is mandated by this specification regardless 1699 of the criticality value asserted for the extension. 1700 1701 User notice is intended for display to a relying party when a 1702 certificate is used. The application software SHOULD display all 1703 user notices in all certificates of the certification path used, 1704 except that if a notice is duplicated only one copy need be 1705 displayed. To prevent such duplication, this qualifier SHOULD only 1706 be present in end entity certificates and CA certificates issued to 1707 other organizations. 1708 1709 The user notice has two optional fields: the noticeRef field and the 1710 explicitText field. 1711 1712 The noticeRef field, if used, names an organization and 1713 identifies, by number, a particular textual statement prepared by 1714 that organization. For example, it might identify the 1715 organization "CertsRUs" and notice number 1. In a typical 1716 implementation, the application software will have a notice file 1717 containing the current set of notices for CertsRUs; the 1718 application will extract the notice text from the file and display 1719 it. Messages MAY be multilingual, allowing the software to select 1720 the particular language message for its own environment. 1721 1722 An explicitText field includes the textual statement directly in 1723 the certificate. The explicitText field is a string with a 1724 maximum size of 200 characters. 1725 1726 If both the noticeRef and explicitText options are included in the 1727 one qualifier and if the application software can locate the notice 1728 text indicated by the noticeRef option, then that text SHOULD be 1729 displayed; otherwise, the explicitText string SHOULD be displayed. 1730 1731 Note: While the explicitText has a maximum size of 200 characters, 1732 some non-conforming CAs exceed this limit. Therefore, certificate 1733 users SHOULD gracefully handle explicitText with more than 200 1734 characters. 1735 1736 1737 1738Housley, et. al. Standards Track [Page 31] 1739 1740RFC 3280 Internet X.509 Public Key Infrastructure April 2002 1741 1742 1743 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 1744 1745 anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificate-policies 0 } 1746 1747 certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 1748 1749 PolicyInformation ::= SEQUENCE { 1750 policyIdentifier CertPolicyId, 1751 policyQualifiers SEQUENCE SIZE (1..MAX) OF 1752 PolicyQualifierInfo OPTIONAL } 1753 1754 CertPolicyId ::= OBJECT IDENTIFIER 1755 1756 PolicyQualifierInfo ::= SEQUENCE { 1757 policyQualifierId PolicyQualifierId, 1758 qualifier ANY DEFINED BY policyQualifierId } 1759 1760 -- policyQualifierIds for Internet policy qualifiers 1761 1762 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 1763 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 1764 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 1765 1766 PolicyQualifierId ::= 1767 OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) 1768 1769 Qualifier ::= CHOICE { 1770 cPSuri CPSuri, 1771 userNotice UserNotice } 1772 1773 CPSuri ::= IA5String 1774 1775 UserNotice ::= SEQUENCE { 1776 noticeRef NoticeReference OPTIONAL, 1777 explicitText DisplayText OPTIONAL} 1778 1779 NoticeReference ::= SEQUENCE { 1780 organization DisplayText, 1781 noticeNumbers SEQUENCE OF INTEGER } 1782 1783 DisplayText ::= CHOICE { 1784 ia5String IA5String (SIZE (1..200)), 1785 visibleString VisibleString (SIZE (1..200)), 1786 bmpString BMPString (SIZE (1..200)), 1787 utf8String UTF8String (SIZE (1..200)) } 1788 1789 1790 1791 1792 1793 1794Housley, et. al. Standards Track [Page 32] 1795 1796RFC 3280 Internet X.509 Public Key Infrastructure April 2002 1797 1798 17994.2.1.6 Policy Mappings 1800 1801 This extension is used in CA certificates. It lists one or more 1802 pairs of OIDs; each pair includes an issuerDomainPolicy and a 1803 subjectDomainPolicy. The pairing indicates the issuing CA considers 1804 its issuerDomainPolicy equivalent to the subject CA's 1805 subjectDomainPolicy. 1806 1807 The issuing CA's users might accept an issuerDomainPolicy for certain 1808 applications. The policy mapping defines the list of policies 1809 associated with the subject CA that may be accepted as comparable to 1810 the issuerDomainPolicy. 1811 1812 Each issuerDomainPolicy named in the policy mapping extension SHOULD 1813 also be asserted in a certificate policies extension in the same 1814 certificate. Policies SHOULD NOT be mapped either to or from the 1815 special value anyPolicy (section 4.2.1.5). 1816 1817 This extension MAY be supported by CAs and/or applications, and it 1818 MUST be non-critical. 1819 1820 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 1821 1822 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 1823 issuerDomainPolicy CertPolicyId, 1824 subjectDomainPolicy CertPolicyId } 1825 18264.2.1.7 Subject Alternative Name 1827 1828 The subject alternative names extension allows additional identities 1829 to be bound to the subject of the certificate. Defined options 1830 include an Internet electronic mail address, a DNS name, an IP 1831 address, and a uniform resource identifier (URI). Other options 1832 exist, including completely local definitions. Multiple name forms, 1833 and multiple instances of each name form, MAY be included. Whenever 1834 such identities are to be bound into a certificate, the subject 1835 alternative name (or issuer alternative name) extension MUST be used; 1836 however, a DNS name MAY be represented in the subject field using the 1837 domainComponent attribute as described in section 4.1.2.4. 1838 1839 Because the subject alternative name is considered to be definitively 1840 bound to the public key, all parts of the subject alternative name 1841 MUST be verified by the CA. 1842 1843 Further, if the only subject identity included in the certificate is 1844 an alternative name form (e.g., an electronic mail address), then the 1845 subject distinguished name MUST be empty (an empty sequence), and the 1846 1847 1848 1849 1850Housley, et. al. Standards Track [Page 33] 1851 1852RFC 3280 Internet X.509 Public Key Infrastructure April 2002 1853 1854 1855 subjectAltName extension MUST be present. If the subject field 1856 contains an empty sequence, the subjectAltName extension MUST be 1857 marked critical. 1858 1859 When the subjectAltName extension contains an Internet mail address, 1860 the address MUST be included as an rfc822Name. The format of an 1861 rfc822Name is an "addr-spec" as defined in RFC 822 [RFC 822]. An 1862 addr-spec has the form "local-part@domain". Note that an addr-spec 1863 has no phrase (such as a common name) before it, has no comment (text 1864 surrounded in parentheses) after it, and is not surrounded by "<" and 1865 ">". Note that while upper and lower case letters are allowed in an 1866 RFC 822 addr-spec, no significance is attached to the case. 1867 1868 When the subjectAltName extension contains a iPAddress, the address 1869 MUST be stored in the octet string in "network byte order," as 1870 specified in RFC 791 [RFC 791]. The least significant bit (LSB) of 1871 each octet is the LSB of the corresponding byte in the network 1872 address. For IP Version 4, as specified in RFC 791, the octet string 1873 MUST contain exactly four octets. For IP Version 6, as specified in 1874 RFC 1883, the octet string MUST contain exactly sixteen octets [RFC 1875 1883]. 1876 1877 When the subjectAltName extension contains a domain name system 1878 label, the domain name MUST be stored in the dNSName (an IA5String). 1879 The name MUST be in the "preferred name syntax," as specified by RFC 1880 1034 [RFC 1034]. Note that while upper and lower case letters are 1881 allowed in domain names, no signifigance is attached to the case. In 1882 addition, while the string " " is a legal domain name, subjectAltName 1883 extensions with a dNSName of " " MUST NOT be used. Finally, the use 1884 of the DNS representation for Internet mail addresses (wpolk.nist.gov 1885 instead of wpolk@nist.gov) MUST NOT be used; such identities are to 1886 be encoded as rfc822Name. 1887 1888 Note: work is currently underway to specify domain names in 1889 international character sets. Such names will likely not be 1890 accommodated by IA5String. Once this work is complete, this profile 1891 will be revisited and the appropriate functionality will be added. 1892 1893 When the subjectAltName extension contains a URI, the name MUST be 1894 stored in the uniformResourceIdentifier (an IA5String). The name 1895 MUST NOT be a relative URL, and it MUST follow the URL syntax and 1896 encoding rules specified in [RFC 1738]. The name MUST include both a 1897 scheme (e.g., "http" or "ftp") and a scheme-specific-part. The 1898 scheme-specific-part MUST include a fully qualified domain name or IP 1899 address as the host. 1900 1901 1902 1903 1904 1905 1906Housley, et. al. Standards Track [Page 34] 1907 1908RFC 3280 Internet X.509 Public Key Infrastructure April 2002 1909 1910 1911 As specified in [RFC 1738], the scheme name is not case-sensitive 1912 (e.g., "http" is equivalent to "HTTP"). The host part is also not 1913 case-sensitive, but other components of the scheme-specific-part may 1914 be case-sensitive. When comparing URIs, conforming implementations 1915 MUST compare the scheme and host without regard to case, but assume 1916 the remainder of the scheme-specific-part is case sensitive. 1917 1918 When the subjectAltName extension contains a DN in the directoryName, 1919 the DN MUST be unique for each subject entity certified by the one CA 1920 as defined by the issuer name field. A CA MAY issue more than one 1921 certificate with the same DN to the same subject entity. 1922 1923 The subjectAltName MAY carry additional name types through the use of 1924 the otherName field. The format and semantics of the name are 1925 indicated through the OBJECT IDENTIFIER in the type-id field. The 1926 name itself is conveyed as value field in otherName. For example, 1927 Kerberos [RFC 1510] format names can be encoded into the otherName, 1928 using using a Kerberos 5 principal name OID and a SEQUENCE of the 1929 Realm and the PrincipalName. 1930 1931 Subject alternative names MAY be constrained in the same manner as 1932 subject distinguished names using the name constraints extension as 1933 described in section 4.2.1.11. 1934 1935 If the subjectAltName extension is present, the sequence MUST contain 1936 at least one entry. Unlike the subject field, conforming CAs MUST 1937 NOT issue certificates with subjectAltNames containing empty 1938 GeneralName fields. For example, an rfc822Name is represented as an 1939 IA5String. While an empty string is a valid IA5String, such an 1940 rfc822Name is not permitted by this profile. The behavior of clients 1941 that encounter such a certificate when processing a certificication 1942 path is not defined by this profile. 1943 1944 Finally, the semantics of subject alternative names that include 1945 wildcard characters (e.g., as a placeholder for a set of names) are 1946 not addressed by this specification. Applications with specific 1947 requirements MAY use such names, but they must define the semantics. 1948 1949 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 1950 1951 SubjectAltName ::= GeneralNames 1952 1953 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 1954 1955 1956 1957 1958 1959 1960 1961 1962Housley, et. al. Standards Track [Page 35] 1963 1964RFC 3280 Internet X.509 Public Key Infrastructure April 2002 1965 1966 1967 GeneralName ::= CHOICE { 1968 otherName [0] OtherName, 1969 rfc822Name [1] IA5String, 1970 dNSName [2] IA5String, 1971 x400Address [3] ORAddress, 1972 directoryName [4] Name, 1973 ediPartyName [5] EDIPartyName, 1974 uniformResourceIdentifier [6] IA5String, 1975 iPAddress [7] OCTET STRING, 1976 registeredID [8] OBJECT IDENTIFIER } 1977 1978 OtherName ::= SEQUENCE { 1979 type-id OBJECT IDENTIFIER, 1980 value [0] EXPLICIT ANY DEFINED BY type-id } 1981 1982 EDIPartyName ::= SEQUENCE { 1983 nameAssigner [0] DirectoryString OPTIONAL, 1984 partyName [1] DirectoryString } 1985 19864.2.1.8 Issuer Alternative Names 1987 1988 As with 4.2.1.7, this extension is used to associate Internet style 1989 identities with the certificate issuer. Issuer alternative names 1990 MUST be encoded as in 4.2.1.7. 1991 1992 Where present, this extension SHOULD NOT be marked critical. 1993 1994 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 1995 1996 IssuerAltName ::= GeneralNames 1997 19984.2.1.9 Subject Directory Attributes 1999 2000 The subject directory attributes extension is used to convey 2001 identification attributes (e.g., nationality) of the subject. The 2002 extension is defined as a sequence of one or more attributes. This 2003 extension MUST be non-critical. 2004 2005 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 2006 2007 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 2008 20094.2.1.10 Basic Constraints 2010 2011 The basic constraints extension identifies whether the subject of the 2012 certificate is a CA and the maximum depth of valid certification 2013 paths that include this certificate. 2014 2015 2016 2017 2018Housley, et. al. Standards Track [Page 36] 2019 2020RFC 3280 Internet X.509 Public Key Infrastructure April 2002 2021 2022 2023 The cA boolean indicates whether the certified public key belongs to 2024 a CA. If the cA boolean is not asserted, then the keyCertSign bit in 2025 the key usage extension MUST NOT be asserted. 2026 2027 The pathLenConstraint field is meaningful only if the cA boolean is 2028 asserted and the key usage extension asserts the keyCertSign bit 2029 (section 4.2.1.3). In this case, it gives the maximum number of non- 2030 self-issued intermediate certificates that may follow this 2031 certificate in a valid certification path. A certificate is self- 2032 issued if the DNs that appear in the subject and issuer fields are 2033 identical and are not empty. (Note: The last certificate in the 2034 certification path is not an intermediate certificate, and is not 2035 included in this limit. Usually, the last certificate is an end 2036 entity certificate, but it can be a CA certificate.) A 2037 pathLenConstraint of zero indicates that only one more certificate 2038 may follow in a valid certification path. Where it appears, the 2039 pathLenConstraint field MUST be greater than or equal to zero. Where 2040 pathLenConstraint does not appear, no limit is imposed. 2041 2042 This extension MUST appear as a critical extension in all CA 2043 certificates that contain public keys used to validate digital 2044 signatures on certificates. This extension MAY appear as a critical 2045 or non-critical extension in CA certificates that contain public keys 2046 used exclusively for purposes other than validating digital 2047 signatures on certificates. Such CA certificates include ones that 2048 contain public keys used exclusively for validating digital 2049 signatures on CRLs and ones that contain key management public keys 2050 used with certificate enrollment protocols. This extension MAY 2051 appear as a critical or non-critical extension in end entity 2052 certificates. 2053 2054 CAs MUST NOT include the pathLenConstraint field unless the cA 2055 boolean is asserted and the key usage extension asserts the 2056 keyCertSign bit. 2057 2058 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 2059 2060 BasicConstraints ::= SEQUENCE { 2061 cA BOOLEAN DEFAULT FALSE, 2062 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 2063 20644.2.1.11 Name Constraints 2065 2066 The name constraints extension, which MUST be used only in a CA 2067 certificate, indicates a name space within which all subject names in 2068 subsequent certificates in a certification path MUST be located. 2069 Restrictions apply to the subject distinguished name and apply to 2070 subject alternative names. Restrictions apply only when the 2071 2072 2073 2074Housley, et. al. Standards Track [Page 37] 2075 2076RFC 3280 Internet X.509 Public Key Infrastructure April 2002 2077 2078 2079 specified name form is present. If no name of the type is in the 2080 certificate, the certificate is acceptable. 2081 2082 Name constraints are not applied to certificates whose issuer and 2083 subject are identical (unless the certificate is the final 2084 certificate in the path). (This could prevent CAs that use name 2085 constraints from employing self-issued certificates to implement key 2086 rollover.) 2087 2088 Restrictions are defined in terms of permitted or excluded name 2089 subtrees. Any name matching a restriction in the excludedSubtrees 2090 field is invalid regardless of information appearing in the 2091 permittedSubtrees. This extension MUST be critical. 2092 2093 Within this profile, the minimum and maximum fields are not used with 2094 any name forms, thus minimum MUST be zero, and maximum MUST be 2095 absent. 2096 2097 For URIs, the constraint applies to the host part of the name. The 2098 constraint MAY specify a host or a domain. Examples would be 2099 "foo.bar.com"; and ".xyz.com". When the the constraint begins with 2100 a period, it MAY be expanded with one or more subdomains. That is, 2101 the constraint ".xyz.com" is satisfied by both abc.xyz.com and 2102 abc.def.xyz.com. However, the constraint ".xyz.com" is not satisfied 2103 by "xyz.com". When the constraint does not begin with a period, it 2104 specifies a host. 2105 2106 A name constraint for Internet mail addresses MAY specify a 2107 particular mailbox, all addresses at a particular host, or all 2108 mailboxes in a domain. To indicate a particular mailbox, the 2109 constraint is the complete mail address. For example, "root@xyz.com" 2110 indicates the root mailbox on the host "xyz.com". To indicate all 2111 Internet mail addresses on a particular host, the constraint is 2112 specified as the host name. For example, the constraint "xyz.com" is 2113 satisfied by any mail address at the host "xyz.com". To specify any 2114 address within a domain, the constraint is specified with a leading 2115 period (as with URIs). For example, ".xyz.com" indicates all the 2116 Internet mail addresses in the domain "xyz.com", but not Internet 2117 mail addresses on the host "xyz.com". 2118 2119 DNS name restrictions are expressed as foo.bar.com. Any DNS name 2120 that can be constructed by simply adding to the left hand side of the 2121 name satisfies the name constraint. For example, www.foo.bar.com 2122 would satisfy the constraint but foo1.bar.com would not. 2123 2124 Legacy implementations exist where an RFC 822 name is embedded in the 2125 subject distinguished name in an attribute of type EmailAddress 2126 (section 4.1.2.6). When rfc822 names are constrained, but the 2127 2128 2129 2130Housley, et. al. Standards Track [Page 38] 2131 2132RFC 3280 Internet X.509 Public Key Infrastructure April 2002 2133 2134 2135 certificate does not include a subject alternative name, the rfc822 2136 name constraint MUST be applied to the attribute of type EmailAddress 2137 in the subject distinguished name. The ASN.1 syntax for EmailAddress 2138 and the corresponding OID are supplied in Appendix A. 2139 2140 Restrictions of the form directoryName MUST be applied to the subject 2141 field in the certificate and to the subjectAltName extensions of type 2142 directoryName. Restrictions of the form x400Address MUST be applied 2143 to subjectAltName extensions of type x400Address. 2144 2145 When applying restrictions of the form directoryName, an 2146 implementation MUST compare DN attributes. At a minimum, 2147 implementations MUST perform the DN comparison rules specified in 2148 Section 4.1.2.4. CAs issuing certificates with a restriction of the 2149 form directoryName SHOULD NOT rely on implementation of the full ISO 2150 DN name comparison algorithm. This implies name restrictions MUST be 2151 stated identically to the encoding used in the subject field or 2152 subjectAltName extension. 2153 2154 The syntax of iPAddress MUST be as described in section 4.2.1.7 with 2155 the following additions specifically for Name Constraints. For IPv4 2156 addresses, the ipAddress field of generalName MUST contain eight (8) 2157 octets, encoded in the style of RFC 1519 (CIDR) to represent an 2158 address range [RFC 1519]. For IPv6 addresses, the ipAddress field 2159 MUST contain 32 octets similarly encoded. For example, a name 2160 constraint for "class C" subnet 10.9.8.0 is represented as the octets 2161 0A 09 08 00 FF FF FF 00, representing the CIDR notation 2162 10.9.8.0/255.255.255.0. 2163 2164 The syntax and semantics for name constraints for otherName, 2165 ediPartyName, and registeredID are not defined by this specification. 2166 2167 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 2168 2169 NameConstraints ::= SEQUENCE { 2170 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 2171 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 2172 2173 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 2174 2175 GeneralSubtree ::= SEQUENCE { 2176 base GeneralName, 2177 minimum [0] BaseDistance DEFAULT 0, 2178 maximum [1] BaseDistance OPTIONAL } 2179 2180 BaseDistance ::= INTEGER (0..MAX) 2181 2182 2183 2184 2185 2186Housley, et. al. Standards Track [Page 39] 2187 2188RFC 3280 Internet X.509 Public Key Infrastructure April 2002 2189 2190 21914.2.1.12 Policy Constraints 2192 2193 The policy constraints extension can be used in certificates issued 2194 to CAs. The policy constraints extension constrains path validation 2195 in two ways. It can be used to prohibit policy mapping or require 2196 that each certificate in a path contain an acceptable policy 2197 identifier. 2198 2199 If the inhibitPolicyMapping field is present, the value indicates the 2200 number of additional certificates that may appear in the path before 2201 policy mapping is no longer permitted. For example, a value of one 2202 indicates that policy mapping may be processed in certificates issued 2203 by the subject of this certificate, but not in additional 2204 certificates in the path. 2205 2206 If the requireExplicitPolicy field is present, the value of 2207 requireExplicitPolicy indicates the number of additional certificates 2208 that may appear in the path before an explicit policy is required for 2209 the entire path. When an explicit policy is required, it is 2210 necessary for all certificates in the path to contain an acceptable 2211 policy identifier in the certificate policies extension. An 2212 acceptable policy identifier is the identifier of a policy required 2213 by the user of the certification path or the identifier of a policy 2214 which has been declared equivalent through policy mapping. 2215 2216 Conforming CAs MUST NOT issue certificates where policy constraints 2217 is a empty sequence. That is, at least one of the 2218 inhibitPolicyMapping field or the requireExplicitPolicy field MUST be 2219 present. The behavior of clients that encounter a empty policy 2220 constraints field is not addressed in this profile. 2221 2222 This extension MAY be critical or non-critical. 2223 2224 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } 2225 2226 PolicyConstraints ::= SEQUENCE { 2227 requireExplicitPolicy [0] SkipCerts OPTIONAL, 2228 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 2229 2230 SkipCerts ::= INTEGER (0..MAX) 2231 22324.2.1.13 Extended Key Usage 2233 2234 This extension indicates one or more purposes for which the certified 2235 public key may be used, in addition to or in place of the basic 2236 purposes indicated in the key usage extension. In general, this 2237 extension will appear only in end entity certificates. This 2238 extension is defined as follows: 2239 2240 2241 2242Housley, et. al. Standards Track [Page 40] 2243 2244RFC 3280 Internet X.509 Public Key Infrastructure April 2002 2245 2246 2247 id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 } 2248 2249 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 2250 2251 KeyPurposeId ::= OBJECT IDENTIFIER 2252 2253 Key purposes may be defined by any organization with a need. Object 2254 identifiers used to identify key purposes MUST be assigned in 2255 accordance with IANA or ITU-T Recommendation X.660 [X.660]. 2256 2257 This extension MAY, at the option of the certificate issuer, be 2258 either critical or non-critical. 2259 2260 If the extension is present, then the certificate MUST only be used 2261 for one of the purposes indicated. If multiple purposes are 2262 indicated the application need not recognize all purposes indicated, 2263 as long as the intended purpose is present. Certificate using 2264 applications MAY require that a particular purpose be indicated in 2265 order for the certificate to be acceptable to that application. 2266 2267 If a CA includes extended key usages to satisfy such applications, 2268 but does not wish to restrict usages of the key, the CA can include 2269 the special keyPurposeID anyExtendedKeyUsage. If the 2270 anyExtendedKeyUsage keyPurposeID is present, the extension SHOULD NOT 2271 be critical. 2272 2273 If a certificate contains both a key usage extension and an extended 2274 key usage extension, then both extensions MUST be processed 2275 independently and the certificate MUST only be used for a purpose 2276 consistent with both extensions. If there is no purpose consistent 2277 with both extensions, then the certificate MUST NOT be used for any 2278 purpose. 2279 2280 The following key usage purposes are defined: 2281 2282 anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 } 2283 2284 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 2285 2286 id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } 2287 -- TLS WWW server authentication 2288 -- Key usage bits that may be consistent: digitalSignature, 2289 -- keyEncipherment or keyAgreement 2290 2291 id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } 2292 -- TLS WWW client authentication 2293 -- Key usage bits that may be consistent: digitalSignature 2294 -- and/or keyAgreement 2295 2296 2297 2298Housley, et. al. Standards Track [Page 41] 2299 2300RFC 3280 Internet X.509 Public Key Infrastructure April 2002 2301 2302 2303 id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } 2304 -- Signing of downloadable executable code 2305 -- Key usage bits that may be consistent: digitalSignature 2306 2307 id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } 2308 -- E-mail protection 2309 -- Key usage bits that may be consistent: digitalSignature, 2310 -- nonRepudiation, and/or (keyEncipherment or keyAgreement) 2311 2312 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 2313 -- Binding the hash of an object to a time 2314 -- Key usage bits that may be consistent: digitalSignature 2315 -- and/or nonRepudiation 2316 2317 id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 } 2318 -- Signing OCSP responses 2319 -- Key usage bits that may be consistent: digitalSignature 2320 -- and/or nonRepudiation 2321 23224.2.1.14 CRL Distribution Points 2323 2324 The CRL distribution points extension identifies how CRL information 2325 is obtained. The extension SHOULD be non-critical, but this profile 2326 RECOMMENDS support for this extension by CAs and applications. 2327 Further discussion of CRL management is contained in section 5. 2328 2329 The cRLDistributionPoints extension is a SEQUENCE of 2330 DistributionPoint. A DistributionPoint consists of three fields, 2331 each of which is optional: distributionPoint, reasons, and cRLIssuer. 2332 While each of these fields is optional, a DistributionPoint MUST NOT 2333 consist of only the reasons field; either distributionPoint or 2334 cRLIssuer MUST be present. If the certificate issuer is not the CRL 2335 issuer, then the cRLIssuer field MUST be present and contain the Name 2336 of the CRL issuer. If the certificate issuer is also the CRL issuer, 2337 then the cRLIssuer field MUST be omitted and the distributionPoint 2338 field MUST be present. If the distributionPoint field is omitted, 2339 cRLIssuer MUST be present and include a Name corresponding to an 2340 X.500 or LDAP directory entry where the CRL is located. 2341 2342 When the distributionPoint field is present, it contains either a 2343 SEQUENCE of general names or a single value, nameRelativeToCRLIssuer. 2344 If the cRLDistributionPoints extension contains a general name of 2345 type URI, the following semantics MUST be assumed: the URI is a 2346 pointer to the current CRL for the associated reasons and will be 2347 issued by the associated cRLIssuer. The expected values for the URI 2348 are those defined in 4.2.1.7. Processing rules for other values are 2349 not defined by this specification. 2350 2351 2352 2353 2354Housley, et. al. Standards Track [Page 42] 2355 2356RFC 3280 Internet X.509 Public Key Infrastructure April 2002 2357 2358 2359 If the DistributionPointName contains multiple values, each name 2360 describes a different mechanism to obtain the same CRL. For example, 2361 the same CRL could be available for retrieval through both LDAP and 2362 HTTP. 2363 2364 If the DistributionPointName contains the single value 2365 nameRelativeToCRLIssuer, the value provides a distinguished name 2366 fragment. The fragment is appended to the X.500 distinguished name 2367 of the CRL issuer to obtain the distribution point name. If the 2368 cRLIssuer field in the DistributionPoint is present, then the name 2369 fragment is appended to the distinguished name that it contains; 2370 otherwise, the name fragment is appended to the certificate issuer 2371 distinguished name. The DistributionPointName MUST NOT use the 2372 nameRealtiveToCRLIssuer alternative when cRLIssuer contains more than 2373 one distinguished name. 2374 2375 If the DistributionPoint omits the reasons field, the CRL MUST 2376 include revocation information for all reasons. 2377 2378 The cRLIssuer identifies the entity who signs and issues the CRL. If 2379 present, the cRLIssuer MUST contain at least one an X.500 2380 distinguished name (DN), and MAY also contain other name forms. 2381 Since the cRLIssuer is compared to the CRL issuer name, the X.501 2382 type Name MUST follow the encoding rules for the issuer name field in 2383 the certificate (section 4.1.2.4). 2384 2385 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 } 2386 2387 CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 2388 2389 DistributionPoint ::= SEQUENCE { 2390 distributionPoint [0] DistributionPointName OPTIONAL, 2391 reasons [1] ReasonFlags OPTIONAL, 2392 cRLIssuer [2] GeneralNames OPTIONAL } 2393 2394 DistributionPointName ::= CHOICE { 2395 fullName [0] GeneralNames, 2396 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 2397 2398 2399 2400 2401 2402 2403 2404 2405 2406 2407 2408 2409 2410Housley, et. al. Standards Track [Page 43] 2411 2412RFC 3280 Internet X.509 Public Key Infrastructure April 2002 2413 2414 2415 ReasonFlags ::= BIT STRING { 2416 unused (0), 2417 keyCompromise (1), 2418 cACompromise (2), 2419 affiliationChanged (3), 2420 superseded (4), 2421 cessationOfOperation (5), 2422 certificateHold (6), 2423 privilegeWithdrawn (7), 2424 aACompromise (8) } 2425 24264.2.1.15 Inhibit Any-Policy 2427 2428 The inhibit any-policy extension can be used in certificates issued 2429 to CAs. The inhibit any-policy indicates that the special anyPolicy 2430 OID, with the value { 2 5 29 32 0 }, is not considered an explicit 2431 match for other certificate policies. The value indicates the number 2432 of additional certificates that may appear in the path before 2433 anyPolicy is no longer permitted. For example, a value of one 2434 indicates that anyPolicy may be processed in certificates issued by 2435 the subject of this certificate, but not in additional certificates 2436 in the path. 2437 2438 This extension MUST be critical. 2439 2440 id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 } 2441 2442 InhibitAnyPolicy ::= SkipCerts 2443 2444 SkipCerts ::= INTEGER (0..MAX) 2445 24464.2.1.16 Freshest CRL (a.k.a. Delta CRL Distribution Point) 2447 2448 The freshest CRL extension identifies how delta CRL information is 2449 obtained. The extension MUST be non-critical. Further discussion of 2450 CRL management is contained in section 5. 2451 2452 The same syntax is used for this extension and the 2453 cRLDistributionPoints extension, and is described in section 2454 4.2.1.14. The same conventions apply to both extensions. 2455 2456 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } 2457 2458 FreshestCRL ::= CRLDistributionPoints 2459 2460 2461 2462 2463 2464 2465 2466Housley, et. al. Standards Track [Page 44] 2467 2468RFC 3280 Internet X.509 Public Key Infrastructure April 2002 2469 2470 24714.2.2 Private Internet Extensions 2472 2473 This section defines two extensions for use in the Internet Public 2474 Key Infrastructure. These extensions may be used to direct 2475 applications to on-line information about the issuing CA or the 2476 subject. As the information may be available in multiple forms, each 2477 extension is a sequence of IA5String values, each of which represents 2478 a URI. The URI implicitly specifies the location and format of the 2479 information and the method for obtaining the information. 2480 2481 An object identifier is defined for the private extension. The 2482 object identifier associated with the private extension is defined 2483 under the arc id-pe within the arc id-pkix. Any future extensions 2484 defined for the Internet PKI are also expected to be defined under 2485 the arc id-pe. 2486 2487 id-pkix OBJECT IDENTIFIER ::= 2488 { iso(1) identified-organization(3) dod(6) internet(1) 2489 security(5) mechanisms(5) pkix(7) } 2490 2491 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 2492 24934.2.2.1 Authority Information Access 2494 2495 The authority information access extension indicates how to access CA 2496 information and services for the issuer of the certificate in which 2497 the extension appears. Information and services may include on-line 2498 validation services and CA policy data. (The location of CRLs is not 2499 specified in this extension; that information is provided by the 2500 cRLDistributionPoints extension.) This extension may be included in 2501 end entity or CA certificates, and it MUST be non-critical. 2502 2503 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 2504 2505 AuthorityInfoAccessSyntax ::= 2506 SEQUENCE SIZE (1..MAX) OF AccessDescription 2507 2508 AccessDescription ::= SEQUENCE { 2509 accessMethod OBJECT IDENTIFIER, 2510 accessLocation GeneralName } 2511 2512 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 2513 2514 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 2515 2516 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 2517 2518 2519 2520 2521 2522Housley, et. al. Standards Track [Page 45] 2523 2524RFC 3280 Internet X.509 Public Key Infrastructure April 2002 2525 2526 2527 Each entry in the sequence AuthorityInfoAccessSyntax describes the 2528 format and location of additional information provided by the CA that 2529 issued the certificate in which this extension appears. The type and 2530 format of the information is specified by the accessMethod field; the 2531 accessLocation field specifies the location of the information. The 2532 retrieval mechanism may be implied by the accessMethod or specified 2533 by accessLocation. 2534 2535 This profile defines two accessMethod OIDs: id-ad-caIssuers and 2536 id-ad-ocsp. 2537 2538 The id-ad-caIssuers OID is used when the additional information lists 2539 CAs that have issued certificates superior to the CA that issued the 2540 certificate containing this extension. The referenced CA issuers 2541 description is intended to aid certificate users in the selection of 2542 a certification path that terminates at a point trusted by the 2543 certificate user. 2544 2545 When id-ad-caIssuers appears as accessMethod, the accessLocation 2546 field describes the referenced description server and the access 2547 protocol to obtain the referenced description. The accessLocation 2548 field is defined as a GeneralName, which can take several forms. 2549 Where the information is available via http, ftp, or ldap, 2550 accessLocation MUST be a uniformResourceIdentifier. Where the 2551 information is available via the Directory Access Protocol (DAP), 2552 accessLocation MUST be a directoryName. The entry for that 2553 directoryName contains CA certificates in the crossCertificatePair 2554 attribute. When the information is available via electronic mail, 2555 accessLocation MUST be an rfc822Name. The semantics of other 2556 id-ad-caIssuers accessLocation name forms are not defined. 2557 2558 The id-ad-ocsp OID is used when revocation information for the 2559 certificate containing this extension is available using the Online 2560 Certificate Status Protocol (OCSP) [RFC 2560]. 2561 2562 When id-ad-ocsp appears as accessMethod, the accessLocation field is 2563 the location of the OCSP responder, using the conventions defined in 2564 [RFC 2560]. 2565 2566 Additional access descriptors may be defined in other PKIX 2567 specifications. 2568 25694.2.2.2 Subject Information Access 2570 2571 The subject information access extension indicates how to access 2572 information and services for the subject of the certificate in which 2573 the extension appears. When the subject is a CA, information and 2574 services may include certificate validation services and CA policy 2575 2576 2577 2578Housley, et. al. Standards Track [Page 46] 2579 2580RFC 3280 Internet X.509 Public Key Infrastructure April 2002 2581 2582 2583 data. When the subject is an end entity, the information describes 2584 the type of services offered and how to access them. In this case, 2585 the contents of this extension are defined in the protocol 2586 specifications for the suported services. This extension may be 2587 included in subject or CA certificates, and it MUST be non-critical. 2588 2589 id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 } 2590 2591 SubjectInfoAccessSyntax ::= 2592 SEQUENCE SIZE (1..MAX) OF AccessDescription 2593 2594 AccessDescription ::= SEQUENCE { 2595 accessMethod OBJECT IDENTIFIER, 2596 accessLocation GeneralName } 2597 2598 Each entry in the sequence SubjectInfoAccessSyntax describes the 2599 format and location of additional information provided by the subject 2600 of the certificate in which this extension appears. The type and 2601 format of the information is specified by the accessMethod field; the 2602 accessLocation field specifies the location of the information. The 2603 retrieval mechanism may be implied by the accessMethod or specified 2604 by accessLocation. 2605 2606 This profile defines one access method to be used when the subject is 2607 a CA, and one access method to be used when the subject is an end 2608 entity. Additional access methods may be defined in the future in 2609 the protocol specifications for other services. 2610 2611 The id-ad-caRepository OID is used when the subject is a CA, and 2612 publishes its certificates and CRLs (if issued) in a repository. The 2613 accessLocation field is defined as a GeneralName, which can take 2614 several forms. Where the information is available via http, ftp, or 2615 ldap, accessLocation MUST be a uniformResourceIdentifier. Where the 2616 information is available via the directory access protocol (dap), 2617 accessLocation MUST be a directoryName. When the information is 2618 available via electronic mail, accessLocation MUST be an rfc822Name. 2619 The semantics of other name forms of of accessLocation (when 2620 accessMethod is id-ad-caRepository) are not defined by this 2621 specification. 2622 2623 The id-ad-timeStamping OID is used when the subject offers 2624 timestamping services using the Time Stamp Protocol defined in 2625 [PKIXTSA]. Where the timestamping services are available via http or 2626 ftp, accessLocation MUST be a uniformResourceIdentifier. Where the 2627 timestamping services are available via electronic mail, 2628 accessLocation MUST be an rfc822Name. Where timestamping services 2629 2630 2631 2632 2633 2634Housley, et. al. Standards Track [Page 47] 2635 2636RFC 3280 Internet X.509 Public Key Infrastructure April 2002 2637 2638 2639 are available using TCP/IP, the dNSName or ipAddress name forms may 2640 be used. The semantics of other name forms of accessLocation (when 2641 accessMethod is id-ad-timeStamping) are not defined by this 2642 specification. 2643 2644 Additional access descriptors may be defined in other PKIX 2645 specifications. 2646 2647 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 2648 2649 id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 } 2650 2651 id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 } 2652 26535 CRL and CRL Extensions Profile 2654 2655 As discussed above, one goal of this X.509 v2 CRL profile is to 2656 foster the creation of an interoperable and reusable Internet PKI. 2657 To achieve this goal, guidelines for the use of extensions are 2658 specified, and some assumptions are made about the nature of 2659 information included in the CRL. 2660 2661 CRLs may be used in a wide range of applications and environments 2662 covering a broad spectrum of interoperability goals and an even 2663 broader spectrum of operational and assurance requirements. This 2664 profile establishes a common baseline for generic applications 2665 requiring broad interoperability. The profile defines a set of 2666 information that can be expected in every CRL. Also, the profile 2667 defines common locations within the CRL for frequently used 2668 attributes as well as common representations for these attributes. 2669 2670 CRL issuers issue CRLs. In general, the CRL issuer is the CA. CAs 2671 publish CRLs to provide status information about the certificates 2672 they issued. However, a CA may delegate this responsibility to 2673 another trusted authority. Whenever the CRL issuer is not the CA 2674 that issued the certificates, the CRL is referred to as an indirect 2675 CRL. 2676 2677 Each CRL has a particular scope. The CRL scope is the set of 2678 certificates that could appear on a given CRL. For example, the 2679 scope could be "all certificates issued by CA X", "all CA 2680 certificates issued by CA X", "all certificates issued by CA X that 2681 have been revoked for reasons of key compromise and CA compromise", 2682 or could be a set of certificates based on arbitrary local 2683 information, such as "all certificates issued to the NIST employees 2684 located in Boulder". 2685 2686 2687 2688 2689 2690Housley, et. al. Standards Track [Page 48] 2691 2692RFC 3280 Internet X.509 Public Key Infrastructure April 2002 2693 2694 2695 A complete CRL lists all unexpired certificates, within its scope, 2696 that have been revoked for one of the revocation reasons covered by 2697 the CRL scope. The CRL issuer MAY also generate delta CRLs. A delta 2698 CRL only lists those certificates, within its scope, whose revocation 2699 status has changed since the issuance of a referenced complete CRL. 2700 The referenced complete CRL is referred to as a base CRL. The scope 2701 of a delta CRL MUST be the same as the base CRL that it references. 2702 2703 This profile does not define any private Internet CRL extensions or 2704 CRL entry extensions. 2705 2706 Environments with additional or special purpose requirements may 2707 build on this profile or may replace it. 2708 2709 Conforming CAs are not required to issue CRLs if other revocation or 2710 certificate status mechanisms are provided. When CRLs are issued, 2711 the CRLs MUST be version 2 CRLs, include the date by which the next 2712 CRL will be issued in the nextUpdate field (section 5.1.2.5), include 2713 the CRL number extension (section 5.2.3), and include the authority 2714 key identifier extension (section 5.2.1). Conforming applications 2715 that support CRLs are REQUIRED to process both version 1 and version 2716 2 complete CRLs that provide revocation information for all 2717 certificates issued by one CA. Conforming applications are NOT 2718 REQUIRED to support processing of delta CRLs, indirect CRLs, or CRLs 2719 with a scope other than all certificates issued by one CA. 2720 27215.1 CRL Fields 2722 2723 The X.509 v2 CRL syntax is as follows. For signature calculation, 2724 the data that is to be signed is ASN.1 DER encoded. ASN.1 DER 2725 encoding is a tag, length, value encoding system for each element. 2726 2727 CertificateList ::= SEQUENCE { 2728 tbsCertList TBSCertList, 2729 signatureAlgorithm AlgorithmIdentifier, 2730 signatureValue BIT STRING } 2731 2732 2733 2734 2735 2736 2737 2738 2739 2740 2741 2742 2743 2744 2745 2746Housley, et. al. Standards Track [Page 49] 2747 2748RFC 3280 Internet X.509 Public Key Infrastructure April 2002 2749 2750 2751 TBSCertList ::= SEQUENCE { 2752 version Version OPTIONAL, 2753 -- if present, MUST be v2 2754 signature AlgorithmIdentifier, 2755 issuer Name, 2756 thisUpdate Time, 2757 nextUpdate Time OPTIONAL, 2758 revokedCertificates SEQUENCE OF SEQUENCE { 2759 userCertificate CertificateSerialNumber, 2760 revocationDate Time, 2761 crlEntryExtensions Extensions OPTIONAL 2762 -- if present, MUST be v2 2763 } OPTIONAL, 2764 crlExtensions [0] EXPLICIT Extensions OPTIONAL 2765 -- if present, MUST be v2 2766 } 2767 2768 -- Version, Time, CertificateSerialNumber, and Extensions 2769 -- are all defined in the ASN.1 in section 4.1 2770 2771 -- AlgorithmIdentifier is defined in section 4.1.1.2 2772 2773 The following items describe the use of the X.509 v2 CRL in the 2774 Internet PKI. 2775 27765.1.1 CertificateList Fields 2777 2778 The CertificateList is a SEQUENCE of three required fields. The 2779 fields are described in detail in the following subsections. 2780 27815.1.1.1 tbsCertList 2782 2783 The first field in the sequence is the tbsCertList. This field is 2784 itself a sequence containing the name of the issuer, issue date, 2785 issue date of the next list, the optional list of revoked 2786 certificates, and optional CRL extensions. When there are no revoked 2787 certificates, the revoked certificates list is absent. When one or 2788 more certificates are revoked, each entry on the revoked certificate 2789 list is defined by a sequence of user certificate serial number, 2790 revocation date, and optional CRL entry extensions. 2791 27925.1.1.2 signatureAlgorithm 2793 2794 The signatureAlgorithm field contains the algorithm identifier for 2795 the algorithm used by the CRL issuer to sign the CertificateList. 2796 The field is of type AlgorithmIdentifier, which is defined in section 2797 4.1.1.2. [PKIXALGS] lists the supported algorithms for this 2798 specification, but other signature algorithms MAY also be supported. 2799 2800 2801 2802Housley, et. al. Standards Track [Page 50] 2803 2804RFC 3280 Internet X.509 Public Key Infrastructure April 2002 2805 2806 2807 This field MUST contain the same algorithm identifier as the 2808 signature field in the sequence tbsCertList (section 5.1.2.2). 2809 28105.1.1.3 signatureValue 2811 2812 The signatureValue field contains a digital signature computed upon 2813 the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded tbsCertList 2814 is used as the input to the signature function. This signature value 2815 is encoded as a BIT STRING and included in the CRL signatureValue 2816 field. The details of this process are specified for each of the 2817 supported algorithms in [PKIXALGS]. 2818 2819 CAs that are also CRL issuers MAY use one private key to digitally 2820 sign certificates and CRLs, or MAY use separate private keys to 2821 digitally sign certificates and CRLs. When separate private keys are 2822 employed, each of the public keys associated with these private keys 2823 is placed in a separate certificate, one with the keyCertSign bit set 2824 in the key usage extension, and one with the cRLSign bit set in the 2825 key usage extension (section 4.2.1.3). When separate private keys 2826 are employed, certificates issued by the CA contain one authority key 2827 identifier, and the corresponding CRLs contain a different authority 2828 key identifier. The use of separate CA certificates for validation 2829 of certificate signatures and CRL signatures can offer improved 2830 security characteristics; however, it imposes a burden on 2831 applications, and it might limit interoperability. Many applications 2832 construct a certification path, and then validate the certification 2833 path (section 6). CRL checking in turn requires a separate 2834 certification path to be constructed and validated for the CA's CRL 2835 signature validation certificate. Applications that perform CRL 2836 checking MUST support certification path validation when certificates 2837 and CRLs are digitally signed with the same CA private key. These 2838 applications SHOULD support certification path validation when 2839 certificates and CRLs are digitally signed with different CA private 2840 keys. 2841 28425.1.2 Certificate List "To Be Signed" 2843 2844 The certificate list to be signed, or TBSCertList, is a sequence of 2845 required and optional fields. The required fields identify the CRL 2846 issuer, the algorithm used to sign the CRL, the date and time the CRL 2847 was issued, and the date and time by which the CRL issuer will issue 2848 the next CRL. 2849 2850 Optional fields include lists of revoked certificates and CRL 2851 extensions. The revoked certificate list is optional to support the 2852 case where a CA has not revoked any unexpired certificates that it 2853 2854 2855 2856 2857 2858Housley, et. al. Standards Track [Page 51] 2859 2860RFC 3280 Internet X.509 Public Key Infrastructure April 2002 2861 2862 2863 has issued. The profile requires conforming CRL issuers to use the 2864 CRL number and authority key identifier CRL extensions in all CRLs 2865 issued. 2866 28675.1.2.1 Version 2868 2869 This optional field describes the version of the encoded CRL. When 2870 extensions are used, as required by this profile, this field MUST be 2871 present and MUST specify version 2 (the integer value is 1). 2872 28735.1.2.2 Signature 2874 2875 This field contains the algorithm identifier for the algorithm used 2876 to sign the CRL. [PKIXALGS] lists OIDs for the most popular 2877 signature algorithms used in the Internet PKI. 2878 2879 This field MUST contain the same algorithm identifier as the 2880 signatureAlgorithm field in the sequence CertificateList (section 2881 5.1.1.2). 2882 28835.1.2.3 Issuer Name 2884 2885 The issuer name identifies the entity who has signed and issued the 2886 CRL. The issuer identity is carried in the issuer name field. 2887 Alternative name forms may also appear in the issuerAltName extension 2888 (section 5.2.2). The issuer name field MUST contain an X.500 2889 distinguished name (DN). The issuer name field is defined as the 2890 X.501 type Name, and MUST follow the encoding rules for the issuer 2891 name field in the certificate (section 4.1.2.4). 2892 28935.1.2.4 This Update 2894 2895 This field indicates the issue date of this CRL. ThisUpdate may be 2896 encoded as UTCTime or GeneralizedTime. 2897 2898 CRL issuers conforming to this profile MUST encode thisUpdate as 2899 UTCTime for dates through the year 2049. CRL issuers conforming to 2900 this profile MUST encode thisUpdate as GeneralizedTime for dates in 2901 the year 2050 or later. 2902 2903 Where encoded as UTCTime, thisUpdate MUST be specified and 2904 interpreted as defined in section 4.1.2.5.1. Where encoded as 2905 GeneralizedTime, thisUpdate MUST be specified and interpreted as 2906 defined in section 4.1.2.5.2. 2907 2908 2909 2910 2911 2912 2913 2914Housley, et. al. Standards Track [Page 52] 2915 2916RFC 3280 Internet X.509 Public Key Infrastructure April 2002 2917 2918 29195.1.2.5 Next Update 2920 2921 This field indicates the date by which the next CRL will be issued. 2922 The next CRL could be issued before the indicated date, but it will 2923 not be issued any later than the indicated date. CRL issuers SHOULD 2924 issue CRLs with a nextUpdate time equal to or later than all previous 2925 CRLs. nextUpdate may be encoded as UTCTime or GeneralizedTime. 2926 2927 This profile requires inclusion of nextUpdate in all CRLs issued by 2928 conforming CRL issuers. Note that the ASN.1 syntax of TBSCertList 2929 describes this field as OPTIONAL, which is consistent with the ASN.1 2930 structure defined in [X.509]. The behavior of clients processing 2931 CRLs which omit nextUpdate is not specified by this profile. 2932 2933 CRL issuers conforming to this profile MUST encode nextUpdate as 2934 UTCTime for dates through the year 2049. CRL issuers conforming to 2935 this profile MUST encode nextUpdate as GeneralizedTime for dates in 2936 the year 2050 or later. 2937 2938 Where encoded as UTCTime, nextUpdate MUST be specified and 2939 interpreted as defined in section 4.1.2.5.1. Where encoded as 2940 GeneralizedTime, nextUpdate MUST be specified and interpreted as 2941 defined in section 4.1.2.5.2. 2942 29435.1.2.6 Revoked Certificates 2944 2945 When there are no revoked certificates, the revoked certificates list 2946 MUST be absent. Otherwise, revoked certificates are listed by their 2947 serial numbers. Certificates revoked by the CA are uniquely 2948 identified by the certificate serial number. The date on which the 2949 revocation occurred is specified. The time for revocationDate MUST 2950 be expressed as described in section 5.1.2.4. Additional information 2951 may be supplied in CRL entry extensions; CRL entry extensions are 2952 discussed in section 5.3. 2953 29545.1.2.7 Extensions 2955 2956 This field may only appear if the version is 2 (section 5.1.2.1). If 2957 present, this field is a sequence of one or more CRL extensions. CRL 2958 extensions are discussed in section 5.2. 2959 29605.2 CRL Extensions 2961 2962 The extensions defined by ANSI X9, ISO/IEC, and ITU-T for X.509 v2 2963 CRLs [X.509] [X9.55] provide methods for associating additional 2964 attributes with CRLs. The X.509 v2 CRL format also allows 2965 communities to define private extensions to carry information unique 2966 to those communities. Each extension in a CRL may be designated as 2967 2968 2969 2970Housley, et. al. Standards Track [Page 53] 2971 2972RFC 3280 Internet X.509 Public Key Infrastructure April 2002 2973 2974 2975 critical or non-critical. A CRL validation MUST fail if it 2976 encounters a critical extension which it does not know how to 2977 process. However, an unrecognized non-critical extension may be 2978 ignored. The following subsections present those extensions used 2979 within Internet CRLs. Communities may elect to include extensions in 2980 CRLs which are not defined in this specification. However, caution 2981 should be exercised in adopting any critical extensions in CRLs which 2982 might be used in a general context. 2983 2984 Conforming CRL issuers are REQUIRED to include the authority key 2985 identifier (section 5.2.1) and the CRL number (section 5.2.3) 2986 extensions in all CRLs issued. 2987 29885.2.1 Authority Key Identifier 2989 2990 The authority key identifier extension provides a means of 2991 identifying the public key corresponding to the private key used to 2992 sign a CRL. The identification can be based on either the key 2993 identifier (the subject key identifier in the CRL signer's 2994 certificate) or on the issuer name and serial number. This extension 2995 is especially useful where an issuer has more than one signing key, 2996 either due to multiple concurrent key pairs or due to changeover. 2997 2998 Conforming CRL issuers MUST use the key identifier method, and MUST 2999 include this extension in all CRLs issued. 3000 3001 The syntax for this CRL extension is defined in section 4.2.1.1. 3002 30035.2.2 Issuer Alternative Name 3004 3005 The issuer alternative names extension allows additional identities 3006 to be associated with the issuer of the CRL. Defined options include 3007 an rfc822 name (electronic mail address), a DNS name, an IP address, 3008 and a URI. Multiple instances of a name and multiple name forms may 3009 be included. Whenever such identities are used, the issuer 3010 alternative name extension MUST be used; however, a DNS name MAY be 3011 represented in the issuer field using the domainComponent attribute 3012 as described in section 4.1.2.4. 3013 3014 The issuerAltName extension SHOULD NOT be marked critical. 3015 3016 The OID and syntax for this CRL extension are defined in section 3017 4.2.1.8. 3018 3019 3020 3021 3022 3023 3024 3025 3026Housley, et. al. Standards Track [Page 54] 3027 3028RFC 3280 Internet X.509 Public Key Infrastructure April 2002 3029 3030 30315.2.3 CRL Number 3032 3033 The CRL number is a non-critical CRL extension which conveys a 3034 monotonically increasing sequence number for a given CRL scope and 3035 CRL issuer. This extension allows users to easily determine when a 3036 particular CRL supersedes another CRL. CRL numbers also support the 3037 identification of complementary complete CRLs and delta CRLs. CRL 3038 issuers conforming to this profile MUST include this extension in all 3039 CRLs. 3040 3041 If a CRL issuer generates delta CRLs in addition to complete CRLs for 3042 a given scope, the complete CRLs and delta CRLs MUST share one 3043 numbering sequence. If a delta CRL and a complete CRL that cover the 3044 same scope are issued at the same time, they MUST have the same CRL 3045 number and provide the same revocation information. That is, the 3046 combination of the delta CRL and an acceptable complete CRL MUST 3047 provide the same revocation information as the simultaneously issued 3048 complete CRL. 3049 3050 If a CRL issuer generates two CRLs (two complete CRLs, two delta 3051 CRLs, or a complete CRL and a delta CRL) for the same scope at 3052 different times, the two CRLs MUST NOT have the same CRL number. 3053 That is, if the this update field (section 5.1.2.4) in the two CRLs 3054 are not identical, the CRL numbers MUST be different. 3055 3056 Given the requirements above, CRL numbers can be expected to contain 3057 long integers. CRL verifiers MUST be able to handle CRLNumber values 3058 up to 20 octets. Conformant CRL issuers MUST NOT use CRLNumber 3059 values longer than 20 octets. 3060 3061 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 3062 3063 CRLNumber ::= INTEGER (0..MAX) 3064 30655.2.4 Delta CRL Indicator 3066 3067 The delta CRL indicator is a critical CRL extension that identifies a 3068 CRL as being a delta CRL. Delta CRLs contain updates to revocation 3069 information previously distributed, rather than all the information 3070 that would appear in a complete CRL. The use of delta CRLs can 3071 significantly reduce network load and processing time in some 3072 environments. Delta CRLs are generally smaller than the CRLs they 3073 update, so applications that obtain delta CRLs consume less network 3074 bandwidth than applications that obtain the corresponding complete 3075 CRLs. Applications which store revocation information in a format 3076 other than the CRL structure can add new revocation information to 3077 the local database without reprocessing information. 3078 3079 3080 3081 3082Housley, et. al. Standards Track [Page 55] 3083 3084RFC 3280 Internet X.509 Public Key Infrastructure April 2002 3085 3086 3087 The delta CRL indicator extension contains the single value of type 3088 BaseCRLNumber. The CRL number identifies the CRL, complete for a 3089 given scope, that was used as the starting point in the generation of 3090 this delta CRL. A conforming CRL issuer MUST publish the referenced 3091 base CRL as a complete CRL. The delta CRL contains all updates to 3092 the revocation status for that same scope. The combination of a 3093 delta CRL plus the referenced base CRL is equivalent to a complete 3094 CRL, for the applicable scope, at the time of publication of the 3095 delta CRL. 3096 3097 When a conforming CRL issuer generates a delta CRL, the delta CRL 3098 MUST include a critical delta CRL indicator extension. 3099 3100 When a delta CRL is issued, it MUST cover the same set of reasons and 3101 the same set of certificates that were covered by the base CRL it 3102 references. That is, the scope of the delta CRL MUST be the same as 3103 the scope of the complete CRL referenced as the base. The referenced 3104 base CRL and the delta CRL MUST omit the issuing distribution point 3105 extension or contain identical issuing distribution point extensions. 3106 Further, the CRL issuer MUST use the same private key to sign the 3107 delta CRL and any complete CRL that it can be used to update. 3108 3109 An application that supports delta CRLs can construct a CRL that is 3110 complete for a given scope by combining a delta CRL for that scope 3111 with either an issued CRL that is complete for that scope or a 3112 locally constructed CRL that is complete for that scope. 3113 3114 When a delta CRL is combined with a complete CRL or a locally 3115 constructed CRL, the resulting locally constructed CRL has the CRL 3116 number specified in the CRL number extension found in the delta CRL 3117 used in its construction. In addition, the resulting locally 3118 constructed CRL has the thisUpdate and nextUpdate times specified in 3119 the corresponding fields of the delta CRL used in its construction. 3120 In addition, the locally constructed CRL inherits the issuing 3121 distribution point from the delta CRL. 3122 3123 A complete CRL and a delta CRL MAY be combined if the following four 3124 conditions are satisfied: 3125 3126 (a) The complete CRL and delta CRL have the same issuer. 3127 3128 (b) The complete CRL and delta CRL have the same scope. The two 3129 CRLs have the same scope if either of the following conditions are 3130 met: 3131 3132 (1) The issuingDistributionPoint extension is omitted from 3133 both the complete CRL and the delta CRL. 3134 3135 3136 3137 3138Housley, et. al. Standards Track [Page 56] 3139 3140RFC 3280 Internet X.509 Public Key Infrastructure April 2002 3141 3142 3143 (2) The issuingDistributionPoint extension is present in both 3144 the complete CRL and the delta CRL, and the values for each of 3145 the fields in the extensions are the same in both CRLs. 3146 3147 (c) The CRL number of the complete CRL is equal to or greater 3148 than the BaseCRLNumber specified in the delta CRL. That is, the 3149 complete CRL contains (at a minimum) all the revocation 3150 information held by the referenced base CRL. 3151 3152 (d) The CRL number of the complete CRL is less than the CRL 3153 number of the delta CRL. That is, the delta CRL follows the 3154 complete CRL in the numbering sequence. 3155 3156 CRL issuers MUST ensure that the combination of a delta CRL and any 3157 appropriate complete CRL accurately reflects the current revocation 3158 status. The CRL issuer MUST include an entry in the delta CRL for 3159 each certificate within the scope of the delta CRL whose status has 3160 changed since the generation of the referenced base CRL: 3161 3162 (a) If the certificate is revoked for a reason included in the 3163 scope of the CRL, list the certificate as revoked. 3164 3165 (b) If the certificate is valid and was listed on the referenced 3166 base CRL or any subsequent CRL with reason code certificateHold, 3167 and the reason code certificateHold is included in the scope of 3168 the CRL, list the certificate with the reason code removeFromCRL. 3169 3170 (c) If the certificate is revoked for a reason outside the scope 3171 of the CRL, but the certificate was listed on the referenced base 3172 CRL or any subsequent CRL with a reason code included in the scope 3173 of this CRL, list the certificate as revoked but omit the reason 3174 code. 3175 3176 (d) If the certificate is revoked for a reason outside the scope 3177 of the CRL and the certificate was neither listed on the 3178 referenced base CRL nor any subsequent CRL with a reason code 3179 included in the scope of this CRL, do not list the certificate on 3180 this CRL. 3181 3182 The status of a certificate is considered to have changed if it is 3183 revoked, placed on hold, released from hold, or if its revocation 3184 reason changes. 3185 3186 It is appropriate to list a certificate with reason code 3187 removeFromCRL on a delta CRL even if the certificate was not on hold 3188 in the referenced base CRL. If the certificate was placed on hold in 3189 3190 3191 3192 3193 3194Housley, et. al. Standards Track [Page 57] 3195 3196RFC 3280 Internet X.509 Public Key Infrastructure April 2002 3197 3198 3199 any CRL issued after the base but before this delta CRL and then 3200 released from hold, it MUST be listed on the delta CRL with 3201 revocation reason removeFromCRL. 3202 3203 A CRL issuer MAY optionally list a certificate on a delta CRL with 3204 reason code removeFromCRL if the notAfter time specified in the 3205 certificate precedes the thisUpdate time specified in the delta CRL 3206 and the certificate was listed on the referenced base CRL or in any 3207 CRL issued after the base but before this delta CRL. 3208 3209 If a certificate revocation notice first appears on a delta CRL, then 3210 it is possible for the certificate validity period to expire before 3211 the next complete CRL for the same scope is issued. In this case, 3212 the revocation notice MUST be included in all subsequent delta CRLs 3213 until the revocation notice is included on at least one explicitly 3214 issued complete CRL for this scope. 3215 3216 An application that supports delta CRLs MUST be able to construct a 3217 current complete CRL by combining a previously issued complete CRL 3218 and the most current delta CRL. An application that supports delta 3219 CRLs MAY also be able to construct a current complete CRL by 3220 combining a previously locally constructed complete CRL and the 3221 current delta CRL. A delta CRL is considered to be the current one 3222 if the current time is between the times contained in the thisUpdate 3223 and nextUpdate fields. Under some circumstances, the CRL issuer may 3224 publish one or more delta CRLs before indicated by the nextUpdate 3225 field. If more than one current delta CRL for a given scope is 3226 encountered, the application SHOULD consider the one with the latest 3227 value in thisUpdate to be the most current one. 3228 3229 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 3230 3231 BaseCRLNumber ::= CRLNumber 3232 32335.2.5 Issuing Distribution Point 3234 3235 The issuing distribution point is a critical CRL extension that 3236 identifies the CRL distribution point and scope for a particular CRL, 3237 and it indicates whether the CRL covers revocation for end entity 3238 certificates only, CA certificates only, attribute certificates only, 3239 3240 or a limited set of reason codes. Although the extension is 3241 critical, conforming implementations are not required to support this 3242 extension. 3243 3244 3245 3246 3247 3248 3249 3250Housley, et. al. Standards Track [Page 58] 3251 3252RFC 3280 Internet X.509 Public Key Infrastructure April 2002 3253 3254 3255 The CRL is signed using the CRL issuer's private key. CRL 3256 Distribution Points do not have their own key pairs. If the CRL is 3257 stored in the X.500 Directory, it is stored in the Directory entry 3258 corresponding to the CRL distribution point, which may be different 3259 than the Directory entry of the CRL issuer. 3260 3261 The reason codes associated with a distribution point MUST be 3262 specified in onlySomeReasons. If onlySomeReasons does not appear, 3263 the distribution point MUST contain revocations for all reason codes. 3264 CAs may use CRL distribution points to partition the CRL on the basis 3265 of compromise and routine revocation. In this case, the revocations 3266 with reason code keyCompromise (1), cACompromise (2), and 3267 aACompromise (8) appear in one distribution point, and the 3268 revocations with other reason codes appear in another distribution 3269 point. 3270 3271 If the distributionPoint field is present and contains a URI, the 3272 following semantics MUST be assumed: the object is a pointer to the 3273 most current CRL issued by this CRL issuer. The URI schemes ftp, 3274 http, mailto [RFC1738] and ldap [RFC1778] are defined for this 3275 purpose. The URI MUST be an absolute pathname, not a relative 3276 pathname, and MUST specify the host. 3277 3278 If the distributionPoint field is absent, the CRL MUST contain 3279 entries for all revoked unexpired certificates issued by the CRL 3280 issuer, if any, within the scope of the CRL. 3281 3282 The CRL issuer MUST assert the indirectCRL boolean, if the scope of 3283 the CRL includes certificates issued by authorities other than the 3284 CRL issuer. The authority responsible for each entry is indicated by 3285 the certificate issuer CRL entry extension (section 5.3.4). 3286 3287 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 3288 3289 issuingDistributionPoint ::= SEQUENCE { 3290 distributionPoint [0] DistributionPointName OPTIONAL, 3291 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 3292 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 3293 onlySomeReasons [3] ReasonFlags OPTIONAL, 3294 indirectCRL [4] BOOLEAN DEFAULT FALSE, 3295 onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE } 3296 32975.2.6 Freshest CRL (a.k.a. Delta CRL Distribution Point) 3298 3299 The freshest CRL extension identifies how delta CRL information for 3300 this complete CRL is obtained. The extension MUST be non-critical. 3301 This extension MUST NOT appear in delta CRLs. 3302 3303 3304 3305 3306Housley, et. al. Standards Track [Page 59] 3307 3308RFC 3280 Internet X.509 Public Key Infrastructure April 2002 3309 3310 3311 The same syntax is used for this extension as the 3312 cRLDistributionPoints certificate extension, and is described in 3313 section 4.2.1.14. However, only the distribution point field is 3314 meaningful in this context. The reasons and CRLIssuer fields MUST be 3315 omitted from this CRL extension. 3316 3317 Each distribution point name provides the location at which a delta 3318 CRL for this complete CRL can be found. The scope of these delta 3319 CRLs MUST be the same as the scope of this complete CRL. The 3320 contents of this CRL extension are only used to locate delta CRLs; 3321 the contents are not used to validate the CRL or the referenced delta 3322 CRLs. The encoding conventions defined for distribution points in 3323 section 4.2.1.14 apply to this extension. 3324 3325 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } 3326 3327 FreshestCRL ::= CRLDistributionPoints 3328 33295.3 CRL Entry Extensions 3330 3331 The CRL entry extensions defined by ISO/IEC, ITU-T, and ANSI X9 for 3332 X.509 v2 CRLs provide methods for associating additional attributes 3333 with CRL entries [X.509] [X9.55]. The X.509 v2 CRL format also 3334 allows communities to define private CRL entry extensions to carry 3335 information unique to those communities. Each extension in a CRL 3336 entry may be designated as critical or non-critical. A CRL 3337 validation MUST fail if it encounters a critical CRL entry extension 3338 which it does not know how to process. However, an unrecognized non- 3339 critical CRL entry extension may be ignored. The following 3340 subsections present recommended extensions used within Internet CRL 3341 entries and standard locations for information. Communities may 3342 elect to use additional CRL entry extensions; however, caution should 3343 be exercised in adopting any critical extensions in CRL entries which 3344 might be used in a general context. 3345 3346 All CRL entry extensions used in this specification are non-critical. 3347 Support for these extensions is optional for conforming CRL issuers 3348 and applications. However, CRL issuers SHOULD include reason codes 3349 (section 5.3.1) and invalidity dates (section 5.3.3) whenever this 3350 information is available. 3351 33525.3.1 Reason Code 3353 3354 The reasonCode is a non-critical CRL entry extension that identifies 3355 the reason for the certificate revocation. CRL issuers are strongly 3356 encouraged to include meaningful reason codes in CRL entries; 3357 however, the reason code CRL entry extension SHOULD be absent instead 3358 of using the unspecified (0) reasonCode value. 3359 3360 3361 3362Housley, et. al. Standards Track [Page 60] 3363 3364RFC 3280 Internet X.509 Public Key Infrastructure April 2002 3365 3366 3367 id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 } 3368 3369 -- reasonCode ::= { CRLReason } 3370 3371 CRLReason ::= ENUMERATED { 3372 unspecified (0), 3373 keyCompromise (1), 3374 cACompromise (2), 3375 affiliationChanged (3), 3376 superseded (4), 3377 cessationOfOperation (5), 3378 certificateHold (6), 3379 removeFromCRL (8), 3380 privilegeWithdrawn (9), 3381 aACompromise (10) } 3382 33835.3.2 Hold Instruction Code 3384 3385 The hold instruction code is a non-critical CRL entry extension that 3386 provides a registered instruction identifier which indicates the 3387 action to be taken after encountering a certificate that has been 3388 placed on hold. 3389 3390 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 3391 3392 holdInstructionCode ::= OBJECT IDENTIFIER 3393 3394 The following instruction codes have been defined. Conforming 3395 applications that process this extension MUST recognize the following 3396 instruction codes. 3397 3398 holdInstruction OBJECT IDENTIFIER ::= 3399 { iso(1) member-body(2) us(840) x9-57(10040) 2 } 3400 3401 id-holdinstruction-none OBJECT IDENTIFIER ::= {holdInstruction 1} 3402 id-holdinstruction-callissuer 3403 OBJECT IDENTIFIER ::= {holdInstruction 2} 3404 id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3} 3405 3406 Conforming applications which encounter an id-holdinstruction- 3407 callissuer MUST call the certificate issuer or reject the 3408 certificate. Conforming applications which encounter an id- 3409 holdinstruction-reject MUST reject the certificate. The hold 3410 instruction id-holdinstruction-none is semantically equivalent to the 3411 absence of a holdInstructionCode, and its use is strongly deprecated 3412 for the Internet PKI. 3413 3414 3415 3416 3417 3418Housley, et. al. Standards Track [Page 61] 3419 3420RFC 3280 Internet X.509 Public Key Infrastructure April 2002 3421 3422 34235.3.3 Invalidity Date 3424 3425 The invalidity date is a non-critical CRL entry extension that 3426 provides the date on which it is known or suspected that the private 3427 key was compromised or that the certificate otherwise became invalid. 3428 This date may be earlier than the revocation date in the CRL entry, 3429 which is the date at which the CA processed the revocation. When a 3430 revocation is first posted by a CRL issuer in a CRL, the invalidity 3431 date may precede the date of issue of earlier CRLs, but the 3432 revocation date SHOULD NOT precede the date of issue of earlier CRLs. 3433 Whenever this information is available, CRL issuers are strongly 3434 encouraged to share it with CRL users. 3435 3436 The GeneralizedTime values included in this field MUST be expressed 3437 in Greenwich Mean Time (Zulu), and MUST be specified and interpreted 3438 as defined in section 4.1.2.5.2. 3439 3440 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 3441 3442 invalidityDate ::= GeneralizedTime 3443 34445.3.4 Certificate Issuer 3445 3446 This CRL entry extension identifies the certificate issuer associated 3447 with an entry in an indirect CRL, that is, a CRL that has the 3448 indirectCRL indicator set in its issuing distribution point 3449 extension. If this extension is not present on the first entry in an 3450 indirect CRL, the certificate issuer defaults to the CRL issuer. On 3451 subsequent entries in an indirect CRL, if this extension is not 3452 present, the certificate issuer for the entry is the same as that for 3453 the preceding entry. This field is defined as follows: 3454 3455 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } 3456 3457 certificateIssuer ::= GeneralNames 3458 3459 If used by conforming CRL issuers, this extension MUST always be 3460 critical. If an implementation ignored this extension it could not 3461 correctly attribute CRL entries to certificates. This specification 3462 RECOMMENDS that implementations recognize this extension. 3463 34646 Certification Path Validation 3465 3466 Certification path validation procedures for the Internet PKI are 3467 based on the algorithm supplied in [X.509]. Certification path 3468 processing verifies the binding between the subject distinguished 3469 name and/or subject alternative name and subject public key. The 3470 binding is limited by constraints which are specified in the 3471 3472 3473 3474Housley, et. al. Standards Track [Page 62] 3475 3476RFC 3280 Internet X.509 Public Key Infrastructure April 2002 3477 3478 3479 certificates which comprise the path and inputs which are specified 3480 by the relying party. The basic constraints and policy constraints 3481 extensions allow the certification path processing logic to automate 3482 the decision making process. 3483 3484 This section describes an algorithm for validating certification 3485 paths. Conforming implementations of this specification are not 3486 required to implement this algorithm, but MUST provide functionality 3487 equivalent to the external behavior resulting from this procedure. 3488 Any algorithm may be used by a particular implementation so long as 3489 it derives the correct result. 3490 3491 In section 6.1, the text describes basic path validation. Valid 3492 paths begin with certificates issued by a trust anchor. The 3493 algorithm requires the public key of the CA, the CA's name, and any 3494 constraints upon the set of paths which may be validated using this 3495 key. 3496 3497 The selection of a trust anchor is a matter of policy: it could be 3498 the top CA in a hierarchical PKI; the CA that issued the verifier's 3499 own certificate(s); or any other CA in a network PKI. The path 3500 validation procedure is the same regardless of the choice of trust 3501 anchor. In addition, different applications may rely on different 3502 trust anchor, or may accept paths that begin with any of a set of 3503 trust anchor. 3504 3505 Section 6.2 describes methods for using the path validation algorithm 3506 in specific implementations. Two specific cases are discussed: the 3507 case where paths may begin with one of several trusted CAs; and where 3508 compatibility with the PEM architecture is required. 3509 3510 Section 6.3 describes the steps necessary to determine if a 3511 certificate is revoked or on hold status when CRLs are the revocation 3512 mechanism used by the certificate issuer. 3513 35146.1 Basic Path Validation 3515 3516 This text describes an algorithm for X.509 path processing. A 3517 conformant implementation MUST include an X.509 path processing 3518 procedure that is functionally equivalent to the external behavior of 3519 this algorithm. However, support for some of the certificate 3520 extensions processed in this algorithm are OPTIONAL for compliant 3521 implementations. Clients that do not support these extensions MAY 3522 omit the corresponding steps in the path validation algorithm. 3523 3524 3525 3526 3527 3528 3529 3530Housley, et. al. Standards Track [Page 63] 3531 3532RFC 3280 Internet X.509 Public Key Infrastructure April 2002 3533 3534 3535 For example, clients are NOT REQUIRED to support the policy mapping 3536 extension. Clients that do not support this extension MAY omit the 3537 path validation steps where policy mappings are processed. Note that 3538 clients MUST reject the certificate if it contains an unsupported 3539 critical extension. 3540 3541 The algorithm presented in this section validates the certificate 3542 with respect to the current date and time. A conformant 3543 implementation MAY also support validation with respect to some point 3544 in the past. Note that mechanisms are not available for validating a 3545 certificate with respect to a time outside the certificate validity 3546 period. 3547 3548 The trust anchor is an input to the algorithm. There is no 3549 requirement that the same trust anchor be used to validate all 3550 certification paths. Different trust anchors MAY be used to validate 3551 different paths, as discussed further in Section 6.2. 3552 3553 The primary goal of path validation is to verify the binding between 3554 a subject distinguished name or a subject alternative name and 3555 subject public key, as represented in the end entity certificate, 3556 based on the public key of the trust anchor. This requires obtaining 3557 a sequence of certificates that support that binding. The procedure 3558 performed to obtain this sequence of certificates is outside the 3559 scope of this specification. 3560 3561 To meet this goal, the path validation process verifies, among other 3562 things, that a prospective certification path (a sequence of n 3563 certificates) satisfies the following conditions: 3564 3565 (a) for all x in {1, ..., n-1}, the subject of certificate x is 3566 the issuer of certificate x+1; 3567 3568 (b) certificate 1 is issued by the trust anchor; 3569 3570 (c) certificate n is the certificate to be validated; and 3571 3572 (d) for all x in {1, ..., n}, the certificate was valid at the 3573 time in question. 3574 3575 When the trust anchor is provided in the form of a self-signed 3576 certificate, this self-signed certificate is not included as part of 3577 the prospective certification path. Information about trust anchors 3578 are provided as inputs to the certification path validation algorithm 3579 (section 6.1.1). 3580 3581 3582 3583 3584 3585 3586Housley, et. al. Standards Track [Page 64] 3587 3588RFC 3280 Internet X.509 Public Key Infrastructure April 2002 3589 3590 3591 A particular certification path may not, however, be appropriate for 3592 all applications. Therefore, an application MAY augment this 3593 algorithm to further limit the set of valid paths. The path 3594 validation process also determines the set of certificate policies 3595 that are valid for this path, based on the certificate policies 3596 extension, policy mapping extension, policy constraints extension, 3597 and inhibit any-policy extension. To achieve this, the path 3598 validation algorithm constructs a valid policy tree. If the set of 3599 certificate policies that are valid for this path is not empty, then 3600 the result will be a valid policy tree of depth n, otherwise the 3601 result will be a null valid policy tree. 3602 3603 A certificate is self-issued if the DNs that appear in the subject 3604 and issuer fields are identical and are not empty. In general, the 3605 issuer and subject of the certificates that make up a path are 3606 different for each certificate. However, a CA may issue a 3607 certificate to itself to support key rollover or changes in 3608 certificate policies. These self-issued certificates are not counted 3609 when evaluating path length or name constraints. 3610 3611 This section presents the algorithm in four basic steps: (1) 3612 initialization, (2) basic certificate processing, (3) preparation for 3613 the next certificate, and (4) wrap-up. Steps (1) and (4) are 3614 performed exactly once. Step (2) is performed for all certificates 3615 in the path. Step (3) is performed for all certificates in the path 3616 except the final certificate. Figure 2 provides a high-level 3617 flowchart of this algorithm. 3618 3619 3620 3621 3622 3623 3624 3625 3626 3627 3628 3629 3630 3631 3632 3633 3634 3635 3636 3637 3638 3639 3640 3641 3642Housley, et. al. Standards Track [Page 65] 3643 3644RFC 3280 Internet X.509 Public Key Infrastructure April 2002 3645 3646 3647 +-------+ 3648 | START | 3649 +-------+ 3650 | 3651 V 3652 +----------------+ 3653 | Initialization | 3654 +----------------+ 3655 | 3656 +<--------------------+ 3657 | | 3658 V | 3659 +----------------+ | 3660 | Process Cert | | 3661 +----------------+ | 3662 | | 3663 V | 3664 +================+ | 3665 | IF Last Cert | | 3666 | in Path | | 3667 +================+ | 3668 | | | 3669 THEN | | ELSE | 3670 V V | 3671 +----------------+ +----------------+ | 3672 | Wrap up | | Prepare for | | 3673 +----------------+ | Next Cert | | 3674 | +----------------+ | 3675 V | | 3676 +-------+ +--------------+ 3677 | STOP | 3678 +-------+ 3679 3680 3681 Figure 2. Certification Path Processing Flowchart 3682 36836.1.1 Inputs 3684 3685 This algorithm assumes the following seven inputs are provided to the 3686 path processing logic: 3687 3688 (a) a prospective certification path of length n. 3689 3690 (b) the current date/time. 3691 3692 3693 3694 3695 3696 3697 3698Housley, et. al. Standards Track [Page 66] 3699 3700RFC 3280 Internet X.509 Public Key Infrastructure April 2002 3701 3702 3703 (c) user-initial-policy-set: A set of certificate policy 3704 identifiers naming the policies that are acceptable to the 3705 certificate user. The user-initial-policy-set contains the 3706 special value any-policy if the user is not concerned about 3707 certificate policy. 3708 3709 (d) trust anchor information, describing a CA that serves as a 3710 trust anchor for the certification path. The trust anchor 3711 information includes: 3712 3713 (1) the trusted issuer name, 3714 3715 (2) the trusted public key algorithm, 3716 3717 (3) the trusted public key, and 3718 3719 (4) optionally, the trusted public key parameters associated 3720 with the public key. 3721 3722 The trust anchor information may be provided to the path 3723 processing procedure in the form of a self-signed certificate. 3724 The trusted anchor information is trusted because it was delivered 3725 to the path processing procedure by some trustworthy out-of-band 3726 procedure. If the trusted public key algorithm requires 3727 parameters, then the parameters are provided along with the 3728 trusted public key. 3729 3730 (e) initial-policy-mapping-inhibit, which indicates if policy 3731 mapping is allowed in the certification path. 3732 3733 (f) initial-explicit-policy, which indicates if the path must be 3734 valid for at least one of the certificate policies in the user- 3735 initial-policy-set. 3736 3737 (g) initial-any-policy-inhibit, which indicates whether the 3738 anyPolicy OID should be processed if it is included in a 3739 certificate. 3740 37416.1.2 Initialization 3742 3743 This initialization phase establishes eleven state variables based 3744 upon the seven inputs: 3745 3746 (a) valid_policy_tree: A tree of certificate policies with their 3747 optional qualifiers; each of the leaves of the tree represents a 3748 valid policy at this stage in the certification path validation. 3749 If valid policies exist at this stage in the certification path 3750 validation, the depth of the tree is equal to the number of 3751 3752 3753 3754Housley, et. al. Standards Track [Page 67] 3755 3756RFC 3280 Internet X.509 Public Key Infrastructure April 2002 3757 3758 3759 certificates in the chain that have been processed. If valid 3760 policies do not exist at this stage in the certification path 3761 validation, the tree is set to NULL. Once the tree is set to 3762 NULL, policy processing ceases. 3763 3764 Each node in the valid_policy_tree includes four data objects: the 3765 valid policy, a set of associated policy qualifiers, a set of one 3766 or more expected policy values, and a criticality indicator. If 3767 the node is at depth x, the components of the node have the 3768 following semantics: 3769 3770 (1) The valid_policy is a single policy OID representing a 3771 valid policy for the path of length x. 3772 3773 (2) The qualifier_set is a set of policy qualifiers associated 3774 with the valid policy in certificate x. 3775 3776 (3) The criticality_indicator indicates whether the 3777 certificate policy extension in certificate x was marked as 3778 critical. 3779 3780 (4) The expected_policy_set contains one or more policy OIDs 3781 that would satisfy this policy in the certificate x+1. 3782 3783 The initial value of the valid_policy_tree is a single node with 3784 valid_policy anyPolicy, an empty qualifier_set, an 3785 expected_policy_set with the single value anyPolicy, and a 3786 criticality_indicator of FALSE. This node is considered to be at 3787 depth zero. 3788 3789 Figure 3 is a graphic representation of the initial state of the 3790 valid_policy_tree. Additional figures will use this format to 3791 describe changes in the valid_policy_tree during path processing. 3792 3793 +----------------+ 3794 | anyPolicy | <---- valid_policy 3795 +----------------+ 3796 | {} | <---- qualifier_set 3797 +----------------+ 3798 | FALSE | <---- criticality_indicator 3799 +----------------+ 3800 | {anyPolicy} | <---- expected_policy_set 3801 +----------------+ 3802 3803 Figure 3. Initial value of the valid_policy_tree state variable 3804 3805 3806 3807 3808 3809 3810Housley, et. al. Standards Track [Page 68] 3811 3812RFC 3280 Internet X.509 Public Key Infrastructure April 2002 3813 3814 3815 (b) permitted_subtrees: A set of root names for each name type 3816 (e.g., X.500 distinguished names, email addresses, or ip 3817 addresses) defining a set of subtrees within which all subject 3818 names in subsequent certificates in the certification path MUST 3819 fall. This variable includes a set for each name type: the 3820 initial value for the set for Distinguished Names is the set of 3821 all Distinguished names; the initial value for the set of RFC822 3822 names is the set of all RFC822 names, etc. 3823 3824 (c) excluded_subtrees: A set of root names for each name type 3825 (e.g., X.500 distinguished names, email addresses, or ip 3826 addresses) defining a set of subtrees within which no subject name 3827 in subsequent certificates in the certification path may fall. 3828 This variable includes a set for each name type, and the initial 3829 value for each set is empty. 3830 3831 (d) explicit_policy: an integer which indicates if a non-NULL 3832 valid_policy_tree is required. The integer indicates the number of 3833 non-self-issued certificates to be processed before this 3834 requirement is imposed. Once set, this variable may be decreased, 3835 but may not be increased. That is, if a certificate in the path 3836 requires a non-NULL valid_policy_tree, a later certificate can not 3837 remove this requirement. If initial-explicit-policy is set, then 3838 the initial value is 0, otherwise the initial value is n+1. 3839 3840 (e) inhibit_any-policy: an integer which indicates whether the 3841 anyPolicy policy identifier is considered a match. The integer 3842 indicates the number of non-self-issued certificates to be 3843 processed before the anyPolicy OID, if asserted in a certificate, 3844 is ignored. Once set, this variable may be decreased, but may not 3845 be increased. That is, if a certificate in the path inhibits 3846 processing of anyPolicy, a later certificate can not permit it. 3847 If initial-any-policy-inhibit is set, then the initial value is 0, 3848 otherwise the initial value is n+1. 3849 3850 (f) policy_mapping: an integer which indicates if policy mapping 3851 is permitted. The integer indicates the number of non-self-issued 3852 certificates to be processed before policy mapping is inhibited. 3853 Once set, this variable may be decreased, but may not be 3854 increased. That is, if a certificate in the path specifies policy 3855 mapping is not permitted, it can not be overridden by a later 3856 certificate. If initial-policy-mapping-inhibit is set, then the 3857 initial value is 0, otherwise the initial value is n+1. 3858 3859 (g) working_public_key_algorithm: the digital signature algorithm 3860 used to verify the signature of a certificate. The 3861 working_public_key_algorithm is initialized from the trusted 3862 public key algorithm provided in the trust anchor information. 3863 3864 3865 3866Housley, et. al. Standards Track [Page 69] 3867 3868RFC 3280 Internet X.509 Public Key Infrastructure April 2002 3869 3870 3871 (h) working_public_key: the public key used to verify the 3872 signature of a certificate. The working_public_key is initialized 3873 from the trusted public key provided in the trust anchor 3874 information. 3875 3876 (i) working_public_key_parameters: parameters associated with the 3877 current public key, that may be required to verify a signature 3878 (depending upon the algorithm). The working_public_key_parameters 3879 variable is initialized from the trusted public key parameters 3880 provided in the trust anchor information. 3881 3882 (j) working_issuer_name: the issuer distinguished name expected 3883 in the next certificate in the chain. The working_issuer_name is 3884 initialized to the trusted issuer provided in the trust anchor 3885 information. 3886 3887 (k) max_path_length: this integer is initialized to n, is 3888 decremented for each non-self-issued certificate in the path, and 3889 may be reduced to the value in the path length constraint field 3890 within the basic constraints extension of a CA certificate. 3891 3892 Upon completion of the initialization steps, perform the basic 3893 certificate processing steps specified in 6.1.3. 3894 38956.1.3 Basic Certificate Processing 3896 3897 The basic path processing actions to be performed for certificate i 3898 (for all i in [1..n]) are listed below. 3899 3900 (a) Verify the basic certificate information. The certificate 3901 MUST satisfy each of the following: 3902 3903 (1) The certificate was signed with the 3904 working_public_key_algorithm using the working_public_key and 3905 the working_public_key_parameters. 3906 3907 (2) The certificate validity period includes the current time. 3908 3909 (3) At the current time, the certificate is not revoked and is 3910 not on hold status. This may be determined by obtaining the 3911 appropriate CRL (section 6.3), status information, or by out- 3912 of-band mechanisms. 3913 3914 (4) The certificate issuer name is the working_issuer_name. 3915 3916 3917 3918 3919 3920 3921 3922Housley, et. al. Standards Track [Page 70] 3923 3924RFC 3280 Internet X.509 Public Key Infrastructure April 2002 3925 3926 3927 (b) If certificate i is self-issued and it is not the final 3928 certificate in the path, skip this step for certificate i. 3929 Otherwise, verify that the subject name is within one of the 3930 permitted_subtrees for X.500 distinguished names, and verify that 3931 each of the alternative names in the subjectAltName extension 3932 (critical or non-critical) is within one of the permitted_subtrees 3933 for that name type. 3934 3935 (c) If certificate i is self-issued and it is not the final 3936 certificate in the path, skip this step for certificate i. 3937 Otherwise, verify that the subject name is not within one of the 3938 excluded_subtrees for X.500 distinguished names, and verify that 3939 each of the alternative names in the subjectAltName extension 3940 (critical or non-critical) is not within one of the 3941 excluded_subtrees for that name type. 3942 3943 (d) If the certificate policies extension is present in the 3944 certificate and the valid_policy_tree is not NULL, process the 3945 policy information by performing the following steps in order: 3946 3947 (1) For each policy P not equal to anyPolicy in the 3948 certificate policies extension, let P-OID denote the OID in 3949 policy P and P-Q denote the qualifier set for policy P. 3950 Perform the following steps in order: 3951 3952 (i) If the valid_policy_tree includes a node of depth i-1 3953 where P-OID is in the expected_policy_set, create a child 3954 node as follows: set the valid_policy to OID-P; set the 3955 qualifier_set to P-Q, and set the expected_policy_set to 3956 {P-OID}. 3957 3958 For example, consider a valid_policy_tree with a node of 3959 depth i-1 where the expected_policy_set is {Gold, White}. 3960 Assume the certificate policies Gold and Silver appear in 3961 the certificate policies extension of certificate i. The 3962 Gold policy is matched but the Silver policy is not. This 3963 rule will generate a child node of depth i for the Gold 3964 policy. The result is shown as Figure 4. 3965 3966 3967 3968 3969 3970 3971 3972 3973 3974 3975 3976 3977 3978Housley, et. al. Standards Track [Page 71] 3979 3980RFC 3280 Internet X.509 Public Key Infrastructure April 2002 3981 3982 3983 +-----------------+ 3984 | Red | 3985 +-----------------+ 3986 | {} | 3987 +-----------------+ node of depth i-1 3988 | FALSE | 3989 +-----------------+ 3990 | {Gold, White} | 3991 +-----------------+ 3992 | 3993 | 3994 | 3995 V 3996 +-----------------+ 3997 | Gold | 3998 +-----------------+ 3999 | {} | 4000 +-----------------+ node of depth i 4001 | uninitialized | 4002 +-----------------+ 4003 | {Gold} | 4004 +-----------------+ 4005 4006 Figure 4. Processing an exact match 4007 4008 (ii) If there was no match in step (i) and the 4009 valid_policy_tree includes a node of depth i-1 with the 4010 valid policy anyPolicy, generate a child node with the 4011 following values: set the valid_policy to P-OID; set the 4012 qualifier_set to P-Q, and set the expected_policy_set to 4013 {P-OID}. 4014 4015 For example, consider a valid_policy_tree with a node of 4016 depth i-1 where the valid_policy is anyPolicy. Assume the 4017 certificate policies Gold and Silver appear in the 4018 certificate policies extension of certificate i. The Gold 4019 policy does not have a qualifier, but the Silver policy has 4020 the qualifier Q-Silver. If Gold and Silver were not matched 4021 in (i) above, this rule will generate two child nodes of 4022 depth i, one for each policy. The result is shown as Figure 4023 5. 4024 4025 4026 4027 4028 4029 4030 4031 4032 4033 4034Housley, et. al. Standards Track [Page 72] 4035 4036RFC 3280 Internet X.509 Public Key Infrastructure April 2002 4037 4038 4039 +-----------------+ 4040 | anyPolicy | 4041 +-----------------+ 4042 | {} | 4043 +-----------------+ node of depth i-1 4044 | FALSE | 4045 +-----------------+ 4046 | {anyPolicy} | 4047 +-----------------+ 4048 / \ 4049 / \ 4050 / \ 4051 / \ 4052 +-----------------+ +-----------------+ 4053 | Gold | | Silver | 4054 +-----------------+ +-----------------+ 4055 | {} | | {Q-Silver} | 4056 +-----------------+ nodes of +-----------------+ 4057 | uninitialized | depth i | uninitialized | 4058 +-----------------+ +-----------------+ 4059 | {Gold} | | {Silver} | 4060 +-----------------+ +-----------------+ 4061 4062 Figure 5. Processing unmatched policies when a leaf node 4063 specifies anyPolicy 4064 4065 (2) If the certificate policies extension includes the policy 4066 anyPolicy with the qualifier set AP-Q and either (a) 4067 inhibit_any-policy is greater than 0 or (b) i<n and the 4068 certificate is self-issued, then: 4069 4070 For each node in the valid_policy_tree of depth i-1, for each 4071 value in the expected_policy_set (including anyPolicy) that 4072 does not appear in a child node, create a child node with the 4073 following values: set the valid_policy to the value from the 4074 expected_policy_set in the parent node; set the qualifier_set 4075 to AP-Q, and set the expected_policy_set to the value in the 4076 valid_policy from this node. 4077 4078 For example, consider a valid_policy_tree with a node of depth 4079 i-1 where the expected_policy_set is {Gold, Silver}. Assume 4080 anyPolicy appears in the certificate policies extension of 4081 certificate i, but Gold and Silver do not. This rule will 4082 generate two child nodes of depth i, one for each policy. The 4083 result is shown below as Figure 6. 4084 4085 4086 4087 4088 4089 4090Housley, et. al. Standards Track [Page 73] 4091 4092RFC 3280 Internet X.509 Public Key Infrastructure April 2002 4093 4094 4095 +-----------------+ 4096 | Red | 4097 +-----------------+ 4098 | {} | 4099 +-----------------+ node of depth i-1 4100 | FALSE | 4101 +-----------------+ 4102 | {Gold, Silver} | 4103 +-----------------+ 4104 / \ 4105 / \ 4106 / \ 4107 / \ 4108 +-----------------+ +-----------------+ 4109 | Gold | | Silver | 4110 +-----------------+ +-----------------+ 4111 | {} | | {} | 4112 +-----------------+ nodes of +-----------------+ 4113 | uninitialized | depth i | uninitialized | 4114 +-----------------+ +-----------------+ 4115 | {Gold} | | {Silver} | 4116 +-----------------+ +-----------------+ 4117 4118 Figure 6. Processing unmatched policies when the certificate 4119 policies extension specifies anyPolicy 4120 4121 (3) If there is a node in the valid_policy_tree of depth i-1 4122 or less without any child nodes, delete that node. Repeat this 4123 step until there are no nodes of depth i-1 or less without 4124 children. 4125 4126 For example, consider the valid_policy_tree shown in Figure 7 4127 below. The two nodes at depth i-1 that are marked with an 'X' 4128 have no children, and are deleted. Applying this rule to the 4129 resulting tree will cause the node at depth i-2 that is marked 4130 with an 'Y' to be deleted. The following application of the 4131 rule does not cause any nodes to be deleted, and this step is 4132 complete. 4133 4134 4135 4136 4137 4138 4139 4140 4141 4142 4143 4144 4145 4146Housley, et. al. Standards Track [Page 74] 4147 4148RFC 3280 Internet X.509 Public Key Infrastructure April 2002 4149 4150 4151 +-----------+ 4152 | | node of depth i-3 4153 +-----------+ 4154 / | \ 4155 / | \ 4156 / | \ 4157 +-----------+ +-----------+ +-----------+ 4158 | | | | | Y | nodes of 4159 +-----------+ +-----------+ +-----------+ depth i-2 4160 / \ | | 4161 / \ | | 4162 / \ | | 4163 +-----------+ +-----------+ +-----------+ +-----------+ nodes of 4164 | | | X | | | | X | depth 4165 +-----------+ +-----------+ +-----------+ +-----------+ i-1 4166 | / | \ 4167 | / | \ 4168 | / | \ 4169 +-----------+ +-----------+ +-----------+ +-----------+ nodes of 4170 | | | | | | | | depth 4171 +-----------+ +-----------+ +-----------+ +-----------+ i 4172 4173 Figure 7. Pruning the valid_policy_tree 4174 4175 (4) If the certificate policies extension was marked as 4176 critical, set the criticality_indicator in all nodes of depth i 4177 to TRUE. If the certificate policies extension was not marked 4178 critical, set the criticality_indicator in all nodes of depth i 4179 to FALSE. 4180 4181 (e) If the certificate policies extension is not present, set the 4182 valid_policy_tree to NULL. 4183 4184 (f) Verify that either explicit_policy is greater than 0 or the 4185 valid_policy_tree is not equal to NULL; 4186 4187 If any of steps (a), (b), (c), or (f) fails, the procedure 4188 terminates, returning a failure indication and an appropriate reason. 4189 4190 If i is not equal to n, continue by performing the preparatory steps 4191 listed in 6.1.4. If i is equal to n, perform the wrap-up steps 4192 listed in 6.1.5. 4193 41946.1.4 Preparation for Certificate i+1 4195 4196 To prepare for processing of certificate i+1, perform the following 4197 steps for certificate i: 4198 4199 4200 4201 4202Housley, et. al. Standards Track [Page 75] 4203 4204RFC 3280 Internet X.509 Public Key Infrastructure April 2002 4205 4206 4207 (a) If a policy mapping extension is present, verify that the 4208 special value anyPolicy does not appear as an issuerDomainPolicy 4209 or a subjectDomainPolicy. 4210 4211 (b) If a policy mapping extension is present, then for each 4212 issuerDomainPolicy ID-P in the policy mapping extension: 4213 4214 (1) If the policy_mapping variable is greater than 0, for each 4215 node in the valid_policy_tree of depth i where ID-P is the 4216 valid_policy, set expected_policy_set to the set of 4217 subjectDomainPolicy values that are specified as equivalent to 4218 ID-P by the policy mapping extension. 4219 4220 If no node of depth i in the valid_policy_tree has a 4221 valid_policy of ID-P but there is a node of depth i with a 4222 valid_policy of anyPolicy, then generate a child node of the 4223 node of depth i-1 that has a valid_policy of anyPolicy as 4224 follows: 4225 4226 (i) set the valid_policy to ID-P; 4227 4228 (ii) set the qualifier_set to the qualifier set of the 4229 policy anyPolicy in the certificate policies extension of 4230 certificate i; 4231 4232 (iii) set the criticality_indicator to the criticality of 4233 the certificate policies extension of certificate i; 4234 4235 (iv) and set the expected_policy_set to the set of 4236 subjectDomainPolicy values that are specified as equivalent 4237 to ID-P by the policy mappings extension. 4238 4239 (2) If the policy_mapping variable is equal to 0: 4240 4241 (i) delete each node of depth i in the valid_policy_tree 4242 where ID-P is the valid_policy. 4243 4244 (ii) If there is a node in the valid_policy_tree of depth 4245 i-1 or less without any child nodes, delete that node. 4246 Repeat this step until there are no nodes of depth i-1 or 4247 less without children. 4248 4249 (c) Assign the certificate subject name to working_issuer_name. 4250 4251 (d) Assign the certificate subjectPublicKey to 4252 working_public_key. 4253 4254 4255 4256 4257 4258Housley, et. al. Standards Track [Page 76] 4259 4260RFC 3280 Internet X.509 Public Key Infrastructure April 2002 4261 4262 4263 (e) If the subjectPublicKeyInfo field of the certificate contains 4264 an algorithm field with non-null parameters, assign the parameters 4265 to the working_public_key_parameters variable. 4266 4267 If the subjectPublicKeyInfo field of the certificate contains an 4268 algorithm field with null parameters or parameters are omitted, 4269 compare the certificate subjectPublicKey algorithm to the 4270 working_public_key_algorithm. If the certificate subjectPublicKey 4271 algorithm and the working_public_key_algorithm are different, set 4272 the working_public_key_parameters to null. 4273 4274 (f) Assign the certificate subjectPublicKey algorithm to the 4275 working_public_key_algorithm variable. 4276 4277 (g) If a name constraints extension is included in the 4278 certificate, modify the permitted_subtrees and excluded_subtrees 4279 state variables as follows: 4280 4281 (1) If permittedSubtrees is present in the certificate, set 4282 the permitted_subtrees state variable to the intersection of 4283 its previous value and the value indicated in the extension 4284 field. If permittedSubtrees does not include a particular name 4285 type, the permitted_subtrees state variable is unchanged for 4286 that name type. For example, the intersection of nist.gov and 4287 csrc.nist.gov is csrc.nist.gov. And, the intersection of 4288 nist.gov and rsasecurity.com is the empty set. 4289 4290 (2) If excludedSubtrees is present in the certificate, set the 4291 excluded_subtrees state variable to the union of its previous 4292 value and the value indicated in the extension field. If 4293 excludedSubtrees does not include a particular name type, the 4294 excluded_subtrees state variable is unchanged for that name 4295 type. For example, the union of the name spaces nist.gov and 4296 csrc.nist.gov is nist.gov. And, the union of nist.gov and 4297 rsasecurity.com is both name spaces. 4298 4299 (h) If the issuer and subject names are not identical: 4300 4301 (1) If explicit_policy is not 0, decrement explicit_policy by 4302 1. 4303 4304 (2) If policy_mapping is not 0, decrement policy_mapping by 1. 4305 4306 (3) If inhibit_any-policy is not 0, decrement inhibit_any- 4307 policy by 1. 4308 4309 4310 4311 4312 4313 4314Housley, et. al. Standards Track [Page 77] 4315 4316RFC 3280 Internet X.509 Public Key Infrastructure April 2002 4317 4318 4319 (i) If a policy constraints extension is included in the 4320 certificate, modify the explicit_policy and policy_mapping state 4321 variables as follows: 4322 4323 (1) If requireExplicitPolicy is present and is less than 4324 explicit_policy, set explicit_policy to the value of 4325 requireExplicitPolicy. 4326 4327 (2) If inhibitPolicyMapping is present and is less than 4328 policy_mapping, set policy_mapping to the value of 4329 inhibitPolicyMapping. 4330 4331 (j) If the inhibitAnyPolicy extension is included in the 4332 certificate and is less than inhibit_any-policy, set inhibit_any- 4333 policy to the value of inhibitAnyPolicy. 4334 4335 (k) Verify that the certificate is a CA certificate (as specified 4336 in a basicConstraints extension or as verified out-of-band). 4337 4338 (l) If the certificate was not self-issued, verify that 4339 max_path_length is greater than zero and decrement max_path_length 4340 by 1. 4341 4342 (m) If pathLengthConstraint is present in the certificate and is 4343 less than max_path_length, set max_path_length to the value of 4344 pathLengthConstraint. 4345 4346 (n) If a key usage extension is present, verify that the 4347 keyCertSign bit is set. 4348 4349 (o) Recognize and process any other critical extension present in 4350 the certificate. Process any other recognized non-critical 4351 extension present in the certificate. 4352 4353 If check (a), (k), (l), (n) or (o) fails, the procedure terminates, 4354 returning a failure indication and an appropriate reason. 4355 4356 If (a), (k), (l), (n) and (o) have completed successfully, increment 4357 i and perform the basic certificate processing specified in 6.1.3. 4358 43596.1.5 Wrap-up procedure 4360 4361 To complete the processing of the end entity certificate, perform the 4362 following steps for certificate n: 4363 4364 (a) If certificate n was not self-issued and explicit_policy is 4365 not 0, decrement explicit_policy by 1. 4366 4367 4368 4369 4370Housley, et. al. Standards Track [Page 78] 4371 4372RFC 3280 Internet X.509 Public Key Infrastructure April 2002 4373 4374 4375 (b) If a policy constraints extension is included in the 4376 certificate and requireExplicitPolicy is present and has a value 4377 of 0, set the explicit_policy state variable to 0. 4378 4379 (c) Assign the certificate subjectPublicKey to 4380 working_public_key. 4381 4382 (d) If the subjectPublicKeyInfo field of the certificate contains 4383 an algorithm field with non-null parameters, assign the parameters 4384 to the working_public_key_parameters variable. 4385 4386 If the subjectPublicKeyInfo field of the certificate contains an 4387 algorithm field with null parameters or parameters are omitted, 4388 compare the certificate subjectPublicKey algorithm to the 4389 working_public_key_algorithm. If the certificate subjectPublicKey 4390 algorithm and the working_public_key_algorithm are different, set 4391 the working_public_key_parameters to null. 4392 4393 (e) Assign the certificate subjectPublicKey algorithm to the 4394 working_public_key_algorithm variable. 4395 4396 (f) Recognize and process any other critical extension present in 4397 the certificate n. Process any other recognized non-critical 4398 extension present in certificate n. 4399 4400 (g) Calculate the intersection of the valid_policy_tree and the 4401 user-initial-policy-set, as follows: 4402 4403 (i) If the valid_policy_tree is NULL, the intersection is 4404 NULL. 4405 4406 (ii) If the valid_policy_tree is not NULL and the user- 4407 initial-policy-set is any-policy, the intersection is the 4408 entire valid_policy_tree. 4409 4410 (iii) If the valid_policy_tree is not NULL and the user- 4411 initial-policy-set is not any-policy, calculate the 4412 intersection of the valid_policy_tree and the user-initial- 4413 policy-set as follows: 4414 4415 1. Determine the set of policy nodes whose parent nodes 4416 have a valid_policy of anyPolicy. This is the 4417 valid_policy_node_set. 4418 4419 2. If the valid_policy of any node in the 4420 valid_policy_node_set is not in the user-initial-policy-set 4421 and is not anyPolicy, delete this node and all its children. 4422 4423 4424 4425 4426Housley, et. al. Standards Track [Page 79] 4427 4428RFC 3280 Internet X.509 Public Key Infrastructure April 2002 4429 4430 4431 3. If the valid_policy_tree includes a node of depth n with 4432 the valid_policy anyPolicy and the user-initial-policy-set 4433 is not any-policy perform the following steps: 4434 4435 a. Set P-Q to the qualifier_set in the node of depth n 4436 with valid_policy anyPolicy. 4437 4438 b. For each P-OID in the user-initial-policy-set that is 4439 not the valid_policy of a node in the 4440 valid_policy_node_set, create a child node whose parent 4441 is the node of depth n-1 with the valid_policy anyPolicy. 4442 Set the values in the child node as follows: set the 4443 valid_policy to P-OID; set the qualifier_set to P-Q; copy 4444 the criticality_indicator from the node of depth n with 4445 the valid_policy anyPolicy; and set the 4446 expected_policy_set to {P-OID}. 4447 4448 c. Delete the node of depth n with the valid_policy 4449 anyPolicy. 4450 4451 4. If there is a node in the valid_policy_tree of depth n-1 4452 or less without any child nodes, delete that node. Repeat 4453 this step until there are no nodes of depth n-1 or less 4454 without children. 4455 4456 If either (1) the value of explicit_policy variable is greater than 4457 zero, or (2) the valid_policy_tree is not NULL, then path processing 4458 has succeeded. 4459 44606.1.6 Outputs 4461 4462 If path processing succeeds, the procedure terminates, returning a 4463 success indication together with final value of the 4464 valid_policy_tree, the working_public_key, the 4465 working_public_key_algorithm, and the working_public_key_parameters. 4466 44676.2 Using the Path Validation Algorithm 4468 4469 The path validation algorithm describes the process of validating a 4470 single certification path. While each certification path begins with 4471 a specific trust anchor, there is no requirement that all 4472 certification paths validated by a particular system share a single 4473 trust anchor. An implementation that supports multiple trust anchors 4474 MAY augment the algorithm presented in section 6.1 to further limit 4475 the set of valid certification paths which begin with a particular 4476 trust anchor. For example, an implementation MAY modify the 4477 algorithm to apply name constraints to a specific trust anchor during 4478 the initialization phase, or the application MAY require the presence 4479 4480 4481 4482Housley, et. al. Standards Track [Page 80] 4483 4484RFC 3280 Internet X.509 Public Key Infrastructure April 2002 4485 4486 4487 of a particular alternative name form in the end entity certificate, 4488 or the application MAY impose requirements on application-specific 4489 extensions. Thus, the path validation algorithm presented in section 4490 6.1 defines the minimum conditions for a path to be considered valid. 4491 4492 The selection of one or more trusted CAs is a local decision. A 4493 system may provide any one of its trusted CAs as the trust anchor for 4494 a particular path. The inputs to the path validation algorithm may 4495 be different for each path. The inputs used to process a path may 4496 reflect application-specific requirements or limitations in the trust 4497 accorded a particular trust anchor. For example, a trusted CA may 4498 only be trusted for a particular certificate policy. This 4499 restriction can be expressed through the inputs to the path 4500 validation procedure. 4501 4502 It is also possible to specify an extended version of the above 4503 certification path processing procedure which results in default 4504 behavior identical to the rules of PEM [RFC 1422]. In this extended 4505 version, additional inputs to the procedure are a list of one or more 4506 Policy Certification Authority (PCA) names and an indicator of the 4507 position in the certification path where the PCA is expected. At the 4508 nominated PCA position, the CA name is compared against this list. 4509 If a recognized PCA name is found, then a constraint of 4510 SubordinateToCA is implicitly assumed for the remainder of the 4511 certification path and processing continues. If no valid PCA name is 4512 found, and if the certification path cannot be validated on the basis 4513 of identified policies, then the certification path is considered 4514 invalid. 4515 45166.3 CRL Validation 4517 4518 This section describes the steps necessary to determine if a 4519 certificate is revoked or on hold status when CRLs are the revocation 4520 mechanism used by the certificate issuer. Conforming implementations 4521 that support CRLs are not required to implement this algorithm, but 4522 they MUST be functionally equivalent to the external behavior 4523 resulting from this procedure. Any algorithm may be used by a 4524 particular implementation so long as it derives the correct result. 4525 4526 This algorithm assumes that all of the needed CRLs are available in a 4527 local cache. Further, if the next update time of a CRL has passed, 4528 the algorithm assumes a mechanism to fetch a current CRL and place it 4529 in the local CRL cache. 4530 4531 This algorithm defines a set of inputs, a set of state variables, and 4532 processing steps that are performed for each certificate in the path. 4533 The algorithm output is the revocation status of the certificate. 4534 4535 4536 4537 4538Housley, et. al. Standards Track [Page 81] 4539 4540RFC 3280 Internet X.509 Public Key Infrastructure April 2002 4541 4542 45436.3.1 Revocation Inputs 4544 4545 To support revocation processing, the algorithm requires two inputs: 4546 4547 (a) certificate: The algorithm requires the certificate serial 4548 number and issuer name to determine whether a certificate is on a 4549 particular CRL. The basicConstraints extension is used to 4550 determine whether the supplied certificate is associated with a CA 4551 or an end entity. If present, the algorithm uses the 4552 cRLDistributionsPoint and freshestCRL extensions to determine 4553 revocation status. 4554 4555 (b) use-deltas: This boolean input determines whether delta CRLs 4556 are applied to CRLs. 4557 4558 Note that implementations supporting legacy PKIs, such as RFC 1422 4559 and X.509 version 1, will need an additional input indicating 4560 whether the supplied certificate is associated with a CA or an end 4561 entity. 4562 45636.3.2 Initialization and Revocation State Variables 4564 4565 To support CRL processing, the algorithm requires the following state 4566 variables: 4567 4568 (a) reasons_mask: This variable contains the set of revocation 4569 reasons supported by the CRLs and delta CRLs processed so far. 4570 The legal members of the set are the possible revocation reason 4571 values: unspecified, keyCompromise, caCompromise, 4572 affiliationChanged, superseded, cessationOfOperation, 4573 certificateHold, privilegeWithdrawn, and aACompromise. The 4574 special value all-reasons is used to denote the set of all legal 4575 members. This variable is initialized to the empty set. 4576 4577 (b) cert_status: This variable contains the status of the 4578 certificate. This variable may be assigned one of the following 4579 values: unspecified, keyCompromise, caCompromise, 4580 affiliationChanged, superseded, cessationOfOperation, 4581 certificateHold, removeFromCRL, privilegeWithdrawn, aACompromise, 4582 the special value UNREVOKED, or the special value UNDETERMINED. 4583 This variable is initialized to the special value UNREVOKED. 4584 4585 (c) interim_reasons_mask: This contains the set of revocation 4586 reasons supported by the CRL or delta CRL currently being 4587 processed. 4588 4589 4590 4591 4592 4593 4594Housley, et. al. Standards Track [Page 82] 4595 4596RFC 3280 Internet X.509 Public Key Infrastructure April 2002 4597 4598 4599 Note: In some environments, it is not necessary to check all reason 4600 codes. For example, some environments are only concerned with 4601 caCompromise and keyCompromise for CA certificates. This algorithm 4602 checks all reason codes. Additional processing and state variables 4603 may be necessary to limit the checking to a subset of the reason 4604 codes. 4605 46066.3.3 CRL Processing 4607 4608 This algorithm begins by assuming the certificate is not revoked. 4609 The algorithm checks one or more CRLs until either the certificate 4610 status is determined to be revoked or sufficient CRLs have been 4611 checked to cover all reason codes. 4612 4613 For each distribution point (DP) in the certificate CRL distribution 4614 points extension, for each corresponding CRL in the local CRL cache, 4615 while ((reasons_mask is not all-reasons) and (cert_status is 4616 UNREVOKED)) perform the following: 4617 4618 (a) Update the local CRL cache by obtaining a complete CRL, a 4619 delta CRL, or both, as required: 4620 4621 (1) If the current time is after the value of the CRL next 4622 update field, then do one of the following: 4623 4624 (i) If use-deltas is set and either the certificate or the 4625 CRL contains the freshest CRL extension, obtain a delta CRL 4626 with the a next update value that is after the current time 4627 and can be used to update the locally cached CRL as 4628 specified in section 5.2.4. 4629 4630 (ii) Update the local CRL cache with a current complete 4631 CRL, verify that the current time is before the next update 4632 value in the new CRL, and continue processing with the new 4633 CRL. If use-deltas is set, then obtain the current delta 4634 CRL that can be used to update the new locally cached 4635 complete CRL as specified in section 5.2.4. 4636 4637 (2) If the current time is before the value of the next update 4638 field and use-deltas is set, then obtain the current delta CRL 4639 that can be used to update the locally cached complete CRL as 4640 specified in section 5.2.4. 4641 4642 (b) Verify the issuer and scope of the complete CRL as follows: 4643 4644 4645 4646 4647 4648 4649 4650Housley, et. al. Standards Track [Page 83] 4651 4652RFC 3280 Internet X.509 Public Key Infrastructure April 2002 4653 4654 4655 (1) If the DP includes cRLIssuer, then verify that the issuer 4656 field in the complete CRL matches cRLIssuer in the DP and that 4657 the complete CRL contains an issuing distribution point 4658 extension with the indrectCRL boolean asserted. Otherwise, 4659 verify that the CRL issuer matches the certificate issuer. 4660 4661 (2) If the complete CRL includes an issuing distribution point 4662 (IDP) CRL extension check the following: 4663 4664 (i) If the distribution point name is present in the IDP 4665 CRL extension and the distribution field is present in the 4666 DP, then verify that one of the names in the IDP matches one 4667 of the names in the DP. If the distribution point name is 4668 present in the IDP CRL extension and the distribution field 4669 is omitted from the DP, then verify that one of the names in 4670 the IDP matches one of the names in the cRLIssuer field of 4671 the DP. 4672 4673 (ii) If the onlyContainsUserCerts boolean is asserted in 4674 the IDP CRL extension, verify that the certificate does not 4675 include the basic constraints extension with the cA boolean 4676 asserted. 4677 4678 (iii) If the onlyContainsCACerts boolean is asserted in the 4679 IDP CRL extension, verify that the certificate includes the 4680 basic constraints extension with the cA boolean asserted. 4681 4682 (iv) Verify that the onlyContainsAttributeCerts boolean is 4683 not asserted. 4684 4685 (c) If use-deltas is set, verify the issuer and scope of the 4686 delta CRL as follows: 4687 4688 (1) Verify that the delta CRL issuer matches complete CRL 4689 issuer. 4690 4691 (2) If the complete CRL includes an issuing distribution point 4692 (IDP) CRL extension, verify that the delta CRL contains a 4693 matching IDP CRL extension. If the complete CRL omits an IDP 4694 CRL extension, verify that the delta CRL also omits an IDP CRL 4695 extension. 4696 4697 (3) Verify that the delta CRL authority key identifier 4698 extension matches complete CRL authority key identifier 4699 extension. 4700 4701 4702 4703 4704 4705 4706Housley, et. al. Standards Track [Page 84] 4707 4708RFC 3280 Internet X.509 Public Key Infrastructure April 2002 4709 4710 4711 (d) Compute the interim_reasons_mask for this CRL as follows: 4712 4713 (1) If the issuing distribution point (IDP) CRL extension is 4714 present and includes onlySomeReasons and the DP includes 4715 reasons, then set interim_reasons_mask to the intersection of 4716 reasons in the DP and onlySomeReasons in IDP CRL extension. 4717 4718 (2) If the IDP CRL extension includes onlySomeReasons but the 4719 DP omits reasons, then set interim_reasons_mask to the value of 4720 onlySomeReasons in IDP CRL extension. 4721 4722 (3) If the IDP CRL extension is not present or omits 4723 onlySomeReasons but the DP includes reasons, then set 4724 interim_reasons_mask to the value of DP reasons. 4725 4726 (4) If the IDP CRL extension is not present or omits 4727 onlySomeReasons and the DP omits reasons, then set 4728 interim_reasons_mask to the special value all-reasons. 4729 4730 (e) Verify that interim_reasons_mask includes one or more reasons 4731 that is not included in the reasons_mask. 4732 4733 (f) Obtain and validate the certification path for the complete CRL 4734 issuer. If a key usage extension is present in the CRL issuer's 4735 certificate, verify that the cRLSign bit is set. 4736 4737 (g) Validate the signature on the complete CRL using the public key 4738 validated in step (f). 4739 4740 (h) If use-deltas is set, then validate the signature on the delta 4741 CRL using the public key validated in step (f). 4742 4743 (i) If use-deltas is set, then search for the certificate on the 4744 delta CRL. If an entry is found that matches the certificate issuer 4745 and serial number as described in section 5.3.4, then set the 4746 cert_status variable to the indicated reason as follows: 4747 4748 (1) If the reason code CRL entry extension is present, set the 4749 cert_status variable to the value of the reason code CRL entry 4750 extension. 4751 4752 (2) If the reason code CRL entry extension is not present, set 4753 the cert_status variable to the value unspecified. 4754 4755 4756 4757 4758 4759 4760 4761 4762Housley, et. al. Standards Track [Page 85] 4763 4764RFC 3280 Internet X.509 Public Key Infrastructure April 2002 4765 4766 4767 (j) If (cert_status is UNREVOKED), then search for the 4768 certificate on the complete CRL. If an entry is found that 4769 matches the certificate issuer and serial number as described in 4770 section 5.3.4, then set the cert_status variable to the indicated 4771 reason as described in step (i). 4772 4773 (k) If (cert_status is removeFromCRL), then set cert_status to 4774 UNREVOKED. 4775 4776 If ((reasons_mask is all-reasons) OR (cert_status is not UNREVOKED)), 4777 then the revocation status has been determined, so return 4778 cert_status. 4779 4780 If the revocation status has not been determined, repeat the process 4781 above with any available CRLs not specified in a distribution point 4782 but issued by the certificate issuer. For the processing of such a 4783 CRL, assume a DP with both the reasons and the cRLIssuer fields 4784 omitted and a distribution point name of the certificate issuer. 4785 That is, the sequence of names in fullName is generated from the 4786 certificate issuer field as well as the certificate issuerAltName 4787 extension. If the revocation status remains undetermined, then 4788 return the cert_status UNDETERMINED. 4789 47907 References 4791 4792 [ISO 10646] ISO/IEC 10646-1:1993. International Standard -- 4793 Information technology -- Universal Multiple-Octet Coded 4794 Character Set (UCS) -- Part 1: Architecture and Basic 4795 Multilingual Plane. 4796 4797 [RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791, 4798 September 1981. 4799 4800 [RFC 822] Crocker, D., "Standard for the format of ARPA Internet 4801 text messages", STD 11, RFC 822, August 1982. 4802 4803 [RFC 1034] Mockapetris, P., "Domain Names - Concepts and 4804 Facilities", STD 13, RFC 1034, November 1987. 4805 4806 [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic 4807 Mail: Part II: Certificate-Based Key Management," RFC 4808 1422, February 1993. 4809 4810 [RFC 1423] Balenson, D., "Privacy Enhancement for Internet 4811 Electronic Mail: Part III: Algorithms, Modes, and 4812 Identifiers," RFC 1423, February 1993. 4813 4814 4815 4816 4817 4818Housley, et. al. Standards Track [Page 86] 4819 4820RFC 3280 Internet X.509 Public Key Infrastructure April 2002 4821 4822 4823 [RFC 1510] Kohl, J. and C. Neuman, "The Kerberos Network 4824 Authentication Service (V5)," RFC 1510, September 1993. 4825 4826 [RFC 1519] Fuller, V., T. Li, J. Yu and K. Varadhan, "Classless 4827 Inter-Domain Routing (CIDR): An Address Assignment and 4828 Aggregation Strategy", RFC 1519, September 1993. 4829 4830 [RFC 1738] Berners-Lee, T., L. Masinter and M. McCahill, "Uniform 4831 Resource Locators (URL)", RFC 1738, December 1994. 4832 4833 [RFC 1778] Howes, T., S. Kille, W. Yeong and C. Robbins, "The String 4834 Representation of Standard Attribute Syntaxes," RFC 1778, 4835 March 1995. 4836 4837 [RFC 1883] Deering, S. and R. Hinden. "Internet Protocol, Version 6 4838 (IPv6) Specification", RFC 1883, December 1995. 4839 4840 [RFC 2044] F. Yergeau, F., "UTF-8, a transformation format of 4841 Unicode and ISO 10646", RFC 2044, October 1996. 4842 4843 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 4844 Requirement Levels", BCP 14, RFC 2119, March 1997. 4845 4846 [RFC 2247] Kille, S., M. Wahl, A. Grimstad, R. Huber and S. 4847 Sataluri, "Using Domains in LDAP/X.500 Distinguished 4848 Names", RFC 2247, January 1998. 4849 4850 [RFC 2252] Wahl, M., A. Coulbeck, T. Howes and S. Kille, 4851 "Lightweight Directory Access Protocol (v3): Attribute 4852 Syntax Definitions", RFC 2252, December 1997. 4853 4854 [RFC 2277] Alvestrand, H., "IETF Policy on Character Sets and 4855 Languages", BCP 18, RFC 2277, January 1998. 4856 4857 [RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO 4858 10646", RFC 2279, January 1998. 4859 4860 [RFC 2459] Housley, R., W. Ford, W. Polk and D. Solo, "Internet 4861 X.509 Public Key Infrastructure: Certificate and CRL 4862 Profile", RFC 2459, January 1999. 4863 4864 [RFC 2560] Myers, M., R. Ankney, A. Malpani, S. Galperin and C. 4865 Adams, "Online Certificate Status Protocal - OCSP", June 4866 1999. 4867 4868 [SDN.701] SDN.701, "Message Security Protocol 4.0", Revision A, 4869 1997-02-06. 4870 4871 4872 4873 4874Housley, et. al. Standards Track [Page 87] 4875 4876RFC 3280 Internet X.509 Public Key Infrastructure April 2002 4877 4878 4879 [X.501] ITU-T Recommendation X.501: Information Technology - Open 4880 Systems Interconnection - The Directory: Models, 1993. 4881 4882 [X.509] ITU-T Recommendation X.509 (1997 E): Information 4883 Technology - Open Systems Interconnection - The 4884 Directory: Authentication Framework, June 1997. 4885 4886 [X.520] ITU-T Recommendation X.520: Information Technology - Open 4887 Systems Interconnection - The Directory: Selected 4888 Attribute Types, 1993. 4889 4890 [X.660] ITU-T Recommendation X.660 Information Technology - ASN.1 4891 encoding rules: Specification of Basic Encoding Rules 4892 (BER), Canonical Encoding Rules (CER) and Distinguished 4893 Encoding Rules (DER), 1997. 4894 4895 [X.690] ITU-T Recommendation X.690 Information Technology - Open 4896 Systems Interconnection - Procedures for the operation of 4897 OSI Registration Authorities: General procedures, 1992. 4898 4899 [X9.55] ANSI X9.55-1995, Public Key Cryptography For The 4900 Financial Services Industry: Extensions To Public Key 4901 Certificates And Certificate Revocation Lists, 8 4902 December, 1995. 4903 4904 [PKIXALGS] Bassham, L., Polk, W. and R. Housley, "Algorithms and 4905 Identifiers for the Internet X.509 Public Key 4906 Infrastructure Certificate and Certificate Revocation 4907 Lists (CRL) Profile", RFC 3279, April 2002. 4908 4909 [PKIXTSA] Adams, C., Cain, P., Pinkas, D. and R. Zuccherato, 4910 "Internet X.509 Public Key Infrastructure Time-Stamp 4911 Protocol (TSP)", RFC 3161, August 2001. 4912 49138 Intellectual Property Rights 4914 4915 The IETF has been notified of intellectual property rights claimed in 4916 regard to some or all of the specification contained in this 4917 document. For more information consult the online list of claimed 4918 rights (see http://www.ietf.org/ipr.html). 4919 4920 The IETF takes no position regarding the validity or scope of any 4921 intellectual property or other rights that might be claimed to 4922 pertain to the implementation or use of the technology described in 4923 this document or the extent to which any license under such rights 4924 might or might not be available; neither does it represent that it 4925 has made any effort to identify any such rights. Information on the 4926 IETF's procedures with respect to rights in standards-track and 4927 4928 4929 4930Housley, et. al. Standards Track [Page 88] 4931 4932RFC 3280 Internet X.509 Public Key Infrastructure April 2002 4933 4934 4935 standards-related documentation can be found in BCP 11. Copies of 4936 claims of rights made available for publication and any assurances of 4937 licenses to be made available, or the result of an attempt made to 4938 obtain a general license or permission for the use of such 4939 proprietary rights by implementors or users of this specification can 4940 be obtained from the IETF Secretariat. 4941 49429 Security Considerations 4943 4944 The majority of this specification is devoted to the format and 4945 content of certificates and CRLs. Since certificates and CRLs are 4946 digitally signed, no additional integrity service is necessary. 4947 Neither certificates nor CRLs need be kept secret, and unrestricted 4948 and anonymous access to certificates and CRLs has no security 4949 implications. 4950 4951 However, security factors outside the scope of this specification 4952 will affect the assurance provided to certificate users. This 4953 section highlights critical issues to be considered by implementers, 4954 administrators, and users. 4955 4956 The procedures performed by CAs and RAs to validate the binding of 4957 the subject's identity to their public key greatly affect the 4958 assurance that ought to be placed in the certificate. Relying 4959 parties might wish to review the CA's certificate practice statement. 4960 This is particularly important when issuing certificates to other 4961 CAs. 4962 4963 The use of a single key pair for both signature and other purposes is 4964 strongly discouraged. Use of separate key pairs for signature and 4965 key management provides several benefits to the users. The 4966 ramifications associated with loss or disclosure of a signature key 4967 are different from loss or disclosure of a key management key. Using 4968 separate key pairs permits a balanced and flexible response. 4969 Similarly, different validity periods or key lengths for each key 4970 pair may be appropriate in some application environments. 4971 Unfortunately, some legacy applications (e.g., SSL) use a single key 4972 pair for signature and key management. 4973 4974 The protection afforded private keys is a critical security factor. 4975 On a small scale, failure of users to protect their private keys will 4976 permit an attacker to masquerade as them, or decrypt their personal 4977 information. On a larger scale, compromise of a CA's private signing 4978 key may have a catastrophic effect. If an attacker obtains the 4979 private key unnoticed, the attacker may issue bogus certificates and 4980 CRLs. Existence of bogus certificates and CRLs will undermine 4981 confidence in the system. If such a compromise is detected, all 4982 certificates issued to the compromised CA MUST be revoked, preventing 4983 4984 4985 4986Housley, et. al. Standards Track [Page 89] 4987 4988RFC 3280 Internet X.509 Public Key Infrastructure April 2002 4989 4990 4991 services between its users and users of other CAs. Rebuilding after 4992 such a compromise will be problematic, so CAs are advised to 4993 implement a combination of strong technical measures (e.g., tamper- 4994 resistant cryptographic modules) and appropriate management 4995 procedures (e.g., separation of duties) to avoid such an incident. 4996 4997 Loss of a CA's private signing key may also be problematic. The CA 4998 would not be able to produce CRLs or perform normal key rollover. 4999 CAs SHOULD maintain secure backup for signing keys. The security of 5000 the key backup procedures is a critical factor in avoiding key 5001 compromise. 5002 5003 The availability and freshness of revocation information affects the 5004 degree of assurance that ought to be placed in a certificate. While 5005 certificates expire naturally, events may occur during its natural 5006 lifetime which negate the binding between the subject and public key. 5007 If revocation information is untimely or unavailable, the assurance 5008 associated with the binding is clearly reduced. Relying parties 5009 might not be able to process every critical extension that can appear 5010 in a CRL. CAs SHOULD take extra care when making revocation 5011 information available only through CRLs that contain critical 5012 extensions, particularly if support for those extensions is not 5013 mandated by this profile. For example, if revocation information is 5014 supplied using a combination of delta CRLs and full CRLs, and the 5015 delta CRLs are issued more frequently than the full CRLs, then 5016 relying parties that cannot handle the critical extensions related to 5017 delta CRL processing will not be able to obtain the most recent 5018 revocation information. Alternatively, if a full CRL is issued 5019 whenever a delta CRL is issued, then timely revocation information 5020 will be available to all relying parties. Similarly, implementations 5021 of the certification path validation mechanism described in section 6 5022 that omit revocation checking provide less assurance than those that 5023 support it. 5024 5025 The certification path validation algorithm depends on the certain 5026 knowledge of the public keys (and other information) about one or 5027 more trusted CAs. The decision to trust a CA is an important 5028 decision as it ultimately determines the trust afforded a 5029 certificate. The authenticated distribution of trusted CA public 5030 keys (usually in the form of a "self-signed" certificate) is a 5031 security critical out-of-band process that is beyond the scope of 5032 this specification. 5033 5034 In addition, where a key compromise or CA failure occurs for a 5035 trusted CA, the user will need to modify the information provided to 5036 the path validation routine. Selection of too many trusted CAs makes 5037 5038 5039 5040 5041 5042Housley, et. al. Standards Track [Page 90] 5043 5044RFC 3280 Internet X.509 Public Key Infrastructure April 2002 5045 5046 5047 the trusted CA information difficult to maintain. On the other hand, 5048 selection of only one trusted CA could limit users to a closed 5049 community of users. 5050 5051 The quality of implementations that process certificates also affects 5052 the degree of assurance provided. The path validation algorithm 5053 described in section 6 relies upon the integrity of the trusted CA 5054 information, and especially the integrity of the public keys 5055 associated with the trusted CAs. By substituting public keys for 5056 which an attacker has the private key, an attacker could trick the 5057 user into accepting false certificates. 5058 5059 The binding between a key and certificate subject cannot be stronger 5060 than the cryptographic module implementation and algorithms used to 5061 generate the signature. Short key lengths or weak hash algorithms 5062 will limit the utility of a certificate. CAs are encouraged to note 5063 advances in cryptology so they can employ strong cryptographic 5064 techniques. In addition, CAs SHOULD decline to issue certificates to 5065 CAs or end entities that generate weak signatures. 5066 5067 Inconsistent application of name comparison rules can result in 5068 acceptance of invalid X.509 certification paths, or rejection of 5069 valid ones. The X.500 series of specifications defines rules for 5070 comparing distinguished names that require comparison of strings 5071 without regard to case, character set, multi-character white space 5072 substring, or leading and trailing white space. This specification 5073 relaxes these requirements, requiring support for binary comparison 5074 at a minimum. 5075 5076 CAs MUST encode the distinguished name in the subject field of a CA 5077 certificate identically to the distinguished name in the issuer field 5078 in certificates issued by that CA. If CAs use different encodings, 5079 implementations might fail to recognize name chains for paths that 5080 include this certificate. As a consequence, valid paths could be 5081 rejected. 5082 5083 In addition, name constraints for distinguished names MUST be stated 5084 identically to the encoding used in the subject field or 5085 subjectAltName extension. If not, then name constraints stated as 5086 excludedSubTrees will not match and invalid paths will be accepted 5087 and name constraints expressed as permittedSubtrees will not match 5088 and valid paths will be rejected. To avoid acceptance of invalid 5089 paths, CAs SHOULD state name constraints for distinguished names as 5090 permittedSubtrees wherever possible. 5091 5092 5093 5094 5095 5096 5097 5098Housley, et. al. Standards Track [Page 91] 5099 5100RFC 3280 Internet X.509 Public Key Infrastructure April 2002 5101 5102 5103Appendix A. Psuedo-ASN.1 Structures and OIDs 5104 5105 This section describes data objects used by conforming PKI components 5106 in an "ASN.1-like" syntax. This syntax is a hybrid of the 1988 and 5107 1993 ASN.1 syntaxes. The 1988 ASN.1 syntax is augmented with 1993 5108 UNIVERSAL Types UniversalString, BMPString and UTF8String. 5109 5110 The ASN.1 syntax does not permit the inclusion of type statements in 5111 the ASN.1 module, and the 1993 ASN.1 standard does not permit use of 5112 the new UNIVERSAL types in modules using the 1988 syntax. As a 5113 result, this module does not conform to either version of the ASN.1 5114 standard. 5115 5116 This appendix may be converted into 1988 ASN.1 by replacing the 5117 definitions for the UNIVERSAL Types with the 1988 catch-all "ANY". 5118 5119A.1 Explicitly Tagged Module, 1988 Syntax 5120 5121PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) 5122 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) } 5123 5124DEFINITIONS EXPLICIT TAGS ::= 5125 5126BEGIN 5127 5128-- EXPORTS ALL -- 5129 5130-- IMPORTS NONE -- 5131 5132-- UNIVERSAL Types defined in 1993 and 1998 ASN.1 5133-- and required by this specification 5134 5135UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING 5136 -- UniversalString is defined in ASN.1:1993 5137 5138BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING 5139 -- BMPString is the subtype of UniversalString and models 5140 -- the Basic Multilingual Plane of ISO/IEC/ITU 10646-1 5141 5142UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 5143 -- The content of this type conforms to RFC 2279. 5144 5145-- PKIX specific OIDs 5146 5147id-pkix OBJECT IDENTIFIER ::= 5148 { iso(1) identified-organization(3) dod(6) internet(1) 5149 security(5) mechanisms(5) pkix(7) } 5150 5151 5152 5153 5154Housley, et. al. Standards Track [Page 92] 5155 5156RFC 3280 Internet X.509 Public Key Infrastructure April 2002 5157 5158 5159-- PKIX arcs 5160 5161id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 5162 -- arc for private certificate extensions 5163id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 5164 -- arc for policy qualifier types 5165id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 5166 -- arc for extended key purpose OIDS 5167id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 5168 -- arc for access descriptors 5169 5170-- policyQualifierIds for Internet policy qualifiers 5171 5172id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 5173 -- OID for CPS qualifier 5174id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 5175 -- OID for user notice qualifier 5176 5177-- access descriptor definitions 5178 5179id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 5180id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 5181id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 } 5182id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 } 5183 5184-- attribute data types 5185 5186Attribute ::= SEQUENCE { 5187 type AttributeType, 5188 values SET OF AttributeValue } 5189 -- at least one value is required 5190 5191AttributeType ::= OBJECT IDENTIFIER 5192 5193AttributeValue ::= ANY 5194 5195AttributeTypeAndValue ::= SEQUENCE { 5196 type AttributeType, 5197 value AttributeValue } 5198 5199-- suggested naming attributes: Definition of the following 5200-- information object set may be augmented to meet local 5201-- requirements. Note that deleting members of the set may 5202-- prevent interoperability with conforming implementations. 5203-- presented in pairs: the AttributeType followed by the 5204-- type definition for the corresponding AttributeValue 5205--Arc for standard naming attributes 5206id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 } 5207 5208 5209 5210Housley, et. al. Standards Track [Page 93] 5211 5212RFC 3280 Internet X.509 Public Key Infrastructure April 2002 5213 5214 5215-- Naming attributes of type X520name 5216 5217id-at-name AttributeType ::= { id-at 41 } 5218id-at-surname AttributeType ::= { id-at 4 } 5219id-at-givenName AttributeType ::= { id-at 42 } 5220id-at-initials AttributeType ::= { id-at 43 } 5221id-at-generationQualifier AttributeType ::= { id-at 44 } 5222 5223X520name ::= CHOICE { 5224 teletexString TeletexString (SIZE (1..ub-name)), 5225 printableString PrintableString (SIZE (1..ub-name)), 5226 universalString UniversalString (SIZE (1..ub-name)), 5227 utf8String UTF8String (SIZE (1..ub-name)), 5228 bmpString BMPString (SIZE (1..ub-name)) } 5229 5230-- Naming attributes of type X520CommonName 5231 5232id-at-commonName AttributeType ::= { id-at 3 } 5233 5234X520CommonName ::= CHOICE { 5235 teletexString TeletexString (SIZE (1..ub-common-name)), 5236 printableString PrintableString (SIZE (1..ub-common-name)), 5237 universalString UniversalString (SIZE (1..ub-common-name)), 5238 utf8String UTF8String (SIZE (1..ub-common-name)), 5239 bmpString BMPString (SIZE (1..ub-common-name)) } 5240 5241-- Naming attributes of type X520LocalityName 5242 5243id-at-localityName AttributeType ::= { id-at 7 } 5244 5245X520LocalityName ::= CHOICE { 5246 teletexString TeletexString (SIZE (1..ub-locality-name)), 5247 printableString PrintableString (SIZE (1..ub-locality-name)), 5248 universalString UniversalString (SIZE (1..ub-locality-name)), 5249 utf8String UTF8String (SIZE (1..ub-locality-name)), 5250 bmpString BMPString (SIZE (1..ub-locality-name)) } 5251 5252-- Naming attributes of type X520StateOrProvinceName 5253 5254id-at-stateOrProvinceName AttributeType ::= { id-at 8 } 5255 5256X520StateOrProvinceName ::= CHOICE { 5257 teletexString TeletexString (SIZE (1..ub-state-name)), 5258 printableString PrintableString (SIZE (1..ub-state-name)), 5259 universalString UniversalString (SIZE (1..ub-state-name)), 5260 utf8String UTF8String (SIZE (1..ub-state-name)), 5261 bmpString BMPString (SIZE(1..ub-state-name)) } 5262 5263 5264 5265 5266Housley, et. al. Standards Track [Page 94] 5267 5268RFC 3280 Internet X.509 Public Key Infrastructure April 2002 5269 5270 5271-- Naming attributes of type X520OrganizationName 5272 5273id-at-organizationName AttributeType ::= { id-at 10 } 5274 5275X520OrganizationName ::= CHOICE { 5276 teletexString TeletexString 5277 (SIZE (1..ub-organization-name)), 5278 printableString PrintableString 5279 (SIZE (1..ub-organization-name)), 5280 universalString UniversalString 5281 (SIZE (1..ub-organization-name)), 5282 utf8String UTF8String 5283 (SIZE (1..ub-organization-name)), 5284 bmpString BMPString 5285 (SIZE (1..ub-organization-name)) } 5286 5287-- Naming attributes of type X520OrganizationalUnitName 5288 5289id-at-organizationalUnitName AttributeType ::= { id-at 11 } 5290 5291X520OrganizationalUnitName ::= CHOICE { 5292 teletexString TeletexString 5293 (SIZE (1..ub-organizational-unit-name)), 5294 printableString PrintableString 5295 (SIZE (1..ub-organizational-unit-name)), 5296 universalString UniversalString 5297 (SIZE (1..ub-organizational-unit-name)), 5298 utf8String UTF8String 5299 (SIZE (1..ub-organizational-unit-name)), 5300 bmpString BMPString 5301 (SIZE (1..ub-organizational-unit-name)) } 5302 5303-- Naming attributes of type X520Title 5304 5305id-at-title AttributeType ::= { id-at 12 } 5306 5307X520Title ::= CHOICE { 5308 teletexString TeletexString (SIZE (1..ub-title)), 5309 printableString PrintableString (SIZE (1..ub-title)), 5310 universalString UniversalString (SIZE (1..ub-title)), 5311 utf8String UTF8String (SIZE (1..ub-title)), 5312 bmpString BMPString (SIZE (1..ub-title)) } 5313 5314-- Naming attributes of type X520dnQualifier 5315 5316id-at-dnQualifier AttributeType ::= { id-at 46 } 5317 5318X520dnQualifier ::= PrintableString 5319 5320 5321 5322Housley, et. al. Standards Track [Page 95] 5323 5324RFC 3280 Internet X.509 Public Key Infrastructure April 2002 5325 5326 5327-- Naming attributes of type X520countryName (digraph from IS 3166) 5328 5329id-at-countryName AttributeType ::= { id-at 6 } 5330 5331X520countryName ::= PrintableString (SIZE (2)) 5332 5333-- Naming attributes of type X520SerialNumber 5334 5335id-at-serialNumber AttributeType ::= { id-at 5 } 5336 5337X520SerialNumber ::= PrintableString (SIZE (1..ub-serial-number)) 5338 5339-- Naming attributes of type X520Pseudonym 5340 5341id-at-pseudonym AttributeType ::= { id-at 65 } 5342 5343X520Pseudonym ::= CHOICE { 5344 teletexString TeletexString (SIZE (1..ub-pseudonym)), 5345 printableString PrintableString (SIZE (1..ub-pseudonym)), 5346 universalString UniversalString (SIZE (1..ub-pseudonym)), 5347 utf8String UTF8String (SIZE (1..ub-pseudonym)), 5348 bmpString BMPString (SIZE (1..ub-pseudonym)) } 5349 5350-- Naming attributes of type DomainComponent (from RFC 2247) 5351 5352id-domainComponent AttributeType ::= 5353 { 0 9 2342 19200300 100 1 25 } 5354 5355DomainComponent ::= IA5String 5356 5357-- Legacy attributes 5358 5359pkcs-9 OBJECT IDENTIFIER ::= 5360 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 } 5361 5362id-emailAddress AttributeType ::= { pkcs-9 1 } 5363 5364EmailAddress ::= IA5String (SIZE (1..ub-emailaddress-length)) 5365 5366-- naming data types -- 5367 5368Name ::= CHOICE { -- only one possibility for now -- 5369 rdnSequence RDNSequence } 5370 5371RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 5372 5373DistinguishedName ::= RDNSequence 5374 5375 5376 5377 5378Housley, et. al. Standards Track [Page 96] 5379 5380RFC 3280 Internet X.509 Public Key Infrastructure April 2002 5381 5382 5383RelativeDistinguishedName ::= 5384 SET SIZE (1 .. MAX) OF AttributeTypeAndValue 5385 5386-- Directory string type -- 5387 5388DirectoryString ::= CHOICE { 5389 teletexString TeletexString (SIZE (1..MAX)), 5390 printableString PrintableString (SIZE (1..MAX)), 5391 universalString UniversalString (SIZE (1..MAX)), 5392 utf8String UTF8String (SIZE (1..MAX)), 5393 bmpString BMPString (SIZE (1..MAX)) } 5394 5395-- certificate and CRL specific structures begin here 5396 5397Certificate ::= SEQUENCE { 5398 tbsCertificate TBSCertificate, 5399 signatureAlgorithm AlgorithmIdentifier, 5400 signature BIT STRING } 5401 5402TBSCertificate ::= SEQUENCE { 5403 version [0] Version DEFAULT v1, 5404 serialNumber CertificateSerialNumber, 5405 signature AlgorithmIdentifier, 5406 issuer Name, 5407 validity Validity, 5408 subject Name, 5409 subjectPublicKeyInfo SubjectPublicKeyInfo, 5410 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 5411 -- If present, version MUST be v2 or v3 5412 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 5413 -- If present, version MUST be v2 or v3 5414 extensions [3] Extensions OPTIONAL 5415 -- If present, version MUST be v3 -- } 5416 5417Version ::= INTEGER { v1(0), v2(1), v3(2) } 5418 5419CertificateSerialNumber ::= INTEGER 5420 5421Validity ::= SEQUENCE { 5422 notBefore Time, 5423 notAfter Time } 5424 5425Time ::= CHOICE { 5426 utcTime UTCTime, 5427 generalTime GeneralizedTime } 5428 5429UniqueIdentifier ::= BIT STRING 5430 5431 5432 5433 5434Housley, et. al. Standards Track [Page 97] 5435 5436RFC 3280 Internet X.509 Public Key Infrastructure April 2002 5437 5438 5439SubjectPublicKeyInfo ::= SEQUENCE { 5440 algorithm AlgorithmIdentifier, 5441 subjectPublicKey BIT STRING } 5442 5443Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 5444 5445Extension ::= SEQUENCE { 5446 extnID OBJECT IDENTIFIER, 5447 critical BOOLEAN DEFAULT FALSE, 5448 extnValue OCTET STRING } 5449 5450-- CRL structures 5451 5452CertificateList ::= SEQUENCE { 5453 tbsCertList TBSCertList, 5454 signatureAlgorithm AlgorithmIdentifier, 5455 signature BIT STRING } 5456 5457TBSCertList ::= SEQUENCE { 5458 version Version OPTIONAL, 5459 -- if present, MUST be v2 5460 signature AlgorithmIdentifier, 5461 issuer Name, 5462 thisUpdate Time, 5463 nextUpdate Time OPTIONAL, 5464 revokedCertificates SEQUENCE OF SEQUENCE { 5465 userCertificate CertificateSerialNumber, 5466 revocationDate Time, 5467 crlEntryExtensions Extensions OPTIONAL 5468 -- if present, MUST be v2 5469 } OPTIONAL, 5470 crlExtensions [0] Extensions OPTIONAL } 5471 -- if present, MUST be v2 5472 5473-- Version, Time, CertificateSerialNumber, and Extensions were 5474-- defined earlier for use in the certificate structure 5475 5476AlgorithmIdentifier ::= SEQUENCE { 5477 algorithm OBJECT IDENTIFIER, 5478 parameters ANY DEFINED BY algorithm OPTIONAL } 5479 -- contains a value of the type 5480 -- registered for use with the 5481 -- algorithm object identifier value 5482 5483-- X.400 address syntax starts here 5484 5485 5486 5487 5488 5489 5490Housley, et. al. Standards Track [Page 98] 5491 5492RFC 3280 Internet X.509 Public Key Infrastructure April 2002 5493 5494 5495ORAddress ::= SEQUENCE { 5496 built-in-standard-attributes BuiltInStandardAttributes, 5497 built-in-domain-defined-attributes 5498 BuiltInDomainDefinedAttributes OPTIONAL, 5499 -- see also teletex-domain-defined-attributes 5500 extension-attributes ExtensionAttributes OPTIONAL } 5501 5502-- Built-in Standard Attributes 5503 5504BuiltInStandardAttributes ::= SEQUENCE { 5505 country-name CountryName OPTIONAL, 5506 administration-domain-name AdministrationDomainName OPTIONAL, 5507 network-address [0] IMPLICIT NetworkAddress OPTIONAL, 5508 -- see also extended-network-address 5509 terminal-identifier [1] IMPLICIT TerminalIdentifier OPTIONAL, 5510 private-domain-name [2] PrivateDomainName OPTIONAL, 5511 organization-name [3] IMPLICIT OrganizationName OPTIONAL, 5512 -- see also teletex-organization-name 5513 numeric-user-identifier [4] IMPLICIT NumericUserIdentifier 5514 OPTIONAL, 5515 personal-name [5] IMPLICIT PersonalName OPTIONAL, 5516 -- see also teletex-personal-name 5517 organizational-unit-names [6] IMPLICIT OrganizationalUnitNames 5518 OPTIONAL } 5519 -- see also teletex-organizational-unit-names 5520 5521CountryName ::= [APPLICATION 1] CHOICE { 5522 x121-dcc-code NumericString 5523 (SIZE (ub-country-name-numeric-length)), 5524 iso-3166-alpha2-code PrintableString 5525 (SIZE (ub-country-name-alpha-length)) } 5526 5527AdministrationDomainName ::= [APPLICATION 2] CHOICE { 5528 numeric NumericString (SIZE (0..ub-domain-name-length)), 5529 printable PrintableString (SIZE (0..ub-domain-name-length)) } 5530 5531NetworkAddress ::= X121Address -- see also extended-network-address 5532 5533X121Address ::= NumericString (SIZE (1..ub-x121-address-length)) 5534 5535TerminalIdentifier ::= PrintableString (SIZE 5536(1..ub-terminal-id-length)) 5537 5538PrivateDomainName ::= CHOICE { 5539 numeric NumericString (SIZE (1..ub-domain-name-length)), 5540 printable PrintableString (SIZE (1..ub-domain-name-length)) } 5541 5542 5543 5544 5545 5546Housley, et. al. Standards Track [Page 99] 5547 5548RFC 3280 Internet X.509 Public Key Infrastructure April 2002 5549 5550 5551OrganizationName ::= PrintableString 5552 (SIZE (1..ub-organization-name-length)) 5553 -- see also teletex-organization-name 5554 5555NumericUserIdentifier ::= NumericString 5556 (SIZE (1..ub-numeric-user-id-length)) 5557 5558PersonalName ::= SET { 5559 surname [0] IMPLICIT PrintableString 5560 (SIZE (1..ub-surname-length)), 5561 given-name [1] IMPLICIT PrintableString 5562 (SIZE (1..ub-given-name-length)) OPTIONAL, 5563 initials [2] IMPLICIT PrintableString 5564 (SIZE (1..ub-initials-length)) OPTIONAL, 5565 generation-qualifier [3] IMPLICIT PrintableString 5566 (SIZE (1..ub-generation-qualifier-length)) 5567 OPTIONAL } 5568 -- see also teletex-personal-name 5569 5570OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units) 5571 OF OrganizationalUnitName 5572 -- see also teletex-organizational-unit-names 5573 5574OrganizationalUnitName ::= PrintableString (SIZE 5575 (1..ub-organizational-unit-name-length)) 5576 5577-- Built-in Domain-defined Attributes 5578 5579BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE 5580 (1..ub-domain-defined-attributes) OF 5581 BuiltInDomainDefinedAttribute 5582 5583BuiltInDomainDefinedAttribute ::= SEQUENCE { 5584 type PrintableString (SIZE 5585 (1..ub-domain-defined-attribute-type-length)), 5586 value PrintableString (SIZE 5587 (1..ub-domain-defined-attribute-value-length)) } 5588 5589-- Extension Attributes 5590 5591ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF 5592 ExtensionAttribute 5593 5594ExtensionAttribute ::= SEQUENCE { 5595 extension-attribute-type [0] IMPLICIT INTEGER 5596 (0..ub-extension-attributes), 5597 extension-attribute-value [1] 5598 ANY DEFINED BY extension-attribute-type } 5599 5600 5601 5602Housley, et. al. Standards Track [Page 100] 5603 5604RFC 3280 Internet X.509 Public Key Infrastructure April 2002 5605 5606 5607-- Extension types and attribute values 5608 5609common-name INTEGER ::= 1 5610 5611CommonName ::= PrintableString (SIZE (1..ub-common-name-length)) 5612 5613teletex-common-name INTEGER ::= 2 5614 5615TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length)) 5616 5617teletex-organization-name INTEGER ::= 3 5618 5619TeletexOrganizationName ::= 5620 TeletexString (SIZE (1..ub-organization-name-length)) 5621 5622teletex-personal-name INTEGER ::= 4 5623 5624TeletexPersonalName ::= SET { 5625 surname [0] IMPLICIT TeletexString 5626 (SIZE (1..ub-surname-length)), 5627 given-name [1] IMPLICIT TeletexString 5628 (SIZE (1..ub-given-name-length)) OPTIONAL, 5629 initials [2] IMPLICIT TeletexString 5630 (SIZE (1..ub-initials-length)) OPTIONAL, 5631 generation-qualifier [3] IMPLICIT TeletexString 5632 (SIZE (1..ub-generation-qualifier-length)) 5633 OPTIONAL } 5634 5635teletex-organizational-unit-names INTEGER ::= 5 5636 5637TeletexOrganizationalUnitNames ::= SEQUENCE SIZE 5638 (1..ub-organizational-units) OF TeletexOrganizationalUnitName 5639 5640TeletexOrganizationalUnitName ::= TeletexString 5641 (SIZE (1..ub-organizational-unit-name-length)) 5642 5643pds-name INTEGER ::= 7 5644 5645PDSName ::= PrintableString (SIZE (1..ub-pds-name-length)) 5646 5647physical-delivery-country-name INTEGER ::= 8 5648 5649PhysicalDeliveryCountryName ::= CHOICE { 5650 x121-dcc-code NumericString (SIZE 5651(ub-country-name-numeric-length)), 5652 iso-3166-alpha2-code PrintableString 5653 (SIZE (ub-country-name-alpha-length)) } 5654 5655 5656 5657 5658Housley, et. al. Standards Track [Page 101] 5659 5660RFC 3280 Internet X.509 Public Key Infrastructure April 2002 5661 5662 5663postal-code INTEGER ::= 9 5664 5665PostalCode ::= CHOICE { 5666 numeric-code NumericString (SIZE (1..ub-postal-code-length)), 5667 printable-code PrintableString (SIZE (1..ub-postal-code-length)) } 5668 5669physical-delivery-office-name INTEGER ::= 10 5670 5671PhysicalDeliveryOfficeName ::= PDSParameter 5672 5673physical-delivery-office-number INTEGER ::= 11 5674 5675PhysicalDeliveryOfficeNumber ::= PDSParameter 5676 5677extension-OR-address-components INTEGER ::= 12 5678 5679ExtensionORAddressComponents ::= PDSParameter 5680 5681physical-delivery-personal-name INTEGER ::= 13 5682 5683PhysicalDeliveryPersonalName ::= PDSParameter 5684 5685physical-delivery-organization-name INTEGER ::= 14 5686 5687PhysicalDeliveryOrganizationName ::= PDSParameter 5688 5689extension-physical-delivery-address-components INTEGER ::= 15 5690 5691ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter 5692 5693unformatted-postal-address INTEGER ::= 16 5694 5695UnformattedPostalAddress ::= SET { 5696 printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) 5697 OF PrintableString (SIZE (1..ub-pds-parameter-length)) 5698 OPTIONAL, 5699 teletex-string TeletexString 5700 (SIZE (1..ub-unformatted-address-length)) OPTIONAL } 5701 5702street-address INTEGER ::= 17 5703 5704StreetAddress ::= PDSParameter 5705 5706post-office-box-address INTEGER ::= 18 5707 5708PostOfficeBoxAddress ::= PDSParameter 5709 5710poste-restante-address INTEGER ::= 19 5711 5712 5713 5714Housley, et. al. Standards Track [Page 102] 5715 5716RFC 3280 Internet X.509 Public Key Infrastructure April 2002 5717 5718 5719PosteRestanteAddress ::= PDSParameter 5720 5721unique-postal-name INTEGER ::= 20 5722 5723UniquePostalName ::= PDSParameter 5724 5725local-postal-attributes INTEGER ::= 21 5726 5727LocalPostalAttributes ::= PDSParameter 5728 5729PDSParameter ::= SET { 5730 printable-string PrintableString 5731 (SIZE(1..ub-pds-parameter-length)) OPTIONAL, 5732 teletex-string TeletexString 5733 (SIZE(1..ub-pds-parameter-length)) OPTIONAL } 5734 5735extended-network-address INTEGER ::= 22 5736 5737ExtendedNetworkAddress ::= CHOICE { 5738 e163-4-address SEQUENCE { 5739 number [0] IMPLICIT NumericString 5740 (SIZE (1..ub-e163-4-number-length)), 5741 sub-address [1] IMPLICIT NumericString 5742 (SIZE (1..ub-e163-4-sub-address-length)) 5743 OPTIONAL }, 5744 psap-address [0] IMPLICIT PresentationAddress } 5745 5746PresentationAddress ::= SEQUENCE { 5747 pSelector [0] EXPLICIT OCTET STRING OPTIONAL, 5748 sSelector [1] EXPLICIT OCTET STRING OPTIONAL, 5749 tSelector [2] EXPLICIT OCTET STRING OPTIONAL, 5750 nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING } 5751 5752terminal-type INTEGER ::= 23 5753 5754TerminalType ::= INTEGER { 5755 telex (3), 5756 teletex (4), 5757 g3-facsimile (5), 5758 g4-facsimile (6), 5759 ia5-terminal (7), 5760 videotex (8) } (0..ub-integer-options) 5761 5762-- Extension Domain-defined Attributes 5763 5764teletex-domain-defined-attributes INTEGER ::= 6 5765 5766 5767 5768 5769 5770Housley, et. al. Standards Track [Page 103] 5771 5772RFC 3280 Internet X.509 Public Key Infrastructure April 2002 5773 5774 5775TeletexDomainDefinedAttributes ::= SEQUENCE SIZE 5776 (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute 5777 5778TeletexDomainDefinedAttribute ::= SEQUENCE { 5779 type TeletexString 5780 (SIZE (1..ub-domain-defined-attribute-type-length)), 5781 value TeletexString 5782 (SIZE (1..ub-domain-defined-attribute-value-length)) } 5783 5784-- specifications of Upper Bounds MUST be regarded as mandatory 5785-- from Annex B of ITU-T X.411 Reference Definition of MTS Parameter 5786-- Upper Bounds 5787 5788-- Upper Bounds 5789ub-name INTEGER ::= 32768 5790ub-common-name INTEGER ::= 64 5791ub-locality-name INTEGER ::= 128 5792ub-state-name INTEGER ::= 128 5793ub-organization-name INTEGER ::= 64 5794ub-organizational-unit-name INTEGER ::= 64 5795ub-title INTEGER ::= 64 5796ub-serial-number INTEGER ::= 64 5797ub-match INTEGER ::= 128 5798ub-emailaddress-length INTEGER ::= 128 5799ub-common-name-length INTEGER ::= 64 5800ub-country-name-alpha-length INTEGER ::= 2 5801ub-country-name-numeric-length INTEGER ::= 3 5802ub-domain-defined-attributes INTEGER ::= 4 5803ub-domain-defined-attribute-type-length INTEGER ::= 8 5804ub-domain-defined-attribute-value-length INTEGER ::= 128 5805ub-domain-name-length INTEGER ::= 16 5806ub-extension-attributes INTEGER ::= 256 5807ub-e163-4-number-length INTEGER ::= 15 5808ub-e163-4-sub-address-length INTEGER ::= 40 5809ub-generation-qualifier-length INTEGER ::= 3 5810ub-given-name-length INTEGER ::= 16 5811ub-initials-length INTEGER ::= 5 5812ub-integer-options INTEGER ::= 256 5813ub-numeric-user-id-length INTEGER ::= 32 5814ub-organization-name-length INTEGER ::= 64 5815ub-organizational-unit-name-length INTEGER ::= 32 5816ub-organizational-units INTEGER ::= 4 5817ub-pds-name-length INTEGER ::= 16 5818ub-pds-parameter-length INTEGER ::= 30 5819ub-pds-physical-address-lines INTEGER ::= 6 5820ub-postal-code-length INTEGER ::= 16 5821ub-pseudonym INTEGER ::= 128 5822ub-surname-length INTEGER ::= 40 5823 5824 5825 5826Housley, et. al. Standards Track [Page 104] 5827 5828RFC 3280 Internet X.509 Public Key Infrastructure April 2002 5829 5830 5831ub-terminal-id-length INTEGER ::= 24 5832ub-unformatted-address-length INTEGER ::= 180 5833ub-x121-address-length INTEGER ::= 16 5834 5835-- Note - upper bounds on string types, such as TeletexString, are 5836-- measured in characters. Excepting PrintableString or IA5String, a 5837-- significantly greater number of octets will be required to hold 5838-- such a value. As a minimum, 16 octets, or twice the specified 5839-- upper bound, whichever is the larger, should be allowed for 5840-- TeletexString. For UTF8String or UniversalString at least four 5841-- times the upper bound should be allowed. 5842 5843END 5844 5845A.2 Implicitly Tagged Module, 1988 Syntax 5846 5847PKIX1Implicit88 { iso(1) identified-organization(3) dod(6) internet(1) 5848 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19) } 5849 5850DEFINITIONS IMPLICIT TAGS ::= 5851 5852BEGIN 5853 5854-- EXPORTS ALL -- 5855 5856IMPORTS 5857 id-pe, id-kp, id-qt-unotice, id-qt-cps, 5858 -- delete following line if "new" types are supported -- 5859 BMPString, UTF8String, -- end "new" types -- 5860 ORAddress, Name, RelativeDistinguishedName, 5861 CertificateSerialNumber, Attribute, DirectoryString 5862 FROM PKIX1Explicit88 { iso(1) identified-organization(3) 5863 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 5864 id-mod(0) id-pkix1-explicit(18) }; 5865 5866 5867-- ISO arc for standard certificate and CRL extensions 5868 5869id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 5870 5871-- authority key identifier OID and syntax 5872 5873id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 5874 5875 5876 5877 5878 5879 5880 5881 5882Housley, et. al. Standards Track [Page 105] 5883 5884RFC 3280 Internet X.509 Public Key Infrastructure April 2002 5885 5886 5887AuthorityKeyIdentifier ::= SEQUENCE { 5888 keyIdentifier [0] KeyIdentifier OPTIONAL, 5889 authorityCertIssuer [1] GeneralNames OPTIONAL, 5890 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 5891 -- authorityCertIssuer and authorityCertSerialNumber MUST both 5892 -- be present or both be absent 5893 5894KeyIdentifier ::= OCTET STRING 5895 5896-- subject key identifier OID and syntax 5897 5898id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 5899 5900SubjectKeyIdentifier ::= KeyIdentifier 5901 5902-- key usage extension OID and syntax 5903 5904id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 5905 5906KeyUsage ::= BIT STRING { 5907 digitalSignature (0), 5908 nonRepudiation (1), 5909 keyEncipherment (2), 5910 dataEncipherment (3), 5911 keyAgreement (4), 5912 keyCertSign (5), 5913 cRLSign (6), 5914 encipherOnly (7), 5915 decipherOnly (8) } 5916 5917-- private key usage period extension OID and syntax 5918 5919id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 5920 5921PrivateKeyUsagePeriod ::= SEQUENCE { 5922 notBefore [0] GeneralizedTime OPTIONAL, 5923 notAfter [1] GeneralizedTime OPTIONAL } 5924 -- either notBefore or notAfter MUST be present 5925 5926-- certificate policies extension OID and syntax 5927 5928id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 5929 5930anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 } 5931 5932CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 5933 5934PolicyInformation ::= SEQUENCE { 5935 5936 5937 5938Housley, et. al. Standards Track [Page 106] 5939 5940RFC 3280 Internet X.509 Public Key Infrastructure April 2002 5941 5942 5943 policyIdentifier CertPolicyId, 5944 policyQualifiers SEQUENCE SIZE (1..MAX) OF 5945 PolicyQualifierInfo OPTIONAL } 5946 5947CertPolicyId ::= OBJECT IDENTIFIER 5948 5949PolicyQualifierInfo ::= SEQUENCE { 5950 policyQualifierId PolicyQualifierId, 5951 qualifier ANY DEFINED BY policyQualifierId } 5952 5953-- Implementations that recognize additional policy qualifiers MUST 5954-- augment the following definition for PolicyQualifierId 5955 5956PolicyQualifierId ::= 5957 OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) 5958 5959-- CPS pointer qualifier 5960 5961CPSuri ::= IA5String 5962 5963-- user notice qualifier 5964 5965UserNotice ::= SEQUENCE { 5966 noticeRef NoticeReference OPTIONAL, 5967 explicitText DisplayText OPTIONAL} 5968 5969NoticeReference ::= SEQUENCE { 5970 organization DisplayText, 5971 noticeNumbers SEQUENCE OF INTEGER } 5972 5973DisplayText ::= CHOICE { 5974 ia5String IA5String (SIZE (1..200)), 5975 visibleString VisibleString (SIZE (1..200)), 5976 bmpString BMPString (SIZE (1..200)), 5977 utf8String UTF8String (SIZE (1..200)) } 5978 5979-- policy mapping extension OID and syntax 5980 5981id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 5982 5983PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 5984 issuerDomainPolicy CertPolicyId, 5985 subjectDomainPolicy CertPolicyId } 5986 5987-- subject alternative name extension OID and syntax 5988 5989id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 5990 5991 5992 5993 5994Housley, et. al. Standards Track [Page 107] 5995 5996RFC 3280 Internet X.509 Public Key Infrastructure April 2002 5997 5998 5999SubjectAltName ::= GeneralNames 6000 6001GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 6002 6003GeneralName ::= CHOICE { 6004 otherName [0] AnotherName, 6005 rfc822Name [1] IA5String, 6006 dNSName [2] IA5String, 6007 x400Address [3] ORAddress, 6008 directoryName [4] Name, 6009 ediPartyName [5] EDIPartyName, 6010 uniformResourceIdentifier [6] IA5String, 6011 iPAddress [7] OCTET STRING, 6012 registeredID [8] OBJECT IDENTIFIER } 6013 6014-- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as 6015-- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax 6016 6017AnotherName ::= SEQUENCE { 6018 type-id OBJECT IDENTIFIER, 6019 value [0] EXPLICIT ANY DEFINED BY type-id } 6020 6021EDIPartyName ::= SEQUENCE { 6022 nameAssigner [0] DirectoryString OPTIONAL, 6023 partyName [1] DirectoryString } 6024 6025-- issuer alternative name extension OID and syntax 6026 6027id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 6028 6029IssuerAltName ::= GeneralNames 6030 6031id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 6032 6033SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 6034 6035-- basic constraints extension OID and syntax 6036 6037id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 6038 6039BasicConstraints ::= SEQUENCE { 6040 cA BOOLEAN DEFAULT FALSE, 6041 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 6042 6043-- name constraints extension OID and syntax 6044 6045id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 6046 6047 6048 6049 6050Housley, et. al. Standards Track [Page 108] 6051 6052RFC 3280 Internet X.509 Public Key Infrastructure April 2002 6053 6054 6055NameConstraints ::= SEQUENCE { 6056 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 6057 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 6058 6059GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 6060 6061GeneralSubtree ::= SEQUENCE { 6062 base GeneralName, 6063 minimum [0] BaseDistance DEFAULT 0, 6064 maximum [1] BaseDistance OPTIONAL } 6065 6066BaseDistance ::= INTEGER (0..MAX) 6067 6068-- policy constraints extension OID and syntax 6069 6070id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } 6071 6072PolicyConstraints ::= SEQUENCE { 6073 requireExplicitPolicy [0] SkipCerts OPTIONAL, 6074 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 6075 6076SkipCerts ::= INTEGER (0..MAX) 6077 6078-- CRL distribution points extension OID and syntax 6079 6080id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31} 6081 6082CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 6083 6084DistributionPoint ::= SEQUENCE { 6085 distributionPoint [0] DistributionPointName OPTIONAL, 6086 reasons [1] ReasonFlags OPTIONAL, 6087 cRLIssuer [2] GeneralNames OPTIONAL } 6088 6089DistributionPointName ::= CHOICE { 6090 fullName [0] GeneralNames, 6091 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 6092 6093ReasonFlags ::= BIT STRING { 6094 unused (0), 6095 keyCompromise (1), 6096 cACompromise (2), 6097 affiliationChanged (3), 6098 superseded (4), 6099 cessationOfOperation (5), 6100 certificateHold (6), 6101 privilegeWithdrawn (7), 6102 aACompromise (8) } 6103 6104 6105 6106Housley, et. al. Standards Track [Page 109] 6107 6108RFC 3280 Internet X.509 Public Key Infrastructure April 2002 6109 6110 6111-- extended key usage extension OID and syntax 6112 6113id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 6114 6115ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 6116 6117 6118KeyPurposeId ::= OBJECT IDENTIFIER 6119 6120-- permit unspecified key uses 6121 6122anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 } 6123 6124-- extended key purpose OIDs 6125 6126id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } 6127id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } 6128id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } 6129id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } 6130id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 6131id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 } 6132 6133-- inhibit any policy OID and syntax 6134 6135id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 } 6136 6137InhibitAnyPolicy ::= SkipCerts 6138 6139-- freshest (delta)CRL extension OID and syntax 6140 6141id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } 6142 6143FreshestCRL ::= CRLDistributionPoints 6144 6145-- authority info access 6146 6147id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 6148 6149AuthorityInfoAccessSyntax ::= 6150 SEQUENCE SIZE (1..MAX) OF AccessDescription 6151 6152AccessDescription ::= SEQUENCE { 6153 accessMethod OBJECT IDENTIFIER, 6154 accessLocation GeneralName } 6155 6156-- subject info access 6157 6158id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 } 6159 6160 6161 6162Housley, et. al. Standards Track [Page 110] 6163 6164RFC 3280 Internet X.509 Public Key Infrastructure April 2002 6165 6166 6167SubjectInfoAccessSyntax ::= 6168 SEQUENCE SIZE (1..MAX) OF AccessDescription 6169 6170-- CRL number extension OID and syntax 6171 6172id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 6173 6174CRLNumber ::= INTEGER (0..MAX) 6175 6176-- issuing distribution point extension OID and syntax 6177 6178id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 6179 6180IssuingDistributionPoint ::= SEQUENCE { 6181 distributionPoint [0] DistributionPointName OPTIONAL, 6182 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 6183 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 6184 onlySomeReasons [3] ReasonFlags OPTIONAL, 6185 indirectCRL [4] BOOLEAN DEFAULT FALSE, 6186 onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE } 6187 6188id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 6189 6190BaseCRLNumber ::= CRLNumber 6191 6192-- CRL reasons extension OID and syntax 6193 6194id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 } 6195 6196CRLReason ::= ENUMERATED { 6197 unspecified (0), 6198 keyCompromise (1), 6199 cACompromise (2), 6200 affiliationChanged (3), 6201 superseded (4), 6202 cessationOfOperation (5), 6203 certificateHold (6), 6204 removeFromCRL (8), 6205 privilegeWithdrawn (9), 6206 aACompromise (10) } 6207 6208-- certificate issuer CRL entry extension OID and syntax 6209 6210id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } 6211 6212CertificateIssuer ::= GeneralNames 6213 6214-- hold instruction extension OID and syntax 6215 6216 6217 6218Housley, et. al. Standards Track [Page 111] 6219 6220RFC 3280 Internet X.509 Public Key Infrastructure April 2002 6221 6222 6223id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 6224 6225HoldInstructionCode ::= OBJECT IDENTIFIER 6226 6227-- ANSI x9 holdinstructions 6228 6229-- ANSI x9 arc holdinstruction arc 6230 6231holdInstruction OBJECT IDENTIFIER ::= 6232 {joint-iso-itu-t(2) member-body(2) us(840) x9cm(10040) 2} 6233 6234-- ANSI X9 holdinstructions referenced by this standard 6235 6236id-holdinstruction-none OBJECT IDENTIFIER ::= 6237 {holdInstruction 1} -- deprecated 6238 6239id-holdinstruction-callissuer OBJECT IDENTIFIER ::= 6240 {holdInstruction 2} 6241 6242id-holdinstruction-reject OBJECT IDENTIFIER ::= 6243 {holdInstruction 3} 6244 6245-- invalidity date CRL entry extension OID and syntax 6246 6247id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 6248 6249InvalidityDate ::= GeneralizedTime 6250 6251END 6252 6253Appendix B. ASN.1 Notes 6254 6255 CAs MUST force the serialNumber to be a non-negative integer, that 6256 is, the sign bit in the DER encoding of the INTEGER value MUST be 6257 zero - this can be done by adding a leading (leftmost) `00'H octet if 6258 necessary. This removes a potential ambiguity in mapping between a 6259 string of octets and an integer value. 6260 6261 As noted in section 4.1.2.2, serial numbers can be expected to 6262 contain long integers. Certificate users MUST be able to handle 6263 serialNumber values up to 20 octets in length. Conformant CAs MUST 6264 NOT use serialNumber values longer than 20 octets. 6265 6266 As noted in section 5.2.3, CRL numbers can be expected to contain 6267 long integers. CRL validators MUST be able to handle cRLNumber 6268 values up to 20 octets in length. Conformant CRL issuers MUST NOT 6269 use cRLNumber values longer than 20 octets. 6270 6271 6272 6273 6274Housley, et. al. Standards Track [Page 112] 6275 6276RFC 3280 Internet X.509 Public Key Infrastructure April 2002 6277 6278 6279 The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 6280 constructs. A valid ASN.1 sequence will have zero or more entries. 6281 The SIZE (1..MAX) construct constrains the sequence to have at least 6282 one entry. MAX indicates the upper bound is unspecified. 6283 Implementations are free to choose an upper bound that suits their 6284 environment. 6285 6286 The construct "positiveInt ::= INTEGER (0..MAX)" defines positiveInt 6287 as a subtype of INTEGER containing integers greater than or equal to 6288 zero. The upper bound is unspecified. Implementations are free to 6289 select an upper bound that suits their environment. 6290 6291 The character string type PrintableString supports a very basic Latin 6292 character set: the lower case letters 'a' through 'z', upper case 6293 letters 'A' through 'Z', the digits '0' through '9', eleven special 6294 characters ' = ( ) + , - . / : ? and space. 6295 6296 Implementers should note that the at sign ('@') and underscore ('_') 6297 characters are not supported by the ASN.1 type PrintableString. 6298 These characters often appear in internet addresses. Such addresses 6299 MUST be encoded using an ASN.1 type that supports them. They are 6300 usually encoded as IA5String in either the emailAddress attribute 6301 within a distinguished name or the rfc822Name field of GeneralName. 6302 Conforming implementations MUST NOT encode strings which include 6303 either the at sign or underscore character as PrintableString. 6304 6305 The character string type TeletexString is a superset of 6306 PrintableString. TeletexString supports a fairly standard (ASCII- 6307 like) Latin character set, Latin characters with non-spacing accents 6308 and Japanese characters. 6309 6310 Named bit lists are BIT STRINGs where the values have been assigned 6311 names. This specification makes use of named bit lists in the 6312 definitions for the key usage, CRL distribution points and freshest 6313 CRL certificate extensions, as well as the freshest CRL and issuing 6314 distribution point CRL extensions. When DER encoding a named bit 6315 list, trailing zeroes MUST be omitted. That is, the encoded value 6316 ends with the last named bit that is set to one. 6317 6318 The character string type UniversalString supports any of the 6319 characters allowed by ISO 10646-1 [ISO 10646]. ISO 10646-1 is the 6320 Universal multiple-octet coded Character Set (UCS). ISO 10646-1 6321 specifies the architecture and the "basic multilingual plane" -- a 6322 large standard character set which includes all major world character 6323 standards. 6324 6325 6326 6327 6328 6329 6330Housley, et. al. Standards Track [Page 113] 6331 6332RFC 3280 Internet X.509 Public Key Infrastructure April 2002 6333 6334 6335 The character string type UTF8String was introduced in the 1997 6336 version of ASN.1, and UTF8String was added to the list of choices for 6337 DirectoryString in the 2001 version of X.520 [X.520]. UTF8String is 6338 a universal type and has been assigned tag number 12. The content of 6339 UTF8String was defined by RFC 2044 [RFC 2044] and updated in RFC 2279 6340 [RFC 2279]. 6341 6342 In anticipation of these changes, and in conformance with IETF Best 6343 Practices codified in RFC 2277 [RFC 2277], IETF Policy on Character 6344 Sets and Languages, this document includes UTF8String as a choice in 6345 DirectoryString and the CPS qualifier extensions. 6346 6347 Implementers should note that the DER encoding of the SET OF values 6348 requires ordering of the encodings of the values. In particular, 6349 this issue arises with respect to distinguished names. 6350 6351 Implementers should note that the DER encoding of SET or SEQUENCE 6352 components whose value is the DEFAULT omit the component from the 6353 encoded certificate or CRL. For example, a BasicConstraints 6354 extension whose cA value is FALSE would omit the cA boolean from the 6355 encoded certificate. 6356 6357 Object Identifiers (OIDs) are used throughout this specification to 6358 identify certificate policies, public key and signature algorithms, 6359 certificate extensions, etc. There is no maximum size for OIDs. 6360 This specification mandates support for OIDs which have arc elements 6361 with values that are less than 2^28, that is, they MUST be between 0 6362 and 268,435,455, inclusive. This allows each arc element to be 6363 represented within a single 32 bit word. Implementations MUST also 6364 support OIDs where the length of the dotted decimal (see [RFC 2252], 6365 section 4.1) string representation can be up to 100 bytes 6366 (inclusive). Implementations MUST be able to handle OIDs with up to 6367 20 elements (inclusive). CAs SHOULD NOT issue certificates which 6368 contain OIDs that exceed these requirements. Likewise, CRL issuers 6369 SHOULD NOT issue CRLs which contain OIDs that exceed these 6370 requirements. 6371 6372 Implementors are warned that the X.500 standards community has 6373 developed a series of extensibility rules. These rules determine 6374 when an ASN.1 definition can be changed without assigning a new 6375 object identifier (OID). For example, at least two extension 6376 definitions included in RFC 2459 [RFC 2459], the predecessor to this 6377 profile document, have different ASN.1 definitions in this 6378 specification, but the same OID is used. If unknown elements appear 6379 within an extension, and the extension is not marked critical, those 6380 unknown elements ought to be ignored, as follows: 6381 6382 (a) ignore all unknown bit name assignments within a bit string; 6383 6384 6385 6386Housley, et. al. Standards Track [Page 114] 6387 6388RFC 3280 Internet X.509 Public Key Infrastructure April 2002 6389 6390 6391 (b) ignore all unknown named numbers in an ENUMERATED type or 6392 INTEGER type that is being used in the enumerated style, provided 6393 the number occurs as an optional element of a SET or SEQUENCE; and 6394 6395 (c) ignore all unknown elements in SETs, at the end of SEQUENCEs, 6396 or in CHOICEs where the CHOICE is itself an optional element of a 6397 SET or SEQUENCE. 6398 6399 If an extension containing unexpected values is marked critical, the 6400 implementation MUST reject the certificate or CRL containing the 6401 unrecognized extension. 6402 6403Appendix C. Examples 6404 6405 This section contains four examples: three certificates and a CRL. 6406 The first two certificates and the CRL comprise a minimal 6407 certification path. 6408 6409 Section C.1 contains an annotated hex dump of a "self-signed" 6410 certificate issued by a CA whose distinguished name is 6411 cn=us,o=gov,ou=nist. The certificate contains a DSA public key with 6412 parameters, and is signed by the corresponding DSA private key. 6413 6414 Section C.2 contains an annotated hex dump of an end entity 6415 certificate. The end entity certificate contains a DSA public key, 6416 and is signed by the private key corresponding to the "self-signed" 6417 certificate in section C.1. 6418 6419 Section C.3 contains a dump of an end entity certificate which 6420 contains an RSA public key and is signed with RSA and MD5. This 6421 certificate is not part of the minimal certification path. 6422 6423 Section C.4 contains an annotated hex dump of a CRL. The CRL is 6424 issued by the CA whose distinguished name is cn=us,o=gov,ou=nist and 6425 the list of revoked certificates includes the end entity certificate 6426 presented in C.2. 6427 6428 The certificates were processed using Peter Gutman's dumpasn1 utility 6429 to generate the output. The source for the dumpasn1 utility is 6430 available at <http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c>. The 6431 binaries for the certificates and CRLs are available at 6432 <http://csrc.nist.gov/pki/pkixtools>. 6433 6434C.1 Certificate 6435 6436 This section contains an annotated hex dump of a 699 byte version 3 6437 certificate. The certificate contains the following information: 6438 (a) the serial number is 23 (17 hex); 6439 6440 6441 6442Housley, et. al. Standards Track [Page 115] 6443 6444RFC 3280 Internet X.509 Public Key Infrastructure April 2002 6445 6446 6447 (b) the certificate is signed with DSA and the SHA-1 hash algorithm; 6448 (c) the issuer's distinguished name is OU=NIST; O=gov; C=US 6449 (d) and the subject's distinguished name is OU=NIST; O=gov; C=US 6450 (e) the certificate was issued on June 30, 1997 and will expire on 6451 December 31, 1997; 6452 (f) the certificate contains a 1024 bit DSA public key with 6453 parameters; 6454 (g) the certificate contains a subject key identifier extension 6455 generated using method (1) of section 4.2.1.2; and 6456 (h) the certificate is a CA certificate (as indicated through the 6457 basic constraints extension.) 6458 6459 0 30 699: SEQUENCE { 6460 4 30 635: SEQUENCE { 6461 8 A0 3: [0] { 6462 10 02 1: INTEGER 2 6463 : } 6464 13 02 1: INTEGER 17 6465 16 30 9: SEQUENCE { 6466 18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 6467 : } 6468 27 30 42: SEQUENCE { 6469 29 31 11: SET { 6470 31 30 9: SEQUENCE { 6471 33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 6472 38 13 2: PrintableString 'US' 6473 : } 6474 : } 6475 42 31 12: SET { 6476 44 30 10: SEQUENCE { 6477 46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 6478 51 13 3: PrintableString 'gov' 6479 : } 6480 : } 6481 56 31 13: SET { 6482 58 30 11: SEQUENCE { 6483 60 06 3: OBJECT IDENTIFIER 6484 : organizationalUnitName (2 5 4 11) 6485 65 13 4: PrintableString 'NIST' 6486 : } 6487 : } 6488 : } 6489 71 30 30: SEQUENCE { 6490 73 17 13: UTCTime '970630000000Z' 6491 88 17 13: UTCTime '971231000000Z' 6492 : } 6493103 30 42: SEQUENCE { 6494105 31 11: SET { 6495 6496 6497 6498Housley, et. al. Standards Track [Page 116] 6499 6500RFC 3280 Internet X.509 Public Key Infrastructure April 2002 6501 6502 6503107 30 9: SEQUENCE { 6504109 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 6505114 13 2: PrintableString 'US' 6506 : } 6507 : } 6508118 31 12: SET { 6509120 30 10: SEQUENCE { 6510122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 6511127 13 3: PrintableString 'gov' 6512 : } 6513 : } 6514132 31 13: SET { 6515134 30 11: SEQUENCE { 6516136 06 3: OBJECT IDENTIFIER 6517 : organizationalUnitName (2 5 4 11) 6518141 13 4: PrintableString 'NIST' 6519 : } 6520 : } 6521 : } 6522147 30 440: SEQUENCE { 6523151 30 300: SEQUENCE { 6524155 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) 6525164 30 287: SEQUENCE { 6526168 02 129: INTEGER 6527 : 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC 6528 : FB 95 32 AC 01 12 33 B9 E0 1C AD 90 9B BC 6529 : 48 54 9E F3 94 77 3C 2C 71 35 55 E6 FE 4F 6530 : 22 CB D5 D8 3E 89 93 33 4D FC BD 4F 41 64 6531 : 3E A2 98 70 EC 31 B4 50 DE EB F1 98 28 0A 6532 : C9 3E 44 B3 FD 22 97 96 83 D0 18 A3 E3 BD 6533 : 35 5B FF EE A3 21 72 6A 7B 96 DA B9 3F 1E 6534 : 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A 6535 : FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48 6536 : 63 FE 43 6537300 02 21: INTEGER 6538 : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA 6539 : 55 F7 7D 57 74 81 E5 6540323 02 129: INTEGER 6541 : 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91 6542 : C0 8E 47 F1 0A C3 01 47 C2 44 42 36 A9 92 6543 : 81 DE 57 C5 E0 68 86 58 00 7B 1F F9 9B 77 6544 : A1 C5 10 A5 80 91 78 51 51 3C F6 FC FC CC 6545 : 46 C6 81 78 92 84 3D F4 93 3D 0C 38 7E 1A 6546 : 5B 99 4E AB 14 64 F6 0C 21 22 4E 28 08 9C 6547 : 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 39 A2 6548 : 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF 6549 : F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE 6550 : 1E 57 18 6551 6552 6553 6554Housley, et. al. Standards Track [Page 117] 6555 6556RFC 3280 Internet X.509 Public Key Infrastructure April 2002 6557 6558 6559 : } 6560 : } 6561455 03 133: BIT STRING 0 unused bits, encapsulates { 6562459 02 129: INTEGER 6563 : 00 B5 9E 1F 49 04 47 D1 DB F5 3A DD CA 04 6564 : 75 E8 DD 75 F6 9B 8A B1 97 D6 59 69 82 D3 6565 : 03 4D FD 3B 36 5F 4A F2 D1 4E C1 07 F5 D1 6566 : 2A D3 78 77 63 56 EA 96 61 4D 42 0B 7A 1D 6567 : FB AB 91 A4 CE DE EF 77 C8 E5 EF 20 AE A6 6568 : 28 48 AF BE 69 C3 6A A5 30 F2 C2 B9 D9 82 6569 : 2B 7D D9 C4 84 1F DE 0D E8 54 D7 1B 99 2E 6570 : B3 D0 88 F6 D6 63 9B A7 E2 0E 82 D4 3B 8A 6571 : 68 1B 06 56 31 59 0B 49 EB 99 A5 D5 81 41 6572 : 7B C9 55 6573 : } 6574 : } 6575591 A3 50: [3] { 6576593 30 48: SEQUENCE { 6577595 30 29: SEQUENCE { 6578597 06 3: OBJECT IDENTIFIER 6579 : subjectKeyIdentifier (2 5 29 14) 6580602 04 22: OCTET STRING, encapsulates { 6581604 04 20: OCTET STRING 6582 : 86 CA A5 22 81 62 EF AD 0A 89 BC AD 72 41 6583 : 2C 29 49 F4 86 56 6584 : } 6585 : } 6586626 30 15: SEQUENCE { 6587628 06 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19) 6588633 01 1: BOOLEAN TRUE 6589636 04 5: OCTET STRING, encapsulates { 6590638 30 3: SEQUENCE { 6591640 01 1: BOOLEAN TRUE 6592 : } 6593 : } 6594 : } 6595 : } 6596 : } 6597 : } 6598643 30 9: SEQUENCE { 6599645 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 6600 : } 6601654 03 47: BIT STRING 0 unused bits, encapsulates { 6602657 30 44: SEQUENCE { 6603659 02 20: INTEGER 6604 : 43 1B CF 29 25 45 C0 4E 52 E7 7D D6 FC B1 6605 : 66 4C 83 CF 2D 77 6606681 02 20: INTEGER 6607 6608 6609 6610Housley, et. al. Standards Track [Page 118] 6611 6612RFC 3280 Internet X.509 Public Key Infrastructure April 2002 6613 6614 6615 : 0B 5B 9A 24 11 98 E8 F3 86 90 04 F6 08 A9 6616 : E1 8D A5 CC 3A D4 6617 : } 6618 : } 6619 : } 6620 6621C.2 Certificate 6622 6623 This section contains an annotated hex dump of a 730 byte version 3 6624 certificate. The certificate contains the following information: 6625 (a) the serial number is 18 (12 hex); 6626 (b) the certificate is signed with DSA and the SHA-1 hash algorithm; 6627 (c) the issuer's distinguished name is OU=nist; O=gov; C=US 6628 (d) and the subject's distinguished name is CN=Tim Polk; OU=nist; 6629 O=gov; C=US 6630 (e) the certificate was valid from July 30, 1997 through December 1, 6631 1997; 6632 (f) the certificate contains a 1024 bit DSA public key; 6633 (g) the certificate is an end entity certificate, as the basic 6634 constraints extension is not present; 6635 (h) the certificate contains an authority key identifier extension 6636 matching the subject key identifier of the certificate in Appendix 6637 C.1; and 6638 (i) the certificate includes one alternative name - an RFC 822 6639 address of "wpolk@nist.gov". 6640 6641 0 30 730: SEQUENCE { 6642 4 30 665: SEQUENCE { 6643 8 A0 3: [0] { 6644 10 02 1: INTEGER 2 6645 : } 6646 13 02 1: INTEGER 18 6647 16 30 9: SEQUENCE { 6648 18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 6649 : } 6650 27 30 42: SEQUENCE { 6651 29 31 11: SET { 6652 31 30 9: SEQUENCE { 6653 33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 6654 38 13 2: PrintableString 'US' 6655 : } 6656 : } 6657 42 31 12: SET { 6658 44 30 10: SEQUENCE { 6659 46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 6660 51 13 3: PrintableString 'gov' 6661 : } 6662 : } 6663 6664 6665 6666Housley, et. al. Standards Track [Page 119] 6667 6668RFC 3280 Internet X.509 Public Key Infrastructure April 2002 6669 6670 6671 56 31 13: SET { 6672 58 30 11: SEQUENCE { 6673 60 06 3: OBJECT IDENTIFIER 6674 : organizationalUnitName (2 5 4 11) 6675 65 13 4: PrintableString 'NIST' 6676 : } 6677 : } 6678 : } 6679 71 30 30: SEQUENCE { 6680 73 17 13: UTCTime '970730000000Z' 6681 88 17 13: UTCTime '971201000000Z' 6682 : } 6683 103 30 61: SEQUENCE { 6684 105 31 11: SET { 6685 107 30 9: SEQUENCE { 6686 109 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 6687 114 13 2: PrintableString 'US' 6688 : } 6689 : } 6690 118 31 12: SET { 6691 120 30 10: SEQUENCE { 6692 122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 6693 127 13 3: PrintableString 'gov' 6694 : } 6695 : } 6696 132 31 13: SET { 6697 134 30 11: SEQUENCE { 6698 136 06 3: OBJECT IDENTIFIER 6699 : organizationalUnitName (2 5 4 11) 6700 141 13 4: PrintableString 'NIST' 6701 : } 6702 : } 6703 147 31 17: SET { 6704 149 30 15: SEQUENCE { 6705 151 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 6706 156 13 8: PrintableString 'Tim Polk' 6707 : } 6708 : } 6709 : } 6710 166 30 439: SEQUENCE { 6711 170 30 300: SEQUENCE { 6712 174 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) 6713 183 30 287: SEQUENCE { 6714 187 02 129: INTEGER 6715 : 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC 6716 : FB 95 32 AC 01 12 33 B9 E0 1C AD 90 9B BC 6717 : 48 54 9E F3 94 77 3C 2C 71 35 55 E6 FE 4F 6718 : 22 CB D5 D8 3E 89 93 33 4D FC BD 4F 41 64 6719 6720 6721 6722Housley, et. al. Standards Track [Page 120] 6723 6724RFC 3280 Internet X.509 Public Key Infrastructure April 2002 6725 6726 6727 : 3E A2 98 70 EC 31 B4 50 DE EB F1 98 28 0A 6728 : C9 3E 44 B3 FD 22 97 96 83 D0 18 A3 E3 BD 6729 : 35 5B FF EE A3 21 72 6A 7B 96 DA B9 3F 1E 6730 : 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A 6731 : FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48 6732 : 63 FE 43 6733 319 02 21: INTEGER 6734 : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA 6735 : 55 F7 7D 57 74 81 E5 6736 342 02 129: INTEGER 6737 : 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91 6738 : C0 8E 47 F1 0A C3 01 47 C2 44 42 36 A9 92 6739 : 81 DE 57 C5 E0 68 86 58 00 7B 1F F9 9B 77 6740 : A1 C5 10 A5 80 91 78 51 51 3C F6 FC FC CC 6741 : 46 C6 81 78 92 84 3D F4 93 3D 0C 38 7E 1A 6742 : 5B 99 4E AB 14 64 F6 0C 21 22 4E 28 08 9C 6743 : 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 39 A2 6744 : 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF 6745 : F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE 6746 : 1E 57 18 6747 : } 6748 : } 6749 474 03 132: BIT STRING 0 unused bits, encapsulates { 6750 478 02 128: INTEGER 6751 : 30 B6 75 F7 7C 20 31 AE 38 BB 7E 0D 2B AB 6752 : A0 9C 4B DF 20 D5 24 13 3C CD 98 E5 5F 6C 6753 : B7 C1 BA 4A BA A9 95 80 53 F0 0D 72 DC 33 6754 : 37 F4 01 0B F5 04 1F 9D 2E 1F 62 D8 84 3A 6755 : 9B 25 09 5A 2D C8 46 8E 2B D4 F5 0D 3B C7 6756 : 2D C6 6C B9 98 C1 25 3A 44 4E 8E CA 95 61 6757 : 35 7C CE 15 31 5C 23 13 1E A2 05 D1 7A 24 6758 : 1C CB D3 72 09 90 FF 9B 9D 28 C0 A1 0A EC 6759 : 46 9F 0D B8 D0 DC D0 18 A6 2B 5E F9 8F B5 6760 : 95 BE 6761 : } 6762 : } 6763 609 A3 62: [3] { 6764 611 30 60: SEQUENCE { 6765 613 30 25: SEQUENCE { 6766 615 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 6767 620 04 18: OCTET STRING, encapsulates { 6768 622 30 16: SEQUENCE { 6769 624 81 14: [1] 'wpolk@nist.gov' 6770 : } 6771 : } 6772 : } 6773 640 30 31: SEQUENCE { 6774 642 06 3: OBJECT IDENTIFIER 6775 6776 6777 6778Housley, et. al. Standards Track [Page 121] 6779 6780RFC 3280 Internet X.509 Public Key Infrastructure April 2002 6781 6782 6783 : authorityKeyIdentifier (2 5 29 35) 6784 647 04 24: OCTET STRING, encapsulates { 6785 649 30 22: SEQUENCE { 6786 651 80 20: [0] 6787 : 86 CA A5 22 81 62 EF AD 0A 89 BC AD 72 6788 : 41 2C 29 49 F4 86 56 6789 : } 6790 : } 6791 : } 6792 : } 6793 : } 6794 : } 6795 673 30 9: SEQUENCE { 6796 675 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 6797 : } 6798 684 03 48: BIT STRING 0 unused bits, encapsulates { 6799 687 30 45: SEQUENCE { 6800 689 02 20: INTEGER 6801 : 36 97 CB E3 B4 2C E1 BB 61 A9 D3 CC 24 CC 6802 : 22 92 9F F4 F5 87 6803 711 02 21: INTEGER 6804 : 00 AB C9 79 AF D2 16 1C A9 E3 68 A9 14 10 6805 : B4 A0 2E FF 22 5A 73 6806 : } 6807 : } 6808 : } 6809 6810C.3 End Entity Certificate Using RSA 6811 6812 This section contains an annotated hex dump of a 654 byte version 3 6813 certificate. The certificate contains the following information: 6814 (a) the serial number is 256; 6815 (b) the certificate is signed with RSA and the SHA-1 hash algorithm; 6816 (c) the issuer's distinguished name is OU=NIST; O=gov; C=US 6817 (d) and the subject's distinguished name is CN=Tim Polk; OU=NIST; 6818 O=gov; C=US 6819 (e) the certificate was issued on May 21, 1996 at 09:58:26 and 6820 expired on May 21, 1997 at 09:58:26; 6821 (f) the certificate contains a 1024 bit RSA public key; 6822 (g) the certificate is an end entity certificate (not a CA 6823 certificate); 6824 (h) the certificate includes an alternative subject name of 6825 "<http://www.itl.nist.gov/div893/staff/polk/index.html>" and an 6826 alternative issuer name of "<http://www.nist.gov/>" - both are URLs; 6827 (i) the certificate include an authority key identifier extension 6828 and a certificate policies extension specifying the policy OID 6829 2.16.840.1.101.3.2.1.48.9; and 6830 6831 6832 6833 6834Housley, et. al. Standards Track [Page 122] 6835 6836RFC 3280 Internet X.509 Public Key Infrastructure April 2002 6837 6838 6839 (j) the certificate includes a critical key usage extension 6840 specifying that the public key is intended for verification of 6841 digital signatures. 6842 6843 0 30 654: SEQUENCE { 6844 4 30 503: SEQUENCE { 6845 8 A0 3: [0] { 6846 10 02 1: INTEGER 2 6847 : } 6848 13 02 2: INTEGER 256 6849 17 30 13: SEQUENCE { 6850 19 06 9: OBJECT IDENTIFIER 6851 : sha1withRSAEncryption (1 2 840 113549 1 1 5) 6852 30 05 0: NULL 6853 : } 6854 32 30 42: SEQUENCE { 6855 34 31 11: SET { 6856 36 30 9: SEQUENCE { 6857 38 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 6858 43 13 2: PrintableString 'US' 6859 : } 6860 : } 6861 47 31 12: SET { 6862 49 30 10: SEQUENCE { 6863 51 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 6864 56 13 3: PrintableString 'gov' 6865 : } 6866 : } 6867 61 31 13: SET { 6868 63 30 11: SEQUENCE { 6869 65 06 3: OBJECT IDENTIFIER 6870 : organizationalUnitName (2 5 4 11) 6871 70 13 4: PrintableString 'NIST' 6872 : } 6873 : } 6874 : } 6875 76 30 30: SEQUENCE { 6876 78 17 13: UTCTime '960521095826Z' 6877 93 17 13: UTCTime '970521095826Z' 6878 : } 6879108 30 61: SEQUENCE { 6880110 31 11: SET { 6881112 30 9: SEQUENCE { 6882114 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 6883119 13 2: PrintableString 'US' 6884 : } 6885 : } 6886123 31 12: SET { 6887 6888 6889 6890Housley, et. al. Standards Track [Page 123] 6891 6892RFC 3280 Internet X.509 Public Key Infrastructure April 2002 6893 6894 6895125 30 10: SEQUENCE { 6896127 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 6897132 13 3: PrintableString 'gov' 6898 : } 6899 : } 6900137 31 13: SET { 6901139 30 11: SEQUENCE { 6902141 06 3: OBJECT IDENTIFIER 6903 : organizationalUnitName (2 5 4 11) 6904146 13 4: PrintableString 'NIST' 6905 : } 6906 : } 6907152 31 17: SET { 6908154 30 15: SEQUENCE { 6909156 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 6910161 13 8: PrintableString 'Tim Polk' 6911 : } 6912 : } 6913 : } 6914171 30 159: SEQUENCE { 6915174 30 13: SEQUENCE { 6916176 06 9: OBJECT IDENTIFIER 6917 : rsaEncryption (1 2 840 113549 1 1 1) 6918187 05 0: NULL 6919 : } 6920189 03 141: BIT STRING 0 unused bits, encapsulates { 6921193 30 137: SEQUENCE { 6922196 02 129: INTEGER 6923 : 00 E1 6A E4 03 30 97 02 3C F4 10 F3 B5 1E 6924 : 4D 7F 14 7B F6 F5 D0 78 E9 A4 8A F0 A3 75 6925 : EC ED B6 56 96 7F 88 99 85 9A F2 3E 68 77 6926 : 87 EB 9E D1 9F C0 B4 17 DC AB 89 23 A4 1D 6927 : 7E 16 23 4C 4F A8 4D F5 31 B8 7C AA E3 1A 6928 : 49 09 F4 4B 26 DB 27 67 30 82 12 01 4A E9 6929 : 1A B6 C1 0C 53 8B 6C FC 2F 7A 43 EC 33 36 6930 : 7E 32 B2 7B D5 AA CF 01 14 C6 12 EC 13 F2 6931 : 2D 14 7A 8B 21 58 14 13 4C 46 A3 9A F2 16 6932 : 95 FF 23 6933328 02 3: INTEGER 65537 6934 : } 6935 : } 6936 : } 6937333 A3 175: [3] { 6938336 30 172: SEQUENCE { 6939339 30 63: SEQUENCE { 6940341 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 6941346 04 56: OCTET STRING, encapsulates { 6942348 30 54: SEQUENCE { 6943 6944 6945 6946Housley, et. al. Standards Track [Page 124] 6947 6948RFC 3280 Internet X.509 Public Key Infrastructure April 2002 6949 6950 6951350 86 52: [6] 6952 : 'http://www.itl.nist.gov/div893/staff/' 6953 : 'polk/index.html' 6954 : } 6955 : } 6956 : } 6957404 30 31: SEQUENCE { 6958406 06 3: OBJECT IDENTIFIER issuerAltName (2 5 29 18) 6959411 04 24: OCTET STRING, encapsulates { 6960413 30 22: SEQUENCE { 6961415 86 20: [6] 'http://www.nist.gov/' 6962 : } 6963 : } 6964 : } 6965437 30 31: SEQUENCE { 6966439 06 3: OBJECT IDENTIFIER 6967 : authorityKeyIdentifier (2 5 29 35) 6968444 04 24: OCTET STRING, encapsulates { 6969446 30 22: SEQUENCE { 6970448 80 20: [0] 6971 : 08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E 6972 : 70 6A 4A 20 84 2C 32 6973 : } 6974 : } 6975 : } 6976470 30 23: SEQUENCE { 6977472 06 3: OBJECT IDENTIFIER 6978 : certificatePolicies (2 5 29 32) 6979477 04 16: OCTET STRING, encapsulates { 6980479 30 14: SEQUENCE { 6981481 30 12: SEQUENCE { 6982483 06 10: OBJECT IDENTIFIER 6983 : '2 16 840 1 101 3 2 1 48 9' 6984 : } 6985 : } 6986 : } 6987 : } 6988495 30 14: SEQUENCE { 6989497 06 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) 6990502 01 1: BOOLEAN TRUE 6991505 04 4: OCTET STRING, encapsulates { 6992507 03 2: BIT STRING 7 unused bits 6993 : '1'B (bit 0) 6994 : } 6995 : } 6996 : } 6997 : } 6998 : } 6999 7000 7001 7002Housley, et. al. Standards Track [Page 125] 7003 7004RFC 3280 Internet X.509 Public Key Infrastructure April 2002 7005 7006 7007511 30 13: SEQUENCE { 7008513 06 9: OBJECT IDENTIFIER 7009 : sha1withRSAEncryption (1 2 840 113549 1 1 5) 7010524 05 0: NULL 7011 : } 7012526 03 129: BIT STRING 0 unused bits 7013 : 1E 07 77 6E 66 B5 B6 B8 57 F0 03 DC 6F 77 7014 : 6D AF 55 1D 74 E5 CE 36 81 FC 4B C5 F4 47 7015 : 82 C4 0A 25 AA 8D D6 7D 3A 89 AB 44 34 39 7016 : F6 BD 61 1A 78 85 7A B8 1E 92 A2 22 2F CE 7017 : 07 1A 08 8E F1 46 03 59 36 4A CB 60 E6 03 7018 : 40 01 5B 2A 44 D6 E4 7F EB 43 5E 74 0A E6 7019 : E4 F9 3E E1 44 BE 1F E7 5F 5B 2C 41 8D 08 7020 : BD 26 FE 6A A6 C3 2F B2 3B 41 12 6B C1 06 7021 : 8A B8 4C 91 59 EB 2F 38 20 2A 67 74 20 0B 7022 : 77 F3 7023 : } 7024 7025C.4 Certificate Revocation List 7026 7027 This section contains an annotated hex dump of a version 2 CRL with 7028 one extension (cRLNumber). The CRL was issued by OU=NIST; O=gov; 7029 C=US on August 7, 1997; the next scheduled issuance was September 7, 7030 1997. The CRL includes one revoked certificates: serial number 18 7031 (12 hex), which was revoked on July 31, 1997 due to keyCompromise. 7032 The CRL itself is number 18, and it was signed with DSA and SHA-1. 7033 7034 0 30 203: SEQUENCE { 7035 3 30 140: SEQUENCE { 7036 6 02 1: INTEGER 1 7037 9 30 9: SEQUENCE { 7038 11 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 7039 : } 7040 20 30 42: SEQUENCE { 7041 22 31 11: SET { 7042 24 30 9: SEQUENCE { 7043 26 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 7044 31 13 2: PrintableString 'US' 7045 : } 7046 : } 7047 35 31 12: SET { 7048 37 30 10: SEQUENCE { 7049 39 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 7050 44 13 3: PrintableString 'gov' 7051 : } 7052 : } 7053 49 31 13: SET { 7054 51 30 11: SEQUENCE { 7055 7056 7057 7058Housley, et. al. Standards Track [Page 126] 7059 7060RFC 3280 Internet X.509 Public Key Infrastructure April 2002 7061 7062 7063 53 06 3: OBJECT IDENTIFIER 7064 : organizationalUnitName (2 5 4 11) 7065 58 13 4: PrintableString 'NIST' 7066 : } 7067 : } 7068 : } 7069 64 17 13: UTCTime '970807000000Z' 7070 79 17 13: UTCTime '970907000000Z' 7071 94 30 34: SEQUENCE { 7072 96 30 32: SEQUENCE { 7073 98 02 1: INTEGER 18 7074101 17 13: UTCTime '970731000000Z' 7075116 30 12: SEQUENCE { 7076118 30 10: SEQUENCE { 7077120 06 3: OBJECT IDENTIFIER cRLReason (2 5 29 21) 7078125 04 3: OCTET STRING, encapsulates { 7079127 0A 1: ENUMERATED 1 7080 : } 7081 : } 7082 : } 7083 : } 7084 : } 7085130 A0 14: [0] { 7086132 30 12: SEQUENCE { 7087134 30 10: SEQUENCE { 7088136 06 3: OBJECT IDENTIFIER cRLNumber (2 5 29 20) 7089141 04 3: OCTET STRING, encapsulates { 7090143 02 1: INTEGER 12 7091 : } 7092 : } 7093 : } 7094 : } 7095 : } 7096146 30 9: SEQUENCE { 7097148 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 7098 : } 7099157 03 47: BIT STRING 0 unused bits, encapsulates { 7100160 30 44: SEQUENCE { 7101162 02 20: INTEGER 7102 : 22 4E 9F 43 BA 95 06 34 F2 BB 5E 65 DB A6 7103 : 80 05 C0 3A 29 47 7104184 02 20: INTEGER 7105 : 59 1A 57 C9 82 D7 02 21 14 C3 D4 0B 32 1B 7106 : 96 16 B1 1F 46 5A 7107 : } 7108 : } 7109 : } 7110 7111 7112 7113 7114Housley, et. al. Standards Track [Page 127] 7115 7116RFC 3280 Internet X.509 Public Key Infrastructure April 2002 7117 7118 7119Author Addresses 7120 7121 Russell Housley 7122 RSA Laboratories 7123 918 Spring Knoll Drive 7124 Herndon, VA 20170 7125 USA 7126 7127 EMail: rhousley@rsasecurity.com 7128 7129 Warwick Ford 7130 VeriSign, Inc. 7131 401 Edgewater Place 7132 Wakefield, MA 01880 7133 USA 7134 7135 EMail: wford@verisign.com 7136 7137 Tim Polk 7138 NIST 7139 Building 820, Room 426 7140 Gaithersburg, MD 20899 7141 USA 7142 7143 EMail: wpolk@nist.gov 7144 7145 David Solo 7146 Citigroup 7147 909 Third Ave, 16th Floor 7148 New York, NY 10043 7149 USA 7150 7151 EMail: dsolo@alum.mit.edu 7152 7153 7154 7155 7156 7157 7158 7159 7160 7161 7162 7163 7164 7165 7166 7167 7168 7169 7170Housley, et. al. Standards Track [Page 128] 7171 7172RFC 3280 Internet X.509 Public Key Infrastructure April 2002 7173 7174 7175Full Copyright Statement 7176 7177 Copyright (C) The Internet Society (2002). All Rights Reserved. 7178 7179 This document and translations of it may be copied and furnished to 7180 others, and derivative works that comment on or otherwise explain it 7181 or assist in its implementation may be prepared, copied, published 7182 and distributed, in whole or in part, without restriction of any 7183 kind, provided that the above copyright notice and this paragraph are 7184 included on all such copies and derivative works. However, this 7185 document itself may not be modified in any way, such as by removing 7186 the copyright notice or references to the Internet Society or other 7187 Internet organizations, except as needed for the purpose of 7188 developing Internet standards in which case the procedures for 7189 copyrights defined in the Internet Standards process must be 7190 followed, or as required to translate it into languages other than 7191 English. 7192 7193 The limited permissions granted above are perpetual and will not be 7194 revoked by the Internet Society or its successors or assigns. 7195 7196 This document and the information contained herein is provided on an 7197 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 7198 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 7199 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 7200 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 7201 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 7202 7203Acknowledgement 7204 7205 Funding for the RFC Editor function is currently provided by the 7206 Internet Society. 7207 7208 7209 7210 7211 7212 7213 7214 7215 7216 7217 7218 7219 7220 7221 7222 7223 7224 7225 7226Housley, et. al. Standards Track [Page 129] 7227 7228