idnits 2.17.00 (12 Aug 2021) /tmp/idnits9249/draft-ietf-pkix-roadmap-04.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: ---------------------------------------------------------------------------- ** 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 48 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 49 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 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 2 instances of lines with control characters in the document. == There are 7 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 1435: '... field, it MUST contain an X.500 Dis...' RFC 2119 keyword, line 1463: '...c mail addresses MUST use the rfc822Na...' RFC 2119 keyword, line 1522: '... name MUST be stored in the uniformR...' RFC 2119 keyword, line 1523: '... The name MUST be a non-relative URL...' RFC 2119 keyword, line 1531: '... implementations MUST compare the sche...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The first octets (the first characters of the first line) of this draft are 'PK', which can make Internet Explorer erroneously think that it is a zip file. It is recommended that you change this, for instance by inserting a blank line before the line starting with 'PK'. == Line 1248 has weird spacing: '...tandard exten...' -- 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 (October 22, 1999) is 8246 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: 'BERT1' is mentioned on line 102, but not defined == Missing Reference: 'CACHE' is mentioned on line 102, but not defined == Missing Reference: 'WEB' is mentioned on line 102, but not defined == Missing Reference: 'POLPROC' is mentioned on line 934, but not defined == Missing Reference: 'DCVS' is mentioned on line 397, but not defined == Missing Reference: 'RFC2459' is mentioned on line 870, but not defined ** Obsolete undefined reference: RFC 2459 (Obsoleted by RFC 3280) == Missing Reference: 'HTTP' is mentioned on line 1226, but not defined == Missing Reference: 'TCP' is mentioned on line 1239, but not defined == Missing Reference: 'RFC 1738' is mentioned on line 1527, but not defined ** Obsolete undefined reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) == Unused Reference: 'INTEROP' is defined on line 2166, but no explicit reference was found in the text == Unused Reference: 'POLPRAC' is defined on line 2247, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AC' -- 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. 'CMP-HTTP' -- Possible downref: Non-RFC (?) normative reference: ref. 'CMP-TCP' -- Possible downref: Non-RFC (?) normative reference: ref. 'INTEROP' ** Obsolete normative reference: RFC 2630 (ref. 'CMS') (Obsoleted by RFC 3369, RFC 3370) ** Obsolete normative reference: RFC 2511 (ref. 'CRMF') (Obsoleted by RFC 4211) -- Possible downref: Non-RFC (?) normative reference: ref. 'DHPOP' -- Possible downref: Non-RFC (?) normative reference: ref. 'DVCS' -- 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') -- Possible downref: Non-RFC (?) normative reference: ref. 'LAAP' ** Obsolete normative reference: RFC 1777 (ref. 'LDAPv2') (Obsoleted by RFC 3494) -- Possible downref: Non-RFC (?) normative reference: ref. 'MISPC' ** Obsolete normative reference: RFC 2560 (ref. 'OCSP') (Obsoleted by RFC 6960) -- Possible downref: Non-RFC (?) normative reference: ref. 'OCSPX' ** 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'PKI-LDAPv3' ** 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. 'SCVP' -- Possible downref: Non-RFC (?) normative reference: ref. 'SIMONETTI' -- Possible downref: Non-RFC (?) normative reference: ref. 'TSP' Summary: 25 errors (**), 0 flaws (~~), 17 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PKIX Working Group A. Arsenault 2 INTERNET DRAFT DOD 3 S. Turner 4 IECA 6 Expires April 22, 2000 October 22, 1999 8 Internet X.509 Public Key Infrastructure 9 PKIX Roadmap 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of 6 months 23 and may be updated, replaced, or may become obsolete by other 24 documents at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of current Internet-Drafts Shadow Directories can be 31 accessed at http://www.ietf.org/shadow.html 33 Abstract 35 This document provides an overview or "roadmap" of the work done by 36 the IETF PKIX working group. It describes some of the terminology 37 used in the working group's documents, and the theory behind an 38 X.509-based Public Key Infrastructure and Privilege Management 39 Infrastructure (PMI). It identifies each document developed by the 40 PKIX 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 contributors we wish to thank. Section 7 provides a list references. 67 Section 8 discusses security considerations, and Section 9 provides 68 contact information for the editors. Finally, Section 10 provides a 69 disclaimer. 71 1.2 Changes Since Last Version 73 Updated refences to current drafts. 75 Added terminology to paragraph 2 for Attribute Authorities, Attribute 76 Certificates, Certificates, Public Key Certificates, Public Key 77 Infrastructure, and Privilege Management Infrastructure. 79 Split paragraph 3.1 and 3.3 in two to allow seperate descriptions for 80 PKI (i.e., PKC discussions) and PMI (i.e., AC discussions). 82 Updated PKIX History (paragraph 3.2). 84 Split paragraph 3.4 in two to accomdate discussions for both X.509 85 Certificates and Attribute Certificates. 87 Updated Profiles, Operational Protocols, and Management Protocols 88 paragraphs 3.6.1, 3.6.2, and 3.6.3, respectively. 90 Updated Revocation paragraph 3.5.8 to indicate why a certificate is 91 retained on a CRL for one additional period. 93 Added descriptions for new drafts in 4.1-4.5: Operation Protocols - 94 LDAPv3, Simple Certificate Validation Protocol (SCVP), Using HTTP as 95 Transport Protocol for CMP, Using TCP as Transport Protocol for CMP, 96 Limited Attribute Certificate Aquisition Protocol (LAAP), OCSP 97 Extensions 99 Added paragraph 4.6 to talk about drafts that didn't make it through 100 working group review. 102 Removed references to [BERT1], [CACHE], and [WEB] from paragraph 7. 104 1.3 To Do 106 Add text in paragraph 5.3 to talk about extended key usages. 108 Add in paragraph to talk about PMI functions. 110 Add in paragraph to talk about delta between RFC2459 and the updated 111 RFC2459. 113 2 Terminology 115 There are a number of terms used and misused throughout PKI-related 116 and PMI-related literature. To limit confusion caused by some of 117 those terms, throughout this document, we will use the following 118 terms in the following ways: 120 - Attribute Authority (AA) - An authority trusted by one or more 121 users to create and sign attribute certificates. It is important 122 to note that the AA is responsible for the attribute certificates 123 during their whole lifetime, not just for issuing them. 125 - Attribute Certificate (AC) - A data structure containing a set of 126 attributes for an end-entity and some other information, which is 127 digitally signed with the private key of the AA which issued it. 129 - Certificate - Can refer to either an AC or a public key 130 certificate. Where there is no distinction made the context 131 should be assumed to apply to both an AC and a public key 132 certificate. 134 - Certification Authority (CA) - An authority trusted by one or 135 more users to create and assign public key certificates. 136 Optionally the CA may create the user's keys. It is important to 137 note that the CA is responsible for the public key certificates 138 during their whole lifetime, not just for issuing them. 140 - Certificate Policy (CP) - A named set of rules that indicates the 141 applicability of a public key certificate to a particular 142 community and/or class of application with common security 143 requirements. For example, a particular certificate policy might 144 indicate applicability of a type of public key certificate to the 145 authentication of electronic data interchange transactions for 146 the trading of goods within a given price range. 148 - Certification Practice Statement (CPS) - A statement of the 149 practices which a CA employs in issuing public key certificates. 151 - End-entity - A subject of a certificate who is not a CA in the 152 PKIC or an AA in the PMI. (An EE from the PKI can be an AA in the 153 PMI.) 155 - Public Key Certificate (PKC) - A data structure containing the 156 public key of an end-entity and some other information, which is 157 digitally signed with the private key of the CA which issued it. 159 - Public Key Infrastructure (PKI) - The set of hardware, software, 160 people, policies and procedures needed to create, manage, store, 161 distribute, and revoke PKCs based on public-key cryptography. 163 - Privilege Management Infrastructure (PMI) - A collection of ACs, 164 with their issuing AA's, subjects, relying parties, and 165 repositories, is referred to as a Privilege Management 166 Infrastructure. 168 - Registration Authority (RA) - An optional entity given 169 responsibility for performing some of the administrative tasks 170 necessary in the registration of subjects, such as: confirming 171 the subject's identity; validating that the subject is entitled 172 to have the values requested in a PKC; and verifying that the 173 subject has possession of the private key associated with the 174 public key requested for a PKC. 176 - Relying party - A user or agent (e.g., a client or server) who 177 relies on the data in a certificate in making decisions. 179 - Root CA - A CA that is directly trusted by an EE; that is, 180 securely acquiring the value of a Root CA public key requires 181 some out-of-band step(s). This term is not meant to imply that a 182 Root CA is necessarily at the top of any hierarchy, simply that 183 the CA in question is trusted directly. 185 - Subordinate CA - A "subordinate CA" is one that is not a Root CA 186 for the EE in question. Often, a subordinate CA will not be a 187 Root CA for any entity but this is not mandatory. 189 - Subject - A subject is the entity (AA, CA, or EE) named in a 190 certificate. Subjects can be human users, computers (as 191 represented by Domain Name Service (DNS) names or Internet 192 Protocol (IP) addresses), or even software agents. 194 - Top CA - A CA that is at the top of a PKI hierarchy. 196 Note: This is often also called a "Root CA," from since in data 197 structures terms and in graph theory, the node at the top of a tree 198 is the "root." However, to minimize confusion in this document, we 199 elect to call this node a "Top CA," and reserve "Root CA" for the 200 CA directly trusted by the EE. Readers new to PKIX should be aware 201 that these terms are not used consistently throughout the PKIX 202 documents, as [FORMAT] uses "Root CA" to refer to what this and 203 other documents call a "Top CA," and "most-trusted CA" to refer to 204 what this and other documents call a "Root CA." 206 3 PKIX Theory 208 3.1 Certificate-using Systems 210 3.1.1 Certificate-using Systems and PKIs 212 At the heart of recent efforts to improve Internet security are a 213 group of security protocols such as Secure Multipurpose Internet Mail 214 Extensions (S/MIME), Transport Layer Sercurity (TLS), and Internet 215 Protocol Security (IPSec). All of these protocols rely on public-key 216 cryptography to provide services such as confidentiality, data 217 integrity, data origin authentication, and non-repudiation. The 218 purpose of a PKI is to provide trusted and efficient key and public 219 key certificate management, thus enabling the use of authentication, 220 non-repudiation, and confidentiality. 222 Users of public key-based systems must be confident that, any time 223 they rely on a public key, the associated private key is owned by the 224 subject with which they are communicating. (This applies whether an 225 encryption or digital signature mechanism is used.) This confidence 226 is obtained through the use of PKCs, which are data structures that 227 bind public key values to subjects. The binding is achieved by having 228 a trusted CA verify the subject's identity and digitally sign each 229 PKC. 231 A PKC has a limited valid lifetime which is indicated in its signed 232 contents. Because a PKC's signature and timeliness can be 233 independently checked by a certificate-using client, PKCs can be 234 distributed via untrusted communications and server systems, and can 235 be cached in unsecured storage in certificate-using systems. 237 PKCs are used in the process of validating signed data. Specifics 238 vary according to which algorithm is used, but the general process 239 works as follows: 241 Note: there is no specific order in which the checks listed below 242 must be made; implementors are free to implement them in the most 243 efficient way for their systems. 245 - The recipient of signed data verifies that the claimed identity 246 of the user is in accordance with the identity contained in the 247 PKC; 249 - The recipient validates that no PKC in the path is revoked (e.g., 250 by retrieving a suitably-current Certificate Revocation List 251 (CRL) or querying an on-line certificate status responder), and 252 that all PKCs are within their validity periods at the time the 253 data was signed; 255 - The recipient verifies that the data are not claimed to have any 256 values for which the PKC indicates that the signer is not 257 authorized; 259 - The recipient verifies that the data have not been altered since 260 signing, by using the public key in the PKC. 262 If all of these checks pass, the recipient can accept that the data 263 was signed by the purported signer. The process for keys used for 264 encryption is similar. 266 Note: It is of course possible that the data was signed by someone 267 very different from the signer, if for example the purported 268 signer's private key was compromised. Security depends on all parts 269 of the certificate-using system, including but not limited to: 270 physical security of the place the computer resides; personnel 271 security (i.e., the trustworthiness of the people who actually 272 develop, install, run, and maintain the system); the security 273 provided by the operating system on which the private key is used; 274 and the security provided the CA. A failure in any one of these 275 areas can cause the entire system security to fail. PKIX is limited 276 in scope, however, and only directly addresses issues related to 277 the operation of the PKI subsystem. For guidance in many of the 278 other areas, see [POLPROC]. 280 3.1.2 Certificate-using Systems and PMIs 282 Many systems use the the PKC to perform identity based access control 283 decisions (i.e, the identity may be used to support identity-based 284 access control decisions after the client proves that it has access 285 to the private key that corresponds to the public key contained in 286 the PKC). For many systems this is sufficient, but increasingly 287 systems are beginning to find that rule-based, role-based, and rank- 288 based access control is required. These forms of access control 289 decisions require additional information that is normally not 290 included in a PKC, because the lifetime of the information is much 291 shorter than the lifetime of the public-private key pair. To support 292 binding this information to a PKC the Attribute Certificate (AC) was 293 defined in ANSI and later incorporated into ITU-T Recommendation 294 X.509. The AC format allows any additional information to be bound to 295 a PKC by including, in a digitally signed data structure, a refernce 296 back to one specific PKC or to multiple PKCs, useful when the subject 297 has the same identity in multiple PKCs. Additionally, the AC can be 298 constructed in such a way that it is only useful at one or more 299 particular targets (e.g., web server, mail host). 301 Users of a PMI must be confident that the identity purporting to 302 posess an attribute has the right to possess that attribute. This 303 confidence may be obtained through the use of PKCs or it may be 304 configured in the AC-using system. If PKCs are used the party making 305 the access control decision can determine "if the AC issuer is 306 trusted to issue ACs containing this attribute." 308 3.2 PKIX History 310 In the beginning there was ITU-T Recommendation X.509. It defines a 311 widely accepted basis for a PKI, including data formats and 312 procedures related to distribution of public keys via PKCs digitally 313 signed by CAs. X.509 does not however include a profile to specify 314 the support requirements for many of the PKC data structure's sub- 315 fields, for any of the extensions, nor for certain data values. PKIX 316 was formed in October 1995 to deliver a profile for the Internet PKI 317 of X.509 version 3 PKCs and version 2 CRLs. The Internet PKI profile 318 [FORMAT] went through eleven draft versions before becoming an RFC. 319 Other profiles have been developed in PKIX for particular algorithms 320 to make use of [FORMAT]. There has been no sense of conflict between 321 the groups that developed these profiles as they are seen as 322 complimentary. 324 The development of the management protocols has not been so 325 straightforward. The Certificate Management Protocol (CMP) was 326 developed to define a message protocol that is used between entities 327 in a PKI [CMP]. The demand for an enrollment protocol and the desire 328 to use PKCS-10 message format as the certificate request syntax lead 329 to the development of two different documents in two different 330 groups. The Certificate Request Syntax (CRS) draft was developed in 331 the SMIME WG which used PKCS-10 [PKCS10] as the certification request 332 message format. Certificate Request Message Format [CRMF] draft was 333 also developed but in the PKIX WG. It was to define a simple 334 enrollment protocol that would subsume both the CMP and CRS 335 enrollment protocols, but it did not use PKCS-10 as the certificate 336 request message format. Then the certificate management message 337 format document, was developed to define an extended set of 338 management messages that flow between the components of the Internet 339 PKI. Certificate Management Messages over CMS (CMC) was developed to 340 allow the use of an existing protocol (S/MIME) as a PKI management 341 protocol, without requiring the development of an entirely new 342 protocol such as CMP [CMC]. It also included [PKCS10] as the 343 certificate request syntax, which caused work on the CRS draft to 344 stop. Information from the certificate management message format 345 document was moved into [CMP] and [CMC] so work on the certificate 346 management message format document was discontinued. 348 Another long debated topic in the WG dealt with certificate 349 revocation. Numerous drafts have been developed to address different 350 issues related certificate revocations. CMP supports revocation 351 request, response, revocation announcement, and requests for CRL 352 messages. CMC defines revocation request, revocation response, and 353 requests for CRL messages messages, but uses CMS as the encapsulating 354 protocol. [OCSP] was devloped to address concerns that not all 355 relying parties want to go through the process checking CRLs from 356 every CA in the certification path. It defines an on-line mechanism 357 to determine the status of a given certificate, which may provide 358 more timely revocation information than is possible with CRLs. The 359 Simple Certification Verification Protocol (SCVP) was produced to 360 allow relying parties to off-load all of their certification 361 verification to another entity [SCVP]. The WG was arguable split over 362 whether such a function should be supported and whether it should be 363 its own protocol or included in OCSP. In response, a draft defining 364 OCSP Extensions [OCSPX] was produced to include the functions of 365 SCVP. One other draft called Open CRL Distribution Point (OCDP) was 366 produced which documented two extensions: one to support an 367 alternative CRL partitioning mechanism to the CRL Distribution Point 368 mechanism documented in [FORMAT] and one to support identifying other 369 revocation sources available to certificate-users. The work from 370 this draft was subsummed by an ITU-T | ISO/IEC Amendment to X.509, 371 hence work on this draft was halted. 373 Development of the operational protocols has been slightly more 374 straightforward. Three documents for the Light Weight Directory 375 Access Protocol (LDAP) have been developed one for defining LDAPv2 as 376 an access protocol to repositories [PKI-LDAPv2]; one for storing PKI 377 information in an LDAP directory [SCHEMA]; and one for LDAPv3 378 requirements for PKI [PKI-LDAPv3]. Using the File Transfer Protocol 379 (FTP) and the Hyper Text Transmission Protocol (HTTP) to retrieve 380 PKCs and CRLs from PKI repositories was documented in [FTPHTTP]. 382 In late 1998 the PKIX charter was revised to include protocols for 383 time stamping and data certification services. [TSP] was developed to 384 define protocols required to interact with a Time Stamp Authority 385 (TSA) who asserts that a datum existed at a given time. Of course, if 386 a true non-repudation service is to be provided additional services 387 that prove the data was actually in the possesion of the subject 388 requesting the time stamp. So, the [DVCS] draft was developed to 389 provide two mechaisms to prove the subject actually possed the data. 390 In addition, [DVCS] provides two additional services: one to verify 391 all signatures attached to the signed document using all appropriate 392 status information and PKCs and one to verify and assert the validity 393 of one or more PKCs at the specified time. Thoughtfully, [DVCS] 394 permits the [TSP] protocol to be used as one of the time stamp 395 tokens. Both [DVCS] and [TSP] use [CMS] as an encapsulating (though 396 in [TSP] request for a time stamp are not required to use [CMS]). 397 [ETNPT] was developed to use [DCVS] to maintain the trust in a token 398 issued by a non-repudiation Trusted Third Party (NR TTP) after the 399 key initially used to establish trust in the token expires. 401 Around the same time, a work item for ACs, defined in [X.509], was 402 added. ACs are similar to PKCs, but they do not bind public keys to 403 identities rather they bind attributes to identities. The attributes 404 bound to the identity can represent anything, but are mostly used to 405 support rule-based, role-based, and rank-based access control 406 decisions. Two drafts have since been developed: the Interent 407 Attribute Certificates Profile for Authorizations [AC] and the 408 Limited AttributeCertificate Acquisition Protocol [LAAP]. The first 409 profiles the fields and extensions of the AC and the second provides 410 a diliberately limited protocol to access a repository when LDAP is 411 not appropriate. 413 Other drafts have been produced to address specific issues. [DHPOP] 414 was developed to define two mechanisms by which a signature can 415 produced using a Diffie-Hellman pair. This draft provides a 416 mechanism to Diffie-Hellam key pairs to issue a PKCS-10 certification 417 request. After some operational experience with [CMP], two drafts, 418 one for using HTTP as the transport protocol [CMP-HTTP] and one for 419 Transmission Control Protocol (TCP) [CMP-TCP], were written to solve 420 problems encountered by implementors. 422 From the alphabet soup above, it is clear why this roadmap is 423 required. 425 3.3 Overview of the PKIX Approach 427 3.3.1 PKI 429 PKIX is an effort to develop specifications for a PKI for the 430 Internet using PKCs. A PKI is defined as: 432 The set of hardware, software, people, policies and procedures needed 433 to create, manage, store, distribute, and revoke PKCs based on 434 public-key cryptography. 436 A PKI consists of five types of components [MISPC]: 438 - Certification Authorities (CAs) that issue and revoke PKCs; 440 - Organizational Registration Authorities (ORAs) that vouch for the 441 binding between public keys and certificate holder identities and 442 other attributes; 444 - Certificate holders that are issued certificates and can sign 445 digital documents and encrypt documents; 447 - Clients that validate digital signatures and their certification 448 paths from a known public key of a trusted CA; 450 - Repositories that store and make available certificates and 451 Certificate Revocation Lists (CRLs). 453 Figure 1 is a simplified view of the architectural model assumed by 454 the PKIX Working Group. 456 +---+ 457 | C | +------------+ 458 | e | <-------------------->| End entity | 459 | r | Operational +------------+ 460 | t | transactions ^ 461 | | and management | Management 462 | / | transactions | transactions 463 | | | PKI users 464 | C | v 465 | R | -------------------+--+-----------+---------------- 466 | L | ^ ^ 467 | | | | PKI management 468 | | v | entities 469 | R | +------+ | 470 | e | <---------------------| RA | <---+ | 471 | p | Publish certificate +------+ | | 472 | o | | | 473 | s | | | 474 | I | v v 475 | t | +------------+ 476 | o | <------------------------------| CA | 477 | r | Publish certificate +------------+ 478 | y | Publish CRL ^ 479 | | | 480 +---+ Management | 481 transactions | 482 v 483 +------+ 484 | CA | 485 +------+ 486 Figure 1 - PKI Entities 488 3.3.2 PMI 490 PKIX is also an effort to develop specifications for a Privilege 491 Management Infrastructure for the Internet using ACs. A Privilege 492 Management Infrastructure, or PMI, is defined as: 494 The set of hardware, software, people, policies and procedures needed 495 to create, manage, store, distribute, and revoke ACs. 497 A PMI consists of five types of components [AC]: 499 - Attribute Authorities (AAs), or Attribute Certificate Issuer, 500 that issue and revoke ACs; 502 Note: AAs may implicitly revoke ACs by using very short validity 503 periods. 505 - Attribute Certificate Users that parses or processes an AC; 507 - Attribute Certificate Verifiers that check the validity of an AC 508 and then makes use of the result; 510 - Clients that request an action for which authorization checks are 511 to be made; 513 - Repositories that store and make available certificates and 514 Certificate Revocation Lists (CRLs). 516 Figure 2 is an example of the exchanges that may involve ACs. 518 +--------------+ 519 | | Server Acquisition 520 | AC Issuer +----------------------------+ 521 | | | 522 +--+-----------+ | 523 | | 524 | Client | 525 | Acquisition | 526 | | 527 +--+-----------+ +--+------------+ 528 | | AC "push" | | 529 | Client +-------------------------+ Server | 530 | | (part of app. protocol) | | 531 +--+-----------+ +--+------------+ 532 | | 533 | Client | Server 534 | Lookup +--------------+ | Lookup 535 | | | | 536 +---------------+ Repository +---------+ 537 | | 538 +--------------+ 540 Figure 2: AC Exchanges 542 3.4 Certificates 544 3.4.1 Public Key Certificates 546 ITU-T X.509 (formerly CCITT X.509) or ISO|IEC/ITU 9594-8, which was 547 first published in 1988 as part of the X.500 Directory 548 recommendations, defines a standard public key certificate format 549 [X.509]. The public key certificate format in the 1988 standard is 550 called the version 1 (v1) format. 552 When X.500 was revised in 1993, two more fields, 553 subjectUniqueIdentier and issuerUniqueIdentifer were added, resulting 554 in the version 2 (v2) format. These two fields may be used to support 555 directory access control. 557 The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993, 558 include specifications for a public key infrastructure based on X.509 559 v1 public key certificates [PEM]. The experience gained in attempts 560 to deploy [PEM] made it clear that the v1 and v2 public key 561 certificate formats are deficient in several respects. Most 562 importantly, more fields were needed to carry information which PEM 563 design and implementation experience has proven necessary. In 564 response to these new requirements, ISO/IEC/ITU and ANSI X9 developed 565 the X.509 version 3 (v3) public key certificate format. The v3 format 566 extends the v2 format by adding provision for additional extension 567 fields. Particular extension field types may be specified in 568 standards or may be defined and registered by any organization or 569 community. In June 1996, standardization of the basic v3 format was 570 completed [X.509]. 572 ISO/IEC/ITU and ANSI X9 have also developed standard extensions for 573 use in the v3 extensions field [X.509][X9.55]. These extensions can 574 convey such data as additional subject identification information, 575 key attribute information, policy information, and certification path 576 constraints. However, the ISO/IEC/ITU and ANSI X9 standard extensions 577 are very broad in their applicability. In order to develop 578 interoperable implementations of X.509 v3 systems for Internet use, 579 it is necessary to specify a profile for use of the X.509 v3 580 extensions tailored for the Internet. It is one goal of PKIX to 581 specify a profile for Internet, electronic mail, and IPsec 582 applications, etc. Environments with additional requirements may 583 build on this profile or may replace it. 585 3.4.2 Attribute Certificates 587 ANSI X.9 first published the Attribute Certificate format in [put 588 date in here] as part of [put reference in here]. It defined the 589 standard version 1 (v1) AC format. They later created a version 2 590 (v2) AC by modifying the owner field to point to either an identity 591 or a specifc PKC and including an extension mechism. In 1997 ITU-T 592 included it in [X.509]. 594 ANSI, ITU-T, and IETF have developed standard extensions and 595 attributes for use in the v2 ACs. Extensions can convey such 596 informatoin as an audit identity that can be used to create an audit 597 trail, identity specific servers/services where the AC owner can use 598 their AC, point to a specific issuer's key, and indicate where to get 599 revocation information. The AC is generic enough to allow any 600 attribute to be conveyed in the data structure. Without limiting the 601 attributes and extensions that can be included in an AC it is very 602 difficult to develop interoperable implementations for Internet use. 603 It is the goal of PKIX to specify a profile for the Internet, 604 electronic mail, IPsec applications, etc. Environments with 605 additional requirements may build on this profile or replace it. 607 3.5 Functions of a PKI 609 This section describes the major functions of a PKI. In some cases, 610 PKIs may provide extra functions. 612 3.5.1 Registration 614 This is the process whereby a subject first makes itself known to a 615 CA (directly, or through an RA), prior to that CA issuing a PKC or 616 PKCs for that subject. Registration involves the subject providing 617 its name (e.g., common name, fully-qualified domain name, IP 618 address), and other attributes to be put in the PKC, followed by the 619 CA (possibly with help from the RA) verifying in accordance with its 620 Certfication Practice Statement (CPS) that the name and other 621 attributes are correct. 623 3.5.2 Initialization 625 Initialization is when the subject (e.g., the user or client system) 626 gets the values needed to begin communicating with the PKI. For 627 example, initialization can involve providing the client system with 628 the public key and/or PKC of a CA, or generating the client system's 629 own public/private key pair. 631 3.5.3 Certification 633 This is the process in which a CA issues a PKC for a subject's public 634 key, and returns that PKC to the subject and/or posts that PKC in a 635 repository. 637 3.5.4 Key Pair Recovery 639 In some implementations, key exchange or encryption keys will be 640 required by local policy to be "backed up," or recoverable in case 641 the key is lost and access to previously-encrypted information is 642 needed. Such implementations can include those where the private key 643 exchange key is stored on a hardware token which can be lost or 644 broken, or when a private key file is protected by a password which 645 can be forgotten. Often, a company is concerned about being able to 646 read mail encrypted by or for a particular employee when that 647 employee is no longer available because she is ill or no longer works 648 for the company. 650 In these cases, the user's private key can be backed up by a CA or by 651 a separate key backup system. If a user or her employer needs to 652 recover these backed up key materials, the PKI must provide a system 653 that permits the recovery without providing an unacceptable risk of 654 compromise of the private key. 656 3.5.5 Key Generation 658 Depending on the CA's policy, the private/public key pair can either 659 be generated by the user in his local environment, or generated by 660 the CA. In the latter case, the key material may be distributed to 661 the user in an encrypted file or on a physical token (e.g., a smart 662 card or PCMCIA card). 664 3.5.6 Key Update 666 All key pairs need to be updated regularly (i.e., replaced with a new 667 key pair) and new PKCs issued. This will happen in two cases: 668 normally, when a key has passed its maximum usable lifetime; and 669 exceptionally, when a key has been compromised and must be replaced. 671 3.5.6.1 Key Expiry 673 In the normal case, a PKI needs to provide a facility to gracefully 674 transition from a PKC with an existing key to a new PKC with a new 675 key. This is particularly true when the key to be updated is that of 676 a CA. Users will know in advance that the key will expire on a 677 certain date; the PKI, working together with PKC-using applications, 678 should allow for appropriate keys to work before and after the 679 transition. There are a number of ways to do this; see [CMP] for an 680 example of one. 682 3.5.6.2 Key Compromise 684 In the case of a key compromise, the transition will not be 685 "graceful" in that there will be an unplanned switch of PKCs and 686 keys; users will not have known in advance what was about to happen. 687 Still, the PKI must support the ability to declare that the previous 688 PKC is now invalid and shall not be used, and to announce the 689 validity and availability of the new PKC. 691 Note: compromise of a private key associated with a Root CA is 692 catastrophic for users relying on that Root CA. If a Root CA's 693 private key is compromised, that CA's PKC must be revoked and all 694 PKCs subordinate to it must also be revoked. Until such time as the 695 Root CA has been issued a new PKC and the Root CA issues PKCs to 696 users relying upon it, users relying on that Root CA are cut off 697 from the rest of the system, as there is no way to develop a valid 698 certification path back to a trusted node. 700 Further, users will likely have to be notified by out-of-band 701 mechanisms about the change in CA keys. If the old key is 702 compromised, any "update" message telling subordinates to switch to a 703 new key could have come from an attacker in possession of the old 704 key, and could point to a new public key for which the attacker 705 already has the private key. It is possible to have anticipated this 706 event, and "pre-placed" replacement Root CA keys with all relying 707 parties, but some secure, out-of-band mechanism will have to be used 708 to tell users to make the switch, and this will only help if the 709 replacement key has not been compromised. 711 Additionally, once the Root CA is brought back up with a new key, it 712 will likely be necessary to re-issue PKCs, signed with the new key, 713 to all subordinate users, since their current PKC would be signed 714 with a now-revoked key. 716 3.5.7 Cross-certification 718 A cross-certificate is a PKC issued by one CA to another CA which 719 contains a public CA key associated with the private CA signature key 720 used for issuing PKCs. Typically, a cross-certificate is used to 721 allow client systems/end entities in one administrative domain to 722 communicate securely with client systems/end users in another 723 administrative domain. Use of a cross-certificate issued from CA_1 to 724 CA_2 allows user Alice, who trusts CA_1, to accept a PKC used by Bob, 725 which was issued by CA_2. Cross-certificates can also be issued from 726 one CA to another CA in the same administrative domain, if required. 728 Cross-certificates can be issued in only one direction, or in both 729 directions, between two CA's. That is, just because CA_1 issues a 730 cross-certificate for CA_2, CA_2 does not have to issue a cross- 731 certificate for CA_1. 733 3.5.8 Revocation 735 When a PKC is issued, it is expected to be in use for its entire 736 validity period. However, various circumstances may cause a PKC to 737 become invalid prior to the expiration of the validity period. Such 738 circumstances include change of name, change of association between 739 subject and CA (e.g., an employee terminates employment with an 740 organization), and compromise or suspected compromise of the 741 corresponding private key. Under such circumstances, the CA needs to 742 revoke the PKC. 744 X.509 defines one method of PKC revocation. This method involves each 745 CA periodically issuing a signed data structure called a certificate 746 revocation list (CRL). A CRL is a time stamped list identifying 747 revoked PKCs which is signed by a CA and made freely available in a 748 public repository. Each revoked PKC is identified in a CRL by its PKC 749 serial number. When a certificate-using system uses a PKC, that 750 system not only checks the PKC signature and validity but also 751 acquires a suitably-recent CRL and checks that the PKC serial number 752 is not on that CRL. The meaning of "suitably-recent" may vary with 753 local policy, but it usually means the most recently-issued CRL. A CA 754 issues a new CRL on a regular periodic basis (e.g., hourly, daily, or 755 weekly). CA's may also issue CRLs aperiodically. For example, if an 756 important key is deemed compromised, the CA may issue a new CRL to 757 expedite notification of that fact, even if the next CRL does not 758 have to be issued for some time. (A problem of aperiodic CRL issuance 759 is that end-entities may not know that a new CRL has been issued, and 760 thus may not retrieve it from a repository.) 762 An entry is added to the CRL as part of the next update following 763 notification of revocation. An entry may be removed from the CRL 764 after appearing on one regularly scheduled CRL issued beyond the 765 revoked PKC's validity period. Leaving the revoked PKC on the CRL for 766 this extra period allows for PKCs that are revoked prior to issuing a 767 new CRL and whose invalidity date falls before the CRL issuing time 768 to be accounted for. If the revoked PKC is not retained on the CRL 769 for this extra period then the possiblity arises that a revoked PKC 770 may never appear on a CRL. 772 An advantage of the CRL revocation method is that CRLs may be 773 distributed by exactly the same means as PKCs themselves, namely, via 774 untrusted communications and server systems. 776 One limitation of the CRL revocation method, using untrusted 777 communications and servers, is that the time granularity of 778 revocation is limited to the CRL issue period. For example, if a 779 revocation is reported now, that revocation will not be reliably 780 notified to certificate-using systems until the next CRL is issued - 781 this may be up to one hour, one day, or one week depending on the 782 frequency that the CA issues CRLs. 784 As with the X.509 v3 PKC format, in order to facilitate interoperable 785 implementations from multiple vendors, the X.509 v2 CRL format needed 786 to be profiled for Internet use. This was done as part of [FORMAT]. 787 However, PKIX does not require CAs to issue CRLs. On-line methods of 788 revocation notification may be applicable in some environments as an 789 alternative to the X.509 CRL. PKIX defines a protocol known as OCSP 790 to facilitate on-line checking of the status of PKCs [OCSP]. 792 On-line revocation checking may significantly reduce the latency 793 between a revocation report and the distribution of the information 794 to relying parties. Once the CA accepts the report as authentic and 795 valid, any query to the on-line service will correctly reflect the 796 PKC validation impacts of the revocation. However, these methods 797 impose new security requirements; the PKC validator must trust the 798 on-line validation service while the repository does not need to be 799 trusted. 801 3.5.9 Certificate and Revocation Notice Distribution/Publication 803 As alluded to in sections 3.1 and 3.5.8 above, the PKI is responsible 804 for the distribution of PKCs and PKC revocation notices (whether in 805 CRL form or in some other form) in the system. "Distribution" of PKCs 806 includes transmission of the PKC to its owner, and may also include 807 publication of the PKC in a repository. "Distribution" of revocation 808 notices may involve posting CRLs in a repository, transmitting them 809 to end-entities, and/or forwarding them to on-line responders. 811 3.6 Parts of PKIX 813 This section identifies the six different areas in which the PKIX 814 working group has developed documents. The first area involves 815 profiles of the X.509 v3 PKC standards and the X.509 v2 CRL standards 816 for the Internet. The second area involves operational protocols, in 817 which relying parties can obtain information such as PKCs or PKC 818 status. The third area covers management protocols, in which 819 different entities in the system exchange information needed for 820 proper management of the PKI. The fourth area provides information 821 about certificate policies and certificate practice statements, 822 covering the areas of PKI security not directly addressed in the rest 823 of PKIX. The fifth area deals with providing time stamping and data 824 certification services, which can be used to build such services as 825 non-repudiation. 827 3.6.1 Profiles 829 An X.509 v3 PKC is a very complex data structure. It consists of 830 basic information fields, plus a number of optional extensions. Many 831 of the fields and numerous extensions can take on a wide range of 832 options. This provides an enormous degree of flexibility, which 833 allows the X.509 v3 PKC format to be used with a wide range of 834 applications in a wide range of environments. Unfortunately, this 835 same flexibility makes it extremely difficult to produce independent 836 implementations that will actually interoperate with one another. In 837 order to build an Internet PKI based on X.509 v3 PKCs, the PKIX 838 working group had to develop a profile of the X.509 v3 PKC 839 specification. 841 A profile of the X.509 v3 PKC specification is a description of the 842 contents of the PKC and which extensions must be supported, which 843 extensions may be supported, and which extensions may not be 844 supported. [FORMAT] provides such a profile of X.509 v3 PKC for the 845 Internet PKI. In addition, [FORMAT] suggests ranges of values for 846 many of the extensions. 848 [FORMAT] also provides a profile for Version 2 CRLs for use in the 849 Internet PKI. CRLs, like PKCs, have a number of optional extensions. 850 In order to promote interoperability, it is necessary to constrain 851 the choices an implementor supports. 853 In addition to profiling the PKC and CRL formats, it is necessary to 854 define particular Object Identifiers (OIDs) for certain encryption 855 algorithms, because there are a variety of OIDs registered for some 856 algorithm suites. Many of the OIDs are defined in [FORMAT] to promote 857 interoperability. Also, PKIX has produced two documents ([ECDSA] and 858 [KEA]) which provide guidance on the proper implementation of 859 specific algorithms. 861 Some countries are in a process of updating their legal frameworks in 862 order to regulate and incorporate recognition of signatures in 863 electronic form. Many of these frameworks introduce certain basic 864 requirements on PKCs, often termed Qualified Certificates, supporting 865 these types of "legal" signatures. Partly as a result of this there 866 is a need for a specific PKC profile providing standardized support 867 for certain related issues such as a common structure for expressing 868 unambiguous identities of certified subjects (unmistakable identity). 869 In December 1998, PKIX adopted as a work item the development of a 870 refinement of [RFC2459] that further profiles PKIX PKC into qualified 871 certificates. This work is reflected in [QC]. 873 Like the X.509 v3 PKC the AC also a very complex data structure 874 consisting of basic information fields, a number of optional 875 extensions, and a virtually unlimited number of attributes. Again, 876 many of the fields, extensions, and attributes can take on a wide 877 range of options allowing an enomerous degree of flexibility. In 878 order to build an Internet PMI based on ACs, the PKIC working group 879 had to develop a profile of the AC. 881 The AC profile is description of the contents of the AC, the allowed 882 and required extensions, and applicable attributes. [AC] provides 883 such a profile of the X.509 v2 AC. 885 3.6.2 Operational Protocols 887 Operational protocols are required to deliver certificates and CRLs 888 (or other certificate status information) to certificate using 889 systems. Provision is needed for a variety of different means of 890 certificate and CRL delivery, including distribution procedures based 891 on LDAP, HTTP, FTP, and X.500. Operational protocols supporting these 892 functions are defined in [FTPHTTP], [OCSP], [PKI-LDAPv2], and [PKI- 893 LDAPv3]. A limited protocol to support AC retrieval has also been 894 document in [LAAP]. 896 [DHPOP] defines a procedure for producing signatures withg the 897 Diffie-Hellman key agreement algorithm. This signature mechanism was 898 developed to support PKCS-10 certificate requests. 900 3.6.3 Management Protocols 902 Management protocols are required to support on-line interactions 903 between PKI user and management entities. For example, a management 904 protocol might be used between a CA and a client system with which a 905 key pair is associated, or between two CAs which cross-certify each 906 other. A management protocol can be used to carry user or client 907 system registration information, or a request for revocation of a 908 certificate. 910 There are two parts to a "management protocol." The first is the 911 format of the messages that will be sent, and the second is the 912 actual protocol that governs the transmission of those messages. 913 Originally, the PKIX working group developed two documents, [CRMF] 914 and certificate management message format (CMMF), that together 915 described the necessary set of message formats, and two other 916 documents, [CMP] and [CMC], that described protocols for exchanging 917 those messages. However, the message formats defined in in the CMMF 918 draft were inserted into both [CMP] and [CMC], and thus the (CMMF) 919 draft has been dropped as a PKIX document. 921 [CMP-HTTP] and [CMP-TCP] were developed, after some implmentation 922 experience, to update the procedure documented in [CMP] for using CMP 923 with HTTP and TCP and the transport protocols [CMP]. 925 3.6.4 Policy Outline 927 As mentioned before, profiling certificates and specifying 928 operational and management protocols only addresses a part of the 929 problem of actually developing and implementing a secure PKI. What is 930 also needed is the development of a certificate policy (CP) and 931 certification practice statement (CPS), and then following those 932 documents. The CP and CPS should address physical and personnel 933 security, subject identification requirements, revocation policy, and 934 a number of other topics. [POLPROC] provides a framework for 935 certification practice statements. 937 3.6.5 Time-Stamp and Data Certification Services 939 In late 1998, the PKIX working group began two efforts that were not 940 in the original working group charter, but were deemed to be 941 appropriate because they described infrastructure services that could 942 be used to provide desired security services. The first of these is 943 time stamping, described in [TSP]. Time stamping is a service in 944 which a trusted third party - a Time Stamp Authority, or TSA - signs 945 a message, in order to provide evidence that it existed prior to a 946 given time. Time stamping provides some support for non-repudiation, 947 in that a user cannot claim that a transaction was later forged after 948 compromise of a private key, because the existence of the signed time 949 stamp indicates that the transaction in question could not have been 950 created after the indicated time. 952 [TSP] also defines the role of a Temporal Data Authority, or TDA. A 953 TDA is a Trusted Third Party (TTP) that creates a temporal data 954 token. This temporal data token associates a message with a 955 particular event and provides supplementary evidence for the time 956 included in the time stamp token. For example, a TDA could associate 957 the message with the most recent closing value of the Dow Jones 958 Average. The temporal data with which the message is associated 959 should be unpredictable in order to prevent forward dating of tokens. 960 The third iteration of the draft removed support for TDAs as no one 961 in the WG expressed a requirement for the role. 963 At the Minneapolis IETF meeting, it was disclosed that the materials 964 covered in [TSP] draft may be covered by patent(s). Use of the 965 material covered by the patent(s) in question has not be granted by 966 the patentholder. Thus, anyone interested in implementing the PKIX 967 [TSP] draft must be aware of this intellectual property issue. 969 The second new effort is the definition of a Data Validation and 970 Certification Server, or DVCS, protocol [DVCS]. A DVCS is a Trusted 971 Third Party that verifies the correctness of specific data submitted 972 to it. 974 This is different from the TSP service in that a TSA will not attempt 975 to parse and/or verify a message sent to it for certification; 976 instead, it will merely append a reliable indication of the current 977 time, and sign the resulting string-of-bits. This offers an 978 indication that the given string-of-bits existed at a specified time; 979 it does not offer any indication of the correctness or relevance of 980 that string of bits. By contrast, the DVCS certifies possession of 981 data or the validity of another entity's signature. As part of this, 982 the DVCS verifies the mathematical correctness of the actual 983 signature value contained in the request and also checks the full 984 certification path from the signing entity to a trusted point (e.g., 985 the DVCS's CA, or the Root CA in a hierarchy). 987 The DVCS supports non-repudiation in two ways. First, it provides 988 evidence that a signature or PKC was valid at the time indicated in 989 the token. The token can be used even after the corresponding PKC 990 expires and its revocation information is no longer available on CRLs 991 (for example). Second, the production of a data certification token 992 in response to a signed request for certification of another 993 signature or PKC also provides evidence that due diligence was 994 performed by the requester in validating the signature or PKC. 996 4 PKIX Documents 998 This section describes each of the documents written by the PKIX 999 working group. As PKIX progresses, this section will need to be 1000 continually updated to reflect the status of each document (e.g., 1001 Proposed Standard, Draft Standard, Standard, Informational Draft, 1002 Informational RFC, something-that-was-just-thrown-out-for- 1003 consideration, etc.). 1005 4.1 Profile 1007 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate 1008 and CRL Profile (RFC 2459) 1010 DESCRIPTION: This document describes the profiles to be used for 1011 X.509 v3 PKCs and version 2 CRLs by Internet PKI participants. The 1012 profiles include the identification of ISO/IEC/ITU and ANSI 1013 extensions which may be useful in the Internet PKI. The profiles are 1014 presented in the 1988 Abstract Syntax Notation One (ASN.1) rather 1015 than the 1994 syntax used in the ISO/IEC/ITU standards. Would-be PKIX 1016 implementors and developers of certificate-using applications should 1017 start with [FORMAT] to ensure that their systems will be able to 1018 interoperate with other users of the PKI. 1020 [FORMAT] also includes path validation procedures. The procedures 1021 presented are based upon the ISO/IEC/ITU definition, but the 1022 presentation assumes one or more self-signed trusted CA PKCs. The 1023 procedures are provided as examples only. Implementations are not 1024 required to use the procedures provided; they may implement whichever 1025 procedures are efficient for their situation. However, 1026 implementations are required to derive the same results as the 1027 example procedures. 1029 STATUS: Proposed Standard. 1031 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure 1032 Representation of Elliptic Curve Digital Signature Algorithm (ECDSA) 1033 Keys and Signatures in Internet X.509 Public Key Infrastructure 1034 Certificates 1036 DESCRIPTION: This document provides Object Identifiers (OIDs) and 1037 other guidance for IPKI users who use the Elliptic Curve Digital 1038 Signature Algorithm (ECDSA). It profiles the format and semantics of 1039 the subjectPublicKeyInfo field and the keyUsage extension in X.509 v3 1040 PKCs containing ECDSA keys. This document should be used by anyone 1041 wishing to support ECDSA; others who do not support ECDSA are not 1042 required to comply with it. 1044 STATUS: WG Last Call. 1046 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure 1047 Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 1048 Public Key Infrastructure Certificates (RFC 2528) 1050 DESCRIPTION: This document provides Object Identifiers (OIDs) and 1051 other guidance for IPKI users who use the Key Exchange Algorithm 1052 (KEA). It profiles the format and semantics of the 1053 subjectPublicKeyInfo field and the keyUsage extension in X.509 v3 1054 PKCs containing KEA keys. This document should be used by anyone 1055 wishing to support KEA; others who do not support ECDSA are not 1056 required to comply with it. 1058 STATUS: Informational RFC. 1060 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Qualified 1061 Certificates 1063 DESCRIPTION: This document profiles the format for and defines 1064 requirements on information content in a specific type of PKCs called 1065 Qualified Certificates. A "Qualified Certificate" is a PKC that is 1066 issued to a natural person (i.e., a living human being); contains an 1067 unmistakable identity based on a real name or a pseudonym of the 1068 subject; exclusively indicates non-repudiation as the key usage for 1069 the certificate's public key; and meets a number of requirements. 1071 STATUS: Under WG review. 1073 DOCUMENT TITLE: An Internet AttributeCertificate Profile for 1074 Authorizations 1076 DESCRIPTION: This document profiles the format for an defines 1077 requirements on X.509 v2 ACs to support authorization services 1078 required by various Internet protocols (TLS, CMS, and the consumers 1079 of CMS, etc.). Two profiles are defined on that supports basic 1080 authorizations and on the supports proxiable services. 1082 STATUS: Under WG review. 1084 4.2 Operational Protocols 1086 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Operational 1087 Protocols - LDAPv2 (RFC 2559) 1089 DESCRIPTION: This document describes the use of LDAPv2 as a protocol 1090 for PKI elements to publish and retrieve certificates and CRLs from a 1091 repository. [LDAPv2] is a protocol that allows publishing and 1092 retrieving of information. 1094 STATUS: Proposed Standard. 1096 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure LDAPv2 1097 Schema (RFC 2587) 1099 DESCRIPTION: This document defines a minimal schema necessary to 1100 support the use of LDAPv2 for PKC and CRL retrieval and related 1101 functions for PKIX. This document supplements [LDAPv2] by identifying 1102 the PKIX-related attributes that must be present. 1104 STATUS: Proposed Standard. 1106 DOCUMENT TITLE: X.509 Internet Public Key Infrastructure Online 1107 Certificate Status Protocol - OCSP (RFC 2560) 1109 DESCRIPTION: This document specifies a protocol useful in determining 1110 the current status of a certificate without the use of CRLs. A major 1111 complaint about certificate-based systems is the need for a relying 1112 party to retrieve a current CRL as part of the certificate validation 1113 process. Depending on the size of the CRL, this can cause severe 1114 problems for bandwidth-challenged devices. Depending on the frequency 1115 of CRL issuance, this can also cause timeliness problems. (E.g., if 1116 CRLs are only published weekly, with no interim releases, a 1117 certificate could actually have been revoked for just short of one 1118 week without it being on the current CRL, and thus improper use of 1119 that certificate could still be occurring.) 1121 OCSP attempts to address those problems. It provides a mechanism 1122 whereby a relying party identifies one or more certificates to an 1123 approved OCSP "responder", and the responder sends back the current 1124 status of the certificate(s) - e.g., "revoked", "notRevoked", 1125 "unknown". This can dramatically reduce the bandwidth required to 1126 transmit revocation status - a relying party does not have to 1127 retrieve a CRL of many entries to check the status of one 1128 certificate. It can (although it is not guaranteed to) improve the 1129 timeliness of revocation notification, and thus reduce the window of 1130 opportunity for someone trying to use a revoked certificate. 1132 STATUS: Proposed Standard. 1134 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Operational 1135 Protocols: FTP and HTTP (RFC 2585) 1137 DESCRIPTION: This document describes the use of the File Transfer 1138 Protocol (FTP) and the Hyper-text Transfer Protocol (HTTP) to obtain 1139 certificates and CRLs from PKI repositories. 1141 STATUS: Proposed Standard. 1143 DOCUMENT TITLE: Diffie-Hellman Proof-of-Possesion Algorithms 1146 DESCRIPTION: This documents describes two signing algorithms using 1147 the Diffie-Hellman key agreement process to provide a shared secret 1148 as the basis of the signature. It allows Diffie-Hellman a key 1149 agreement algorithm to be used instead of requiring that the public 1150 key being requested for certification correspond to an algorithm that 1151 is capable of signing and/or encrypting. The first algorithm 1152 generates a signature for a specific verifier where the signer and 1153 recipient have the same public key parameters. The second algorithm 1154 generates a signature for arbitrary verifiers where the signer and 1155 recipient do not have the same public key parameters. 1157 STATUS: Under WG review. 1159 DOCUMENT TITLE: Limited Attribute Certificate Aquisition Protocol 1160 1162 DESCRIPTION: This document specifies a deliberately limited protocol 1163 for requesting ACs from a server. It is intended to be complementary 1164 to the use of LDAP for AC retrieval, covering those cases where use 1165 of an LDAP server is not suitable due to the type of authorization 1166 model being employed. 1168 STATUS: Under WG review. 1170 4.3 Management Protocols 1172 DOCUMENT TITLE: Certificate Management Messages over CMS 1175 DESCRIPTION: This document defines the means by which PKI clients and 1176 servers may exchange PKI messages when using S/MIME's Cryptographic 1177 Message Syntax [CMS] as a transaction envelope. CMC supports the 1178 certificate request message body specified in the Certificate Request 1179 Message Format [CRMF] documents, as well as a variety of other 1180 certificate management messages. The primary purpose of this 1181 specification is to allow the use of an existing protocol (S/MIME) as 1182 a PKI management protocol, without requiring the development of an 1183 entirely new protocol such as CMP. A secondary purpose is to codify 1184 in IETF standards the current industry practice of using PKCS-10 1185 messages [PKCS10] for certificate requests. 1187 STATUS: Under WG review. 1189 DOCUMENT TITLE: Internet X.509 Certificate Request Message Format 1190 (RFC 2511) 1192 DESCRIPTION: CRMF specifies a format recommended for use whenever a 1193 relying party is requesting a certificate from a CA or requesting 1194 that an RA help it get a certificate. The request message format was 1195 needed before many of the other message formats had to be finalized, 1196 and so it was put into a separate document. This document only 1197 specifies the format of a message. Specification of a protocol to 1198 transport that message is beyond the scope of CRMF. 1200 STATUS: Proposed Standard. 1202 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate 1203 Management Protocols (RFC 2510) 1205 DESCRIPTION: This document specifies a new protocol specifically 1206 developed for the purpose of transporting messages like those 1207 specified in CRMF among PKI elements. In general, CMP will be used in 1208 conjunction with CRMF, and will then be run over a transfer service 1209 (e.g., S/MIME, HTTP) to provide a complete PKI management service. 1211 STATUS: Proposed Standard. 1213 DOCUMENT TITLE: Simple Certificate Validation Protocol (SCVP) 1216 DESCRIPTION: The SCVP protocol allows a client to offload certificate 1217 handling to a server. The server can give a variety of valuable 1218 information about the certificate, such as whether or not the 1219 certificate is valid, a chain to a trusted root, and so on. 1221 STATUS: Under WG review. 1223 DOCUMENT TITLE: Using HTTP as a Transport Protocol for CMP 1226 DESCRIPTION: This document describes how to layer [CMP] over [HTTP]. 1227 A simple method for doing so is described in [CMP], but that method 1228 does not accommodate a polling mechanism, which may be required in 1229 some environments. This document specifies an alternative method 1230 which uses the polling protocol defined in [CMP]. A new Content-Type 1231 for messages is also defined. 1233 STATUS: Under WG review. 1235 DOCUMENT TITLE: Using TCP as a Transport Protocol for CMP 1238 DESCRIPTION: This document describes how to layer Certificate 1239 Management Protocols [CMP] over [TCP]. A method for doing so is 1240 described in [CMP], but that method does not solve problems 1241 encountered by implementors. This document specifies an enhanced 1242 method which extends the protocol. 1244 STATUS: Under WG review. 1246 DOCUMENT TITLE: OCSP Extensions 1248 DESCRIPTION: This document defines Internet-standard extensions to 1249 OCSP that enable a client to delegate processing of certificate 1250 acceptance functions to a trusted server. The client may control the 1251 degree to which delegation takes place. In addition limited support 1252 is provided for delegating authorization decisions. 1254 STATUS: Under WG review. 1256 4.4 Policy Outline 1258 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate 1259 Policy and Certification Practices Framework (RFC 2527) 1261 DESCRIPTION: As noted before, the specification and implementation of 1262 certificate profiles, operational protocols, and management protocols 1263 is only part of building a PKI. Equally as important - if not more 1264 important - is the development and enforcement of a certificate 1265 security policy, and a Certification Practice Statement (CPS). The 1266 purpose of this document (PKIX-4) is to establish a clear 1267 relationship between certificate policies and CPSs, and to present a 1268 framework to assist the writers of certificate policies or CPSs with 1269 their tasks. In particular, the framework identifies the elements 1270 that may need to be considered in formulating a certificate policy or 1271 a CPS. The purpose is not to define particular certificate policies 1272 or CPSs, per se. 1274 STATUS: Informational RFC. 1276 4.5 Time-Stamp and Data Certification Services 1278 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Time Stamp 1279 Protocols 1281 DESCRIPTION: This document defines the specification for a time stamp 1282 service. It defines a Time Stamp Authority, or TSA, a trusted third 1283 party who maintains a reliable time service. When the TSA receives a 1284 time stamp request, it appends the current time to the request and 1285 signs it into a token to certify that the original request existed 1286 prior to the indicated time. This helps provide non-repudiation by 1287 preventing someone (either a legitimate user or an attacker who has 1288 successfully compromised a key) from "back-dating" a transaction. It 1289 also makes it more difficult to challenge a transaction by asserting 1290 that it has been back-dated. Note that the TSA does not provide any 1291 data parsing service; that is, the TSA does not attempt to validate 1292 that which it signs; it merely regards it as a string of bits whose 1293 meaning is unimportant, but existence is vital. 1295 STATUS: Under WG review. 1297 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Data 1298 Certification Server Protocols 1300 DESCRIPTION: This document defines a data validation and 1301 certification service, or DVCS, which can be used to certify both the 1302 existence and correctness of a message or signature. In contrast to 1303 the time stamp service described above, the DVCS certifies possession 1304 of data or the validity of another entity's signature. As part of 1305 this, the DVCS verifies the mathematical correctness of the actual 1306 signature value contained in the request and also checks the full 1307 certification path from the signing entity to a trusted point (e.g., 1308 the DVCS's CA, or the Root CA in a hierarchy). 1310 The DVCS supports non-repudiation in two ways. First, it provides 1311 evidence that a signature or public key certificate was valid at the 1312 time indicated in the token. The token can be used even after the 1313 corresponding public key certificate expires and its revocation 1314 information is no longer available on CRLs (for example). Second, the 1315 production of a data certification token in response to a signed 1316 request for certification of another signature or public key 1317 certificate also provides evidence that due diligence was performed 1318 by the requester in validating the signature or public key 1319 certificate. 1321 STATUS: Under WG review. 1323 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Extending 1324 trust in non repudiation tokens in time 1327 DESCRIPTION: This document describes a method to maintain the trust 1328 in a token issued by a non-repudiation Trusted Third Party (NR TTP) 1329 (DVCS/TSA/TDA) after the key initially used to establish trust in the 1330 token expires. The document describes a general format for storage of 1331 DVCS/TS/TDA tokens for this purpose, which establishes a chain of 1332 custody for the data. 1334 STATUS: Under WG review. 1336 4.6 Documents that never made it out of the working group 1338 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate 1339 Management Message Formats 1341 DESCRIPTION: This document contains the formats for a series of 1342 messages important in certificate/PKI management. These messages let 1343 CA's, RA's, and relying parties communicate with each other. Note 1344 that this document only specifies message formats; it does not 1345 specify a protocol for transferring messages. That protocol can be 1346 either CMP or CMC, or perhaps another custom protocol. 1348 STATUS: Work has been discontinued, as all useful information from it 1349 has been moved into [CMP] and [CMC]. 1351 DOCUMENT TITLE: WEB based Certificate Access Protocol-- WebCAP/1.0 1353 DESCRIPTION: This document specifies a set of methods, headers, and 1354 content-types ancillary to HTTP/1.1 to publish, retrieve X.509 1355 certificates and Certificate Revocation Lists. This protocol also 1356 facilitates determining current status of a digital certificate 1357 without the use of CRLs. This protocol defines new methods, request 1358 and response bodies, error codes to HTTP/1.1 protocol for securely 1359 publishing, retrieving, and validating certificates across a 1360 firewall. 1362 STATUS: Work has been discontinued due to lack of interest. 1364 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Enhanced CRL 1365 Distribution Options (OpenCDP) 1367 DESCRIPTION: This document proposes an alternative to the CRL 1368 Distribution Point (CDP) approach documented in [FORMAT]. OCDP 1369 separates the CRL location function from the process of certificate 1370 and CRL validation, and thus claims some benefits over the CDP 1371 approach. 1373 STATUS: Work has been discontinued, as all useful information has 1374 been incorporated into [X.509]. An updated [FORMAT] RFC should 1375 profile the use of the CDP approach. 1377 DOCUMENT TITLE: Internet Public Key Infrastructure: Caching the 1378 Online Certificate Status Protocol 1380 DESCRIPTION: To improve the degree to which it can scale, OCSP allows 1381 caching of responses - e.g., at intermediary servers, or even at the 1382 relying party's end system. This document describes how to support 1383 OCSP caching at intermediary servers. 1385 STATUS: Work has been discontinued due to lack of interest. 1387 DOCUMENT TITLE: Basic Event Representation Token 1390 DESCRIPTION: This document defines a finite method of representing a 1391 discrete instant in time as a referable event. The Basic Event 1392 Representation Token (BERT) is a light-weight binary token designed 1393 for use in large numbers over short periods of time. The tokens 1394 contain only a single instance of an event stamp and the trust 1395 process is referenced against an external reference. 1397 STATUS: Work has been discontinued. 1399 5 Advice to Implementors 1401 This section provides guidance to those who would implement various 1402 parts of the PKIX suite of documents. The topics discussed in this 1403 section engendered significant discussion in the working group, and 1404 there was at times either widespread disagreement or widespread 1405 misunderstanding of them. Thus, this discussion is provided to help 1406 readers of the PKIX document set understand these issues, in the hope 1407 of fostering greater interoperability among eventual PKIX 1408 implementations. 1410 5.1 Names 1412 PKIX has been referred to as a "name-centric" PKI because the PKCs 1413 associate public keys with names of entities. Each PKC contains at 1414 least one name for the owner of a particular public key. The name can 1415 be an X.500 distinguished name, contained in the subjectDN field of 1416 the PKC. There can also be names such as RFC822 e-mail addresses, DNS 1417 domain names, and uniform resource identifiers (URIs) associated with 1418 the key; these attributes are kept in the subjectAltName extension of 1419 the PKC. A PKC must contain at least one of these name forms, it may 1420 contain multiple forms if deemed appropriate by the CA based on the 1421 intended usage of the PKC. 1423 5.1.1 Name Forms 1425 There are two possible places to put a name in an X.509 v3 PKC. One 1426 is the subject field in the base PKC (often called the "Distinguished 1427 Name" or "DN" field), and the other is in the subjectAltName 1428 extension. 1430 5.1.1.1 Distinguished Names 1432 According to [FORMAT], a PKIX PKC must have a non-null value in the 1433 subject field, except for an EE PKC, which is permitted to have an 1434 empty subject field. Furthermore, if a PKC has a non-null subject 1435 field, it MUST contain an X.500 Distinguished Name. 1437 5.1.1.2 SubjectAltName Forms 1439 In addition to the DN, a PKIX PKC may have one or more values in the 1440 subjectAltName extension. 1442 The subjectAltName extension allows additional identities to be bound 1443 to the subject of the PKC (e.g., it allows "umbc.edu" and 1444 "130.85.1.3" to be associated with a particular subject, as well as 1445 "C=US, O=University of Maryland, L=Baltimore, CN=UMBC"). 1446 X.509-defined options for this extension include: Internet electronic 1447 mail addresses; DNS names; IP addresses; and URIs. Other options can 1448 exist, including locally-defined name forms. 1450 A single subjectAltName extension can include multiple name forms, 1451 and multiple instances of each name form. 1453 Whenever such alternate name forms are to be bound into a PKC, the 1454 subjectAltName (or issuerAltName) extension must be used. It is 1455 technically possible to embed an alternate name form in the subject 1456 field. For example, one could make a DN contain an IP address via a 1457 kludge such as "C=US, L=Baltimore, CN=130.85.1.3". However, this 1458 usage is deprecated; the alternative name extension is the preferred 1459 location for finding such information. As another example, some 1460 legacy implementations exist where an RFC822 name is embedded in the 1461 subject distinguished name as an EmailAddress attribute. Per 1462 [FORMAT], PKIX-compliant implementations generating new PKCs with 1463 electronic mail addresses MUST use the rfc822Name in the 1464 subjectAltName extension to describe such EEs. Simultaneous inclusion 1465 of the EmailAddress attribute in the subject distinguished name to 1466 support legacy implementation is deprecated but permitted. 1468 In line with this, if the only subject identity included in a PKC is 1469 an alternative name form, then the subject distinguished name must be 1470 empty (technically, an empty sequence), and the subjectAltName 1471 extension must be present. If the subject field contains an empty 1472 sequence, the subjectAltName extension must be marked critical. 1474 If the subjectAltName extension is present, the sequence must contain 1475 at least one entry. Unlike the subject field, conforming CAs shall 1476 not issue PKCs with subjectAltNames containing empty GeneralName 1477 fields. For example, an rfc822Name is represented as an IA5String. 1478 While an empty string is a valid IA5String, such an rfc822Name is not 1479 permitted by PKIX. The behavior of clients that encounter such a PKC 1480 when processing a certification path is not defined by this working 1481 group. 1483 Because the subject's alternative name is considered to be 1484 definitively bound to the public key, all parts of the subject's 1485 alternative name must be verified by the CA. 1487 5.1.1.2.1 Internet e-mail addresses 1489 When the subjectAltName extension contains an Internet mail address, 1490 the adress is included as an rfc822Name. The format of an rfc822Name 1491 is an "addr-spec" as defined in [RFC-822]. An addr-spec has the form 1492 local-part@domain; it does not have a phrase (such as a common name) 1493 before it, or a comment (text surrounded in parentheses) after it, 1494 and it is not surrounded by "<" and ">". 1496 5.1.1.2.2 DNS Names 1498 When the subjectAltName extension contains a domain name service 1499 label, the domain name is stored in the dNSName attribute(an 1500 IA5String). The string shall be in the "preferred name syntax," as 1501 specified by [DNS]. Note that while upper and lower case letters are 1502 allowed in domain names, no signifigance is attached to the case. In 1503 addition, while the string " " is a legal domain name, subjectAltName 1504 extensions with a dNSName " " are not permitted. Finally, the use of 1505 the DNS representation for Internet mail addresses (wpolk.nist.gov 1506 instead of wpolk@nist.gov) is not permitted; such identities are to 1507 be encoded as rfc822Name. 1509 5.1.1.2.3 IP addresses 1511 When the subjectAltName extension contains an iPAddress, the address 1512 shall be stored in the octet string in "network byte order," as 1513 specified in [IP]. The least significant bit (LSB) of each octet is 1514 the LSB of the corresponding byte in the network address. For IP 1515 Version 4, as specified in [IP], the octet string must contain 1516 exactly four octets. For IP Version 6, as specified in [IPv6], the 1517 octet string must contain exactly sixteen octets. 1519 5.1.1.2.4 URIs 1521 [FORMAT] notes "When the subjectAltName extension contains a URI, the 1522 name MUST be stored in the uniformResourceIdentifier (an IA5String). 1523 The name MUST be a non-relative URL, and MUST follow the URL syntax 1524 and encoding rules specified in [RFC 1738]. The name must include 1525 both a scheme (e.g., "http" or "ftp") and a scheme-specific-part. The 1526 scheme-specific-part must include a fully qualified domain name or IP 1527 address as the host. As specified in [RFC 1738], the scheme name is 1528 not case-sensitive (e.g., "http" is equivalent to "HTTP"). The host 1529 part is also not case-sensitive, but other components of the scheme- 1530 specific-part may be case-sensitive. When comparing URIs, conforming 1531 implementations MUST compare the scheme and host without regard to 1532 case, but assume the remainder of the scheme-specific-part is case 1533 sensitive." 1535 5.1.2 Scope of Names 1537 The original X.500 work presumed that every subject in the world 1538 would have a globally-unique distinguished name. Thus, every subject 1539 could be easily located, and there would never be a conflict. All 1540 that would be needed is a sufficiently-large name space, and rules 1541 for constructing names based on subordination and location. 1543 Obviously, that is not practical in the real world, for a variety of 1544 reasons. There is no single entity in the world trusted by everybody 1545 to reside at the top of the name space, and there is no way to 1546 enforce uniqueness on names for all entities. (These were among the 1547 reasons for the failure of PEM to be widely implemented.) 1549 This does not mean, however, that a name-based PKI cannot work. It is 1550 important to recognize that the scope of names in PKIX is local; they 1551 need to be defined and unique only within their own domain. 1553 Suppose for example that a Top CA is established with DN "O=IETF, 1554 OU=PKIX, CN=PKIX_CA". That CA will then issue PKCs for subjects 1555 subordinate to it. The only requirement, which can be enforced 1556 procedurally, is that no two distinct entities beneath this Top CA 1557 have the same name. We can't prevent somebody else in the world from 1558 creating her own CA, called "O=IETF, OU=PKIX, CN=PKIX_CA", and it is 1559 not necessary to do so. Within the domain of the original Top CA, 1560 there will be no conflict, and the fact that there is another CA of 1561 the same name in some other domain is irrelevant. 1563 This is analogous to the current DNS or IP address situations. On the 1564 Internet, there is only one node called www.ietf.org. The fact that 1565 there might be 10 different intranets, each with a host given the DNS 1566 name www.ieft.org, is irrelevant and causes no interoperability 1567 problems - those are different domains. However, if there were to be 1568 another node on the Internet with domain name www.ietf.org, then 1569 there would be a problem due to name duplication. 1571 The same applies for IP addresses. As long as only one node on the 1572 Internet responds to the IP address 130.85.1.3, there is no problem, 1573 despite the fact that there are 100 different corporate Intranets, 1574 each using that same IP address. However, if two different nodes on 1575 the Internet each responded to the IP address 130.85.1.3, there would 1576 be a problem. 1578 5.1.3 Certificate Path Construction 1580 Certificate path construction has been the topic of many discussions 1581 in the WG. The issue centered around how best to get a certificate 1582 when the connection between the subject's name and the name of their 1583 CA, as well as the CA's repository (or directory), may not be 1584 obvious. Many proposals were put forth, including implementing a 1585 global X.500 Directory Service, using DNS SRV records, and using an 1586 extension to point to the directory provider. At the end of the 1587 discussion the group decided to use the authority information access 1588 extension defined in [FORMAT], which allows the CA to indicate the 1589 access method and location of CA information and services. The 1590 extension would be included in subject's certificates and could be 1591 used to associate an Internet style identity for the location of 1592 repository to retrieve the issuer's certificate in cases where such a 1593 location is not related to the issuer's name. 1595 Another discussion related to certificate path construction was where 1596 to store the CA and EE PKCs in the directory (specifically LDAPv2 1597 directories). Two camps emerged with different views on where to 1598 store CA and cross-certificates. In the CA's directory entry, one 1599 camp wanted self-issued PKCs stored in the cACertificate attribute, 1600 PKCs issued to this CA stored in the forward element of the 1601 crossCertificatePair, and PKCs issued from this CA for other CAs in 1602 the reverse element of the crossCertificatePair attribute. The other 1603 camp wanted all CA PKCs stored in the cACertificate attribute, and 1604 PKCs issued to/from another domain stored in the crossCertificatePair 1605 attribute. There was a short discussion that the second was more 1606 efficient than first, and that one solution or the other was more 1607 widely deployed. The end result was to indicate that self-issued PKCs 1608 and PKCs issued to the CA by CAs in the same domain as the CA are 1609 stored in the cACertificate attribute. The crossCertificatePair 1610 attribute's forward element will include all but self-issued PKCs 1611 issued to the CA. The reverse element may include a subset of PKCs 1612 issued by the CA to other CAs. With this resolution both camp's 1613 implementations are supported and are free to chose the location of 1614 CA PKCs to best support their implementation. 1616 5.1.4 Name Constraints 1618 A question that has arisen a number of times is "how does one enforce 1619 Name constraints when there is more than one name form in a PKC?" 1620 That is, [FORMAT] states that: 1622 subject's alternative names may be constrained in the same manner 1623 as subject distinguished names using the name constraints extension 1624 as described in section 4.2.1.11. 1626 What does this mean? Suppose that there is a CA with DN "O=IETF, 1627 OU=PKIX, CN=PKIX_CA", with the subjectAltName extension having 1628 dNSName "PKIX_CA.IETF.ORG". Suppose that that CA has issued a PKC 1629 with an empty DN, with subjectAltName extension having dNSName set to 1630 "PKIX_CA.IETF.ORG", and rfc822Name set to Steve@PKIX_CA.IETF.ORG. The 1631 question is, are name constraints enforced on these two PKCs - is the 1632 name of the EE PKC considered to be properly subordinate to the name 1633 of the CA? 1635 The answer is "yes". The general rules for deciding whether a PKC 1636 meets name constraints are: 1638 - If a PKC complies with name constraints in any one of its name 1639 forms, then the PKC is deemed to comply with name constraints. 1641 - If a PKC contains a name form that its issuer does not, the PKC 1642 is deemed to comply with name constraints for that name form. 1644 In deciding whether a name form meets name constraints, the following 1645 rules apply (in all cases Name B is the name in the name constraints 1646 extension): 1648 5.1.4.1 rfc822Names 1650 Three variations are allowed: 1652 - If the name constraint is specified as "larry@mail.mit.edu", then 1653 Name A is subordinate to Name B (in B's subtree) if Name A 1654 contains all of Name B's name (specifies a particular mailbox). 1655 For example, larry@mail.mit.edu is subordinate, but 1656 larry_sanders@mail.mit.edu is not. 1658 - If the name constraint is specified as "mail.mit.edu", then Name 1659 A is subordinate to Name B (in B's subtree) if Name A contains 1660 all of Name B's name (specified all mailboxes on host 1661 mail.mit.edu). For example, curly@mail.mit.edu and 1662 mo@mail.mit.edu are subordinate, but mo@mail6.mit.edu and 1663 curly@smtp.mail.mit.edu are not. 1665 - If the name constraint is specified as ".mit.edu", then Name A is 1666 subordinate to Name B (in B's subtree) if Name A contains all of 1667 Name B's name, with the addition of zero or more additional host 1668 or domain names to the left of Name B's name. That is, 1669 smtp.mit.edu is subordinate to .mit.edu, as is pop.mit.edu. 1670 However, mit.edu is not subordinate to .mit.edu. When the 1671 constraint begins with a "." it specifies any address within a 1672 domain. In the previous example, "mit.edu" is not in the domain 1673 of ".mit.edu". 1675 Note: If rfc822 names are constrained, but the PKC does not contain a 1676 subjectAltName extension, the EmailAddress attribute will be used to 1677 constrain the name in the subject distinguished name. For example (c 1678 is country, o is organization, ou is organizational unit, and em is 1679 EmailAddress), Name A ("c=US, o=MIT, ou=CS, em=curly@mail.mit.edu") 1680 is subordinate to Name B ("c=US, o=MIT, ou=CS") (in B's subtree) if 1681 Name A contains all of Name B's names. 1683 5.1.4.2 dNSNames 1685 Name A is subordinate to Name B (in B's subtree) if Name A contains 1686 all of Name B's name, with the addition of zero or more additional 1687 domain names to the left of Name B's name. That is, www.mit.edu is 1688 subordinate to mit.edu, as is larry.cs.mit.edu. However, www.mit.edu 1689 is not subordinate to web.mit.edu. 1691 5.1.4.3 x.400 addresses 1693 Name A is subordinate to Name B (in B's subtree) if Name A contains 1694 all of Name B's name. For example (c is country-name, admd is 1695 administrative-domain-name, and o is orgnaization-name, ou is 1696 organizational-unit-name, pn is personal-name, sn=surname, and gn is 1697 given-name in both Name A and B), the mneumonic X.400 address (using 1698 PrintableString choices for c and admd) "c=US, admd=AT&T, o=MIT, 1699 ou=cs, pn='sn=Doe,gn=John'" is subordinate to "c=US, admd=AT&T, 1700 o=MIT, ou=cs" and "c=US, admd=AT&T, o=MIT, pn='sn=DOE,gn=JOHN'" (pn 1701 is a SET that includes, among other things, sn and gn). 1703 5.1.4.5 DNs 1705 Name A is subordinate to Name B (in B's subtree), if Name A contains 1706 all of Name B's name, treating attribute values encoded in different 1707 types as different strings, ignoring case in PrintableString (in all 1708 other types case is not ignored), removing leading and trailing white 1709 space in PrintableString, and converting internal substrings of one 1710 or more consecutive white space characters to a single space. For 1711 example, (c is country, o is organization, ou is organizational unit, 1712 and cn is common name): 1714 - Assuming PrinatString types for all attribute values in Name A 1715 and B, "c=US, o=MIT, ou=CS" is subordinate to "c=us, o=MIT, 1716 ou=cs", as is "c=US, o=MIT, ou=CS, ou=adminstration". Another 1717 example, "c=US, o=MIT, ou=CS, cn= John Doe" (note the white 1718 spaces) is subordinate to "c=US, o=MIT, ou=CS, cn=John Doe". 1720 - Assuming UTF8String types for all attribute values in Name A and 1721 B, "c=US, o=MIT, ou=CS, ou=administration" is subordinate to 1722 "c=US, o=MIT, ou=CS", but "c=US, o=MIT, ou=cs, ou=Adminstration". 1723 "c=US, o=MIT, ou=CS, cn= John Smith" (note the white spaces) is 1724 not subordinate to "c=US, o=MIT, ou=CS, cn= John Smith". 1726 - Assuming UTF8String types for all attribute values in Name A and 1727 PrintableString types for all attribute values in Name B, "c=US, 1728 o=MIT, ou=cs" is subordinate to "c=US, o=MIT, ou=CS" if the 1729 verification software supports the full comparison algorithm in 1730 the X.500 series. "c=US, o=MIT, ou=cs" is NOT subordinate to 1731 "c=US, o=MIT, ou=CS" if the verification software supports the 1732 comparison algorithm in [FORMAT]. 1734 5.1.4.6 URIs 1736 The constraints apply only to the host part of the name. Two 1737 variations are allowed: 1739 - If the name constraint is specified as ".mit.edu", then Name A is 1740 subordinate to Name B (in B's subtree) if Name A contains all of 1741 Name B's name, with the addition of zero or more additional host 1742 or domain names to the left of Name B's name. That is, 1743 www.mit.edu is subordinate to .mit.edu, as is curly.cs.mit.edu. 1745 However, mit.edu is not subordinate to .mit.edu. When the 1746 constraint begins with a "." it specifies a host. 1748 - If the name constraint is specified as "abc.mit.edu", then Name A 1749 is subordinate to Name B (in B's subtree) if Name A conatins all 1750 of Name B's name. No leftward expansion of the host or domain 1751 name is allowed. 1753 5.1.4.7 iPaddresses 1755 Two variations are allowed depending on the IP version: 1757 - For IPv4 addresses: Name A (128.32.1.1 encoded as 80 20 01 01) is 1758 subordinate to Name B (128.32.1.0/255.255.255.0 encoded as 80 20 1759 00 00 FF FF FF 00) (in B's subtree) if Name A falls within the 1760 net denoted in Name B's CIDR notation. 1762 - For IPv6 addresses: Name A (4224.0.0.0.8.2048.8204.16762 encoded 1763 as 10 80 00 00 00 00 00 00 00 08 08 00 20 0C 41 7A) is 1764 subordinate to Name B (4224.0.0.0.8.2048.8204.0/ 1765 65535.65535.65535.65535.65535.65535.65535.0 encoded as 10 80 00 1766 00 00 00 00 00 00 08 08 00 20 0C 00 00 FF FF FF FF FF FF FF FF FF 1767 FF FF FF FF FF 00 00) (in B's subtree) if Name A falls within the 1768 net denoted in Name B's CIDR notation. 1770 5.1.4.8 Others 1772 As [FORMAT] does not define requirements for the name forms 1773 otherName, ediPartyName, or registeredID there are no corresponding 1774 name constraints requirements. 1776 5.1.5 Wildcards in Name Forms 1778 A "wildcard" in a name form is a placeholder for a set of names 1779 (e.g., "*.mit.edu" meaning "any domain name ending in .mit.edu", and 1780 *@aol.com meaning "email address that uses aol.com"). There are many 1781 people who believe that allowing wildcards in name forms in PKIX PKCs 1782 would be a useful thing to do, because it would allow a single PKC to 1783 be used by all members of a group. These members would presumably 1784 have attributes in common; e.g., access rights to some set of 1785 resources, and so issuance of a PKC with a wildcard for the group 1786 would simplify management. 1788 After much discussion, the PKIX working group decided to permit the 1789 use of wildcards in PKCs. That is, it is permissible for a PKIX- 1790 conformant CA to issue a PKC with a wildcard. However, the semantics 1791 of subjectAltName extension that include wildcard characters are not 1792 addressed by PKIX. Applications with specific requirements may use 1793 such names but must define the semantics. 1795 5.1.6 Name Encoding 1797 A very important topic that consumed much of the WG's time was the 1798 implementation of the directory string choices. While the long term 1799 goal of the IETF was clear, use UTF8String, the short term goals were 1800 not so clear. Many implementations only use PrintableString, others 1801 use BMPString, and still others use Latin1String (ISO 8859-1) and tag 1802 it as TeletexString (there are others still). To ensure that there is 1803 consistency with encodings [FORMAT] defines a set of rules for the 1804 string choices. PrintableString was kept as the first choice because 1805 of it's widespread support by vendors. BMPString was the second 1806 choice, also for it's widespread vendor support. Failing support by 1807 PrintableString and BMPString, UTF8String must be used. In keeping 1808 with the IETF mandate, UTF8String can be used at any time if the CA 1809 supports it. Also, processing implementations that wish to support 1810 TeletexString should handle the entire ISO 8859-1 character set and 1811 not just the Latin1String subset. 1813 5.2 POP 1815 Proof of Possession, or POP, means that the CA is adequately 1816 convinced that the entity requesting a PKC containing a public key Y 1817 has access to the private key X corresponding to that public key. 1819 POP is important because it provides an appropriate level of 1820 assurance in the correct operation of the PKI as a whole. At its 1821 lowest level, POP counters the "self-inflicted denial of service"; 1822 that is, an entity voluntarily getting a PKC that cannot be used to 1823 sign or encrypt/decrypt information. However, as the following two 1824 examples demonstrate, POP also counters less direct, but more severe, 1825 threats. 1827 5.2.1 POP for Signing Keys 1829 It is important to provide POP for keys used to sign material, in 1830 order to provide non-repudiation of transactions. For example, 1831 suppose Alice legitimately has private key X and its corresponding 1832 public key Y. Alice has a PKC from Charlie, a CA, containing Y. Alice 1833 uses X to sign a transaction T. Without POP, Mal could also get a PKC 1834 from Charlie containing the same public key, Y. Now, there are two 1835 possible threats: Mal could claim to have been the real signer of T; 1836 or Alice can falsely deny signing T, claiming that it was instead 1837 Mal. Since no one can reliably prove that Mal did or did not ever 1838 possess X, neither of these claims can be refuted, and thus the 1839 service provided by and the confidence in the PKI has been defeated. 1840 (Of course, if Mal really did possess X, Alice's private key, then no 1841 POP mechanism in the world will help, but that is a different 1842 problem.) 1844 One level of protection can be gained by having Alice, as the true 1845 signer of the transaction, include in the signed information her PKC 1846 or an identifier of her PKC (e.g., a hash of her PKC). This might 1847 make it more difficult for Mal to claim authorship - he would have to 1848 assert that he incorrectly included Alice's PKC, rather than his own. 1849 However, it would not stop Alice from falsely repudiating her 1850 actions. Since the PKC itself is a public item, Mal indeed could have 1851 inserted Alice's PKC into the signed transaction, and thus its 1852 presence does not indicate that Alice was the one who participated in 1853 the now-repudiated transaction. The only reliable way to stop this 1854 attack is to require that Mal prove he possesses X before his PKC is 1855 issued. 1857 For signing keys used only for authentication, and not for non- 1858 repudiation, the threat is lower because users may not care about 1859 Alice's after-the-fact repudiation, and thus POP becomes less 1860 important. However, POP SHOULD still be done wherever feasible in 1861 this environment, by either off-line or on-line means. 1863 5.2.2 POP for Key Management Keys 1865 Similarly, POP for key management keys (that is, keys used for either 1866 key agreement or key exchange) can help to prevent undermining 1867 confidence in the PKI. Suppose that Al is a new instructor in the 1868 Computer Science Department of a local University. Al has created a 1869 draft final exam for the Introduction to Networking course he is 1870 teaching. He wants to send a copy of the draft final to Dorothy, the 1871 Department Head, for her review prior to giving the exam. This exam 1872 will of course be encrypted, as several students have access to the 1873 computer system. However, a quick search of the PKC repository (e.g., 1874 search the repository for all records with 1875 subjectPublicKey=Dorothy's-value) turns up the fact that several 1876 students have PKCs containing the same public key management key as 1877 Dorothy. At this point, if no POP has been done by the CA, Al has no 1878 way of knowing whether all of the students have simply created these 1879 PKCs without knowing the corresponding private key (and thus it is 1880 safe to send the encrypted exam to Dorothy), or whether the students 1881 have somehow acquired Dorothy's private key (and thus it is certainly 1882 not safe to send the exam). Thus, the service to be provided by the 1883 PKI - allowing users to communicate with one another, with confidence 1884 in who they are communicating with - has been totally defeated. If 1885 the CA is providing POP, then either no students will have such PKCs, 1886 or Al can know with certainty that the students do indeed know 1887 Dorothy's private key, and act accordingly. 1889 CMP requires that POP be provided for all keys, either through on- 1890 line or out-of-band means. There are any number of ways to provide 1891 POP, and the choice of which to use is a local matter. Additionally, 1892 a PKC requester can provide POP to either a CA or to an RA, if the RA 1893 can adequately assure the CA that POP has been performed. Some of the 1894 acceptable ways to provide POP include: 1896 - Out-of-band means: 1898 - For keys generated by the CA or an RA (e.g., on a token such as 1899 a smart card or PCMCIA card), possession of the token can 1900 provide adequate proof of possession of the private key. 1902 - For user-generated keys, another approach can be used in 1903 environments where "key recovery" requirements force the 1904 requester to provide a copy of the private key to the CA or an 1905 RA. In this case, the CA will not issue the requested PKC until 1906 such time as the requester has provided the private key. This 1907 approach is in general not recommended, as it is extremely 1908 risky (e.g., the system designers need to figure out a way to 1909 protect the private keys from compromise while they are being 1910 sent to the CA/RA/other authority, and how to protect them 1911 there), but it can be used. 1913 - On-line means: 1915 - For signature keys that are generated by an EE, the requester 1916 of a PKC can be required to sign some piece of data (typically, 1917 the PKC request itself) using the private key. The CA will then 1918 use the requested public key to verify the signature. If the 1919 signature verification works, the CA can safely conclude that 1920 the requester had access to the private key. If the signature 1921 verification process fails, the CA can conclude that the 1922 requester did not have access to the correct private key, and 1923 reject the request. 1925 - For key management keys that are generated by the requester, 1926 the CA can send the user the requested public key, along with 1927 the CA's own private key, to encrypt some piece of data, and 1928 send it to the requester to be decrypted. For example, the CA 1929 can generate some random challenge, and require some action to 1930 be taken after decryption (e.g., "decrypt this encrypted random 1931 number and send it back to me"). If the requester does not take 1932 the requested action, the CA concludes that the requester did 1933 not possess the private key, and the PKC is not issued. 1935 Another method of providing POP for key management keys is for the CA 1936 to generate the requested PKC, and then send it to the requester in 1937 encrypted form. If the requester does not have access to the 1938 appropriate private key, the requester cannot decrypt the PKC, and 1939 thus cannot use it. After some period of time in which the PKC is not 1940 used, the CA will revoke the PKC. (This only works if the PKC is not 1941 made available to any untrusted entities until after the requester 1942 has successfully decrypted it.) 1944 5.3 Key Usage Bits 1946 5.3.1 Key Usage Extension 1948 The key usage extension defines the purpose (e.g., encipherment, 1949 signature, certificate signing) of the key contained in the PKC. This 1950 extension is used when a key that could be used for more than one 1951 operation is to be restricted. For example, when an RSA key should be 1952 used only for signing, the digitalSignature and/or nonRepudiation 1953 bits would be asserted. Likewise, when an RSA key should be used only 1954 for key management, the keyEncipherment bit would be asserted. When 1955 used, this extension should be marked critical. 1957 According to [FORMAT], bits in the KeyUsage type are used as follows: 1959 - The digitalSignature bit is asserted when the subject public key 1960 is used to verify digital signatures that have purposes other 1961 than non-repudiation, certificate signature, and CRL signature. 1962 For example, the digitalSignature bit is asserted when the 1963 subject public key is used to provide authentication via the 1964 signing of ephemeral data. 1966 - The nonRepudiation bit is asserted when the subject public key is 1967 used to verify digital signatures used to provide a non- 1968 repudiation service which protects against the signing entity 1969 falsely denying some action, excluding certificate or CRL 1970 signing. 1972 - The keyEncipherment bit is asserted when the subject public key 1973 is used for key transport. For example, when an RSA key is to be 1974 used for key management, this bit must asserted. 1976 - The dataEncipherment bit is asserted when the subject public key 1977 is used for enciphering user data, other than cryptographic keys. 1979 - The keyAgreement bit is asserted when the subject public key is 1980 used for key agreement. For example, when a Diffie-Hellman key is 1981 to be used for key management, this bit must asserted. 1983 - The keyCertSign bit is asserted when the subject public key is 1984 used for verifying a signature on certificates. This bit may only 1985 be asserted in CA certificates. 1987 - The cRLSign bit is asserted when the subject public key is used 1988 for verifying a signature on revocation information (e.g., a 1989 CRL). 1991 - The meaning of the encipherOnly bit is undefined in the absence 1992 of the keyAgreement bit. When the encipherOnly bit is asserted 1993 and the keyAgreement bit is also set, the subject public key may 1994 be used only for enciphering data while performing key agreement. 1996 - The meaning of the decipherOnly bit is undefined in the absence 1997 of the keyAgreement bit. When the decipherOnly bit is asserted 1998 and the keyAgreement bit is also set, the subject public key may 1999 be used only for deciphering data while performing key agreement. 2001 PKIX does not restrict the combinations of bits that may be set in an 2002 instantiation of the keyUsage extension. 2004 The discussion on the PKIX mailing list has centered on the 2005 digitalSignature bit and the nonRepudiation bit. The question has 2006 come down to something like: When support for the service of non- 2007 repudiation is desired, should both the digitalSignature and 2008 nonRepudiation bits be set, or just the nonRepudiation bit? 2010 Note: Provision of the service of non-repudiation requires more 2011 than a single bit set in a PKC. It requires an entire 2012 infrastructure of components to preserve for some period of time 2013 the keys, PKCs, revocation status, signed material, etc., as well 2014 as a trusted source of time. However, the nonRepudiation key usage 2015 bit is provided as an indicator that such keys should not be used 2016 as a component of a system providing a non-repudiation service. 2018 According to [SIMONETTI], the intent is that the digitalSignature bit 2019 should be set when what is desired is the ability to sign ephemeral 2020 transactions; e.g., for a single session authentication. These 2021 transactions are "ephemeral" in the sense that they are important 2022 only while they are in existence; after the session is terminated, 2023 there is no long-term record of the digital signature and its 2024 properties kept. When something is intended to be kept for some 2025 period of time, the nonRepudiation bit should be set. This generally 2026 implies that an application will digitally sign something; thus, some 2027 implementors turn on the digitalSignature bit as well. Other 2028 implementors, however, keep the two bits mutually exclusive, to 2029 prevent a single key from being used for both ephemeral and long-term 2030 signing. 2032 While [FORMAT] is silent on this specific issue, the working group's 2033 general conclusion is that a PKC may have either or both bits set. If 2034 only the nonRepudiation bit is set, the key should not be used for 2035 ephemeral transactions. If only the digitalSignature bit is set, the 2036 key should not be used for long-term signing. If both bits are set, 2037 the key may be used for either purpose. 2039 To actually enforce this requires that an application understands 2040 whether it is signing ephemeral transactions or for the long-term. 2041 The application developers will have to understand the difference, 2042 and set up their checks on the key usage bits field accordingly. For 2043 example, TLS implementors should check only the digitalSignature bit, 2044 and ignore the nonRepudiation bit. S/MIME implementors, though, will 2045 have a difficult choice to make, since their application could be 2046 used for either purpose, and they will generally accept signing using 2047 keys associated with PKCs having either or both bits being turned on. 2048 Certification Authorities should know what applications they are 2049 providing PKCs for, and provide PKCs according to the requirements of 2050 those applications. If CA's are tied into non-repudiation systems, 2051 they may treat PKCs differently when the nonRepudiation bit is turned 2052 on (e.g., store information associated with the PKC - like the user's 2053 identification provided during PKC registration, or PKC generation 2054 date/time stamps - for longer periods of time, in more secure 2055 environments). 2057 The bottom line is that this is an area where PKI implementors are 2058 somewhat limited in what they can do. The onus is on developers of 2059 PKC-using systems to understand their requirements and request PKCs 2060 with the appropriate bits set. 2062 5.3.1 Extended Key Usage Extension 2064 [Add in text to talk about the extended key usages!] 2066 5.4 Trust Models 2068 An important design decision is where in the PKI the trust point for 2069 a particular EE should be located (i.e., where is the EE's Root CA) . 2070 There are two extremes: the Top CA or the CA who issues the EE's 2071 certificate. Of course, the trust point for a particular EE can be 2072 anywhere in the PKI, but the following presents the advanatages and 2073 disadvantages of locating the the trust point at these two places. 2075 Advantages of Top CA trust point: 2077 - Path discovery is easier since all EEs trust the same CA. 2079 - Certificate paths are potentially shorter between distant EEs, 2080 since the verifier need only trace back to the root, not back to 2081 his local CA. 2083 - Root can enforce adherence to a certificate policy by subordinate 2084 CAs. 2086 - Cross certification with other PKIs can be controlled at a senior 2087 level. 2089 Disadvantages of root trust point: 2091 - Compromise of the root key is catastrophic, requiring a re- 2092 distribution of certificates to all EEs. Similarly trust point 2093 roll-over affects entire hierarchy. 2095 - Users are required to trust a CA which may be remote from them. 2097 - Distribution of the trusted point certificate to distant EEs may 2098 be non-trivial. 2100 - Verification back to the root CA may be too onerous for low value 2101 transactions. 2103 - Certificate paths are potentially longer for nearby EEs since the 2104 verifier must always trace back to the root, not back to the CA 2105 it shares with the other party. 2107 Advantages of local trusted point: 2109 - The trusted point certificate need only be distributed from the 2110 CA to its local (nearby) EEs. 2112 - EEs are more likely to trust their local CA (which could be part 2113 of the same immediate organization) than a geographically remote 2114 CA. 2116 - Compromise of the local CAs private key only affects its own EEs. 2117 Similarly for trusted point roll-over. 2119 - Potentially shorter certification paths between nearby EEs, since 2120 the verifier may belong to the same CA as the other party. 2122 Disavantages of local trust point: 2124 - Potentially longer certification paths between distant EEs, since 2125 the verifier must trace the path back to its local CA. 2127 - Path discovery more complex and may not be supported in current 2128 products. 2130 - More difficult for the root to control cross-certification or 2131 ensure adherence to the certificate policy. 2133 6 Acknowledgements 2135 A lot of the information in this document was taken from the PKIX 2136 source documents; the authors of those deserve the credit for their 2137 own words. Other good material was taken from mail posted to the PKIX 2138 working group mail list (ietf-pkix@imc.org). Among those with good 2139 things to say were (in alphabetical order, with apologies to anybody 2140 we've missed): Sharon Boeyen, Santosh Chokhani, Warwick Ford, Russ 2141 Housley, Steve Kent, Ambarish Malpani, Matt Fite, Michael Myers, Tim 2142 Polk, Stefan Santesson, Dave Simonetti, and Paul Hoffman. 2144 7 References 2146 [AC] S. Farrell, R. HousleyMcNeil, M., and Glassey, T., "An Internet 2147 Attribute Certificate Profile for Authorization," , October 1999. 2150 [CMC] Myers, M., Liu, X., Fox, B., and Weinstein, J., "Certificate 2151 Management Messages over CMS," , 14 July 2152 1999. 2154 [CMP] Adams, C., Farrell, S., "Internet X.509 Public Key 2155 Infrastructure Certificate Management Protocols", RFC 2510, March 2156 1999. 2158 [CMP-HTTP] Tschal"ar, R., Kapoor, A., and Adams, C., "Using HTTP as a 2159 Transport Protocol for CMP", , 2160 August 1999. 2162 [CMP-TCP] Tschal"ar, R., Kapoor, A., and Adams, C., "Using TCP as a 2163 Transport Protocol for CMP", , August 2164 1999. 2166 [INTEROP] Moskowitz, R., "CMP Interoperability Testing: Results and 2167 Agreements", , June 1999. 2169 [CMS] R. Housley, "Cryptographic Message Syntax," RFC 2630, July 2170 1999. 2172 [CRMF] Myers, M., Adams, C., Solo, D., and Kemp, D., "Internet X.509 2173 Certificate Request Message Format," RFC 2511, March 1999. 2175 [DHPOP] Prafullchandra, H., and Schaad, J., "Diffie-Hellman Proof-of- 2176 Possession Algorithms," , 1 October 2177 1999. 2179 [DNS] Mockapetris, P.V., "Domain names - concepts and facilities," 2180 RFC 1034, November 1987. 2182 [DVCS] Adams, C., Sylvester, P., Zolotarev, M., Zuccherato, R., 2183 "Internet X.509 Public Key Infrastructure Data Certification Server 2184 Protocols", , 15 October 1999. 2186 [ECDSA] Bassham, L., Johnson, D., and Polk, W., "Internet x.509 2187 Public Key Infrastructure: Representation of Elliptic Curve Digital 2188 Signature Algorithm (ECDSA) Keys and Signatures in Internet X.509 2189 Public Key Infrastructure Certificates," , 3 June 1999. 2192 [ETNPT] Namjoshi, P., "Internet X.509 Public Key Infrastructure 2193 Extending trust in non repudiation tokens in time," , 28 May 1999. 2196 [IP] Postel, J., "Internet Protocol," RFC 791, September 1981. 2198 [IPv6] Deering, S., and Hinden, R., "Internet Protocol, Version 6 2199 [IPv6] Specification," RFC 1883, December 1995. 2201 [FORMAT] Housley, R., Ford, W., Polk, W., and Solo, D., "Internet 2202 X.509 Public Key Infrastructure Certificate and CRL Profile," RFC 2203 2459, January 1999. 2205 [FTPHTTP] Housley, R., and Hoffman, P., "Internet X.509 Public Key 2206 Infrastructure Operational Protocols: FTP and HTTP," RFC 2585, July 2207 1998. 2209 [KEA] Housley, R., and Polk, W., "Internet X.509 Public Key 2210 Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in 2211 Internet X.509 Public Key Infrastructure Certificates," RFC 2528, 2212 March 1999. 2214 [LAAP] Farrell, S., Chadwick, C.W., "Limited AttributeCertificate 2215 Acquisition Protocol", , Octoboer 1999. 2217 [LDAPv2] Yeong, Y., Howes, T., and Kille, S., "Lightweight Directory 2218 Access Protocol", RFC 1777, March 1995. 2220 [MISPC] Burr, W., Dodson, D., Nazario, N., and Polk, W., "MISPC 2221 Minimum Interoperability Specification for PKI Components, Version 2222 1", , 3 September 1997. 2224 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and Adams, 2225 C., "X.509 Internet Public Key Infrastructure Online Certificate 2226 Status Protocol - OCSP," RFC 2560, June 1999. 2228 [OCSPX] Myers, M., Ankney, R., Malpani, A., Galperin, S., and Adams, 2229 C., "OCSP Extensions," , 3 September 2230 1999. 2232 [PEM] Kent, S., "Privacy Enhancement for Internet Electronic Mail: 2233 Part II: Certificate-Based Key Management," RFC 1422, February 1993. 2235 [PKCS10] RSA Laboratories, "The Public-Key Cryptography 2236 Standards(PKCS)," RSA Data Security Inc., Redwood City, California, 2237 November 1993 Release. 2239 [PKI-LDAPv2] Boeyen, S., Howes, T., and Richard, P., "Internet X.509 2240 Public Key Infrastructure Operational Protocols - LDAPv2," RFC 2559, 2241 April 1999. 2243 [PKI-LDAPv3] Chadwick, D.W., "Internet X.509 Public Key 2244 Infrastructure Operational Protocols - LDAPv3," , August 1999. 2247 [POLPRAC] Chokhani, S., and Ford, W., "Internet X.509 Public Key 2248 Infrastructure Certificate Policy and Certification Practices 2249 Framework," RFC 2527, March 1999. 2251 [QC] Santesson, S., Polk, W., and Gloeckner, P., "Internet X.509 2252 Public Key Infrastructure Qualified Certificates", , 6 August 1999. 2255 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 2256 Messages," RFC 822, August 1982. 2258 [SCHEMA] Boeyen, S., Howes, T., and Richard, P., "Internet X.509 2259 Public Key Infrastructure LDAPv2 Schema," RFC 2587, June 1999. 2261 [SCVP] Malpani, A., Hoffman, P., "Simple Certificate Validation 2262 Protocol (SCVP)," , 9 August 1999. 2264 [SIMONETTI] Simonetti, D., "Re: German Key Usage", posting to ietf- 2265 pkix@imc.org mailing list, 12 August 1998. 2267 [TSP] Adams, C., Cain, P., Pinkas, D., and Zuccherato, R., "Internet 2268 X.509 Public Key Infrastructure Time Stamp Protocols", , September 1999. 2271 [X.509] ITU-T Recommendation X.509 (1997 E): Information Technology - 2272 Open Systems Interconnection - The Directory: Authentication 2273 Framework, June 1997. 2275 [X9.42] ANSI X9.42-199x, Public Key Cryptography for The Financial 2276 Services Industry: Agreement of Symmetric Algorithm Keys Using 2277 Diffie-Hellman (Working Draft), December 1997. 2279 [X9.55] ANSI X9.55-1995, Public Key Cryptography For The Financial 2280 Services Industry: Extensions To Public Key Certificates And 2281 Certificate Revocation Lists, 8 December, 1995. 2283 [X9.57] ANSI X9.57-199x, Public Key Cryptography For The Financial 2284 Services Industry: Certificate Management (Working Draft), 21 June, 2285 1996. 2287 8 Security Considerations 2289 TBSL 2291 9 Editor's Address 2293 Alfred Arsenault U. S. Department of Defense 9800 Savage Road Suite 2294 6734 Fort George G. Meade, MD 20755-6734 (410) 684-7114 2295 awarsen@missi.ncsc.mil 2297 Sean Turner IECA, Inc. 9010 Edgepark Road Vienna, VA 22182 (703) 2298 628-3180 turners@ieca.com 2300 10 Disclaimer 2302 This work constitutes the opinion of the editors only, and may not 2303 reflect the opinions or policies of their employers. 2305 Expires April 22, 2000