vlm | 270be9f | 2004-09-07 06:37:25 +0000 | [diff] [blame] | 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | Network Working Group R. Housley |
| 8 | Request for Comments: 3280 RSA Laboratories |
| 9 | Obsoletes: 2459 W. Polk |
| 10 | Category: 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 | |
| 20 | Status 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 | |
| 28 | Copyright Notice |
| 29 | |
| 30 | Copyright (C) The Internet Society (2002). All Rights Reserved. |
| 31 | |
| 32 | Abstract |
| 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 | |
| 46 | Table 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 | |
| 58 | Housley, et. al. Standards Track [Page 1] |
| 59 | |
| 60 | RFC 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 | |
| 114 | Housley, et. al. Standards Track [Page 2] |
| 115 | |
| 116 | RFC 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 | |
| 170 | Housley, et. al. Standards Track [Page 3] |
| 171 | |
| 172 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 173 | |
| 174 | |
| 175 | Full Copyright Statement . . . . . . . . . . . . . . . . . . 129 |
| 176 | |
| 177 | 1 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 | |
| 226 | Housley, et. al. Standards Track [Page 4] |
| 227 | |
| 228 | RFC 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 | |
| 269 | 2 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 | |
| 282 | Housley, et. al. Standards Track [Page 5] |
| 283 | |
| 284 | RFC 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 | |
| 312 | 2.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 | |
| 327 | 2.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 | |
| 338 | Housley, et. al. Standards Track [Page 6] |
| 339 | |
| 340 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 341 | |
| 342 | |
| 343 | 2.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 | |
| 357 | 2.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 | |
| 366 | 3 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 | |
| 394 | Housley, et. al. Standards Track [Page 7] |
| 395 | |
| 396 | RFC 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 | |
| 432 | 3.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 | |
| 450 | Housley, et. al. Standards Track [Page 8] |
| 451 | |
| 452 | RFC 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 | |
| 494 | 3.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 | |
| 506 | Housley, et. al. Standards Track [Page 9] |
| 507 | |
| 508 | RFC 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 | |
| 562 | Housley, et. al. Standards Track [Page 10] |
| 563 | |
| 564 | RFC 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 | |
| 603 | 3.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 | |
| 618 | Housley, et. al. Standards Track [Page 11] |
| 619 | |
| 620 | RFC 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 | |
| 674 | Housley, et. al. Standards Track [Page 12] |
| 675 | |
| 676 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 677 | |
| 678 | |
| 679 | 3.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 | |
| 692 | 3.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 | |
| 730 | Housley, et. al. Standards Track [Page 13] |
| 731 | |
| 732 | RFC 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 | |
| 761 | 4 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 | |
| 786 | Housley, et. al. Standards Track [Page 14] |
| 787 | |
| 788 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 789 | |
| 790 | |
| 791 | 4.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 | |
| 842 | Housley, et. al. Standards Track [Page 15] |
| 843 | |
| 844 | RFC 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 | |
| 855 | 4.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 | |
| 860 | 4.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 | |
| 868 | 4.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 | |
| 889 | 4.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 | |
| 898 | Housley, et. al. Standards Track [Page 16] |
| 899 | |
| 900 | RFC 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 | |
| 912 | 4.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 | |
| 924 | 4.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 | |
| 941 | 4.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 | |
| 954 | Housley, et. al. Standards Track [Page 17] |
| 955 | |
| 956 | RFC 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 | |
| 968 | 4.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 | |
| 980 | 4.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 | |
| 1010 | Housley, et. al. Standards Track [Page 18] |
| 1011 | |
| 1012 | RFC 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 | |
| 1066 | Housley, et. al. Standards Track [Page 19] |
| 1067 | |
| 1068 | RFC 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 | |
| 1122 | Housley, et. al. Standards Track [Page 20] |
| 1123 | |
| 1124 | RFC 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 | |
| 1178 | Housley, et. al. Standards Track [Page 21] |
| 1179 | |
| 1180 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 1181 | |
| 1182 | |
| 1183 | 4.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 | |
| 1200 | 4.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 | |
| 1218 | 4.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 | |
| 1234 | Housley, et. al. Standards Track [Page 22] |
| 1235 | |
| 1236 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 1237 | |
| 1238 | |
| 1239 | 4.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 | |
| 1290 | Housley, et. al. Standards Track [Page 23] |
| 1291 | |
| 1292 | RFC 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 | |
| 1302 | 4.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 | |
| 1311 | 4.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 | |
| 1324 | 4.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 | |
| 1331 | 4.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 | |
| 1346 | Housley, et. al. Standards Track [Page 24] |
| 1347 | |
| 1348 | RFC 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 | |
| 1388 | 4.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 | |
| 1402 | Housley, et. al. Standards Track [Page 25] |
| 1403 | |
| 1404 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 1405 | |
| 1406 | |
| 1407 | 4.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 | |
| 1458 | Housley, et. al. Standards Track [Page 26] |
| 1459 | |
| 1460 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 1461 | |
| 1462 | |
| 1463 | 4.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 | |
| 1514 | Housley, et. al. Standards Track [Page 27] |
| 1515 | |
| 1516 | RFC 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 | |
| 1523 | 4.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 | |
| 1570 | Housley, et. al. Standards Track [Page 28] |
| 1571 | |
| 1572 | RFC 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 | |
| 1615 | 4.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 | |
| 1626 | Housley, et. al. Standards Track [Page 29] |
| 1627 | |
| 1628 | RFC 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 | |
| 1652 | 4.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 | |
| 1682 | Housley, et. al. Standards Track [Page 30] |
| 1683 | |
| 1684 | RFC 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 | |
| 1738 | Housley, et. al. Standards Track [Page 31] |
| 1739 | |
| 1740 | RFC 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 | |
| 1794 | Housley, et. al. Standards Track [Page 32] |
| 1795 | |
| 1796 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 1797 | |
| 1798 | |
| 1799 | 4.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 | |
| 1826 | 4.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 | |
| 1850 | Housley, et. al. Standards Track [Page 33] |
| 1851 | |
| 1852 | RFC 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 | |
| 1906 | Housley, et. al. Standards Track [Page 34] |
| 1907 | |
| 1908 | RFC 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 | |
| 1962 | Housley, et. al. Standards Track [Page 35] |
| 1963 | |
| 1964 | RFC 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 | |
| 1986 | 4.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 | |
| 1998 | 4.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 | |
| 2009 | 4.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 | |
| 2018 | Housley, et. al. Standards Track [Page 36] |
| 2019 | |
| 2020 | RFC 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 | |
| 2064 | 4.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 | |
| 2074 | Housley, et. al. Standards Track [Page 37] |
| 2075 | |
| 2076 | RFC 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 | |
| 2130 | Housley, et. al. Standards Track [Page 38] |
| 2131 | |
| 2132 | RFC 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 | |
| 2186 | Housley, et. al. Standards Track [Page 39] |
| 2187 | |
| 2188 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 2189 | |
| 2190 | |
| 2191 | 4.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 | |
| 2232 | 4.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 | |
| 2242 | Housley, et. al. Standards Track [Page 40] |
| 2243 | |
| 2244 | RFC 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 | |
| 2298 | Housley, et. al. Standards Track [Page 41] |
| 2299 | |
| 2300 | RFC 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 | |
| 2322 | 4.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 | |
| 2354 | Housley, et. al. Standards Track [Page 42] |
| 2355 | |
| 2356 | RFC 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 | |
| 2410 | Housley, et. al. Standards Track [Page 43] |
| 2411 | |
| 2412 | RFC 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 | |
| 2426 | 4.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 | |
| 2446 | 4.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 | |
| 2466 | Housley, et. al. Standards Track [Page 44] |
| 2467 | |
| 2468 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 2469 | |
| 2470 | |
| 2471 | 4.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 | |
| 2493 | 4.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 | |
| 2522 | Housley, et. al. Standards Track [Page 45] |
| 2523 | |
| 2524 | RFC 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 | |
| 2569 | 4.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 | |
| 2578 | Housley, et. al. Standards Track [Page 46] |
| 2579 | |
| 2580 | RFC 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 | |
| 2634 | Housley, et. al. Standards Track [Page 47] |
| 2635 | |
| 2636 | RFC 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 | |
| 2653 | 5 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 | |
| 2690 | Housley, et. al. Standards Track [Page 48] |
| 2691 | |
| 2692 | RFC 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 | |
| 2721 | 5.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 | |
| 2746 | Housley, et. al. Standards Track [Page 49] |
| 2747 | |
| 2748 | RFC 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 | |
| 2776 | 5.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 | |
| 2781 | 5.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 | |
| 2792 | 5.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 | |
| 2802 | Housley, et. al. Standards Track [Page 50] |
| 2803 | |
| 2804 | RFC 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 | |
| 2810 | 5.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 | |
| 2842 | 5.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 | |
| 2858 | Housley, et. al. Standards Track [Page 51] |
| 2859 | |
| 2860 | RFC 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 | |
| 2867 | 5.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 | |
| 2873 | 5.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 | |
| 2883 | 5.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 | |
| 2893 | 5.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 | |
| 2914 | Housley, et. al. Standards Track [Page 52] |
| 2915 | |
| 2916 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 2917 | |
| 2918 | |
| 2919 | 5.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 | |
| 2943 | 5.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 | |
| 2954 | 5.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 | |
| 2960 | 5.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 | |
| 2970 | Housley, et. al. Standards Track [Page 53] |
| 2971 | |
| 2972 | RFC 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 | |
| 2988 | 5.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 | |
| 3003 | 5.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 | |
| 3026 | Housley, et. al. Standards Track [Page 54] |
| 3027 | |
| 3028 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 3029 | |
| 3030 | |
| 3031 | 5.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 | |
| 3065 | 5.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 | |
| 3082 | Housley, et. al. Standards Track [Page 55] |
| 3083 | |
| 3084 | RFC 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 | |
| 3138 | Housley, et. al. Standards Track [Page 56] |
| 3139 | |
| 3140 | RFC 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 | |
| 3194 | Housley, et. al. Standards Track [Page 57] |
| 3195 | |
| 3196 | RFC 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 | |
| 3233 | 5.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 | |
| 3250 | Housley, et. al. Standards Track [Page 58] |
| 3251 | |
| 3252 | RFC 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 | |
| 3297 | 5.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 | |
| 3306 | Housley, et. al. Standards Track [Page 59] |
| 3307 | |
| 3308 | RFC 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 | |
| 3329 | 5.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 | |
| 3352 | 5.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 | |
| 3362 | Housley, et. al. Standards Track [Page 60] |
| 3363 | |
| 3364 | RFC 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 | |
| 3383 | 5.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 | |
| 3418 | Housley, et. al. Standards Track [Page 61] |
| 3419 | |
| 3420 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 3421 | |
| 3422 | |
| 3423 | 5.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 | |
| 3444 | 5.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 | |
| 3464 | 6 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 | |
| 3474 | Housley, et. al. Standards Track [Page 62] |
| 3475 | |
| 3476 | RFC 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 | |
| 3514 | 6.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 | |
| 3530 | Housley, et. al. Standards Track [Page 63] |
| 3531 | |
| 3532 | RFC 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 | |
| 3586 | Housley, et. al. Standards Track [Page 64] |
| 3587 | |
| 3588 | RFC 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 | |
| 3642 | Housley, et. al. Standards Track [Page 65] |
| 3643 | |
| 3644 | RFC 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 | |
| 3683 | 6.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 | |
| 3698 | Housley, et. al. Standards Track [Page 66] |
| 3699 | |
| 3700 | RFC 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 | |
| 3741 | 6.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 | |
| 3754 | Housley, et. al. Standards Track [Page 67] |
| 3755 | |
| 3756 | RFC 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 | |
| 3810 | Housley, et. al. Standards Track [Page 68] |
| 3811 | |
| 3812 | RFC 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 | |
| 3866 | Housley, et. al. Standards Track [Page 69] |
| 3867 | |
| 3868 | RFC 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 | |
| 3895 | 6.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 | |
| 3922 | Housley, et. al. Standards Track [Page 70] |
| 3923 | |
| 3924 | RFC 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 | |
| 3978 | Housley, et. al. Standards Track [Page 71] |
| 3979 | |
| 3980 | RFC 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 | |
| 4034 | Housley, et. al. Standards Track [Page 72] |
| 4035 | |
| 4036 | RFC 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 | |
| 4090 | Housley, et. al. Standards Track [Page 73] |
| 4091 | |
| 4092 | RFC 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 | |
| 4146 | Housley, et. al. Standards Track [Page 74] |
| 4147 | |
| 4148 | RFC 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 | |
| 4194 | 6.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 | |
| 4202 | Housley, et. al. Standards Track [Page 75] |
| 4203 | |
| 4204 | RFC 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 | |
| 4258 | Housley, et. al. Standards Track [Page 76] |
| 4259 | |
| 4260 | RFC 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 | |
| 4314 | Housley, et. al. Standards Track [Page 77] |
| 4315 | |
| 4316 | RFC 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 | |
| 4359 | 6.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 | |
| 4370 | Housley, et. al. Standards Track [Page 78] |
| 4371 | |
| 4372 | RFC 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 | |
| 4426 | Housley, et. al. Standards Track [Page 79] |
| 4427 | |
| 4428 | RFC 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 | |
| 4460 | 6.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 | |
| 4467 | 6.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 | |
| 4482 | Housley, et. al. Standards Track [Page 80] |
| 4483 | |
| 4484 | RFC 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 | |
| 4516 | 6.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 | |
| 4538 | Housley, et. al. Standards Track [Page 81] |
| 4539 | |
| 4540 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 4541 | |
| 4542 | |
| 4543 | 6.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 | |
| 4563 | 6.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 | |
| 4594 | Housley, et. al. Standards Track [Page 82] |
| 4595 | |
| 4596 | RFC 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 | |
| 4606 | 6.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 | |
| 4650 | Housley, et. al. Standards Track [Page 83] |
| 4651 | |
| 4652 | RFC 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 | |
| 4706 | Housley, et. al. Standards Track [Page 84] |
| 4707 | |
| 4708 | RFC 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 | |
| 4762 | Housley, et. al. Standards Track [Page 85] |
| 4763 | |
| 4764 | RFC 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 | |
| 4790 | 7 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 | |
| 4818 | Housley, et. al. Standards Track [Page 86] |
| 4819 | |
| 4820 | RFC 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 | |
| 4874 | Housley, et. al. Standards Track [Page 87] |
| 4875 | |
| 4876 | RFC 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 | |
| 4913 | 8 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 | |
| 4930 | Housley, et. al. Standards Track [Page 88] |
| 4931 | |
| 4932 | RFC 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 | |
| 4942 | 9 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 | |
| 4986 | Housley, et. al. Standards Track [Page 89] |
| 4987 | |
| 4988 | RFC 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 | |
| 5042 | Housley, et. al. Standards Track [Page 90] |
| 5043 | |
| 5044 | RFC 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 | |
| 5098 | Housley, et. al. Standards Track [Page 91] |
| 5099 | |
| 5100 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 5101 | |
| 5102 | |
| 5103 | Appendix 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 | |
| 5119 | A.1 Explicitly Tagged Module, 1988 Syntax |
| 5120 | |
| 5121 | PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) |
| 5122 | security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) } |
| 5123 | |
| 5124 | DEFINITIONS EXPLICIT TAGS ::= |
| 5125 | |
| 5126 | BEGIN |
| 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 | |
| 5135 | UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING |
| 5136 | -- UniversalString is defined in ASN.1:1993 |
| 5137 | |
| 5138 | BMPString ::= [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 | |
| 5142 | UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING |
| 5143 | -- The content of this type conforms to RFC 2279. |
| 5144 | |
| 5145 | -- PKIX specific OIDs |
| 5146 | |
| 5147 | id-pkix OBJECT IDENTIFIER ::= |
| 5148 | { iso(1) identified-organization(3) dod(6) internet(1) |
| 5149 | security(5) mechanisms(5) pkix(7) } |
| 5150 | |
| 5151 | |
| 5152 | |
| 5153 | |
| 5154 | Housley, et. al. Standards Track [Page 92] |
| 5155 | |
| 5156 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 5157 | |
| 5158 | |
| 5159 | -- PKIX arcs |
| 5160 | |
| 5161 | id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } |
| 5162 | -- arc for private certificate extensions |
| 5163 | id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } |
| 5164 | -- arc for policy qualifier types |
| 5165 | id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } |
| 5166 | -- arc for extended key purpose OIDS |
| 5167 | id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } |
| 5168 | -- arc for access descriptors |
| 5169 | |
| 5170 | -- policyQualifierIds for Internet policy qualifiers |
| 5171 | |
| 5172 | id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } |
| 5173 | -- OID for CPS qualifier |
| 5174 | id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } |
| 5175 | -- OID for user notice qualifier |
| 5176 | |
| 5177 | -- access descriptor definitions |
| 5178 | |
| 5179 | id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } |
| 5180 | id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } |
| 5181 | id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 } |
| 5182 | id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 } |
| 5183 | |
| 5184 | -- attribute data types |
| 5185 | |
| 5186 | Attribute ::= SEQUENCE { |
| 5187 | type AttributeType, |
| 5188 | values SET OF AttributeValue } |
| 5189 | -- at least one value is required |
| 5190 | |
| 5191 | AttributeType ::= OBJECT IDENTIFIER |
| 5192 | |
| 5193 | AttributeValue ::= ANY |
| 5194 | |
| 5195 | AttributeTypeAndValue ::= 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 |
| 5206 | id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 } |
| 5207 | |
| 5208 | |
| 5209 | |
| 5210 | Housley, et. al. Standards Track [Page 93] |
| 5211 | |
| 5212 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 5213 | |
| 5214 | |
| 5215 | -- Naming attributes of type X520name |
| 5216 | |
| 5217 | id-at-name AttributeType ::= { id-at 41 } |
| 5218 | id-at-surname AttributeType ::= { id-at 4 } |
| 5219 | id-at-givenName AttributeType ::= { id-at 42 } |
| 5220 | id-at-initials AttributeType ::= { id-at 43 } |
| 5221 | id-at-generationQualifier AttributeType ::= { id-at 44 } |
| 5222 | |
| 5223 | X520name ::= 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 | |
| 5232 | id-at-commonName AttributeType ::= { id-at 3 } |
| 5233 | |
| 5234 | X520CommonName ::= 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 | |
| 5243 | id-at-localityName AttributeType ::= { id-at 7 } |
| 5244 | |
| 5245 | X520LocalityName ::= 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 | |
| 5254 | id-at-stateOrProvinceName AttributeType ::= { id-at 8 } |
| 5255 | |
| 5256 | X520StateOrProvinceName ::= 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 | |
| 5266 | Housley, et. al. Standards Track [Page 94] |
| 5267 | |
| 5268 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 5269 | |
| 5270 | |
| 5271 | -- Naming attributes of type X520OrganizationName |
| 5272 | |
| 5273 | id-at-organizationName AttributeType ::= { id-at 10 } |
| 5274 | |
| 5275 | X520OrganizationName ::= 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 | |
| 5289 | id-at-organizationalUnitName AttributeType ::= { id-at 11 } |
| 5290 | |
| 5291 | X520OrganizationalUnitName ::= 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 | |
| 5305 | id-at-title AttributeType ::= { id-at 12 } |
| 5306 | |
| 5307 | X520Title ::= 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 | |
| 5316 | id-at-dnQualifier AttributeType ::= { id-at 46 } |
| 5317 | |
| 5318 | X520dnQualifier ::= PrintableString |
| 5319 | |
| 5320 | |
| 5321 | |
| 5322 | Housley, et. al. Standards Track [Page 95] |
| 5323 | |
| 5324 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 5325 | |
| 5326 | |
| 5327 | -- Naming attributes of type X520countryName (digraph from IS 3166) |
| 5328 | |
| 5329 | id-at-countryName AttributeType ::= { id-at 6 } |
| 5330 | |
| 5331 | X520countryName ::= PrintableString (SIZE (2)) |
| 5332 | |
| 5333 | -- Naming attributes of type X520SerialNumber |
| 5334 | |
| 5335 | id-at-serialNumber AttributeType ::= { id-at 5 } |
| 5336 | |
| 5337 | X520SerialNumber ::= PrintableString (SIZE (1..ub-serial-number)) |
| 5338 | |
| 5339 | -- Naming attributes of type X520Pseudonym |
| 5340 | |
| 5341 | id-at-pseudonym AttributeType ::= { id-at 65 } |
| 5342 | |
| 5343 | X520Pseudonym ::= 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 | |
| 5352 | id-domainComponent AttributeType ::= |
| 5353 | { 0 9 2342 19200300 100 1 25 } |
| 5354 | |
| 5355 | DomainComponent ::= IA5String |
| 5356 | |
| 5357 | -- Legacy attributes |
| 5358 | |
| 5359 | pkcs-9 OBJECT IDENTIFIER ::= |
| 5360 | { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 } |
| 5361 | |
| 5362 | id-emailAddress AttributeType ::= { pkcs-9 1 } |
| 5363 | |
| 5364 | EmailAddress ::= IA5String (SIZE (1..ub-emailaddress-length)) |
| 5365 | |
| 5366 | -- naming data types -- |
| 5367 | |
| 5368 | Name ::= CHOICE { -- only one possibility for now -- |
| 5369 | rdnSequence RDNSequence } |
| 5370 | |
| 5371 | RDNSequence ::= SEQUENCE OF RelativeDistinguishedName |
| 5372 | |
| 5373 | DistinguishedName ::= RDNSequence |
| 5374 | |
| 5375 | |
| 5376 | |
| 5377 | |
| 5378 | Housley, et. al. Standards Track [Page 96] |
| 5379 | |
| 5380 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 5381 | |
| 5382 | |
| 5383 | RelativeDistinguishedName ::= |
| 5384 | SET SIZE (1 .. MAX) OF AttributeTypeAndValue |
| 5385 | |
| 5386 | -- Directory string type -- |
| 5387 | |
| 5388 | DirectoryString ::= 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 | |
| 5397 | Certificate ::= SEQUENCE { |
| 5398 | tbsCertificate TBSCertificate, |
| 5399 | signatureAlgorithm AlgorithmIdentifier, |
| 5400 | signature BIT STRING } |
| 5401 | |
| 5402 | TBSCertificate ::= 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 | |
| 5417 | Version ::= INTEGER { v1(0), v2(1), v3(2) } |
| 5418 | |
| 5419 | CertificateSerialNumber ::= INTEGER |
| 5420 | |
| 5421 | Validity ::= SEQUENCE { |
| 5422 | notBefore Time, |
| 5423 | notAfter Time } |
| 5424 | |
| 5425 | Time ::= CHOICE { |
| 5426 | utcTime UTCTime, |
| 5427 | generalTime GeneralizedTime } |
| 5428 | |
| 5429 | UniqueIdentifier ::= BIT STRING |
| 5430 | |
| 5431 | |
| 5432 | |
| 5433 | |
| 5434 | Housley, et. al. Standards Track [Page 97] |
| 5435 | |
| 5436 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 5437 | |
| 5438 | |
| 5439 | SubjectPublicKeyInfo ::= SEQUENCE { |
| 5440 | algorithm AlgorithmIdentifier, |
| 5441 | subjectPublicKey BIT STRING } |
| 5442 | |
| 5443 | Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension |
| 5444 | |
| 5445 | Extension ::= SEQUENCE { |
| 5446 | extnID OBJECT IDENTIFIER, |
| 5447 | critical BOOLEAN DEFAULT FALSE, |
| 5448 | extnValue OCTET STRING } |
| 5449 | |
| 5450 | -- CRL structures |
| 5451 | |
| 5452 | CertificateList ::= SEQUENCE { |
| 5453 | tbsCertList TBSCertList, |
| 5454 | signatureAlgorithm AlgorithmIdentifier, |
| 5455 | signature BIT STRING } |
| 5456 | |
| 5457 | TBSCertList ::= 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 | |
| 5476 | AlgorithmIdentifier ::= 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 | |
| 5490 | Housley, et. al. Standards Track [Page 98] |
| 5491 | |
| 5492 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 5493 | |
| 5494 | |
| 5495 | ORAddress ::= 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 | |
| 5504 | BuiltInStandardAttributes ::= 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 | |
| 5521 | CountryName ::= [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 | |
| 5527 | AdministrationDomainName ::= [APPLICATION 2] CHOICE { |
| 5528 | numeric NumericString (SIZE (0..ub-domain-name-length)), |
| 5529 | printable PrintableString (SIZE (0..ub-domain-name-length)) } |
| 5530 | |
| 5531 | NetworkAddress ::= X121Address -- see also extended-network-address |
| 5532 | |
| 5533 | X121Address ::= NumericString (SIZE (1..ub-x121-address-length)) |
| 5534 | |
| 5535 | TerminalIdentifier ::= PrintableString (SIZE |
| 5536 | (1..ub-terminal-id-length)) |
| 5537 | |
| 5538 | PrivateDomainName ::= CHOICE { |
| 5539 | numeric NumericString (SIZE (1..ub-domain-name-length)), |
| 5540 | printable PrintableString (SIZE (1..ub-domain-name-length)) } |
| 5541 | |
| 5542 | |
| 5543 | |
| 5544 | |
| 5545 | |
| 5546 | Housley, et. al. Standards Track [Page 99] |
| 5547 | |
| 5548 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 5549 | |
| 5550 | |
| 5551 | OrganizationName ::= PrintableString |
| 5552 | (SIZE (1..ub-organization-name-length)) |
| 5553 | -- see also teletex-organization-name |
| 5554 | |
| 5555 | NumericUserIdentifier ::= NumericString |
| 5556 | (SIZE (1..ub-numeric-user-id-length)) |
| 5557 | |
| 5558 | PersonalName ::= 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 | |
| 5570 | OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units) |
| 5571 | OF OrganizationalUnitName |
| 5572 | -- see also teletex-organizational-unit-names |
| 5573 | |
| 5574 | OrganizationalUnitName ::= PrintableString (SIZE |
| 5575 | (1..ub-organizational-unit-name-length)) |
| 5576 | |
| 5577 | -- Built-in Domain-defined Attributes |
| 5578 | |
| 5579 | BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE |
| 5580 | (1..ub-domain-defined-attributes) OF |
| 5581 | BuiltInDomainDefinedAttribute |
| 5582 | |
| 5583 | BuiltInDomainDefinedAttribute ::= 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 | |
| 5591 | ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF |
| 5592 | ExtensionAttribute |
| 5593 | |
| 5594 | ExtensionAttribute ::= 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 | |
| 5602 | Housley, et. al. Standards Track [Page 100] |
| 5603 | |
| 5604 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 5605 | |
| 5606 | |
| 5607 | -- Extension types and attribute values |
| 5608 | |
| 5609 | common-name INTEGER ::= 1 |
| 5610 | |
| 5611 | CommonName ::= PrintableString (SIZE (1..ub-common-name-length)) |
| 5612 | |
| 5613 | teletex-common-name INTEGER ::= 2 |
| 5614 | |
| 5615 | TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length)) |
| 5616 | |
| 5617 | teletex-organization-name INTEGER ::= 3 |
| 5618 | |
| 5619 | TeletexOrganizationName ::= |
| 5620 | TeletexString (SIZE (1..ub-organization-name-length)) |
| 5621 | |
| 5622 | teletex-personal-name INTEGER ::= 4 |
| 5623 | |
| 5624 | TeletexPersonalName ::= 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 | |
| 5635 | teletex-organizational-unit-names INTEGER ::= 5 |
| 5636 | |
| 5637 | TeletexOrganizationalUnitNames ::= SEQUENCE SIZE |
| 5638 | (1..ub-organizational-units) OF TeletexOrganizationalUnitName |
| 5639 | |
| 5640 | TeletexOrganizationalUnitName ::= TeletexString |
| 5641 | (SIZE (1..ub-organizational-unit-name-length)) |
| 5642 | |
| 5643 | pds-name INTEGER ::= 7 |
| 5644 | |
| 5645 | PDSName ::= PrintableString (SIZE (1..ub-pds-name-length)) |
| 5646 | |
| 5647 | physical-delivery-country-name INTEGER ::= 8 |
| 5648 | |
| 5649 | PhysicalDeliveryCountryName ::= 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 | |
| 5658 | Housley, et. al. Standards Track [Page 101] |
| 5659 | |
| 5660 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 5661 | |
| 5662 | |
| 5663 | postal-code INTEGER ::= 9 |
| 5664 | |
| 5665 | PostalCode ::= CHOICE { |
| 5666 | numeric-code NumericString (SIZE (1..ub-postal-code-length)), |
| 5667 | printable-code PrintableString (SIZE (1..ub-postal-code-length)) } |
| 5668 | |
| 5669 | physical-delivery-office-name INTEGER ::= 10 |
| 5670 | |
| 5671 | PhysicalDeliveryOfficeName ::= PDSParameter |
| 5672 | |
| 5673 | physical-delivery-office-number INTEGER ::= 11 |
| 5674 | |
| 5675 | PhysicalDeliveryOfficeNumber ::= PDSParameter |
| 5676 | |
| 5677 | extension-OR-address-components INTEGER ::= 12 |
| 5678 | |
| 5679 | ExtensionORAddressComponents ::= PDSParameter |
| 5680 | |
| 5681 | physical-delivery-personal-name INTEGER ::= 13 |
| 5682 | |
| 5683 | PhysicalDeliveryPersonalName ::= PDSParameter |
| 5684 | |
| 5685 | physical-delivery-organization-name INTEGER ::= 14 |
| 5686 | |
| 5687 | PhysicalDeliveryOrganizationName ::= PDSParameter |
| 5688 | |
| 5689 | extension-physical-delivery-address-components INTEGER ::= 15 |
| 5690 | |
| 5691 | ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter |
| 5692 | |
| 5693 | unformatted-postal-address INTEGER ::= 16 |
| 5694 | |
| 5695 | UnformattedPostalAddress ::= 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 | |
| 5702 | street-address INTEGER ::= 17 |
| 5703 | |
| 5704 | StreetAddress ::= PDSParameter |
| 5705 | |
| 5706 | post-office-box-address INTEGER ::= 18 |
| 5707 | |
| 5708 | PostOfficeBoxAddress ::= PDSParameter |
| 5709 | |
| 5710 | poste-restante-address INTEGER ::= 19 |
| 5711 | |
| 5712 | |
| 5713 | |
| 5714 | Housley, et. al. Standards Track [Page 102] |
| 5715 | |
| 5716 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 5717 | |
| 5718 | |
| 5719 | PosteRestanteAddress ::= PDSParameter |
| 5720 | |
| 5721 | unique-postal-name INTEGER ::= 20 |
| 5722 | |
| 5723 | UniquePostalName ::= PDSParameter |
| 5724 | |
| 5725 | local-postal-attributes INTEGER ::= 21 |
| 5726 | |
| 5727 | LocalPostalAttributes ::= PDSParameter |
| 5728 | |
| 5729 | PDSParameter ::= 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 | |
| 5735 | extended-network-address INTEGER ::= 22 |
| 5736 | |
| 5737 | ExtendedNetworkAddress ::= 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 | |
| 5746 | PresentationAddress ::= 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 | |
| 5752 | terminal-type INTEGER ::= 23 |
| 5753 | |
| 5754 | TerminalType ::= 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 | |
| 5764 | teletex-domain-defined-attributes INTEGER ::= 6 |
| 5765 | |
| 5766 | |
| 5767 | |
| 5768 | |
| 5769 | |
| 5770 | Housley, et. al. Standards Track [Page 103] |
| 5771 | |
| 5772 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 5773 | |
| 5774 | |
| 5775 | TeletexDomainDefinedAttributes ::= SEQUENCE SIZE |
| 5776 | (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute |
| 5777 | |
| 5778 | TeletexDomainDefinedAttribute ::= 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 |
| 5789 | ub-name INTEGER ::= 32768 |
| 5790 | ub-common-name INTEGER ::= 64 |
| 5791 | ub-locality-name INTEGER ::= 128 |
| 5792 | ub-state-name INTEGER ::= 128 |
| 5793 | ub-organization-name INTEGER ::= 64 |
| 5794 | ub-organizational-unit-name INTEGER ::= 64 |
| 5795 | ub-title INTEGER ::= 64 |
| 5796 | ub-serial-number INTEGER ::= 64 |
| 5797 | ub-match INTEGER ::= 128 |
| 5798 | ub-emailaddress-length INTEGER ::= 128 |
| 5799 | ub-common-name-length INTEGER ::= 64 |
| 5800 | ub-country-name-alpha-length INTEGER ::= 2 |
| 5801 | ub-country-name-numeric-length INTEGER ::= 3 |
| 5802 | ub-domain-defined-attributes INTEGER ::= 4 |
| 5803 | ub-domain-defined-attribute-type-length INTEGER ::= 8 |
| 5804 | ub-domain-defined-attribute-value-length INTEGER ::= 128 |
| 5805 | ub-domain-name-length INTEGER ::= 16 |
| 5806 | ub-extension-attributes INTEGER ::= 256 |
| 5807 | ub-e163-4-number-length INTEGER ::= 15 |
| 5808 | ub-e163-4-sub-address-length INTEGER ::= 40 |
| 5809 | ub-generation-qualifier-length INTEGER ::= 3 |
| 5810 | ub-given-name-length INTEGER ::= 16 |
| 5811 | ub-initials-length INTEGER ::= 5 |
| 5812 | ub-integer-options INTEGER ::= 256 |
| 5813 | ub-numeric-user-id-length INTEGER ::= 32 |
| 5814 | ub-organization-name-length INTEGER ::= 64 |
| 5815 | ub-organizational-unit-name-length INTEGER ::= 32 |
| 5816 | ub-organizational-units INTEGER ::= 4 |
| 5817 | ub-pds-name-length INTEGER ::= 16 |
| 5818 | ub-pds-parameter-length INTEGER ::= 30 |
| 5819 | ub-pds-physical-address-lines INTEGER ::= 6 |
| 5820 | ub-postal-code-length INTEGER ::= 16 |
| 5821 | ub-pseudonym INTEGER ::= 128 |
| 5822 | ub-surname-length INTEGER ::= 40 |
| 5823 | |
| 5824 | |
| 5825 | |
| 5826 | Housley, et. al. Standards Track [Page 104] |
| 5827 | |
| 5828 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 5829 | |
| 5830 | |
| 5831 | ub-terminal-id-length INTEGER ::= 24 |
| 5832 | ub-unformatted-address-length INTEGER ::= 180 |
| 5833 | ub-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 | |
| 5843 | END |
| 5844 | |
| 5845 | A.2 Implicitly Tagged Module, 1988 Syntax |
| 5846 | |
| 5847 | PKIX1Implicit88 { iso(1) identified-organization(3) dod(6) internet(1) |
| 5848 | security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19) } |
| 5849 | |
| 5850 | DEFINITIONS IMPLICIT TAGS ::= |
| 5851 | |
| 5852 | BEGIN |
| 5853 | |
| 5854 | -- EXPORTS ALL -- |
| 5855 | |
| 5856 | IMPORTS |
| 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 | |
| 5869 | id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} |
| 5870 | |
| 5871 | -- authority key identifier OID and syntax |
| 5872 | |
| 5873 | id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } |
| 5874 | |
| 5875 | |
| 5876 | |
| 5877 | |
| 5878 | |
| 5879 | |
| 5880 | |
| 5881 | |
| 5882 | Housley, et. al. Standards Track [Page 105] |
| 5883 | |
| 5884 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 5885 | |
| 5886 | |
| 5887 | AuthorityKeyIdentifier ::= 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 | |
| 5894 | KeyIdentifier ::= OCTET STRING |
| 5895 | |
| 5896 | -- subject key identifier OID and syntax |
| 5897 | |
| 5898 | id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } |
| 5899 | |
| 5900 | SubjectKeyIdentifier ::= KeyIdentifier |
| 5901 | |
| 5902 | -- key usage extension OID and syntax |
| 5903 | |
| 5904 | id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } |
| 5905 | |
| 5906 | KeyUsage ::= 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 | |
| 5919 | id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } |
| 5920 | |
| 5921 | PrivateKeyUsagePeriod ::= 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 | |
| 5928 | id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } |
| 5929 | |
| 5930 | anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 } |
| 5931 | |
| 5932 | CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation |
| 5933 | |
| 5934 | PolicyInformation ::= SEQUENCE { |
| 5935 | |
| 5936 | |
| 5937 | |
| 5938 | Housley, et. al. Standards Track [Page 106] |
| 5939 | |
| 5940 | RFC 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 | |
| 5947 | CertPolicyId ::= OBJECT IDENTIFIER |
| 5948 | |
| 5949 | PolicyQualifierInfo ::= 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 | |
| 5956 | PolicyQualifierId ::= |
| 5957 | OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) |
| 5958 | |
| 5959 | -- CPS pointer qualifier |
| 5960 | |
| 5961 | CPSuri ::= IA5String |
| 5962 | |
| 5963 | -- user notice qualifier |
| 5964 | |
| 5965 | UserNotice ::= SEQUENCE { |
| 5966 | noticeRef NoticeReference OPTIONAL, |
| 5967 | explicitText DisplayText OPTIONAL} |
| 5968 | |
| 5969 | NoticeReference ::= SEQUENCE { |
| 5970 | organization DisplayText, |
| 5971 | noticeNumbers SEQUENCE OF INTEGER } |
| 5972 | |
| 5973 | DisplayText ::= 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 | |
| 5981 | id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } |
| 5982 | |
| 5983 | PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { |
| 5984 | issuerDomainPolicy CertPolicyId, |
| 5985 | subjectDomainPolicy CertPolicyId } |
| 5986 | |
| 5987 | -- subject alternative name extension OID and syntax |
| 5988 | |
| 5989 | id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } |
| 5990 | |
| 5991 | |
| 5992 | |
| 5993 | |
| 5994 | Housley, et. al. Standards Track [Page 107] |
| 5995 | |
| 5996 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 5997 | |
| 5998 | |
| 5999 | SubjectAltName ::= GeneralNames |
| 6000 | |
| 6001 | GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName |
| 6002 | |
| 6003 | GeneralName ::= 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 | |
| 6017 | AnotherName ::= SEQUENCE { |
| 6018 | type-id OBJECT IDENTIFIER, |
| 6019 | value [0] EXPLICIT ANY DEFINED BY type-id } |
| 6020 | |
| 6021 | EDIPartyName ::= SEQUENCE { |
| 6022 | nameAssigner [0] DirectoryString OPTIONAL, |
| 6023 | partyName [1] DirectoryString } |
| 6024 | |
| 6025 | -- issuer alternative name extension OID and syntax |
| 6026 | |
| 6027 | id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } |
| 6028 | |
| 6029 | IssuerAltName ::= GeneralNames |
| 6030 | |
| 6031 | id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } |
| 6032 | |
| 6033 | SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute |
| 6034 | |
| 6035 | -- basic constraints extension OID and syntax |
| 6036 | |
| 6037 | id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } |
| 6038 | |
| 6039 | BasicConstraints ::= SEQUENCE { |
| 6040 | cA BOOLEAN DEFAULT FALSE, |
| 6041 | pathLenConstraint INTEGER (0..MAX) OPTIONAL } |
| 6042 | |
| 6043 | -- name constraints extension OID and syntax |
| 6044 | |
| 6045 | id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } |
| 6046 | |
| 6047 | |
| 6048 | |
| 6049 | |
| 6050 | Housley, et. al. Standards Track [Page 108] |
| 6051 | |
| 6052 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 6053 | |
| 6054 | |
| 6055 | NameConstraints ::= SEQUENCE { |
| 6056 | permittedSubtrees [0] GeneralSubtrees OPTIONAL, |
| 6057 | excludedSubtrees [1] GeneralSubtrees OPTIONAL } |
| 6058 | |
| 6059 | GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree |
| 6060 | |
| 6061 | GeneralSubtree ::= SEQUENCE { |
| 6062 | base GeneralName, |
| 6063 | minimum [0] BaseDistance DEFAULT 0, |
| 6064 | maximum [1] BaseDistance OPTIONAL } |
| 6065 | |
| 6066 | BaseDistance ::= INTEGER (0..MAX) |
| 6067 | |
| 6068 | -- policy constraints extension OID and syntax |
| 6069 | |
| 6070 | id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } |
| 6071 | |
| 6072 | PolicyConstraints ::= SEQUENCE { |
| 6073 | requireExplicitPolicy [0] SkipCerts OPTIONAL, |
| 6074 | inhibitPolicyMapping [1] SkipCerts OPTIONAL } |
| 6075 | |
| 6076 | SkipCerts ::= INTEGER (0..MAX) |
| 6077 | |
| 6078 | -- CRL distribution points extension OID and syntax |
| 6079 | |
| 6080 | id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31} |
| 6081 | |
| 6082 | CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint |
| 6083 | |
| 6084 | DistributionPoint ::= SEQUENCE { |
| 6085 | distributionPoint [0] DistributionPointName OPTIONAL, |
| 6086 | reasons [1] ReasonFlags OPTIONAL, |
| 6087 | cRLIssuer [2] GeneralNames OPTIONAL } |
| 6088 | |
| 6089 | DistributionPointName ::= CHOICE { |
| 6090 | fullName [0] GeneralNames, |
| 6091 | nameRelativeToCRLIssuer [1] RelativeDistinguishedName } |
| 6092 | |
| 6093 | ReasonFlags ::= 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 | |
| 6106 | Housley, et. al. Standards Track [Page 109] |
| 6107 | |
| 6108 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 6109 | |
| 6110 | |
| 6111 | -- extended key usage extension OID and syntax |
| 6112 | |
| 6113 | id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} |
| 6114 | |
| 6115 | ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId |
| 6116 | |
| 6117 | |
| 6118 | KeyPurposeId ::= OBJECT IDENTIFIER |
| 6119 | |
| 6120 | -- permit unspecified key uses |
| 6121 | |
| 6122 | anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 } |
| 6123 | |
| 6124 | -- extended key purpose OIDs |
| 6125 | |
| 6126 | id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } |
| 6127 | id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } |
| 6128 | id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } |
| 6129 | id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } |
| 6130 | id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } |
| 6131 | id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 } |
| 6132 | |
| 6133 | -- inhibit any policy OID and syntax |
| 6134 | |
| 6135 | id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 } |
| 6136 | |
| 6137 | InhibitAnyPolicy ::= SkipCerts |
| 6138 | |
| 6139 | -- freshest (delta)CRL extension OID and syntax |
| 6140 | |
| 6141 | id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } |
| 6142 | |
| 6143 | FreshestCRL ::= CRLDistributionPoints |
| 6144 | |
| 6145 | -- authority info access |
| 6146 | |
| 6147 | id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } |
| 6148 | |
| 6149 | AuthorityInfoAccessSyntax ::= |
| 6150 | SEQUENCE SIZE (1..MAX) OF AccessDescription |
| 6151 | |
| 6152 | AccessDescription ::= SEQUENCE { |
| 6153 | accessMethod OBJECT IDENTIFIER, |
| 6154 | accessLocation GeneralName } |
| 6155 | |
| 6156 | -- subject info access |
| 6157 | |
| 6158 | id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 } |
| 6159 | |
| 6160 | |
| 6161 | |
| 6162 | Housley, et. al. Standards Track [Page 110] |
| 6163 | |
| 6164 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 6165 | |
| 6166 | |
| 6167 | SubjectInfoAccessSyntax ::= |
| 6168 | SEQUENCE SIZE (1..MAX) OF AccessDescription |
| 6169 | |
| 6170 | -- CRL number extension OID and syntax |
| 6171 | |
| 6172 | id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } |
| 6173 | |
| 6174 | CRLNumber ::= INTEGER (0..MAX) |
| 6175 | |
| 6176 | -- issuing distribution point extension OID and syntax |
| 6177 | |
| 6178 | id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } |
| 6179 | |
| 6180 | IssuingDistributionPoint ::= 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 | |
| 6188 | id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } |
| 6189 | |
| 6190 | BaseCRLNumber ::= CRLNumber |
| 6191 | |
| 6192 | -- CRL reasons extension OID and syntax |
| 6193 | |
| 6194 | id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 } |
| 6195 | |
| 6196 | CRLReason ::= 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 | |
| 6210 | id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } |
| 6211 | |
| 6212 | CertificateIssuer ::= GeneralNames |
| 6213 | |
| 6214 | -- hold instruction extension OID and syntax |
| 6215 | |
| 6216 | |
| 6217 | |
| 6218 | Housley, et. al. Standards Track [Page 111] |
| 6219 | |
| 6220 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 6221 | |
| 6222 | |
| 6223 | id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } |
| 6224 | |
| 6225 | HoldInstructionCode ::= OBJECT IDENTIFIER |
| 6226 | |
| 6227 | -- ANSI x9 holdinstructions |
| 6228 | |
| 6229 | -- ANSI x9 arc holdinstruction arc |
| 6230 | |
| 6231 | holdInstruction 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 | |
| 6236 | id-holdinstruction-none OBJECT IDENTIFIER ::= |
| 6237 | {holdInstruction 1} -- deprecated |
| 6238 | |
| 6239 | id-holdinstruction-callissuer OBJECT IDENTIFIER ::= |
| 6240 | {holdInstruction 2} |
| 6241 | |
| 6242 | id-holdinstruction-reject OBJECT IDENTIFIER ::= |
| 6243 | {holdInstruction 3} |
| 6244 | |
| 6245 | -- invalidity date CRL entry extension OID and syntax |
| 6246 | |
| 6247 | id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } |
| 6248 | |
| 6249 | InvalidityDate ::= GeneralizedTime |
| 6250 | |
| 6251 | END |
| 6252 | |
| 6253 | Appendix 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 | |
| 6274 | Housley, et. al. Standards Track [Page 112] |
| 6275 | |
| 6276 | RFC 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 | |
| 6330 | Housley, et. al. Standards Track [Page 113] |
| 6331 | |
| 6332 | RFC 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 | |
| 6386 | Housley, et. al. Standards Track [Page 114] |
| 6387 | |
| 6388 | RFC 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 | |
| 6403 | Appendix 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 | |
| 6434 | C.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 | |
| 6442 | Housley, et. al. Standards Track [Page 115] |
| 6443 | |
| 6444 | RFC 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 | : } |
| 6493 | 103 30 42: SEQUENCE { |
| 6494 | 105 31 11: SET { |
| 6495 | |
| 6496 | |
| 6497 | |
| 6498 | Housley, et. al. Standards Track [Page 116] |
| 6499 | |
| 6500 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 6501 | |
| 6502 | |
| 6503 | 107 30 9: SEQUENCE { |
| 6504 | 109 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) |
| 6505 | 114 13 2: PrintableString 'US' |
| 6506 | : } |
| 6507 | : } |
| 6508 | 118 31 12: SET { |
| 6509 | 120 30 10: SEQUENCE { |
| 6510 | 122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) |
| 6511 | 127 13 3: PrintableString 'gov' |
| 6512 | : } |
| 6513 | : } |
| 6514 | 132 31 13: SET { |
| 6515 | 134 30 11: SEQUENCE { |
| 6516 | 136 06 3: OBJECT IDENTIFIER |
| 6517 | : organizationalUnitName (2 5 4 11) |
| 6518 | 141 13 4: PrintableString 'NIST' |
| 6519 | : } |
| 6520 | : } |
| 6521 | : } |
| 6522 | 147 30 440: SEQUENCE { |
| 6523 | 151 30 300: SEQUENCE { |
| 6524 | 155 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) |
| 6525 | 164 30 287: SEQUENCE { |
| 6526 | 168 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 |
| 6537 | 300 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 |
| 6540 | 323 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 | |
| 6554 | Housley, et. al. Standards Track [Page 117] |
| 6555 | |
| 6556 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 6557 | |
| 6558 | |
| 6559 | : } |
| 6560 | : } |
| 6561 | 455 03 133: BIT STRING 0 unused bits, encapsulates { |
| 6562 | 459 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 | : } |
| 6575 | 591 A3 50: [3] { |
| 6576 | 593 30 48: SEQUENCE { |
| 6577 | 595 30 29: SEQUENCE { |
| 6578 | 597 06 3: OBJECT IDENTIFIER |
| 6579 | : subjectKeyIdentifier (2 5 29 14) |
| 6580 | 602 04 22: OCTET STRING, encapsulates { |
| 6581 | 604 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 | : } |
| 6586 | 626 30 15: SEQUENCE { |
| 6587 | 628 06 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19) |
| 6588 | 633 01 1: BOOLEAN TRUE |
| 6589 | 636 04 5: OCTET STRING, encapsulates { |
| 6590 | 638 30 3: SEQUENCE { |
| 6591 | 640 01 1: BOOLEAN TRUE |
| 6592 | : } |
| 6593 | : } |
| 6594 | : } |
| 6595 | : } |
| 6596 | : } |
| 6597 | : } |
| 6598 | 643 30 9: SEQUENCE { |
| 6599 | 645 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) |
| 6600 | : } |
| 6601 | 654 03 47: BIT STRING 0 unused bits, encapsulates { |
| 6602 | 657 30 44: SEQUENCE { |
| 6603 | 659 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 |
| 6606 | 681 02 20: INTEGER |
| 6607 | |
| 6608 | |
| 6609 | |
| 6610 | Housley, et. al. Standards Track [Page 118] |
| 6611 | |
| 6612 | RFC 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 | |
| 6621 | C.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 | |
| 6666 | Housley, et. al. Standards Track [Page 119] |
| 6667 | |
| 6668 | RFC 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 | |
| 6722 | Housley, et. al. Standards Track [Page 120] |
| 6723 | |
| 6724 | RFC 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 | |
| 6778 | Housley, et. al. Standards Track [Page 121] |
| 6779 | |
| 6780 | RFC 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 | |
| 6810 | C.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 | |
| 6834 | Housley, et. al. Standards Track [Page 122] |
| 6835 | |
| 6836 | RFC 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 | : } |
| 6879 | 108 30 61: SEQUENCE { |
| 6880 | 110 31 11: SET { |
| 6881 | 112 30 9: SEQUENCE { |
| 6882 | 114 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) |
| 6883 | 119 13 2: PrintableString 'US' |
| 6884 | : } |
| 6885 | : } |
| 6886 | 123 31 12: SET { |
| 6887 | |
| 6888 | |
| 6889 | |
| 6890 | Housley, et. al. Standards Track [Page 123] |
| 6891 | |
| 6892 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 6893 | |
| 6894 | |
| 6895 | 125 30 10: SEQUENCE { |
| 6896 | 127 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) |
| 6897 | 132 13 3: PrintableString 'gov' |
| 6898 | : } |
| 6899 | : } |
| 6900 | 137 31 13: SET { |
| 6901 | 139 30 11: SEQUENCE { |
| 6902 | 141 06 3: OBJECT IDENTIFIER |
| 6903 | : organizationalUnitName (2 5 4 11) |
| 6904 | 146 13 4: PrintableString 'NIST' |
| 6905 | : } |
| 6906 | : } |
| 6907 | 152 31 17: SET { |
| 6908 | 154 30 15: SEQUENCE { |
| 6909 | 156 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) |
| 6910 | 161 13 8: PrintableString 'Tim Polk' |
| 6911 | : } |
| 6912 | : } |
| 6913 | : } |
| 6914 | 171 30 159: SEQUENCE { |
| 6915 | 174 30 13: SEQUENCE { |
| 6916 | 176 06 9: OBJECT IDENTIFIER |
| 6917 | : rsaEncryption (1 2 840 113549 1 1 1) |
| 6918 | 187 05 0: NULL |
| 6919 | : } |
| 6920 | 189 03 141: BIT STRING 0 unused bits, encapsulates { |
| 6921 | 193 30 137: SEQUENCE { |
| 6922 | 196 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 |
| 6933 | 328 02 3: INTEGER 65537 |
| 6934 | : } |
| 6935 | : } |
| 6936 | : } |
| 6937 | 333 A3 175: [3] { |
| 6938 | 336 30 172: SEQUENCE { |
| 6939 | 339 30 63: SEQUENCE { |
| 6940 | 341 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) |
| 6941 | 346 04 56: OCTET STRING, encapsulates { |
| 6942 | 348 30 54: SEQUENCE { |
| 6943 | |
| 6944 | |
| 6945 | |
| 6946 | Housley, et. al. Standards Track [Page 124] |
| 6947 | |
| 6948 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 6949 | |
| 6950 | |
| 6951 | 350 86 52: [6] |
| 6952 | : 'http://www.itl.nist.gov/div893/staff/' |
| 6953 | : 'polk/index.html' |
| 6954 | : } |
| 6955 | : } |
| 6956 | : } |
| 6957 | 404 30 31: SEQUENCE { |
| 6958 | 406 06 3: OBJECT IDENTIFIER issuerAltName (2 5 29 18) |
| 6959 | 411 04 24: OCTET STRING, encapsulates { |
| 6960 | 413 30 22: SEQUENCE { |
| 6961 | 415 86 20: [6] 'http://www.nist.gov/' |
| 6962 | : } |
| 6963 | : } |
| 6964 | : } |
| 6965 | 437 30 31: SEQUENCE { |
| 6966 | 439 06 3: OBJECT IDENTIFIER |
| 6967 | : authorityKeyIdentifier (2 5 29 35) |
| 6968 | 444 04 24: OCTET STRING, encapsulates { |
| 6969 | 446 30 22: SEQUENCE { |
| 6970 | 448 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 | : } |
| 6976 | 470 30 23: SEQUENCE { |
| 6977 | 472 06 3: OBJECT IDENTIFIER |
| 6978 | : certificatePolicies (2 5 29 32) |
| 6979 | 477 04 16: OCTET STRING, encapsulates { |
| 6980 | 479 30 14: SEQUENCE { |
| 6981 | 481 30 12: SEQUENCE { |
| 6982 | 483 06 10: OBJECT IDENTIFIER |
| 6983 | : '2 16 840 1 101 3 2 1 48 9' |
| 6984 | : } |
| 6985 | : } |
| 6986 | : } |
| 6987 | : } |
| 6988 | 495 30 14: SEQUENCE { |
| 6989 | 497 06 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) |
| 6990 | 502 01 1: BOOLEAN TRUE |
| 6991 | 505 04 4: OCTET STRING, encapsulates { |
| 6992 | 507 03 2: BIT STRING 7 unused bits |
| 6993 | : '1'B (bit 0) |
| 6994 | : } |
| 6995 | : } |
| 6996 | : } |
| 6997 | : } |
| 6998 | : } |
| 6999 | |
| 7000 | |
| 7001 | |
| 7002 | Housley, et. al. Standards Track [Page 125] |
| 7003 | |
| 7004 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 7005 | |
| 7006 | |
| 7007 | 511 30 13: SEQUENCE { |
| 7008 | 513 06 9: OBJECT IDENTIFIER |
| 7009 | : sha1withRSAEncryption (1 2 840 113549 1 1 5) |
| 7010 | 524 05 0: NULL |
| 7011 | : } |
| 7012 | 526 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 | |
| 7025 | C.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 | |
| 7058 | Housley, et. al. Standards Track [Page 126] |
| 7059 | |
| 7060 | RFC 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 |
| 7074 | 101 17 13: UTCTime '970731000000Z' |
| 7075 | 116 30 12: SEQUENCE { |
| 7076 | 118 30 10: SEQUENCE { |
| 7077 | 120 06 3: OBJECT IDENTIFIER cRLReason (2 5 29 21) |
| 7078 | 125 04 3: OCTET STRING, encapsulates { |
| 7079 | 127 0A 1: ENUMERATED 1 |
| 7080 | : } |
| 7081 | : } |
| 7082 | : } |
| 7083 | : } |
| 7084 | : } |
| 7085 | 130 A0 14: [0] { |
| 7086 | 132 30 12: SEQUENCE { |
| 7087 | 134 30 10: SEQUENCE { |
| 7088 | 136 06 3: OBJECT IDENTIFIER cRLNumber (2 5 29 20) |
| 7089 | 141 04 3: OCTET STRING, encapsulates { |
| 7090 | 143 02 1: INTEGER 12 |
| 7091 | : } |
| 7092 | : } |
| 7093 | : } |
| 7094 | : } |
| 7095 | : } |
| 7096 | 146 30 9: SEQUENCE { |
| 7097 | 148 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) |
| 7098 | : } |
| 7099 | 157 03 47: BIT STRING 0 unused bits, encapsulates { |
| 7100 | 160 30 44: SEQUENCE { |
| 7101 | 162 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 |
| 7104 | 184 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 | |
| 7114 | Housley, et. al. Standards Track [Page 127] |
| 7115 | |
| 7116 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 7117 | |
| 7118 | |
| 7119 | Author 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 | |
| 7170 | Housley, et. al. Standards Track [Page 128] |
| 7171 | |
| 7172 | RFC 3280 Internet X.509 Public Key Infrastructure April 2002 |
| 7173 | |
| 7174 | |
| 7175 | Full 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 | |
| 7203 | Acknowledgement |
| 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 | |
| 7226 | Housley, et. al. Standards Track [Page 129] |
| 7227 | |