idnits 2.17.1 draft-ietf-pkix-ipki-part1-00.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-24) 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 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. ** There are 159 instances of too long lines in the document, the longest one being 45 characters in excess of 72. ** 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 396: '... issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,...' RFC 2119 keyword, line 398: '... subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,...' RFC 2119 keyword, line 400: '... extensions [3] Extensions OPTIONAL...' RFC 2119 keyword, line 610: '...DEFINED BY policyElementId OPTIONAL }...' RFC 2119 keyword, line 648: '...fier KeyIdentifier OPTIONAL,...' (24 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 113 has weird spacing: '...ate the certi...' == Line 232 has weird spacing: '...ication path ...' == Line 331 has weird spacing: '...issuing a cer...' == Line 338 has weird spacing: '...: This is th...' == Line 560 has weird spacing: '...sion of the X...' == (1 more instance...) -- 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 (February 1996) is 10296 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) -- Missing reference section? 'RFC 1422' on line 1287 looks like a reference -- Missing reference section? 'ISO TC' on line 189 looks like a reference -- Missing reference section? '0' on line 1041 looks like a reference -- Missing reference section? '1' on line 1042 looks like a reference -- Missing reference section? '2' on line 1043 looks like a reference -- Missing reference section? '3' on line 1044 looks like a reference -- Missing reference section? '4' on line 1045 looks like a reference -- Missing reference section? '5' on line 1046 looks like a reference -- Missing reference section? '6' on line 1047 looks like a reference -- Missing reference section? '7' on line 990 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 12 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 (Nortel) 4 D. Solo (BBN) 5 expires in six months February 1996 7 Internet Public Key Infrastructure 9 Part I: X.509 Certificate and CRL Profile 11 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 To learn the current status of any Internet-Draft, please check the 26 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 27 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au Pacific Rim), ds.internic.net (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 Abstract 33 This is the second draft of the Internet Public Key Infrastructure 34 X.509 Certificate and CRL Profile. This document was sections 1 35 through 5 and section 11 of draft-ietf-pkix-ipki-00.txt. That 36 original document has been divided into four parts; it was simply too 37 big. This is the first part. Many changes are the result of 38 discussion at the Dallas IETF in December 1995 and discussion on the 39 ietf-pkix@tandem.com mail list. The intent of this document is to 40 generate further productive discussion and build concensus. 42 1 Executive Summary 44 << Write this last. >> 46 2 Requirements and Assumptions 48 Goal is to develop a profile and associated management structure to 49 facilitate the adoption/use of X.509 certificates within Internet 50 applications for those communities wishing to make use of X.509 51 technology. Such applications may include WWW, electronic mail, user 52 authentication, electronic payment systems, IPSEC, as well as others. 53 In order to relieve some of the obstacles to using X.509 54 certificates, this document defines a profile to promote the 55 development of certificate management systems; development of 56 application tools; and interoperability determined by policy, as 57 opposed to syntax. 59 Some communities will need to supplement, or possibly replace, this 60 profile in order to meet the requirements of specialized application 61 domains or environments with additional authorization, assurance, or 62 operational requirements. However, for basic applications, common 63 representations of frequently used attributes are defined so that 64 application developers can obtain necessary information without 65 regard to the issuer of a particular certificate or certificate 66 revocation list (CRL). 68 As supplemental authorization and attribute management tools emerge, 69 such as attribute certificates, it may be appropriate to limit the 70 authenticated attributes that are included in a certificate. These 71 other management tools may be more appropriate method of conveying 72 many authenticated attributes. 74 2.1 Communication and Topology 76 The users of certificates will operate in a wide range of 77 environments with respect to their communication topology, especially 78 users of secure electronic mail. This profile supports users without 79 high bandwidth, real-time IP connectivity, or high connection 80 availablity. In addition, the profile allows for the presence of 81 firewall or other filtered communication. 83 2.2 Acceptability Criteria 85 The goal of the Internet Public Key Infrstructure (PKI) is to meet 86 the needs of deterministic, automated identification, authentication, 87 access control, and authorization functions. Support for these 88 services determines the attributes contained in the certificate as 89 well as the ancillary control information in the certificate such as 90 policy data and certification path constraints. 92 2.3 User Expectations 94 Users of the Internet PKI are people and processes who use client 95 software and are the subjects named in certificates. These uses 96 include readers and writers of electronic mail, the clients for WWW 97 browsers, and the key manager for IPSEC within a router. This 98 profile recognizes the limitations of the platforms these users 99 employ and the sophistication/attentiveness of the users themselves. 100 This manifests itself in minimal user configuration responsibility 101 (e.g., root keys, rules), explicit platform usage constraints within 102 the certificate, certification path constraints which shield the user 103 from many malicious actions, and applications which sensibly automate 104 validation functions. 106 2.4 Administrator Expectations 108 As with users, the Internet PKI profile is structured to support the 109 individuals who generally operate Certification Authorities (CAs). 110 Providing administrators with unbounded choices increases the chances 111 that a subtle CA administrator mistake will result in broad 112 compromise. Also, unbounded choices greatly complicates the software 113 that must process and validate the certificates created by the CA. 115 3 Overview of Approach 117 Following is a simplified view of the architectural model assumed by 118 the PKIX specifications. 120 +---+ 121 | C | +------------+ 122 | e | <-------------------->| End entity | 123 | r | Operational +------------+ 124 | t | transactions ^ 125 | | and management | Management 126 | / | transactions | transactions 127 | | | 128 | C | PKI users v 129 | R | -------+-------+--------+------ 130 | L | PKI management ^ ^ 131 | | entities | | 132 | | v | 133 | R | +------+ | 134 | e | <-------------- | RA | <-----+ | 135 | p | certificate | | | | 136 | o | publish +------+ | | 137 | s | | | 138 | i | v v 139 | t | +------------+ 140 | o | <--------------------------| CA | 141 | r | certificate publish +------------+ 142 | y | CRL publish ^ 143 | | | 144 +---+ | Management 145 | transactions 146 v 147 +------+ 148 | CA | 149 +------+ 151 Figure 1 - PKI Entities 153 The components in this model are: 155 end entity: user of PKI certificates and/or end user system that 156 the PKI certifies; 157 CA: certification authority; 158 RA: registration authority, i.e., an optional system to 159 which a CA delegates certain manaagement functions; 160 repository: a system or collection of distributed systems that 161 store certificates and CRLs and serves as a means of 162 distributing these certificates and CRLs to end entities. 164 3.1 X.509 Version 3 Certificate 166 Application of public key technology requires the user of a public key to be confident that the public key 167 belongs to the correct remote subject (person or system) with which an encryption or digital signature 168 mechanism will be used. This confidence is obtained through the use of public key certificates, which are 169 data structures that bind public key values to subject identities. The binding is achieved by having a 170 trusted certification authority (CA) digitally sign each certificate. A certificate has a limited valid lifetime 171 which is indicated in its signed contents. Because a certificate's signature and timeliness can be 172 independently checked by a certificate-using client, certificates can be distributed via untrusted 173 communications and server systems, and can be cached in unsecured storage in certificate-using systems. 175 The standard known as ITU-T X.509 (formerly CCITT X.509) or ISO/IEC 9594-8, which was first 176 published in 1988 as part of the X.500 Directory recommendations, defines a standard certificate format. 177 The certificate format in the 1988 standard is called the version 1 (v1) format. When X.500 was revised 178 in 1993, two more fields were added, resulting in the version 2 (v2) format. These two fields are used to 179 support directory access control. 181 The Internet Privacy Enhanced Mail (PEM) proposals, published in 1993, include specifications for a 182 public key infrastructure based on X.509 v1 certificates [RFC 1422]. The experience gained in 183 attempts to deploy RFC 1422 made it clear that the v1 and v2 certificate formats are deficient in several 184 respects. Most importantly, more fields were needed to carry information which PEM design and 185 implementation experience has proven necessary. In response to these new requirements, ISO/IEC and 186 ANSI X9 developed the X.509 version 3 (v3) certificate format. The v3 format extends the v2 format by 187 adding provision for additional extension fields. Particular extension field types may be specified in 188 standards or may be defined and registered by any organization or community. In August 1995, 189 standardization of the basic v3 format was completed [ISO TC]. 191 ISO/IEC and ANSI X9 have also developed a set of standard extensions for use in the v3 extensions field 192 [ISO DAM, ANSI X9.55]. These extensions can convey such data as additional subject identification 193 information, key attribute information, policy information, and certification path constraints. 195 However, the ISO/IEC and ANSI standard extensions are very broad in their applicability. In order to 196 develop interoperable implementations of X.509 v3 systems for Internet use, it is necessary to specify 197 a profile for use of the X.509 v3 extensions tailored for the Internet. It is one goal of this document to 198 specify a profile for Internet WWW, electronic mail, and IPSEC applications. Environments with 199 additional requirements may build on this profile or may replace it. 201 3.2 Certification Paths and Trust 203 A user of a security service requiring knowledge of a public key generally needs to obtain and validate a 204 certificate containing the required public key. If the public-key user does not already hold an assured copy 205 of the public key of the CA that signed the certificate, then it might need an additional certificate to obtain 206 that public key. In general, a chain of multiple certificates may be needed, comprising a certificate of the 207 public key owner (the end entity) signed by one CA, and zero or more additional certificates of CAs 208 signed by other CAs. Such chains, called certification paths, are required because a public key user is 209 only initialized with a limited number (often one) of assured CA public keys. 211 There are different ways in which CAs might be configured in order for public key users to be able to find 212 certification paths. For PEM, RFC 1422 defined a rigid hierarchical structure of CAs. There are three 213 types of PEM certification authority: 215 (a) Internet Policy Registration Authority (IPRA): This authority, operated under the auspices of the 216 Internet Society, acts as the root of the PEM certification hierarchy at level 1. It issues certificates only for 217 the next level of authorities, PCAs. All certification paths start with the IPRA. 219 (b) Policy Certification Authorities (PCAs): PCAs are at level 2 of the hierarchy, each PCA being 220 certified by the IPRA. A PCA must establish and publish a statement of its policy with respect to 221 certifying users or subordinate certification authorities. Distinct PCAs aim to satisfy different user needs. 222 For example, one PCA (an organizational PCA) might support the general electronic mail needs of 223 commercial organizations, and another PCA (a high-assurance PCA) might have a more stringent policy 224 designed for satisfying legally binding signature requirements. 226 (c) Certification Authorities (CAs): CAs are at level 3 of the hierarchy and can also be at lower levels. 227 Those at level 3 are certified by PCAs. CAs represent, for example, particular organizations, particular 228 organizational units (e.g., departments, groups, sections), or particular geographical areas. 230 RFC 1422 furthermore has a name subordination rule which requires that a CA can only issue certificates 231 for entities whose names are subordinate (in the X.500 naming tree) to the name of the CA itself. The 232 trust associated with a PEM certification path is implied by the PCA name. The name subordination rule 233 ensures that CAs below the PCA are sensibly constrained as to the set of subordinate entities they can 234 certify (e.g., a CA for an organization can only certify entities in that organization's name tree). 235 Certificate user systems are able to mechanically check that the name subordination rule has been 236 followed. 238 The RFC 1422 CA hierarchical model has been found to have several deficiencies, including: 240 (a) The pure top-down hierarchy, with all ertification paths starting from the root, is too restrictive for 241 many purposes. For some applications, verification of certification paths should start with a public key of 242 a CA in a user's own domain, rather than mandating that verification commence at the top of a hierarchy. 243 In many environments, the local domain is often the most trusted. Also, initialization and key-pair-update 244 operations can be more effectively conducted between an end entity and a local management system. 246 (b) The name subordination rule introduces undesirable constraints upon the X.500 naming system an 247 organization may use. 249 (c) Use of the PCA concept requires knowledge of individual PCAs to be built into certificate chain 250 verification logic. In the particular case of Internet mail, this is not a major problem -- the PCA name can 251 always be displayed to the human user who can make a decision as to what trust to imply from a particular 252 chain. However, in many commercial applications, such as electronic commerce or EDI, operator 253 intervention to make policy decisions is impractical. The process needs to be automated to a much higher 254 degree. In fact, the full process of certificate chain processing needs to be implementable in trusted 255 software. 257 Because of the above shortcomings, it is proposed that more flexible CA structures than the RFC 1422 258 hierarchy be supported by the PKIX specifications. In fact, the main reason for the structural restrictions 259 imposed by RFC 1422 was the restricted certificate format provided with X.509 v1. With X.509 v3, most 260 of the requirements addressed by RFC 1422 can be addressed using certificate extensions, without a need 261 to restrict the CA structures used. In particular, the certificate extensions relating to certificate policies 262 obviate the need for PCAs and the constraint extensions obviate the need for the name subordination rule. 264 3.3 Revocation 266 When a certificate is issued, it is expected to be in use for its entire validity period. However, various 267 circumstances may cause a certificate to become invalid prior to the expiration of the validity period. 268 Such circumstances might include change of name, change of association between subject and CA (e.g., 269 an employee terminates employment with an organization), and compromise or suspected compromise of 270 the corresponding private key. Under such circumstances, the CA needs to revoke the certificate. 272 X.509 defines one method of certificate revocation. This method involves each CA periodically issuing a 273 signed data structure called a certificate revocation list (CRL). A CRL is a time stamped list identifying 274 revoked certificates which is signed by a CA and made freely available in a public repository. Each 275 revoked certificate is identified in a CRL by its certificate serial number. When a certificate-using system 276 uses a certificate (e.g., for verifying a remote user's digital signature), that system not only checks the 277 certificate signature and validity but also acquires a suitably-recent CRL and checks that the certificate 278 serial number is not on that CRL. The meaning of "suitably-recent" may vary with local policy, but it 279 usually means the most recently-issued CRL. A CA issues a new CRL on a regular periodic basis (e.g., 280 hourly, daily, or weekly). Entries are added to CRLs as revocations occur, and an entry may be removed 281 when the certificate expiration date is reached. 283 An advantage of this revocation method is that CRLs may be distributed by exactly the same means as 284 certificates themselves, namely, via untrusted communications and server systems. 286 One limitation of the CRL revocation method, using untrusted communications and servers, is that the 287 time granularity of revocation is limited to the CRL issue period. For example, if a revocation is reported 288 now, that revocation will not be reliably notified to certificate-using systems until the next periodic CRL is 289 issued -- this may be up to one hour, one day, or one week depending on the frequency that the CA issues 290 CRLs. 292 Another potential problem with CRLs is the risk of a CRL growing to an entirely unacceptable size. In 293 the 1988 and 1993 versions of X.509, the CRL for the end-user certificates needed to cover the entire 294 population of end-users for one CA. It is desirable to allow such populations to be in the range of 295 thousands, tens of thousands, or possibly even hundreds of thousands of users. The end-user CRL is 296 therefore at risk of growing to such sizes, which present major communication and storage overhead 297 problems. With the version 2 CRL format, introduced along with the v3 certificate format, it becomes 298 possible to arbitrarily divide the population of certificates for one CA into a number of partitions, each 299 partition being associated with one CRL distribution point (e.g., directory entry or URL) from which 300 CRLs are distributed. Therefore, the maximum CRL size can be controlled by a CA. Separate CRL 301 distribution points can also exist for different revocation reasons. For example, routine revocations (e.g., 302 name change) may be placed on a different CRL to revocations resulting from suspected key compromises, 303 and policy may specify that the latter CRL be updated and issued more frequently than the former. 305 As with the X.509 v3 certificate format, in order to facilitate interoperable implementations from multiple 306 vendors, the X.509 v2 CRL format needs to be profiled for Internet use. It is one goal of this document to 307 specify such profiles. 309 Furthermore, it is recognized that on-line methods of revocation notification may be applicable in some 310 environments as an alternative to the X.509 CRL. On-line revocation checking eliminates the latency 311 between a revocation report and CRL the next issue. Once the revocation is reported, any query to the on- 312 line service will correctly reflect the certificate validation impacts of the revocation. Therefore, this 313 document will also consider standard approaches to on-line revocation notification. 315 3.4 Operational Protocols 317 Operational protocols are required to deliver certificates and CRLs to certificate using client systems. 318 Provision is needed for a variety of different means of certificate and CRL delivery, including 319 request/delivery procedures based on E-mail, http, X.500, and WHOIS++. These specifications include 320 definitions of, and/or references to, message formats and procedures for supporting all of the above 321 operational environments, including definitions of or references to appropriate MIME content types. 323 3.5 Management Protocols 325 Management protocols are required to support on-line interactions between Public Key Infrastructure 326 (PKI) components. For example, management protocol might be used between a CA and a client system 327 with which a key pair is associated, or between two CAs which cross-certify each other. The set of 328 functions which potentially need to be supported by management protocols include: 330 (a) registration: This is the process whereby a user first makes itself known to a CA, prior to that CA 331 issuing a certificate or certificates for that user. 333 (b) initialization: Before a client system can operate securely it is necessary to install in it necessary key 334 materials which have the appropriate relationship with keys stored elsewhere in the infrastructure. For 335 example, the client needs to be securely initialized with the public key of a CA, to be used in validating 336 certificate paths. Furthermore, a client typically needs to be initialized with its own key pair(s). 338 (c) certification: This is the process in which a CA issues a certificate for a user's public key, and returns 339 that certificate to the user's client system and/or posts that certificate in a public repository. 341 (d) key pair recovery: As an option, user client key materials (e.g., a user's private key used for 342 encryption purposes) may be backed up by a CA or a key backup system associated with a CA. If a user 343 needs to recover these backed up key materials (e.g., as a result of a forgotten password or a lost key chain 344 file), an on-line protocol exchange may be needed to support such recovery. 346 (e) key pair update: All key pairs need to be updated regularly, i.e., replaced with a new key pair, and 347 new certificates issued. 349 (f) revocation request: An authorized person advises a CA of an abnormal situation requiring certificate 350 revocation. 352 (g) cross-certification: Two CAs exchange the information necessary to establish cross-certificates 353 between those CAs. 355 Note that on-line protocols are not the only way of implementing the above functions. For all functions 356 there are off-line methods of achieving the same result, and this specification does not mandate use of on- 357 line protocols. For example, when hardware tokens are used, many of the functions may be achieved 358 through as part of the physical token delivery. Furthermore, some of the above functions may be 359 combined into one protocol exchange. In particular, two or more of the registration, initialization, and 360 certification functions can be combined into one protocol exchange. 362 Part 3 of the PKIX series of specifications defines a set of standard message formats supporting the 363 above functions. The protocols for conveying these messages in different environments (on-line, 364 e-mail, and WWW) are also specified. 366 4 Certificate and Certificate Extensions Profile 368 As described above, the goal of this section is to create a profile for X.509 v3 certificates that will foster 369 interoperability and a reusable public key infrastructure. To achieve this goal, some assumptions need to 370 be made about the nature of information to be included along with guidelines for how extensibility will be 371 employed. 373 Certificates may be used in a wide range of applications and environments covering a broad spectrum of 374 interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this 375 section is to establish a common baseline for generic applications requiring broad interoperability and 376 limited special purpose requirements. In particular, the emphasis will be on supporting the use of X.509 377 v3 certificates for informal internet electronic mail, IPSEC, and WWW applications. This section defines 378 a baseline set of information, common locations within a certificate for this information, and common 379 representations for this information. Environments with additional requirements may build on this 380 profile or may replace it. 382 4.1 Basic Certificate Fields 384 The X.509 v3 certificate Basic syntax follows. For signature calculation, the certificate is ASN.1 385 DER encoded [reference X.509?]. ASN.1 DER encoding is a tag, length, value encoding system for each 386 element. 388 Certificate ::= SIGNED { SEQUENCE { 389 version [0] Version DEFAULT v1, 390 serialNumber CertificateSerialNumber, 391 signature AlgorithmIdentifier, 392 issuer Name, 393 validity Validity, 394 subject Name, 395 subjectPublicKeyInfo SubjectPublicKeyInfo, 396 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 397 -- If present, version must be v2 or v3 398 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 399 -- If present, version must be v2 or v3 400 extensions [3] Extensions OPTIONAL 401 -- If present, version must be v3 402 } } 404 Version ::= INTEGER { v1(0), v2(1), v3(2) } 406 CertificateSerialNumber ::= INTEGER 408 Validity ::= SEQUENCE { 409 notBefore UTCTime, 410 notAfter UTCTime } 412 UniqueIdentifier ::= BIT STRING 414 SubjectPublicKeyInfo ::= SEQUENCE { 415 algorithm AlgorithmIdentifier, 416 subjectPublicKey BIT STRING } 418 The following items describe a proposed use of the X.509 v3 419 certificate for the Internet. 421 4.1.1 Version 423 This field describes the version of the encoded certificate. When 424 extensions are used, as expected in this profile, use X.509 version 3 425 (value is 2). If no extensions are present, but a UniqueIdentifier 426 is present, use version 2 (value is 1). If only basic fields are 427 present, use version 1 (the value is absent). 429 Implementations should be prepared to accept any version certificate. 431 In particular, at a minimum, implementations should recognize version 432 3 certificates; determine whether any critical extensions are 433 present; and accept certificates without critical extensions even if 434 they don't recognize any extensions. A certificate with an 435 unrecognized critical extension must always be rejected. 437 Generation of version 2 certificates is not expected by CAs using 438 this profile. 440 4.1.2 Serial number 442 The serial number is an integer assigned by the CA to each 443 certificate. It must be unique for each certificate issued by a CA 444 (i.e., the issuer name and serial number identify a unique 445 certificate). 447 << Do we want to define a maximum value for the serial number? >> 449 4.1.3 Signature 451 This field contains the algorithm identifier for the algorithm used 452 to sign the certificate. Section 7.2 of this profile lists the 453 supported signature algorithms. 455 4.1.4 Issuer Name 457 The issuer name (combined with the IssuerUniqueID, if present) 458 provides a globally unique identifier of the authority signing the 459 certificate. Reliance on the IssuerUniqueID is strongly discouraged. 460 The syntax of the issuer name is an X.500 distinguished name. A name 461 in the certificate may provide semantic information, may provide a 462 reference to an external information store or service, provides a 463 unique identifier, may provide authorization information, or may 464 provide a basis for managing the CA relationships and certificate 465 paths (other purposes are also possible). This strawman suggests 466 that the issuer (and subject) name fields must provide a globally 467 unique identifier. In addition, they should contain semantic 468 information identifying the issuer/subject (e.g. a full name, 469 organization name, etc.). Access information will be provided in a 470 separate extension (when other than via X.500 directory) and internet 471 specific identities (electronic mail address, DNS name, and URLs) 472 will be carried in alternative name extensions. 474 << Further discussion of naming guidelines for internet use is 475 needed. >> 477 4.1.5 Validity 479 This field indicates the dates on which the certificate becomes valid 480 (notBefore) and on which the certificate ceases to be valid 481 (notAfter). 483 The UTCTime (Coordinated Universal Time) values included in this 484 field shall be expressed in Greenwich Mean Time (Zulu) and include 485 granularity to the minute, even though finer granularity can be 486 expressed in the UTCTime format. That is, UTCTime should be 487 expressed as YYMMDDHHMMZ. 489 Implementors are warned that no DER is defined for UTCTime, thus 490 transformation between local time representations and the DER 491 transfer syntax must be performed carefully when computing the hash 492 value for a certificate signature. For example, a UTCTime value 493 which includes explict, zero values for seconds will not produce the 494 same hash value as one in which the seconds are omitted. UTCTime 495 expresses the value of a year modulo 100, with no indication of 496 century, hence comparisons involving dates in different centuries 497 must be performed with care. 499 4.1.6 Subject Name 501 The purpose of the subject name (combined with the SubjectUniqueID, 502 if present) is to provide a unique identifier of the subject of the 503 certificate. Reliance on the IssuerUniqueID is discouraged. The 504 syntax of the subject name is an X.500 distinguished name. The 505 discussion in section 4.1.4 on issuer names applies to subject names 506 as well. 508 << How do we bind a public key to an Internet e-mail address? One 509 alternative is to make Subject Name as a unique identifier. Or, it 510 could be legal to have a null Subject Name. Either way the 511 SubjectAltName contains the e-mail address. >> 513 4.1.7 Subject Public Key Info 515 This field is used to carry the public key and identify the algorithm 516 with which the key is used. 518 4.1.8 Unique Identifiers 520 The subject and issuer unique identifier are present in the 521 certificate to handle the possibility of reuse of subject and/or 522 issuer names over time. This profile strongly recommends that names 523 not be reused, thus certificates conforming to this profile do not 524 make use of unique identifiers. 526 4.2 Certificate Extensions 528 The extensions already defined by ANSI X9 and ISO for X.509 v3 529 certificates provide methods for associating additional attributes 530 with users or public keys and for managing the certification 531 hierarchy. The X.509 v3 certificate format also allows communities to 532 define private extensions to carry information unique to those 533 communities. Each extension in a certificate may be designated as 534 critical or non-critical. A certificate using system (an application 535 validating a certificate) must reject the certificate if it 536 encounters a critical extension it does not recognize. A non- 537 critical extension may be ignored if it is not recognized. The 538 following presents recommended extensions used within Internet 539 certificates and standard locations for information. Communities may 540 elect to use additional extensions; however, caution should be 541 exercised in adopting any critical extensions in certificates which 542 might be used in a general context. 544 << Need to add table of OIDs for all extensions from X.509 and X9.55. 545 Say which are allowed in this profile, and which are prohibited in 546 this profile. >> 548 4.2.1 Subject Alternative Name 550 The altNames extension allows additional identities to be bound to 551 the subject of the certificate. Defined options include an rfc822 552 name (electronic mail address), a DNS name, and a URL. Each of these 553 are IA5 strings. Multiple instances may be included. Whenever such 554 identities are to be bound in a certificate, the subject alternative 555 name (or issuer alternative name) field shall be used. A form of 556 such an identifier may also be present in the subject distinguished 557 name; however, the altName field is the preferred location for 558 finding such information. 560 The following definition is an enhanced version of the X9.55 561 definition of GeneralName. This definition is anticipated to be used 562 in the X.509 Amendment. 564 rfc822Name, dNSName, url, and ipAddress are name forms expected to be 565 used with this profile. Such names are subject to the basic 566 constraint extension for issuers which may restrict the names a given 567 CA can certify (see section on Basic Constraint extension). 569 The use of otherName should not be used in conjunction with this 570 profile. 572 AltNames ::= SEQUENCE OF GeneralName 573 GeneralName ::= CHOICE { 574 otherName [0] INSTANCE OF OTHER-NAME, 575 rfc822Name [1] IA5String, 576 dNSName [2] IA5String, 577 x400Address [3] ORAddress, 578 directoryName [4] Name, 579 ediPartyName [5] IA5String, 580 url [6] IA5String, 581 ipAddress [7] OCTET STRING } 583 4.2.2 Issuer Alternative Name 585 As with 4.2.1, this extension is used to bind Internet style 586 identities to the issuer name. 588 4.2.3 Certificate Policies 590 The certificatePolicies extension contains one or more object 591 identifiers (OIDs). Each OID indicates the policy under which the 592 certificate has been issued. This profile expects that a simple OID 593 will be present in each PolicyElementInfo. The qualifier within the 594 PolicyElementInfo should be absent. 596 Implementations processing certificate policy fields are expected to 597 have lists of those policies which they will accept. The 598 implementations compare the policy identifier(s) in the certificate 599 to that list. This field provides information to be used at the 600 discretion of a relying party. In contrast, the policy identifier(s) 601 in the keyUsageRestriction is a mandate by the issuer that a 602 certificate be used only in particular environments. 604 CertificatePolicies ::= SEQUENCE OF PolicyInformation 606 PolicyInformation ::= SEQUENCE OF PolicyElementInfo 608 PolicyElementInfo ::= SEQUENCE { 609 policyElementId OBJECT IDENTIFIER, 610 qualifier ANY DEFINED BY policyElementId OPTIONAL } 612 4.2.4 Key Attributes 614 The keyAttributes extension contains information about the key itself 615 including a unique key identifier, a key usage period (lifetime of 616 the private key as opposed to the lifetime of the certificate), and 617 an intended key usage. The Internet certificate should use the 618 keyAttributes extension and contain a key identifier and private key 619 validity to aid in system management. The key usage field in this 620 extension is intended to be advisory (as contrasted with the key 621 usage restriction extension which imposes mandatory restrictions). 622 The key usage field in this extension should be used to differentiate 623 certificates containing public keys for validating CA certificate 624 signatures, for validating CA CRL signatures, and validating 625 signatures on on-line transactions. However, the nonrepudiation and 626 dataEncipherment values should not be used. Where a reference to a 627 public key identifier is needed (as with an Authority Key ID) and is 628 not included in an attribute in the associated certificate, an SHA-1 629 hash of the public key shall be used. 631 The GeneralizedTime values included in this field shall be expressed 632 in Greenwich Mean Time (Zulu) and include granularity to the minute, 633 even though finer granularity can be expressed in the GeneralizedTime 634 format. That is, GeneralizedTime should be expressed as 635 YYYYMMDDHHMMZ. 637 Implementors are warned that no DER is defined for GeneralizedTime, 638 thus transformation between local time representations and the DER 639 transfer syntax must be performed carefully when computing the hash 640 value for a certificate signature. For example, a GeneralizedTime 641 value which includes explict, zero values for seconds will not 642 produce the same hash value as one in which the seconds are omitted. 643 GeneralizedTime expresses the using four digits. Remember that 644 UTCTime represents the value of a year modulo 100, with no indication 645 of century. 647 KeyAttributes ::= SEQUENCE { 648 keyIdentifier KeyIdentifier OPTIONAL, 649 intendedKeyUsage KeyUsage OPTIONAL, 650 privateKeyUsagePeriod PrivateKeyValidity OPTIONAL } 652 KeyIdentifier ::= OCTET STRING 654 PrivateKeyValidity ::= SEQUENCE { 655 notBefore [0] GeneralizedTime OPTIONAL, 656 notAfter [1] GeneralizedTime OPTIONAL } 658 KeyUsage ::= BIT STRING { 659 digitalSignature (0), 660 nonRepudiation (1), 661 keyEncipherment (2), 662 dataEncipherment (3), 663 keyAgreement (4), 664 keyCertSign (5), 665 offLineCRLSign (6) } 667 4.2.5 Key Usage Restriction 669 The keyUsageRestriction extension defines mandatory restrictions on 670 the use of the key contained in the certificate based on policy 671 and/or usage (e.g., signature, encryption). This field should be 672 used whenever the use of the key is to be restricted based on either 673 usage or policy (see discussion in policies). The usage restriction 674 would be employed when a multipurpose key is to be restricted (e.g., 675 when an RSA key should be used only for signing or only for key 676 encipherment). 678 The policy restriction in this field provides a mandate by the issuer 679 that a certificate be used only in selected environments (for 680 example, that a certificate be used only for a given type of 681 financial transaction). In contrast, the policy identifier in the 682 certificatePolicies extension is information which may be used at the 683 discretion of a relying party. 685 keyUsageRestriction ::= SEQUENCE { 686 certPolicySet SEQUENCE OF CertPolicyId OPTIONAL, 687 restrictedKeyUsage KeyUsage OPTIONAL } 689 4.2.6 Basic Constraints 691 The basicConstraints extension identifies whether the subject of the 692 certificate is a CA or an end user. In addition, this field can 693 limit the authority of a subject CA in terms of the certificates it 694 can issue. Discussion of certification path restriction is covered 695 elsewhere in this draft. The subject type field should be present in 696 all Internet certificates. 698 basicConstraints ::= SEQUENCE { 699 subjectType SubjectType, 700 pathLenConstraint INTEGER OPTIONAL, 701 permittedSubtrees [0] SEQUENCE OF GeneralName OPTIONAL, 702 excludedSubtrees [1] SEQUENCE OF GeneralName OPTIONAL } 704 SubjectType ::= BIT STRING { 705 cA (0), 706 endEntity (1) } 708 4.2.7 CRL Distribution Points 710 The cRLDistributionPoints extension identifies the CRL distribution 711 point or points to which a certificate user should refer to acertain 712 if the certificate has been revoked. This extenstion provides a 713 mechanism to divide the CRL inot manageable pieces if the CA has a 714 large constituency. Further discussion of CRL management is 715 contained in section 5. 717 4.2.8 Authority Key Identifier 719 The authority key identifier extension provides a means of 720 identifying the particular public key used to sign a certificate. 721 The identification can be based on either the key identifier (from 722 the key Attributes extension) or on the issuer name and serial 723 number. The key identifier method is recommended in this profile. 724 This extension would be used where an issuer has multiple signing 725 keys (either due to multiple concurrent key pairs or due to 726 changeover). In general, this extension should be included in 727 certificates. If the issuer name/serial number approach is used, both 728 the certIssuer and certSerialNumber fields must be present. 730 authorityKeyId ::= SEQUENCE { 731 keyIdentifier [0] KeyIdentifier OPTIONAL, 732 certIssuer [1] Name OPTIONAL, 733 certSerialNumber [2] CertificateSerialNumber OPTIONAL } 735 4.2.9 Subject Directory Attributes 737 The DAM provides an extension for subject directory attributes. This 738 extension may hold any information about the subject where that 739 information has a defined X.500 Directory attribute. This extension 740 is not recommended as an essential part of this profile but may be 741 used in local environments. This extension is always non-critical. 743 subjectDirectoryAttributes ::= SEQUENCE OF Attribute 745 4.2.10 Information Access 747 The informationAccess field is proposed as a private extension to 748 tell how information about a subject or CA (or ancillary CA services) 749 may be accessed. For example, this field might provide a pointer to 750 information about a user (e.g., a URL) or might tell how to access CA 751 information such as certificate status or on-line validation 752 services. 754 In many cases, the accuracy of this information is not certified by 755 the CA. 757 << Can IssuerAltNames and SubjectAltNames be used instead of some of 758 this information? If not, then add a paragraph describing each of 759 the optional components? >> 761 informationAccess ::= SEQUENCE { 762 certRetrieval GeneralName OPTIONAL, 763 certValidation GeneralName OPTIONAL, 764 caInfo GeneralName OPTIONAL, 765 userInfo GeneralName OPTIONAL } 767 Url ::= IA5String 769 4.2.11 Other extensions 771 The X.509 DAM defines additional extensions; however, this 772 specification does not include them in the profile. 774 << policyMappings? We could say this optional. It is non-critical, 775 so not problematical. >> 777 << nameConstraints. We should add a paragraph that strictly forbids 778 use of this extensions. >> 780 << policyConstraints? We should encourage support of this extension. 781 Since it is critical, we should include it in our profile so that all 782 implementations are prepared to process it. It will be needed for 783 interoperability in the future. >> 785 4.3 Examples 787 << Certificate samples including descriptive text and ASN.1 encoded 788 blobs will be inserted. >> 790 5 CRL and CRL Extensions Profile 792 As described above, one goal of this X.509 v2 CRL profile is to 793 foster the creation of an interoperable and reusable Internet PKI. 794 To achieve this goal, guidelines for the use of extensions are 795 specified, and some assumptions are made about the nature of 796 information included in the CRL. 798 CRLs may be used in a wide range of applications and environments 799 covering a broad spectrum of interoperability goals and an even 800 broader spectrum of operational and assurance requirements. This 801 profile establishes a common baseline for generic applications 802 requiring broad interoperability. Emphasis is placed on support for 803 X.509 v2 CRLs. The profile defines a baseline set of information 804 that can be expected in every CRL. Also, the profile defines common 805 locations within the CRL for frequently used attributes, and common 806 representations for these attributes. 808 Environments with additional or special purpose requirements may 809 build on this profile or may replace it. 811 5.1 CRL Fields 813 The X.509 v2 CRL syntax is as follows. For signature calculation, 814 the data that is to be signed is ASN.1 DER encoded. ASN.1 DER 815 encoding is a tag, length, value encoding system for each element. 817 CertificateList ::= SIGNED { SEQUENCE { 818 version Version OPTIONAL, 819 -- if present, must be v2 820 signature AlgorithmIdentifier, 821 issuer Name, 822 thisUpdate UTCTime, 823 nextUpdate UTCTime, 824 revokedCertificates SEQUENCE OF SEQUENCE { 825 userCertificate CertificateSerialNumber, 826 revocationDate UTCTime, 827 crlEntryExtensions Extensions OPTIONAL } OPTIONAL, 828 crlExtensions [0] Extensions OPTIONAL } } 830 Version ::= INTEGER { v1(0), v2(1), v3(2) } 832 AlgorithmIdentifier ::= SEQUENCE { 833 algorithm OBJECT IDENTIFIER, 834 parameters ANY DEFINED BY algorithm OPTIONAL } 835 -- contains a value of the type 836 -- registered for use with the 837 -- algorithm object identifier value 839 CertificateSerialNumber ::= INTEGER 841 Extensions ::= SEQUENCE OF Extension 843 Extension ::= SEQUENCE { 844 extnId OBJECT IDENTIFIER, 845 critical BOOLEAN DEFAULT FALSE, 846 extnValue OCTET STRING } 847 -- contains a DER encoding of a value 848 -- of the type registered for use with 849 -- the extnId object identifier value 851 The following items describe the proposed use of the X.509 v2 CRL for 852 in Internet PKI. 854 5.1.1 Version 856 This field describes the version of the encoded CRL. When extensions 857 are used, as expected in this profile, use version 2 (the integer 858 value is 1). If neither CRL extensions nor CRL entry extensions are 859 present, use version 1 (the integer value must be omitted). 861 5.1.2 Signature 863 This field contains the algorithm identifier for the algorithm used 864 to sign the CRL. Section 7.2 lists the signature algorithms used in 865 the Internet PKI. 867 5.1.3 Issuer Name 869 The issuer name provides a globally unique identifier of the 870 certification authority signing the CRL. The syntax of the issuer 871 name is an X.500 distinguished name. 873 5.1.4 Last Update 875 This field indicates the issue date of this CRL. 877 The UTCTime (Coordinated Universal Time) value included in this field 878 shall be expressed in Greenwich Mean Time (Zulu) and include 879 granularity to the minute, even though finer granularity can be 880 expressed in the UTCTime format. That is, UTCTime should be 881 expressed as YYMMDDHHMMZ. 883 Implementors are warned that no DER is defined for UTCTime, thus 884 transformation between local time representations and the DER 885 transfer syntax must be performed carefully when computing the hash 886 value for a CRL signature. For example, a UTCTime value which 887 includes explict, zero values for seconds will not produce the same 888 hash value as one in which the seconds are omitted. UTCTime 889 expresses the value of a year modulo 100, with no indication of 890 century, hence comparisons involving dates in different centuries 891 must be performed with care. 893 5.1.5 Next Update 895 This field indicates the date by which the next CRL will be issued. 896 The next CRL could be issued before the indicated date, but it will 897 not be issued any later than the indicated date. 899 The same restrictions associated with UTCTime for Last Update apply 900 to Next Update. 902 5.1.6 Revoked Certificates 904 Revoked certificates are listed. The revoked certificates are named 905 by their serial numbers. Certificates are uniquely identified by the 906 combination of the issuer name and the user certificate serial 907 number. The date on which the revocation occured is specified. The 908 same restrictions associated with UTCTime for Last Update apply to 909 the revocation date. CRL entry extensions are discussed in section 910 5.3. 912 When a CA wishes to revoke a certificate that it issued to another 913 CA, the revocation shall appear on the CRL. The revocation should 914 also appear on the ARL. The CA is revoking a certificate that it 915 issued. 917 5.2 CRL Extensions 919 The extensions already defined by ANSI X9 and ISO for X.509 v2 CRLs 920 provide methods for associating additional attributes with CRLs. The 921 X.509 v2 CRL format also allows communities to define private 922 extensions to carry information unique to those communities. Each 923 extension in a CRL may be designated as critical or non-critical. A 924 CRL validation must fail if it encounters an critical extension which 925 it does not know how to process. However, an unrecognized non- 926 critical extension may be ignored. The following presents those 927 extensions used within Internet CRLs. Communities may elect to use 928 additional extensions; however, caution should be exercised in 929 adopting any critical extensions in CRLs which might be used in a 930 general context. 932 << Need to add table of OIDs for all extensions from X.509 and X9.55. 933 Say which are allowed in this profile, and which are prohibited in 934 this profile. >> 936 5.2.1 Authority Key Identifier 938 The authorityKeyIdentifier is a non-critical CRL extension that 939 identifies the CA's key used to sign the CRL. This extension is 940 useful when a CA uses more than one key; it allows distinct keys 941 differentiated (e.g., as key updating occurs). The key may be 942 identified by an explicit key identifier, by identification of a 943 certificate for the key (giving certificate issuer and certificate 944 serial number), or both. If both are used then the CA issuer shall 945 ensure that all three fields are consistent. 947 AuthorityKeyId ::= SEQUENCE { 948 keyIdentifier [0] KeyIdentifier OPTIONAL, 949 certIssuer [1] Name OPTIONAL, 950 certSerialNumber [2] CertificateSerialNumber OPTIONAL } 951 -- certIssuer and certSerialNumber constitute a logical pair, 952 -- and if either is present both must be present. Either this 953 -- pair or the keyIdentifier field or all shall be present 955 KeyIdentifier ::= OCTET STRING 957 5.2.2 Issuer Alternative Name 959 The issuerAltName is a non-critical CRL extension that provides 960 additional CA names. Multiple instances may be included. The syntax 961 for the issuerAltName is the same as described in section 4.2.1. 962 Whenever such alternative names are included in a CRL, the issuer 963 alternative name field shall be used. Implementations which 964 recognize this extension are not required to be able to process all 965 the alternative name formats. Unrecognized alternative name formats 966 may be ignored by an implementation. 968 The following definition is an enhanced version of the X9.55 969 definition of GeneralName. This definition is anticipated to be used 970 in the X.509 Amendment. 972 rfc822Name, dNSName, url, and ipAddress are name forms expected to be 973 used with this profile. Such names are subject to the basic 974 constraint extension for issuers which may restrict the names a given 975 CA can certify (see section on Basic Constraint extension). 977 The use of otherName should not be used in conjunction with this 978 profile. 980 AltNames ::= SEQUENCE OF GeneralName 982 GeneralName ::= CHOICE { 983 otherName [0] INSTANCE OF OTHER-NAME, 984 rfc822Name [1] IA5String, 985 dNSName [2] IA5String, 986 x400Address [3] ORAddress, 987 directoryName [4] Name, 988 ediPartyName [5] IA5String, 989 url [6] IA5String, 990 ipAddress [7] OCTET STRING } 992 5.2.3 CRL Number 994 The cRLNumber is a non-critical CRL extension which conveys a 995 monotonically increacing sequence number for each CRL issued by a 996 given CA through a specific CA X.500 Directory entry or CRL 997 distribution point. This extension allows users to easily determine 998 when a particular CRL superceeds another CRL. CAs conforming to this 999 profile shall include this CRL. 1001 CRLNumber ::= INTEGER 1003 5.2.4 Issuing Distribution Point 1005 The issuingDistributionPoint is a critical CRL extension that 1006 identifiers the CRL distribution point for this particular CRL, and 1007 it indicates whether the CRL covers revocation for end entity 1008 certificates only, CA certificates only, or a limitied set of reason 1009 codes. Support for CRL distribution points is strongly encouraged. 1010 The use of certificateHold is strictly prohibited in this profile. 1012 Only the following reason codes may be used in conjunction with this 1013 profile. The use of keyCompromise (1) shall be used to indicate 1014 compromise or suspected compromise. The use of affiliationChanged 1015 (3), superseded (4), or cessationOfOperation (5)shall be used to 1016 indicate routine compromise. 1018 << Does anyone see a use for (2)? >> 1020 The CRL is signed by the CA's key. CRL Distribution Points do not 1021 have their own key pairs. If the CRL is stored in the X.500 1022 Directory, it is stored entry corresponding to the CRL distribution 1023 point, which may be different that the directory entry of the CA. 1025 CRL distribution points, if used, should be partitioned the CRL on 1026 the basis of compromise and routine revocation. That is, the 1027 revocations with reason code (1) shall appear in one distribution 1028 point, and the revocations with reason codes (3), (4), and (5) shall 1029 appear in another distribution point. 1031 DistributionPoint ::= SEQUENCE { 1032 distributionPoint DistributionPointName, 1033 reasons ReasonFlags OPTIONAL } 1035 DistributionPointName ::= CHOICE { 1036 fullName [0] Name, 1037 nameRelativeToCA [1] RelativeDistinguishedName, 1038 generalName [2] GeneralName } 1040 GeneralName ::= CHOICE { 1041 otherName [0] INSTANCE OF OTHER-NAME, 1042 rfc822Name [1] IA5String, 1043 dNSName [2] IA5String, 1044 x400Address [3] ORAddress, 1045 directoryName [4] Name, 1046 ediPartyName [5] IA5String, 1047 uniformResourceLocator [6] IA5String } 1049 OTHER-NAME ::= TYPE-IDENTIFIER 1050 ReasonFlags ::= BIT STRING { 1051 unused (0), 1052 keyCompromise (1), 1053 caCompromise (2), 1054 affiliationChanged (3), 1055 superseded (4), 1056 cessationOfOperation (5), 1057 certificateHold (6) } 1059 5.2.5 Delta CRL Indicator 1061 The deltaCRLIndicator is a critical CRL extension that identifies a 1062 delta-CRL. The use of delta-CRLs can significantly improve 1063 processing time for applications which store revocation information 1064 in a format other than the CRLstructure. This allows changes to be 1065 added to the local database while ignoring unchanged information that 1066 is already in the local databse. 1068 CAs are shall always issue a complete CRL when a delta-CRL is issued. 1070 The value of BaseCRLNumber identifies the CRL number of the base CRL 1071 that was used as the starting point in the generation of this delta- 1072 CRL. The delta-CRL contains the changes between the base CRL and the 1073 current CRL issued along with the delta-CRL. It is the decision of a 1074 CA as to whether to provide delta-CRLs. Again, a delta-CRL shall not 1075 be issued without a corresponding CRL. The value of CRLNumber for 1076 both the delta-CRL and the corresponding CRL shall be identical. 1078 A CRL user constructing a locally held CRL from delta-CRLs shall 1079 consider the constructed CRL incomplete and unusable if the CRLNumber 1080 of the received delta-CRL is more that one greater that the CRLnumber 1081 of the delta-CRL last processed. 1083 5.3 CRL Entry Extensions 1085 The CRL entry extensions already defined by ANSI X9 and ISO for X.509 1086 v2 CRLs provide methods for associating additional attributes with 1087 CRL entries. The X.509 v2 CRL format also allows communities to 1088 define private CRL entry extensions to carry information unique to 1089 those communities. Each extension in a CRL entry may be designated 1090 as critical or non-critical. A CRL validation must fail if it 1091 encounters an critical CRL entry extension which it does not know how 1092 to process. However, an unrecognized non-critical CRL entry 1093 extension may be ignored. The following presents recommended 1094 extensions used within Internet CRL entries and standard locations 1095 for information. Communities may elect to use additional CRL entry 1096 extensions; however, caution should be exercised in adopting any 1097 critical extensions in CRL entries which might be used in a general 1098 context. 1100 << Need to add table of OIDs for all extensions from X.509 and X9.55. 1101 Say which are allowed in this profile, and which are prohibited in 1102 this profile. >> 1104 5.3.1 Reason Code 1106 The reasonCode is a non-critical CRL entry extension that identifies 1107 the reason for the certificate revocation. CAs are strongly 1108 encouraged to include reason codes in CRL entries; however, some 1109 reasonCode values are strictly prohibited. The reason code extension 1110 permits certificates to placed on hold or suspended. The processing 1111 associated with suspended certificates greatly complicates 1112 certificate validation, therefore the use of reasonCode values 1113 certificateHold (6), certHoldRelease (7), and removeFromCRL (8) shall 1114 not be used. Also, the reasonCode CRL entry extension should be 1115 absent instead of using the unspecified (0) reasonCode value. 1117 << Again, is there any reason to permit caCompromise (2)? >> 1119 CRLReason ::= ENUMERATED { 1120 unspecified (0), 1121 keyCompromise (1), 1122 caCompromise (2), 1123 affiliationChanged (3), 1124 superseded (4), 1125 cessationOfOperation (5), 1126 certificateHold (6), 1127 certHoldRelease (7), 1128 removeFromCRL (8) } 1130 5.3.2 Expiration Date 1132 The expirationDate is a non-critical CRL entry extension that 1133 indicates the expiration of a hold entry in a CRL. The use of this 1134 extension is strictly prohibited by this profile. 1136 5.3.3 Instruction Code 1138 The instructionCode is a non-critical CRL entry extension that 1139 provides a registered instruction identifier which indicates the 1140 action to be taken after encountering a certificate that has been 1141 placed on hold. The use of this extension is strictly prohibited by 1142 this profile. 1144 5.3.4 Invalidity Date 1146 The invalidityDate is a non-critical CRL entry extension that 1147 provides the date on which it is known or suspected that the private 1148 key was compromised or that the certificate otherwise became invalid. 1149 This date may be earlier than the revocation date in the CRL entry, 1150 but it must be later than the issue date of the previously issued 1151 CRL. Remember that the revocation date in the CRL entry specifies 1152 the date that the CA revoked the certificate. Whenever this 1153 information is available, CAs are strongly encouraged to share it 1154 with CRL users. 1156 The GeneralizedTime values included in this field shall be expressed 1157 in Greenwich Mean Time (Zulu) and include granularity to the minute, 1158 even though finer granularity can be expressed in the GeneralizedTime 1159 format. That is, GeneralizedTime should be expressed as 1160 YYYYMMDDHHMMZ. 1162 Implementors are warned that no DER is defined for GeneralizedTime, 1163 thus transformation between local time representations and the DER 1164 transfer syntax must be performed carefully when computing the hash 1165 value for a certificate signature. For example, a GeneralizedTime 1166 value which includes explict, zero values for seconds will not 1167 produce the same hash value as one in which the seconds are omitted. 1168 GeneralizedTime expresses the using four digits. Remember that 1169 UTCTime represents the value of a year modulo 100, with no indication 1170 of century. 1172 InvalidityDate ::= GeneralizedTime 1174 5.4 Examples 1176 << CRL samples including descriptive text and ASN.1 encoded blobs 1177 will be inserted. >> 1179 6 Certificate Path Validation 1181 Certification path processing verifies the binding between the 1182 subject distinguished name and subject public key. The basic 1183 constraints and policy constraints extensions facilitate automated, 1184 self-contained implementation of certification path processing logic. 1186 The following is an outline of a procedure for validating 1187 certification paths. An implementation shall be functionally 1188 equivalent to the external behaviour resulting from this procedure. 1189 Any algorithm may be used by a particular implementation so long as 1190 it derives the correct result. 1192 The inputs to the certification path processing procedure are: 1194 (a) a set of certificates comprising a certification path; 1196 (b) a CA name and trusted public key value (or an identifier of 1197 such a key if the key is stored internally to the certification 1198 path processing module) for use in verifying the first certificate 1199 in the certification path; 1201 (c) a set of initial-policy identifiers (each comprising a 1202 sequence of policy element identifiers), which identifies one or 1203 more certificate policies, any one of which would be acceptable 1204 for the purposes of certification path processing; and 1206 (d) the current date/time (if not available internally to the 1207 certification path processing module). 1209 The outputs of the procedure are: 1211 (a) an indication of success or failure of certification path 1212 validation; 1214 (b) if validation failed, a reason for failure; and 1216 (c) if validation was successful, a (possibly empty) set of 1217 policy qualifiers obtained from CAs on the path. 1219 The procedure makes use of the following set of state variables: 1221 (a) acceptable policy set: A set of certificate policy identifiers 1222 comprising the policy or policies recognized by the public key user 1223 together with policies deemed equivalent through policy mapping; 1225 (b) constrained subtrees: A set of root names defining a set of 1226 subtrees within which all subject names in subsequent certificates in 1227 the certification path shall fall; if no restriction is in force this 1228 state variable takes the special value unbounded; and 1230 (c) excluded subtrees: A set of root names defining a set of 1231 subtrees within which no subject name in subsequent certificates in 1232 the certification path may fall; if no restriction is in force this 1233 state variable takes the special value empty. 1235 The procedure involves an initialization step, followed by a series 1236 of certificate-processing steps. The initialization step comprises: 1238 (a) Initialize the constrained subtress to unbounded; 1239 (b) Initialize the excluded subtrees indicator to empty; and 1241 (c) Initialize the acceptable policy set to the set of initial- 1242 policy identifiers. 1244 Each certificate is then processed in turn, starting with the 1245 certificate signed using the trusted CA public key which was input to 1246 this procedure. The last certificate is processed as an end-entity 1247 certificate; all other certificates (if any) are processed as CA- 1248 certificates. 1250 The following checks are applied to all certificates: 1252 (a) Check that the signature verifies, that dates are valid, that 1253 the subject and issuer names chain correctly, and that the 1254 certificate has not been revoked; 1256 (b) If a key usage restriction extension is present in the 1257 certificate and contains a certPolicySet component, check that at 1258 least one member of the acceptable policy set appears in the 1259 field; 1261 (c) Check that the subject name is consistent with the 1262 constrained subtrees state variables; and 1264 (d) Check that the subject name is consistent with the excluded 1265 subtrees state variables. 1267 If any one of the above checks fails, the procedure terminates, 1268 returning a failure indication and an appropriate reason. If none of 1269 the above checks fail on the end-entity certificate, the procedure 1270 terminates, returning a success indication together with the set of 1271 all policy qualifier values encountered in the set of certificates. 1273 For a CA-certificate, the following constraint recording actions are 1274 then performed, in order to correctly set up the state variables for 1275 the processing of the next certificate: 1277 (a) If permittedSubtrees is present in the certificate, set the 1278 constrained subtrees state variable to the intersection of its 1279 previous value and the value indicated in the extension field. 1281 (b) If excludedSubtrees is present in the certificate, set the 1282 excluded subtrees state variable to the union of its previous 1283 value and the value indicated in the extension field. 1285 Note: It is possible to specify an extended version of the above 1286 certification path processing procedure which results in default 1287 behaviour identical to the rules of Privacy Enhanced Mail [RFC 1422]. 1288 In this extended version, additional inputs to the procedure are a 1289 list of one or more Policy Certification Authority (PCA) names and an 1290 indicator of the position in the certification path where the PCA is 1291 expected. At the nominated PCA position, the CA name is compared 1292 against this list. If a recognized PCA name is found, then a 1293 constraint of SubordinateToCA is implicitly assumed for the remainder 1294 of the certification path and processing continues. If no valid PCA 1295 name is found, and if the certification path cannot be validated on 1296 the basis of identified policies, then the certification path is 1297 considered invalid. 1299 7 Algorithm Support 1301 7.1 One-way Hash Functions 1303 One-way hash functions are also called message digest algorithms. 1304 SHA-1 is be the most popular one-way hash function used in the 1305 Internet PKI. However, PEM uses MD2 for certificates [RFC1422, 1306 RFC1423]. For this reason, MD2 may continue to be used in 1307 certificates for many years. 1309 7.1.1 MD2 One-way Hash Function 1311 MD2 was also developed by Ron Rivest, but RSA Data Security has not 1312 placed the MD2 algorithm in the public domain. Rather, RSA Data 1313 Security has granted license to use MD2 for non-commerical Internet 1314 Privacy-Enhanced Mail. For this reason, MD2 may continue to be used 1315 with PEM certificates, but MD5 is preferred. MD2 is fully described 1316 in RFC 1319. 1318 << Add a paragraph about the MD2 flaw that was recently discovered. 1319 Urge MD2 replacement with SHA-1. >> 1321 7.1.2 SHA-1 One-way Hash Function 1323 SHA-1 was developed by the U.S. Government. SHA-1 is fully described 1324 in FIPS 180-1. 1326 SHA-1 is the one-way hash function of choice for use with both RSA 1327 the DSA signature algorithms. 1329 7.2 Signature Algorithms 1331 RSA and DSA are the most popular signature algorithms used in the 1332 Internet. 1334 There is some ambiguity in 1988 X.509 document regarding the 1335 definition of the SIGNED macro regarding, the representation of a 1336 signature in a certificate or a CRL. The interpretation selected for 1337 the Internet requires that the data to be signed (e.g., the one-way 1338 function output value) is first ASN.1 encoded as an OCTET STRING and 1339 the result is encrypted (e.g., using RSA Encryption) to form the 1340 signed quantity, which is then ASN.1 encoded as a BIT STRING. 1342 7.2.1 RSA Signature Algorithm 1344 A patent statement regarding the RSA algorithm can be found at the 1345 end of this profile. 1347 The RSA algorithm is named for it's inventors: Rivest, Shamir, and 1348 Adleman. The RSA signature algorithm is defined in PKCS #1. It 1349 combines the either the MD2 or the SHA-1 one-way hash function with 1350 the RSA asymmetric encryption algorithm. As defined in PKCS #1, the 1351 ASN.1 object identifiers used to identify these signature algorithms 1352 are: 1354 md2WithRSAEncryption OBJECT IDENTIFIER ::= { 1355 iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 1356 pkcs-1(1) 2 } 1358 sha-1WithRSAEncryption OBJECT IDENTIFIER ::= { 1359 iso(1) identified-organization(3) oiw(14) secsig(3) 1360 algorithm(2) 29 } 1362 When either of these object identifiers is used within the ASN.1 type 1363 AlgorithmIdentifier, the parameters component of that type shall be 1364 absent or the ASN.1 type NULL. 1366 7.2.2 DSA Signature Algorithm 1368 A patent statement regarding the DSA can be found at the end of this 1369 profile. 1371 The Digital Signature Algorithm (DSA) is also called the Digital 1372 Signature Standard (DSS). DSA was developed by the U.S. Government, 1373 and DSA is used in conjunction with the the SHA-1 one-way hash 1374 function. DSA is fully described in FIPS 186. The ASN.1 object 1375 identifiers used to identify this signature algorithm is: 1377 dsaWithSHA-1 OBJECT IDENTIFIER ::= { 1378 joint-iso-ccitt(2) country(16) US(840) organization(1) 1379 us-government(101) dod(2) infosec(1) algorithms(1) 2 } 1381 When this object identifier is used with the ASN.1 type 1382 AlgorithmIdentifier, the parameters component of that type is 1383 optional. If it is absent, the DSA parameters p, q, and g are 1384 assumed to be known, otherwise the parameters are included using the 1385 following ASN.1 structure: 1387 Dss-Parms ::= SEQUENCE { 1388 p OCTET STRING, 1389 q OCTET STRING, 1390 g OCTET STRING } 1392 7.3 Subject Public Key Algorithms 1394 << Add a section that lists the public key algorithms that are 1395 supported by this profile. Obviously, RSA, DSA, Diffie-Hellman, and 1396 KEA will be included. Are there others? >> 1398 << Should a different algorithm identifier be assigned to RSA 1399 signature keys and RSA key management keys? If so, there will be one 1400 subsection for each within this section.>> 1401 Patent Statements 1403 The Internet PKI relies on the use of patented public key technology. 1404 The Internet Standards Process as defined in RFC 1310 requires a 1405 written statement from the Patent holder that a license will be made 1406 available to applicants under reasonable terms and conditions prior 1407 to approving a specification as a Proposed, Draft or Internet 1408 Standard. 1410 Patent statements for DSA, RSA, and Diffie-Hellman follow. These 1411 statements have been supplied by the patent holders, not the authors 1412 of this profile. 1414 Digital Signature Algorithm (DSA) 1416 The U.S. Government holds patent 5,231,668 on the Digital 1417 Signature Algorithm (DSA), which has been incorporated into 1418 Federal Information Processing Standard (FIPS) 186. The patent 1419 was issued on July 27, 1993. 1421 The National Institute of Standards and Technology (NIST) has a 1422 long tradition of supplying U.S. Government-developed techniques 1423 to committees and working groups for inclusion into standards on a 1424 royalty-free basis. NIST has made the DSA patent available 1425 royalty-free to users worldwide. 1427 Regarding patent infringement, FIPS 186 summarizes our position; 1428 the Department of Commerce is not aware of any patents that would 1429 be infringed by the DSA. Questions regarding this matter may be 1430 directed to the Deputy Chief Counsel for NIST. 1432 RSA Signature and Encryption 1434 << Now that PKP has dissolved, a revised patent statement for RSA 1435 from RSADSI is needed. >> 1437 Diffie-Hellman Key Agreement 1439 << Now that PKP has dissolved, a revised patent statement for 1440 Diffie-Hellman from Cylink is needed. >> 1442 Obsolete PKP Patent Statement 1444 << This statement is included here until a replacement from RSADSI 1445 and Cylink can be obtained. >> 1447 The Massachusetts Institute of Technology and the Board of 1448 Trustees of the Leland Stanford Junior University have granted 1449 Public Key Partners (PKP) exclusive sub-licensing rights to the 1450 following patents issued in the United States, and all of their 1451 corresponding foreign patents: 1453 Cryptographic Apparatus and Method 1454 ("Diffie-Hellman")......................... No. 4,200,770 1456 Public Key Cryptographic Apparatus 1457 and Method ("Hellman-Merkle").............. No. 4,218,582 1459 Cryptographic Communications System and 1460 Method ("RSA")............................. No. 4,405,829 1462 Exponential Cryptographic Apparatus 1463 and Method ("Hellman-Pohlig").............. No. 4,424,414 1465 These patents are stated by PKP to cover all known methods of 1466 practicing the art of Public Key encryption, including the 1467 variations collectively known as El Gamal. 1469 Public Key Partners has provided written assurance to the Internet 1470 Society that parties will be able to obtain, under reasonable, 1471 nondiscriminatory terms, the right to use the technology covered 1472 by these patents. This assurance is documented in RFC 1170 titled 1473 "Public Key Standards and Licenses". A copy of the written 1474 assurance dated April 20, 1990, may be obtained from the Internet 1475 Assigned Number Authority (IANA). 1477 The Internet Society, Internet Architecture Board, Internet 1478 Engineering Steering Group and the Corporation for National 1479 Research Initiatives take no position on the validity or scope of 1480 the patents and patent applications, nor on the appropriateness of 1481 the terms of the assurance. The Internet Society and other groups 1482 mentioned above have not made any determination as to any other 1483 intellectual property rights which may apply to the practice of 1484 this standard. Any further consideration of these matters is the 1485 user's own responsibility. 1487 Security Considerations 1489 This entire memo is about security mechanisms. 1490 Author Addresses: 1492 Russell Housley 1493 SPYRUS 1494 PO Box 1198 1495 Herndon, VA 22070 1496 USA 1497 housley@spyrus.com 1499 Warwick Ford 1500 Nortel Secure Networks 1501 PO Box 3511, Station C 1502 Ottawa, Ontario 1503 Canada KY 4H7 1504 wford@bnr.ca 1506 David Solo 1507 BBN 1508 150 CambridgePark Drive 1509 Cambridge, MA 02140 1510 USA 1511 solo@bbn.com