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