idnits 2.17.00 (12 Aug 2021) /tmp/idnits20676/draft-ietf-pkix-roadmap-01.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 seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 37 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 4 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 1099: '...ubject field, it MUST contain an X.500...' RFC 2119 keyword, line 1130: '... addresses MUST use the rfc822Name i...' RFC 2119 keyword, line 1191: '... the name MUST be stored in the unif...' RFC 2119 keyword, line 1192: '...tring). The name MUST be a non-relativ...' RFC 2119 keyword, line 1200: '... implementations MUST compare the sche...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 254 has weird spacing: '... of the certi...' == Line 1008 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 (22 March 1999) is 8460 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 672, but not defined ** Obsolete undefined reference: RFC 2459 (Obsoleted by RFC 3280) == Missing Reference: 'RFC1883' is mentioned on line 1186, but not defined ** Obsolete undefined reference: RFC 1883 (Obsoleted by RFC 2460) == Missing Reference: 'RFC 1738' is mentioned on line 1196, but not defined ** Obsolete undefined reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) == Unused Reference: 'CACHE' is defined on line 1603, but no explicit reference was found in the text == Unused Reference: 'CMS' is defined on line 1626, but no explicit reference was found in the text == Unused Reference: 'OCDP' is defined on line 1656, but no explicit reference was found in the text == Unused Reference: 'RFC 1883' is defined on line 1690, but no explicit reference was found in the text == Unused Reference: 'IPv6' is defined on line 1691, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CACHE' -- Possible downref: Non-RFC (?) normative reference: ref. 'CMC' -- Possible downref: Non-RFC (?) normative reference: ref. 'CMMF' ** Obsolete normative reference: RFC 2511 (ref. 'CRMF') (Obsoleted by RFC 4211) -- Possible downref: Non-RFC (?) normative reference: ref. 'CRS' ** Obsolete normative reference: RFC 2510 (ref. 'CMP') (Obsoleted by RFC 4210) -- 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. 'FTP' -- Possible downref: Non-RFC (?) normative reference: ref. 'KEA' -- Possible downref: Non-RFC (?) normative reference: ref. 'LDAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'MISPC' -- Possible downref: Non-RFC (?) normative reference: ref. 'OCDP' -- Possible downref: Non-RFC (?) normative reference: ref. 'OCSP' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS10' ** Obsolete normative reference: RFC 2527 (ref. 'PKIX-4') (Obsoleted by RFC 3647) -- 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'SCHEMA' -- 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: 21 errors (**), 0 flaws (~~), 14 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group A. Arsenault 3 INTERNET DRAFT DOD 4 S. Turner 5 IECA 7 Expires in six months from 22 March 1999 9 Internet X.509 Public Key Infrastructure 10 PKIX Roadmap 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance 16 with all provisions of Section 10 of RFC2026. 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of 6 months 24 and may be updated, replaced, or may become obsolete by other 25 documents at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as work in progress. To 27 view the entire list of current Internet-Drafts, please check 28 the"1id-abstracts.txt" listing contained in the Internet-Drafts 29 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 30 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 31 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 32 Copyright (C) The Internet Society (date). All Rights Reserved. 34 Abstract 36 This document provides an overview or 'roadmap' of the work done by 37 the IETF PKIX working group. It describes some of the terminology 38 used in the working group's documents, and the theory behind an 39 X.509-based PKI. It identifies each document developed by the PKIX 40 working group, and describes the relationships among the various 41 documents. It also provides advice to would-be PKIX implementors 42 about some of the issues discussed at length during PKIX development, 43 in hopes of making it easier to build implementations that will 44 actually interoperate. 46 TABLE OF CONTENTS 47 1 Introduction.................................................2 48 1.1 This Document................................................2 49 1.2 Changes Since the Last Version...............................3 50 2 Terminology..................................................3 51 3 PKIX Theory..................................................4 52 3.1 Certificate-using Systems and PKIs...........................4 53 3.2 PKIX History.................................................5 54 3.3 Overview of the PKIX Approach................................5 55 3.4 X.509 certificates...........................................6 56 3.5 Functions of a PKI...........................................7 57 3.5.1 Registration.................................................7 58 3.5.2 Initialization...............................................7 59 3.5.3 Certification................................................7 60 3.5.4 Key Pair Recovery............................................7 61 3.5.5 Key Generation...............................................8 62 3.5.6 Key Update...................................................8 63 3.5.7 Cross-certification..........................................9 64 3.5.8 Revocation...................................................9 65 3.5.9 Certificate and Revocation Notice Distribution/Publication..10 66 3.6 Parts of PKIX...............................................10 67 3.6.1 Profile.....................................................11 68 3.6.2 Operational Protocols.......................................11 69 3.6.3 Management Protocols........................................11 70 3.6.4 Policy Outline..............................................12 71 3.6.5 Time-Stamp and Data Certification Services..................12 72 4 PKIX Documents..............................................13 73 4.1 Profile.....................................................13 74 4.2 Operational Protocols.......................................14 75 4.3 Management Protocols........................................16 76 4.4 Policy Outline..............................................17 77 4.5 Time-Stamp and Data Certification Services..................17 78 5 Advice to Implementors......................................19 79 5.1 Names.......................................................19 80 5.1.1 Name Forms..................................................19 81 5.1.2 Scope of Names..............................................21 82 5.1.3 Certificate Path Construction...............................22 83 5.1.4 Name Constraints............................................22 84 5.1.5 Wildcards in Name Forms.....................................23 85 5.1.6 Name Encoding...............................................23 86 5.2 POP.........................................................23 87 5.3 Key Usage Bits..............................................25 88 5.4 Trust Models................................................27 89 6 Acknowledgements............................................28 90 7 References..................................................28 91 8 Security Considerations.....................................30 92 9 Editor's Address............................................30 93 10 Disclaimer..................................................30 95 1 Introduction 97 1.1 This Document 99 This document is an informational Internet draft that provides a 100 "roadmap" to the documents produced by the PKIX working group. It is 101 intended to provide information; there are no requirements or 102 specifications in this document. 104 Section 2 of this document defines key terms used in this document. 105 Section 3 covers "PKIX theory"; it explains what the PKIX working 106 group's basic assumptions were. Section 4 provides an overview of 107 the various PKIX documents. It identifies which documents address 108 which areas, and describes the relationships among the various 109 documents. Section 5 contains "Advice to implementors". Its primary 110 purpose is to capture some of the major issues discussed by the PKIX 111 working group, as a way of explaining WHY some of the requirements 112 and specifications say what they say. This should cut down on the 113 number of misinterpretations of the documents, and help developers 114 build interoperable implementations. Section 6 contains a list of 115 references. Section 7 discusses security considerations, and Section 116 8 provides contact information for the editors. 118 1.2 Changes Since the Last Version 120 The major changes in this document since version -00 include: 122 inclusion of a section on "PKIX History" the definition and usage of 123 "root CA" were changed to be consistent with CMP, in line with the 124 discussion on the PKIX mailing list updates on the status of all 125 major documents addition of descriptions of documents covering work 126 items that are new to PKIX since September 1998 a number of sections 127 that had been left unspecified have now been completed (e.g., the 128 Proof of Possession (POP) section; rules on name constraints for 129 different name types) The old section 4.5, which attempted to 130 graphically depict document relationships, has been deleted because 131 it didn't seem to add any value. 133 2 Terminology 135 There are a number of terms used and misused throughout PKI-related 136 literature. To limit confusion caused by some of those terms, 137 throughout this document, we will use the following terms in the 138 following ways: 140 - Certification Authority (CA) - an authority trusted by one or more 141 users to create and assign certificates. Optionally the 142 certification authority may create the user's keys. (It is important 143 to note that the CA is responsible for the certificates during their 144 whole lifetime, not just for issuing them.) 146 - Certificate policy - a named set of rules that indicates the 147 applicability of a certificate to a particular community and/or class 148 of application with common security requirements. For example, a 149 particular certificate policy might indicate applicability of a type 150 of certificate to the authentication of electronic data interchange 151 transaction s for the trading of goods within a given price range. 153 - Root CA - a CA that is directly trusted by an end entity; that is, 154 securely acquiring the value of a root CA public key requires some 155 out-of-band step(s). This term is not meant to imply that a root CA 156 is necessarily at the top of any hierarchy, simply that the CA in 157 question is trusted directly. 159 - Top CA - a CA that is at the top of a PKI hierarchy. 161 Note that this is often also called a "root CA", from since in 162 data structures terms and in graph theory, the node at the top 163 of a tree is the "root". However, to minimize confusion in this 164 document, we elect to call this node a "Top CA," and reserve 165 "root CA" for the CA directly trusted by the user. Readers new 166 to PKIX should be aware that these terms are not used 167 consistently throughout the PKIX documents, as [RFC2459] uses 168 "root CA" to refer to what this and other documents call a "top 169 CA", and "most-trusted CA" to refer to what this and other 170 documents call a "root CA". 172 - Subordinate CA - A "subordinate CA" is one that is not a root CA 173 for the end entity in question. Often, a subordinate CA will not 174 be a root CA for any entity but this is not mandatory 176 - Registration Authority (RA) - an optional entity given 177 responsibility for performing some of the administrative tasks 178 necessary in the registration of subjects, such as: confirming 179 the subject's identity; validating that the subject is entitled 180 to have the attributes requested in a certificate; and verifying 181 that the subject has possession of the private key associated 182 with the public key requested for a certificate. 184 - End-entity - a subject of a certificate who is not a CA. 186 - Relying party - a user or agent (e.g., a client or server) who 187 relies on the data in a certificate in making decisions. 189 - Subject - a subject is the entity (CA or end-entity) named in a 190 certificate. Subjects can be human users, computers (as 191 represented by DNS names or IP addresses), or even software 192 agents. 194 3 PKIX Theory 196 3.1 Certificate-using Systems and PKIs 198 At the heart of recent efforts to improve Internet security are a 199 group of security protocols such as S/MIME, TLS, and IPSec. All of 200 these protocols rely on public-key cryptography to provide services 201 such as confidentiality, data integrity, data origin authentication, 202 and non-repudiation. The purpose of a PKI is to provide trusted and 203 efficient key- and certificate management, thus enabling the use of 204 authentication, non-repudiation, and confidentiality. 206 Users of public key-based systems must be confident that, any time 207 they rely on a public key, the associated private key is owned by the 208 subject with which they are communicating. (This applies whether an 209 encryption or digital signature mechanism is used.) This confidence 210 is obtained through the use of public key certificates, which are 211 data structures that bind public key values to subjects. The binding 212 is achieved by having a trusted CA verify the subject's identity and 213 digitally sign each certificate. 215 A certificate has a limited valid lifetime which is indicated in its 216 signed contents. Because a certificate's signature and timeliness 217 can be independently checked by a certificate-using client, 218 certificates can be distributed via untrusted communications and 219 server systems, and can be cached in unsecured storage in 220 certificate-using systems. 222 Certificates are used in the process of validating signed data. 223 Specifics vary according to which algorithm is used, but the general 224 process works as follows: 226 (Note: there is no specific order in which the checks listed 227 below must be made; implementers are free to implement them in the 228 most efficient way for their systems) 230 - the recipient of signed data verifies that the claimed identity of 231 the user is in accordance wit the identity contained in the 232 certificate; 234 - the recipient validates that no certificate in the path has been 235 revoked (e.g., by retrieving a suitably-current Certificate 236 Revocation List (CRL) or querying an on-line certificate status 237 responder), and that all certificates were within their validity 238 periods at the time the data were signed; 240 - the recipient verifies that the data are not claimed to have any 241 attributes for which the certificate indicates that the signer is 242 not authorized; 244 - the recipient verifies that the data have not been altered since 245 signing, by using the public key in the certificate. 247 If all of these checks pass, the recipient can accept that the data 248 were signed by the purported signer. The process for keys used for 249 encryption is similar. 251 Note: it is of course possible that the data were signed by 252 someone very different from the signer, if for example the 253 purported signer's private key was compromised. Security depends 254 on all parts of the certificate-using SYSTEM, including but not 255 limited to: physical security of the place the computer resides; 256 personnel security (i.e., the trustworthiness of the people who 257 actually develop, install, run, and maintain the system); the 258 security provided by the operating system on which the private key 259 is used; and the security provided the CA. A failure in any one 260 of these areas can cause the entire system security to fail. PKIX 261 is limited in scope, however, and only directly addresses issues 262 related to the operation of the PKI subsystem. For guidance in 263 many of the other areas, see [PKIX-4]. 265 A collection of certificates, with their issuing CA's, subjects, 266 relying parties, RA's, and repositories, is referred to as a Public 267 Key Infrastructure, or PKI. 269 3.2 PKIX History 271 [This still needs more work.] 273 In the beginning there was ITU-T Recommendation X.509. It defines a 274 widely accepted basis for a public-key infrastructure, including data 275 formats and procedures related to distribution of public keys via 276 certificates digitally signed by CAs. X.509 does not however include 277 a profile to specify the support requirements for many of the 278 certificate data structure's sub-fields, for any of the extensions, 279 nor for certain data values. PKIX was formed in October 1995 to 280 deliver a profile for the Internet PKI of X.509 version 3 281 certificates and version 2 CRLs. The Internet PKI profile [RFC 2459] 282 went through eleven draft versions before becoming an RFC. Other 283 profiles have been developed in PKIX for particular algorithms to 284 make use of [RFC 2459]. There has been no sense of conflict between 285 the groups that developed these profiles as they are seen as 286 complimentary. 288 The development of the management protocols has not been so 289 straightforward. [CMP] was developed to define a message protocol 290 that is used between entities in a PKI. The demand for an enrollment 291 protocol and the desire to use PKCS-10 message format as the 292 certificate request syntax lead to the development of two different 293 documents in two different groups. The Certificate Request Syntax 294 [CRS] draft was developed in the SMIME WG which used PKCS10 [PKCS10] 295 as the certification request message format. Certificate Request 296 Message Format [CRMF] draft was also developed but in the PKIX WG. 297 It was to define a simple enrollment protocol that would subsume both 298 the [CMP] and [CRS] enrollment protocols, but it did not use PKCS10 299 as the certificate request message format. Then, [CMMF] was 300 developed to define an extended set of management messages that flow 301 between the components of the Internet PKI. CMMF over CMS [CMC] was 302 developed to allow the use of an existing protocol (S/MIME) as a PKI 303 management protocol, without requiring the development of an entirely 304 new protocol such as CMP [CMP]. It also included [PKCS10] as the 305 certificate request syntax, which caused work on [CRS] to stop. 306 Information from [CMMF] has been moved into [CMP] and [CMC] so [CMMF] 307 is being discontinued. 309 Development of the operational protocols has been slightly more 310 straightforward. Two documents for LDAPv2 have been developed one 311 for defining LDAPv2 as an access protocol to repositories [LDAP] and 312 one for storing PKI information in an LDAP directory [SCHEMA]. Using 313 FTP and HTTP to retrieve certificates and CRL from PKI repositories 314 was documented without a fight in [FTP]. Likewise, methods, headers, 315 and content-types ancillary to HTTP/1.1 to publish and retrieve X.509 316 certificates and CRLs was documented in [WEB] without much argument. 318 [Need to add text about OpenCDP vs DistributionPoints, Why DCP was 319 started, information on TSP, and OCSP, and caching OCSP.] 321 3.3 Overview of the PKIX Approach 323 PKIX is an effort to develop specifications for a Public Key 324 Infrastructure for the Internet using X.509 certificates. The PKIX 325 working group was initially chartered in 1995. A Public Key 326 Infrastructure, or PKI, is defined as: 328 The set of hardware, software, people, policies and procedures needed 329 to create, manage, store, distribute, and revoke certificates based 330 on public-key cryptography. 332 A PKI consists of five types of components [MISPC]: 334 - Certification Authorities (CAs) that issue and revoke certificates; 335 - Organizational Registration Authorities (ORAs) that vouch for the 336 binding between public keys and certificate holder identities and 337 other attributes; - Certificate holders that are issued certificates 338 and can sign digital documents; - Clients that validate digital 339 signatures and their certification paths from a known public key of a 340 trusted CA; - Repositories that store and make available certificates 341 and Certificate Revocation Lists (CRLs). 343 Figure 1 is a simplified view of the architectural model assumed by 344 the PKIX Working Group. 346 +---+ 347 | C | +------------+ 348 | e | <-------------------->| End entity | 349 | r | Operational +------------+ 350 | t | transactions ^ 351 | | and management | Management 352 | / | transactions | transactions 353 | | | PKI users 354 | C | v 355 | R | -------------------+--+-----------+---------------- 356 | L | ^ ^ 357 | | | | PKI management 358 | | v | entities 359 | R | +------+ | 360 | e | <---------------------| RA | <---+ | 361 | p | Publish certificate +------+ | | 362 | o | | | 363 | s | | | 364 | I | v v 365 | t | +------------+ 366 | o | <------------------------------| CA | 367 | r | Publish certificate +------------+ 368 | y | Publish CRL ^ 369 | | | 370 +---+ Management | 371 transactions | 372 v 373 +------+ 374 | CA | 375 +------+ 376 Figure 1 - PKI Entities 378 3.4 X.509 certificates 380 ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8, which was 381 first published in 1988 as part of the X.500 Directory 382 recommendations, defines a standard certificate format [X.509]. The 383 certificate format in the 1988 standard is called the version 1 (v1) 384 format. 386 When X.500 was revised in 1993, two more fields were added, resulting 387 in the version 2 (v2) format. These two fields may be used to support 388 directory access control. 390 The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993, 391 include specifications for a public key infrastructure based on 392 X.509v1 certificates [RFC 1422]. The experience gained in attempts 393 to deploy RFC 1422 made it clear that the v1 and v2 certificate 394 formats are deficient in several respects. Most importantly, more 395 fields were needed to carry information which PEM design and 396 implementation experience has proven necessary. In response to these 397 new requirements, ISO/IEC/ITU and ANSI X9 developed the X.509 version 398 3 (v3) certificate format. The v3 format extends the v2 format by 399 adding provision for additional extension fields. Particular 400 extension field types may be specified in standards or may be defined 401 and registered by any organization or community. In June 1996, 402 standardization of the basic v3 format was completed [X.509]. 404 ISO/IEC/ITU and ANSI X9 have also developed standard extensions for 405 use in the v3 extensions field [X.509][X9.55]. These extensions can 406 convey such data as additional subject identification information, 407 key attribute information, policy information, and certification path 408 constraints. However, the ISO/IEC/ITU and ANSI X9 standard 409 extensions are very broad in their applicability. In order to 410 develop interoperable implementations of X.509 v3 systems for 411 Internet use, it is necessary to specify a profile for use of the 412 X.509 v3 extensions tailored for the Internet. It is one goal of 413 PKIX to specify a profile for Internet WWW, electronic mail, and 414 IPsec applications. Environments with additional requirements may 415 build on this profile or may replace it. 417 3.5 Functions of a PKI 419 This section describes the major functions of a PKI. In some cases, 420 PKIs may provide extra functions. 422 3.5.1 Registration 424 This is the process whereby a subject first makes itself known to a 425 CA (directly, or through an RA), prior to that CA issuing a 426 certificate or certificates for that subject. Registration involves 427 the subject providing its name (e.g., common name, fully-qualified 428 domain name, IP address), and other attributes to be put in the 429 certificate, followed by the CA (possibly with help from the RA) 430 verifying in accordance with its CPS that the name and other 431 attributes are correct. 433 3.5.2 Initialization 435 Initialization is when the subject - e.g., the user or client system 436 - gets the values needed to begin communicating with the PKI. For 437 example, initialization can involve providing the client system with 438 the public key and/or certificate of a CA, or generating the client 439 system's own public/private key pair. 441 3.5.3 Certification 443 This is the process in which a CA issues a certificate for a 444 subject's public key, and returns that certificate to the subject 445 and/or posts that certificate in a repository. 447 3.5.4 Key Pair Recovery 449 In some implementations, key exchange or encryption keys will be 450 required by local policy to be "backed up", or recoverable in case 451 the key is lost and access to previously-encrypted information is 452 needed. Such implementations can include those where the private key 453 exchange key is stored on a hardware token which can be lost or 454 broken, or when a private key file is protected by a password which 455 can be forgotten. Often, a company is concerned about being able to 456 read mail encrypted by or for a particular employee when that 457 employee is no longer available because she is ill or no longer works 458 for the company. 460 In these cases, the user's private key can be backed up by a CA or by 461 a separate key backup system. If a user or her employer needs to 462 recover these backed up key materials, the PKI must provide a system 463 that permits the recovery WITHOUT providing an unacceptable risk of 464 compromise of the private key. 466 3.5.5 Key Generation 468 Depending on the CA's policy, the private/public key pair can either 469 be generated by the user in his local environment, or generated by 470 the CA. In the latter case, the key material may be distributed to 471 the user in an encrypted file or on a physical token - e.g., a smart 472 card or PCMCIA card. 474 3.5.6 Key Update 476 All key pairs need to be updated regularly, i.e., replaced with a new 477 key pair, and new certificates issued. This will happen in two 478 cases: normally, when a key has passed its maximum usable lifetime; 479 and exceptionally, when a key has been compromised and must be 480 replaced. 482 In the normal case, a PKI needs to provide a facility to gracefully 483 transition from a certificate with an existing key to a new 484 certificate with a new key. This is particularly true when the key 485 to be updated is that of a CA. Users will know in advance that the 486 key will expire on a certain date; the PKI, working together with 487 certificate-using applications, should allow for appropriate keys to 488 work before and after the transition. There are a number of ways to 489 do this; see [insert appropriate reference here] for an example of 490 one. In the case of a key compromise, the transition will not be 491 "graceful" in that there will be an unplanned switch of certificates 492 and keys; users will not have known in advance what was about to 493 happen. Still, the PKI must support the ability to declare that the 494 previous certificate is now invalid and shall not be used, and to 495 announce the validity and availability of the new certificate. 497 Note that compromise of a private key associated with a rootCA is 498 catastrophic for users relying on that rootCA. If a rootCA's 499 private key is compromised, that CA must be taken down and brought 500 up again with a new key. Until such time as the rootCA is brought 501 back up, though, users relying on that rootCA are cut off from the 502 rest of the system, as there is no way to develop a valid 503 certification path back to a trusted node. 505 Further, users will likely have to be notified by out-of-band 506 mechanisms about the change in CA keys. If the old key is 507 compromised, any "update" message telling subordinates to switch to a 508 new key could have come from an attacker in possession of the old 509 key, and could point to a new public key for which the attacker 510 already has the private key. It is possible to have anticipated this 511 event, and "pre-placed" replacement rootCA keys with all relying 512 parties, but some secure, out-of-band mechanism will have to be used 513 to tell users to make the switch, and this will only help if the 514 replacement key has not been compromised. 516 Additionally, once the rootCA is brought back up with a new key, it 517 will likely be necessary to re-issue certificates, signed with the 518 new key, to all subordinate users, since their current certificate 519 would be signed with a now-revoked key. 521 3.5.7 Cross-certification 523 A cross-certificate is a certificate issued by one CA to another CA 524 which contains a public CA key associated with the private CA 525 signature key used for issuing certificates. Typically, a cross- 526 certificate is used to allow client systems/end entities in one 527 administrative domain to communicate security with client systems/end 528 users in another administrative domain. Use of a cross-certificate 529 issued from CA_1 to CA_2 allows user Alice, who trusts CA_1, to 530 accept a certificate used by Bob, which was issued by CA_2. 532 Note: cross-certificates can also be issued from one CA to another 533 CA in the same administrative domain, if required. 535 Cross-certificates can be issued in only one direction, or in both 536 directions, between two CA's. That is, just because CA_1 issues a 537 cross-certificate for CA_2 does not require CA_2 to issue a cross- 538 certificate for CA_1. 540 3.5.8 Revocation 542 When a certificate is issued, it is expected to be in use for its 543 entire validity period. However, various circumstances may cause a 544 certificate to become invalid prior to the expiration of the validity 545 period. Such circumstances include change of name, change of 546 association between subject and CA (e.g., an employee terminates 547 employment with an organization), and compromise or suspected 548 compromise of the corresponding private key. Under such 549 circumstances, the CA needs to revoke the certificate. 551 X.509 defines one method of certificate revocation. This method 552 involves each CA periodically issuing a signed data structure called 553 a certificate revocation list (CRL). A CRL is a time stamped list 554 identifying revoked certificates which is signed by a CA and made 555 freely available in a public repository. Each revoked certificate is 556 identified in a CRL by its certificate serial number. When a 557 certificate-using system uses a certificate (e.g., for verifying a 558 remote user's digital signature), that system not only checks the 559 certificate signature and validity but also acquires a suitably- 560 recent CRL and checks that the certificate serial number is not on 561 that CRL. The meaning of "suitably-recent" may vary with local 562 policy, but it usually means the most recently-issued CRL. A CA 563 issues a new CRL on a regular periodic basis (e.g., hourly, daily, or 564 weekly). CA's may also issue CRLs aperiodically; e.g., if an 565 important key is deemed compromised, the CA may issue a new CRL to 566 expedite notification of that fact, even if the next CRL does not 567 have to be issued for some time. (A problem of aperiodic CRL issuance 568 is that end-entities may not know that a new CRL has been issued, and 569 thus may not retrieve it from a repository.) 570 An entry is added to the CRL as part of the next update following 571 notification of revocation. An entry may be removed from the CRL 572 after appearing on one regularly scheduled CRL issued beyond the 573 revoked certificate's validity period. 575 An advantage of the CRL revocation method is that CRLs may be 576 distributed by exactly the same means as certificates themselves, 577 namely, via untrusted communications and server systems. 579 One limitation of the CRL revocation method, using untrusted 580 communications and servers, is that the time granularity of 581 revocation is limited to the CRL issue period. For example, if a 582 revocation is reported now, that revocation will not be reliably 583 notified to certificate-using systems until the next CRL is issued -- 584 this may be up to one hour, one day, or one week depending on the 585 frequency that the CA issues CRLs. 587 As with the X.509 v3 certificate format, in order to facilitate 588 interoperable implementations from multiple vendors, the X.509 v2 CRL 589 format needed to be profiled for Internet use. This was done as part 590 of [RFC 2459]. However, PKIX does not require CAs to issue CRLs. On- 591 line methods of revocation notification may be applicable in some 592 environments as an alternative to the X.509 CRL. PKIX defines a 593 protocol known as OCSP [OCSP] to facilitate on-line checking of the 594 status of certificates. 596 On-line revocation checking may significantly reduce the latency 597 between a revocation report and the distribution of the information 598 to relying parties. Once the CA accepts the report as authentic and 599 valid, any query to the on-line service will correctly reflect the 600 certificate validation impacts of the revocation. However, these 601 methods impose new security requirements; the certificate validator 602 must trust the on-line validation service while the repository does 603 not need to be trusted. 605 3.5.9 Certificate and Revocation Notice Distribution/Publication 607 As alluded to in sections x and y above, the PKI is responsible for 608 the distribution of certificates and certificate revocation notices 609 (whether in CRL form or in some other form) in the system. 610 "Distribution" of certificates includes transmission of the 611 certificate to its owner, and may also include publication of the 612 certificate in a repository. "Distribution" of revocation notices 613 may involve posting CRLs in a repository, transmitting them to end- 614 entities, and/or forwarding them to on-line responders. 616 3.6 Parts of PKIX 618 This section identifies the five different areas in which the PKIX 619 working group has developed documents. The first area involves 620 profiles of the X.509 v3 certificate standards and the X.509v2 CRL 621 standards for the Internet. The second area involves operational 622 protocols, in which relying parties can obtain information such as 623 certificates or certificate status. The third area covers management 624 protocols, in which different entities in the system exchange 625 information needed for proper management of the PKI. The fourth area 626 provides information about certificate policies and certificate 627 practice statements, covering the areas of PKI security not directly 628 addressed in the rest of PKIX. The fifth area deals with providing 629 time stamping and data certification services, which can be used to 630 build such services as non-repudiation. 632 3.6.1 Profile 634 An X.509v3 certificate is a very complex data structure. It consists 635 of basic information fields, plus a number of optional certificate 636 extensions. Many of the fields and numerous extensions can take on a 637 wide range of options. This provides an enormous degree of 638 flexibility, which allows the X.509v3 certificate format to be used 639 with a wide range of applications in a wide range of environments. 640 Unfortunately, this same flexibility makes it extremely difficult to 641 produce independent implementations that will actually interoperate 642 with one another. In order to build an Internet PKI based on X.509v3 643 certificates, the PKIX working group had to develop a profile of the 644 X.509v3 specification. 646 A profile of the X.509v3 specification is a description of the 647 contents of the certificate and which certificate extensions must be 648 supported, which extensions may be supported, and which extensions 649 may not be supported. [RFC 2459] provides such a profile of X.509v3 650 for the Internet PKI. In addition, [RFC 2459] suggests ranges of 651 values for many of the extensions. 653 [RFC 2459] also provides a profile for Version 2 CRLs for use in the 654 Internet PKI. CRLs, like certificates, have a number of optional 655 extensions. In order to promote interoperability, it is necessary to 656 constrain the choices an implementor supports. 658 In addition to profiling the certificate and CRL formats, it is 659 necessary to specify particular Object Identifiers (OIDs) for certain 660 encryption algorithms, because there are a variety of OIDs registered 661 for some algorithm suites. Thus, PKIX has produced two documents 662 ([ECDSA] and [KEA]) which provide guidance on the proper 663 implementation of specific algorithms. 665 Certain organizations, such as countries, have recently mandated 666 certain restrictions on certificates (such as that the subject of a 667 certificate must be a natural person, or that the country of 668 citizenship and/or country of residence of the subject must be 669 included in the certificate). A certificate which meets these 670 restrictions is deemed a "qualified certificate." In December 1998, 671 PKIX adopted as a work item the development of a refinement of 672 [RFC2459] that further profiles PKIX certificates into qualified 673 certificates. This work is reflected in [QC]. 675 3.6.2 Operational Protocols 677 Operational protocols are required to deliver certificates and CRLs 678 (or other certificate status information) to certificate using 679 systems. Provision is needed for a variety of different means of 680 certificate and CRL delivery, including distribution procedures based 681 on LDAP, HTTP, FTP, and X.500. Operational protocols supporting 682 these functions are defined in [FTP], [OCSP], [LDAP], and [WEB]. 684 3.6.3 Management Protocols 686 Management protocols are required to support on-line interactions 687 between PKI user and management entities. For example, a management 688 protocol might be used between a CA and a client system with which a 689 key pair is associated, or between two CAs which cross-certify each 690 other. A management protocol can be used to carry user or client 691 system registration information, or a request for revocation of a 692 certificate. 694 There are two parts to a "management protocol". The first is the 695 format of the messages that will be sent, and the second is the 696 actual protocol that governs the transmission of those messages. 697 Originally, the PKIX working group developed two documents ([CRMF] 698 and [CMMF]) that together described the necessary set of message 699 formats, and two other documents ([CMP] and [CMC]) that described 700 protocols for exchanging those messages. However, the message 701 formats defined in [CMMF] were inserted into both [CMP] and [CMC], 702 and thus [CMMF] will be dropped as a PKIX document. 704 3.6.4 Policy Outline 706 As mentioned before, profiling certificates and specifying 707 operational and management protocols only addresses a part of the 708 problem of actually developing and implementing a secure PKI. What is 709 also needed is the development of a certificate policy and 710 certification practice statement, and then following those documents. 711 The CP and CPS should address physical and personnel security, 712 subject identification requirements, revocation policy, and a number 713 of other topics. [PKIX-4] provides a framework for certification 714 practice statements. 716 3.6.5 Time-Stamp and Data Certification Services 718 In late 1998, the PKIX working group began two efforts that were not 719 in the original working group charter, but were deemed to be 720 appropriate because they described infrastructure services that could 721 be used to provide desired security services. The first of these is 722 time stamping, described in [TSP]. Time stamping is a service in 723 which a trusted third party - a Time Stamp Authority, or TSA - signs 724 a message, in order to provide evidence that it existed prior to a 725 given time. Time stamping provides some support for non-repudiation, 726 in that a user cannot claim that a transaction was later forged after 727 compromise of a private key, because the existence of the signed time 728 stamp indicates that the transaction in question could not have been 729 created after the indicated time. 731 [TSP] also defines the role of a Temporal Data Authority, or TDA. A 732 TDA is a TTP that creates a temporal data token. This temporal data 733 token associates a message with a particular event and provides 734 supplementary evidence for the time included in the time stamp token. 735 For example, a TDA could associate the message with the most recent 736 closing value of the Dow Jones Average. The temporal data with which 737 the message is associated should be unpredictable in order to prevent 738 forward dating of tokens. 740 The second new effort is the definition of a Data Certification 741 Server, or DCS, protocol [DCS]. A DCS is a Trusted Third Party that 742 verifies the correctness of specific data submitted to it. 744 This is different from the TSP service in that a TSA will not attempt 745 to parse and/or verify a message sent to it for certification; 746 instead, it will merely append a reliable indication of the current 747 time, and sign the resulting string-of-bits. This offers an 748 indication that the given string-of-bits existed at a specified time; 749 it does not offer any indication of the correctness or relevance of 750 that string of bits. By contrast, the DCS certifies possession of 751 data or the validity of another entity's signature. As part of this, 752 the DCS verifies the mathematical correctness of the actual signature 753 value contained in the request and also checks the full certification 754 path from the signing entity to a trusted point (e.g., the DCS's CA, 755 or the root CA in a hierarchy). 757 The DCS supports non-repudiation in two ways. First, it provides 758 evidence that a signature or public key certificate was valid at the 759 time indicated in the token. The token can be used even after the 760 corresponding public key certificate expires and its revocation 761 information is no longer available on CRLs (for example). Second, the 762 production of a data certification token in response to a signed 763 request for certification of another signature or public key 764 certificate also provides evidence that due diligence was performed 765 by the requester in validating the signature or public key 766 certificate. 768 4 PKIX Documents 770 This section describes each of the documents written by the PKIX 771 working group. As PKIX progresses, this section will need to be 772 continually updated to reflect the status of each document (e.g., 773 Proposed Standard, Draft Standard, Standard, Informational Draft, 774 Informational RFC, something-that-was-just-thrown-out-for- 775 consideration, etc.) 777 4.1 Profile 779 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate 780 and CRL Profile (RFC 2459) 782 DESCRIPTION: This document describes the profiles to be used for 783 X.509v3 certificates and version2 CRLs by Internet PKI participants. 784 The profiles include the identification of ISO/IEC/ITU and ANSI 785 extensions which may be useful in the Internet PKI. The profiles are 786 presented in the 1988 Abstract Syntax Notation One (ASN.1) rather 787 than the 1994 syntax used in the ISO/IEC/ITU standards. Would-be 788 PKIX implementors and developers of certificate-using applications 789 should start with [RFC 2459] to ensure that their systems will be 790 able to interoperate with other users of the PKI. 792 [RFC 2459] also includes path validation procedures. The procedures 793 presented are based upon the ISO/IEC/ITU definition, but the 794 presentation assumes one or more self-signed trusted CA certificates. 795 The procedures are provided as examples only. Implementations are 796 not required to use the procedures provided; they may implement 797 whichever procedures are efficient for their situation. However, 798 implementations are required to derive the same results as the 799 example procedures. 801 STATUS: Proposed Standard; approved 29 September 1998. 803 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure: 804 Representation of Elliptic Curve Digital Signature Algorithm (ECDSA) 805 Keys and Signatures in Internet X.509 Public Key Infrastructure 806 Certificates 808 DESCRIPTION: This document provides Object Identifiers (OIDs) and 809 other guidance for IPKI users who use the Elliptic Curve Digital 810 Signature Algorithm (ECDSA). It profiles the format and semantics of 811 the subjectPublicKeyInfo field and the keyUsage extension in X.509 V3 812 certificates containing ECDSA keys. This document should be used by 813 anyone wishing to support ECDSA; others who do not support ECDSA are 814 not required to comply with it. 816 STATUS: 818 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure 819 Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 820 Public Key Infrastructure Certificates (RFC ####) 822 DESCRIPTION: This document provides Object Identifiers (OIDs) and 823 other guidance for IPKI users who use the Key Exchange Algorithm 824 (KEA). It profiles the format and semantics of the 825 subjectPublicKeyInfo field and the keyUsage extension in X.509 V3 826 certificates containing KEA keys. This document should be used by 827 anyone wishing to support KEA; others who do not support ECDSA are 828 not required to comply with it. 830 STATUS: Informational RFC; approved 22 January 1999. 832 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Enhanced CRL 833 Distribution Options (OpenCDP) 835 DESCRIPTION: This document proposes an alternative to the CRL 836 Distribution Point (CDP) approach documented in [RFC 2459]. OCDP 837 separates the CRL location function from the process of certificate 838 and CRL validation, and thus claims some benefits over the CDP 839 approach. 841 STATUS: 843 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Qualified 844 Certificates 846 DESCRIPTION: This document profiles the format for and defines 847 requirements on information content in a specific type of 848 certificates called Qualified Certificates. A "Qualified Certificate" 849 is a certificate that is issued to a natural person (i.e., a living 850 human being); contains an unmistakable identity based on a real name 851 or a pseudonym of the subject; exclusively indicates non-repudiation 852 as the key usage for the certificate's public key; and meets a number 853 of requirements. 855 STATUS: 857 4.2 Operational Protocols 859 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Operational 860 Protocols - LDAPv2 862 DESCRIPTION: This document describes the use of LDAPv2 as a protocol 863 for PKI elements to publish and retrieve certificates and CRLs from a 864 certificate repository. LDAPv2 [RFC 1777] is a protocol that allows 865 publishing and retrieving of information. 867 STATUS: 869 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure LDAPv2 870 Schema 872 DESCRIPTION: This document defines a minimal schema necessary to 873 support the use of LDAPv2 for certificate and CRL retrieval and 874 related functions for PKIX. This document supplements [LDAP] by 875 identifying the PKIX-related attributes that must be present. 877 STATUS: 879 DOCUMENT TITLE: X.509 Internet Public Key Infrastructure Online 880 Certificate Status Protocol - OCSP 882 DESCRIPTION: This document specifies a protocol useful in 883 determining the current status of a certificate without the use of 884 CRLs. A major complaint about certificate-based systems is the need 885 for a relying party to retrieve a current CRL as part of the 886 certificate validation process. Depending on the size of the CRL, 887 this can cause severe problems for bandwidth-challenged devices. 888 Depending on the frequency of CRL issuance, this can also cause 889 timeliness problems. (E.g., if CRLs are only published weekly, with 890 no interim releases, a certificate could actually have been revoked 891 for just short of one week without it being on the current CRL, and 892 thus improper use of that certificate could still be occurring.) 894 OCSP attempts to address those problems. It provides a mechanism 895 whereby a relying party identifies one or more certificates to an 896 approved OCSP "responder", and the responder sends back the current 897 status of the certificate(s) - e.g., "revoked", "notRevoked", 898 "unknown". This can dramatically reduce the bandwidth required to 899 transmit revocation status - a relying party does not have to 900 retrieve a CRL of many entries to check the status of one 901 certificate. It can (although it is not guaranteed to) improve the 902 timeliness of revocation notification, and thus reduce the window of 903 opportunity for someone trying to use a revoked certificate. 905 STATUS: 907 DOCUMENT TITLE: Internet Public Key Infrastructure: Caching the 908 Online Certificate Status Protocol 911 DESCRIPTION: To improve the degree to which it can scale, OCSP 912 allows caching of responses - e.g., at intermediary servers, or even 913 at the relying party's end system. This document describes how to 914 support OCSP caching at intermediary servers. 916 STATUS: 918 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Operational 919 Protocols: FTP and HTTP 921 DESCRIPTION: This document describes the use of the File Transfer 922 Protocol (FTP) and the Hyper-text Transfer Protocol (HTTP) to obtain 923 certificates and CRLs from PKI repositories. 925 STATUS: 927 DOCUMENT TITLE: WEB based Certificate Access Protocol-- WebCAP/1.0 929 DESCRIPTION: This document specifies a set of methods, headers, and 930 content-types ancillary to HTTP/1.1 to publish, retrieve X.509 931 certificates and Certificate Revocation Lists. This protocol also 932 facilitates determining current status of a digital certificate 933 without the use of CRLs. This protocol defines new methods, request 934 and response bodies, error codes to HTTP/1.1 protocol for securely 935 publishing, retrieving, and validating certificates across a 936 firewall. 938 STATUS: 940 4.3 Management Protocols 942 DOCUMENT TITLE: Certificate Management Messages over CMS 945 DESCRIPTION: This document defines the means by which PKI clients and 946 servers may exchange PKI messages when using S/MIME's Cryptographic 947 Message Syntax [CMS]as a transaction envelope. CMC supports the 948 certificate request message body specified in the Certificate Request 949 Message Format [CRMF] documents, as well as a variety of other 950 certificate management messages. The primary purpose of this 951 specification is to allow the use of an existing protocol (S/MIME)as 952 a PKI management protocol, without requiring the development of an 953 entirely new protocol such as CMP. A secondary purpose is to codify 954 in IETF standards the current industry practice of using PKCS 10 955 messages [PKCS10] for certificate requests. DOCUMENT TITLE: Internet 956 X.509 Public Key Infrastructure Certificate Management Message 957 Formats 959 DESCRIPTION: This document contains the formats for a series of 960 messages important in certificate/PKI management. These messages let 961 CA's, RA's, and relying parties communicate with each other. Note 962 that this document only specifies message formats; it does not 963 specify a protocol for transferring messages. That protocol can be 964 either CMP or CMC, or perhaps another custom protocol. 966 STATUS: Will be discontinued, as all useful information from it has 967 been moved into [CMP] and [CMC]. 969 DOCUMENT TITLE: Internet X.509 Certificate Request Message Format 970 (RFC####) 972 DESCRIPTION: CRMF specifies a format recommended for use whenever a 973 relying party is requesting a certificate from a CA or requesting 974 that an RA help it get a certificate. This document is distinct from 975 CMMF for historical reasons - the request message format was needed 976 before many of the other message formats had to be finalized, and so 977 it was put into a separate document. Like CMMF, this document only 978 specifies the format of a message. Specification of a protocol to 979 transport that message is beyond the scope of CRMF. 981 STATUS: Proposed Standard; approved 22 January 1999. 983 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate 984 Management Protocols (RFC ####) 986 DESCRIPTION: This document specifies a new protocol specifically 987 developed for the purpose of transporting messages like those 988 specified in CMMF and CRMF among PKI elements. In general, CMP will 989 be used in conjunction with CMMF and CRMF, and will then be run over 990 a transfer service (e.g., S/MIME, HTTP) to provide a complete PKI 991 management service. 993 STATUS: Proposed Standard; approved 22 January 1999. 995 4.4 Policy Outline 997 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate 998 Policy and Certification Practices Framework (RFC ####) 1000 DESCRIPTION: As noted before, the specification and implementation of 1001 certificate profiles, operational protocols, and management protocols 1002 is only part of building a PKI. Equally as important - if not more 1003 important - is the development and enforcement of a certificate 1004 security policy, and a Certification Practice Statement (CPS). The 1005 purpose of this document (PKIX-4) is to establish a clear 1006 relationship between certificate policies and(CPSs), and to present a 1007 framework to assist the writers of certificate policies or CPSs with 1008 their tasks. In particular, the framework identifies the elements 1009 that may need to be considered in formulating a certificate policy or 1010 a CPS. The purpose is not to define particular certificate policies 1011 or CPSs, per se. 1013 STATUS: Informational RFC, approved 22 January 1999. 1015 4.5 Time-Stamp and Data Certification Services 1017 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Time Stamp 1018 Protocols 1020 DESCRIPTION: This document defines the specification for a time stamp 1021 service. It defines a Time Stamp Authority, or TSA, a trusted third 1022 party who maintains a reliable time service. When the TSA receives a 1023 time stamp request, it appends the current time to the request and 1024 signs it into a token to certify that the original request existed 1025 prior to the indicated time. This helps provide non-repudiation by 1026 preventing someone (either a legitimate user or an attacker who has 1027 successfully compromised a key) from "back-dating" a transaction. It 1028 also makes it more difficult to challenge a transaction by asserting 1029 that it has been back-dated. Note that the TSA does not provide any 1030 data parsing service; that is, the TSA does not attempt to validate 1031 that which it signs; it merely regards it as a string of bits whose 1032 meaning is unimportant, but existence is vital. 1034 STATUS: 1036 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Data 1037 Certification Server Protocols 1039 DESCRIPTION: This document defines a data certification service, or 1040 DCS, which can be used to certify both the existence and correctness 1041 of a message or signature. In contrast to the time stamp service 1042 described above, the DCS certifies possession of data or the validity 1043 of another entity's signature. As part of this, the DCS verifies the 1044 mathematical correctness of the actual signature value contained in 1045 the request and also checks the full certification path from the 1046 signing entity to a trusted point (e.g., the DCS's CA, or the root CA 1047 in a hierarchy). 1049 The DCS supports non-repudiation in two ways. First, it provides 1050 evidence that a signature or public key certificate was valid at the 1051 time indicated in the token. The token can be used even after the 1052 corresponding public key certificate expires and its revocation 1053 information is no longer available on CRLs (for example). Second, the 1054 production of a data certification token in response to a signed 1055 request for certification of another signature or public key 1056 certificate also provides evidence that due diligence was performed 1057 by the requester in validating the signature or public key 1058 certificate. 1060 STATUS: 1062 5 Advice to Implementors 1064 This section provides guidance to those who would implement various 1065 parts of the PKIX suite of documents. The topics discussed in this 1066 section engendered significant discussion in the working group, and 1067 there was at times either widespread disagreement or widespread 1068 misunderstanding of them. Thus, this discussion is provided to help 1069 readers of the PKIX document set understand these issues, in the hope 1070 of fostering greater interoperability among eventual PKIX 1071 implementations. 1073 5.1 Names 1075 PKIX has been referred to as a "name-centric" PKI because the 1076 certificates associate public keys with names of entities. Each 1077 certificate contains at least one name for the owner of a particular 1078 public key. The name can be an X.500 distinguished name, contained 1079 in the subjectDN field of the certificate. There can also be names 1080 such as RFC822 e-mail addresses, DNS domain names, and URIs 1081 associated with the key; these attributes are kept in the 1082 subjectAltName extension of the certificate. A certificate must 1083 contain at least one of these name forms, it may contain multiple 1084 forms if deemed appropriate by the CA based on the intended usage of 1085 the certificate. 1087 5.1.1 Name Forms 1089 There are two possible places to put a name in an X.509v3 1090 certificate. One is the subject field in the base certificate (often 1091 called the "Distinguished Name" or "DN" field), and the other is in 1092 the subjectAltName extension. 1094 5.1.1.1 Distinguished Names 1096 According to [RFC 2459], a PKIX certificate must have a non-null 1097 value in the Subject field, except for an end-entity certificate, 1098 which is permitted to have an empty subject field. Furthermore, if a 1099 certificate has a non-null Subject field, it MUST contain an X.500 1100 Distinguished Name. 1102 5.1.1.2 SubjectAltName Forms 1104 In addition to the DN, a PKIX certificate may have one or more values 1105 in the subjectAltName extension. 1107 The subjectAltName extension allows additional identities to be bound 1108 to the subject of the certificate - e.g., it allows "umbc.edu" and 1109 "130.85.1.3" to be associated with a particular subject, as well as 1110 "C=US, O=University of Maryland, L=Baltimore, CN=UMBC". 1111 X.509-defined options for this extension include: Internet 1112 electronic mail addresses; DNS names; IP addresses; and uniform 1113 resource indentifiers (URIs). Other options can exist, including 1114 locally-defined name forms. 1116 A single subjectAltName extension can include multiple name forms, 1117 and multiple instances of each name form. 1119 Whenever such Alternate Name forms are to be bound into a 1120 certificate, the subject alternative name (or issuer alternative 1121 name) extension must be used. It is technically possible to embed an 1122 Alternate Name Form in the subject field. For example, one could 1123 make a DN contain an IP address via a kludge such as "C=US, 1124 L=Baltimore, CN=130.85.1.3". However, this usage is deprecated; the 1125 alternative name extension is the preferred location for finding such 1126 information. As another example, some legacy implementations exist 1127 where an RFC822 name is embedded in the subject distinguished name as 1128 an EmailAddress attribute. Per [RFC 2459], PKIX-compliant 1129 implementations generating new certificates with electronic mail 1130 addresses MUST use the rfc822Name in the subject alternative name 1131 field to describe such entities. Simultaneous inclusion of the 1132 EmailAddress attribute in the subject distinguished name to support 1133 legacy implementation is deprecated but permitted. 1135 In line with this, if the only subject identity included in a 1136 certificate is an alternative name form, then the subject 1137 distinguished name must be empty (technically, an empty sequence), 1138 and the subjectAltName extension must be present. If the subject 1139 field contains an empty sequence, the subjectAltName extension must 1140 be marked critical. 1142 If the subjectAltName extension is present, the sequence must contain 1143 at least one entry. Unlike the subject field, conforming CAs shall 1144 not issue certificates with subjectAltNames containing empty 1145 GeneralName fields. For example, an rfc822Name is represented as an 1146 IA5String. While an empty string is a valid IA5String, such an 1147 rfc822Name is not permitted by PKIX. The behavior of clients that 1148 encounter such a certificate when processing a certification path is 1149 not defined by this working group. 1151 Because the subject alternative name is considered to be definitively 1152 bound to the public key, all parts of the subject alternative name 1153 must be verified by the CA. 1155 5.1.1.2.1 Internet e-mail addresses 1157 When the subjectAltName extension contains an Internet mail address, 1158 the adress is included as an rfc822Name. The format of an rfc822Name 1159 is an "addr-spec" as defined in RFC 822 [RFC 822]. An addr-spec has 1160 the form local-part@domain; it does not have a phrase (such as a 1161 common name) before it, or a comment (text surrounded in parentheses) 1162 after it, and it is not surrounded by "<" and ">". 1164 5.1.1.2.2 DNS Names 1166 When the subjectAltName extension contains a domain name service 1167 label, the domain name is stored in the dNSName attribute(an 1168 IA5String). The string shall be in the "preferred name syntax," as 1169 specified by RFC 1034 [RFC 1034]. Note that while upper and lower 1170 case letters are allowed in domain names, no signifigance is attached 1171 to the case. In addition, while the string " " is a legal domain 1172 name, subjectAltName extensions with a dNSName " " are not permitted. 1173 Finally, the use of the DNS representation for Internet mail 1174 addresses (wpolk.nist.gov instead of wpolk@nist.gov) is not 1175 permitted; such identities are to be encoded as rfc822Name. 1177 5.1.1.2.3 IP addresses 1179 When the subjectAltName extension contains an iPAddress, the address 1180 shall be stored in the octet string in "network byte order," as 1181 specified in RFC 791 [RFC 791]. The least significant bit (LSB) of 1182 each octet is the LSB of the corresponding byte in the network 1183 address. For IP Version 4, as specified in RFC 791, the octet string 1184 must contain exactly four octets. For IP Version 6, as specified in 1185 RFC 1883, the octet string must contain exactly sixteen octets 1186 [RFC1883]. 1188 5.1.1.2.4 URIs 1190 [RFC 2459] notes "When the subjectAltName extension contains a URI, 1191 the name MUST be stored in the uniformResourceIdentifier (an 1192 IA5String). The name MUST be a non-relative URL, and MUST follow the 1193 URL syntax and encoding rules specified in [RFC 1738]. The name must 1194 include both a scheme (e.g., "http" or "ftp") and a scheme-specific- 1195 part. The scheme-specific-part must include a fully qualified domain 1196 name or IP address as the host. As specified in [RFC 1738], the 1197 scheme name is not case-sensitive (e.g., "http" is equivalent to 1198 "HTTP"). The host part is also not case-sensitive, but other 1199 components of the scheme-specific-part may be case-sensitive. When 1200 comparing URIs, conforming implementations MUST compare the scheme 1201 and host without regard to case, but assume the remainder of the 1202 scheme-specific-part is case sensitive." 1204 5.1.2 Scope of Names 1206 The original X.500 work presumed that every subject in the world 1207 would have a globally-unique distinguished name. Thus, every subject 1208 could be easily located, and there would never be a conflict. All 1209 that would be needed is a sufficiently-large name space, and rules 1210 for constructing names based on subordination and location. 1212 Obviously, that is not practical in the real world, for a variety of 1213 reasons. There is no single entity in the world trusted by everybody 1214 to reside at the top of the name space, and there is no way to 1215 enforce uniqueness on names for all entities. (These were among the 1216 reasons for the failure of PEM to be widely implemented.) 1218 This does not mean, however, that a name-based PKI cannot work. It 1219 is important to recognize that the scope of names in PKIX is local; 1220 they need to be defined and unique only within their own domain. 1222 Suppose for example that a rootCA is established with DN "O=IETF, 1223 OU=PKIX, CN=PKIX_CA". That CA will then issue certificates for users 1224 subordinate to it. The only requirement - and this can be enforced 1225 procedurally - is that no two distinct entities beneath this rootCA 1226 have the same name. We can't prevent somebody else in the world from 1227 creating her own CA, called "O=IETF, OU=PKIX, CN=PKIX_CA", and it is 1228 not necessary to do so. Within the domain of the original rootCA, 1229 there will be no conflict, and the fact that there is another CA of 1230 the same name in some other domain is irrelevant. 1232 This is analogous to the current DNS or IP address situations. On 1233 the Internet, there is only one node called www.ietf.org. The fact 1234 that there might be 10 different intranets, each with a host given 1235 the DNS name www.ieft.org, is irrelevant and causes no 1236 interoperability problems - those are different domains. However, if 1237 there were to be another node on the Internet with domain name 1238 www.ietf.org, then there would be a problem due to name duplication. 1240 The same applies for IP addresses. As long as only one node on the 1241 Internet responds to the IP address 130.85.1.3, there is no problem, 1242 despite the fact that there are 100 different corporate Intranets, 1243 each using that same IP address. However, if two different nodes on 1244 the Internet each responded to the IP address 130.85.1.3, there would 1245 be a problem. 1247 5.1.3 Certificate Path Construction 1249 Path construction - make point that there is no single best way to 1250 construct a path. Implementors can pick the way that is most 1251 efficient for them. Discuss some of the issues being hashed out in 1252 the "ldap" discussion on the mail list. If there is ever a 1253 resolution, include it in this section. 1255 5.1.4 Name Constraints 1257 (Note: this section still needs a lot of work.) 1259 A question that has arisen a number of times is "how does one enforce 1260 Name constraints when there is more than one name form in a 1261 certificate?" That is, [RFC 2459] states that: 1263 Subject alternative names may be constrained in the same manner as 1264 subject distinguished names using the name constraints extension as 1265 described in section 4.2.1.11. 1267 What does this mean? Suppose that there is a CA with DN "O=IETF, 1268 OU=PKIX, CN=PKIX_CA", with the subjectAltName extension having 1269 dNSName "PKIX_CA.IETF.ORG". Suppose that that CA has issued a 1270 certificate with an empty DN, with subjectAltName extension having 1271 dNSName set to "PKIX_CA.IETF.ORG", and rfc822Name set to 1272 Steve@PKIX_CA.IETF.ORG. The question is, are name constraints 1273 enforced on these two certificates - is the name of the end-entity 1274 certificate considered to be properly subordinate to the name of the 1275 CA? 1277 The answer is "yes". The general rules for deciding whether a 1278 certificate meets name constraints are: 1280 If a certificate complies with name constraints in any one of its 1281 name forms, then the certificate is deemed to comply with name 1282 constraints. 1284 If a certificate contains a name form that its issuer does not, 1285 the certificate is deemed to comply with name constraints for that 1286 name form. 1288 In deciding whether a name form meets name constraints, the following 1289 rules apply: 1291 - for DNs: - for rfc822Names: - for dNSNames: Name A is subordinate 1292 to Name B (in B's subtree) if Name A contains all of Name B's name, 1293 with the addition of zero or more additional domain names to the left 1294 of Name B's name. That is, www.mit.edu is subordinate to mit.edu, as 1295 is larry.cs.mit.edu. However, www.mit.edu is not subordinate to 1296 web.mit.edu. - for URIs: - for iPaddresses: Name A is subordinate to 1297 Name B if... 1299 5.1.5 Wildcards in Name Forms 1301 A "wildcard" in a name form is a placeholder for a set of names; e.g. 1302 "*.mit.edu" meaning "any domain name ending in .mit.edu", and 1303 *@aol.com meaning "email address that uses aol.com". There are many 1304 people who believe that allowing wildcards in name forms in PKIX 1305 certificates would be a useful thing to do, because it would allow a 1306 single certificate to be used by all members of a group. These 1307 members would presumably have attributes in common; e.g., access 1308 rights to some set of resources, and so issuance of a certificate 1309 with a wildcard for the group would simplify management. 1311 After much discussion, the PKIX working group decided to permit the 1312 use of wildcards in certificates. That is, it is permissible for a 1313 PKIX-conformant CA to issue a certificate with a wildcard. However, 1314 the semantics of subject alternative names that include wildcard 1315 characters are not addressed by PKIX. Applications with specific 1316 requirements may use such names but must define the semantics. 1318 5.1.6 Name Encoding 1320 (insert a section on encoding non-ASCII names. Key points to make:) 1321 - UTF8 is the long-term goal for IETF, and is mandatory in 2003 and 1322 later - BMPString is presently supported by most vendors - 1323 Teletexstring containing ISO 8859-1 is also used by many CA's 1325 5.2 POP 1327 Proof of Possession, or POP, means that the CA is adequately 1328 convinced that the entity requesting a certificate containing a 1329 public key Y has access to the private key X corresponding to that 1330 public key. 1332 POP is important because it provides an appropriate level of 1333 assurance in the correct operation of the PKI as a whole. At its 1334 lowest level, POP counters the "self-inflicted denial of service"; 1335 that is, an entity voluntarily getting a certificate that cannot be 1336 used to sign or encrypt/decrypt information. However, as the 1337 following two examples demonstrate, POP also counters less direct, 1338 but more severe, threats: 1340 POP for signing keys: it is important to provide POP for keys used 1341 to sign material, in order to provide non-repudiation of 1342 transactions. For example, suppose Alice legitimately has private 1343 key X and its corresponding public key Y. Alice has a certificate 1344 from Charlie, a CA, containing Y. Alice uses X to sign a 1345 transaction T. Without POP, Mal could also get a certificate from 1346 Charlie containing the same public key, Y. Now, there are two 1347 possible threats: Mal could claim to have been the real signer of 1348 T; or Alice can falsely deny signing T, claiming that it was 1349 instead Mal. Since no one can reliably prove that Mal did or did 1350 not ever possess X, neither of these claims can be refuted, and 1351 thus the service provided by and the confidence in the PKI has 1352 been defeated. (Of course, if Mal really did possess X, Alice's 1353 private key, then no POP mechanism in the world will help, but 1354 that is a different problem.) 1356 Note that one level of protection can be gained by having Alice, 1357 as the true signer of the transaction, include in the signed 1358 information her certificate or an identifier of her certificate 1359 (e.g., a hash of her certificate). This might make it more 1360 difficult for Mal to claim authorship - he would have to assert 1361 that he incorrectly included Alice's certificate, rather than his 1362 own. However, it would not stop Alice from falsely repudiating 1363 her actions. Since the certificate itself is a public item, Mal 1364 indeed could have inserted Alice's certificate into the signed 1365 transaction, and thus its presence does not indicate that Alice 1366 was the one who participated in the now-repudiated transaction. 1367 The only reliable way to stop this attack is to require that Mal 1368 prove he possesses X before his certificate is issued. 1370 For signing keys used only for authentication, and not for non- 1371 repudiation, the threat is lower because users may not care about 1372 Alice's after-the-fact repudiation, and thus POP becomes less 1373 important. However, POP SHOULD still be done wherever feasible in 1374 this environment, by either off-line or on-line means. 1376 POP for key management keys: Similarly, POP for key management keys 1377 (that is, keys used for either key agreement or key exchange) can 1378 help to prevent undermining confidence in the PKI. Suppose that Al 1379 is a new instructor in the Computer Science Department of a local 1380 University. Al has created a draft final exam for the Introduction 1381 to Networking course he is teaching. He wants to send a copy of the 1382 draft final to Dorothy, the Department Head, for her review prior to 1383 giving the exam. This exam will of course be encrypted, as several 1384 students have access to the computer system. However, a quick search 1385 of the certificate repository (e.g., search the repository for all 1386 records with subjectPublicKey=Dorothy's-value) turns up the fact that 1387 several students have certificates containing the same public key 1388 management key as Dorothy. At this point, if no POP has been done by 1389 the CA, Al has no way of knowing whether all of the students have 1390 simply created these certificates without knowing the corresponding 1391 private key (and thus it is safe to send the encrypted exam to 1392 Dorothy), or whether the students have somehow acquired Dorothy's 1393 private key (and thus it is certainly not safe to send the exam). 1394 Thus, the service to be provided by the PKI - allowing users to 1395 communicate with one another, with confidence in who they are 1396 communicating with - has been totally defeated. If the CA is 1397 providing POP, then either no students will have such certificates, 1398 or Al can know with certainty that the students do indeed know 1399 Dorothy's private key, and act accordingly. 1401 CMP requires that POP be provided for all keys, either through on- 1402 line or out-of-band means. There are any number of ways to provide 1403 POP, and the choice of which to use is a local matter. Additionally, 1404 a certificate requester can provide POP to either a CA or to an RA, 1405 if the RA can adequately assure the CA that POP has been performed. 1406 Some of the acceptable ways to provide POP include: 1408 Out-of-band means: 1410 For keys generated by the CA or an RA (e.g., on a token such as a 1411 smart card or PCMCIA card), possession of the token can provide 1412 adequate proof of possession of the private key. 1414 For user-generated keys, another approach can be used in 1415 environments where "key recovery" requirements force the requester 1416 to provide a copy of the private key to the CA or an RA. In this 1417 case, the CA will not issue the requested certificate until such 1418 time as the requester has provided the private key. This approach 1419 is in general not recommended, as it is extremely risky (e.g., the 1420 system designers need to figure out a way to protect the private 1421 keys from compromise while they are being sent to the CA/RA/other 1422 authority, and how to protect them there), but it can be used. 1424 On-line means: 1426 For signature keys that are generated by an end-entity, the 1427 requester of a certificate can be required to sign some piece of 1428 data (typically, the certificate request itself) using the private 1429 key. The CA will then use the requested public key to verify the 1430 signature. If the signature verification works, the CA can safely 1431 conclude that the requester had access to the private key. If the 1432 signature verification process fails, the CA can conclude that the 1433 requester did not have access to the correct private key, and 1434 reject the request. 1436 For key management keys that are generated by the requester, the 1437 CA can send the user the requested public key, along with the CA's 1438 own private key, to encrypt some piece of data, and send it to the 1439 requester to be decrypted. For example, the CA can generate some 1440 random challenge, and require some action to be taken after 1441 decryption (e.g., "decrypt this encrypted random number and send 1442 it back to me"). If the requester does not take the requested 1443 action, the CA concludes that the requester did not possess the 1444 private key, and the certificate is not issued. 1446 Another method of providing POP for key management keys is for the 1447 CA to generate the requested certificate, and then send it to the 1448 requester in encrypted form. If the requester does not have 1449 access to the appropriate private key, the requester cannot 1450 decrypt the certificate, and thus cannot use it. After some period 1451 of time in which the certificate is not used, the CA will revoke 1452 the certificate. (This only works if the certificate is not made 1453 available to any untrusted entities until after the requester has 1454 successfully decrypted it.) 1456 5.3 Key Usage Bits 1458 The key usage extension defines the purpose (e.g., encipherment, 1459 signature, certificate signing) of the key contained in the 1460 certificate. This extension is used when a key that could be used for 1461 more than one operation is to be restricted. For example, when an 1462 RSA key should be used only for signing, the digitalSignature and/or 1463 nonRepudiation bits would be asserted. Likewise, when an RSA key 1464 should be used only for key management, the keyEncipherment bit would 1465 be asserted. When used, this extension should be marked critical. 1467 The eight bits defined for this extension identify seven mechanisms 1468 and one service, namely: 1470 - digitalSignature - nonRepudiation - keyEncipherment - 1471 dataEncipherment - keyAgreement - keyCertSign - cRLSign - 1472 encipherOnly - decipherOnly 1474 According to [RFC 2459], bits in the KeyUsage type are used as 1475 follows: 1477 The digitalSignature bit is asserted when the subject public key 1478 is used to verify digital signatures that have purposes other than 1479 non-repudiation, certificate signature, and CRL signature. For 1480 example, the digitalSignature bit is asserted when the subject 1481 public key is used to provide authentication via the signing of 1482 ephemeral data. 1484 The nonRepudiation bit is asserted when the subject public key is 1485 used to verify digital signatures used to provide a non- 1486 repudiation service which protects against the signing entity 1487 falsely denying some action, excluding certificate or CRL signing. 1489 The keyEncipherment bit is asserted when the subject public key is 1490 used for key transport. For example, when an RSA key is to be 1491 used for key management, this bit must asserted. 1493 The dataEncipherment bit is asserted when the subject public key 1494 is used for enciphering user data, other than cryptographic keys. 1496 The keyAgreement bit is asserted when the subject public key is 1497 used for key agreement. For example, when a Diffie-Hellman key is 1498 to be used for key management, this bit must asserted. 1500 The keyCertSign bit is asserted when the subject public key is 1501 used for verifying a signature on certificates. This bit may only 1502 be asserted in CA certificates. 1504 The cRLSign bit is asserted when the subject public key is used 1505 for verifying a signature on revocation information (e.g., a CRL). 1507 The meaning of the encipherOnly bit is undefined in the absence of 1508 the keyAgreement bit. When the encipherOnly bit is asserted and 1509 the keyAgreement bit is also set, the subject public key may be 1510 used only for enciphering data while performing key agreement. 1512 The meaning of the decipherOnly bit is undefined in the absence of 1513 the keyAgreement bit. When the decipherOnly bit is asserted and 1514 the keyAgreement bit is also set, the subject public key may be 1515 used only for deciphering data while performing key agreement. 1517 PKIX does not restrict the combinations of bits that may be set in an 1518 instantiation of the keyUsage extension. 1520 The discussion on the PKIX mailing list has centered on the 1521 digitalSignature bit and the nonRepudiation bit. The question has 1522 come down to something like: When support for the service of non- 1523 repudiation is desired, should both the digitalSignature and 1524 nonRepudiation bits be set, or just the nonRepudiation bit? 1526 (It is noted that provision of the service of non-repudiation 1527 requires more than a single bit set in a certificate. It requires an 1528 entire infrastructure of components to preserve for some period of 1529 time the keys, certificates, revocation status, signed material, 1530 etc., as well as a trusted source of time. However, the 1531 nonRepudiation key usage bit is provided as an indicator that such 1532 keys should not be used as a component of a system providing a non- 1533 repudiation service.) 1535 According to [SIMONETTI], the intent is that the digitalSignature bit 1536 should be set when what is desired is the ability to sign ephemeral 1537 transactions; e.g., for a single session authentication. These 1538 transactions are "ephemeral" in the sense that they are important 1539 only while they are in existence; after the session is terminated, 1540 there is no long-term record of the digital signature and its 1541 properties kept. When something is intended to be kept for some 1542 period of time, the nonRepudiation bit should be set. This generally 1543 implies that an application will digitally sign something; thus, some 1544 implementors turn on the digitalSignature bit as well. Other 1545 implementors, however, keep the two bits mutually exclusive, to 1546 prevent a single key from being used for both ephemeral and long-term 1547 signing. 1549 While [RFC 2459] is silent on this specific issue, the working 1550 group's general conclusion is that a certificate may have either or 1551 both bits set. If only the nonRepudiation bit is set, the key should 1552 not be used for ephemeral transactions. If only the digitalSignature 1553 bit is set, the key should not be used for long-term signing. If 1554 both bits are set, the key may be used for either purpose. 1556 To actually enforce this requires that an application understands 1557 whether it is signing ephemeral transactions or for the long-term. 1558 The application developers will have to understand the difference, 1559 and set up their checks on the key usage bits field accordingly. For 1560 example, TLS implementors should check only the digitalSignature bit, 1561 and ignore the nonRepudiation bit. S/MIME implementors, though, will 1562 have a difficult choice to make, since their application could be 1563 used for either purpose, and they will generally accept signing using 1564 keys associated with certificates having either or both bits being 1565 turned on. Certification Authorities should know what applications 1566 they are providing certificates for, and provide certificates 1567 according to the requirements of those applications. If CA's are 1568 tied into non-repudiation systems, they may treat certificates 1569 differently when the nonRepudiation bit is turned on (e.g., store 1570 information associated with the certificate - like the user's 1571 identification provided during certificate registration, or 1572 certificate generation date/time stamps - for longer periods of time, 1573 in more secure environments). 1575 The bottom line is that this is an area where PKI implementors are 1576 somewhat limited in what they can do. The onus is on developers of 1577 certificate-using systems to understand their requirements and 1578 request certificates with the appropriate bits set. 1580 5.4 Trust Models 1582 (This section will describe the various trust models that PKIX can 1583 support. It is important to note that PKIX is bound to neither a 1584 pure hierarchical model a la PEM, nor a web of trust model a la PGP. 1585 PKIX can support either of those models, or any flavor in between. 1586 The implications of different trust models should be described: 1588 - efficiency of revocation - certification path building - etc.) 1590 6 Acknowledgements 1592 A lot of the information in this document was taken from the PKIX 1593 source documents; the authors of those deserve the credit for their 1594 own words. Other good material was taken from mail posted to the 1595 PKIX working group mail list (ietf-pkix@imc.org). Among those with 1596 good things to say were (in alphabetical order, with apologies to 1597 anybody we've missed): Sharon Boeyen, Santosh Chokhani, Warwick Ford, 1598 Russ Housley, Steve Kent, Ambarish Malpani, Matt Fite, Michael Myers, 1599 Tim Polk, Stefan Santesson, Dave Simonetti, and. 1601 7 References 1603 [CACHE] "Internet Public Key Infrastructure: Caching the Online 1604 Certificate Status Protocol," , 1605 April 1998 1607 [CMC] Myers, M., Liu, X., Fox, B., and Weinstein, J., "Certificate 1608 Management Messages over CMS," , November 1609 1998 1611 [CMMF] Adams, C., and Myers, M., "Internet X.509 Public Key 1612 Infrastructure Certificate Management Message Formats," , July 1998 1615 [CRMF] Myers, M., Adams, C., Solo, D., and Kemp, D., "Internet X.509 1616 Certificate Request Message Format," RFC 2511, March 1999 1618 [CRS] Myers, M., Liu X., Fox B., Prafullchandra H., Weinstein J., " 1619 Certificate Request Syntax," , November 1620 1997 1622 [CMP] Adams, C., and Farrell, S., "Internet X.509 Public Key 1623 Infrastructure Certificate Management Protocols," RFC 2510, March 1624 1999 1626 [CMS] R. Housley, "Cryptographic Message Syntax," , December 1998 1629 [DCS] Adams, C., and Zuccherato, R., "Internet X.509 Public Key 1630 Infrastructure Data Certification Server Protocols", , 23 September 1998. 1633 [ECDSA] Bassham, L., Johnson, D., and Polk, W., "Internet x.509 1634 Public Key Infrastructure: Representation of Elliptic Curve Digital 1635 Signature Algorithm (ECDSA) Keys and Signatures in Internet X.509 1636 Public Key Infrastructure Certificates," , November 1997 1639 [FTP] Housley, R., and Hoffman, P., "Internet X.509 Public Key 1640 Infrastructure Operational Protocols: FTP and HTTP," , July 1998 1643 [KEA] Housley, R., and Polk, W., "Internet X.509 Public Key 1644 Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in 1645 Internet X.509 Public Key Infrastructure Certificates," RFC ####, 1646 date TBD. 1648 [LDAP] Boeyen, S., Howes, T., and Richard, P., "Internet X.509 Public 1649 Key Infrastructure Operational Protocols - LDAPv2," , September 1998. 1652 [MISPC] Burr, W., Dodson, D., Nazario, N., and Polk, W., "MISPC 1653 Minimum Interoperability Specification for PKI Components, Version 1654 1", September 3, 1997 1656 [OCDP] Hallam-Baker, P., and Ford, W., "Internet X.509 Public Key 1657 Infrastructure Enhanced CRL Distribution Options (OpenCDP)," , August 7, 1998 1660 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and Adams, 1661 C., "X.509 Internet Public Key Infrastructure Online Certificate 1662 Status Protocol - OCSP," , September 1663 1998. 1665 [PKCS10] "Certification Request Syntax Standard", Public Key 1666 Cryptography Standard #10, RSA Laboratories. 1668 [PKIX-4] Chokhani, S., and Ford, W., "Internet X.509 Public Key 1669 Infrastructure Certificate Policy and Certification Practices 1670 Framework," RFC 2527, March 1999. 1672 [QC] Santesson, S., Polk, W., and Gloeckner, P., "Internet X.509 1673 Public Key Infrastructure Qualified Certificates", , 3 February 1999. 1676 [RFC 791] Postel, J., "Internet Protocol", September 1981. 1678 [RFC 822] Crocker, D., "Standard for the Format of ARPA Internet Text 1679 Messages", August 1982. 1681 [RFC 1034] Mockapetris, P.V., "Domain names - concepts and 1682 facilities", November 1987. 1684 [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic 1685 Mail: Part II: Certificate-Based Key Management," February 1993. 1687 [RFC 1777] Yeong, Y., Howes, T., and Kille, S., "Lightweight 1688 Directory Access Protocol", March 1995 1690 [RFC 1883] Deering, S., and Hinden, R., "Internet Protocol, Version 6 1691 [IPv6] Specification", December 1995. 1693 [RFC 2459] Housley, R., Ford, W., Polk, W., and Solo, D., "Internet 1694 X.509 Public Key Infrastructure Certificate and CRL Profile," January 1695 1999. 1697 [SCHEMA] Boeyen, S., Howes, T., and Richard, P., "Internet X.509 1698 Public Key Infrastructure LDAPv2 Schema," , September 1998 1701 [SIMONETTI] Simonetti, D., "Re: German Key Usage", posting to ietf- 1702 pkix@imc.org mailing list, 12 August 1998 1704 [TSP] Adams, C., Cain, P., Pinkas, D., and Zuccherato, R., "Internet 1705 X.509 Public Key Infrastructure Time Stamp Protocols", , 23 September 1998. 1708 [WEB] Reddy, S., "WEB based Certificate Access Protocol-- 1709 WebCAP/1.0," , April 19, 1998 1711 [X.509] ITU-T Recommendation X.509 (1997 E): Information Technology 1712 - Open Systems Interconnection - The Directory: Authentication 1713 Framework, June 1997. 1715 [X9.42] ANSI X9.42-199x, Public Key Cryptography for The Financial 1716 Services Industry: Agreement of Symmetric Algorithm Keys Using 1717 Diffie-Hellman (Working Draft), December 1997. 1719 [X9.55] ANSI X9.55-1995, Public Key Cryptography For The Financial 1720 Services Industry: Extensions To Public Key Certificates And 1721 Certificate Revocation Lists, 8 December, 1995. 1723 [X9.57] ANSI X9.57-199x, Public Key Cryptography For The Financial 1724 Services Industry: Certificate Management (Working Draft), 21 June, 1725 1996. 1727 8 Security Considerations 1729 TBSL 1731 9 Editor's Address 1733 Alfred Arsenault 1734 U. S. Department of Defense 1735 9800 Savage Road Suite 1736 6734 Fort George G. Meade, MD 20755-6734 1737 (410) 684-7114 1738 awarsen@missi.ncsc.mil 1740 Sean Turner 1741 IECA, Inc. 1742 9010 Edgepark Road Vienna, VA 22182 1743 (703) 358-9113 1744 turners@ieca.com 1746 10 Disclaimer 1748 This work constitutes the opinion of the editors only, and may not 1749 reflect the opinions or policies of their employers.