idnits 2.17.1 draft-ietf-pkix-roadmap-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. Found some kind of copyright notice around line 30 but it does not match any copyright boilerplate known by this tool. 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 25 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 26 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 3 instances of lines with control characters in the document. == 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. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The first octets (the first characters of the first line) of this draft are 'PK', which can make Internet Explorer erroneously think that it is a zip file. It is recommended that you change this, for instance by inserting a blank line before the line starting with 'PK'. -- The 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'RFC1883' is mentioned on line 971, but not defined ** Obsolete undefined reference: RFC 1883 (Obsoleted by RFC 2460) == Unused Reference: 'CACHE' is defined on line 1247, but no explicit reference was found in the text == Unused Reference: 'OCDP' is defined on line 1288, but no explicit reference was found in the text == Unused Reference: 'RFC 1777' is defined on line 1315, but no explicit reference was found in the text == Unused Reference: 'RFC 1883' is defined on line 1318, but no explicit reference was found in the text == Unused Reference: 'IPv6' is defined on line 1319, but no explicit reference was found in the text == Unused Reference: 'SCHEMA' is defined on line 1321, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CACHE' -- Possible downref: Non-RFC (?) normative reference: ref. 'CMC' -- Possible downref: Non-RFC (?) normative reference: ref. 'CMMF' -- Possible downref: Non-RFC (?) normative reference: ref. 'CRMF' -- Possible downref: Non-RFC (?) normative reference: ref. 'CMP' -- Possible downref: Non-RFC (?) normative reference: ref. 'ECDSA' -- Possible downref: Non-RFC (?) normative reference: ref. 'FTP' -- Possible downref: Non-RFC (?) normative reference: ref. 'KEA' -- Possible downref: Non-RFC (?) normative reference: ref. 'LDAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'MISPC' -- Possible downref: Non-RFC (?) normative reference: ref. 'OCDP' -- Possible downref: Non-RFC (?) normative reference: ref. 'OCSP' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKIX-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKIX-4' ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Downref: Normative reference to an Historic RFC: RFC 1422 ** Obsolete normative reference: RFC 1777 (Obsoleted by RFC 3494) ** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460) -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6' -- Possible downref: Non-RFC (?) normative reference: ref. 'SCHEMA' -- Possible downref: Non-RFC (?) normative reference: ref. 'SIMONETTI' -- Possible downref: Non-RFC (?) normative reference: ref. 'WEB' Summary: 15 errors (**), 0 flaws (~~), 12 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PKIX Working Group A. Arsenault 2 INTERNET DRAFT DOD 3 S. Turner 4 IECA 6 Expires in six months from September 8,1998 8 Internet X.509 Public Key Infrastructure 9 PKIX Roadmap 10 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of 6 months and 20 may be updated, replaced, or may become obsolete by other documents at 21 any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as work in progress. 24 To view the entire list of current Internet-Drafts, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 27 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 28 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 30 Copyright (C) The Internet Society (date). All Rights Reserved. 32 Abstract 34 This document provides an overview or 'roadmap' of the work done by the 35 IETF PKIX working group. It describes some of the terminology used in 36 the working group's documents, and the theory behind an X.509-based PKI. 37 It identifies each document developed by the PKIX working group, and 38 describes the relationships among the various document. It also 39 provides advice to would-be PKIX implementors about some of the issues 40 discussed at length during PKIX development, in hopes of making it 41 easier to build implementations that will actually interoperate. 43 TABLE OF CONTENTS 44 1 INTRODUCTION 2 45 2 Terminology 3 46 3 PKIX Theory 3 47 3.1 Certificate-using Systems and PKIs 3 48 3.2 Overview of the PKIX Approach 4 49 3.3 X.509 certificates 6 50 3.4 Functions of a PKI 6 51 3.4.1 Registration 6 52 3.4.2 Initialization 7 53 3.4.3 Certification 7 54 3.4.4 Key Pair Recovery 7 55 3.4.5 Key Generation 7 56 3.4.6 Key Update 7 57 3.4.7 Cross-certification 8 58 3.4.8 Revocation 8 59 3.4.9 Certificate and Revocation Notice Distribution/Publication 10 60 3.5 Parts of PKIX 10 61 3.5.1 Profile 10 62 3.5.2 Operational Protocols 11 63 3.5.3 Management Protocols 11 64 3.5.4 Policy Outline 11 65 4 PKIX Documents 11 66 4.1 Profile 11 67 4.2 Operational Protocols 13 68 4.3 Management Protocols 14 69 4.4 Policy Outline 15 70 4.5 DOCUMENT RELATIONSHIPS 16 71 5 Advice to Implementors 17 72 5.1 Names 17 73 5.1.1 Name Forms 17 74 5.1.2 Scope of Names 19 75 5.1.3 Certificate Path Construction 19 76 5.1.4 Name Constraints 20 77 5.1.5 Wildcards in Name Forms 20 78 5.1.6 Name Encoding 21 79 5.2 POP 21 80 5.3 Key Usage Bits 21 81 5.4 Trust Models 23 82 6 Acknowledgements 23 83 7 References 24 84 8 Security Considerations 25 85 9 Editor's Address 26 86 10 Disclaimer 26 88 1 INTRODUCTION 90 This document is an informational Internet draft that provides a 91 "roadmap" to the documents produced by the PKIX working group. It is 92 intended to provide information; there are no requirements or 93 specifications in this document. 95 Section 2 of this document defines key terms used in this document. 96 Section 3 covers "PKIX theory"; it explains what the PKIX working 97 group's basic assumptions were. Section 4 provides an overview of the 98 various PKIX documents. It identifies which documents address which 99 areas, and describes the relationships among the various documents. 100 Section 5 contains "Advice to implementors". Its primary purpose is to 101 capture some of the major issues discussed by the PKIX working group, as 102 a way of explaining WHY some of the requirements and specifications say 103 what they say. This should cut down on the number of misinterpretations 104 of the documents, and help developers build interoperable 105 implementations. Section 6 contains a list of references. Section 7 106 discusses security considerations, and Section 8 provides contact 107 information for the editors. 109 2 Terminology 111 There are a number of terms used and misused throughout PKI-related 112 literature. To limit confusion caused by some of those terms, throughout 113 this document, we will use the following terms in the following ways: 115 - Certification Authority (CA) - an authority trusted by one or 116 more users to create and assign certificates. Optionally the 117 certification authority may create the users' key'. (It is 118 important to note that the CA is responsible for the certificates 119 during their whole lifetime, not just for issuing them.) 120 - Certificate policy - a named set of rules that indicates the 121 applicability of a certificate to a particular community and/or 122 class of application with common security requirements. For 123 example, a particular certificate policy might indicate 124 applicability of a type of certificate to the authentication of 125 electronic data interchange transaction s for the trading of 126 goods within a given price range. 127 - Root CA - a CA whose certificate is self-signed; that is, the 128 issuer and subject are the same entity. 129 - Registration Agent (RA) - an optional entity given responsibility 130 for performing some of the administrative tasks necessary in the 131 registration of subjects, such as: confirming the subject's 132 identity; validating that the subject is entitled to have the 133 attributes requested in a certificate; and verifying that the 134 subject has possession of the private key associated with the 135 public key requested for a certificate. 136 - End-entity - a subject of a certificate who is not a CA. 137 - Relying party - a user or agent (e.g., a client or server) who 138 relies on the data in a certificate in making decisions. 139 - Subject - a subject is the entity (CA or end-entity) named in a 140 certificate. Subjects can be human users, computers (as 141 represented by DNS names or IP addresses), or even software 142 agents. 144 3 PKIX Theory 146 3.1 Certificate-using Systems and PKIs 148 At the heart of recent efforts to improve Internet security are a group 149 of security protocols such as S/MIME, TLS, and IPSec. All of these 150 protocols rely on public-key cryptography to provide services such as 151 confidentiality, data integrity, data origin authentication, and 152 non-repudiation. The purpose of a PKI is to provide trusted and 153 efficient key- and certificate management, thus enabling the use of 154 authentication, non-repudiation, and confidentiality. 156 Users of public key-based systems must be confident that, any time they 157 rely on a public key, the associated private key is owned by the subject 158 with which they are communicating. (This applies whether an encryption 159 or digital signature mechanism is used.) This confidence is obtained 160 through the use of public key certificates, which are data structures 161 that bind public key values to subjects. The binding is achieved by 162 having a trusted CA verify the subject's identity and digitally sign 163 each certificate. 165 A certificate has a limited valid lifetime which is indicated in its 166 signed contents. Because a certificate's signature and timeliness can 167 be independently checked by a certificate-using client, certificates can 168 be distributed via untrusted communications and server systems, and can 169 be cached in unsecured storage in certificate-using systems. 171 Certificates are used in the process of validating signed data. 172 Specifics vary according to which algorithm is used, but the general 173 process works as follows: (note: there is no specific order in which 174 the checks listed below must be made; implementors are free to implement 175 them in the most efficient way for their systems) 177 - the recipient of signed data verifies that the claimed identity 178 of the user is in accordance wit the identity contained in the 179 certificate; 180 - the recipient validates that no certificate in the path has been 181 revoked (e.g., by retrieving a suitably-current Certificate 182 Revocation List (CRL) or querying an on-line certificate status 183 responder), and that all certificates were within their validity 184 periods at the time the data were signed; 185 - the recipient verifies that the data are not claimed to have any 186 attributes for which the certificate indicates that the signer is 187 not authorized; 188 - the recipient verifies that the data have not been altered since 189 signing, by using the public key in the certificate. 191 If all of these checks pass, the recipient can accept that the data were 192 signed by the purported signer. The process for keys used for 193 encryption is similar. 195 (Note: it is of course possible that data were signed by someone very 196 different from the signer, if for example the purported signer's private 197 key was compromised. Security depends on all parts of the 198 certificate-using SYSTEM, including but not limited to: physical 199 security of the place the computer resides; personnel security (i.e., 200 the trustworthiness of the people who actually develop, install, run, 201 and maintain the system); the security provided by the operating system 202 on which the private key is used; and the security provided the CA. A 203 failure in any one of these areas can cause the entire system security 204 to fail. PKIX is limited in scope, however, and only directly addresses 205 issues related to the operation of the PKI subsystem. For guidance in 206 many of the other areas, see [PKIX-4].) 208 A collection of certificates, with their issuing CA's, subjects, relying 209 parties, RA's, and repositories, is referred to as a Public Key 210 Infrastructure, or PKI. 212 3.2 Overview of the PKIX Approach 214 PKIX is an effort to develop specifications for a Public Key 215 Infrastructure for the Internet using X.509 certificates. The PKIX 216 working group was initially chartered in 1995. A Public Key 217 Infrastructure, or PKI, is defined as: 219 The set of hardware, software, people, policies and procedures needed 220 to create, manage, store, distribute, and revoke certificates based on 221 public-key cryptography. 223 A PKI consists five types of components[MISPC]: 224 * Certification Authorities (CAs) that issue and revoke 225 certificates; 226 * Organizational Registration Authorities (ORAs) that vouch for the 227 binding between public keys and certificate holder identities and 228 other attributes; 229 * Certificate holders that are issued certificates and can sign 230 digital documents; 231 * Clients that validate digital signatures and their certification 232 paths from a known public key of a trusted CA; 233 * Repositories that store and make available certificates and 234 Certificate Revocation Lists (CRLs). 236 Figure 1 is a simplified view of the architectural model assumed by the 237 PKIX Working Group. 239 +---+ 240 | C | +------------+ 241 | e | <-------------------->| End entity | 242 | r | Operational +------------+ 243 | t | transactions ^ 244 | | and management | Management 245 | / | transactions | transactions 246 | | | PKI users 247 | C | v 248 | R | -------------------+--+-----------+---------------- 249 | L | ^ ^ 250 | | | | PKI management 251 | | v | entities 252 | R | +------+ | 253 | e | <---------------------| RA | <---+ | 254 | p | Publish certificate +------+ | | 255 | o | | | 256 | s | | | 257 | I | v v 258 | t | +------------+ 259 | o | <------------------------------| CA | 260 | r | Publish certificate +------------+ 261 | y | Publish CRL ^ 262 | | | 263 +---+ Management | 264 transactions | 265 v 266 +------+ 267 | CA | 268 +------+ 269 Figure 1 - PKI Entities 271 3.3 X.509 certificates 273 ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8, which was 274 first published in 1988 as part of the X.500 Directory recommendations, 275 defines a standard certificate format [X.509]. The certificate format in 276 the 1988 standard is called the version 1 (v1) format. 278 When X.500 was revised in 1993, two more fields were added, resulting in 279 the version 2 (v2) format. These two fields may be used to support 280 directory access control. 282 The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993, 283 include specifications for a public key infrastructure based on X.509v1 284 certificates [RFC 1422]. The experience gained in attempts to deploy 285 RFC 1422 made it clear that the v1 and v2 certificate formats are 286 deficient in several respects. Most importantly, more fields were 287 needed to carry information which PEM design and implementation 288 experience has proven necessary. In response to these new requirements, 289 ISO/IEC/ITU and ANSI X9 developed the X.509 version 3 (v3) certificate 290 format. The v3 format extends the v2 format by adding provision for 291 additional extension fields. Particular extension field types may be 292 specified in standards or may be defined and registered by any 293 organization or community. In June 1996, standardization of the basic v3 294 format was completed [X.509]. 296 ISO/IEC/ITU and ANSI X9 have also developed standard extensions for use 297 in the v3 extensions field [X.509][X9.55]. These extensions can convey 298 such data as additional subject identification information, key 299 attribute information, policy information, and certification path 300 constraints. However, the ISO/IEC/ITU and ANSI X9 standard extensions 301 are very broad in their applicability. In order to develop 302 interoperable implementations of X.509 v3 systems for Internet use, it 303 is necessary to specify a profile for use of the X.509 v3 extensions 304 tailored for the Internet. It is one goal of PKIX to specify a profile 305 for Internet WWW, electronic mail, and IPsec applications. Environments 306 with additional requirements may build on this profile or may replace it. 308 3.4 Functions of a PKI 310 This section describes the major functions of a PKI. In some cases, 311 PKIs may provide extra functions. 313 3.4.1 Registration 315 This is the process whereby a subject first makes itself known to a CA 316 (directly, or through an RA), prior to that CA issuing a certificate or 317 certificates for that subject. Registration involves the subject 318 providing its name (e.g., common name, fully-qualified domain name, IP 319 address), and other attributes to be put in the certificate, followed 320 by the CA (possibly with help from the RA) verifying in accordance with 321 its CPS that the name and other attributes are correct. 323 3.4.2 Initialization 325 Initialization is when the subject - e.g., the user or client system - 326 gets the values needed to begin communicating with the PKI. For 327 example, initialization can involve providing the client system with the 328 public key and/or certificate of a CA, or generating the client system's 329 own public/private key pair. 331 3.4.3 Certification 333 This is the process in which a CA issues a certificate for a subject's 334 public key, and returns that certificate to the subject and/or posts 335 that certificate in a repository. 337 3.4.4 Key Pair Recovery 339 In some implementations, key exchange or encryption keys will be 340 required by local policy to be "backed up", or recoverable in case the 341 key is lost and access to previously-encrypted information is needed. 342 Such implementations can include those where the private key exchange 343 key is stored on a hardware token which can be lost or broken, or when 344 a private key file is protected by a password which can be forgotten. 345 Often, a company is concerned about being able to read mail encrypted 346 by or for a particular employee when that employee is no longer 347 available because she is ill or no longer works for the company. 349 In these cases, the user's private key can be backed up by a CA or by a 350 separate key backup system. If a user or her employer needs to recover 351 these backed up key materials, the PKI must provide a system that 352 permits the recovery WITHOUT providing an unacceptable risk of 353 compromise of the private key. 355 3.4.5 Key Generation 357 Depending on the CA's policy, the private/public key pair can either be 358 generated by the user in his local environment, or generated by the CA. 359 In the latter case, the key material may be distributed to the user in 360 an encrypted file or on a physical token - e.g., a smart card or PCMCIA 361 card. 363 3.4.6 Key Update 365 All key pairs need to be updated regularly, i.e., replaced with a new 366 key pair, and new certificates issued. This will happen in two cases: 367 normally, when a key has passed its maximum usable lifetime; and 368 exceptionally, when a key has been compromised and must be replaced. 370 In the normal case, a PKI needs to provide a facility to gracefully 371 transition from a certificate with an existing key to a new certificate 372 with a new key. This is particularly true when the key to be updated is 373 that of a CA. Users will know in advance that the key will expire on a 374 certain date; the PKI, working together with certificate-using 375 applications, should allow for appropriate keys to work before and after 376 the transition. There are a number of ways to do this; see [insert 377 appropriate reference here] for an example of one. 379 In the case of a key compromise, the transition will not be "graceful" 380 in that there will be an unplanned switch of certificates and keys; 381 users will not have known in advance what was about to happen. Still, 382 the PKI must support the ability to declare that the previous 383 certificate is now invalid and shall not be used, and to announce the 384 validity and availability of the new certificate. 386 Note, however, that the compromise of a private key associated with a 387 self-signed rootCA certificate is always catastrophic. That is, once 388 the rootCA's private signature key has been compromised, there is no way 389 to reliably convince users and subordinate CA's to accept a new key for 390 the rootCA. If the key is compromised, any "update" message telling 391 subordinates to switch to a new key could have come from an attacker in 392 possession of the old key, and could point to a new public key for which 393 the attacker already has the private key. 395 When a rootCA's private signature key is compromised, the only option is 396 dismantling the entire infrastructure subordinate to that rootCA and 397 starting over again from scratch. It is possible to have anticipated 398 this event, and "pre-placed" replacement rootCA keys with all relying 399 parties, but some secure, out-of-band mechanism will have to be used to 400 tell users to make the switch, and this will only help if the 401 replacement key has not been compromised. 403 3.4.7 Cross-certification 405 A cross-certificate is a certificate issued by one CA to another CA 406 which contains a public CA key associated with the private CA signature 407 key used for issuing certificates. Typically, a cross-certificate is 408 used to allow client systems/end entities in one administrative domain 409 to communicate security with client systems/end users in another 410 administrative domain. Use of a cross-certificate issued from CA_1 to 411 CA_2 allows user Alice, who trusts CA_1, to accept a certificate used by 412 Bob, which was issued by CA_2. (Note: cross-certificates can also be 413 issued from one CA to another CA in the same administrative domain, if 414 required.) 416 Cross-certificates can be issued in only one direction, or in both 417 directions, between two CA's. That is, just because CA_1 issues a 418 cross-certificate for CA_2 does not require CA_2 to issue a 419 cross-certificate for CA_1. 421 3.4.8 Revocation 423 When a certificate is issued, it is expected to be in use for its entire 424 validity period. However, various circumstances may cause a certificate 425 to become invalid prior to the expiration of the validity period. Such 426 circumstances include change of name, change of association between 427 subject and CA (e.g., an employee terminates employment with an 428 organization), and compromise or suspected compromise of the 429 corresponding private key. Under such circumstances, the CA needs to 430 revoke the certificate. 432 X.509 defines one method of certificate revocation. This method 433 involves each CA periodically issuing a signed data structure called a 434 certificate revocation list (CRL). A CRL is a time stamped list 435 identifying revoked certificates which is signed by a CA and made freely 436 available in a public repository. Each revoked certificate is 437 identified in a CRL by its certificate serial number. When a 438 certificate-using system uses a certificate (e.g., for verifying a 439 remote user's digital signature), that system not only checks the 440 certificate signature and validity but also acquires a suitably-recent 441 CRL and checks that the certificate serial number is not on that CRL. 442 The meaning of "suitably-recent" may vary with local policy, but it 443 usually means the most recently-issued CRL. A CA issues a new CRL on a 444 regular periodic basis (e.g., hourly, daily, or weekly). CA's may also 445 issue CRLs aperiodically; e.g., if an important key is deemed 446 compromised, the CA may issue a new CRL to expedite notification of that 447 fact, even if the next CRL does not have to be issued for some time. 448 (A problem of aperiodic CRL issuance is that end-entities may not know 449 that a new CRL has been issued, and thus may not retrieve it from a 450 repository.) 452 An entry is added to the CRL as part of the next update following 453 notification of revocation. An entry may be removed from the CRL after 454 appearing on one regularly scheduled CRL issued beyond the revoked 455 certificate's validity period. 457 An advantage of the CRL revocation method is that CRLs may be 458 distributed by exactly the same means as certificates themselves, 459 namely, via untrusted communications and server systems. 461 One limitation of the CRL revocation method, using untrusted 462 communications and servers, is that the time granularity of revocation 463 is limited to the CRL issue period. For example, if a revocation is 464 reported now, that revocation will not be reliably notified to 465 certificate-using systems until the next CRL is issued -- this may be up 466 to one hour, one day, or one week depending on the frequency that the CA 467 issues CRLs. 469 As with the X.509 v3 certificate format, in order to facilitate 470 interoperable implementations from multiple vendors, the X.509 v2 CRL 471 format needs to be profiled for Internet use. It is one goal of PKIX to 472 specify that profile. However, PKIX does not require CAs to issue CRLs. 473 Message formats and protocols supporting on-line revocation notification 474 may be defined in other PKIX specifications. On-line methods of 475 revocation notification may be applicable in some environments as an 476 alternative to the X.509 CRL. 478 On-line revocation checking may significantly reduce the latency 479 between a revocation report and the distribution of the information 480 to relying parties. Once the CA accepts the report as authentic and 481 valid, any query to the on-line service will correctly reflect the 482 certificate validation impacts of the revocation. However, these 483 methods impose new security requirements; the certificate validator 484 must trust the on-line validation service while the repository does not 485 need to be trusted. 487 3.4.9 Certificate and Revocation Notice Distribution/Publication 489 As alluded to in sections 3.4.3 and 3.4.8 above, the PKI is responsible 490 for the distribution of certificates and certificate revocation notices 491 (whether in CRL form or in some other form) in the system. 492 "Distribution" of certificates includes transmission of the certificate 493 to its owner, and may also include publication of the certificate in a 494 repository. "Distribution" of revocation notices may involve posting 495 CRLs in a repository, transmitting them to end-entities, and/or 496 forwarding them to on-line responders. 498 3.5 Parts of PKIX 500 This section identifies the four different areas in which the PKIX 501 working group has developed documents. The first area involves profiles 502 of the X.509 v3 certificate standards and the X.509v2 CRL standards for 503 the Internet. The second area involves operational protocols, in which 504 relying parties can obtain information such as certificates or 505 certificate status. The third area covers management protocols, in 506 which different entities in the system exchange information needed for 507 proper management of the PKI. The last area provides information about 508 certificate policies and certificate practice statements, covering the 509 areas of PKI security not directly addressed in the rest of PKIX. 511 3.5.1 Profile 513 An X.509v3 certificate is a very complex data structure. It consists of 514 basic information fields, plus a number of optional certificate 515 extensions. Many of the fields and numerous extensions can take on a 516 wide range of options. This provides an enormous degree of flexibility, 517 which allows the X.509v3 certificate format to be used with a wide range 518 of applications in a wide range of environments. Unfortunately, this 519 same flexibility makes it extremely difficult to produce independent 520 implementations that will actually interoperate with one another. In 521 order to build an Internet PKI based on X.509v3 certificates, the PKIX 522 working group had to develop a profile of the X.509v3 specification. 524 A profile of the X.509v3 specification is a description of the contents 525 of the certificate and which certificate extensions must be supported, 526 which extensions may be supported, and which extensions may not be 527 supported. [PKIX-1] provides such a profile of X.509v3 for the Internet 528 PKI. In addition, [PKIX-1] suggests ranges of values for many of the 529 extensions. 531 [PKIX-1] also provides a profile for Version 2 CRLs for use in the 532 Internet PKI. CRLs, like certificates, have a number of optional 533 extensions. In order to promote interoperability, it is necessary to 534 constrain the choices an implementor supports. 536 In addition to profiling the certificate and CRL formats, it is 537 necessary to specify particular Object Identifiers (OIDs) for certain 538 encryption algorithms, because there are a variety of OIDs registered 539 for some algorithm suites. Thus, PKIX has produced at least two 540 documents ([ECDSA] and [KEA]) which provide guidance on the proper 541 implementation of specific algorithms. 543 3.5.2 Operational Protocols 545 Operational protocols are required to deliver certificates and CRLs 546 (or other certificate status information) to certificate using systems. 547 Provision is needed for a variety of different means of certificate and 548 CRL delivery, including distribution procedures based on LDAP, HTTP, 549 FTP, and X.500. Operational protocols supporting these functions are 550 defined in other [FTP], [OCSP],[LDAP], and [WEB]. 552 3.5.3 Management Protocols 554 Management protocols are required to support on-line interactions 555 between PKI user and management entities. For example, a management 556 protocol might be used between a CA and a client system with which a 557 key pair is associated, or between two CAs which cross-certify each 558 other. A management protocol can be used to carry user or client 559 system registration information, or a request for revocation of a 560 certificate. 562 There are two parts to a "management protocol". The first is the format 563 of the messages that will be sent, and the second is the actual protocol 564 that governs the transmission of those messages. The PKIX working group 565 has developed two documents ([CRMF] and [CMMF]) that together describe 566 the necessary set of message, and two other documents ([CMP] and [CMC]) 567 that describe protocols for exchanging those messages. 569 3.5.4 Policy Outline 571 As mentioned before, profiling certificates and specifying operational 572 and management protocols only addresses a part of the problem of 573 actually developing and implementing a secure PKI. What is also needed 574 is the development of a certificate policy and certification practice 575 statement, and then following those documents. The CP and CPS should 576 address physical and personnel security, subject identification 577 requirements, revocation policy, and a number of other topics. [PKIX-4] 578 provides a framework for certification practice statements. 580 4 PKIX Documents 582 This section describes each of the documents written by the PKIX working 583 group. As PKIX progresses, this section will need to be continually 584 updated to reflect the status of each document (e.g., Proposed Standard, 585 Draft Standard, Standard, Informational Draft, Informational RFC, 586 something-that-was-just-thrown-out-for-consideration, etc.) 588 4.1 Profile 590 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate and 591 CRL Profile 593 DESCRIPTION: This document describes the profiles to be used for 594 X.509v3 certificates and version2 CRLs by Internet PKI participants. The 595 profiles include the identification of ISO/IEC/ITU and ANSI extensions 596 which may be useful in the Internet PKI. The profiles are presented in 597 the 1988 Abstract Syntax Notation One (ASN.1) rather than the 1994 598 syntax used in the ISO/IEC/ITU standards. Would-be PKIX implementors 599 and developers of certificate-using applications should start with 600 [PKIX-1] to ensure that their systems will be able to interoperate with 601 other users of the PKI. 603 [PKIX-1]also includes path validation procedures. The procedures 604 presented are based upon the ISO/IEC/ITU definition, but the 605 presentation assumes one or more self-signed trusted CA certificates. 606 The procedures are provided as examples only. Implementations are not 607 required to use the procedures provided; they may implement whichever 608 procedures are efficient for their situation. However, implementations 609 are required to derive the same results as the example procedures. 611 STATUS: 613 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure: 614 Representation of Elliptic Curve Digital Signature Algorithm (ECDSA) 615 Keys and Signatures in Internet X.509 Public Key Infrastructure 616 Certificates 618 DESCRIPTION: This document provides Object Identifiers (OIDs) and other 619 guidance for IPKI users who use the Elliptic Curve Digital Signature 620 Algorithm (ECDSA). It profiles the format and semantics of the 621 subjectPublicKeyInfo field and the keyUsage extension in X.509 V3 622 certificates containing ECDSA keys. This document should be used by 623 anyone wishing to support ECDSA; others who do not support ECDSA are not 624 required to comply with it. 626 STATUS: 628 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Representation 629 of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key 630 Infrastructure Certificates 632 DESCRIPTION: This document provides Object Identifiers (OIDs) and other 633 guidance for IPKI users who use the Key Exchange Algorithm (KEA). It 634 profiles the format and semantics of the subjectPublicKeyInfo field and 635 the keyUsage extension in X.509 V3 certificates containing KEA keys. 636 This document should be used by anyone wishing to support KEA; others 637 who do not support ECDSA are not required to comply with it. 639 STATUS: 641 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure OPEN CRL 642 DISTRIBUTION PROCESS (OpenCDP) 644 DESCRIPTION: This document proposes an alternative to the CRL 645 Distribution Point (CDP) approach documented in [PKIX-1]. OCDP separates 646 the CRL location function from the process of certificate and CRL 647 validation, and thus claims some benefits over the CDP approach. 649 STATUS: 651 4.2 Operational Protocols 653 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Operational 654 Protocols - LDAPv2 656 DESCRIPTION: This document describes the use of LDAPv2 as a protocol 657 for PKI elements to publish and retrieve certificates and CRLs from a 658 certificate repository. LDAPv2 [RFC abcd] is a protocol that allows 659 publishing and retrieving of information. 661 STATUS: 663 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure LDAPv2 Schema 664 666 DESCRIPTION: This document defines a minimal schema necessary to 667 support the use of LDAPv2 for certificate and CRL retrieval and related 668 functions for PKIX. This document supplements [LDAP] by identifying the 669 PKIX-related attributes that must be present. 671 STATUS: 673 DOCUMENT TITLE: X.509 Internet Public Key Infrastructure Online 674 Certificate Status Protocol - OCSP 676 DESCRIPTION: This document specifies a protocol useful in determining 677 the current status of a certificate without the use of CRLs. A major 678 complaint about certificate-based systems is the need for a relying 679 party to retrieve a current CRL as part of the certificate validation 680 process. Depending on the size of the CRL, this can cause severe 681 problems for bandwidth-challenged devices. Depending on the frequency 682 of CRL issuance, this can also cause timeliness problems. (E.g., if 683 CRLs are only published weekly, with no interim releases, a certificate 684 could actually have been revoked for just short of one week without it 685 being on the current CRL, and thus improper use of that certificate 686 could still be occurring.) 688 OCSP attempts to address those problems. It provides a mechanism 689 whereby a relying party identifies one or more certificates to an 690 approved OCSP "responder", and the responder sends back the current 691 status of the certificate(s) - e.g., "revoked", "notRevoked", "unknown". 692 This can dramatically reduce the bandwidth required to transmit 693 revocation status - a relying party does not have to retrieve a CRL of 694 many entries to check the status of one certificate. It can (although 695 it is not guaranteed to) improve the timeliness of revocation 696 notification, and thus reduce the window of opportunity for someone 697 trying to use a revoked certificate. 699 STATUS: 701 DOCUMENT TITLE: Internet Public Key Infrastructure: Caching the Online 702 Certificate Status Protocol 704 DESCRIPTION: To improve the degree to which it can scale, OCSP allows 705 caching of responses - e.g., at intermediary servers, or even at the 706 relying party's end system. This document describes how to support OCSP 707 caching at intermediary servers. 709 STATUS: 711 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Operational 712 Protocols: FTP and HTTP 714 DESCRIPTION: This document describes the use of the File Transfer 715 Protocol (FTP) and the Hyper-text Transfer Protocol (HTTP) to obtain 716 certificates and CRLs from PKI repositories. 718 STATUS: 720 DOCUMENT TITLE: WEB based Certificate Access Protocol-- WebCAP/1.0 722 DESCRIPTION: This document specifies a set of methods, headers, and 723 content-types ancillary to HTTP/1.1 to publish, retrieve X.509 724 certificates and Certificate Revocation Lists. This protocol also 725 facilitates determining current status of a digital certificate without 726 the use of CRLs. This protocol defines new methods, request and 727 response bodies, error codes to HTTP/1.1 protocol for securely 728 publishing, retrieving, and validating certificates across a firewall. 730 STATUS: 732 4.3 Management Protocols 734 DOCUMENT TITLE: Certificate Management Messages over CMS 735 737 DESCRIPTION: This document defines the means by which PKI clients and 738 servers may exchange PKI messages when using S/MIME's Cryptographic 739 Message Syntax [CMS]as a transaction envelope. CMC supports message 740 bodies specified in the Certificate Management Message Formats [CMMF] 741 and Certificate Request Message Format [CRMF] documents. The purpose of 742 this specification is to allow the use of an existing protocol (S/MIME) 743 as a PKI management protocol, rather than requiring the development of a 744 new, custom protocol for the task. 746 STATUS: 748 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate 749 Management Message Formats 751 DESCRIPTION: This document contains the formats for a series of 752 messages important in certificate/PKI management. These messages let 753 CA's, RA's, and relying parties communicate with each other. Note that 754 this document only specifies message formats; it does not specify a 755 protocol for transferring messages. That protocol can be either CMP or 756 CMC, or perhaps another custom protocol. 758 STATUS: 760 DOCUMENT TITLE: Internet X.509 Certificate Request Message Format 761 763 DESCRIPTION: CRMF specifies a format recommended for use whenever a 764 relying party is requesting a certificate from a CA or requesting that 765 an RA help it get a certificate. This document is distinct from CMMF 766 for historical reasons - the request message format was needed before 767 many of the other message formats had to be finalized, and so it was put 768 into a separate document. Like CMMF, this document only specifies the 769 format of a message. Specification of a protocol to transport that 770 message is beyond the scope of CRMF. 772 STATUS: 774 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate 775 Management Protocols 777 DESCRIPTION: This document specifies a new protocol specifically 778 developed for the purpose of transporting messages like those specified 779 in CMMF and CRMF among PKI elements. In general, CMP will be used in 780 conjunction with CMMF and CRMF, and will then be run over a transfer 781 service (e.g., S/MIME, HTTP) to provide a complete PKI management 782 service. 784 STATUS: 786 4.4 Policy Outline 788 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate 789 Policy and Certification Practices Framework 790 792 DESCRIPTION: As noted before, the specification and implementation of 793 certificate profiles, operational protocols, and management protocols 794 is only part of building a PKI. Equally as important - if not more 795 important - is the development and enforcement of a certificate security 796 policy, and a Certification Practice Statement (CPS). The purpose of 797 this document (PKIX-4) is to establish a clear relationship between 798 certificate policies and(CPSs), and to present a framework to assist the 799 writers of certificate policies or CPSs with their tasks. In 800 particular, the framework identifies the elements that may need to be 801 considered in formulating a certificate policy or a CPS. The purpose is 802 not to define particular certificate policies or CPSs, per se. 804 STATUS: 806 4.5 DOCUMENT RELATIONSHIPS 808 Figure 2 shows graphically the relationships among the PKIX documents. 810 CERT and CRL PROFILES 811 Certificate and CRL Profile 812 | 813 +--- Representation of Elliptic Curve Digital Signature Algorithm 814 | (ECDSA)Keys and Signatures in Internet X.509 815 | Public Key Infrastructure Certificates 816 +--- Representation of Key Exchange Algorithm (KEA) Keys in 817 | Internet X.509 Public Key Infrastructure Certificates 818 +--- OPEN CRL DISTRIBUTION PROCESS (OpenCDP) 820 Operational Protocols 821 | 822 +---------- Internet X.509 Public Key Infrastructure Operational 823 | Protocols - LDAPv2 824 | | 825 | +----- Internet X.509 Public Key Infrastructure LDAPv2 826 | Schema 827 | 828 +--+- X.509 Internet Public Key Infrastructure Online Certificate 829 | | Status Protocol - OCSP 830 | | 831 | +-- Internet Public Key Infrastructure: Caching the Online 832 | Certificate Status Protocol 833 | 834 +------- Internet X.509 Public Key Infrastructure Operational 835 | Protocols: FTP and HTTP 836 | 837 +------- WEB based Certificate Access Protocol-- WebCAP/1.0 839 Management Protocols 840 | 841 +--- Message Formats 842 | | 843 | +--- Internet X.509 Public Key Infrastructure Certificate 844 | | Management Message Formats 845 | +--- Internet X.509 Certificate Request Message Format 846 | 847 | 848 +--- Protocols 849 | 850 +--- Internet X.509 Public Key Infrastructure Certificate 851 | Management Protocols 852 +--- Certificate Management Messages over CMS 853 855 Policy Outline 856 | 857 +-- Internet X.509 Public Key Infrastructure Certificate Policy and 858 Certification Practices Framework 860 Figure 2: Document Relationships 862 5 Advice to Implementors 864 This section provides guidance to those who would implement various 865 parts of the PKIX suite of documents. The topics discussed in this 866 section engendered significant discussion in the working group, and 867 there was at times either widespread disagreement or widespread 868 misunderstanding of them. Thus, this discussion is provided to help 869 readers of the PKIX document set understand these issues, in the hope of 870 fostering greater interoperability among eventual PKIX implementations. 872 5.1 Names 874 PKIX has been referred to as a "name-centric" PKI because the 875 certificates associate public keys with names of entities. Each 876 certificate contains at least one name for the owner of a particular 877 public key. The name can be an X.500 distinguished name, contained in 878 the subjectDN field of the certificate. There can also be names such as 879 RFC822 e-mail addresses, DNS domain names, and URIs associated with the 880 key; these attributes are kept in the subjectAltName extension of the 881 certificate. A certificate must contain at least one of these name 882 forms, it may contain multiple forms if deemed appropriate by the CA 883 based on the intended usage of the certificate. 885 5.1.1 Name Forms 887 There are two possible places to put a name in an X.509v3 certificate. 888 One is the subject field in the base certificate (often called the 889 "Distinguished Name" or "DN" field), and the other is in the 890 subjectAltName extension. 892 5.1.1.1 Distinguished Names 894 According to [PKIX-1], a PKIX certificate must have a non-null value in 895 the Distinguished Name field, except for an end-entity certificate, 896 which is permitted to have an empty DN field. 898 5.1.1.2 SubjectAltName Forms 900 In addition to the DN, a PKIX certificate may have one or more values in 901 the subjectAltName extension. 903 The subjectAltName extension allows additional identities to be bound to 904 the subject of the certificate - e.g., it allows "umbc.edu" and 905 "130.85.1.3" to be associated with a particular subject, as well as 906 "C=US, O=University of Maryland, L=Baltimore, CN=UMBC". X.509-defined 907 options for this extension include: Internet electronic mail addresses; 908 DNS names; IP addresses; and uniform resource indentifiers (URIs). 909 Other options can exist, including locally-defined name forms. 911 A single subjectAltName extension can include multiple name forms, and 912 multiple instances of each name form. 914 Note: whenever such Alternate Name forms are to be bound into a 915 certificate, the subject alternative name (or issuer alternative name) 916 extension must be used. It is technically possible to embed an 917 Alternate Name Form in the subject field. For example, one could make a 918 DN contain an IP address via a kludge such as "C=US, L=Baltimore, 919 CN=130.85.1.3". However, this usage is deprecated; the alternative name 920 extension is the preferred location for finding such information.) 922 In line with this, if the only subject identity included in a 923 certificate is an alternative name form, then the subject distinguished 924 name must be empty (technically, an empty sequence), and the 925 subjectAltName extension must be present. If the subject field contains 926 an empty sequence, the subjectAltName extension must be marked critical. 928 If the subjectAltName extension is present, the sequence must contain at 929 least one entry. Unlike the subject field, conforming CAs shall not 930 issue certificates with subjectAltNames containing empty GeneralName 931 fields. For example, an rfc822Name is represented as an IA5String. While 932 an empty string is a valid IA5String, such an rfc822Name is not 933 permitted by PKIX. The behavior of clients that encounter such a 934 certificate when processing a certification path is not defined by this 935 working group. 937 Because the subject alternative name is considered to be definitively 938 bound to the public key, all parts of the subject alternative name must 939 be verified by the CA. 941 5.1.1.2.1 Internet e-mail addresses 943 When the subjectAltName extension contains an Internet mail address, the 944 adress is included as an rfc822Name. The format of an rfc822Name is an 945 "addr-spec" as defined in RFC 822 [RFC 822]. An addr-spec has the form 946 local-part@domain; it does not have a phrase (such as a common name) 947 before it, or a comment (text surrounded in parentheses) after it, and 948 it is not surrounded by "<" and ">". 950 5.1.1.2.2 DNS Names 952 When the subjectAltName extension contains a domain name service label, 953 the domain name is stored in the dNSName attribute(an IA5String). The 954 string shall be in the "preferred name syntax," as specified by RFC 1034 955 [RFC 1034]. Note that while upper and lower case letters are allowed in 956 domain names, no signifigance is attached to the case. In addition, 957 while the string " " is a legal domain name, subjectAltName extensions 958 with a dNSName " " are not permitted. Finally, the use of the DNS 959 representation for Internet mail addresses (wpolk.nist.gov instead of 960 wpolk@nist.gov) is not permitted; such identities are to be encoded as 961 rfc822Name. 963 5.1.1.2.3 IP addresses 965 When the subjectAltName extension contains an iPAddress, the address 966 shall be stored in the octet string in "network byte order," as 967 specified in RFC 791 [RFC 791]. The least significant bit (LSB) of each 968 octet is the LSB of the corresponding byte in the network address. For 969 IP Version 4, as specified in RFC 791, the octet string must contain 970 exactly four octets. For IP Version 6, as specified in RFC 1883, the 971 octet string must contain exactly sixteen octets [RFC1883]. 973 5.1.1.2.4 URIs 975 (is there any guidance about URIs as name forms?) 977 5.1.2 Scope of Names 979 The original X.500 work presumed that every subject in the world would 980 have a globally-unique distinguished name. Thus, every subject could 981 be easily located, and there would never be a conflict. All that would 982 be needed is a sufficiently-large name space, and rules for constructing 983 names based on subordination and location. 985 Obviously, that is not practical in the real world, for a variety of 986 reasons. There is no single entity in the world trusted by everybody to 987 reside at the top of the name space, and there is no way to enforce 988 uniqueness on names for all entities. (These were among the reasons for 989 the failure of PEM to be widely implemented.) 991 This does not mean, however, that a name-based PKI cannot work. It is 992 important to recognize that the scope of names in PKIX is local; they 993 need to be defined and unique only within their own domain. 995 Suppose for example that a rootCA is established with DN "O=IETF, 996 OU=PKIX, CN=PKIX_CA". That CA will then issue certificates for names 997 subordinate to it. The only requirement - and this can be enforced 998 procedurally - is that no two distinct entities beneath this rootCA have 999 the same name. We can't prevent somebody else in the world from creating 1000 her own CA, called "O=IETF, OU=PKIX, CN=PKIX_CA", and it is not 1001 necessary to do so. Within the domain of the original rootCA, there 1002 will be no conflict, and the fact that there is another CA of the same 1003 name in some other domain is irrelevant. 1005 This is analogous to the current DNS or IP address situations. On the 1006 Internet, there is only one node called www.ietf.org. The fact that 1007 there might be 10 different intranets, each with a host given the DNS 1008 name www.ieft.org, is irrelevant and causes no interoperability problems 1009 - those are different domains. However, if there were to be another 1010 node on the Internet with domain name www.ietf.org, then there would be 1011 a problem due to name duplication. 1013 The same applies for IP addresses. As long as only one node on the 1014 Internet responds to the IP address 130.85.1.3, there is no problem, 1015 despite the fact that there are 100 different corporate Intranets, each 1016 using that same IP address. However, if two different nodes on the 1017 Internet each responded to the IP address 130.85.1.3, there would be a 1018 problem. 1020 5.1.3 Certificate Path Construction 1022 Path construction - make point that there is no single best way to 1023 construct a path. Implementors can pick the way that is most efficient 1024 for them. Discuss some of the issues being hashed out in the "ldap" 1025 discussion on the mail list. If there is ever a resolution, include it 1026 in this section. 1028 5.1.4 Name Constraints 1030 (Note: this section still needs a lot of work.) 1032 A question that has arisen a number of times is "how does one enforce 1033 Name constraints when there is more than one name form in a 1034 certificate?" That is, [PKIX-1] states that: 1036 Subject alternative names may be constrained in the same manner as 1037 subject distinguished names using the name constraints extension as 1038 described in section 4.2.1.11. 1040 What does this mean? Suppose that there is a CA with DN "O=IETF, 1041 OU=PKIX, CN=PKIX_CA", with the subjectAltName extension having dNSName 1042 "PKIX_CA.IETF.ORG". Suppose that that CA has issued a certificate with 1043 an empty DN, with subjectAltName extension having dNSName set to 1044 "PKIX_CA.IETF.ORG", and rfc822Name set to Steve@PKIX_CA.IETF.ORG. The 1045 question is, are name constraints enforced on these two certificates - 1046 is the name of the end-entity certificate considered to be properly 1047 subordinate to the name of the CA? 1049 The answer is "yes". In deciding whether a name form meets name 1050 constraints, the following rules apply: 1051 - for DNs: 1052 - for rfc822Names: 1053 - for dNSNames: 1054 - for URIs: 1055 - for iPaddresses 1057 The general rules are: 1059 If a certificate complies with name constraints in any one of its name 1060 forms, then the certificate is deemed to comply with name constraints. 1062 If a certificate contains a name form that its issuer does not, the 1063 certificate is deemed to comply with name constraints for that name 1064 form. 1066 5.1.5 Wildcards in Name Forms 1068 A "wildcard" in a name form is a placeholder for a set of names; 1069 e.g. "*.mit.edu" meaning "any domain name ending in .mit.edu", and 1070 *@aol.com meaning "email address that uses aol.com". There are many 1071 people who believe that allowing wildcards in name forms in PKIX 1072 certificates would be a useful thing to do, because it would allow a 1073 single certificate to be used by all members of a group. These members 1074 would presumably have attributes in common; e.g., access rights to some 1075 set of resources, and so issuance of a certificate with a wildcard for 1076 the group would simplify management. 1078 After much discussion, the PKIX working group decided to permit the use 1079 of wildcards in certificates. That is, it is permissible for a 1080 PKIX-conformant CA to issue a certificate with a wildcard. However, 1081 the semantics of subject alternative names that include wildcard 1082 characters are not addressed by PKIX. Applications with specific 1083 requirements may use such names but must define the semantics. 1085 5.1.6 Name Encoding 1087 (insert a section on encoding non-ASCII names. Key points to make:) 1088 - UTF8 is the long-term goal for IETF, and is mandatory in 2003 and 1089 later 1090 - BMPString is presently supported by most vendors 1091 - Teletexstring containing ISO 8859-1 is also used by many CA's 1093 5.2 POP 1095 - The importance of PoP 1096 - PoP for signature keys vs. PoP for key-management keys 1097 - What the CA/RA has to do 1098 - Different ways of accomplishing this 1100 5.3 Key Usage Bits 1102 The key usage extension defines the purpose (e.g., encipherment, 1103 signature, certificate signing) of the key contained in the certificate. 1104 This extension is used when a key that could be used for more than one 1105 operation is to be restricted. For example, when an RSA key should be 1106 used only for signing, the digitalSignature and/or nonRepudiation bits 1107 would be asserted. Likewise, when an RSA key should be used only for key 1108 management, the keyEncipherment bit would be asserted. When used, this 1109 extension should be marked critical. 1111 The eight bits defined for this extension identify seven mechanisms and 1112 one service, namely: 1113 - digitalSignature 1114 - nonRepudiation 1115 - keyEncipherment 1116 - dataEncipherment 1117 - keyAgreement 1118 - keyCertSign 1119 - cRLSign 1120 - encipherOnly 1121 - decipherOnly 1123 According to [PKIX-1], bits in the KeyUsage type are used as follows: 1125 The digitalSignature bit is asserted when the subject public key is used 1126 to verify digital signatures that have purposes other than 1127 non-repudiation, certificate signature, and CRL signature. For example, 1128 the digitalSignature bit is asserted when the subject public key is used 1129 to provide authentication via the signing of ephemeral data. 1131 The nonRepudiation bit is asserted when the subject public key is used 1132 to verify digital signatures used to provide a non-repudiation service 1133 which protects against the signing entity falsely denying some action, 1134 excluding certificate or CRL signing. 1136 The keyEncipherment bit is asserted when the subject public key is used 1137 for key transport. For example, when an RSA key is to be used for key 1138 management, this bit must asserted. 1140 The dataEncipherment bit is asserted when the subject public key is 1141 used for enciphering user data, other than cryptographic keys. 1143 The keyAgreement bit is asserted when the subject public key is used for 1144 key agreement. For example, when a Diffie-Hellman key is to be used for 1145 key management, this bit must asserted. 1147 The keyCertSign bit is asserted when the subject public key is used for 1148 verifying a signature on certificates. This bit may only be asserted in 1149 CA certificates. 1151 The cRLSign bit is asserted when the subject public key is used for 1152 verifying a signature on revocation information (e.g., a CRL). 1154 The meaning of the encipherOnly bit is undefined in the absence of the 1155 keyAgreement bit. When the encipherOnly bit is asserted and the 1156 keyAgreement bit is also set, the subject public key may be used only 1157 for enciphering data while performing key agreement. 1159 The meaning of the decipherOnly bit is undefined in the absence of the 1160 keyAgreement bit. When the decipherOnly bit is asserted and the 1161 keyAgreement bit is also set, the subject public key may be used only 1162 for deciphering data while performing key agreement. 1164 PKIX does not restrict the combinations of bits that may be set in an 1165 instantiation of the keyUsage extension. 1167 The discussion on the PKIX mailing list has centered on the 1168 digitalSignature bit and the nonRepudiation bit. The question has come 1169 down to something like: When support for the service of non-repudiation 1170 is desired, should both the digitalSignature and nonRepudiation bits be 1171 set, or just the nonRepudiation bit? 1173 (It is noted that provision of the service of non-repudiation requires 1174 more than a single bit set in a certificate. It requires an entire 1175 infrastructure of components to preserve for some period of time the 1176 keys, certificates, revocation status, signed material, etc., as well as 1177 a trusted source of time. However, the nonRepudiation key usage bit is 1178 provided as an indicator that such keys should not be used as a 1179 component of a system providing a non-repudiation service.) 1181 According to [SIMONETTI], the intent is that the digitalSignature bit 1182 should be set when what is desired is the ability to sign ephemeral 1183 transactions; e.g., for a single session authentication. These 1184 transactions are "ephemeral" in the sense that they are important only 1185 while they are in existence; after the session is terminated, there is 1186 no long-term record of the digital signature and its properties kept. 1187 When something is intended to be kept for some period of time, the 1188 nonRepudiation bit should be set. This generally implies that an 1189 application will digitally sign something; thus, some implementors turn 1190 on the digitalSignature bit as well. Other implementors, however, keep 1191 the two bits mutually exclusive, to prevent a single key from being used 1192 for both ephemeral and long-term signing. 1194 While [PKIX-1] is silent on this specific issue, the working group's 1195 general conclusion is that a certificate may have either or both bits 1196 set. If only the nonRepudiation bit is set, the key should not be used 1197 for ephemeral transactions. If only the digitalSignature bit is set, 1198 the key should not be used for long-term signing. If both bits are set, 1199 the key may be used for either purpose. 1201 To actually enforce this requires that an application understands 1202 whether it is signing ephemeral transactions or for the long-term. The 1203 application developers will have to understand the difference, and set 1204 up their checks on the key usage bits field accordingly. For example, 1205 TLS implementors should check only the digitalSignature bit, and ignore 1206 the nonRepudiation bit. S/MIME implementors, though, will have a 1207 difficult choice to make, since their application could be used for 1208 either purpose, and they will generally accept signing using keys 1209 associated with certificates having either or both bits being turned on. 1210 Certification Authorities should know what applications they are 1211 providing certificates for, and provide certificates according to the 1212 requirements of those applications. If CA's are tied into 1213 non-repudiation systems, they may treat certificates differently when 1214 the nonRepudiation bit is turned on (e.g., store information associated 1215 with the certificate - like the user's identification provided during 1216 certificate registration, or certificate generation date/time stamps - 1217 for longer periods of time, in more secure environments). 1219 The bottom line is that this is an area where PKI implementors are 1220 somewhat limited in what they can do. The onus is on developers of 1221 certificate-using systems to understand their requirements, and request 1222 certificates with the appropriate bits set. 1224 5.4 Trust Models 1226 (This section will describe the various trust models that PKIX can 1227 support. It is important to note that PKIX is bound to neither a pure 1228 hierarchical model a la PEM, nor a web of trust model a la PGP. PKIX 1229 can support either of those models, or any flavor in between. The 1230 implications of different trust models should be described: 1231 - efficiency of revocation 1232 - certification path building 1233 - etc.) 1235 6 Acknowledgements 1237 A lot of the information in this document was taken from the PKIX source 1238 documents; the authors of those deserve the credit for their own words. 1239 Other good material was taken from mail posted to the PKIX working group 1240 mail list (ietf-pkix@imc.org). Among those with good things to say were 1241 (in alphabetical order, with apologies to anybody I've missed): Sharon 1242 Boeyen, Santosh Chokhani, Warwick Ford, Russ Housley, Steve Kent, 1243 Ambarish Malpani, Michael Myers, Tim Polk, Stefan Santesson, 1244 Dave Simonetti, 1245 7 References 1247 [CACHE] "Internet Public Key Infrastructure: Caching the Online 1248 Certificate Status Protocol," 1250 [CMC] Myers, M., Liu, X., Fox, B., and Weinstein, J., "Certificate 1251 Management Messages over CMS," , March 1998 1253 [CMMF] Adams, C., and Myers, M., "Internet X.509 Public Key 1254 Infrastructure Certificate Management Message Formats," 1255 , July 1998 1257 [CRMF] Myers, M., Adams, C., Solo, D., and Kemp, D., "Internet X.509 1258 Certificate Request Message Format," , 1259 May 1998 1261 [CMP] Adams, C., and Farrell, S., "Internet X.509 Public Key 1262 Infrastructure Certificate Management Protocols," 1263 , May 1998 1265 [ECDSA] Bassham, L., Johnson, D., and Polk, W., "Internet x.509 Public 1266 Key Infrastructure: Representation of Elliptic Curve Digital Signature 1267 Algorithm (ECDSA) Keys and Signatures in Internet X.509 Public Key 1268 Infrastructure Certificates," , 1269 November 1997 1271 [FTP] Housley, R., and Hoffman, P., "Internet X.509 Public Key 1272 Infrastructure Operational Protocols: FTP and HTTP," 1273 , July 1998 1275 [KEA] Housley, R., and Polk, W., "Internet X.509 Public Key 1276 Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in 1277 Internet X.509 Public Key Infrastructure Certificates," 1278 , 5 August 1998. 1280 [LDAP] Boeyen, S., Howes, T., and Richard, P., "Internet X.509 Public 1281 Key Infrastructure Operational Protocols - LDAPv2," 1282 , March 1998. 1284 [MISPC] Burr, W., Dodson, D., Nazario, N., and Polk, W., "MISPC Minimum 1285 Interoperability Specification for PKI Components, Version 1", September 1286 3, 1997 1288 [OCDP] Hallam-Baker, P., and Ford, W., "Internet X.509 Public Key 1289 Infrastructure Open CRL Distribution Process (OpenCDP)," 1290 , April 1998 1292 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and Adams, C., 1293 "X.509 Internet Public Key Infrastructure Online Certificate Status 1294 Protocol - OCSP," , June 1998. 1296 [PKIX-1] Housley, R., Ford, W., Polk, W., and Solo, D., "Internet X.509 1297 Public Key Infrastructure Certificate and CRL Profile," 1298 , July 28, 1998. 1300 [PKIX-4] Chokhani, S., and Ford, W., "Internet X.509 Public Key 1301 Infrastructure Certificate Policy and Certification Practices 1302 Framework," ; 25 April 1998. 1304 [RFC 791] Postel, J., "Internet Protocol", September 1981. 1306 [RFC 822] Crocker, D., "Standard for the Format of ARPA Internet Text 1307 Messages", August 1982. 1309 [RFC 1034] Mockapetris, P.V., "Domain names - concepts and facilities", 1310 November 1987. 1312 [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic 1313 Mail: Part II: Certificate-Based Key Management," February 1993. 1315 [RFC 1777] Yeong, Y., Howes, T., and Kille, S., "Lightweight Directory 1316 Access Protocol", March 1995 1318 [RFC 1883] Deering, S., and Hinden, R., "Internet Protocol, Version 6 1319 [IPv6] Specification", December 1995. 1321 [SCHEMA] Boeyen, S., Howes, T., and Richard, P., "Internet X.509 Public 1322 Key Infrastructure LDAPv2 Schema," 1323 , March 1998 1325 [SIMONETTI] Simonetti, D., "Re: German Key Usage", posting to 1326 ietf-pkix@imc.org mailing list, 12 August 1998 1328 [WEB] Reddy, S., "WEB based Certificate Access Protocol-- WebCAP/1.0," 1329 , April 19, 1998 1331 [X.509] ITU-T Recommendation X.509 (1997 E): Information Technology - 1332 Open Systems Interconnection - The Directory: Authentication Framework, 1333 June 1997. 1335 [X9.42] ANSI X9.42-199x, Public Key Cryptography for The Financial 1336 Services Industry: Agreement of Symmetric Algorithm Keys Using 1337 Diffie-Hellman (Working Draft), December 1997. 1339 [X9.55] ANSI X9.55-1995, Public Key Cryptography For The Financial 1340 Services Industry: Extensions To Public Key Certificates And Certificate 1341 Revocation Lists, 8 December, 1995. 1343 [X9.57] ANSI X9.57-199x, Public Key Cryptography For The Financial 1344 Services Industry: Certificate Management (Working Draft), 21 June, 1996. 1346 8 Security Considerations 1348 TBSL 1349 9 Editor's Address 1351 Alfred Arsenault 1352 U. S. Department of Defense 1353 9800 Savage Road Suite 6734 1354 Fort George G. Meade, MD 20755-6734 1355 (410) 684-7114 1356 awarsen@missi.ncsc.mil 1358 Sean Turner 1359 IECA, Inc. 1360 9010 Edgepark Road 1361 Vienna, VA 22182 1362 (703) 358-9113 1363 turners@ieca.com 1365 10 Disclaimer 1367 This work constitutes the opinion of the editor only, and may not 1368 reflect the opinions or policies of his employer.