idnits 2.17.00 (12 Aug 2021) /tmp/idnits18405/draft-ietf-pkix-roadmap-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 42 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 8 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1143: '...ubject field, it MUST contain an X.500...' RFC 2119 keyword, line 1174: '... addresses MUST use the rfc822Name i...' RFC 2119 keyword, line 1235: '... the name MUST be stored in the unif...' RFC 2119 keyword, line 1236: '...tring). The name MUST be a non-relativ...' RFC 2119 keyword, line 1244: '... implementations MUST compare the sche...' (1 more instance...) 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'. == Line 223 has weird spacing: '... of the certi...' == Line 1027 has weird spacing: '...ks. In parti...' -- 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 (June 23, 1999) is 8367 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: 'RFC2459' is mentioned on line 651, but not defined ** Obsolete undefined reference: RFC 2459 (Obsoleted by RFC 3280) == Missing Reference: 'RFC1883' is mentioned on line 1230, but not defined ** Obsolete undefined reference: RFC 1883 (Obsoleted by RFC 2460) == Missing Reference: 'RFC 1738' is mentioned on line 1240, but not defined ** Obsolete undefined reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) == Unused Reference: 'BERT1' is defined on line 1803, but no explicit reference was found in the text == Unused Reference: 'CACHE' is defined on line 1806, but no explicit reference was found in the text == Unused Reference: 'CMS' is defined on line 1824, but no explicit reference was found in the text == Unused Reference: 'ETNPT' is defined on line 1837, but no explicit reference was found in the text == Unused Reference: 'OCDP' is defined on line 1845, but no explicit reference was found in the text == Unused Reference: 'DHPOP' is defined on line 1857, but no explicit reference was found in the text == Unused Reference: 'RFC 1883' is defined on line 1879, but no explicit reference was found in the text == Unused Reference: 'IPv6' is defined on line 1880, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BERT1' -- 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. 'CRS' -- Possible downref: Non-RFC (?) normative reference: ref. 'CMS' -- Possible downref: Non-RFC (?) normative reference: ref. 'DCS' -- Possible downref: Non-RFC (?) normative reference: ref. 'ECDSA' -- Possible downref: Non-RFC (?) normative reference: ref. 'ETNPT' -- 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. 'PKCS10' -- Possible downref: Non-RFC (?) normative reference: ref. 'DHPOP' -- Possible downref: Non-RFC (?) normative reference: ref. 'QC' ** 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' ** Obsolete normative reference: RFC 2459 (Obsoleted by RFC 3280) ** Obsolete normative reference: RFC 2510 (Obsoleted by RFC 4210) -- Duplicate reference: RFC2510, mentioned in 'RFC 2511', was also mentioned in 'RFC 2510'. ** Obsolete normative reference: RFC 2510 (ref. 'RFC 2511') (Obsoleted by RFC 4210) ** Obsolete normative reference: RFC 2527 (Obsoleted by RFC 3647) ** Downref: Normative reference to an Informational RFC: RFC 2528 ** Obsolete normative reference: RFC 2559 (Obsoleted by RFC 3494) ** Obsolete normative reference: RFC 2587 (Obsoleted by RFC 4523) -- Possible downref: Non-RFC (?) normative reference: ref. 'SIMONETTI' -- Possible downref: Non-RFC (?) normative reference: ref. 'TSP' -- Possible downref: Non-RFC (?) normative reference: ref. 'WEB' Summary: 23 errors (**), 0 flaws (~~), 17 warnings (==), 23 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 June 23, 1999 8 Internet X.509 Public Key Infrastructure 9 PKIX Roadmap 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of 6 months 23 and may be updated, replaced, or may become obsolete by other 24 documents at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as work in progress. To 26 view the entire list of current Internet-Drafts, please check the 27 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 29 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 30 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 31 Copyright (C) The Internet Society (date). All Rights Reserved. 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 This document provides an overview or 'roadmap' of the work done by 42 the IETF PKIX working group. It describes some of the terminology 43 used in the working group's documents, and the theory behind an 44 X.509-based PKI. It identifies each document developed by the PKIX 45 working group, and describes the relationships among the various 46 documents. It also provides advice to would-be PKIX implementors 47 about some of the issues discussed at length during PKIX development, 48 in hopes of making it easier to build implementations that will 49 actually interoperate. 51 1 Introduction 53 1.1 This Document 55 This document is an informational Internet draft that provides a 56 "roadmap" to the documents produced by the PKIX working group. It is 57 intended to provide information; there are no requirements or 58 specifications in this document. 60 Section 2 of this document defines key terms used in this document. 61 Section 3 covers "PKIX theory"; it explains what the PKIX working 62 group's basic assumptions were. Section 4 provides an overview of 63 the various PKIX documents. It identifies which documents address 64 which areas, and describes the relationships among the various 65 documents. Section 5 contains "Advice to implementors". Its primary 66 purpose is to capture some of the major issues discussed by the PKIX 67 working group, as a way of explaining WHY some of the requirements 68 and specifications say what they say. This should cut down on the 69 number of misinterpretations of the documents, and help developers 70 build interoperable implementations. Section 6 contains a list of 71 references. Section 7 discusses security considerations, and Section 72 8 provides contact information for the editors. 74 1.2 Changes Since the Last Version 76 The major changes in this document since version -00 include: 78 - QC text was updated (section 3.6.1). 80 - Name constraints text was updated (section 5.1.4). 82 - Name encoding text was added (section 5.1.6). 84 - Added Attribute Certificate Profile for Authorizations and DH 85 PoP Algorithms to Profile section (section 4.1). 87 - Added descriptions for BERT and Extending trust in non- 88 repudiation tokens in time to Time Stamp and DCS section (section 89 4.5). 91 - Replaced references to CMP with RFC 2510, CRMF with RFC 2511, 92 PKIX-4 with RFC 2527, KEA with RFC 2528, LDAP with RFC 2559, FTP 93 with RFC 2585, SCHEMA with RFC 2587. 95 - Updates references to current drafts. 97 - Added sections for D-H PoP, Attribute Certificate Profile for 98 Authorizations, Basic Event Representation Token v1, Extending 99 Trust in Non-repudiation tokens in time. 101 2 Terminology 103 There are a number of terms used and misused throughout PKI-related 104 literature. To limit confusion caused by some of those terms, 105 throughout this document, we will use the following terms in the 106 following ways: 108 - Certification Authority (CA) - an authority trusted by one or 109 more users to create and assign certificates. Optionally the 110 certification authority may create the user's keys. (It is 111 important to note that the CA is responsible for the certificates 112 during their whole lifetime, not just for issuing them.) 114 - Certificate policy - a named set of rules that indicates the 115 applicability of a certificate to a particular community and/or 116 class of application with common security requirements. For 117 example, a particular certificate policy might indicate 118 applicability of a type of certificate to the authentication of 119 electronic data interchange transaction s for the trading of goods 120 within a given price range. 122 - Root CA - a CA that is directly trusted by an end entity; that 123 is, securely acquiring the value of a root CA public key requires 124 some out-of-band step(s). This term is not meant to imply that a 125 root CA is necessarily at the top of any hierarchy, simply that 126 the CA in question is trusted directly. 128 - Top CA - a CA that is at the top of a PKI hierarchy. 130 Note: this is often also called a "root CA", from since in data 131 structures terms and in graph theory, the node at the top of a 132 tree is the "root". However, to minimize confusion in this 133 document, we elect to call this node a "Top CA," and reserve 134 "root CA" for the CA directly trusted by the user. Readers new 135 to PKIX should be aware that these terms are not used 136 consistently throughout the PKIX documents, as [RFC2459] uses 137 "root CA" to refer to what this and other documents call a "top 138 CA", and "most-trusted CA" to refer to what this and other 139 documents call a "root CA". 141 - Subordinate CA - A "subordinate CA" is one that is not a root CA 142 for the end entity in question. Often, a subordinate CA will not 143 be a root CA for any entity but this is not mandatory 145 - Registration Authority (RA) - an optional entity given 146 responsibility for performing some of the administrative tasks 147 necessary in the registration of subjects, such as: confirming the 148 subject's identity; validating that the subject is entitled to 149 have the attributes requested in a certificate; and verifying that 150 the subject has possession of the private key associated with the 151 public key requested for a certificate. 153 - End-entity - a subject of a certificate who is not a CA. 155 - Relying party - a user or agent (e.g., a client or server) who 156 relies on the data in a certificate in making decisions. 158 - Subject - a subject is the entity (CA or end-entity) named in a 159 certificate. Subjects can be human users, computers (as 160 represented by DNS names or IP addresses), or even software 161 agents. 163 3 PKIX Theory 165 3.1 Certificate-using Systems and PKIs 167 At the heart of recent efforts to improve Internet security are a 168 group of security protocols such as S/MIME, TLS, and IPSec. All of 169 these protocols rely on public-key cryptography to provide services 170 such as confidentiality, data integrity, data origin authentication, 171 and non-repudiation. The purpose of a PKI is to provide trusted and 172 efficient key- and certificate management, thus enabling the use of 173 authentication, non-repudiation, and confidentiality. 175 Users of public key-based systems must be confident that, any time 176 they rely on a public key, the associated private key is owned by the 177 subject with which they are communicating. (This applies whether an 178 encryption or digital signature mechanism is used.) This confidence 179 is obtained through the use of public key certificates, which are 180 data structures that bind public key values to subjects. The binding 181 is achieved by having a trusted CA verify the subject's identity and 182 digitally sign each certificate. 184 A certificate has a limited valid lifetime which is indicated in its 185 signed contents. Because a certificate's signature and timeliness 186 can be independently checked by a certificate-using client, 187 certificates can be distributed via untrusted communications and 188 server systems, and can be cached in unsecured storage in 189 certificate-using systems. 191 Certificates are used in the process of validating signed data. 192 Specifics vary according to which algorithm is used, but the general 193 process works as follows: 195 Note: there is no specific order in which the checks listed below 196 must be made; implementers are free to implement them in the most 197 efficient way for their systems. 199 - the recipient of signed data verifies that the claimed identity 200 of the user is in accordance wit the identity contained in the 201 certificate; 203 - the recipient validates that no certificate in the path has been 204 revoked (e.g., by retrieving a suitably-current Certificate 205 Revocation List (CRL) or querying an on-line certificate status 206 responder), and that all certificates were within their validity 207 periods at the time the data were signed; 209 - the recipient verifies that the data are not claimed to have any 210 attributes for which the certificate indicates that the signer is 211 not authorized; 213 - the recipient verifies that the data have not been altered since 214 signing, by using the public key in the certificate. 216 If all of these checks pass, the recipient can accept that the data 217 were signed by the purported signer. The process for keys used for 218 encryption is similar. 220 Note: it is of course possible that the data were signed by 221 someone very different from the signer, if for example the 222 purported signer's private key was compromised. Security depends 223 on all parts of the certificate-using SYSTEM, including but not 224 limited to: physical security of the place the computer resides; 225 personnel security (i.e., the trustworthiness of the people who 226 actually develop, install, run, and maintain the system); the 227 security provided by the operating system on which the private key 228 is used; and the security provided the CA. A failure in any one 229 of these areas can cause the entire system security to fail. PKIX 230 is limited in scope, however, and only directly addresses issues 231 related to the operation of the PKI subsystem. For guidance in 232 many of the other areas, see [RFC 2527]. 234 A collection of certificates, with their issuing CA's, subjects, 235 relying parties, RA's, and repositories, is referred to as a Public 236 Key Infrastructure, or PKI. 238 3.2 PKIX History 240 [This still needs more work.] 242 In the beginning there was ITU-T Recommendation X.509. It defines a 243 widely accepted basis for a public-key infrastructure, including data 244 formats and procedures related to distribution of public keys via 245 certificates digitally signed by CAs. X.509 does not however include 246 a profile to specify the support requirements for many of the 247 certificate data structure's sub-fields, for any of the extensions, 248 nor for certain data values. PKIX was formed in October 1995 to 249 deliver a profile for the Internet PKI of X.509 version 3 250 certificates and version 2 CRLs. The Internet PKI profile [RFC 2459] 251 went through eleven draft versions before becoming an RFC. Other 252 profiles have been developed in PKIX for particular algorithms to 253 make use of [RFC 2459]. There has been no sense of conflict between 254 the groups that developed these profiles as they are seen as 255 complimentary. 257 The development of the management protocols has not been so 258 straightforward. [RFC 2510] was developed to define a message 259 protocol that is used between entities in a PKI. The demand for an 260 enrollment protocol and the desire to use PKCS-10 message format as 261 the certificate request syntax lead to the development of two 262 different documents in two different groups. The Certificate Request 263 Syntax [CRS] draft was developed in the SMIME WG which used PKCS10 264 [PKCS10] as the certification request message format. Certificate 265 Request Message Format [RFC 2511] draft was also developed but in the 266 PKIX WG. It was to define a simple enrollment protocol that would 267 subsume both the [RFC 2510] and [CRS] enrollment protocols, but it 268 did not use PKCS10 as the certificate request message format. Then, 269 [CMMF] was developed to define an extended set of management messages 270 that flow between the components of the Internet PKI. CMMF over CMS 271 [CMC] was developed to allow the use of an existing protocol (S/MIME) 272 as a PKI management protocol, without requiring the development of an 273 entirely new protocol such as CMP [RFC 2510]. It also included 274 [PKCS10] as the certificate request syntax, which caused work on 275 [CRS] to stop. Information from [CMMF] has been moved into [RFC 276 2510] and [CMC] so [CMMF] is being discontinued. 278 Development of the operational protocols has been slightly more 279 straightforward. Two documents for LDAPv2 have been developed one 280 for defining LDAPv2 as an access protocol to repositories [RFC 2559] 281 and one for storing PKI information in an LDAP directory [RFC 2587]. 282 Using FTP and HTTP to retrieve certificates and CRL from PKI 283 repositories was documented without a fight in [RFC 2585]. Likewise, 284 methods, headers, and content-types ancillary to HTTP/1.1 to publish 285 and retrieve X.509 certificates and CRLs was documented in [WEB] 286 without much argument. 288 [Need to add text about OpenCDP vs DistributionPoints, Why DCP was 289 started, information on TSP, and OCSP, and caching OCSP.] 291 3.3 Overview of the PKIX Approach 293 PKIX is an effort to develop specifications for a Public Key 294 Infrastructure for the Internet using X.509 certificates. The PKIX 295 working group was initially chartered in 1995. A Public Key 296 Infrastructure, or PKI, is defined as: 298 The set of hardware, software, people, policies and procedures needed 299 to create, manage, store, distribute, and revoke certificates based 300 on public-key cryptography. 302 A PKI consists of five types of components [MISPC]: 304 - Certification Authorities (CAs) that issue and revoke 305 certificates; 307 - Organizational Registration Authorities (ORAs) that vouch for 308 the binding between public keys and certificate holder identities 309 and other attributes; 311 - Certificate holders that are issued certificates and can sign 312 digital documents; 314 - Clients that validate digital signatures and their certification 315 paths from a known public key of a trusted CA; 317 - Repositories that store and make available certificates and 318 Certificate Revocation Lists (CRLs). 320 Figure 1 is a simplified view of the architectural model assumed by 321 the PKIX Working Group. 323 +---+ 324 | C | +------------+ 325 | e | <-------------------->| End entity | 326 | r | Operational +------------+ 327 | t | transactions ^ 328 | | and management | Management 329 | / | transactions | transactions 330 | | | PKI users 331 | C | v 332 | R | -------------------+--+-----------+---------------- 333 | L | ^ ^ 334 | | | | PKI management 335 | | v | entities 336 | R | +------+ | 337 | e | <---------------------| RA | <---+ | 338 | p | Publish certificate +------+ | | 339 | o | | | 340 | s | | | 341 | I | v v 342 | t | +------------+ 343 | o | <------------------------------| CA | 344 | r | Publish certificate +------------+ 345 | y | Publish CRL ^ 346 | | | 347 +---+ Management | 348 transactions | 349 v 350 +------+ 351 | CA | 352 +------+ 353 Figure 1 - PKI Entities 355 3.4 X.509 certificates 357 ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8, which was 358 first published in 1988 as part of the X.500 Directory 359 recommendations, defines a standard certificate format [X.509]. The 360 certificate format in the 1988 standard is called the version 1 (v1) 361 format. 363 When X.500 was revised in 1993, two more fields were added, resulting 364 in the version 2 (v2) format. These two fields may be used to support 365 directory access control. 367 The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993, 368 include specifications for a public key infrastructure based on 369 X.509v1 certificates [RFC 1422]. The experience gained in attempts 370 to deploy RFC 1422 made it clear that the v1 and v2 certificate 371 formats are deficient in several respects. Most importantly, more 372 fields were needed to carry information which PEM design and 373 implementation experience has proven necessary. In response to these 374 new requirements, ISO/IEC/ITU and ANSI X9 developed the X.509 version 375 3 (v3) certificate format. The v3 format extends the v2 format by 376 adding provision for additional extension fields. Particular 377 extension field types may be specified in standards or may be defined 378 and registered by any organization or community. In June 1996, 379 standardization of the basic v3 format was completed [X.509]. 381 ISO/IEC/ITU and ANSI X9 have also developed standard extensions for 382 use in the v3 extensions field [X.509][X9.55]. These extensions can 383 convey such data as additional subject identification information, 384 key attribute information, policy information, and certification path 385 constraints. However, the ISO/IEC/ITU and ANSI X9 standard 386 extensions are very broad in their applicability. In order to 387 develop interoperable implementations of X.509 v3 systems for 388 Internet use, it is necessary to specify a profile for use of the 389 X.509 v3 extensions tailored for the Internet. It is one goal of 390 PKIX to specify a profile for Internet WWW, electronic mail, and 391 IPsec applications. Environments with additional requirements may 392 build on this profile or may replace it. 394 3.5 Functions of a PKI 396 This section describes the major functions of a PKI. In some cases, 397 PKIs may provide extra functions. 399 3.5.1 Registration 401 This is the process whereby a subject first makes itself known to a 402 CA (directly, or through an RA), prior to that CA issuing a 403 certificate or certificates for that subject. Registration involves 404 the subject providing its name (e.g., common name, fully-qualified 405 domain name, IP address), and other attributes to be put in the 406 certificate, followed by the CA (possibly with help from the RA) 407 verifying in accordance with its CPS that the name and other 408 attributes are correct. 410 3.5.2 Initialization 412 Initialization is when the subject - e.g., the user or client system 413 - gets the values needed to begin communicating with the PKI. For 414 example, initialization can involve providing the client system with 415 the public key and/or certificate of a CA, or generating the client 416 system's own public/private key pair. 418 3.5.3 Certification 420 This is the process in which a CA issues a certificate for a 421 subject's public key, and returns that certificate to the subject 422 and/or posts that certificate in a repository. 424 3.5.4 Key Pair Recovery 426 In some implementations, key exchange or encryption keys will be 427 required by local policy to be "backed up", or recoverable in case 428 the key is lost and access to previously-encrypted information is 429 needed. Such implementations can include those where the private key 430 exchange key is stored on a hardware token which can be lost or 431 broken, or when a private key file is protected by a password which 432 can be forgotten. Often, a company is concerned about being able to 433 read mail encrypted by or for a particular employee when that 434 employee is no longer available because she is ill or no longer works 435 for the company. 437 In these cases, the user's private key can be backed up by a CA or by 438 a separate key backup system. If a user or her employer needs to 439 recover these backed up key materials, the PKI must provide a system 440 that permits the recovery WITHOUT providing an unacceptable risk of 441 compromise of the private key. 443 3.5.5 Key Generation 445 Depending on the CA's policy, the private/public key pair can either 446 be generated by the user in his local environment, or generated by 447 the CA. In the latter case, the key material may be distributed to 448 the user in an encrypted file or on a physical token - e.g., a smart 449 card or PCMCIA card. 451 3.5.6 Key Update 453 All key pairs need to be updated regularly, i.e., replaced with a new 454 key pair, and new certificates issued. This will happen in two 455 cases: normally, when a key has passed its maximum usable lifetime; 456 and exceptionally, when a key has been compromised and must be 457 replaced. 459 In the normal case, a PKI needs to provide a facility to gracefully 460 transition from a certificate with an existing key to a new 461 certificate with a new key. This is particularly true when the key 462 to be updated is that of a CA. Users will know in advance that the 463 key will expire on a certain date; the PKI, working together with 464 certificate-using applications, should allow for appropriate keys to 465 work before and after the transition. There are a number of ways to 466 do this; see [insert appropriate reference here] for an example of 467 one. In the case of a key compromise, the transition will not be 468 "graceful" in that there will be an unplanned switch of certificates 469 and keys; users will not have known in advance what was about to 470 happen. Still, the PKI must support the ability to declare that the 471 previous certificate is now invalid and shall not be used, and to 472 announce the validity and availability of the new certificate. 474 Note: compromise of a private key associated with a rootCA is 475 catastrophic for users relying on that rootCA. If a rootCA's 476 private key is compromised, that CA must be taken down and brought 477 up again with a new key. Until such time as the rootCA is brought 478 back up, though, users relying on that rootCA are cut off from the 479 rest of the system, as there is no way to develop a valid 480 certification path back to a trusted node. 482 Further, users will likely have to be notified by out-of-band 483 mechanisms about the change in CA keys. If the old key is 484 compromised, any "update" message telling subordinates to switch to a 485 new key could have come from an attacker in possession of the old 486 key, and could point to a new public key for which the attacker 487 already has the private key. It is possible to have anticipated this 488 event, and "pre-placed" replacement rootCA keys with all relying 489 parties, but some secure, out-of-band mechanism will have to be used 490 to tell users to make the switch, and this will only help if the 491 replacement key has not been compromised. 493 Additionally, once the rootCA is brought back up with a new key, it 494 will likely be necessary to re-issue certificates, signed with the 495 new key, to all subordinate users, since their current certificate 496 would be signed with a now-revoked key. 498 3.5.7 Cross-certification 500 A cross-certificate is a certificate issued by one CA to another CA 501 which contains a public CA key associated with the private CA 502 signature key used for issuing certificates. Typically, a cross- 503 certificate is used to allow client systems/end entities in one 504 administrative domain to communicate security with client systems/end 505 users in another administrative domain. Use of a cross-certificate 506 issued from CA_1 to CA_2 allows user Alice, who trusts CA_1, to 507 accept a certificate used by Bob, which was issued by CA_2. 509 Note: cross-certificates can also be issued from one CA to another 510 CA in the same administrative domain, if required. 512 Cross-certificates can be issued in only one direction, or in both 513 directions, between two CA's. That is, just because CA_1 issues a 514 cross-certificate for CA_2 does not require CA_2 to issue a cross- 515 certificate for CA_1. 517 3.5.8 Revocation 519 When a certificate is issued, it is expected to be in use for its 520 entire validity period. However, various circumstances may cause a 521 certificate to become invalid prior to the expiration of the validity 522 period. Such circumstances include change of name, change of 523 association between subject and CA (e.g., an employee terminates 524 employment with an organization), and compromise or suspected 525 compromise of the corresponding private key. Under such 526 circumstances, the CA needs to revoke the certificate. 528 X.509 defines one method of certificate revocation. This method 529 involves each CA periodically issuing a signed data structure called 530 a certificate revocation list (CRL). A CRL is a time stamped list 531 identifying revoked certificates which is signed by a CA and made 532 freely available in a public repository. Each revoked certificate is 533 identified in a CRL by its certificate serial number. When a 534 certificate-using system uses a certificate (e.g., for verifying a 535 remote user's digital signature), that system not only checks the 536 certificate signature and validity but also acquires a suitably- 537 recent CRL and checks that the certificate serial number is not on 538 that CRL. The meaning of "suitably-recent" may vary with local 539 policy, but it usually means the most recently-issued CRL. A CA 540 issues a new CRL on a regular periodic basis (e.g., hourly, daily, or 541 weekly). CA's may also issue CRLs aperiodically; e.g., if an 542 important key is deemed compromised, the CA may issue a new CRL to 543 expedite notification of that fact, even if the next CRL does not 544 have to be issued for some time. (A problem of aperiodic CRL issuance 545 is that end-entities may not know that a new CRL has been issued, and 546 thus may not retrieve it from a repository.) 547 An entry is added to the CRL as part of the next update following 548 notification of revocation. An entry may be removed from the CRL 549 after appearing on one regularly scheduled CRL issued beyond the 550 revoked certificate's validity period. 552 An advantage of the CRL revocation method is that CRLs may be 553 distributed by exactly the same means as certificates themselves, 554 namely, via untrusted communications and server systems. 556 One limitation of the CRL revocation method, using untrusted 557 communications and servers, is that the time granularity of 558 revocation is limited to the CRL issue period. For example, if a 559 revocation is reported now, that revocation will not be reliably 560 notified to certificate-using systems until the next CRL is issued -- 561 this may be up to one hour, one day, or one week depending on the 562 frequency that the CA issues CRLs. 564 As with the X.509 v3 certificate format, in order to facilitate 565 interoperable implementations from multiple vendors, the X.509 v2 CRL 566 format needed to be profiled for Internet use. This was done as part 567 of [RFC 2459]. However, PKIX does not require CAs to issue CRLs. On- 568 line methods of revocation notification may be applicable in some 569 environments as an alternative to the X.509 CRL. PKIX defines a 570 protocol known as OCSP [OCSP] to facilitate on-line checking of the 571 status of certificates. 573 On-line revocation checking may significantly reduce the latency 574 between a revocation report and the distribution of the information 575 to relying parties. Once the CA accepts the report as authentic and 576 valid, any query to the on-line service will correctly reflect the 577 certificate validation impacts of the revocation. However, these 578 methods impose new security requirements; the certificate validator 579 must trust the on-line validation service while the repository does 580 not need to be trusted. 582 3.5.9 Certificate and Revocation Notice Distribution/Publication 584 As alluded to in sections x and y above, the PKI is responsible for 585 the distribution of certificates and certificate revocation notices 586 (whether in CRL form or in some other form) in the system. 587 "Distribution" of certificates includes transmission of the 588 certificate to its owner, and may also include publication of the 589 certificate in a repository. "Distribution" of revocation notices 590 may involve posting CRLs in a repository, transmitting them to end- 591 entities, and/or forwarding them to on-line responders. 593 3.6 Parts of PKIX 595 This section identifies the five different areas in which the PKIX 596 working group has developed documents. The first area involves 597 profiles of the X.509 v3 certificate standards and the X.509v2 CRL 598 standards for the Internet. The second area involves operational 599 protocols, in which relying parties can obtain information such as 600 certificates or certificate status. The third area covers management 601 protocols, in which different entities in the system exchange 602 information needed for proper management of the PKI. The fourth area 603 provides information about certificate policies and certificate 604 practice statements, covering the areas of PKI security not directly 605 addressed in the rest of PKIX. The fifth area deals with providing 606 time stamping and data certification services, which can be used to 607 build such services as non-repudiation. 609 3.6.1 Profile 611 An X.509v3 certificate is a very complex data structure. It consists 612 of basic information fields, plus a number of optional certificate 613 extensions. Many of the fields and numerous extensions can take on a 614 wide range of options. This provides an enormous degree of 615 flexibility, which allows the X.509v3 certificate format to be used 616 with a wide range of applications in a wide range of environments. 617 Unfortunately, this same flexibility makes it extremely difficult to 618 produce independent implementations that will actually interoperate 619 with one another. In order to build an Internet PKI based on X.509v3 620 certificates, the PKIX working group had to develop a profile of the 621 X.509v3 specification. 623 A profile of the X.509v3 specification is a description of the 624 contents of the certificate and which certificate extensions must be 625 supported, which extensions may be supported, and which extensions 626 may not be supported. [RFC 2459] provides such a profile of X.509v3 627 for the Internet PKI. In addition, [RFC 2459] suggests ranges of 628 values for many of the extensions. 630 [RFC 2459] also provides a profile for Version 2 CRLs for use in the 631 Internet PKI. CRLs, like certificates, have a number of optional 632 extensions. In order to promote interoperability, it is necessary to 633 constrain the choices an implementor supports. 635 In addition to profiling the certificate and CRL formats, it is 636 necessary to specify particular Object Identifiers (OIDs) for certain 637 encryption algorithms, because there are a variety of OIDs registered 638 for some algorithm suites. Thus, PKIX has produced two documents 639 ([ECDSA] and [RFC 2528]) which provide guidance on the proper 640 implementation of specific algorithms. 642 Certain countries are in a process of updating their legal frameworks 643 in order to regulate and incorporate recognition of signatures in 644 electronic form. Many of these frameworks introduce certain basic 645 requirements on certificates, often termed Qualified Certificates, 646 supporting these types of "legal" signatures. Partly as a result of 647 this there is a need for a specific certificate profile providing 648 standardized support for certain related issues such as a common 649 structure for expressing unambiguous identities of certified subjects 650 (unmistakable identity). In December 1998, PKIX adopted as a work 651 item the development of a refinement of [RFC2459] that further 652 profiles PKIX certificates into qualified certificates. This work is 653 reflected in [QC]. 655 3.6.2 Operational Protocols 657 Operational protocols are required to deliver certificates and CRLs 658 (or other certificate status information) to certificate using 659 systems. Provision is needed for a variety of different means of 660 certificate and CRL delivery, including distribution procedures based 661 on LDAP, HTTP, FTP, and X.500. Operational protocols supporting 662 these functions are defined in [RFC 2585], [OCSP], [RFC 2559], and 663 [WEB]. 665 3.6.3 Management Protocols 667 Management protocols are required to support on-line interactions 668 between PKI user and management entities. For example, a management 669 protocol might be used between a CA and a client system with which a 670 key pair is associated, or between two CAs which cross-certify each 671 other. A management protocol can be used to carry user or client 672 system registration information, or a request for revocation of a 673 certificate. 675 There are two parts to a "management protocol". The first is the 676 format of the messages that will be sent, and the second is the 677 actual protocol that governs the transmission of those messages. 678 Originally, the PKIX working group developed two documents ([RFC 679 2511] and [CMMF]) that together described the necessary set of 680 message formats, and two other documents ([RFC 2510] and [CMC]) that 681 described protocols for exchanging those messages. However, the 682 message formats defined in [CMMF] were inserted into both [RFC 2510] 683 and [CMC], and thus [CMMF] will be dropped as a PKIX document. 685 3.6.4 Policy Outline 687 As mentioned before, profiling certificates and specifying 688 operational and management protocols only addresses a part of the 689 problem of actually developing and implementing a secure PKI. What is 690 also needed is the development of a certificate policy and 691 certification practice statement, and then following those documents. 692 The CP and CPS should address physical and personnel security, 693 subject identification requirements, revocation policy, and a number 694 of other topics. [RFC 2527] provides a framework for certification 695 practice statements. 697 3.6.5 Time-Stamp and Data Certification Services 699 In late 1998, the PKIX working group began two efforts that were not 700 in the original working group charter, but were deemed to be 701 appropriate because they described infrastructure services that could 702 be used to provide desired security services. The first of these is 703 time stamping, described in [TSP]. Time stamping is a service in 704 which a trusted third party - a Time Stamp Authority, or TSA - signs 705 a message, in order to provide evidence that it existed prior to a 706 given time. Time stamping provides some support for non-repudiation, 707 in that a user cannot claim that a transaction was later forged after 708 compromise of a private key, because the existence of the signed time 709 stamp indicates that the transaction in question could not have been 710 created after the indicated time. 712 [TSP] also defines the role of a Temporal Data Authority, or TDA. A 713 TDA is a TTP that creates a temporal data token. This temporal data 714 token associates a message with a particular event and provides 715 supplementary evidence for the time included in the time stamp token. 716 For example, a TDA could associate the message with the most recent 717 closing value of the Dow Jones Average. The temporal data with which 718 the message is associated should be unpredictable in order to prevent 719 forward dating of tokens. 721 At the Minneapolis IETF meeting, it was disclosed that the materials 722 covered in the Timestamp Internet draft may be covered by patent(s). 723 Use of the material covered by the patent(s) in question has not be 724 granted by the patentholder. Thus, anyone interested in implementing 725 the PKIX Timestamp draft must be aware of this intellectual property 726 issue. 728 The second new effort is the definition of a Data Certification 729 Server, or DCS, protocol [DCS]. A DCS is a Trusted Third Party that 730 verifies the correctness of specific data submitted to it. 732 This is different from the TSP service in that a TSA will not attempt 733 to parse and/or verify a message sent to it for certification; 734 instead, it will merely append a reliable indication of the current 735 time, and sign the resulting string-of-bits. This offers an 736 indication that the given string-of-bits existed at a specified time; 737 it does not offer any indication of the correctness or relevance of 738 that string of bits. By contrast, the DCS certifies possession of 739 data or the validity of another entity's signature. As part of this, 740 the DCS verifies the mathematical correctness of the actual signature 741 value contained in the request and also checks the full certification 742 path from the signing entity to a trusted point (e.g., the DCS's CA, 743 or the root CA in a hierarchy). 745 The DCS supports non-repudiation in two ways. First, it provides 746 evidence that a signature or public key certificate was valid at the 747 time indicated in the token. The token can be used even after the 748 corresponding public key certificate expires and its revocation 749 information is no longer available on CRLs (for example). Second, the 750 production of a data certification token in response to a signed 751 request for certification of another signature or public key 752 certificate also provides evidence that due diligence was performed 753 by the requester in validating the signature or public key 754 certificate. 756 4 PKIX Documents 758 This section describes each of the documents written by the PKIX 759 working group. As PKIX progresses, this section will need to be 760 continually updated to reflect the status of each document (e.g., 761 Proposed Standard, Draft Standard, Standard, Informational Draft, 762 Informational RFC, something-that-was-just-thrown-out-for- 763 consideration, etc.) 765 4.1 Profile 767 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate 768 and CRL Profile (RFC 2459) 770 DESCRIPTION: This document describes the profiles to be used for 771 X.509v3 certificates and version2 CRLs by Internet PKI participants. 772 The profiles include the identification of ISO/IEC/ITU and ANSI 773 extensions which may be useful in the Internet PKI. The profiles are 774 presented in the 1988 Abstract Syntax Notation One (ASN.1) rather 775 than the 1994 syntax used in the ISO/IEC/ITU standards. Would-be 776 PKIX implementors and developers of certificate-using applications 777 should start with [RFC 2459] to ensure that their systems will be 778 able to interoperate with other users of the PKI. 780 [RFC 2459] also includes path validation procedures. The procedures 781 presented are based upon the ISO/IEC/ITU definition, but the 782 presentation assumes one or more self-signed trusted CA certificates. 783 The procedures are provided as examples only. Implementations are 784 not required to use the procedures provided; they may implement 785 whichever procedures are efficient for their situation. However, 786 implementations are required to derive the same results as the 787 example procedures. 789 STATUS: Proposed Standard. 791 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure: 792 Representation of Elliptic Curve Digital Signature Algorithm (ECDSA) 793 Keys and Signatures in Internet X.509 Public Key Infrastructure 794 Certificates 796 DESCRIPTION: This document provides Object Identifiers (OIDs) and 797 other guidance for IPKI users who use the Elliptic Curve Digital 798 Signature Algorithm (ECDSA). It profiles the format and semantics of 799 the subjectPublicKeyInfo field and the keyUsage extension in X.509 V3 800 certificates containing ECDSA keys. This document should be used by 801 anyone wishing to support ECDSA; others who do not support ECDSA are 802 not required to comply with it. 804 STATUS: WG Last Call. 806 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure 807 Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 808 Public Key Infrastructure Certificates (RFC 2528) 810 DESCRIPTION: This document provides Object Identifiers (OIDs) and 811 other guidance for IPKI users who use the Key Exchange Algorithm 812 (KEA). It profiles the format and semantics of the 813 subjectPublicKeyInfo field and the keyUsage extension in X.509 V3 814 certificates containing KEA keys. This document should be used by 815 anyone wishing to support KEA; others who do not support ECDSA are 816 not required to comply with it. 818 STATUS: Informational RFC. 820 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Enhanced CRL 821 Distribution Options (OpenCDP) 823 DESCRIPTION: This document proposes an alternative to the CRL 824 Distribution Point (CDP) approach documented in [RFC 2459]. OCDP 825 separates the CRL location function from the process of certificate 826 and CRL validation, and thus claims some benefits over the CDP 827 approach. 829 STATUS: Under WG review. 831 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Qualified 832 Certificates 834 DESCRIPTION: This document profiles the format for and defines 835 requirements on information content in a specific type of 836 certificates called Qualified Certificates. A "Qualified Certificate" 837 is a certificate that is issued to a natural person (i.e., a living 838 human being); contains an unmistakable identity based on a real name 839 or a pseudonym of the subject; exclusively indicates non-repudiation 840 as the key usage for the certificate's public key; and meets a number 841 of requirements. 843 STATUS: Under WG review. 845 DOCUMENT TITLE: An Internet AttributeCertificate Profile for 846 Authorizations 848 DESCRIPTION: This document profiles the format for an defines 849 requirements on X.509 Attribute Certificates to support authorization 850 services required by various Internet protocols (TLS, CMS, and the 851 consumers of CMS, etc.). Two profiles are defined on that supports 852 basic authorizations and on the supports proxiable services. 854 STATUS: Under WG review. 856 DOCUMENT TITLE: Diffie-Hellman Proof-of-Possesion Algorithms 859 DESCRIPTION: This documents describes two signing algorithms using 860 the Diffie-Hellman key agreement process to provide a shared secret 861 as the basis of the signature. It allows Diffie-Hellman a key 862 agreement algorithm to be used instead of requiring that the public 863 key being requested for certification correspond to an algorithm that 864 is capable of signing and/or encrypting. The first algorithm 865 generates a signature for a specific verifier where the signer and 866 recipient have the same public key parameters. The second algorithm 867 generates a signature for arbitrary verifiers where the signer and 868 recipient do not have the same public key parameters. 870 STATUS: Under WG review. 872 4.2 Operational Protocols 874 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Operational 875 Protocols - LDAPv2 (RFC 2559) 877 DESCRIPTION: This document describes the use of LDAPv2 as a protocol 878 for PKI elements to publish and retrieve certificates and CRLs from a 879 certificate repository. LDAPv2 [RFC 1777] is a protocol that allows 880 publishing and retrieving of information. 882 STATUS: Proposed Standard. 884 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure LDAPv2 885 Schema (RFC 2587) 887 DESCRIPTION: This document defines a minimal schema necessary to 888 support the use of LDAPv2 for certificate and CRL retrieval and 889 related functions for PKIX. This document supplements [RFC 1777] by 890 identifying the PKIX-related attributes that must be present. 892 STATUS: Proposed Standard. 894 DOCUMENT TITLE: X.509 Internet Public Key Infrastructure Online 895 Certificate Status Protocol - OCSP 897 DESCRIPTION: This document specifies a protocol useful in 898 determining the current status of a certificate without the use of 899 CRLs. A major complaint about certificate-based systems is the need 900 for a relying party to retrieve a current CRL as part of the 901 certificate validation process. Depending on the size of the CRL, 902 this can cause severe problems for bandwidth-challenged devices. 903 Depending on the frequency of CRL issuance, this can also cause 904 timeliness problems. (E.g., if CRLs are only published weekly, with 905 no interim releases, a certificate could actually have been revoked 906 for just short of one week without it being on the current CRL, and 907 thus improper use of that certificate could still be occurring.) 909 OCSP attempts to address those problems. It provides a mechanism 910 whereby a relying party identifies one or more certificates to an 911 approved OCSP "responder", and the responder sends back the current 912 status of the certificate(s) - e.g., "revoked", "notRevoked", 913 "unknown". This can dramatically reduce the bandwidth required to 914 transmit revocation status - a relying party does not have to 915 retrieve a CRL of many entries to check the status of one 916 certificate. It can (although it is not guaranteed to) improve the 917 timeliness of revocation notification, and thus reduce the window of 918 opportunity for someone trying to use a revoked certificate. 920 STATUS: Approved as Proposed Standard. 922 DOCUMENT TITLE: Internet Public Key Infrastructure: Caching the 923 Online Certificate Status Protocol 926 DESCRIPTION: To improve the degree to which it can scale, OCSP 927 allows caching of responses - e.g., at intermediary servers, or even 928 at the relying party's end system. This document describes how to 929 support OCSP caching at intermediary servers. 931 STATUS: ??? 933 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Operational 934 Protocols: FTP and HTTP (RFC 2585) 936 DESCRIPTION: This document describes the use of the File Transfer 937 Protocol (FTP) and the Hyper-text Transfer Protocol (HTTP) to obtain 938 certificates and CRLs from PKI repositories. 940 STATUS: Proposed Standard. 942 DOCUMENT TITLE: WEB based Certificate Access Protocol-- WebCAP/1.0 943 945 DESCRIPTION: This document specifies a set of methods, headers, and 946 content-types ancillary to HTTP/1.1 to publish, retrieve X.509 947 certificates and Certificate Revocation Lists. This protocol also 948 facilitates determining current status of a digital certificate 949 without the use of CRLs. This protocol defines new methods, request 950 and response bodies, error codes to HTTP/1.1 protocol for securely 951 publishing, retrieving, and validating certificates across a 952 firewall. 954 STATUS: Has been discontinued. 956 4.3 Management Protocols 958 DOCUMENT TITLE: Certificate Management Messages over CMS 961 DESCRIPTION: This document defines the means by which PKI clients and 962 servers may exchange PKI messages when using S/MIME's Cryptographic 963 Message Syntax [CMS]as a transaction envelope. CMC supports the 964 certificate request message body specified in the Certificate Request 965 Message Format [RFC 2511] documents, as well as a variety of other 966 certificate management messages. The primary purpose of this 967 specification is to allow the use of an existing protocol (S/MIME)as 968 a PKI management protocol, without requiring the development of an 969 entirely new protocol such as CMP. A secondary purpose is to codify 970 in IETF standards the current industry practice of using PKCS 10 971 messages [PKCS10] for certificate requests. 973 STATUS: Under WG review. 975 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate 976 Management Message Formats 978 DESCRIPTION: This document contains the formats for a series of 979 messages important in certificate/PKI management. These messages let 980 CA's, RA's, and relying parties communicate with each other. Note 981 that this document only specifies message formats; it does not 982 specify a protocol for transferring messages. That protocol can be 983 either CMP or CMC, or perhaps another custom protocol. 985 STATUS: Has been discontinued, as all useful information from it has 986 been moved into [RFC 2510] and [CMC]. 988 DOCUMENT TITLE: Internet X.509 Certificate Request Message Format 989 (RFC 2511) 991 DESCRIPTION: CRMF specifies a format recommended for use whenever a 992 relying party is requesting a certificate from a CA or requesting 993 that an RA help it get a certificate. This document is distinct from 994 CMMF for historical reasons - the request message format was needed 995 before many of the other message formats had to be finalized, and so 996 it was put into a separate document. Like CMMF, this document only 997 specifies the format of a message. Specification of a protocol to 998 transport that message is beyond the scope of CRMF. 1000 STATUS: Proposed Standard. 1002 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate 1003 Management Protocols (RFC 2510) 1005 DESCRIPTION: This document specifies a new protocol specifically 1006 developed for the purpose of transporting messages like those 1007 specified in CMMF and CRMF among PKI elements. In general, CMP will 1008 be used in conjunction with CMMF and CRMF, and will then be run over 1009 a transfer service (e.g., S/MIME, HTTP) to provide a complete PKI 1010 management service. 1012 STATUS: Proposed Standard. 1014 4.4 Policy Outline 1016 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate 1017 Policy and Certification Practices Framework (RFC 2527) 1019 DESCRIPTION: As noted before, the specification and implementation of 1020 certificate profiles, operational protocols, and management protocols 1021 is only part of building a PKI. Equally as important - if not more 1022 important - is the development and enforcement of a certificate 1023 security policy, and a Certification Practice Statement (CPS). The 1024 purpose of this document (PKIX-4) is to establish a clear 1025 relationship between certificate policies and(CPSs), and to present a 1026 framework to assist the writers of certificate policies or CPSs with 1027 their tasks. In particular, the framework identifies the elements 1028 that may need to be considered in formulating a certificate policy or 1029 a CPS. The purpose is not to define particular certificate policies 1030 or CPSs, per se. 1032 STATUS: Informational RFC. 1034 4.5 Time-Stamp and Data Certification Services 1036 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Time Stamp 1037 Protocols 1039 DESCRIPTION: This document defines the specification for a time stamp 1040 service. It defines a Time Stamp Authority, or TSA, a trusted third 1041 party who maintains a reliable time service. When the TSA receives a 1042 time stamp request, it appends the current time to the request and 1043 signs it into a token to certify that the original request existed 1044 prior to the indicated time. This helps provide non-repudiation by 1045 preventing someone (either a legitimate user or an attacker who has 1046 successfully compromised a key) from "back-dating" a transaction. It 1047 also makes it more difficult to challenge a transaction by asserting 1048 that it has been back-dated. Note that the TSA does not provide any 1049 data parsing service; that is, the TSA does not attempt to validate 1050 that which it signs; it merely regards it as a string of bits whose 1051 meaning is unimportant, but existence is vital. 1053 STATUS: Under WG review. 1055 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Data 1056 Certification Server Protocols 1058 DESCRIPTION: This document defines a data certification service, or 1059 DCS, which can be used to certify both the existence and correctness 1060 of a message or signature. In contrast to the time stamp service 1061 described above, the DCS certifies possession of data or the validity 1062 of another entity's signature. As part of this, the DCS verifies the 1063 mathematical correctness of the actual signature value contained in 1064 the request and also checks the full certification path from the 1065 signing entity to a trusted point (e.g., the DCS's CA, or the root CA 1066 in a hierarchy). 1068 The DCS supports non-repudiation in two ways. First, it provides 1069 evidence that a signature or public key certificate was valid at the 1070 time indicated in the token. The token can be used even after the 1071 corresponding public key certificate expires and its revocation 1072 information is no longer available on CRLs (for example). Second, the 1073 production of a data certification token in response to a signed 1074 request for certification of another signature or public key 1075 certificate also provides evidence that due diligence was performed 1076 by the requester in validating the signature or public key 1077 certificate. 1079 STATUS: Under WG review. 1081 DOCUMENT TITLE: Basic Event Representation Token 1084 DESCRIPTION: This document defines a finite method of representing a 1085 discrete instant in time as a referable event. The Basic Event 1086 Representation Token (BERT) is a light-weight binary token designed 1087 for use in large numbers over short periods of time. The tokens 1088 contain only a single instance of an event stamp and the trust 1089 process is referenced against an external reference. 1091 STATUS: Under WG review. 1093 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Extending 1094 trust in non repudiation tokens in time 1097 DESCRIPTION: This document describes a method to maintain the trust 1098 in a token issued by a non-repudiation Trusted Third Party (NR TTP) 1099 (DCS/TSA/TDA) after the key initially used to establish trust in the 1100 token expires. The document describes a general format for storage 1101 of DCS/TS/TDA tokens for this purpose, which establishes a chain of 1102 custody for the data. 1104 STATUS: Under WG review. 1106 5 Advice to Implementors 1108 This section provides guidance to those who would implement various 1109 parts of the PKIX suite of documents. The topics discussed in this 1110 section engendered significant discussion in the working group, and 1111 there was at times either widespread disagreement or widespread 1112 misunderstanding of them. Thus, this discussion is provided to help 1113 readers of the PKIX document set understand these issues, in the hope 1114 of fostering greater interoperability among eventual PKIX 1115 implementations. 1117 5.1 Names 1119 PKIX has been referred to as a "name-centric" PKI because the 1120 certificates associate public keys with names of entities. Each 1121 certificate contains at least one name for the owner of a particular 1122 public key. The name can be an X.500 distinguished name, contained 1123 in the subjectDN field of the certificate. There can also be names 1124 such as RFC822 e-mail addresses, DNS domain names, and URIs 1125 associated with the key; these attributes are kept in the 1126 subjectAltName extension of the certificate. A certificate must 1127 contain at least one of these name forms, it may contain multiple 1128 forms if deemed appropriate by the CA based on the intended usage of 1129 the certificate. 1131 5.1.1 Name Forms 1133 There are two possible places to put a name in an X.509v3 1134 certificate. One is the subject field in the base certificate (often 1135 called the "Distinguished Name" or "DN" field), and the other is in 1136 the subjectAltName extension. 1138 5.1.1.1 Distinguished Names 1140 According to [RFC 2459], a PKIX certificate must have a non-null 1141 value in the Subject field, except for an end-entity certificate, 1142 which is permitted to have an empty subject field. Furthermore, if a 1143 certificate has a non-null Subject field, it MUST contain an X.500 1144 Distinguished Name. 1146 5.1.1.2 SubjectAltName Forms 1148 In addition to the DN, a PKIX certificate may have one or more values 1149 in the subjectAltName extension. 1151 The subjectAltName extension allows additional identities to be bound 1152 to the subject of the certificate - e.g., it allows "umbc.edu" and 1153 "130.85.1.3" to be associated with a particular subject, as well as 1154 "C=US, O=University of Maryland, L=Baltimore, CN=UMBC". 1155 X.509-defined options for this extension include: Internet 1156 electronic mail addresses; DNS names; IP addresses; and uniform 1157 resource indentifiers (URIs). Other options can exist, including 1158 locally-defined name forms. 1160 A single subjectAltName extension can include multiple name forms, 1161 and multiple instances of each name form. 1163 Whenever such Alternate Name forms are to be bound into a 1164 certificate, the subject alternative name (or issuer alternative 1165 name) extension must be used. It is technically possible to embed an 1166 Alternate Name Form in the subject field. For example, one could 1167 make a DN contain an IP address via a kludge such as "C=US, 1168 L=Baltimore, CN=130.85.1.3". However, this usage is deprecated; the 1169 alternative name extension is the preferred location for finding such 1170 information. As another example, some legacy implementations exist 1171 where an RFC822 name is embedded in the subject distinguished name as 1172 an EmailAddress attribute. Per [RFC 2459], PKIX-compliant 1173 implementations generating new certificates with electronic mail 1174 addresses MUST use the rfc822Name in the subject alternative name 1175 field to describe such entities. Simultaneous inclusion of the 1176 EmailAddress attribute in the subject distinguished name to support 1177 legacy implementation is deprecated but permitted. 1179 In line with this, if the only subject identity included in a 1180 certificate is an alternative name form, then the subject 1181 distinguished name must be empty (technically, an empty sequence), 1182 and the subjectAltName extension must be present. If the subject 1183 field contains an empty sequence, the subjectAltName extension must 1184 be marked critical. 1186 If the subjectAltName extension is present, the sequence must contain 1187 at least one entry. Unlike the subject field, conforming CAs shall 1188 not issue certificates with subjectAltNames containing empty 1189 GeneralName fields. For example, an rfc822Name is represented as an 1190 IA5String. While an empty string is a valid IA5String, such an 1191 rfc822Name is not permitted by PKIX. The behavior of clients that 1192 encounter such a certificate when processing a certification path is 1193 not defined by this working group. 1195 Because the subject alternative name is considered to be definitively 1196 bound to the public key, all parts of the subject alternative name 1197 must be verified by the CA. 1199 5.1.1.2.1 Internet e-mail addresses 1201 When the subjectAltName extension contains an Internet mail address, 1202 the adress is included as an rfc822Name. The format of an rfc822Name 1203 is an "addr-spec" as defined in RFC 822 [RFC 822]. An addr-spec has 1204 the form local-part@domain; it does not have a phrase (such as a 1205 common name) before it, or a comment (text surrounded in parentheses) 1206 after it, and it is not surrounded by "<" and ">". 1208 5.1.1.2.2 DNS Names 1210 When the subjectAltName extension contains a domain name service 1211 label, the domain name is stored in the dNSName attribute(an 1212 IA5String). The string shall be in the "preferred name syntax," as 1213 specified by RFC 1034 [RFC 1034]. Note that while upper and lower 1214 case letters are allowed in domain names, no signifigance is attached 1215 to the case. In addition, while the string " " is a legal domain 1216 name, subjectAltName extensions with a dNSName " " are not permitted. 1217 Finally, the use of the DNS representation for Internet mail 1218 addresses (wpolk.nist.gov instead of wpolk@nist.gov) is not 1219 permitted; such identities are to be encoded as rfc822Name. 1221 5.1.1.2.3 IP addresses 1223 When the subjectAltName extension contains an iPAddress, the address 1224 shall be stored in the octet string in "network byte order," as 1225 specified in RFC 791 [RFC 791]. The least significant bit (LSB) of 1226 each octet is the LSB of the corresponding byte in the network 1227 address. For IP Version 4, as specified in RFC 791, the octet string 1228 must contain exactly four octets. For IP Version 6, as specified in 1229 RFC 1883, the octet string must contain exactly sixteen octets 1230 [RFC1883]. 1232 5.1.1.2.4 URIs 1234 [RFC 2459] notes "When the subjectAltName extension contains a URI, 1235 the name MUST be stored in the uniformResourceIdentifier (an 1236 IA5String). The name MUST be a non-relative URL, and MUST follow the 1237 URL syntax and encoding rules specified in [RFC 1738]. The name must 1238 include both a scheme (e.g., "http" or "ftp") and a scheme-specific- 1239 part. The scheme-specific-part must include a fully qualified domain 1240 name or IP address as the host. As specified in [RFC 1738], the 1241 scheme name is not case-sensitive (e.g., "http" is equivalent to 1242 "HTTP"). The host part is also not case-sensitive, but other 1243 components of the scheme-specific-part may be case-sensitive. When 1244 comparing URIs, conforming implementations MUST compare the scheme 1245 and host without regard to case, but assume the remainder of the 1246 scheme-specific-part is case sensitive." 1248 5.1.2 Scope of Names 1250 The original X.500 work presumed that every subject in the world 1251 would have a globally-unique distinguished name. Thus, every subject 1252 could be easily located, and there would never be a conflict. All 1253 that would be needed is a sufficiently-large name space, and rules 1254 for constructing names based on subordination and location. 1256 Obviously, that is not practical in the real world, for a variety of 1257 reasons. There is no single entity in the world trusted by everybody 1258 to reside at the top of the name space, and there is no way to 1259 enforce uniqueness on names for all entities. (These were among the 1260 reasons for the failure of PEM to be widely implemented.) 1262 This does not mean, however, that a name-based PKI cannot work. It 1263 is important to recognize that the scope of names in PKIX is local; 1264 they need to be defined and unique only within their own domain. 1266 Suppose for example that a rootCA is established with DN "O=IETF, 1267 OU=PKIX, CN=PKIX_CA". That CA will then issue certificates for users 1268 subordinate to it. The only requirement - and this can be enforced 1269 procedurally - is that no two distinct entities beneath this rootCA 1270 have the same name. We can't prevent somebody else in the world from 1271 creating her own CA, called "O=IETF, OU=PKIX, CN=PKIX_CA", and it is 1272 not necessary to do so. Within the domain of the original rootCA, 1273 there will be no conflict, and the fact that there is another CA of 1274 the same name in some other domain is irrelevant. 1276 This is analogous to the current DNS or IP address situations. On 1277 the Internet, there is only one node called www.ietf.org. The fact 1278 that there might be 10 different intranets, each with a host given 1279 the DNS name www.ieft.org, is irrelevant and causes no 1280 interoperability problems - those are different domains. However, if 1281 there were to be another node on the Internet with domain name 1282 www.ietf.org, then there would be a problem due to name duplication. 1284 The same applies for IP addresses. As long as only one node on the 1285 Internet responds to the IP address 130.85.1.3, there is no problem, 1286 despite the fact that there are 100 different corporate Intranets, 1287 each using that same IP address. However, if two different nodes on 1288 the Internet each responded to the IP address 130.85.1.3, there would 1289 be a problem. 1291 5.1.3 Certificate Path Construction 1293 Certificate path construction has been the topic of many discussions 1294 in the WG. The issue centered around how best to get a certificate 1295 when the connection between the subject's name and the name of their 1296 CA, as well as the CA's repository (or directory), may not be 1297 obvious. Many proposals were put forth, including implementing a 1298 global X.500 Directory Service, using DNS SRV records, and using an 1299 attribute to point to the directory provider. At the end of the 1300 discussion the group decided to use the authority information access 1301 extension defined in [RFC 2459], which allows the CA to indicate the 1302 access method and location of CA information and services. The 1303 extension would be included in subject's certificates and could be 1304 used to associate an Internet style identity for the location of 1305 repository to retrieve the issuer's certificate in cases where such a 1306 location is not related to the issuer's name. 1308 Another discussion related to certificate path construction was where 1309 to store the CA and end-entity certificates in the directory 1310 (specifically LDAPv2 directories). Two camps emerged with different 1311 views on where to store CA and cross-certificates. In the CA's 1312 directory entry, one camp wanted self-issued certificates stored in 1313 the cACertificate attribute, certificates issued to this CA stored in 1314 the forward element of the crossCertificatePair, and certificates 1315 issued from this CA for other CAs in the reverse element of the 1316 crossCertificatePair attribute. The other camp wanted all CA 1317 certificates stored in the cACertificate attribute, and certificates 1318 issued to/from another domain stored in the crossCertificatePair 1319 attribute. There was a short discussion that the second was more 1320 efficient than first, and that one solution or the other was more 1321 widely deployed. The end result was to indicate that self-issued 1322 certificates and certificates issued to the CA by CAs in the same 1323 domain as the CA are stored in the cACertificate attribute. The 1324 crossCertificatePair attribute's forward element will include all but 1325 self-issued certificates issued to the CA. The reverse element may 1326 include a subset of certificates issued by the CA to other CAs. With 1327 this resolution both camp's implementations are supported and are 1328 free to chose the location of CA certificates to best support their 1329 implementation. 1331 5.1.4 Name Constraints 1333 A question that has arisen a number of times is "how does one enforce 1334 Name constraints when there is more than one name form in a 1335 certificate?" That is, [RFC 2459] states that: 1337 Subject alternative names may be constrained in the same manner as 1338 subject distinguished names using the name constraints extension 1339 as described in section 4.2.1.11. 1341 What does this mean? Suppose that there is a CA with DN "O=IETF, 1342 OU=PKIX, CN=PKIX_CA", with the subjectAltName extension having 1343 dNSName "PKIX_CA.IETF.ORG". Suppose that that CA has issued a 1344 certificate with an empty DN, with subjectAltName extension having 1345 dNSName set to "PKIX_CA.IETF.ORG", and rfc822Name set to 1346 Steve@PKIX_CA.IETF.ORG. The question is, are name constraints 1347 enforced on these two certificates - is the name of the end-entity 1348 certificate considered to be properly subordinate to the name of the 1349 CA? 1351 The answer is "yes". The general rules for deciding whether a 1352 certificate meets name constraints are: 1354 If a certificate complies with name constraints in any one of its 1355 name forms, then the certificate is deemed to comply with name 1356 constraints. 1358 If a certificate contains a name form that its issuer does not, 1359 the certificate is deemed to comply with name constraints for that 1360 name form. 1362 In deciding whether a name form meets name constraints, the following 1363 rules apply (in all cases Name B is the name in the name constraints 1364 extension): 1366 - rfc822Names: Three variations are allowed: 1368 - If the name constraint is specified as "larry@mail.mit.edu", 1369 then Name A is subordinate to Name B (in B's subtree) if Name A 1370 contains all of Name B's name (specifies a particular mailbox). 1371 For example, larry@mail.mit.edu is subordinate, but 1372 larry_sanders@mail.mit.edu is not. 1374 - If the name constraint is specified as "mail.mit.edu", then 1375 Name A is subordinate to Name B (in B's subtree) if Name A 1376 contains all of Name B's name (specified all mailboxes on host 1377 mail.mit.edu). For example, curly@mail.mit.edu and 1378 mo@mail.mit.edu are subordinate, but mo@mail6.mit.edu and 1379 curly@smtp.mail.mit.edu are not. 1381 - If the name constraint is specified as ".mit.edu", then Name 1382 A is subordinate to Name B (in B's subtree) if Name A contains 1383 all of Name B's name, with the addition of zero or more 1384 additional host or domain names to the left of Name B's name. 1385 That is, smtp.mit.edu is subordinate to .mit.edu, as is 1386 pop.mit.edu. However, mit.edu is not subordinate to .mit.edu. 1387 When the constraint begins with a "." it specifies any address 1388 within a domain. In the previous example, "mit.edu" is not in 1389 the domain of ".mit.edu". 1391 Note: If rfc822 names are constrained, but the certificate does 1392 not contain a subject alternative name, the EmailAddress 1393 attribute will be used to constrain the name in the subject 1394 distinguished name. For example (c is country, o is 1395 organization, ou is organizational unit, and em is 1396 EmailAddress), Name A ("c=US, o=MIT, ou=CS, 1397 em=curly@mail.mit.edu") is subordinate to Name B ("c=US, o=MIT, 1398 ou=CS") (in B's subtree) if Name A contains all of Name B's 1399 names. 1401 - dNSNames: Name A is subordinate to Name B (in B's subtree) if 1402 Name A contains all of Name B's name, with the addition of zero or 1403 more additional domain names to the left of Name B's name. That 1404 is, www.mit.edu is subordinate to mit.edu, as is larry.cs.mit.edu. 1405 However, www.mit.edu is not subordinate to web.mit.edu. 1407 - x.400 addresses: Name A is subordinate to Name B (in B's 1408 subtree) if Name A contains all of Name B's name. For example (c 1409 is country-name, admd is administrative-domain-name, and o is 1410 orgnaization-name, ou is organizational-unit-name, pn is personal- 1411 name, sn=surname, and gn is given-name in both Name A and B), the 1412 mneumonic X.400 address (using PrintableString choices for c and 1413 admd) "c=US, admd=AT&T, o=MIT, ou=cs, pn='sn=Doe,gn=John'" is 1414 subordinate to "c=US, admd=AT&T, o=MIT, ou=cs" and "c=US, 1415 admd=AT&T, o=MIT, pn='sn=DOE,gn=JOHN'" (pn is a SET that includes, 1416 among other things, sn and gn). 1418 - DNs: Name A is subordinate to Name B (in B's subtree), if Name A 1419 contains all of Name B's name, treating attribute values encoded 1420 in different types as different strings, ignoring case in 1421 PrintableString (in all other types case is not ignored), removing 1422 leading and trailing white space in PrintableString, and 1423 converting internal substrings of one or more consecutive white 1424 space characters to a single space. For example, (c is country, o 1425 is organization, ou is organizational unit, and cn is common 1426 name): 1428 (Assuming PrinatString types for all attribute values in Name A 1429 and B) "c=US, o=MIT, ou=CS" is subordinate to "c=us, o=MIT, 1430 ou=cs", as is "c=US, o=MIT, ou=CS, ou=adminstration". Another 1431 example, "c=US, o=MIT, ou=CS, cn= John Doe" (note the white 1432 spaces) is subordinate to "c=US, o=MIT, ou=CS, cn=John Doe". 1434 (Assuming UTF8String types for all attribute values in Name A 1435 and B) "c=US, o=MIT, ou=CS, ou=administration" is subordinate 1436 to "c=US, o=MIT, ou=CS", but "c=US, o=MIT, ou=cs, 1437 ou=Adminstration". "c=US, o=MIT, ou=CS, cn= John Smith" (note 1438 the white spaces) is not subordinate to "c=US, o=MIT, ou=CS, 1439 cn= John Smith". 1441 (Assuming UTF8String types for all attribute values in Name A 1442 and PrintableString types for all attribute values in Name B) 1443 "c=US, o=MIT, ou=cs" is subordinate to "c=US, o=MIT, ou=CS" if 1444 the verification software supports the full comparison 1445 algorithm in the X.500 series. "c=US, o=MIT, ou=cs" is NOT 1446 subordinate to "c=US, o=MIT, ou=CS" if the verification 1447 software supports the comparison algorithm in [RFC 2459]. 1449 - URIs: The constraints apply only to the host part of the 1450 name. Two variations are allowed: 1452 - If the name constraint is specified as ".mit.edu", then Name 1453 A is subordinate to Name B (in B's subtree) if Name A contains 1454 all of Name B's name, with the addition of zero or more 1455 additional host or domain names to the left of Name B's name. 1456 That is, www.mit.edu is subordinate to .mit.edu, as is 1457 curly.cs.mit.edu. However, mit.edu is not subordinate to 1458 .mit.edu. When the constraint begins with a "." it specifies a 1459 host. 1461 - If the name constraint is specified as "abc.mit.edu", then 1462 Name A is subordinate to Name B (in B's subtree) if Name A 1463 conatins all of Name B's name. No leftward expansion of the 1464 host or domain name is allowed. 1466 - iPaddresses: Two variations are allowed depending on the IP 1467 version: 1469 For IPv4 addresses: Name A (128.32.1.1 encoded as 80 20 01 01) 1470 is subordinate to Name B (128.32.1.0/255.255.255.0 encoded as 1471 80 20 00 00 FF FF FF 00) (in B's subtree) if Name A falls 1472 within the net denoted in Name B's CIDR notation. 1474 For IPv6 addresses: Name A (4224.0.0.0.8.2048.8204.16762 1475 encoded as 10 80 00 00 00 00 00 00 00 08 08 00 20 0C 41 7A) is 1476 subordinate to Name B (4224.0.0.0.8.2048.8204.0/ 1477 65535.65535.65535.65535.65535.65535.65535.0 encoded as 10 80 00 1478 00 00 00 00 00 00 08 08 00 20 0C 00 00 FF FF FF FF FF FF FF FF 1479 FF FF FF FF FF FF 00 00) (in B's subtree) if Name A falls 1480 within the net denoted in Name B's CIDR notation. 1482 As [RFC 2459] does not define requirements for the name forms 1483 otherName, ediPartyName, or registeredID there are no corresponding 1484 name constraints requirements. 1486 5.1.5 Wildcards in Name Forms 1488 A "wildcard" in a name form is a placeholder for a set of names; e.g. 1489 "*.mit.edu" meaning "any domain name ending in .mit.edu", and 1490 *@aol.com meaning "email address that uses aol.com". There are many 1491 people who believe that allowing wildcards in name forms in PKIX 1492 certificates would be a useful thing to do, because it would allow a 1493 single certificate to be used by all members of a group. These 1494 members would presumably have attributes in common; e.g., access 1495 rights to some set of resources, and so issuance of a certificate 1496 with a wildcard for the group would simplify management. 1498 After much discussion, the PKIX working group decided to permit the 1499 use of wildcards in certificates. That is, it is permissible for a 1500 PKIX-conformant CA to issue a certificate with a wildcard. However, 1501 the semantics of subject alternative names that include wildcard 1502 characters are not addressed by PKIX. Applications with specific 1503 requirements may use such names but must define the semantics. 1505 5.1.6 Name Encoding 1507 A very important topic that consumed much of the WG's time was the 1508 implementation of the directory string choices. While the long term 1509 goal of the IETF was clear, use UTF8String, the short term goals were 1510 not so clear. Many implementations only use PrintableString, others 1511 use BMPString, and still others use Latin1String (ISO 8859-1) and tag 1512 it as TeletexString (there are others still). To ensure that there 1513 is consistency with encodings [RFC 2459] defines a set of rules for 1514 the string choices. PrintableString was kept as the first choice 1515 because of it's widespread support by vendors. BMPString was the 1516 second choice, also for it's widespread vendor support. Failing 1517 support by PrintableString and BMPString, UTF8String must be used. 1518 In keeping with the IETF mandate, UTF8String can be used at any time 1519 if the CA supports it. Also, processing implementations that wish to 1520 support TeletexString should handle the entire ISO 8859-1 character 1521 set and not just the Latin1String subset. 1523 5.2 POP 1525 Proof of Possession, or POP, means that the CA is adequately 1526 convinced that the entity requesting a certificate containing a 1527 public key Y has access to the private key X corresponding to that 1528 public key. 1530 POP is important because it provides an appropriate level of 1531 assurance in the correct operation of the PKI as a whole. At its 1532 lowest level, POP counters the "self-inflicted denial of service"; 1533 that is, an entity voluntarily getting a certificate that cannot be 1534 used to sign or encrypt/decrypt information. However, as the 1535 following two examples demonstrate, POP also counters less direct, 1536 but more severe, threats: 1538 POP for signing keys: it is important to provide POP for keys used 1539 to sign material, in order to provide non-repudiation of 1540 transactions. For example, suppose Alice legitimately has private 1541 key X and its corresponding public key Y. Alice has a certificate 1542 from Charlie, a CA, containing Y. Alice uses X to sign a 1543 transaction T. Without POP, Mal could also get a certificate from 1544 Charlie containing the same public key, Y. Now, there are two 1545 possible threats: Mal could claim to have been the real signer of 1546 T; or Alice can falsely deny signing T, claiming that it was 1547 instead Mal. Since no one can reliably prove that Mal did or did 1548 not ever possess X, neither of these claims can be refuted, and 1549 thus the service provided by and the confidence in the PKI has 1550 been defeated. (Of course, if Mal really did possess X, Alice's 1551 private key, then no POP mechanism in the world will help, but 1552 that is a different problem.) 1554 One level of protection can be gained by having Alice, as the true 1555 signer of the transaction, include in the signed information her 1556 certificate or an identifier of her certificate (e.g., a hash of 1557 her certificate). This might make it more difficult for Mal to 1558 claim authorship - he would have to assert that he incorrectly 1559 included Alice's certificate, rather than his own. However, it 1560 would not stop Alice from falsely repudiating her actions. Since 1561 the certificate itself is a public item, Mal indeed could have 1562 inserted Alice's certificate into the signed transaction, and thus 1563 its presence does not indicate that Alice was the one who 1564 participated in the now-repudiated transaction. The only reliable 1565 way to stop this attack is to require that Mal prove he possesses 1566 X before his certificate is issued. 1568 For signing keys used only for authentication, and not for non- 1569 repudiation, the threat is lower because users may not care about 1570 Alice's after-the-fact repudiation, and thus POP becomes less 1571 important. However, POP SHOULD still be done wherever feasible in 1572 this environment, by either off-line or on-line means. 1574 POP for key management keys: Similarly, POP for key management keys 1575 (that is, keys used for either key agreement or key exchange) can 1576 help to prevent undermining confidence in the PKI. Suppose that Al 1577 is a new instructor in the Computer Science Department of a local 1578 University. Al has created a draft final exam for the Introduction 1579 to Networking course he is teaching. He wants to send a copy of the 1580 draft final to Dorothy, the Department Head, for her review prior to 1581 giving the exam. This exam will of course be encrypted, as several 1582 students have access to the computer system. However, a quick search 1583 of the certificate repository (e.g., search the repository for all 1584 records with subjectPublicKey=Dorothy's-value) turns up the fact that 1585 several students have certificates containing the same public key 1586 management key as Dorothy. At this point, if no POP has been done by 1587 the CA, Al has no way of knowing whether all of the students have 1588 simply created these certificates without knowing the corresponding 1589 private key (and thus it is safe to send the encrypted exam to 1590 Dorothy), or whether the students have somehow acquired Dorothy's 1591 private key (and thus it is certainly not safe to send the exam). 1592 Thus, the service to be provided by the PKI - allowing users to 1593 communicate with one another, with confidence in who they are 1594 communicating with - has been totally defeated. If the CA is 1595 providing POP, then either no students will have such certificates, 1596 or Al can know with certainty that the students do indeed know 1597 Dorothy's private key, and act accordingly. 1599 CMP requires that POP be provided for all keys, either through on- 1600 line or out-of-band means. There are any number of ways to provide 1601 POP, and the choice of which to use is a local matter. Additionally, 1602 a certificate requester can provide POP to either a CA or to an RA, 1603 if the RA can adequately assure the CA that POP has been performed. 1604 Some of the acceptable ways to provide POP include: 1606 Out-of-band means: 1608 For keys generated by the CA or an RA (e.g., on a token such as a 1609 smart card or PCMCIA card), possession of the token can provide 1610 adequate proof of possession of the private key. 1612 For user-generated keys, another approach can be used in 1613 environments where "key recovery" requirements force the requester 1614 to provide a copy of the private key to the CA or an RA. In this 1615 case, the CA will not issue the requested certificate until such 1616 time as the requester has provided the private key. This approach 1617 is in general not recommended, as it is extremely risky (e.g., the 1618 system designers need to figure out a way to protect the private 1619 keys from compromise while they are being sent to the CA/RA/other 1620 authority, and how to protect them there), but it can be used. 1622 On-line means: 1624 For signature keys that are generated by an end-entity, the 1625 requester of a certificate can be required to sign some piece of 1626 data (typically, the certificate request itself) using the private 1627 key. The CA will then use the requested public key to verify the 1628 signature. If the signature verification works, the CA can safely 1629 conclude that the requester had access to the private key. If the 1630 signature verification process fails, the CA can conclude that the 1631 requester did not have access to the correct private key, and 1632 reject the request. 1634 For key management keys that are generated by the requester, the 1635 CA can send the user the requested public key, along with the CA's 1636 own private key, to encrypt some piece of data, and send it to the 1637 requester to be decrypted. For example, the CA can generate some 1638 random challenge, and require some action to be taken after 1639 decryption (e.g., "decrypt this encrypted random number and send 1640 it back to me"). If the requester does not take the requested 1641 action, the CA concludes that the requester did not possess the 1642 private key, and the certificate is not issued. 1644 Another method of providing POP for key management keys is for the 1645 CA to generate the requested certificate, and then send it to the 1646 requester in encrypted form. If the requester does not have 1647 access to the appropriate private key, the requester cannot 1648 decrypt the certificate, and thus cannot use it. After some period 1649 of time in which the certificate is not used, the CA will revoke 1650 the certificate. (This only works if the certificate is not made 1651 available to any untrusted entities until after the requester has 1652 successfully decrypted it.) 1654 5.3 Key Usage Bits 1656 The key usage extension defines the purpose (e.g., encipherment, 1657 signature, certificate signing) of the key contained in the 1658 certificate. This extension is used when a key that could be used for 1659 more than one operation is to be restricted. For example, when an 1660 RSA key should be used only for signing, the digitalSignature and/or 1661 nonRepudiation bits would be asserted. Likewise, when an RSA key 1662 should be used only for key management, the keyEncipherment bit would 1663 be asserted. When used, this extension should be marked critical. 1665 The eight bits defined for this extension identify seven mechanisms 1666 and one service, namely: 1668 - digitalSignature - nonRepudiation - keyEncipherment - 1669 dataEncipherment - keyAgreement - keyCertSign - cRLSign - 1670 encipherOnly - decipherOnly 1672 According to [RFC 2459], bits in the KeyUsage type are used as 1673 follows: 1675 - The digitalSignature bit is asserted when the subject public key 1676 is used to verify digital signatures that have purposes other than 1677 non-repudiation, certificate signature, and CRL signature. For 1678 example, the digitalSignature bit is asserted when the subject 1679 public key is used to provide authentication via the signing of 1680 ephemeral data. 1682 - The nonRepudiation bit is asserted when the subject public key 1683 is used to verify digital signatures used to provide a non- 1684 repudiation service which protects against the signing entity 1685 falsely denying some action, excluding certificate or CRL signing. 1687 - The keyEncipherment bit is asserted when the subject public key 1688 is used for key transport. For example, when an RSA key is to be 1689 used for key management, this bit must asserted. 1691 - The dataEncipherment bit is asserted when the subject public key 1692 is used for enciphering user data, other than cryptographic keys. 1694 - The keyAgreement bit is asserted when the subject public key is 1695 used for key agreement. For example, when a Diffie-Hellman key is 1696 to be used for key management, this bit must asserted. 1698 - The keyCertSign bit is asserted when the subject public key is 1699 used for verifying a signature on certificates. This bit may only 1700 be asserted in CA certificates. 1702 - The cRLSign bit is asserted when the subject public key is used 1703 for verifying a signature on revocation information (e.g., a CRL). 1705 - The meaning of the encipherOnly bit is undefined in the absence 1706 of the keyAgreement bit. When the encipherOnly bit is asserted 1707 and the keyAgreement bit is also set, the subject public key may 1708 be used only for enciphering data while performing key agreement. 1710 - The meaning of the decipherOnly bit is undefined in the absence 1711 of the keyAgreement bit. When the decipherOnly bit is asserted 1712 and the keyAgreement bit is also set, the subject public key may 1713 be used only for deciphering data while performing key agreement. 1715 PKIX does not restrict the combinations of bits that may be set in an 1716 instantiation of the keyUsage extension. 1718 The discussion on the PKIX mailing list has centered on the 1719 digitalSignature bit and the nonRepudiation bit. The question has 1720 come down to something like: When support for the service of non- 1721 repudiation is desired, should both the digitalSignature and 1722 nonRepudiation bits be set, or just the nonRepudiation bit? 1724 (It is noted that provision of the service of non-repudiation 1725 requires more than a single bit set in a certificate. It requires an 1726 entire infrastructure of components to preserve for some period of 1727 time the keys, certificates, revocation status, signed material, 1728 etc., as well as a trusted source of time. However, the 1729 nonRepudiation key usage bit is provided as an indicator that such 1730 keys should not be used as a component of a system providing a non- 1731 repudiation service.) 1733 According to [SIMONETTI], the intent is that the digitalSignature bit 1734 should be set when what is desired is the ability to sign ephemeral 1735 transactions; e.g., for a single session authentication. These 1736 transactions are "ephemeral" in the sense that they are important 1737 only while they are in existence; after the session is terminated, 1738 there is no long-term record of the digital signature and its 1739 properties kept. When something is intended to be kept for some 1740 period of time, the nonRepudiation bit should be set. This generally 1741 implies that an application will digitally sign something; thus, some 1742 implementors turn on the digitalSignature bit as well. Other 1743 implementors, however, keep the two bits mutually exclusive, to 1744 prevent a single key from being used for both ephemeral and long-term 1745 signing. 1747 While [RFC 2459] is silent on this specific issue, the working 1748 group's general conclusion is that a certificate may have either or 1749 both bits set. If only the nonRepudiation bit is set, the key should 1750 not be used for ephemeral transactions. If only the digitalSignature 1751 bit is set, the key should not be used for long-term signing. If 1752 both bits are set, the key may be used for either purpose. 1754 To actually enforce this requires that an application understands 1755 whether it is signing ephemeral transactions or for the long-term. 1756 The application developers will have to understand the difference, 1757 and set up their checks on the key usage bits field accordingly. For 1758 example, TLS implementors should check only the digitalSignature bit, 1759 and ignore the nonRepudiation bit. S/MIME implementors, though, will 1760 have a difficult choice to make, since their application could be 1761 used for either purpose, and they will generally accept signing using 1762 keys associated with certificates having either or both bits being 1763 turned on. Certification Authorities should know what applications 1764 they are providing certificates for, and provide certificates 1765 according to the requirements of those applications. If CA's are 1766 tied into non-repudiation systems, they may treat certificates 1767 differently when the nonRepudiation bit is turned on (e.g., store 1768 information associated with the certificate - like the user's 1769 identification provided during certificate registration, or 1770 certificate generation date/time stamps - for longer periods of time, 1771 in more secure environments). 1773 The bottom line is that this is an area where PKI implementors are 1774 somewhat limited in what they can do. The onus is on developers of 1775 certificate-using systems to understand their requirements and 1776 request certificates with the appropriate bits set. 1778 5.4 Trust Models 1780 (This section will describe the various trust models that PKIX can 1781 support. It is important to note that PKIX is bound to neither a 1782 pure hierarchical model a la PEM, nor a web of trust model a la PGP. 1783 PKIX can support either of those models, or any flavor in between. 1784 The implications of different trust models should be described: 1786 - efficiency of revocation 1787 - certification path building 1788 - etc.) 1790 6 Acknowledgements 1792 A lot of the information in this document was taken from the PKIX 1793 source documents; the authors of those deserve the credit for their 1794 own words. Other good material was taken from mail posted to the PKIX 1795 working group mail list (ietf-pkix@imc.org). Among those with good 1796 things to say were (in alphabetical order, with apologies to anybody 1797 we've missed): Sharon Boeyen, Santosh Chokhani, Warwick Ford, Russ 1798 Housley, Steve Kent, Ambarish Malpani, Matt Fite, Michael Myers, Tim 1799 Polk, Stefan Santesson, Dave Simonetti, and. 1801 7 References 1803 [BERT1] McNeil, M., and Glassey, T., "Basic Event Representation 1804 Token," , May 1999. 1806 [CACHE] "Internet Public Key Infrastructure: Caching the Online 1807 Certificate Status Protocol," , 1808 April 1998. 1810 [CMC] Myers, M., Liu, X., Fox, B., and Weinstein, J., "Certificate 1811 Management Messages over CMS," , May 1812 1999. 1814 [CMMF] Adams, C., and Myers, M., "Internet X.509 Public Key 1815 Infrastructure Certificate Management Message Formats," , July 1998. 1818 Note: This following document has expired. 1820 [CRS] Myers, M., Liu X., Fox B., Prafullchandra H., Weinstein J., " 1821 Certificate Request Syntax," , November 1822 1997. 1824 [CMS] R. Housley, "Cryptographic Message Syntax," , April 1999. 1827 [DCS] Adams, C., and Zuccherato, R., "Internet X.509 Public Key 1828 Infrastructure Data Certification Server Protocols", , 23 September 1998. 1831 [ECDSA] Bassham, L., Johnson, D., and Polk, W., "Internet x.509 1832 Public Key Infrastructure: Representation of Elliptic Curve Digital 1833 Signature Algorithm (ECDSA) Keys and Signatures in Internet X.509 1834 Public Key Infrastructure Certificates," , November 1997 1837 [ETNPT] Namjoshi, P., "Internet X.509 Public Key Infrastructure 1838 Extending trust in non repudiation tokens in time," , May 1999. 1841 [MISPC] Burr, W., Dodson, D., Nazario, N., and Polk, W., "MISPC 1842 Minimum Interoperability Specification for PKI Components, Version 1843 1", September 3, 1997 1845 [OCDP] Hallam-Baker, P., and Ford, W., "Internet X.509 Public Key 1846 Infrastructure Enhanced CRL Distribution Options (OpenCDP)," , August 7, 1998 1849 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and Adams, 1850 C., "X.509 Internet Public Key Infrastructure Online Certificate 1851 Status Protocol - OCSP," , March 1999. 1853 [PKCS10] RSA Laboratories, "The Public-Key Cryptography 1854 Standards(PKCS)", RSA Data Security Inc., Redwood City, California, 1855 November 1993 Release. 1857 [DHPOP] Prafullchandra, H., and Schaad, J., "Diffie-Hellman Proof-of- 1858 Possession Algorithms," , February 1859 1999. 1861 [QC] Santesson, S., Polk, W., and Gloeckner, P., "Internet X.509 1862 Public Key Infrastructure Qualified Certificates", , 3 February 1999. 1865 [RFC 791] Postel, J., "Internet Protocol", September 1981. 1867 [RFC 822] Crocker, D., "Standard for the Format of ARPA Internet Text 1868 Messages", August 1982. 1870 [RFC 1034] Mockapetris, P.V., "Domain names - concepts and 1871 facilities", November 1987. 1873 [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic 1874 Mail: Part II: Certificate-Based Key Management," February 1993. 1876 [RFC 1777] Yeong, Y., Howes, T., and Kille, S., "Lightweight 1877 Directory Access Protocol", March 1995 1879 [RFC 1883] Deering, S., and Hinden, R., "Internet Protocol, Version 6 1880 [IPv6] Specification", December 1995. 1882 [RFC 2459] Housley, R., Ford, W., Polk, W., and Solo, D., "Internet 1883 X.509 Public Key Infrastructure Certificate and CRL Profile," January 1884 1999. 1886 [RFC 2510] Adams, C., Farrell, S., "Internet X.509 Public Key 1887 Infrastructure Certificate Management Protocols", March 1999. 1889 [RFC 2511] Myers, M., Adams, C., Solo, D., and Kemp, D., "Internet 1890 X.509 Certificate Request Message Format," RFC 2510, March 1999. 1892 [RFC 2527] Chokhani, S., and Ford, W., "Internet X.509 Public Key 1893 Infrastructure Certificate Policy and Certification Practices 1894 Framework," RFC 2527, March 1999. 1896 [RFC 2528] Housley, R., and Polk, W., "Internet X.509 Public Key 1897 Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in 1898 Internet X.509 Public Key Infrastructure Certificates," RFC 2528, 1899 March 1999. 1901 [RFC 2559] Boeyen, S., Howes, T., and Richard, P., "Internet X.509 1902 Public Key Infrastructure Operational Protocols - LDAPv2," RFC 2559, 1903 April 1999. 1905 [RFC 2585] Housley, R., and Hoffman, P., "Internet X.509 Public Key 1906 Infrastructure Operational Protocols: FTP and HTTP," RFC 2585, July 1907 1998. 1909 [RFC 2587] Boeyen, S., Howes, T., and Richard, P., "Internet X.509 1910 Public Key Infrastructure LDAPv2 Schema," RFC 2587, June 1999. 1912 [SIMONETTI] Simonetti, D., "Re: German Key Usage", posting to ietf- 1913 pkix@imc.org mailing list, 12 August 1998 1915 [TSP] Adams, C., Cain, P., Pinkas, D., and Zuccherato, R., "Internet 1916 X.509 Public Key Infrastructure Time Stamp Protocols", , May 1999. 1919 [WEB] Reddy, S., "WEB based Certificate Access Protocol-- 1920 WebCAP/1.0," , April 19, 1998 1922 [X.509] ITU-T Recommendation X.509 (1997 E): Information Technology 1923 - Open Systems Interconnection - The Directory: Authentication 1924 Framework, June 1997. 1926 [X9.42] ANSI X9.42-199x, Public Key Cryptography for The Financial 1927 Services Industry: Agreement of Symmetric Algorithm Keys Using 1928 Diffie-Hellman (Working Draft), December 1997. 1930 [X9.55] ANSI X9.55-1995, Public Key Cryptography For The Financial 1931 Services Industry: Extensions To Public Key Certificates And 1932 Certificate Revocation Lists, 8 December, 1995. 1934 [X9.57] ANSI X9.57-199x, Public Key Cryptography For The Financial 1935 Services Industry: Certificate Management (Working Draft), 21 June, 1936 1996. 1938 8 Security Considerations 1940 TBSL 1942 9 Editor's Address 1944 Alfred Arsenault U. S. Department of Defense 9800 Savage Road Suite 1945 6734 Fort George G. Meade, MD 20755-6734 (410) 684-7114 1946 awarsen@missi.ncsc.mil 1948 Sean Turner IECA, Inc. 9010 Edgepark Road Vienna, VA 22182 (703) 1949 628-3180 turners@ieca.com 1951 10 Disclaimer 1953 This work constitutes the opinion of the editors only, and may not 1954 reflect the opinions or policies of their employers.