idnits 2.17.1 draft-ietf-pkix-ipki-part1-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 60 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 61 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 34 instances of too long lines in the document, the longest one being 10 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 532: '... issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,...' RFC 2119 keyword, line 534: '... subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,...' RFC 2119 keyword, line 536: '... extensions [3] Extensions OPTIONAL...' RFC 2119 keyword, line 814: '... keyIdentifier [0] KeyIdentifier OPTIONAL,...' RFC 2119 keyword, line 815: '... authorityCertIssuer [1] GeneralNames OPTIONAL,...' (58 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 155 has weird spacing: '...ate the certi...' == Line 304 has weird spacing: '...ication path ...' == Line 442 has weird spacing: '...issuing a cer...' == Line 453 has weird spacing: '...: This is th...' == Line 2112 has weird spacing: '...cKey is the v...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 1996) is 9993 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 2577 -- Looks like a reference, but probably isn't: '1' on line 2578 -- Looks like a reference, but probably isn't: '2' on line 2579 -- Looks like a reference, but probably isn't: '3' on line 2580 -- Looks like a reference, but probably isn't: '4' on line 2581 -- Looks like a reference, but probably isn't: '5' on line 2409 -- Looks like a reference, but probably isn't: '6' on line 2410 -- Looks like a reference, but probably isn't: '7' on line 2411 -- Looks like a reference, but probably isn't: '8' on line 2412 == Missing Reference: 'OIW' is mentioned on line 2016, but not defined == Unused Reference: 'RFC 1423' is defined on line 2712, but no explicit reference was found in the text == Unused Reference: 'RFC 1959' is defined on line 2716, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS 180-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS 186' -- Possible downref: Non-RFC (?) normative reference: ref. 'RC95' ** Obsolete normative reference: RFC 1319 (Obsoleted by RFC 6149) ** Downref: Normative reference to an Historic RFC: RFC 1422 ** Downref: Normative reference to an Historic RFC: RFC 1423 ** Obsolete normative reference: RFC 1959 (Obsoleted by RFC 2255) Summary: 16 errors (**), 0 flaws (~~), 13 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group R. Housley (SPYRUS) 3 Internet Draft W. Ford (Verisign) 4 W. Polk (NIST) 5 D. Solo (BBN) 6 expires in six months December 1996 8 Internet Public Key Infrastructure 10 Part I: X.509 Certificate and CRL Profile 12 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 To learn the current status of any Internet-Draft, please check the 27 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 28 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au Pacific Rim), ds.internic.net (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 Abstract 34 This is the second draft of the Internet Public Key Infrastructure 35 X.509 Certificate and CRL Profile. Since the first version was 36 distributed, ISO has completed work on X.509 Version 3 Certificates 37 and X.509 Version 2 Certificate Revocation Lists (CRLs). Many of the 38 Internet community requirements that were in the previous version of 39 this document have been included in the final ISO document. As a 40 result, this document has gotten simpler. Please send comments on 41 this document to the ietf-pkix@tandem.com mail list. 43 1 Executive Summary 45 This specification is Part 1 of a four part standard for development 46 of a Public Key Infrastructure for the Internet. This specification 47 is a standalone document; implementations of this standard may 48 proceed before completion of parts two through four. 50 This specification profiles the format and semantics of certificates 51 and certificate revocation lists for the Internet PKI. Procedures 52 are described for processing of certification paths in the Internet 53 environment. Encoding rules are provided for popular cryptographic 54 algorithms. Finally, a comprehensive ASN.1 module is provided in the 55 appendices for all data structure defined or referenced. 57 The specification presents profiles of the X.509 version 3 58 certificate and version 2 certificate revocation lists. The profiles 59 include the identification of ISO and ANSI extensions which may be 60 useful in the Internet PKI and definition of new extensions to meet 61 the Internet's requirements. The profiles are presented in the 1988 62 Abstract Syntax Notation One (ASN.1) rather than the 1993 syntax used 63 in the ISO standards. 65 This specification also includes path validation procedures. These 66 procedures are based upon the ISO definition, but incorporate the 67 Internet defined extensions. Implementations are required to derive 68 the same results but are not required to use the specified 69 procedures. 71 Finally, the specification describes procedures for identification 72 and encoding of public key materials and digital signatures. 73 Implementations are not required to use any particular cryptographic 74 algorithms. However, conforming implementations which use the 75 identified algorithms are required to identify and encode the public 76 key materials and digital signatures as described. 78 An Appendix is provided containing all ASN.1 structures defined or 79 referenced within this specification. As above, the material is 80 presented in the 1988 Abstract Syntax Notation One (ASN.1) rather 81 than the 1993 syntax. 83 2 Requirements and Assumptions 85 Goal is to develop a profile and associated management structure to 86 facilitate the adoption/use of X.509 certificates within Internet 87 applications for those communities wishing to make use of X.509 88 technology. Such applications may include WWW, electronic mail, user 89 authentication, and IPSEC, as well as others. In order to relieve 90 some of the obstacles to using X.509 certificates, this document 91 defines a profile to promote the development of certificate 92 management systems; development of application tools; and 93 interoperability determined by policy, as opposed to syntax. 95 Some communities will need to supplement, or possibly replace, this 96 profile in order to meet the requirements of specialized application 97 domains or environments with additional authorization, assurance, or 98 operational requirements. However, for basic applications, common 99 representations of frequently used attributes are defined so that 100 application developers can obtain necessary information without 101 regard to the issuer of a particular certificate or certificate 102 revocation list (CRL). 104 As supplemental authorization and attribute management tools emerge, 105 such as attribute certificates, it may be appropriate to limit the 106 authenticated attributes that are included in a certificate. These 107 other management tools may be more appropriate method of conveying 108 many authenticated attributes. 110 2.1 Communication and Topology 112 The users of certificates will operate in a wide range of 113 environments with respect to their communication topology, especially 114 users of secure electronic mail. This profile supports users without 115 high bandwidth, real-time IP connectivity, or high connection 116 availablity. In addition, the profile allows for the presence of 117 firewall or other filtered communication. 119 This profile does not assume the deployment of an X.500 Directory 120 system. The profile does not prohibit the use of an X.500 Directory, 121 but other means of distributing certificates and certificate 122 revocation lists (CRLs) are supported. 124 2.2 Acceptability Criteria 126 The goal of the Internet Public Key Infrastructure (PKI) is to meet 127 the needs of deterministic, automated identification, authentication, 128 access control, and authorization functions. Support for these 129 services determines the attributes contained in the certificate as 130 well as the ancillary control information in the certificate such as 131 policy data and certification path constraints. 133 2.3 User Expectations 135 Users of the Internet PKI are people and processes who use client 136 software and are the subjects named in certificates. These uses 137 include readers and writers of electronic mail, the clients for WWW 138 browsers, WWW servers, and the key manager for IPSEC within a router. 140 This profile recognizes the limitations of the platforms these users 141 employ and the sophistication/attentiveness of the users themselves. 142 This manifests itself in minimal user configuration responsibility 143 (e.g., root keys, rules), explicit platform usage constraints within 144 the certificate, certification path constraints which shield the user 145 from many malicious actions, and applications which sensibly automate 146 validation functions. 148 2.4 Administrator Expectations 150 As with users, the Internet PKI profile is structured to support the 151 individuals who generally operate Certification Authorities (CAs). 152 Providing administrators with unbounded choices increases the chances 153 that a subtle CA administrator mistake will result in broad 154 compromise. Also, unbounded choices greatly complicates the software 155 that must process and validate the certificates created by the CA. 157 3 Overview of Approach 159 Following is a simplified view of the architectural model assumed by 160 the PKIX specifications. 162 +---+ 163 | C | +------------+ 164 | e | <-------------------->| End entity | 165 | r | Operational +------------+ 166 | t | transactions ^ 167 | | and management | Management 168 | / | transactions | transactions 169 | | | 170 | C | PKI users v 171 | R | -------+-------+--------+------ 172 | L | PKI management ^ ^ 173 | | entities | | 174 | | v | 175 | R | +------+ | 176 | e | <-------------- | RA | <-----+ | 177 | p | certificate | | | | 178 | o | publish +------+ | | 179 | s | | | 180 | I | v v 181 | t | +------------+ 182 | o | <--------------------------| CA | 183 | r | certificate publish +------------+ 184 | y | CRL publish ^ 185 | | | 186 +---+ | Management 187 | transactions 188 v 189 +------+ 190 | CA | 191 +------+ 193 Figure 1 - PKI Entities 195 The components in this model are: 197 end entity: user of PKI certificates and/or end user system that 198 the PKI certifies; 199 CA: certification authority; 200 RA: registration authority, i.e., an optional system to 201 which a CA delegates certain management functions; 202 repository: a system or collection of distributed systems that 203 store certificates and CRLs and serves as a means of 204 distributing these certificates and CRLs to end 205 entities. 207 3.1 X.509 Version 3 Certificate 209 Application of public key technology requires the user of a public 210 key to be confident that the public key belongs to the correct remote 211 subject (person or system) with which an encryption or digital 212 signature mechanism will be used. This confidence is obtained 213 through the use of public key certificates, which are data structures 214 that bind public key values to subject identities. The binding is 215 achieved by having a trusted certification authority (CA) digitally 216 sign each certificate. A certificate has a limited valid lifetime 217 which is indicated in its signed contents. Because a certificate's 218 signature and timeliness can be independently checked by a 219 certificate-using client, certificates can be distributed via 220 untrusted communications and server systems, and can be cached in 221 unsecured storage in certificate-using systems. 223 The standard known as ITU-T X.509 (formerly CCITT X.509) or ISO/IEC 224 9594-8, which was first published in 1988 as part of the X.500 225 Directory recommendations, defines a standard certificate format. The 226 certificate format in the 1988 standard is called the version 1 (v1) 227 format. When X.500 was revised in 1993, two more fields were added, 228 resulting in the version 2 (v2) format. These two fields are used to 229 support directory access control. 231 The Internet Privacy Enhanced Mail (PEM) proposals, published in 232 1993, include specifications for a public key infrastructure based on 233 X.509 v1 certificates [RFC 1422]. The experience gained in attempts 234 to deploy RFC 1422 made it clear that the v1 and v2 certificate 235 formats are deficient in several respects. Most importantly, more 236 fields were needed to carry information which PEM design and 237 implementation experience has proven necessary. In response to these 238 new requirements, ISO/IEC and ANSI X9 developed the X.509 version 3 239 (v3) certificate format. The v3 format extends the v2 format by 240 adding provision for additional extension fields. Particular 241 extension field types may be specified in standards or may be defined 242 and registered by any organization or community. In June 1996, 243 standardization of the basic v3 format was completed [X.509-AM]. 245 ISO/IEC and ANSI X9 have also developed a set of standard extensions 246 for use in the v3 extensions field [X.509-AM][X9.55]. These 247 extensions can convey such data as additional subject identification 248 information, key attribute information, policy information, and 249 certification path constraints. 251 However, the ISO/IEC and ANSI standard extensions are very broad in 252 their applicability. In order to develop interoperable 253 implementations of X.509 v3 systems for Internet use, it is necessary 254 to specify a profile for use of the X.509 v3 extensions tailored for 255 the Internet. It is one goal of this document to specify a profile 256 for Internet WWW, electronic mail, and IPSEC applications. 257 Environments with additional requirements may build on this profile 258 or may replace it. 260 3.2 Certification Paths and Trust 262 A user of a security service requiring knowledge of a public key 263 generally needs to obtain and validate a certificate containing the 264 required public key. If the public-key user does not already hold an 265 assured copy of the public key of the CA that signed the certificate, 266 then it might need an additional certificate to obtain that public 267 key. In general, a chain of multiple certificates may be needed, 268 comprising a certificate of the public key owner (the end entity) 269 signed by one CA, and zero or more additional certificates of CAs 270 signed by other CAs. Such chains, called certification paths, are 271 required because a public key user is only initialized with a limited 272 number (often one) of assured CA public keys. 274 There are different ways in which CAs might be configured in order 275 for public key users to be able to find certification paths. For 276 PEM, RFC 1422 defined a rigid hierarchical structure of CAs. There 277 are three types of PEM certification authority: 279 (a) Internet Policy Registration Authority (IPRA): This authority, 280 operated under the auspices of the Internet Society, acts as the root 281 of the PEM certification hierarchy at level 1. It issues 282 certificates only for the next level of authorities, PCAs. All 283 certification paths start with the IPRA. 285 (b) Policy Certification Authorities (PCAs): PCAs are at level 2 of 286 the hierarchy, each PCA being certified by the IPRA. A PCA must 287 establish and publish a statement of its policy with respect to 288 certifying users or subordinate certification authorities. Distinct 289 PCAs aim to satisfy different user needs. For example, one PCA (an 290 organizational PCA) might support the general electronic mail needs 291 of commercial organizations, and another PCA (a high-assurance PCA) 292 might have a more stringent policy designed for satisfying legally 293 binding signature requirements. 295 (c) Certification Authorities (CAs): CAs are at level 3 of the 296 hierarchy and can also be at lower levels. Those at level 3 are 297 certified by PCAs. CAs represent, for example, particular 298 organizations, particular organizational units (e.g., departments, 299 groups, sections), or particular geographical areas. 301 RFC 1422 furthermore has a name subordination rule which requires 302 that a CA can only issue certificates for entities whose names are 303 subordinate (in the X.500 naming tree) to the name of the CA itself. 304 The trust associated with a PEM certification path is implied by the 305 PCA name. The name subordination rule ensures that CAs below the PCA 306 are sensibly constrained as to the set of subordinate entities they 307 can certify (e.g., a CA for an organization can only certify entities 308 in that organization's name tree). Certificate user systems are able 309 to mechanically check that the name subordination rule has been 310 followed. 312 The RFC 1422 CA hierarchical model has been found to have several 313 deficiencies, including: 315 (a) The pure top-down hierarchy, with all certification paths 316 starting from the root, is too restrictive for many purposes. For 317 some applications, verification of certification paths should start 318 with a public key of a CA in a user's own domain, rather than 319 mandating that verification commence at the top of a hierarchy. In 320 many environments, the local domain is often the most trusted. Also, 321 initialization and key-pair-update operations can be more effectively 322 conducted between an end entity and a local management system. 324 (b) The name subordination rule introduces undesirable constraints 325 upon the X.500 naming system an organization may use. 327 (c) Use of the PCA concept requires knowledge of individual PCAs to 328 be built into certificate chain verification logic. In the 329 particular case of Internet mail, this is not a major problem -- the 330 PCA name can always be displayed to the human user who can make a 331 decision as to what trust to imply from a particular chain. However, 332 in many commercial applications, such as electronic commerce or EDI, 333 operator intervention to make policy decisions is impractical. The 334 process needs to be automated to a much higher degree. In fact, the 335 full process of certificate chain processing needs to be 336 implementable in trusted software. 338 Because of the above shortcomings, it is proposed that more flexible 339 CA structures than the RFC 1422 hierarchy be supported by the PKIX 340 specifications. In fact, the main reason for the structural 341 restrictions imposed by RFC 1422 was the restricted certificate 342 format provided with X.509 v1. With X.509 v3, most of the 343 requirements addressed by RFC 1422 can be addressed using certificate 344 extensions, without a need to restrict the CA structures used. In 345 particular, the certificate extensions relating to certificate 346 policies obviate the need for PCAs and the constraint extensions 347 obviate the need for the name subordination rule. 349 3.3 Revocation 351 When a certificate is issued, it is expected to be in use for its 352 entire validity period. However, various circumstances may cause a 353 certificate to become invalid prior to the expiration of the validity 354 period. Such circumstances might include change of name, change of 355 association between subject and CA (e.g., an employee terminates 356 employment with an organization), and compromise or suspected 357 compromise of the corresponding private key. Under such 358 circumstances, the CA needs to revoke the certificate. 360 X.509 defines one method of certificate revocation. This method 361 involves each CA periodically issuing a signed data structure called 362 a certificate revocation list (CRL). A CRL is a time stamped list 363 identifying revoked certificates which is signed by a CA and made 364 freely available in a public repository. Each revoked certificate is 365 identified in a CRL by its certificate serial number. When a 366 certificate-using system uses a certificate (e.g., for verifying a 367 remote user's digital signature), that system not only checks the 368 certificate signature and validity but also acquires a suitably- 369 recent CRL and checks that the certificate serial number is not on 370 that CRL. The meaning of "suitably-recent" may vary with local 371 policy, but it usually means the most recently-issued CRL. A CA 372 issues a new CRL on a regular periodic basis (e.g., hourly, daily, or 373 weekly). Entries are added to CRLs as revocations occur, and an 374 entry may be removed when the certificate expiration date is reached. 376 An advantage of this revocation method is that CRLs may be 377 distributed by exactly the same means as certificates themselves, 378 namely, via untrusted communications and server systems. 380 One limitation of the CRL revocation method, using untrusted 381 communications and servers, is that the time granularity of 382 revocation is limited to the CRL issue period. For example, if a 383 revocation is reported now, that revocation will not be reliably 384 notified to certificate-using systems until the next periodic CRL is 385 issued -- this may be up to one hour, one day, or one week depending 386 on the frequency that the CA issues CRLs. 388 Another potential problem with CRLs is the risk of a CRL growing to 389 an entirely unacceptable size. In the 1988 and 1993 versions of 390 X.509, the CRL for the end-user certificates needed to cover the 391 entire population of end-users for one CA. It is desirable to allow 392 such populations to be in the range of thousands, tens of thousands, 393 or possibly even hundreds of thousands of users. The end-user CRL is 394 therefore at risk of growing to such sizes, which present major 395 communication and storage overhead problems. With the version 2 CRL 396 format, introduced along with the v3 certificate format, it becomes 397 possible to arbitrarily divide the population of certificates for one 398 CA into a number of partitions, each partition being associated with 399 one CRL distribution point (e.g., directory entry or URL) from which 400 CRLs are distributed. Therefore, the maximum CRL size can be 401 controlled by a CA. Separate CRL distribution points can also exist 402 for different revocation reasons. For example, routine revocations 403 (e.g., name change) may be placed on a different CRL to revocations 404 resulting from suspected key compromises, and policy may specify that 405 the latter CRL be updated and issued more frequently than the former. 407 As with the X.509 v3 certificate format, in order to facilitate 408 interoperable implementations from multiple vendors, the X.509 v2 CRL 409 format needs to be profiled for Internet use. It is one goal of this 410 document to specify such profiles. 412 Furthermore, it is recognized that on-line methods of revocation 413 notification may be applicable in some environments as an alternative 414 to the X.509 CRL. On-line revocation checking eliminates the latency 415 between a revocation report and CRL the next issue. Once the 416 revocation is reported, any query to the on-line service will 417 correctly reflect the certificate validation impacts of the 418 revocation. Therefore, this profile will also consider standard 419 approaches to on-line revocation notification. 421 3.4 Operational Protocols 423 Operational protocols are required to deliver certificates and CRLs 424 to certificate using client systems. Provision is needed for a 425 variety of different means of certificate and CRL delivery, including 426 request/delivery procedures based on E-mail, http, X.500, and 427 WHOIS++. These specifications include definitions of, and/or 428 references to, message formats and procedures for supporting all of 429 the above operational environments, including definitions of or 430 references to appropriate MIME content types. 432 3.5 Management Protocols 434 Management protocols are required to support on-line interactions 435 between Public Key Infrastructure (PKI) components. For example, 436 management protocol might be used between a CA and a client system 437 with which a key pair is associated, or between two CAs which cross- 438 certify each other. The set of functions which potentially need to 439 be supported by management protocols include: 441 (a) registration: This is the process whereby a user first makes 442 itself known to a CA, prior to that CA issuing a certificate or 443 certificates for that user. 445 (b) initialization: Before a client system can operate securely it 446 is necessary to install in it necessary key materials which have the 447 appropriate relationship with keys stored elsewhere in the 448 infrastructure. For example, the client needs to be securely 449 initialized with the public key of a CA, to be used in validating 450 certificate paths. Furthermore, a client typically needs to be 451 initialized with its own key pair(s). 453 (c) certification: This is the process in which a CA issues a 454 certificate for a user's public key, and returns that certificate to 455 the user's client system and/or posts that certificate in a public 456 repository. 458 (d) key pair recovery: As an option, user client key materials 459 (e.g., a user's private key used for encryption purposes) may be 460 backed up by a CA or a key backup system associated with a CA. If a 461 user needs to recover these backed up key materials (e.g., as a 462 result of a forgotten password or a lost key chain file), an on-line 463 protocol exchange may be needed to support such recovery. 465 (e) key pair update: All key pairs need to be updated regularly, 466 i.e., replaced with a new key pair, and new certificates issued. 468 (f) revocation request: An authorized person advises a CA of an 469 abnormal situation requiring certificate revocation. 471 (g) cross-certification: Two CAs exchange the information necessary 472 to establish cross-certificates between those CAs. 474 Note that on-line protocols are not the only way of implementing the 475 above functions. For all functions there are off-line methods of 476 achieving the same result, and this specification does not mandate 477 use of on- line protocols. For example, when hardware tokens are 478 used, many of the functions may be achieved through as part of the 479 physical token delivery. Furthermore, some of the above functions 480 may be combined into one protocol exchange. In particular, two or 481 more of the registration, initialization, and certification functions 482 can be combined into one protocol exchange. 484 Part 3 of the PKIX series of specifications defines a set of standard 485 message formats supporting the above functions. The protocols for 486 conveying these messages in different environments (on-line, e-mail, 487 and WWW) are also specified. 489 4 Certificate and Certificate Extensions Profile 491 This section presents a profile for public key certificates that will 492 foster interoperability and a reusable public key infrastructure. 494 This section is based upon the X.509 V3 certificate format and the 495 standard certificate extensions defined in the Amendment [X.509-AM]. 496 The ISO definitions use the 1993 version of ASN.1; while this 497 document uses the older ASN.1 syntax, the encoded certificate and 498 standard extensions are equivalent. This section also defines 499 private extensions required to support a public key infrastructure 500 for the Internet community. 502 Certificates may be used in a wide range of applications and 503 environments covering a broad spectrum of interoperability goals and 504 a broader spectrum of operational and assurance requirements. The 505 goal of this document is to establish a common baseline for generic 506 applications requiring broad interoperability and limited special 507 purpose requirements. In particular, the emphasis will be on 508 supporting the use of X.509 v3 certificates for informal internet 509 electronic mail, IPSEC, and WWW applications. Other efforts are 510 looking at certificate profiles for payment systems. 512 4.1 Basic Certificate Fields 514 The X.509 v3 certificate basic syntax is as follows. For signature 515 calculation, the certificate is encoded using the ASN.1 distinguished 516 encoding rules (DER) [X.208]. ASN.1 DER encoding is a tag, length, 517 value encoding system for each element. 519 Certificate ::= SEQUENCE { 520 tbsCertificate TBSCertificate, 521 signatureAlgorithm AlgorithmIdentifier, 522 signature BIT STRING } 524 TBSCertificate ::= SEQUENCE { 525 version [0] Version DEFAULT v1, 526 serialNumber CertificateSerialNumber, 527 signature AlgorithmIdentifier, 528 issuer Name, 529 validity Validity, 530 subject Name, 531 subjectPublicKeyInfo SubjectPublicKeyInfo, 532 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 533 -- If present, version must be v2 or v3 534 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 535 -- If present, version must be v2 or v3 536 extensions [3] Extensions OPTIONAL 537 -- If present, version must be v3 538 } 540 Version ::= INTEGER { v1(0), v2(1), v3(2) } 541 CertificateSerialNumber ::= INTEGER 543 Validity ::= SEQUENCE { 544 notBefore CertificateValidityDate, 545 notAfter CertificateValidityDate } 547 CertificateValidityDate ::= CHOICE { 548 utcTime UTCTime, 549 generalTime GeneralizedTime } 551 UniqueIdentifier ::= BIT STRING 553 SubjectPublicKeyInfo ::= SEQUENCE { 554 algorithm AlgorithmIdentifier, 555 subjectPublicKey BIT STRING } 557 Extensions ::= SEQUENCE OF Extension 559 Extension ::= SEQUENCE { 560 extnID OBJECT IDENTIFIER, 561 critical BOOLEAN DEFAULT FALSE, 562 extnValue OCTET STRING } 564 The following items describe a proposed use of the X.509 v3 565 certificate for the Internet. 567 4.1.1 Certificate Fields 569 The Certificate is a SEQUENCE of three required fields. The fields 570 are are described in detail in the following subsections 572 4.1.1.1 tbsCertificate 574 The first field in the sequence is the tbsCertificate. This is a 575 itself a sequence, and contains the names of the subject and issuer, 576 a public key associated with the subject an expiration date, and 577 other associated information. The fields of the basic tbsCertificate 578 are described in detail in section 4.1.2; the tbscertificate may also 579 include extensions which are described in section 4.2. 581 4.1.1.2 signatureAlgorithm 583 The signatureAlgorithm field contains the algorithm identifier for 584 the algorithm used by the CA to sign the certificate. Section 7.2 585 lists the supported signature algorithms. 587 This field should contain the same algorithm identifier as the field 588 signature in the sequence tbsCertificate (see section 4.1.2.3) 590 4.1.1.3 signature 592 The signature field contains a digital signature computed upon the 593 ASN.1 DER encoded TBSCertificate. The ASN.1 DER encoded 594 TBSCertificate is used as the input to a one-way hash function. The 595 one-way hash function output value is ASN.1 encoded as an OCTET 596 STRING and the result is encrypted (e.g., using RSA Encryption) to 597 form the signed quantity. This signature value is then ASN.1 encoded 598 as a BIT STRING and included in the Certificate's signature field. 600 By generating this signature, a CA certifies the validity of the 601 information in tbscertificate. In particular, the CA certifies the 602 binding between the public key material and the subject of the 603 certificate. 605 4.1.2 TBSCertificate 607 The sequence TBSCertificate is a sequence which contains information 608 associated with the subject of the certificate and the CA who issued 609 it. Every TBSCertificate contains the names of the subject and 610 issuer, a public key associated with the subject, an expiration date, 611 a version number and a serial number; some will contain optional 612 unique identifier fields. The remainder of this section describes 613 the syntax and semantics of these fields. A TBSCertificate may also 614 include extensions. Extensions for the Internet PKI are described in 615 Section 4.2. 617 4.1.2.1 Version 619 This field describes the version of the encoded certificate. When 620 extensions are used, as expected in this profile, use X.509 version 3 621 (value is 2). If no extensions are present, but a UniqueIdentifier 622 is present, use version 2 (value is 1). If only basic fields are 623 present, use version 1 (the value is omitted from the certificate as 624 the default value). 626 Implementations should be prepared to accept any version certificate. 627 In particular, at a minimum, implementations must recognize version 3 628 certificates; determine whether any critical extensions are present; 629 and accept certificates without critical extensions even if they 630 don't recognize any extensions. A certificate with an unrecognized 631 critical extension must always be rejected. 633 Generation of version 2 certificates is not expected by 634 implementations based on this profile. 636 4.1.2.2 Serial number 638 The serial number is an integer assigned by the certification 639 authority to each certificate. It must be unique for each 640 certificate issued by a given CA (i.e., the issuer name and serial 641 number identify a unique certificate). 643 4.1.2.3 Signature 645 This field contains the algorithm identifier for the algorithm used 646 by the CA to sign the certificate. Section 7.2 lists the supported 647 signature algorithms. 649 4.1.2.4 Issuer Name 651 The issuer name identifies the entity who has signed (and issued the 652 certificate). The issuer identity may be carried in the issuer name 653 field and/or the issuerAltName extension. If identity information is 654 present only in the issuerAltName extension, then the issuer name may 655 be an empty sequence and the issuerAltName extension must be 656 critical. 658 4.1.2.5 Validity 660 This field indicates the dates on which the certificate becomes valid 661 (notBefore) and on which the certificate ceases to be valid 662 (notAfter). Both notBefore and notAfter may be encoded as UTCTime or 663 GeneralizedTime. 665 CAs conforming to this profile shall not issue certificates where 666 notAfter or notBefore is encoded as GeneralizedTime before the year 667 2005. CAs conforming to this profile shall not issue certificates 668 where notAfter or notBefore is encoded as UTCTime after the year 669 2015. 671 4.1.2.5.1 UTCTime 673 The universal time type, UTCTime, is a standard ASN.1 type intended 674 for international applications where local time alone is not 675 adequate. UTCTime specifies the year through the two low order digits 676 and time is specified to the precision of one minute or one second. 677 UTCTime includes either Z (for Zulu, or Greenwich Mean Time) or a 678 time differential. 680 For the purposes of this profile, UTCTime values shall be expressed 681 Greenwich Mean Time (Zulu) and shall include< seconds (i.e., times 682 are YYMMDDHHMMSSZ), even where the number of seconds is zero. 683 Conforming systems shall interpret the year field (YY) as follows: 685 Where YY is greater than 50, the year shall be interpreted as 686 19YY; and 688 Where YY is less than or equal to 50, the year shall be 689 interpreted as 20YY. 691 4.1.2.6 GeneralizedTime 693 The generalized time type, GeneralizedTime, is a standard ASN.1 type 694 for variable precision representation of time. Optionally, the 695 GeneralizedTime field can include a representation of the time 696 differential between local and Greenwich Mean Time. 698 For the purposes of this profile, GeneralizedTime values shall be 699 expressed Greenwich Mean Time (Zulu) and shall include seconds (i.e., 700 times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. 701 GeneralizedTime values shall not include fractional seconds. 703 4.1.2.6 Subject Name 705 The subject name identifies the entity associated with the public key 706 stored in the subject public key field. The subject identity may be 707 carried in the subject field and/or the subjectAltName extension. If 708 identity information is present only in the subjectAltName extension 709 (e.g., a key bound only to an email address or URI), then the subject 710 name may be an empty sequence and the subjectAltName extension must 711 be critical. 713 4.1.2.7 Subject Public Key Info 715 This field is used to carry the public key and identify the algorithm 716 with which the key is used. 718 4.1.2.8 Unique Identifiers 720 The subject and issuer unique identifier are present in the 721 certificate to handle the possibility of reuse of subject and/or 722 issuer names over time. This profile recommends that names not be 723 reused and that Internet certificates not make use of unique 724 identifiers. CAs conforming to this profile should not generate 725 certificates with unique identifiers. Applications conforming to 726 this profile should be capable of parsing unique identifiers and 727 making comparisons. 729 4.2 Certificate Extensions 731 The extensions defined for X.509 v3 certificates provide methods for 732 associating additional attributes with users or public keys, for 733 managing the certification hierarchy, and for managing CRL 734 distribution. The X.509 v3 certificate format also allows 735 communities to define private extensions to carry information unique 736 to those communities. Each extension in a certificate may be 737 designated as critical or non-critical. A certificate using system 738 (an application validating a certificate) must reject the certificate 739 if it encounters a critical extension it does not recognize. A non- 740 critical extension may be ignored if it is not recognized. The 741 following presents recommended extensions used within Internet 742 certificates and standard locations for information. Communities may 743 elect to use additional extensions; however, caution should be 744 exercised in adopting any critical extensions in certificates which 745 might be used in a general context. 747 Each extension includes an object identifier and an ASN.1 structure. 748 When an extension appears in a certificate, the object identifier 749 appears as the field extnID and the corresponding ASN.1 encoded 750 structure is the value of the bit string extnValue. Only one 751 instance of a particular extension may appear in a particular 752 certificate. For example, a certificate may contain only one 753 authority key identifier extension (4.2.1.1). An extension may also 754 include the optional boolean critical; critical's default value is 755 FALSE. The text for each extension specifies the acceptable values 756 for the critical field. 758 Conforming CAs are required to support the Basic Constraints 759 extension (Section 4.2.1.10). If the CA issues certificates with an 760 empty sequence for the subject field, the CA must support the 761 altSubjectName extension. If the CA issues certificates with an 762 empty sequence for the issuer field, the CA must support the 763 altIssuerName extension. Support for the remaining extensions is 764 optional. Conforming CAs may support extensions that are not 765 identified within this specification; certificate issuers are 766 cautioned that marking such extensions as critical may inhibit 767 interoperability. 769 At a minimum, applications conforming to this profile shall recognize 770 extensions which shall or may be critical. These extensions are: key 771 usage (4.2.1.3), certificate policies (4.2.1.5), the alternative 772 subject name (4.2.1.7), issuer alternative name (4.2.1.8), basic 773 constraints (4.2.1.10), name constraints (4.2.1.11), policy 774 constraints (4.2.1.12), authority information access (4.2.2.2), and 775 CA information access (4.2.2.3). 777 In addition, this profile recommends support for key identifiers 778 (4.2.1.2 and 4.2.1.3) and CRL distribution points (4.2.1.13). 780 4.2.1 Standard Extensions 782 This section identifies standard certificate extensions defined in 783 [X.509-AM] for use in the Internet Public Key Infrastructure. Each 784 extension is associated with an object identifier defined in [X.509- 785 AM]. These object identifiers are members of the 786 certificateExtension arc, which is defined by the following: 788 certificateExtension OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 789 id-ce OBJECT IDENTIFIER ::= certificateExtension 791 4.2.1.1 Authority Key Identifier 793 The authority key identifier extension provides a means of 794 identifying the particular public key used to sign a certificate. 795 This extension would be used where an issuer has multiple signing 796 keys (either due to multiple concurrent key pairs or due to 797 changeover). In general, this extension should be included in 798 certificates. 800 The identification can be based on either the key identifier (the 801 subject key identifier in the issuer's certificate) or on the issuer 802 name and serial number. The key identifier method is recommended in 803 this profile. Conforming CAs that generate this extension shall 804 include or omit both authorityCertIssuer and 805 authorityCertSerialNumber. If authorityCertIssuer and 806 authorityCertSerialNumber are omitted, the keyIdentifier field shall 807 be present. 809 This extension shall not be marked critical. 811 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 813 AuthorityKeyIdentifier ::= SEQUENCE { 814 keyIdentifier [0] KeyIdentifier OPTIONAL, 815 authorityCertIssuer [1] GeneralNames OPTIONAL, 816 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL 817 } 819 KeyIdentifier ::= OCTET STRING 821 4.2.1.2 Subject Key Identifier 823 The subject key identifier extension provides a means of identifying 824 the particular public key used in an application. Where a reference 825 to a public key identifier is needed (as with an Authority Key 826 Identifier) and one is not included in the associated certificate, a 827 SHA-1 hash of the subject public key shall be used. The hash shall 828 be calculated over the value (excluding tag and length) of the 829 subject public key field in the certificate. This extension should 830 be marked non-critical. 832 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 834 SubjectKeyIdentifier ::= KeyIdentifier 836 4.2.1.3 Key Usage 838 The key usage extension defines the purpose (e.g., encipherment, 839 signature, certificate signing) of the key contained in the 840 certificate. The usage restriction might be employed when a 841 multipurpose key is to be restricted (e.g., when an RSA key should be 842 used only for signing or only for key encipherment). The profile 843 recommends that when used, this be marked as a critical extension. 845 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 847 KeyUsage ::= BIT STRING { 848 digitalSignature (0), 849 nonRepudiation (1), 850 keyEncipherment (2), 851 dataEncipherment (3), 852 keyAgreement (4), 853 keyCertSign (5), 854 cRLSign (6) } 856 4.2.1.4 Private Key Usage Period 858 The private key usage period extension allows the certificate issuer 859 to specify a different validty period for the private key than the 860 certificate. This extension is intended for use with digital 861 signature keys. This extension consists of two optional components 862 notBefore and notAfter. The private key associated with the 863 certificate should not be used to sign objects before or after the 864 times specified by the two components, respectively. CAs conforming 865 to this profile shall not generate certificates with private key 866 usage period extensions unless at least one of the two components is 867 present. 869 This profile recommends against the use of this extension. CAs 870 conforming to this profile shall not generate certificates with 871 critical private key usage period extensions. 873 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 875 PrivateKeyUsagePeriod ::= SEQUENCE { 876 notBefore [0] GeneralizedTime OPTIONAL, 877 notAfter [1] GeneralizedTime OPTIONAL } 879 4.2.1.5 Certificate Policies 881 The certificate policies extension contains a sequence of policy 882 information terms, each of which consists of an object identifier 883 (OID) and optional qualifiers. These policy information terms 884 indicate the policy under which the certificate has been issued and 885 the purposes for which the certificate may be used. This profile 886 strongly recommends that a simple OID be present in this field. 887 Optional qualifiers which may be present are expected to provide 888 information about obtaining CA rules, not change the definition of 889 the policy. 891 Applications with specific policy requirements are expected to have a 892 list of those policies which they will accept and to compare the 893 policy OIDs in the certificate to that list. If this extension is 894 critical, the path validation software must be able to interpret this 895 extension, or must reject the certificate. (Applications are free to 896 ignore the policy field, even if the extension is marked critical.) 898 This specification defines two policy qualifiers types for use by 899 certificate policy writers and certificate issuers at their own 900 discretion. The quailfier types are the CPS Pointer qualifier, and 901 the User Notice qualifier. 903 The CPS Pointer qualifier contains a pointer to a Certification 904 Practice Statement (CPS) published by the CA. The pointer is in the 905 form of a URI. 907 The User Notice qualifier contains a text string that is to be 908 displayed to a certificate user (including subscribers and relying 909 parties) prior to the use of the certificate. The text string may be 910 an IA5String or a BMPString - a subset of the ISO 100646-1 multiple 911 octet coded character set. A CA may invoke a procedure that requires 912 that the certficate user acknowledge that the applicable terms and 913 conditions have been disclosed or accepted. 915 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 917 certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 919 PolicyInformation ::= SEQUENCE { 920 policyIdentifier CertPolicyId, 921 policyQualifiers SEQUENCE SIZE (1..MAX) OF 922 PolicyQualifierInfo OPTIONAL } 924 CertPolicyId ::= OBJECT IDENTIFIER 926 PolicyQualifierInfo ::= SEQUENCE { 927 policyQualifierId PolicyQualifierId, 928 qualifier ANY DEFINED BY policyQualifierId } 930 -- policyQualifierIds for Internet policy qualifiers 932 id-pkix-cps OBJECT IDENTIFIER ::= { pkix 4 } 933 id-pkix-unotice OBJECT IDENTIFIER ::= { pkix 5 } 935 PolicyQualifierId ::= ENUMERATED { id-pkix-cps, id-pkix-unotice } 937 Qualifier ::= CHOICE { 938 cPSuri CPSuri, 939 userNotice UserNotice } 941 CPSuri ::= IA5String 943 UserNotice ::= CHOICE { 944 ia5String IA5String, 945 bmpString ANY } 947 4.2.1.6 Policy Mappings 949 This extension is used in CA certificates. It lists pairs of 950 obbjectidentifiers; each pair includes an issuerDomainPolicy and a 951 subjectDomainPolicy. The pairing indicates the issuing CA considers 952 its issuerDomainPolicy equivalent to the subject CA's 953 subjectDomainPolicy. 955 The issuing CA's users may accept an issuerDomainPolicy for certain 956 applications. The policy mapping tells the issuing CA's users which 957 policies associated with the subject CA are comparable to the policy 958 they accept. 960 This extension may be supported by CAs and/or applications, and it is 961 always non-critical. 963 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 965 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 966 issuerDomainPolicy CertPolicyId, 967 subjectDomainPolicy CertPolicyId } 969 4.2.1.7 Subject Alternative Name 971 The subject alternative names extension allows additional identities 972 to be bound to the subject of the certificate. Defined options 973 include an rfc822 name (electronic mail address), a DNS name, an IP 974 address, and a URI. Other options exist, including completely local 975 definitions. Multiple instances of a name and multiple name forms 976 may be included. Whenever such identities are to be bound into a 977 certificate, the subject alternative name (or issuer alternative 978 name) extension shall be used. (Note: a form of such an identifier 979 may also be present in the subject distinguished name; however, the 980 alternative name extension is the preferred location for finding such 981 information.) 983 Further, if the only subject identity included in the certificate is 984 an alternative name form (e.g., an electronic mail address), then the 985 subject distinguished name should be empty (an empty sequence), the 986 subjectAltName extension should be used. If the subject field 987 contains an empty squence, the subjectAltName extension shall be 988 marked critical. 990 Alternative names may be constrained in the same manner as subject 991 distinguished names using the name constraints extension as described 992 in section 4.2.1.11. 994 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 996 SubjectAltName ::= GeneralNames 998 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 1000 GeneralName ::= CHOICE { 1001 otherName [0] ANY, 1002 rfc822Name [1] IA5String, 1003 dNSName [2] IA5String, 1004 x400Address [3] ORAddress, 1005 directoryName [4] Name, 1006 ediPartyName [5] EDIPartyName, 1007 uniformResourceIdentifier [6] IA5String, 1008 iPAddress [7] OCTET STRING, 1009 registeredID [8] OBJECT IDENTIFIER } 1011 EDIPartyName ::= SEQUENCE { 1012 nameAssigner [0] DirectoryString OPTIONAL, 1013 partyName [1] DirectoryString } 1015 4.2.1.8 Issuer Alternative Name 1017 As with 4.2.1.7, this extension is used to associate Internet style 1018 identities with the certificate issuer. If the only issuer identity 1019 included in the certificate is an alternative name form (e.g., an 1020 electronic mail address), then the issuer distinguished name should 1021 be empty (an empty sequence), the issuerAltName extension should be 1022 used. If the issuer field is empty and more than one issuerAltName 1023 extension is included in the certificate, the issuerAltName extension 1024 shall be marked critical. 1026 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 1028 IssuerAltName ::= GeneralNames 1030 4.2.1.9 Subject Directory Attributes 1032 The subject directory attributes extension is not recommended as an 1033 essential part of this profile, but it may 1034 be used in local environments. This extension is always non-critical. 1036 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 1038 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 1040 4.2.1.10 Basic Constraints 1042 The basic constraints extension identifies whether the subject of the 1043 certificate is a CA and how deep a certification path may exist 1044 through that CA. This profile requires the use of this extension, 1045 and it shall be critical for all certificates issued to CAs. 1047 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 1049 BasicConstraints ::= SEQUENCE { 1050 cA BOOLEAN DEFAULT FALSE, 1051 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 1053 4.2.1.11 Name Constraints 1055 The name constraints extension provides permitted and excluded 1056 subtrees that place restrictions on names that may be included within 1057 a certificate issued by a given CA. Restrictions may apply to the 1058 subject distringuished name or subject alternative names. Any name 1059 matching a restriction in the excluded subtrees field is invalid 1060 regardless of information appearing in the permitted subtrees. This 1061 extension may be critical or non-critical. 1063 Restrictions for the rfc822, dNSName, and uri name forms are all 1064 expressed in terms of strings with wild card matching. An "*" is the 1065 wildcard character. The minimum and maximum fields in general 1066 subtree are not used for these name forms. For uris and rfc822 1067 names, the restriction applies to the host part of the name. 1068 Examples would be foo.bar.com; www*.bar.com; *.xyz.com. 1070 Restrictions of the form directoryName shall be applied to the 1071 subject field in the certificate and to the subjectAltName extensions 1072 of type directoryName. Restrictions of the form x400Address shall be 1073 applied to subjectAltName extensions of type x400Address. 1075 The syntax and semantics for name constraints for otherName, 1076 ediPartyName, and registeredID are not defined by this specification. 1078 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 1080 NameConstraints ::= SEQUENCE { 1081 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 1082 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 1084 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 1086 GeneralSubtree ::= SEQUENCE { 1087 base GeneralName, 1088 minimum [0] BaseDistance DEFAULT 0, 1089 maximum [1] BaseDistance OPTIONAL } 1091 BaseDistance ::= INTEGER (0..MAX) 1093 4.2.1.12 Policy Constraints 1095 The policy constraints extension can be used in certificates issued 1096 to CAs. The policy constraints extension constrains path validation 1097 in two ways. It can be used to prohibit policy mapping or limit the 1098 set of poicies that can in subsequent certificates. This extension 1099 may be critical or non-critical. 1101 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 34 } 1103 PolicyConstraints ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 1104 policySet [0] CertPolicySet OPTIONAL, 1105 requireExplicitPolicy [1] SkipCerts OPTIONAL, 1106 inhibitPolicyMapping [2] SkipCerts OPTIONAL } 1108 SkipCerts ::= INTEGER (0..MAX) 1110 CertPolicySet ::= SEQUENCE SIZE (1..MAX) OF CertPolicyId 1112 4.2.1.13 CRL Distribution Points 1114 The CRL distribution points extension identifies how CRL information 1115 is obtained. The extension shall be non-critical, but this profile 1116 recommends support for this extension by CAs and applications. 1117 Further discussion of CRL management is contained in section 5. 1119 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 } 1121 cRLDistributionPoints ::= { 1122 CRLDistPointsSyntax } 1124 CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 1126 DistributionPoint ::= SEQUENCE { 1127 distributionPoint [0] DistributionPointName OPTIONAL, 1128 reasons [1] ReasonFlags OPTIONAL, 1129 cRLIssuer [2] GeneralNames OPTIONAL } 1131 DistributionPointName ::= CHOICE { 1132 fullName [0] GeneralNames, 1133 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 1135 ReasonFlags ::= BIT STRING { 1136 unused (0), 1137 keyCompromise (1), 1138 cACompromise (2), 1139 affiliationChanged (3), 1140 superseded (4), 1141 cessationOfOperation (5), 1142 certificateHold (6) } 1144 4.2.2 Private Internet Extensions 1146 This section defines new extensions for use in the Internet Public 1147 Key Infrastructure. These extensions may be used to direct 1148 applications to additional information about the certificate's 1149 subject or issuer. This extension includes the type of information, 1150 where it is located, and a method for obtaining the information. The 1151 types of information include certificate status, CA policy 1152 information, and related certificates. 1154 The object identifiers associated with the private extensions are 1155 defined under the iso (1), org (3), dod (6), internet (1), 1156 security(5) or 1.3.6.1.5, branch of the name space. These extensions 1157 make use of OIDs of the form {applTCPProtoID port}, which identify 1158 TCP-based protocols that don't have OIDs assigned by other means, to 1159 identify common methods for retrieving information. 1161 The following ASN.1 defines object identifiers which may be used by 1162 applications that implement the private extensions; additional access 1163 methods may be used, but the semantics are undefined by this 1164 document. 1166 pkix OBJECT IDENTIFIER ::= { iso(1) org(3) dod (6) internet (1) 1167 security(5) pkix(?) } 1169 -- Object identifiers for ftp, http, smtp and ldap protocols 1171 applTCPProto OBJECT IDENTIFIER ::= { 1 3 6 1 2 1 27 4 } 1173 ftpID OBJECT-IDENTIFIER ::= {applTCPProtoID 21} 1174 httpID OBJECT-IDENTIFIER ::= {applTCPProtoID 80} 1175 smtpID OBJECT-IDENTIFIER ::= {applTCPProtoID 25} 1176 ldapID OBJECT-IDENTIFIER ::= {applTCPProtoID 389} 1178 -- Object identifier for the X.500 directory access protocol 1180 dap OBJECT-IDENTIFIER ::= { 2 5 3 1 } 1182 4.2.2.1 Subject Information Access 1184 The name information in the certificate identifies the entity to 1185 which the public key is bound. In some instances, it may also be 1186 necessary to know where to find additional information about the 1187 named entity. In the case of X.500 names, this relationship is 1188 automatic. The subject information access extension provides a means 1189 of identifying where and how to find information about the subject. 1190 The extension specifies a method of obtaining information and a 1191 general name form indicating where. This extension shall always be 1192 non-critical. 1194 id-pkix-subjectInfoAccess OBJECT-IDENTIFIER ::= { pkix 1} 1196 -- subjectInfoAccess ::= { SubjectInfoAccessSyntax } 1198 SubjectInfoAccessSyntax ::= SEQUENCE SIZE (1..MAX) OF AccessDescription 1200 AccessDescription ::= SEQUENCE { 1201 accessMethod OBJECT IDENTIFIER, 1202 accessLocation GeneralName } 1204 This specification defines the following values for accessMethod: 1205 ftpID, httpID, smtpID, ldapID, and dap. The accessMethod value 1206 indicates the protocol required to obtain the information. If 1207 accessMethod is ftpID, then the information must available through 1208 anonymous ftp. If accessMethod is ftpID, httpID, smtpID, or ldapID, 1209 then the accessLocation shall be a uniformResourceIndicator (i.e., a 1210 URI). The URI shall specify all information required to retrieve the 1211 information. If accessMethod is dap, then the accessLocation shall 1212 be a directoryName. 1214 4.2.2.2 Authority Information Access 1216 The authority information access extension indicates how to access CA 1217 information and services for the issuer of the certificate in which 1218 the extension appears. Information and services include certificate 1219 status or on-line validation services, certificate retrieval, CA 1220 policy data, and CA certificates (certificates certifying the target 1221 CA to aid in certification path navigation). This extension may be 1222 included in subject or CA certificates and may be critical or non- 1223 critical. 1225 id-pkix-authorityInfoAccess OBJECT-IDENTIFIER ::= { pkix 2} 1227 -- authorityInfoAccess ::= { AuthorityInfoAccessSyntax } 1229 AuthorityInfoAccessSyntax ::= SEQUENCE { 1230 certStatus [0] SEQUENCE OF AccessDescription OPTIONAL, 1231 certRetrieval [1] SEQUENCE OF AccessDescription OPTIONAL, 1232 caPolicy [2] SEQUENCE OF AccessDescription OPTIONAL, 1233 caCerts [3] SEQUENCE OF AccessDescription OPTIONAL } 1235 If certStatus is present, each entry in that sequence describes a 1236 mechanism and location for 1238 on-line verification of the status of this certificate, or 1240 the CRL on which this certificate would appear if revoked. 1242 If certRetrieval is present, each entry in the sequence describes how 1243 to retrieve all current certificates whose subject is the issuer of 1244 the certificate in which this extension appears. 1246 If caPolicy is present, each entry in the sequence describes how to 1247 retrieve the policy that was in effect when this certificate was 1248 issued. 1250 If caCerts is present, each entry in the sequence describes a 1251 mechanism and location for retrieval of certificates the issuer has 1252 issued to other CAs. 1254 If the certStatus, certRetrieval, caPolicy, or caCerts sequence has 1255 more than one value, conforming applications are not required to 1256 process all the values. Successful processing of any one 1257 AccessDescritpion shall be sufficient. It is the responsibility of 1258 the certificate issuer to ensure all mechanisms provide the same 1259 information. 1261 The expected values for AccessDescription are the values defined in 1262 4.2.2.1. Processing rules for other values for accessMethod are not 1263 defined. 1265 If this extension is critical, applications are required to use the 1266 information in the certStatus field (if present) to check the 1267 revocation status of this certificate, the certRetrieval field (if 1268 present) to obtain the issuer's current certificates, and the caCerts 1269 field (if present) to obtain certificates issued by the subject to 1270 other CAs. 1272 There are no additional processing requirements for cAPolicy if the 1273 extension is marked as critical. 1275 4.2.2.3 CA Information Access 1277 Where the subject of a certificate is a CA, the subjectInfoAccess 1278 extension may be insufficient. The CA information access extension 1279 indicates how to access CA information and services for the subject 1280 of the certificate in which the extension appears. Information and 1281 services include certificate status or on-line validation services, 1282 certificate retrieval, CA policy data, and CA certificates 1283 (certificates certifying the target CA to aid in cert path 1284 navigation). This extension is syntactically identical to 1285 authorityInfoAccess, but is identified by a different OID. This 1286 extension may be included only in CA certificates and may be critical 1287 or non-critical. CA certificates may include both an authority and a 1288 caInfoAccess extension to describe access methods for both the CA and 1289 its issuer. 1291 id-pkix-caInfoAccess OBJECT-IDENTIFIER ::= { pkix 3 } 1293 -- caInfoAccess ::= { AuthorityInfoAccessSyntax } 1295 If certStatus is present, each entry in that sequence describes a 1296 mechanism and location for 1298 on-line verification of the status of this certificate, or 1300 CRL issued by the subject of this certificate. 1302 If certRetrieval is present, each entry in the sequence describes how 1303 to retrieve all current certificates whose subject is the subject of 1304 the certificate in which this extension appears. 1306 If caPolicy is present, each entry in the sequence describes how to 1307 retrieve the current policy tssociated with the subject of this 1308 certificate. 1310 If caCerts is present, each entry in the sequence describes a 1311 mechanism and location for retrieval of certificates the subject has 1312 issued to other CAs. 1314 If the certStatus, certRetrieval, caPolicy, or caCerts sequence has 1315 more than one value, conforming applications are not required to 1316 process all the values. Successful processing of any one 1317 AccessDescritpion shall be sufficient. It is the responsibility of 1318 the certificate issuer to ensure all mechanisms provide the same 1319 information. 1321 The legal values for AccessDescription shall be as defined in 1322 4.2.2.1. 1324 If this extension is critical, applications are required to use the 1325 information in the certStatus field (if present) to check the 1326 revocation status of this certificate, the certRetrieval field (if 1327 present) to obtain the subject's other current certificates, and the 1328 caCerts field (if present) to obtain certificates issued by the 1329 subject to other CAs. 1331 There are no additional processing requirements for cAPolicy if the 1332 extension is marked as critical. 1334 4.3 Examples 1336 << Certificate samples including descriptive text and ASN.1 encoded 1337 blobs will be inserted. >> 1339 4.3.1 Simple certificate, no extensions 1341 <> 1343 4.3.2 Certificate with Private extensions 1345 <> 1347 4.3.3 certificate with no subject DN 1349 <> 1351 5 CRL and CRL Extensions Profile 1353 As described above, one goal of this X.509 v2 CRL profile is to 1354 foster the creation of an interoperable and reusable Internet PKI. 1355 To achieve this goal, guidelines for the use of extensions are 1356 specified, and some assumptions are made about the nature of 1357 information included in the CRL. 1359 CRLs may be used in a wide range of applications and environments 1360 covering a broad spectrum of interoperability goals and an even 1361 broader spectrum of operational and assurance requirements. This 1362 profile establishes a common baseline for generic applications 1363 requiring broad interoperability. Emphasis is placed on support for 1364 X.509 v2 CRLs. The profile defines a baseline set of information 1365 that can be expected in every CRL. Also, the profile defines common 1366 locations within the CRL for frequently used attributes, and common 1367 representations for these attributes. 1369 This profile does not define any private Internet CRL extensions or 1370 CRL entry extensions. 1372 Environments with additional or special purpose requirements may 1373 build on this profile or may replace it. 1375 Conforming CAs are not required to issue CRLs if other revocation or 1376 status mechanisms are provided. Conforming CAs that issue CRLs are 1377 required to issue version 2 CRLs. Conforming applications are 1378 required to process version 1 and 2 certificates. 1380 5.1 CRL Fields 1382 The X.509 v2 CRL syntax is as follows. For signature calculation, 1383 the data that is to be signed is ASN.1 DER encoded. ASN.1 DER 1384 encoding is a tag, length, value encoding system for each element. 1386 CertificateList ::= SEQUENCE { 1387 tbsCertList TBSCertList, 1388 signatureAlgorithm AlgorithmIdentifier, 1389 signature BIT STRING } 1391 TBSCertList ::= SEQUENCE { 1392 version Version OPTIONAL, 1393 -- if present, must be v2 1394 signature AlgorithmIdentifier, 1395 issuer Name, 1396 thisUpdate ChoiceOfTime, 1397 nextUpdate ChoiceOfTime, 1398 revokedCertificates SEQUENCE OF SEQUENCE { 1399 userCertificate CertificateSerialNumber, 1400 revocationDate ChoiceOfTime, 1401 crlEntryExtensions Extensions OPTIONAL 1402 -- if present, must be v2 1403 } OPTIONAL, 1404 crlExtensions [0] Extensions OPTIONAL 1405 -- if present, must be v2 1406 } 1408 ChoiceOfTime ::= CHOICE { 1409 utcTime UTCTime, 1410 generalTime GeneralizedTime } 1412 Version ::= INTEGER { v1(0), v2(1), v3(2) } 1414 AlgorithmIdentifier ::= SEQUENCE { 1415 algorithm OBJECT IDENTIFIER, 1416 parameters ANY DEFINED BY algorithm OPTIONAL } 1417 -- contains a value of the type 1418 -- registered for use with the 1419 -- algorithm object identifier value 1421 CertificateSerialNumber ::= INTEGER 1423 Extensions ::= SEQUENCE OF Extension 1425 Extension ::= SEQUENCE { 1426 extnId OBJECT IDENTIFIER, 1427 critical BOOLEAN DEFAULT FALSE, 1428 extnValue OCTET STRING } 1429 -- contains a DER encoding of a value 1430 -- of the type registered for use with 1431 -- the extnId object identifier value 1433 The following items describe the proposed use of the X.509 v2 CRL in 1434 the Internet PKI. 1436 5.1.1 CertificateList Fields 1438 The CertificateList is a SEQUENCE of three required fields. The 1439 fields are are described in detail in the following subsections 1441 5.1.1.1 tbsCertList 1443 The first field in the sequence is the tbsCertList. This is a itself 1444 a sequence, and is generally thought of as the X.509 CRL. It contains 1445 the names of the subject and issuer, a public key associated with the 1446 subject an expiration date, and other associated information. The 1447 fields of the basic tbsCertificate are described in detail in section 1448 4.1.2; the tbscertificate may also include extensions which are 1449 described in section 4.2. 1451 5.1.1.2 signatureAlgorithm 1453 The signatureAlgorithm field contains the algorithm identifier for 1454 the algorithm used by the CA to sign the CertificateList. Section 1455 7.2 lists the supported signature algorithms. 1457 5.1.1.3 signature 1459 The signature field contains a digital signature computed upon the 1460 ASN.1 DER encoded TBSCertList. The ASN.1 DER encoded TBSCertificate 1461 is used as the input to a one-way hash function. The one-way hash 1462 function output value is ASN.1 encoded as an OCTET STRING and the 1463 result is encrypted (e.g., using RSA Encryption) to form the signed 1464 quantity. This signature value is then ASN.1 encoded as a BIT STRING 1465 and included in the Certificate's signature field. 1467 5.1.2 Certificate List "To Be Signed" 1469 The certificate list to be signed, or tBSCertList, is a SEQUENCE of 1470 required and optional fields. The required fields identify the CRL 1471 issuer, the algorithm used to sign the CRL, the date and time the CRL 1472 was issued, and the date and time by which the CA will issue the next 1473 CRL. 1475 Optional fields include lists of revoked certificates and CRL 1476 extensions. The revoked certificate list is optional to support the 1477 special case where a CA has not revoked any unexpired certificates it 1478 has issued. It is expected that nearly all CRLs issued in the 1479 Internet PKI will contain one or more lists of revoked certificates. 1480 Similarly, the profile requires conforming CAs to use of one CRL 1481 extension (CRL number) in all CRLs issued. 1483 5.1.2.1 Version 1485 This field describes the version of the encoded CRL. When extensions 1486 are used, as expected in this profile, use version 2 (the integer 1487 value is 1). If neither CRL extensions nor CRL entry extensions are 1488 present, version 1 CRLs are recommended (e.g., the integer value 1489 should be omitted). 1491 5.1.2.2 Signature 1493 This field contains the algorithm identifier for the algorithm used 1494 to sign the CRL. Section 7.2 lists the signature algorithms used in 1495 the Internet PKI. 1497 5.1.2.3 Issuer Name 1499 The issuer name identifies the entity who has signed (and issued the 1500 CRL). The issuer identity may be carried in the issuer name field 1501 and/or the issuerAltName extension. If identity information is 1502 present only in the issuerAltName extension, then the issuer name may 1503 be an empty sequence and the issuerAltName extension must be 1504 critical. 1506 5.1.2.4 This Update 1508 This field indicates the issue date of this CRL. ThisUpdate may be 1509 encoded as UTCTime or GeneralizedTime. 1511 CAs conforming to this profile shall not issue CRLs where thisUpdate 1512 is encoded as GeneralizedTime before the year 2005. CAs conforming to 1513 this profile shall not issue CRLs where thisUpdate is encoded as 1514 UTCTime after the year 2015. 1516 Where encoded as UTCTime, thisUpdate shall be specified and 1517 interpreted as defined in Section 4.1.2.5.1. Where encoded as 1518 GeneralizedTime, thisUpdate shall be specified and interpreted as 1519 defined in Section 4.1.2.5.2. 1521 5.1.2.5 Next Update 1523 This field indicates the date by which the next CRL will be issued. 1524 The next CRL could be issued before the indicated date, but it will 1525 not be issued any later than the indicated date. nextUpdate may be 1526 encoded as UTCTime or GeneralizedTime. 1528 CAs conforming to this profile shall not issue CRLs where nextUpdate 1529 is encoded as GeneralizedTime before the year 2005. CAs conforming to 1530 this profile shall not issue CRLs where nextUpdate is encoded as 1531 UTCTime after the year 2015. 1533 Where encoded as UTCTime, nextUpdate shall be specified and 1534 interpreted as defined in Section 4.1.2.5.1. Where encoded as 1535 GeneralizedTime, nextUpdate shall be specified and interpreted as 1536 defined in Section 4.1.2.5.2. 1538 5.1.2.6 Revoked Certificates 1540 Revoked certificates are listed. The revoked certificates are named 1541 by their serial numbers. Certificates are uniquely identified by the 1542 combination of the issuer name or issuer alternative name along with 1543 the user certificate serial number. The date on which the revocation 1544 occured is specified. The time for revocationDate shall be expressed 1545 as described in section 5.1.2.4. Additional information may be 1546 supplied in CRL entry extensions; CRL entry extensions are discussed 1547 in section 5.3. 1549 5.2 CRL Extensions 1551 The extensions defined by ANSI X9 and ISO for X.509 v2 CRLs [X.509- 1552 AM] [X9.55] provide methods for associating additional attributes 1553 with CRLs. The X.509 v2 CRL format also allows communities to define 1554 private extensions to carry information unique to those communities. 1555 Each extension in a CRL may be designated as critical or non- 1556 critical. A CRL validation must fail if it encounters an critical 1557 extension which it does not know how to process. However, an 1558 unrecognized non-critical extension may be ignored. The following 1559 presents those extensions used within Internet CRLs. Communities may 1560 elect to include extensions in CRLs which are not defined in this 1561 specification. However, caution should be exercised in adopting any 1562 critical extensions in CRLs which might be used in a general context. 1564 Conforming CAs that issue CRLs are required to support the CRL number 1565 extension (5.2.3), and include it in all CRLs issued. Conforming 1566 applications are required to support the critical and optionally 1567 critical CRL extensions issuer alternative name (5.2.2), issuing 1568 distribution point (5.2.4) and delta CRL indicator (5.2.5). 1570 5.2.1 Authority Key Identifier 1572 The authority key identifier extension provides a means of 1573 identifying the particular public key used to sign a CRL. The 1574 identification can be based on either the key identifier (the subject 1575 key identifier in the CRL signer's certificate) or on the issuer name 1576 and serial number. The key identifier method is recommended in this 1577 profile. This extension would be used where an issuer has multiple 1578 signing keys, either due to multiple concurrent key pairs or due to 1579 changeover. In general, this non-critical extension should be 1580 included in certificates. 1582 The syntax for this CRL extension is defined in Section 4.2.1.1. 1584 5.2.2 Issuer Alternative Name 1586 The issuer alternative names extension allows additional identities 1587 to be associated with the issuer of the CRL. Defined options include 1588 an rfc822 name (electronic mail address), a DNS name, an IP address, 1589 and a URI. Multiple instances of a name and multiple name forms may 1590 be included. Whenever such identities are used, the issuer 1591 alternative name extension shall be used. 1593 Further, if the only issuer identity included in the CRL is an 1594 alternative name form (e.g., an electronic mail address), then the 1595 issuer distinguished name should be empty (an empty sequence), the 1596 issuerAltName extension should be used, and the issuerAltName 1597 extension must be marked critical. If more than one issuerAltName 1598 extension appears in the CRL and the issuer distinguished name is 1599 empty, exactly one issuerAltName extension must be marked critical. 1601 The object identifier and syntax for this CRL extension are defined 1602 in Section 4.2.1.8. 1604 5.2.3 CRL Number 1606 The CRL number is a non-critical CRL extension which conveys a 1607 monotonically increacing sequence number for each CRL issued by a 1608 given CA through a specific CA X.500 Directory entry or CRL 1609 distribution point. This extension allows users to easily determine 1610 when a particular CRL supercedes another CRL. CAs conforming to this 1611 profile shall include this extension in all CRLs. 1613 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 1615 cRLNumber ::= INTEGER (0..MAX) 1617 5.2.4 Issuing Distribution Point 1619 The issuing distribution point is a critical CRL extension that 1620 identifies the CRL distribution point for a particular CRL, and it 1621 indicates whether the CRL covers revocation for end entity 1622 certificates only, CA certificates only, or a limitied set of reason 1623 codes. Since this extension is critical, all certificate users must 1624 be prepared to receive CRLs with this extension. 1626 The CRL is signed using the CA's private key. CRL Distribution 1627 Points do not have their own key pairs. If the CRL is stored in the 1628 X.500 Directory, it is stored in the Directory entry corresponding to 1629 the CRL distribution point, which may be different that the Directory 1630 entry of the CA. 1632 CRL distribution points, if used by a CA, should be partition the CRL 1633 on the basis of compromise and routine revocation. That is, the 1634 revocations with reason code keyCompromise (1) shall appear in one 1635 distribution point, and the revocations with other reason codes shall 1636 appear in another distribution point. 1638 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 1639 issuingDistributionPoint ::= SEQUENCE { 1640 distributionPoint [0] DistributionPointName OPTIONAL, 1641 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 1642 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 1643 onlySomeReasons [3] ReasonFlags OPTIONAL, 1644 indirectCRL [4] BOOLEAN DEFAULT FALSE } 1646 5.2.5 Delta CRL Indicator 1648 The delta CRL indicator is a critical CRL extension that identifies a 1649 delta-CRL. The use of delta-CRLs can significantly improve 1650 processing time for applications which store revocation information 1651 in a format other than the CRL structure. This allows changes to be 1652 added to the local database while ignoring unchanged information that 1653 is already in the local databse. 1655 When a delta-CRL is issued, the CAs shall also issue a complete CRL. 1657 The value of BaseCRLNumber identifies the CRL number of the base CRL 1658 that was used as the starting point in the generation of this delta- 1659 CRL. The delta-CRL contains the changes between the base CRL and the 1660 current CRL issued along with the delta-CRL. It is the decision of a 1661 CA as to whether to provide delta-CRLs. Again, a delta-CRL shall not 1662 be issued without a corresponding CRL. The value of CRLNumber for 1663 both the delta-CRL and the corresponding CRL shall be identical. 1665 A CRL user constructing a locally held CRL from delta-CRLs shall 1666 consider the constructed CRL incomplete and unusable if the CRLNumber 1667 of the received delta-CRL is more that one greater that the CRLnumber 1668 of the delta-CRL last processed. 1670 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 1672 deltaCRLIndicator ::= BaseCRLNumber 1674 BaseCRLNumber ::= CRLNumber 1676 5.3 CRL Entry Extensions 1678 The CRL entry extensions already defined by ANSI X9 and ISO for X.509 1679 v2 CRLs [X.509-AM] [X9.55] provide methods for associating additional 1680 attributes with CRL entries. The X.509 v2 CRL format also allows 1681 communities to define private CRL entry extensions to carry 1682 information unique to those communities. Each extension in a CRL 1683 entry may be designated as critical or non-critical. A CRL 1684 validation must fail if it encounters a critical CRL entry extension 1685 which it does not know how to process. However, an unrecognized 1686 non-critical CRL entry extension may be ignored. The following 1687 presents recommended extensions used within Internet CRL entries and 1688 standard locations for information. Communities may elect to use 1689 additional CRL entry extensions; however, caution should be exercised 1690 in adopting any critical extensions in CRL entries which might be 1691 used in a general context. 1693 All CRL entry extensions are non-critical; support for these 1694 extensions is optional for conforming CAs and applications. However, 1695 CAs that issue CRLs are strongly encouraged to include reason codes 1696 (5.3.1) whenever this information is available. 1698 5.3.1 Reason Code 1700 The reasonCode is a non-critical CRL entry extension that identifies 1701 the reason for the certificate revocation. CAs are strongly 1702 encouraged to include reason codes in CRL entries; however, the 1703 reason code CRL entry extension should be absent instead of using the 1704 unspecified (0) reasonCode value. 1706 id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 } 1708 -- reasonCode ::= { CRLReason } 1710 CRLReason ::= ENUMERATED { 1711 unspecified (0), 1712 keyCompromise (1), 1713 cACompromise (2), 1714 affiliationChanged (3), 1715 superseded (4), 1716 cessationOfOperation (5), 1717 certificateHold (6), 1718 removeFromCRL (8) } 1720 5.3.2 Hold Instruction Code 1722 The hold instruction code is a non-critical CRL entry extension that 1723 provides a registered instruction identifier which indicates the 1724 action to be taken after encountering a certificate that has been 1725 placed on hold. 1727 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 1729 holdInstructionCode ::= OBJECT IDENTIFIER 1731 The following instruction codes have been defined. Conforming applications 1732 that process this extension shall recognize the following instruction codes. 1734 holdInstruction OBJECT IDENTIFIER ::= 1735 { iso(1) member-body(2) us(840) x9-57(10040) 2 } 1737 id-holdinstruction-none OBJECT IDENTIFIER ::= {holdInstruction 1} 1738 id-holdinstruction-callissuer OBJECT IDENTIFIER ::= {holdInstruction 2} 1739 id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3} 1741 Conforming applications which encounter a id-holdinstruction- 1742 callissuer must call the certificate issuer or reject the 1743 certificate. Conforming applications which encounter a id- 1744 holdinstruction-reject ID shall reject the transaction. id- 1745 holdinstruction-none is semantically equivalent to the absence of a 1746 holdInstructionCode. Its use is strongly deprecated for the Internet 1747 PKI. 1749 <> 1752 5.3.3 Invalidity Date 1754 The invalidity date is a non-critical CRL entry extension that 1755 provides the date on which it is known or suspected that the private 1756 key was compromised or that the certificate otherwise became invalid. 1757 This date may be earlier than the revocation date in the CRL entry, 1758 but it must be later than the issue date of the previously issued 1759 CRL. Remember that the revocation date in the CRL entry specifies 1760 the date that the CA revoked the certificate. Whenever this 1761 information is available, CAs are strongly encouraged to share it 1762 with CRL users. 1764 The GeneralizedTime values included in this field shall be expressed 1765 in Greenwich Mean Time (Zulu) and omit trailing zeros in fractional 1766 seconds. GeneralizedTime shall be expressed as YYYYMMDDHHMMSSZ. 1768 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 1770 invalidityDate ::= GeneralizedTime 1772 5.4 Examples 1774 5.4.1 Empty CRL 1776 <> 1778 5.4.2 CRL with entries, no extensions 1780 <> 1782 5.4.3 CRL with extensions 1783 <> 1785 6 Certificate Path Validation 1787 Certification path validation procedures for the Internet PKI are 1788 based on Section 12.4.3 of [X.509-AM]. 1790 Certification path processing verifies the binding between the 1791 subject distinguished name and subject public key. The basic 1792 constraints and policy constraints extensions facilitate automated, 1793 self-contained implementation of certification path processing logic. 1795 The following is an outline of a procedure for validating 1796 certification paths. An implementation shall be functionally 1797 equivalent to the external behaviour resulting from this procedure. 1798 Any algorithm may be used by a particular implementation so long as 1799 it derives the correct result. 1801 The inputs to the certification path processing procedure are: 1803 (a) a set of certificates comprising a certification path; 1805 (b) a CA name and trusted public key value (or an identifier of 1806 such a key if the key is stored internally to the certification 1807 path processing module) for use in verifying the first certificate 1808 in the certification path; 1810 (c) a set of initial-policy identifiers (each comprising a 1811 sequence of policy element identifiers), which identifies one or 1812 more certificate policies, any one of which would be acceptable 1813 for the purposes of certification path processing; and 1815 (d) the current date/time (if not available internally to the 1816 certification path processing module). 1818 The outputs of the procedure are: 1820 (a) an indication of success or failure of certification path 1821 validation; 1823 (b) if validation failed, a reason for failure; and 1825 (c) if validation was successful, a (possibly empty) set of 1826 policy qualifiers obtained from CAs on the path. 1828 The procedure makes use of the following set of state variables: 1830 (a) acceptable policy set: A set of certificate policy 1831 identifiers comprising the policy or policies recognized by the 1832 public key user together with policies deemed equivalent through 1833 policy mapping; 1835 (b) constrained subtrees: A set of root names defining a set of 1836 subtrees within which all subject names in subsequent certificates 1837 in the certification path shall fall; if no restriction is in 1838 force this state variable takes the special value unbounded; and 1840 (c) excluded subtrees: A set of root names defining a set of 1841 subtrees within which no subject name in subsequent certificates 1842 in the certification path may fall; if no restriction is in force 1843 this state variable takes the special value empty. 1845 The procedure involves an initialization step, followed by a 1846 series of certificate-processing steps. The initialization step 1847 comprises: 1849 (a) Initialize the constrained subtress to unbounded; 1851 (b) Initialize the excluded subtrees indicator to empty; and 1853 (c) Initialize the acceptable policy set to the set of initial- 1854 policy identifiers. 1856 Each certificate is then processed in turn, starting with the 1857 certificate signed using the trusted CA public key which was input to 1858 this procedure. The last certificate is processed as an end-entity 1859 certificate; all other certificates (if any) are processed as CA- 1860 certificates. 1862 The following checks are applied to all certificates: 1864 (a) Check that the signature verifies, that dates are valid, that 1865 the subject and issuer names chain correctly, and that the 1866 certificate has not been revoked; 1868 If the certificate has an empty sequence in the name field, name 1869 chaining will use the critical altSubjectNames and altIssuerNames 1870 fields. If the certificate has a critical authorityInfoAccess or 1871 caInfoAccess extension, the information in that extension must be 1872 used to determine the status of the certificates. 1874 (b) If a key usage restriction extension is present in the 1875 certificate and contains a certPolicySet component, check that at 1876 least one member of the acceptable policy set appears in the 1877 field; 1878 (c) Check that the subject name or critical AltSubjectName 1879 extension is consistent with the constrained subtrees state 1880 variables; and 1882 (d) Check that the subject name or critical AltSubjectName 1883 extension is consistent with the excluded subtrees state 1884 variables. 1886 If any one of the above checks fails, the procedure terminates, 1887 returning a failure indication and an appropriate reason. If none of 1888 the above checks fail on the end-entity certificate, the procedure 1889 terminates, returning a success indication together with the set of 1890 all policy qualifier values encountered in the set of certificates. 1892 For a CA-certificate, the following constraint recording actions are 1893 then performed, in order to correctly set up the state variables for 1894 the processing of the next certificate: 1896 (a) If permittedSubtrees is present in the certificate, set the 1897 constrained subtrees state variable to the intersection of its 1898 previous value and the value indicated in the extension field. 1900 (b) If excludedSubtrees is present in the certificate, set the 1901 excluded subtrees state variable to the union of its previous 1902 value and the value indicated in the extension field. 1904 Note: It is possible to specify an extended version of the above 1905 certification path processing procedure which results in default 1906 behaviour identical to the rules of Privacy Enhanced Mail [RFC 1907 1422]. In this extended version, additional inputs to the 1908 procedure are a list of one or more Policy Certification Authority 1909 (PCA) names and an indicator of the position in the certification 1910 path where the PCA is expected. At the nominated PCA position, 1911 the CA name is compared against this list. If a recognized PCA 1912 name is found, then a constraint of SubordinateToCA is implicitly 1913 assumed for the remainder of the certification path and processing 1914 continues. If no valid PCA name is found, and if the 1915 certification path cannot be validated on the basis of identified 1916 policies, then the certification path is considered invalid. 1918 7 Algorithm Support 1920 This section describes cryptographic alogrithms which may be used 1921 with this standard. The section describes one-way hash functions and 1922 digital signature algorithms which may be used to sign certificates 1923 and CRLs, and identifies object identifiers for public keys contained 1924 in a certificate. 1926 Conforming CAs and applications are not required to support the 1927 algorithms or algorithm identifiers described in this section. 1928 However, this profile requires conforming CAs and applications to 1929 conform when they use the algorithms identified here. 1931 7.1 One-way Hash Functions 1933 This section identifies one-way hash functions for use in the 1934 Internet PKI. One-way hash functions are also called message digest 1935 algorithms. SHA-1 is the preferred one-way hash function for the 1936 Internet PKI. However, PEM uses MD2 for certificates [RFC 1422] [RFC 1937 1423]. For this reason, MD2 is included in this profile. 1939 7.1.1 MD2 One-way Hash Function 1941 MD2 was developed by Ron Rivest, but RSA Data Security has not placed 1942 the MD2 algorithm in the public domain. Rather, RSA Data Security 1943 has granted license to use MD2 for non-commerical Internet Privacy- 1944 Enhanced Mail. For this reason, MD2 may continue to be used with PEM 1945 certificates, but SHA-1 is preferred. MD2 is fully described in RFC 1946 1319 [RFC 1319]. 1948 At the Selected Areas in Cryptography '95 conference in May 1995, 1949 Rogier and Chauvaud presented an attack on MD2 that can nearly find 1950 collisions [RC95]. Collisions occur when two different messages 1951 generate the same message digest. A checksum operation in MD2 is the 1952 only remaining obstacle to the success of the attack. For this 1953 reason, the use of MD2 for new applications is discouraged. It is 1954 still reasonable to use MD2 to verify existing signatures, as the 1955 ability to find collisions in MD2 does not enable an attacker to find 1956 new messages having a previously computed hash value. 1958 << More information on the attack and its implications can be 1959 obtained from a RSA Laboratories security bulletin. These bulletins 1960 are available from . >> 1962 7.1.2 SHA-1 One-way Hash Function 1964 SHA-1 was developed by the U.S. Government. SHA-1 is fully described 1965 in FIPS 180-1 [FIPS 180-1]. 1967 SHA-1 is the one-way hash function of choice for use with both the 1968 RSA and DSA signature algorithms. 1970 7.2 Signature Algorithms 1972 Certificates and CRLs described by this standard may be signed with 1973 any public key signature algorithm. The certificate or CRL indicates 1974 the algorithm through an algorithmidentifier which appears in the 1975 signatureAlgorithm field in a Certificate or CertificateList. This 1976 algorithmidentfier is an OID and has optionally associated 1977 parameters. This section identifies algorithm identifiers and 1978 parameters that shall be used in the signatureAlgorithm field in a 1979 Certificate or CertificateList. 1981 RSA and DSA are the most popular signature algorithms used in the 1982 Internet. Signature algorithms are always used in conjunction with a 1983 one-way hash function identified in Section 7.1. 1985 The signature algorithm (and one-way hash function) used to sign a 1986 certificate or CRL is indicated by use of an algorithm identifier. 1987 An algorithm identifier is an object identifier, and may include 1988 associated parameters. This section identifies OIDS for RSA and DSA 1989 and the corresponding parameters. 1991 The data to be signed (e.g., the one-way hash function output value) 1992 is first ASN.1 encoded as an OCTET STRING and the result is encrypted 1993 (e.g., using RSA Encryption) to form the signed quantity. This 1994 signature value is then ASN.1 encoded as a BIT STRING and included in 1995 the Certificate or CertificateList (in the signature field). 1997 7.2.1 RSA Signature Algorithm 1999 A patent statement regarding the RSA algorithm can be found at the 2000 end of this profile. 2002 The RSA algorithm is named for it's inventors: Rivest, Shamir, and 2003 Adleman. The RSA signature algorithm combines either the MD2 or the 2004 SHA-1 one-way hash function with the RSA asymmetric encryption 2005 algorithm. The RSA signature algorithm with MD2 and the RSA 2006 encryption algorithm is defined in PKCS #1 [PKCS#1]. As defined in 2007 PKCS #1, the ASN.1 object identifier used to identify this signature 2008 algorithm is: 2010 md2WithRSAEncryption OBJECT IDENTIFIER ::= { 2011 iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 2012 pkcs-1(1) 2 } 2014 The RSA signature algorithm with SHA-1 and the RSA encryption 2015 algorithm is defined in by the OSI Ineroperability Workshop in []. As 2016 defined in [OIW], the ASN.1 object identifier used to identify this 2017 signature algorithm is: 2019 sha-1WithRSAEncryption OBJECT IDENTIFIER ::= { 2020 iso(1) identified-organization(3) oiw(14) 2021 secsig(3) algorithm(2) 29 } 2023 When either of these object identifiers is used within the ASN.1 type 2024 AlgorithmIdentifier, the parameters component of that type shall be 2025 the ASN.1 type NULL. 2027 When signing, the RSA algorithm generates an integer y. This value 2028 is converted to a bit string such that the most significant bit in y 2029 is the first bit in the bit string and the least significant bit in y 2030 is the last bit in the bit string. 2032 (In general this occurs in two steps. The integer y is converted to 2033 an octect string such that the first octect has the most significance 2034 and the last octect has the least significance. The octet string is 2035 converted into a bit string such that the most significant bit of the 2036 first octect shall become the first bit in the bit string, and the 2037 least significant bit of the last octect is the last bit in the BIT 2038 STRING. 2040 7.2.2 DSA Signature Algorithm 2042 A patent statement regarding the DSA can be found at the end of this 2043 profile. 2045 The Digital Signature Algorithm (DSA) is also called the Digital 2046 Signature Standard (DSS). DSA was developed by the U.S. Government, 2047 and DSA is used in conjunction with the the SHA-1 one-way hash 2048 function. DSA is fully described in FIPS 186 [FIPS 186]. The ASN.1 2049 object identifiers used to identify this signature algorithm are: 2051 id-dsa-with-sha1 ID ::= { 2052 iso(1) member-body(2) us(840) x9-57 (10040) secsig(2) 2053 x9algorithm(4) 3 } 2055 The id-dsa-with-sha1 algorithm syntax has NULL parameters. The DSA 2056 parameters in the subjectPublicKeyInfo field of the certificate of 2057 the issuer shall apply to the verification of the signature. 2059 If the subjectPublicKeyInfo AlgorithmIdentifier field has NULL 2060 parameters and the CA signed the subject certificate using DSA, then 2061 the certificate issuer's parameters apply to the subject's DSA key. 2062 If the subjectPublicKeyInfo AlgorithmIdentifier field has NULL 2063 parameters and the CA signed the subject with a signature algorithm 2064 other than DSA, then clients shall not validate the certificate. 2066 When signing, the DSA algorithm generates two values. These values 2067 are commonly referred to as r and s. To easily transfer these two 2068 values as one signature, they shall be ASN.1 encoded using the 2069 following ASN.1 structure: 2071 Dss-Sig-Value ::= SEQUENCE { 2072 r INTEGER, 2073 s INTEGER } 2075 7.3 Subject Public Key Algorithms 2077 Certificates described by this standard may convey a public key for 2078 any public key algorithm. The certificate indicates the algorithm 2079 through an algorithmidentifier. This algorithmidentfieier is an OID 2080 and optionally associated parameters. 2082 This section identifies preferred OIDs and parameters for the RSA, 2083 DSA, KEA, and Diffie-Hellman algorithms. Conforming CAs shall use 2084 the identified OIDs when issuing certificates containing public keys 2085 for these algorithms. Conforming applications supporting any of these 2086 algorithms shall, at a minimum, recognize the OID identified in this 2087 section. 2089 7.3.1 RSA Keys 2091 The object identifier rsaEncryption identifies RSA public keys. 2093 pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840) 2094 rsadsi(113549) pkcs(1) 1 } 2096 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1} 2098 The rsaEncryption object identifier is intended to be used in the 2099 algorithm field of a value of type AlgorithmIdentifier. The 2100 parameters field shall have ASN.1 type NULL for this algorithm 2101 identifier. 2103 The rsa public key shall be encoded using the ASN.1 type 2104 RSAPublicKey: 2106 RSAPublicKey ::= SEQUENCE { 2107 modulus INTEGER, -- n 2108 publicExponent INTEGER -- e 2109 } 2111 where modulus is the modulus n, and publicExponent is the public 2112 exponent e. The DER encoded RSAPublicKey is the value of the BIT 2113 STRING subjectPubliKey. 2115 This object identifier is used in public key certificates for both 2116 RSA signature keys and RSA encryption keys. The intended application 2117 for the key may be indicated in the key usage field (see Section 2118 4.2.1.3). The use of a single key for both signature and encryption 2119 purposes is not recommended, but is not forbidden. 2121 7.3.2 Diffie-Hellman Key Exchange Key 2123 This diffie-hellman object identifier supported by this standard is 2124 defined by ANSI X9.42. 2126 dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2127 US(840) ansi-x942(10046) number-type(2) 1 } 2129 DHParameter ::= SEQUENCE { 2130 prime INTEGER, -- p 2131 base INTEGER, -- g } 2133 The dhpublicnumber object identifier is intended to be used in the 2134 algorithm field of a value of type AlgorithmIdentifier. The 2135 parameters field of that type, which has the algorithm-specific 2136 syntax ANY DEFINED BY algorithm, would have ASN.1 type DHParameter 2137 for this algorithm. 2139 DHParameter ::= SEQUENCE { 2140 prime INTEGER, -- p 2141 base INTEGER, -- g } 2143 The fields of type DHParameter have the following meanings: 2145 prime is the prime p. 2147 base is the base g. 2149 The Diffie-Hellman public key (an INTEGER) is mapped to a 2150 subjectPublicKey (a BIT STRING) as follows: the most significant bit 2151 (MSB) of the INTEGER becomes the MSB of the BIT STRING; the least 2152 significant bit (LSB) of the INTEGER becomes the LSB of the BIT 2153 STRING. 2155 7.3.3 DSA Signature Keys 2157 The object identifier supported by this standard is 2159 id-dsa ID ::= { iso(1) member-body(2) us(840) x9-57(10040) 2160 secsig(2) x9algorithm(4) 1 } 2162 The id-dsa algorithm syntax includes optional parameters. These 2163 parameters are commonly referred to as p, q, and g. If the DSA 2164 algorithm parameters are absent from the subjectPublicKeyInfo 2165 AlgorithmIdentifier and the CA signed the subject certificate using 2166 DSA, then the certificate issuer's DSA parameters apply to the 2167 subject's DSA key. If the DSA algorithm parameters are absent from 2168 the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the 2169 subject certificate using a signature algorithm other than DSA, then 2170 the subject's DSA parameters are distributed by other means. The 2171 parameters are included using the following ASN.1 structure: 2173 Dss-Parms ::= SEQUENCE { 2174 p INTEGER, 2175 q INTEGER, 2176 g INTEGER } 2178 If the subjectPublicKeyInfo AlgorithmIdentifier field has NULL 2179 parameters and the CA signed the subject certificate using DSA, then 2180 the certificate issuer's parameters apply to the subject's DSA key. 2181 If the subjectPublicKeyInfo AlgorithmIdentifier field has NULL 2182 parameters and the CA signed the subject with a signature algorithm 2183 other than DSA, then clients shall not validate the certificate. 2185 When signing, DSA algorithm generates two values. These values are 2186 commonly referred to as r and s. To easily transfer these two values 2187 as one signature, they are ASN.1 encoded using the following ASN.1 2188 structure: 2190 Dss-Sig-Value ::= SEQUENCE { 2191 r INTEGER, 2192 s INTEGER } 2194 The encoded signature is conveyed as the value of the BIT STRING 2195 signature in a Certificate or CertificateList. 2197 The DSA public key shall be ASN.1 encoded as an INTEGER; this 2198 encoding shall be used as the contents (i.e., the value) of the 2199 subjectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo 2200 data element. 2202 DSAPublicKey ::= INTEGER -- public key Y 2204 7.3.4 Key Exchange Algorithm (KEA) 2206 The Key Exchange Algorithm (KEA) is a classified algorithm for 2207 exchanging keys. A KEA "pairwise key" may be generated between two 2208 users if their KEA public keys were generated with the same KEA 2209 parameters. The KEA parameters are not included in a certificate; 2210 instead a "domain identifier" is supplied in the parameters field. 2212 When the subjectPublicKeyInfo field contains a KEA key, the algorithm 2213 identifier and parameters shall be as defined in [sdn.701r]: 2215 id-keyEncryptionAlgorithm OBJECT IDENTIFIER ::= 2216 { 2 16 840 1 101 2 1 1 22 } 2218 KEA-Parms-Id ::= OCTET STRING 2220 The Kea-Parms-Id shall always appear when the subjectPublicKeyInfo 2221 field algorithm identifier is id-keyEncryptionAlgorithm. Kea-Parms-Id 2222 is the "domain identifier" and is ten octets in length. If the Kea- 2223 Parms-Id of two KEA keys are equivalent, the subjects possess the 2224 same KEA parameter values and may exchange keys. 2226 <> 2228 8. ASN.1 Structures and OIDs 2230 PKIX1 DEFINITIONS ::= 2232 BEGIN 2234 -- need ASN.1 for: 2235 -- AlgorithmIdentifier 2236 -- ORAddress 2238 -- attribute data types -- 2240 Attribute ::= SEQUENCE { 2241 type AttributeValue, 2242 values SET OF AttributeValue 2243 -- at least one value is required -- } 2245 AttributeType ::= OBJECT IDENTIFIER 2247 AttributeValue ::= ANY 2249 AttributeTypeAndValue ::= SEQUENCE { 2250 type AttributeValue, 2251 value AttributeValue } 2253 AttributeValueAssertion ::= SEQUENCE {AttributeType, AttributeValue} 2255 -- naming data types -- 2257 Name ::= CHOICE { -- only one possibility for now -- 2258 rdnSequence RDNSequence } 2260 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 2262 DistinguishedName ::= RDNSequence 2264 RelativeDistinguishedName ::= SET SIZE (1 .. MAX) OF AttributeTypeAndValue 2266 -- Directory string type -- 2268 DirectoryString ::= CHOICE { 2269 teletexString TeletexString (SIZE (1..maxSize)), 2270 printableString PrintableString (SIZE (1..maxSize)), 2271 universalString ANY -- the '93 ASN.1 type UniversalString 2272 } 2274 -- basic stuff starts here 2276 Certificate ::= SEQUENCE { 2277 tbsCertificate TBSCertificate, 2278 signatureAlgorithm AlgorithmIdentifier, 2279 signature BIT STRING } 2281 TBSCertificate ::= SEQUENCE { 2282 version [0] Version DEFAULT v1, 2283 serialNumber CertificateSerialNumber, 2284 signature AlgorithmIdentifier, 2285 issuer Name, 2286 validity Validity, 2287 subject Name, 2288 subjectPublicKeyInfo SubjectPublicKeyInfo, 2289 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 2290 -- If present, version must be v2 or v3 2291 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 2292 -- If present, version must be v2 or v3 2293 extensions [3] Extensions OPTIONAL 2294 -- If present, version must be v3 2295 } 2297 Version ::= INTEGER { v1(0), v2(1), v3(2) } 2299 CertificateSerialNumber ::= INTEGER 2301 Validity ::= SEQUENCE { 2302 notBefore CertificateValidityDate, 2303 notAfter CertificateValidityDate } 2305 CertificateValidityDate ::= CHOICE { 2306 utcTime UTCTime, 2307 generalTime GeneralizedTime } 2309 UniqueIdentifier ::= BIT STRING 2311 SubjectPublicKeyInfo ::= SEQUENCE { 2312 algorithm AlgorithmIdentifier, 2313 subjectPublicKey BIT STRING } 2315 Extensions ::= SEQUENCE OF Extension 2317 Extension ::= SEQUENCE { 2318 extnID OBJECT IDENTIFIER, 2319 critical BOOLEAN DEFAULT FALSE, 2320 extnValue OCTET STRING } 2322 -- Extension ::= { {id-ce 15}, ... , keyUsage } 2324 ID ::= OBJECT IDENTIFIER 2325 joint-iso-ccitt ID ::= { 2 } 2326 ds ID ::= {joint-iso-ccitt 5} 2327 certificateExtension ID ::= {ds 29} 2328 -- id-ce ID ::= certificateExtension 2329 id-ce ID ::= {ds 29} 2331 AuthorityKeyIdentifier ::= SEQUENCE { 2332 keyIdentifier [0] KeyIdentifier OPTIONAL, 2333 authorityCertIssuer [1] GeneralNames OPTIONAL, 2334 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL 2335 } 2336 ( WITH COMPONENTS {..., authorityCertIssuer PRESENT, 2337 authorityCertSerialNumber PRESENT} | 2338 WITH COMPONENTS {..., authorityCertIssuer ABSENT, 2339 authorityCertSerialNumber ABSENT} ) 2341 -- authorityKeyIdentifier ::= AuthorityKeyIdentifier 2343 KeyIdentifier ::= OCTET STRING 2345 -- subjectKeyIdentifier ::= KeyIdentifier 2347 KeyUsage ::= BIT STRING { 2348 digitalSignature (0), 2349 nonRepudiation (1), 2350 keyEncipherment (2), 2351 dataEncipherment (3), 2352 keyAgreement (4), 2353 keyCertSign (5), 2354 cRLSign (6) } 2356 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 2358 PrivateKeyUsagePeriod ::= SEQUENCE { 2359 notBefore [0] GeneralizedTime OPTIONAL, 2360 notAfter [1] GeneralizedTime OPTIONAL } 2361 ( WITH COMPONENTS {..., notBefore PRESENT} | 2362 WITH COMPONENTS {..., notAfter PRESENT} ) 2364 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 2366 CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 2368 PolicyInformation ::= SEQUENCE { 2369 policyIdentifier CertPolicyId, 2370 policyQualifiers SEQUENCE SIZE (1..MAX) OF 2371 PolicyQualifierInfo OPTIONAL } 2373 CertPolicyId ::= OBJECT IDENTIFIER 2375 -- PolicyQualifierInfo ::= SEQUENCE { 2376 -- policyQualifierId CERT-POLICY-QUALIFIER.&id 2377 -- ({SupportedPolicyQualifiers}), 2378 -- qualifier CERT-POLICY-QUALIFIER.&Qualifier 2379 -- 2380 -- ({SupportedPolicyQualifiers}{@policyQualifierId}) 2381 -- OPTIONAL } 2383 -- SupportedPolicyQualifiers CERT-POLICY-QUALIFIER ::= { ... } 2385 PolicyQualifierInfo ::= SEQUENCE { 2386 policyQualifierId PolicyQualifierId, 2387 qualifier ANY DEFINED BY policyQualifierId } 2389 PolicyQualifierId ::= ENUMERATED { 2390 qualId1 (1), qualId2 (2), qualId3 (3), qualId4 (4), qualId5 ( 5 ) } 2392 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 2394 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 2395 issuerDomainPolicy CertPolicyId, 2396 subjectDomainPolicy CertPolicyId } 2398 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 2400 SubjectAltName ::= GeneralNames 2401 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 2403 GeneralName ::= CHOICE { 2404 otherName [0] ANY, 2405 rfc822Name [1] IA5String, 2406 dNSName [2] IA5String, 2407 x400Address [3] ORAddress, 2408 directoryName [4] Name, 2409 ediPartyName [5] EDIPartyName, 2410 uniformResourceIdentifier [6] IA5String, 2411 iPAddress [7] OCTET STRING, 2412 registeredID [8] OBJECT IDENTIFIER } 2414 -- OTHER-NAME ::= TYPE-IDENTIFIER note: not supported in '88 ASN.1 2415 -- substituted ANY where used [GeneralName otherName] 2417 EDIPartyName ::= SEQUENCE { 2418 nameAssigner [0] DirectoryString OPTIONAL, 2419 partyName [1] DirectoryString } 2421 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 2423 IssuerAltName ::= GeneralNames 2425 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 2427 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 2429 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 2431 BasicConstraints ::= SEQUENCE { 2432 cA BOOLEAN DEFAULT FALSE, 2433 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 2435 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 2437 NameConstraints ::= SEQUENCE { 2438 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 2439 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 2441 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 2443 GeneralSubtree ::= SEQUENCE { 2444 base GeneralName, 2445 minimum [0] BaseDistance DEFAULT 0, 2446 maximum [1] BaseDistance OPTIONAL } 2448 BaseDistance ::= INTEGER (0..MAX) 2449 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 34 } 2451 PolicyConstraints ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 2452 policySet [0] CertPolicySet OPTIONAL, 2453 requireExplicitPolicy [1] SkipCerts OPTIONAL, 2454 inhibitPolicyMapping [2] SkipCerts OPTIONAL } 2456 SkipCerts ::= INTEGER (0..MAX) 2458 CertPolicySet ::= SEQUENCE SIZE (1..MAX) OF CertPolicyId 2460 -- cRLDistributionPoints CRLDistPointsSyntax ::= 2461 -- SEQUENCE SIZE (1..MAX) OF DistributionPoint 2463 CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 2465 DistributionPoint ::= SEQUENCE { 2466 distributionPoint [0] DistributionPointName OPTIONAL, 2467 reasons [1] ReasonFlags OPTIONAL, 2468 cRLIssuer [2] GeneralNames OPTIONAL } 2470 DistributionPointName ::= CHOICE { 2471 fullName [0] GeneralNames, 2472 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 2474 ReasonFlags ::= BIT STRING { 2475 unused (0), 2476 keyCompromise (1), 2477 cACompromise (2), 2478 affiliationChanged (3), 2479 superseded (4), 2480 cessationOfOperation (5), 2481 certificateHold (6) } 2483 pkix OBJECT IDENTIFIER ::= { 1 3 6 1 5 3 } 2485 -- Object identifiers for ftp, http, smtp and ldap protocols 2487 applTCPProto OBJECT IDENTIFIER ::= { 1 3 6 1 2 1 27 4 } 2489 ftpID OBJECT-IDENTIFIER ::= {applTCPProtoID 21} 2490 httpID OBJECT-IDENTIFIER ::= {applTCPProtoID 80} 2491 smtpID OBJECT-IDENTIFIER ::= {applTCPProtoID 25} 2492 ldapID OBJECT-IDENTIFIER ::= {applTCPProtoID 389} 2494 -- Object identifier for the X.500 directory access protocol 2496 dap OBJECT-IDENTIFIER ::= { 2 5 3 1 } 2497 id-pkix-subjectInfoAccess OBJECT IDENTIFIER ::= { pkix 1 } 2499 AccessDescription ::= SEQUENCE { 2500 accessMethod OBJECT IDENTIFIER, 2501 accessLocation GeneralName } 2503 --subjectInfoAccess SubjectInfoAccessSyntax ::= 2504 -- SEQUENCE SIZE (1..MAX) OF AccessDescription 2505 SubjectInfoAccessSyntax ::= 2506 SEQUENCE OF AccessDescription 2508 id-pkix-authorityInfoAccess OBJECT IDENTIFIER ::= { pkix 2 } 2510 AuthorityInfoAccessSyntax ::= SEQUENCE { 2511 certStatus [0] SEQUENCE OF AccessDescription OPTIONAL, 2512 certRetrieval [1] SEQUENCE OF AccessDescription OPTIONAL, 2513 caPolicy [2] SEQUENCE OF AccessDescription OPTIONAL, 2514 caCerts [3] SEQUENCE OF AccessDescription OPTIONAL } 2516 id-pkix-caInfoAccess OBJECT-IDENTIFIER ::= { pkix 3 } 2518 -- caInfoAccess ::= { 2519 -- AuthorityInfoAccessSyntax } 2521 -- CRL structures 2523 CertificateList ::= SEQUENCE { 2524 tbsCertList TBSCertList, 2525 signatureAlgorithm AlgorithmIdentifier, 2526 signature BIT STRING } 2528 TBSCertList ::= SEQUENCE { 2529 version Version OPTIONAL, 2530 -- if present, must be v2 2531 signature AlgorithmIdentifier, 2532 issuer Name, 2533 thisUpdate ChoiceOfTime, 2534 nextUpdate ChoiceOfTime, 2535 revokedCertificates SEQUENCE OF SEQUENCE { 2536 userCertificate CertificateSerialNumber, 2537 revocationDate ChoiceOfTime, 2538 crlEntryExtensions Extensions OPTIONAL 2539 -- if present, must be v2 2540 } OPTIONAL, 2541 crlExtensions [0] Extensions OPTIONAL 2542 -- if present, must be v2 2543 } 2545 Version ::= INTEGER { v1(0), v2(1), v3(2) } 2547 AlgorithmIdentifier ::= SEQUENCE { 2548 algorithm OBJECT IDENTIFIER, 2549 parameters ANY DEFINED BY algorithm OPTIONAL } 2550 -- contains a value of the type 2551 -- registered for use with the 2552 -- algorithm object identifier value 2554 ChoiceOfTime ::= CHOICE { 2555 utcTime UTCTime, 2556 generalTime GeneralizedTime } 2558 CertificateSerialNumber ::= INTEGER 2560 Extensions ::= SEQUENCE OF Extension 2562 Extension ::= SEQUENCE { 2563 extnId OBJECT IDENTIFIER, 2564 critical BOOLEAN DEFAULT FALSE, 2565 extnValue OCTET STRING } 2566 -- contains a DER encoding of a value 2567 -- of the type registered for use with 2568 -- the extnId object identifier value 2570 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 2572 CRLNumber ::= INTEGER (0..MAX) 2574 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 2576 IssuingDistributionPoint ::= SEQUENCE { 2577 distributionPoint [0] DistributionPointName OPTIONAL, 2578 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 2579 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 2580 onlySomeReasons [3] ReasonFlags OPTIONAL, 2581 indirectCRL [4] BOOLEAN DEFAULT FALSE } 2583 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 2585 -- deltaCRLIndicator ::= BaseCRLNumber 2587 BaseCRLNumber ::= CRLNumber 2589 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 2591 -- reasonCode EXTENSION ::= { 2592 -- SYNTAX CRLReason 2593 -- IDENTIFIED BY { id-ce 21 } } 2595 CRLReason ::= ENUMERATED { 2596 unspecified (0), 2597 keyCompromise (1), 2598 cACompromise (2), 2599 affiliationChanged (3), 2600 superseded (4), 2601 cessationOfOperation (5), 2602 certificateHold (6), 2603 removeFromCRL (8) } 2605 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 2607 HoldInstructionCode ::= OBJECT IDENTIFIER 2609 member-body ID ::= { iso 2 } 2610 us ID ::= { member-body 840 } 2611 x9cm ID ::= { us 10040 } 2612 holdInstruction ID ::= {x9cm 2} 2614 id-holdinstruction-none ID ::= {holdInstruction 1} 2615 id-holdinstruction-callissuer ID ::= {holdInstruction 2} 2616 id-holdinstruction-reject ID ::= {holdInstruction 3} 2618 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 2620 InvalidityDate ::= GeneralizedTime 2622 -- Algorithm strustures 2624 md2WithRSAEncryption OBJECT IDENTIFIER ::= { 2625 iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 2626 pkcs-1(1) 2 } 2628 sha-1WithRSAEncryption OBJECT IDENTIFIER ::= { 2629 iso(1) identified-organization(3) oiw(14) secsig(3) 2630 algorithm(2) 29 } 2632 id-dsa-with-sha1 ID ::= { 2633 iso(1) member-body(2) us(840) x9-57 (10040) secsig(2) 2634 x9algorithm(4) 3 } 2636 Dss-Sig-Value ::= SEQUENCE { 2637 r INTEGER, 2638 s INTEGER } 2640 pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840) 2641 rsadsi(113549) pkcs(1) 1 } 2643 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1} 2645 dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2646 US(840) ansi-x942(10046) 1 } 2648 DHParameter ::= SEQUENCE { 2649 prime INTEGER, -- p 2650 base INTEGER -- g 2651 } 2653 id-dsa ID ::= { iso(1) member-body(2) us(840) x9-57(10040) 2654 secsig(2) x9algorithm(4) 1 } 2656 Dss-Parms ::= SEQUENCE { 2657 p INTEGER, 2658 q INTEGER, 2659 g INTEGER } 2661 Dss-Sig-Value ::= SEQUENCE { 2662 r INTEGER, 2663 s INTEGER } 2665 id-keyEncryptionAlgorithm OBJECT IDENTIFIER ::= 2666 { 2 16 840 1 101 2 1 1 22 } 2668 KEA-Parms-Id ::= OCTET STRING 2670 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 2671 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 2672 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 2673 id-pkix-policy-CPS OBJECT IDENTIFIER ::= { pkix 4 } 2675 CPSuri ::= IA5String 2677 id-pkix-policy-userNotice OBJECT IDENTIFIER ::= { pkix 5 } 2679 UserNotice ::= CHOICE { 2680 ia5String IA5String, 2681 bnpString ANY -- defined as BMPString in '93 ASN.1 2682 } 2684 END 2686 References 2688 [X9.57] ANSI X9.57 2690 [FIPS 180-1] Federal Information Processing Standards Publication 2691 (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995. 2692 [Supersedes FIPS PUB 180 dated 11 May 1993.] 2694 [FIPS 186] Federal Information Processing Standards Publication 2695 (FIPS PUB) 186, Digital Signature Standard, 18 May 1994. 2697 [PKCS#1] PKCS #1: RSA Encryption Standard, Version 1.4, RSA Data 2698 Security, Inc., 3 June 1991. 2700 [RC95] Rogier, N. and Chauvaud, P., "The compression function of 2701 MD2 is not collision free," Presented at Selected Areas in 2702 Cryptography '95, Carleton University, Ottawa, Canada, 2703 18-19 May 1995. 2705 [RFC 1319] Kaliski, B., "The MD2 Message-Digest Algorithm," RFC 1319, 2706 RSA Laboratories, April 1992. 2708 [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic 2709 Mail: Part II: Certificate-Based Key Management," RFC 2710 1422, BBN Communications, February 1993. 2712 [RFC 1423] Balenson, D., "Privacy Enhancement for Internet Electronic 2713 Mail: Part III: Algorithms, Modes, and Identifiers," 2714 RFC 1423, Trusted Information Systems, February 1993. 2716 [RFC 1959] T. Howes, M. Smith, "An LDAP URL Format", RFC 1959, 2717 June 1996. 2719 [SDN.701R] SDN.701, "Message Security Protocol", Revision 4.0 2720 1996-06-07 with "Corrections to Message Security Protocol, 2721 SDN.701, Rev 4.0, 96-06-07." August 30, 1996. 2723 [X.208] << Do we want to reference the 1988 or 1993 version? >> 2725 [X.509-AM] << Need final reference >> 2727 [X9.55] << Need final reference >> 2729 Patent Statements 2731 The Internet PKI relies on the use of patented public key technology. 2732 The Internet Standards Process as defined in RFC 1310 requires a 2733 written statement from the Patent holder that a license will be made 2734 available to applicants under reasonable terms and conditions prior 2735 to approving a specification as a Proposed, Draft or Internet 2736 Standard. 2738 Patent statements for DSA, RSA, and Diffie-Hellman follow. These 2739 statements have been supplied by the patent holders, not the authors 2740 of this profile. 2742 Digital Signature Algorithm (DSA) 2744 The U.S. Government holds patent 5,231,668 on the Digital 2745 Signature Algorithm (DSA), which has been incorporated into 2746 Federal Information Processing Standard (FIPS) 186. The patent 2747 was issued on July 27, 1993. 2749 The National Institute of Standards and Technology (NIST) has a 2750 long tradition of supplying U.S. Government-developed techniques 2751 to committees and working groups for inclusion into standards on a 2752 royalty-free basis. NIST has made the DSA patent available 2753 royalty-free to users worldwide. 2755 Regarding patent infringement, FIPS 186 summarizes our position; 2756 the Department of Commerce is not aware of any patents that would 2757 be infringed by the DSA. Questions regarding this matter may be 2758 directed to the Deputy Chief Counsel for NIST. 2760 RSA Signature and Encryption 2762 << Now that PKP has dissolved, a revised patent statement for RSA 2763 from RSADSI is needed. >> 2765 Diffie-Hellman Key Agreement 2767 << Now that PKP has dissolved, a revised patent statement for 2768 Diffie-Hellman from Cylink is needed. >> 2770 Obsolete PKP Patent Statement 2772 << This statement is included here until a replacement from RSADSI 2773 and Cylink can be obtained. >> 2775 The Massachusetts Institute of Technology and the Board of 2776 Trustees of the Leland Stanford Junior University have granted 2777 Public Key Partners (PKP) exclusive sub-licensing rights to the 2778 following patents issued in the United States, and all of their 2779 corresponding foreign patents: 2781 Cryptographic Apparatus and Method 2782 ("Diffie-Hellman")......................... No. 4,200,770 2783 Public Key Cryptographic Apparatus 2784 and Method ("Hellman-Merkle").............. No. 4,218,582 2786 Cryptographic Communications System and 2787 Method ("RSA")............................. No. 4,405,829 2789 Exponential Cryptographic Apparatus 2790 and Method ("Hellman-Pohlig").............. No. 4,424,414 2792 These patents are stated by PKP to cover all known methods of 2793 practicing the art of Public Key encryption, including the 2794 variations collectively known as El Gamal. 2796 Public Key Partners has provided written assurance to the Internet 2797 Society that parties will be able to obtain, under reasonable, 2798 nondiscriminatory terms, the right to use the technology covered 2799 by these patents. This assurance is documented in RFC 1170 titled 2800 "Public Key Standards and Licenses". A copy of the written 2801 assurance dated April 20, 1990, may be obtained from the Internet 2802 Assigned Number Authority (IANA). 2804 The Internet Society, Internet Architecture Board, Internet 2805 Engineering Steering Group and the Corporation for National 2806 Research Initiatives take no position on the validity or scope of 2807 the patents and patent applications, nor on the appropriateness of 2808 the terms of the assurance. The Internet Society and other groups 2809 mentioned above have not made any determination as to any other 2810 intellectual property rights which may apply to the practice of 2811 this standard. Any further consideration of these matters is the 2812 user's own responsibility. 2814 Security Considerations 2816 This entire memo is about security mechanisms. 2817 Author Addresses: 2819 Russell Housley 2820 SPYRUS 2821 PO Box 1198 2822 Herndon, VA 20172 2823 USA 2824 housley@spyrus.com 2826 Warwick Ford 2827 VeriSign, Inc. 2828 One Alewife Center 2829 Cambridge, MA 02140 2830 wford@verisign.com 2831 Tim Polk 2832 NIST 2833 Building 820, Room 426 2834 Gaithersburg, MD 20899 2835 wpolk@nist.gov 2837 David Solo 2838 BBN 2839 150 CambridgePark Drive 2840 Cambridge, MA 02140 2841 USA 2842 solo@bbn.com