idnits 2.17.00 (12 Aug 2021) /tmp/idnits4785/draft-ietf-pkix-roadmap-05.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 49 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 50 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 6 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 1465: '...null subject field, it MUST contain an...' RFC 2119 keyword, line 1494: '...c mail addresses MUST use the rfc822Na...' RFC 2119 keyword, line 1553: '... name MUST be stored in the uniformR...' RFC 2119 keyword, line 1554: '... The name MUST be a non-relative URL...' RFC 2119 keyword, line 1562: '... implementations MUST compare the sche...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The first octets (the first characters of the first line) of this draft are 'PK', which can make Internet Explorer erroneously think that it is a zip file. It is recommended that you change this, for instance by inserting a blank line before the line starting with 'PK'. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1252 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 (March 10, 2000) is 8106 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: 'POLPROC' is mentioned on line 923, but not defined == Missing Reference: 'DCVS' is mentioned on line 383, but not defined == Missing Reference: 'RFC2459' is mentioned on line 859, but not defined ** Obsolete undefined reference: RFC 2459 (Obsoleted by RFC 3280) == Missing Reference: 'HTTP' is mentioned on line 1230, but not defined == Missing Reference: 'TCP' is mentioned on line 1243, but not defined == Missing Reference: 'RFC 1738' is mentioned on line 1558, but not defined ** Obsolete undefined reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) == Unused Reference: 'INTEROP' is defined on line 2146, but no explicit reference was found in the text == Unused Reference: 'POLPRAC' is defined on line 2228, but no explicit reference was found in the text == Unused Reference: 'SIMONETTI' is defined on line 2245, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2459bis' ** Obsolete normative reference: RFC 2510 (Obsoleted by RFC 4210) -- Possible downref: Non-RFC (?) normative reference: ref. 'AC' -- Possible downref: Non-RFC (?) normative reference: ref. 'CMC' -- Duplicate reference: RFC2510, mentioned in 'CMP', was also mentioned in '2510bis'. ** 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. 'TECHNR' -- Possible downref: Non-RFC (?) normative reference: ref. 'TSP' Summary: 26 errors (**), 0 flaws (~~), 16 warnings (==), 24 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 10 September, 2000 March 10, 2000 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 This Internet-Draft will expire in September, 2000. Comments or 34 suggestions for improvement may be made on the "ietf-pkix" mailing 35 list, or directly to the authors. 37 Copyright (C) The Internet Society (2000). All Rights Reserved. 39 Abstract 41 This document provides an overview or "roadmap" of the work done by 42 the IETF PKIX working group. It describes some of the terminology 43 used in the working group's documents, and the theory behind an 44 X.509-based Public Key Infrastructure and Privilege Management 45 Infrastructure (PMI). It identifies each document developed by the 46 PKIX working group, and describes the relationships among the various 47 documents. It also provides advice to would-be PKIX implementors 48 about some of the issues discussed at length during PKIX development, 49 in hopes of making it easier to build implementations that will 50 actually interoperate. 52 1 Introduction 54 1.1 This Document 56 This document is an informational Internet draft that provides a 57 "roadmap" to the documents produced by the PKIX working group. It is 58 intended to provide information; there are no requirements or 59 specifications in this document. 61 Section 2 of this document defines key terms used in this document. 62 Section 3 covers "PKIX theory;" it explains what the PKIX working 63 group's basic assumptions were. Section 4 provides an overview of the 64 various PKIX documents. It identifies which documents address which 65 areas, and describes the relationships among the various documents. 66 Section 5 contains "Advice to implementors." Its primary purpose is 67 to capture some of the major issues discussed by the PKIX working 68 group, as a way of explaining WHY some of the requirements and 69 specifications say what they say. This should cut down on the number 70 of misinterpretations of the documents, and help developers build 71 interoperable implementations. Section 6 contains a list of 72 contributors we wish to thank. Section 7 provides a list references. 73 Section 8 discusses security considerations, and Section 9 provides 74 contact information for the editors. Finally, Section 10 provides a 75 disclaimer. 77 1.2 Changes Since Last Version 79 Updated references to current drafts. 81 Add references to 2459bis (son-of-rfc 2459), 2510bis, Technical 82 Requirements for a Non-Repudiation Service, A String Represenation of 83 General Name. 85 Revised 5th paragraph in clause 3.2 as per comments. 87 Updated clause 5.2.2 as per comments. 89 Rewrote clause 5.3 Key Usage to addres more issues with respect to 90 the DS and NR bits. Also to change its focus from when to set the 91 bits to driving the definition of non-repudiation service 92 requirements. 94 Added a new clause 5.4 to talk about non-repudiation requirements. 96 1.3 To Do 97 Add in paragraph to talk about PMI functions. 99 Add in paragraph to talk about the whole QC naming issues 100 (dnQualifier vs serialNumber, serialNumber specification, etc.). 102 Rewrite trust models section. 104 2 Terminology 106 There are a number of terms used and misused throughout PKI-related 107 and PMI-related literature. To limit confusion caused by some of 108 those terms, throughout this document, we will use the following 109 terms in the following ways: 111 - Attribute Authority (AA) - An authority trusted by one or more 112 users to create and sign attribute certificates. It is important 113 to note that the AA is responsible for the attribute certificates 114 during their whole lifetime, not just for issuing them. 116 - Attribute Certificate (AC) - A data structure containing a set of 117 attributes for an end-entity and some other information, which is 118 digitally signed with the private key of the AA which issued it. 120 - Certificate - Can refer to either an AC or a public key 121 certificate. Where there is no distinction made the context 122 should be assumed to apply to both an AC and a public key 123 certificate. 125 - Certification Authority (CA) - An authority trusted by one or 126 more users to create and assign public key certificates. 127 Optionally the CA may create the user's keys. It is important to 128 note that the CA is responsible for the public key certificates 129 during their whole lifetime, not just for issuing them. 131 - Certificate Policy (CP) - A named set of rules that indicates the 132 applicability of a public key certificate to a particular 133 community or class of application with common security 134 requirements. For example, a particular certificate policy might 135 indicate applicability of a type of public key certificate to the 136 authentication of electronic data interchange transactions for 137 the trading of goods within a given price range. 139 - Certification Practice Statement (CPS) - A statement of the 140 practices which a CA employs in issuing public key certificates. 142 - End-entity - A subject of a certificate who is not a CA in the 143 PKIC or an AA in the PMI. (An EE from the PKI can be an AA in the 144 PMI.) 146 - Public Key Certificate (PKC) - A data structure containing the 147 public key of an end-entity and some other information, which is 148 digitally signed with the private key of the CA which issued it. 150 - Public Key Infrastructure (PKI) - The set of hardware, software, 151 people, policies and procedures needed to create, manage, store, 152 distribute, and revoke PKCs based on public-key cryptography. 154 - Privilege Management Infrastructure (PMI) - A collection of ACs, 155 with their issuing AA's, subjects, relying parties, and 156 repositories, is referred to as a Privilege Management 157 Infrastructure. 159 - Registration Authority (RA) - An optional entity given 160 responsibility for performing some of the administrative tasks 161 necessary in the registration of subjects, such as: confirming 162 the subject's identity; validating that the subject is entitled 163 to have the values requested in a PKC; and verifying that the 164 subject has possession of the private key associated with the 165 public key requested for a PKC. 167 - Relying party - A user or agent (e.g., a client or server) who 168 relies on the data in a certificate in making decisions. 170 - Root CA - A CA that is directly trusted by an EE; that is, 171 securely acquiring the value of a Root CA public key requires 172 some out-of-band step(s). This term is not meant to imply that a 173 Root CA is necessarily at the top of any hierarchy, simply that 174 the CA in question is trusted directly. 176 - Subordinate CA - A "subordinate CA" is one that is not a Root CA 177 for the EE in question. Often, a subordinate CA will not be a 178 Root CA for any entity but this is not mandatory. 180 - Subject - A subject is the entity (AA, CA, or EE) named in a 181 certificate. Subjects can be human users, computers (as 182 represented by Domain Name Service (DNS) names or Internet 183 Protocol (IP) addresses), or even software agents. 185 - Top CA - A CA that is at the top of a PKI hierarchy. 187 Note: This is often also called a "Root CA," since in data 188 structures terms and in graph theory, the node at the top of a tree 189 is the "root." However, to minimize confusion in this document, we 190 elect to call this node a "Top CA," and reserve "Root CA" for the 191 CA directly trusted by the EE. Readers new to PKIX should be aware 192 that these terms are not used consistently throughout the PKIX 193 documents, as [FORMAT] uses "Root CA" to refer to what this and 194 other documents call a "Top CA," and "most-trusted CA" to refer to 195 what this and other documents call a "Root CA." 197 3 PKIX Theory 199 3.1 Certificate-using Systems 201 3.1.1 Certificate-using Systems and PKIs 203 At the heart of recent efforts to improve Internet security are a 204 group of security protocols such as Secure Multipurpose Internet Mail 205 Extensions (S/MIME), Transport Layer Security (TLS), and Internet 206 Protocol Security (IPSec). All of these protocols rely on public-key 207 cryptography to provide services such as confidentiality, data 208 integrity, data origin authentication, and non-repudiation. The 209 purpose of a PKI is to provide trusted and efficient key and public 210 key certificate management, thus enabling the use of authentication, 211 non-repudiation, and confidentiality. 213 Users of public key-based systems must be confident that, any time 214 they rely on a public key, the associated private key is owned by the 215 subject with which they are communicating. (This applies whether an 216 encryption or digital signature mechanism is used.) This confidence 217 is obtained through the use of PKCs, which are data structures that 218 bind public key values to subjects. The binding is achieved by having 219 a trusted CA verify the subject's identity and digitally sign each 220 PKC. 222 A PKC has a limited valid lifetime, which is indicated in its signed 223 contents. Because a PKC's signature and timeliness can be 224 independently checked by a certificate-using client, PKCs can be 225 distributed via untrusted communications and server systems, and can 226 be cached in unsecured storage in certificate-using systems. 228 PKCs are used in the process of validating signed data. Specifics 229 vary according to which algorithm is used, but the general process 230 works as follows: 232 Note: there is no specific order in which the checks listed below 233 must be made; implementors are free to implement them in the most 234 efficient way for their systems. 236 - The recipient of signed data verifies that the claimed identity 237 of the user is in accordance with the identity contained in the 238 PKC; 240 - The recipient validates that no PKC in the path is revoked (e.g., 241 by retrieving a suitably-current Certificate Revocation List 242 (CRL) or querying an on-line certificate status responder), and 243 that all PKCs are within their validity periods at the time the 244 data was signed; 246 - The recipient verifies that the data are not claimed to have any 247 values for which the PKC indicates that the signer is not 248 authorized; 250 - The recipient verifies that the data have not been altered since 251 signing, by using the public key in the PKC. 253 If all of these checks pass, the recipient can accept that the data 254 was signed by the purported signer. The process for keys used for 255 encryption is similar. 257 Note: It is of course possible that the data was signed by someone 258 very different from the signer, if for example the purported 259 signer's private key was compromised. Security depends on all parts 260 of the certificate-using system, including but not limited to: 261 physical security of the place the computer resides; personnel 262 security (i.e., the trustworthiness of the people who actually 263 develop, install, run, and maintain the system); the security 264 provided by the operating system on which the private key is used; 265 and the security provided the CA. A failure in any one of these 266 areas can cause the entire system security to fail. PKIX is limited 267 in scope, however, and only directly addresses issues related to 268 the operation of the PKI subsystem. For guidance in many of the 269 other areas, see [POLPROC]. 271 3.1.2 Certificate-using Systems and PMIs 273 Many systems use the PKC to perform identity based access control 274 decisions (i.e., the identity may be used to support identity-based 275 access control decisions after the client proves that it has access 276 to the private key that corresponds to the public key contained in 277 the PKC). For many systems this is sufficient, but increasingly 278 systems are beginning to find that rule-based, role-based, and rank- 279 based access control is required. These forms of access control 280 decisions require additional information that is normally not 281 included in a PKC, because the lifetime of the information is much 282 shorter than the lifetime of the public-private key pair. To support 283 binding this information to a PKC the Attribute Certificate (AC) was 284 defined in ANSI and later incorporated into ITU-T Recommendation 285 X.509. The AC format allows any additional information to be bound to 286 a PKC by including, in a digitally signed data structure, a reference 287 back to one specific PKC or to multiple PKCs, useful when the subject 288 has the same identity in multiple PKCs. Additionally, the AC can be 289 constructed in such a way that it is only useful at one or more 290 particular targets (e.g., web server, mail host). 292 Users of a PMI must be confident that the identity purporting to 293 posess an attribute has the right to possess that attribute. This 294 confidence may be obtained through the use of PKCs or it may be 295 configured in the AC-using system. If PKCs are used the party making 296 the access control decision can determine "if the AC issuer is 297 trusted to issue ACs containing this attribute." 299 3.2 PKIX History 301 In the beginning there was ITU-T Recommendation X.509. It defines a 302 widely accepted basis for a PKI, including data formats and 303 procedures related to distribution of public keys via PKCs digitally 304 signed by CAs. X.509 does not however include a profile to specify 305 the support requirements for many of the PKC data structure's sub- 306 fields, for any of the extensions, nor for certain data values. PKIX 307 was formed in October 1995 to deliver a profile for the Internet PKI 308 of X.509 version 3 PKCs and version 2 CRLs. The Internet PKI profile 309 [FORMAT] went through eleven draft versions before becoming an RFC. 310 Other profiles have been developed in PKIX for particular algorithms 311 to make use of [FORMAT]. There has been no sense of conflict between 312 the authors that developed these profiles as they are seen as 313 complimentary. 315 The development of the management protocols has not been so 316 straightforward. The Certificate Management Protocol (CMP) was 317 developed to define a message protocol that is used between entities 318 in a PKI [CMP]. The demand for an enrollment protocol and the desire 319 to use PKCS-10 message format as the certificate request syntax lead 320 to the development of two different documents in two different 321 groups. The Certificate Request Syntax (CRS) draft was developed in 322 the SMIME WG which used PKCS-10 [PKCS10] as the certification request 323 message format. Certificate Request Message Format [CRMF] draft was 324 also developed but in the PKIX WG. It was to define a simple 325 enrollment protocol that would subsume both the CMP and CRS 326 enrollment protocols, but it did not use PKCS-10 as the certificate 327 request message format. Then the certificate management message 328 format document, was developed to define an extended set of 329 management messages that flow between the components of the Internet 330 PKI. Certificate Management Messages over CMS (CMC) was developed to 331 allow the use of an existing protocol (S/MIME) as a PKI management 332 protocol, without requiring the development of an entirely new 333 protocol such as CMP [CMC]. It also included [PKCS10] as the 334 certificate request syntax, which caused work on the CRS draft to 335 stop. Information from the certificate management message format 336 document was moved into [CMP] and [CMC] so work on the certificate 337 management message format document was discontinued. 339 Another long debated topic in the WG dealt with certificate 340 revocation. Numerous drafts have been developed to address different 341 issues related certificate revocations. CMP supports revocation 342 request, response, revocation announcement, and requests for CRL 343 messages. CMC defines revocation request, revocation response, and 344 requests for CRL messages, but uses CMS as the encapsulating 345 protocol. [OCSP] was developed to address concerns that not all 346 relying parties want to go through the process checking CRLs from 347 every CA in the certification path. It defines an on-line mechanism 348 to determine the status of a given certificate, which may provide 349 more timely revocation information than is possible with CRLs. The 350 Simple Certification Verification Protocol (SCVP) was produced to 351 allow relying parties to off-load all of their certification 352 verification to another entity [SCVP]. The WG was arguable split over 353 whether such a function should be supported and whether it should be 354 its own protocol or included in OCSP. In response, a draft defining 355 OCSP Extensions [OCSPX] was produced to include the functions of 356 SCVP. One other draft called Open CRL Distribution Point (OCDP) was 357 produced which documented two extensions: one to support an 358 alternative CRL partitioning mechanism to the CRL Distribution Point 359 mechanism documented in [FORMAT] and one to support identifying other 360 revocation sources available to certificate-users. The work from 361 this draft was subsumed by an ITU-T | ISO/IEC Amendment to X.509, 362 hence work on this draft was halted. 364 Development of the operational protocols has been slightly more 365 straightforward. Three documents for the Light Weight Directory 366 Access Protocol (LDAP) have been developed one for defining LDAPv2 as 367 an access protocol to repositories [PKI-LDAPv2]; one for storing PKI 368 information in an LDAP directory [SCHEMA]; and one for LDAPv3 369 requirements for PKI [PKI-LDAPv3]. Using the File Transfer Protocol 370 (FTP) and the Hyper Text Transmission Protocol (HTTP) to retrieve 371 PKCs and CRLs from PKI repositories was documented in [FTPHTTP]. 373 In late 1998 the PKIX charter was revised to include protocols for 374 time stamping and data certification services. [TSP] was developed to 375 define protocols required to interact with a Time Stamp Authority 376 (TSA) who asserts that a datum existed at a given time. [DVCS] allows 377 to verify and assert the validity of all signatures attached to the 378 signed document using all appropriate status information and PKCs or 379 to verify and assert the validity of one or more PKCs at the 380 specified time. Both [DVCS] and [TSP] use [CMS] as an encapsulating 381 (though in [TSP] request for a time stamp are not required to use 383 [CMS]). [ETNPT] was developed to use [DCVS] to maintain the trust in 384 a token issued by a non-repudiation Trusted Third Party (NR TTP) 385 after the key initially used to establish trust in the token expires. 387 Around the same time, a work item for ACs, defined in [X.509], was 388 added. ACs are similar to PKCs, but they do not bind public keys to 389 identities rather they bind attributes to identities. The attributes 390 bound to the identity can represent anything, but are mostly used to 391 support rule-based, role-based, and rank-based access control 392 decisions. Two drafts have since been developed: the Internet 393 Attribute Certificates Profile for Authorizations [AC] and the 394 Limited AttributeCertificate Acquisition Protocol [LAAP]. The first 395 profiles the fields and extensions of the AC and the second provides 396 a deliberately limited protocol to access a repository when LDAP is 397 not appropriate. 399 Other drafts have been produced to address specific issues. [DHPOP] 400 was developed to define two mechanisms by which a signature can 401 produced using a Diffie-Hellman pair. This draft provides a 402 mechanism to Diffie-Hellam key pairs to issue a PKCS-10 certification 403 request. After some operational experience with [CMP], two drafts, 404 one for using HTTP as the transport protocol [CMP-HTTP] and one for 405 Transmission Control Protocol (TCP) [CMP-TCP], were written to solve 406 problems encountered by implementors. 408 From the alphabet soup above, it is clear why this roadmap is 409 required. 411 Note that [FORMAT] and [CMP] are currently being updated based on 412 implementation experience, see [2459bis] and [2510bis]. 414 3.3 Overview of the PKIX Approach 416 3.3.1 PKI 418 PKIX is an effort to develop specifications for a PKI for the 419 Internet using PKCs. A PKI is defined as: 421 The set of hardware, software, people, policies and procedures needed 422 to create, manage, store, distribute, and revoke PKCs based on 423 public-key cryptography. 425 A PKI consists of five types of components [MISPC]: 427 - Certification Authorities (CAs) that issue and revoke PKCs; 429 - Organizational Registration Authorities (ORAs) that vouch for the 430 binding between public keys and certificate holder identities and 431 other attributes; 433 - Certificate holders that are issued certificates and can sign 434 digital documents and encrypt documents; 436 - Clients that validate digital signatures and their certification 437 paths from a known public key of a trusted CA; 439 - Repositories that store and make available certificates and 440 Certificate Revocation Lists (CRLs). 442 Figure 1 is a simplified view of the architectural model assumed by 443 the PKIX Working Group. 445 +---+ 446 | C | +------------+ 447 | e | <-------------------->| End entity | 448 | r | Operational +------------+ 449 | t | transactions ^ 450 | | and management | Management 451 | / | transactions | transactions 452 | | | PKI users 453 | C | v 454 | R | -------------------+--+-----------+---------------- 455 | L | ^ ^ 456 | | | | PKI management 457 | | v | entities 458 | R | +------+ | 459 | e | <---------------------| RA | <---+ | 460 | p | Publish certificate +------+ | | 461 | o | | | 462 | s | | | 463 | I | v v 464 | t | +------------+ 465 | o | <------------------------------| CA | 466 | r | Publish certificate +------------+ 467 | y | Publish CRL ^ 468 | | | 469 +---+ Management | 470 transactions | 471 v 472 +------+ 473 | CA | 474 +------+ 475 Figure 1 - PKI Entities 477 3.3.2 PMI 479 PKIX is also an effort to develop specifications for a Privilege 480 Management Infrastructure for the Internet using ACs. A Privilege 481 Management Infrastructure, or PMI, is defined as: 483 The set of hardware, software, people, policies and procedures needed 484 to create, manage, store, distribute, and revoke ACs. 486 A PMI consists of five types of components [AC]: 488 - Attribute Authorities (AAs), or Attribute Certificate Issuer, 489 that issue and revoke ACs; 491 Note: AAs may implicitly revoke ACs by using very short validity 492 periods. 494 - Attribute Certificate Users that parses or processes an AC; 496 - Attribute Certificate Verifiers that check the validity of an AC 497 and then makes use of the result; 499 - Clients that request an action for which authorization checks are 500 to be made; 502 - Repositories that store and make available certificates and 503 Certificate Revocation Lists (CRLs). 505 Figure 2 is an example of the exchanges that may involve ACs. 507 +--------------+ 508 | | Server Acquisition 509 | AC Issuer +----------------------------+ 510 | | | 511 +--+-----------+ | 512 | | 513 | Client | 514 | Acquisition | 515 | | 516 +--+-----------+ +--+------------+ 517 | | AC "push" | | 518 | Client +-------------------------+ Server | 519 | | (part of app. protocol) | | 520 +--+-----------+ +--+------------+ 521 | | 522 | Client | Server 523 | Lookup +--------------+ | Lookup 524 | | | | 525 +---------------+ Repository +---------+ 526 | | 527 +--------------+ 529 Figure 2: AC Exchanges 531 3.4 Certificates 533 3.4.1 Public Key Certificates 535 ITU-T X.509 (formerly CCITT X.509) or ISO|IEC/ITU 9594-8, which was 536 first published in 1988 as part of the X.500 Directory 537 recommendations, defines a standard public key certificate format 538 [X.509]. The public key certificate format in the 1988 standard is 539 called the version 1 (v1) format. 541 When X.500 was revised in 1993, two more fields, 542 subjectUniqueIdentifier and issuerUniqueIdentifier were added, 543 resulting in the version 2 (v2) format. These two fields may be used 544 to support directory access control. 546 The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993, 547 include specifications for a public key infrastructure based on X.509 548 v1 public key certificates [PEM]. The experience gained in attempts 549 to deploy [PEM] made it clear that the v1 and v2 public key 550 certificate formats are deficient in several respects. Most 551 importantly, more fields were needed to carry information which PEM 552 design and implementation experience has proven necessary. In 553 response to these new requirements, ISO/IEC/ITU and ANSI X9 developed 554 the X.509 version 3 (v3) public key certificate format. The v3 format 555 extends the v2 format by adding provision for additional extension 556 fields. Particular extension field types may be specified in 557 standards or may be defined and registered by any organization or 558 community. In June 1996, standardization of the basic v3 format was 559 completed [X.509]. 561 ISO/IEC/ITU and ANSI X9 have also developed standard extensions for 562 use in the v3 extensions field [X.509][X9.55]. These extensions can 563 convey such data as additional subject identification information, 564 key attribute information, policy information, and certification path 565 constraints. However, the ISO/IEC/ITU and ANSI X9 standard extensions 566 are very broad in their applicability. In order to develop 567 interoperable implementations of X.509 v3 systems for Internet use, 568 it is necessary to specify a profile for use of the X.509 v3 569 extensions tailored for the Internet. It is one goal of PKIX to 570 specify a profile for Internet, electronic mail, and IPSec 571 applications, etc. Environments with additional requirements may 572 build on this profile or may replace it. 574 3.4.2 Attribute Certificates 576 ANSI X.9 first published the Attribute Certificate format in [put 577 date in here] as part of [put reference in here]. It defined the 578 standard version 1 (v1) AC format. They later created a version 2 579 (v2) AC by modifying the owner field to point to either an identity 580 or a specific PKC and including an extension mechanism. In 1997 ITU-T 581 included it in [X.509]. 583 ANSI, ITU-T, and IETF have developed standard extensions and 584 attributes for use in the v2 ACs. Extensions can convey such 585 informatoin as an audit identity that can be used to create an audit 586 trail, identity specific servers and services where the AC owner can 587 use their AC, point to a specific issuer's key, and indicate where to 588 get revocation information. The AC is generic enough to allow any 589 attribute to be conveyed in the data structure. Without limiting the 590 attributes and extensions that can be included in an AC it is very 591 difficult to develop interoperable implementations for Internet use. 592 It is the goal of PKIX to specify a profile for the Internet, 593 electronic mail, IPSec applications, etc. Environments with 594 additional requirements may build on this profile or replace it. 596 3.5 Functions of a PKI 598 This section describes the major functions of a PKI. In some cases, 599 PKIs may provide extra functions. 601 3.5.1 Registration 603 This is the process whereby a subject first makes itself known to a 604 CA (directly, or through an RA), prior to that CA issuing a PKC or 605 PKCs for that subject. Registration involves the subject providing 606 its name (e.g., common name, fully-qualified domain name, IP 607 address), and other attributes to be put in the PKC, followed by the 608 CA (possibly with help from the RA) verifying in accordance with its 609 Certification Practice Statement (CPS) that the name and other 610 attributes are correct. 612 3.5.2 Initialization 614 Initialization is when the subject (e.g., the user or client system) 615 gets the values needed to begin communicating with the PKI. For 616 example, initialization can involve providing the client system with 617 the public key or PKC of a CA, or generating the client system's own 618 public-private key pair. 620 3.5.3 Certification 622 This is the process in which a CA issues a PKC for a subject's public 623 key, and returns that PKC to the subject or posts that PKC in a 624 repository. 626 3.5.4 Key Pair Recovery 628 In some implementations, key exchange or encryption keys will be 629 required by local policy to be "backed up," or recoverable in case 630 the key is lost and access to previously-encrypted information is 631 needed. Such implementations can include those where the private key 632 exchange key is stored on a hardware token which can be lost or 633 broken, or when a private key file is protected by a password which 634 can be forgotten. Often, a company is concerned about being able to 635 read mail encrypted by or for a particular employee when that 636 employee is no longer available because she is ill or no longer works 637 for the company. 639 In these cases, the user's private key can be backed up by a CA or by 640 a separate key backup system. If a user or her employer needs to 641 recover these backed up key materials, the PKI must provide a system 642 that permits the recovery without providing an unacceptable risk of 643 compromise of the private key. 645 3.5.5 Key Generation 647 Depending on the CA's policy, the private-public key pair can either 648 be generated by the user in his local environment, or generated by 649 the CA. In the latter case, the key material may be distributed to 650 the user in an encrypted file or on a physical token (e.g., a smart 651 card or PCMCIA card). 653 3.5.6 Key Update 655 All key pairs need to be updated regularly (i.e., replaced with a new 656 key pair) and new PKCs issued. This will happen in two cases: 657 normally, when a key has passed its maximum usable lifetime; and 658 exceptionally, when a key has been compromised and must be replaced. 660 3.5.6.1 Key Expiry 662 In the normal case, a PKI needs to provide a facility to gracefully 663 transition from a PKC with an existing key to a new PKC with a new 664 key. This is particularly true when the key to be updated is that of 665 a CA. Users will know in advance that the key will expire on a 666 certain date; the PKI, working together with PKC-using applications, 667 should allow for appropriate keys to work before and after the 668 transition. There are a number of ways to do this; see [CMP] for an 669 example of one. 671 3.5.6.2 Key Compromise 673 In the case of a key compromise, the transition will not be 674 "graceful" in that there will be an unplanned switch of PKCs and 675 keys; users will not have known in advance what was about to happen. 676 Still, the PKI must support the ability to declare that the previous 677 PKC is now invalid and shall not be used, and to announce the 678 validity and availability of the new PKC. 680 Note: compromise of a private key associated with a Root CA is 681 catastrophic for users relying on that Root CA. If a Root CA's 682 private key is compromised, that CA's PKC must be revoked and all 683 PKCs subordinate to it must also be revoked. Until such time as the 684 Root CA has been issued a new PKC and the Root CA issues PKCs to 685 users relying upon it, users relying on that Root CA are cut off 686 from the rest of the system, as there is no way to develop a valid 687 certification path back to a trusted node. 689 Further, users will likely have to be notified by out-of-band 690 mechanisms about the change in CA keys. If the old key is 691 compromised, any "update" message telling subordinates to switch to a 692 new key could have come from an attacker in possession of the old 693 key, and could point to a new public key for which the attacker 694 already has the private key. It is possible to have anticipated this 695 event, and "pre-placed" replacement Root CA keys with all relying 696 parties, but some secure, out-of-band mechanism will have to be used 697 to tell users to make the switch, and this will only help if the 698 replacement key has not been compromised. 700 Additionally, once the Root CA is brought back up with a new key, it 701 will likely be necessary to re-issue PKCs, signed with the new key, 702 to all subordinate users, since their current PKC would be signed 703 with a now-revoked key. 705 3.5.7 Cross-certification 707 A cross-certificate is a PKC issued by one CA to another CA which 708 contains a public CA key associated with the private CA signature key 709 used for issuing PKCs. Typically, a cross-certificate is used to 710 allow client systems orend entities in one administrative domain to 711 communicate securely with client systems or end users in another 712 administrative domain. Use of a cross-certificate issued from CA_1 to 713 CA_2 allows user Alice, who trusts CA_1, to accept a PKC used by Bob, 714 which was issued by CA_2. Cross-certificates can also be issued from 715 one CA to another CA in the same administrative domain, if required. 717 Cross-certificates can be issued in only one direction, or in both 718 directions, between two CA's. That is, just because CA_1 issues a 719 cross-certificate for CA_2, CA_2 does not have to issue a cross- 720 certificate for CA_1. 722 3.5.8 Revocation 724 When a PKC is issued, it is expected to be in use for its entire 725 validity period. However, various circumstances may cause a PKC to 726 become invalid prior to the expiration of the validity period. Such 727 circumstances include change of name, change of association between 728 subject and CA (e.g., an employee terminates employment with an 729 organization), and compromise or suspected compromise of the 730 corresponding private key. Under such circumstances, the CA needs to 731 revoke the PKC. 733 X.509 defines one method of PKC revocation. This method involves each 734 CA periodically issuing a signed data structure called a certificate 735 revocation list (CRL). A CRL is a time stamped list identifying 736 revoked PKCs which is signed by a CA and made freely available in a 737 public repository. Each revoked PKC is identified in a CRL by its PKC 738 serial number. When a certificate-using system uses a PKC, that 739 system not only checks the PKC signature and validity but also 740 acquires a suitably-recent CRL and checks that the PKC serial number 741 is not on that CRL. The meaning of "suitably-recent" may vary with 742 local policy, but it usually means the most recently-issued CRL. A CA 743 issues a new CRL on a regular periodic basis (e.g., hourly, daily, or 744 weekly). CA's may also issue CRLs aperiodically. For example, if an 745 important key is deemed compromised, the CA may issue a new CRL to 746 expedite notification of that fact, even if the next CRL does not 747 have to be issued for some time. (A problem of aperiodic CRL issuance 748 is that end-entities may not know that a new CRL has been issued, and 749 thus may not retrieve it from a repository.) 751 An entry is added to the CRL as part of the next update following 752 notification of revocation. An entry may be removed from the CRL 753 after appearing on one regularly scheduled CRL issued beyond the 754 revoked PKC's validity period. Leaving the revoked PKC on the CRL for 755 this extra period allows for PKCs that are revoked prior to issuing a 756 new CRL and whose invalidity date falls before the CRL issuing time 757 to be accounted for. If the revoked PKC is not retained on the CRL 758 for this extra period then the possibility arises that a revoked PKC 759 may never appear on a CRL. 761 An advantage of the CRL revocation method is that CRLs may be 762 distributed by exactly the same means as PKCs themselves, namely, via 763 untrusted communications and server systems. 765 One limitation of the CRL revocation method, using untrusted 766 communications and servers, is that the time granularity of 767 revocation is limited to the CRL issue period. For example, if a 768 revocation is reported now, that revocation will not be reliably 769 notified to certificate-using systems until the next CRL is issued - 770 this may be up to one hour, one day, or one week depending on the 771 frequency that the CA issues CRLs. 773 As with the X.509 v3 PKC format, in order to facilitate interoperable 774 implementations from multiple vendors, the X.509 v2 CRL format needed 775 to be profiled for Internet use. This was done as part of [FORMAT]. 776 However, PKIX does not require CAs to issue CRLs. On-line methods of 777 revocation notification may be applicable in some environments as an 778 alternative to the X.509 CRL. PKIX defines a protocol known as OCSP 779 to facilitate on-line checking of the status of PKCs [OCSP]. 781 On-line revocation checking may significantly reduce the latency 782 between a revocation report and the distribution of the information 783 to relying parties. Once the CA accepts the report as authentic and 784 valid, any query to the on-line service will correctly reflect the 785 PKC validation impacts of the revocation. However, these methods 786 impose new security requirements; the PKC validator must trust the 787 on-line validation service while the repository does not need to be 788 trusted. 790 3.5.9 Certificate and Revocation Notice Distribution and Publication 792 As alluded to in sections 3.1 and 3.5.8 above, the PKI is responsible 793 for the distribution of PKCs and PKC revocation notices (whether in 794 CRL form or in some other form) in the system. "Distribution" of PKCs 795 includes transmission of the PKC to its owner, and may also include 796 publication of the PKC in a repository. "Distribution" of revocation 797 notices may involve posting CRLs in a repository, transmitting them 798 to end-entities, or forwarding them to on-line responders. 800 3.6 Parts of PKIX 802 This section identifies the five different areas in which the PKIX 803 working group has developed documents. The first area involves 804 profiles of the X.509 v3 PKC standards and the X.509 v2 CRL standards 805 for the Internet. The second area involves operational protocols, in 806 which relying parties can obtain information such as PKCs or PKC 807 status. The third area covers management protocols, in which 808 different entities in the system exchange information needed for 809 proper management of the PKI. The fourth area provides information 810 about certificate policies and certificate practice statements, 811 covering the areas of PKI security not directly addressed in the rest 812 of PKIX. The fifth area deals with providing time stamping and data 813 certification services, which can be used to build such services as 814 non-repudiation. 816 3.6.1 Profiles 818 An X.509 v3 PKC is a very complex data structure. It consists of 819 basic information fields, plus a number of optional extensions. Many 820 of the fields and numerous extensions can take on a wide range of 821 options. This provides an enormous degree of flexibility, which 822 allows the X.509 v3 PKC format to be used with a wide range of 823 applications in a wide range of environments. Unfortunately, this 824 same flexibility makes it extremely difficult to produce independent 825 implementations that will actually interoperate with one another. In 826 order to build an Internet PKI based on X.509 v3 PKCs, the PKIX 827 working group had to develop a profile of the X.509 v3 PKC 828 specification. 830 A profile of the X.509 v3 PKC specification is a description of the 831 contents of the PKC and which extensions must be supported, which 832 extensions may be supported, and which extensions may not be 833 supported. [FORMAT] provides such a profile of X.509 v3 PKC for the 834 Internet PKI. In addition, [FORMAT] suggests ranges of values for 835 many of the extensions. 837 [FORMAT] also provides a profile for Version 2 CRLs for use in the 838 Internet PKI. CRLs, like PKCs, have a number of optional extensions. 839 In order to promote interoperability, it is necessary to constrain 840 the choices an implementor supports. 842 In addition to profiling the PKC and CRL formats, it is necessary to 843 define particular Object Identifiers (OIDs) for certain encryption 844 algorithms, because there are a variety of OIDs registered for some 845 algorithm suites. Many of the OIDs are defined in [FORMAT] to promote 846 interoperability. Also, PKIX has produced two documents ([ECDSA] and 847 [KEA]) which provide guidance on the proper implementation of 848 specific algorithms. 850 Some countries are in a process of updating their legal frameworks in 851 order to regulate and incorporate recognition of signatures in 852 electronic form. Many of these frameworks introduce certain basic 853 requirements on PKCs, often termed Qualified Certificates, supporting 854 these types of "legal" signatures. Partly as a result of this there 855 is a need for a specific PKC profile providing standardized support 856 for certain related issues such as a common structure for expressing 857 unambiguous identities of certified subjects (unmistakable identity). 858 In December 1998, PKIX adopted as a work item the development of a 859 refinement of [RFC2459] that further profiles PKIX PKC into qualified 860 certificates. This work is reflected in [QC]. 862 Like the X.509 v3 PKC, the AC also a very complex data structure 863 consisting of basic information fields, a number of optional 864 extensions, and a virtually unlimited number of attributes. Again, 865 many of the fields, extensions, and attributes can take on a wide 866 range of options allowing an enormous degree of flexibility. In order 867 to build an Internet PMI based on ACs, the PKIX working group had to 868 develop a profile of the AC. 870 The AC profile is description of the contents of the AC, the allowed 871 and required extensions, and applicable attributes. [AC] provides 872 such a profile of the X.509 v2 AC. 874 3.6.2 Operational Protocols 876 Operational protocols are required to deliver certificates and CRLs 877 (or other certificate status information) to certificate using 878 systems. Provision is needed for a variety of different means of 879 certificate and CRL delivery, including distribution procedures based 880 on LDAP, HTTP, FTP, and X.500. Operational protocols supporting these 881 functions are defined in [FTPHTTP], [OCSP], [PKI-LDAPv2], and [PKI- 882 LDAPv3]. A limited protocol to support AC retrieval has also been 883 document in [LAAP]. 885 [DHPOP] defines a procedure for producing signatures withg the 886 Diffie-Hellman key agreement algorithm. This signature mechanism was 887 developed to support PKCS-10 certificate requests. 889 3.6.3 Management Protocols 891 Management protocols are required to support on-line interactions 892 between PKI user and management entities. For example, a management 893 protocol might be used between a CA and a client system with which a 894 key pair is associated, or between two CAs which cross-certify each 895 other. A management protocol can be used to carry user or client 896 system registration information, or a request for revocation of a 897 certificate. 899 There are two parts to a "management protocol." The first is the 900 format of the messages that will be sent, and the second is the 901 actual protocol that governs the transmission of those messages. 902 Originally, the PKIX working group developed two documents, [CRMF] 903 and certificate management message format (CMMF), that together 904 described the necessary set of message formats, and two other 905 documents, [CMP] and [CMC], that described protocols for exchanging 906 those messages. However, the message formats defined in the CMMF 907 draft were inserted into both [CMP] and [CMC], and thus the (CMMF) 908 draft has been dropped as a PKIX document. 910 [CMP-HTTP] and [CMP-TCP] were developed, after some implementation 911 experience, to update the procedure documented in [CMP] for using CMP 912 with HTTP and TCP and the transport protocols [CMP]. 914 3.6.4 Policy Outline 916 As mentioned before, profiling certificates and specifying 917 operational and management protocols only addresses a part of the 918 problem of actually developing and implementing a secure PKI. What is 919 also needed is the development of a certificate policy (CP) and 920 certification practice statement (CPS), and then following those 921 documents. The CP and CPS should address physical and personnel 922 security, subject identification requirements, revocation policy, and 923 a number of other topics. [POLPROC] provides a framework for 924 certification practice statements. 926 3.6.5 Time-Stamp, Data Verification, and Data Certification Services 928 In late 1998, the PKIX working group began two efforts that were not 929 in the original working group charter, but were deemed to be 930 appropriate because they described infrastructure services that could 931 be used to provide desired security services. The first of these is 932 time stamping, described in [TSP]. Time stamping is a service in 933 which a trusted third party - a Time Stamp Authority, or TSA - signs 934 a message, in order to provide evidence that it existed prior to a 935 given time. Time stamping provides some support for non-repudiation, 936 in that a user cannot claim that a transaction was later forged after 937 compromise of a private key, because the existence of the signed time 938 stamp indicates that the transaction in question could not have been 939 created after the indicated time. 941 [TSP] also defines the role of a Temporal Data Authority, or TDA. A 942 TDA is a Trusted Third Party (TTP) that creates a temporal data 943 token. This temporal data token associates a message with a 944 particular event and provides supplementary evidence for the time 945 included in the time stamp token. For example, a TDA could associate 946 the message with the most recent closing value of the Dow Jones 947 Average. The temporal data with which the message is associated 948 should be unpredictable in order to prevent forward dating of tokens. 949 The third iteration of the draft removed support for TDAs as no one 950 in the WG expressed a requirement for the role. 952 At the Minneapolis IETF meeting, it was disclosed that the materials 953 covered in [TSP] draft may be covered by patent(s). Use of the 954 material covered by the patent(s) in question has not be granted by 955 the patent holder. Thus, anyone interested in implementing the PKIX 956 [TSP] draft must be aware of this intellectual property issue. 958 The second new effort is the definition of a Data Validation and 959 Certification Server, or DVCS, protocol [DVCS]. A DVCS is a Trusted 960 Third Party that verifies the correctness of specific data submitted 961 to it. It also allows the delegation of trustworthy servers and 962 allows for chaining of verifications. 964 This services offered by DVCS are different from the TSP service in 965 that a TSA will not attempt to parse or verify a message sent to it 966 for certification; instead, it will merely append a reliable 967 indication of the current time, and sign the resulting string-of- 968 bits. This offers an indication that the given string-of-bits existed 969 at a specified time; it does not offer any indication of the 970 correctness or relevance of that string of bits. By contrast, the 971 DVCS certifies possession of data or the validity of another entity's 972 signature. As part of this, the DVCS verifies the mathematical 973 correctness of the actual signature value contained in the request 974 and also checks the full certification path from the signing entity 975 to a trusted point (e.g., the DVCS's CA, or the Root CA in a 976 hierarchy). 978 The DVCS supports non-repudiation in two ways. First, it provides 979 evidence that a signature or PKC was valid at the time indicated in 980 the token. The token can be used even after the corresponding PKC 981 expires and its revocation information is no longer available on CRLs 982 (for example). Second, the production of a data certification token 983 in response to a signed request for certification of another 984 signature or PKC also provides evidence that due diligence was 985 performed by the requester in validating the signature or PKC. 987 4 PKIX Documents 989 This section describes each of the documents written by the PKIX 990 working group. As PKIX progresses, this section will need to be 991 continually updated to reflect the status of each document (e.g., 992 Proposed Standard, Draft Standard, Standard, Informational Draft, 993 Informational RFC, something-that-was-just-thrown-out-for- 994 consideration, etc.). 996 4.1 Profile 998 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate 999 and CRL Profile (RFC 2459) 1001 DESCRIPTION: This document describes the profiles to be used for 1002 X.509 v3 PKCs and version 2 CRLs by Internet PKI participants. The 1003 profiles include the identification of ISO/IEC/ITU and ANSI 1004 extensions which may be useful in the Internet PKI. The profiles are 1005 presented in the 1988 Abstract Syntax Notation One (ASN.1) rather 1006 than the 1994 syntax used in the ISO/IEC/ITU standards. Would-be PKIX 1007 implementors and developers of certificate-using applications should 1008 start with [FORMAT] to ensure that their systems will be able to 1009 interoperate with other users of the PKI. 1011 [FORMAT] also includes path validation procedures. The procedures 1012 presented are based upon the ISO/IEC/ITU definition, but the 1013 presentation assumes one or more self-signed trusted CA PKCs. The 1014 procedures are provided as examples only. Implementations are not 1015 required to use the procedures provided; they may implement whichever 1016 procedures are efficient for their situation. However, 1017 implementations are required to derive the same results as the 1018 example procedures. 1020 STATUS: Proposed Standard. 1022 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure 1023 Representation of Elliptic Curve Digital Signature Algorithm (ECDSA) 1024 Keys and Signatures in Internet X.509 Public Key Infrastructure 1025 Certificates 1027 DESCRIPTION: This document provides Object Identifiers (OIDs) and 1028 other guidance for IPKI users who use the Elliptic Curve Digital 1029 Signature Algorithm (ECDSA). It profiles the format and semantics of 1030 the subjectPublicKeyInfo field and the keyUsage extension in X.509 v3 1031 PKCs containing ECDSA keys. This document should be used by anyone 1032 wishing to support ECDSA; others who do not support ECDSA are not 1033 required to comply with it. 1035 STATUS: Finished WG Last Call. 1037 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure 1038 Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 1039 Public Key Infrastructure Certificates (RFC 2528) 1041 DESCRIPTION: This document provides Object Identifiers (OIDs) and 1042 other guidance for IPKI users who use the Key Exchange Algorithm 1043 (KEA). It profiles the format and semantics of the 1044 subjectPublicKeyInfo field and the keyUsage extension in X.509 v3 1045 PKCs containing KEA keys. This document should be used by anyone 1046 wishing to support KEA; others who do not support ECDSA are not 1047 required to comply with it. 1049 STATUS: Informational RFC. 1051 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Qualified 1052 Certificates 1054 DESCRIPTION: This document profiles the format for and defines 1055 requirements on information content in a specific type of PKCs called 1056 Qualified Certificates. A "Qualified Certificate" is a PKC that is 1057 issued to a natural person (i.e., a living human being); contains an 1058 unmistakable identity based on a real name or a pseudonym of the 1059 subject; exclusively indicates non-repudiation as the key usage for 1060 the certificate's public key; and meets a number of requirements. 1062 STATUS: WG Last Call. 1064 DOCUMENT TITLE: An Internet AttributeCertificate Profile for 1065 Authorizations 1066 DESCRIPTION: This document profiles the format for an defines 1067 requirements on X.509 v2 ACs to support authorization services 1068 required by various Internet protocols (TLS, CMS, and the consumers 1069 of CMS, etc.). Two profiles are defined in support of basic 1070 authorizations and in support of services that can operate via proxy. 1072 STATUS: Under WG review. 1074 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate 1075 and CRL Profile 1077 DESCRIPTION: This document is an update of [FORMAT]. 1079 STATUS: Under WG review. 1081 DOCUMENT TITLE: A String Representation of General Name 1084 DESCRIPTION: This document specifies a string format for the ASN.1 1085 construct GeneralName. 1087 STATUS: Under WG review. 1089 4.2 Operational Protocols 1091 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Operational 1092 Protocols - LDAPv2 (RFC 2559) 1094 DESCRIPTION: This document describes the use of LDAPv2 as a protocol 1095 for PKI elements to publish and retrieve certificates and CRLs from a 1096 repository. [LDAPv2] is a protocol that allows publishing and 1097 retrieving of information. 1099 STATUS: Proposed Standard. 1101 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure LDAPv2 1102 Schema (RFC 2587) 1104 DESCRIPTION: This document defines a minimal schema necessary to 1105 support the use of LDAPv2 for PKC and CRL retrieval and related 1106 functions for PKIX. This document supplements [LDAPv2] by identifying 1107 the PKIX-related attributes that must be present. 1109 STATUS: Proposed Standard. 1111 DOCUMENT TITLE: X.509 Internet Public Key Infrastructure Online 1112 Certificate Status Protocol - OCSP (RFC 2560) 1113 DESCRIPTION: This document specifies a protocol useful in determining 1114 the current status of a certificate without the use of CRLs. A major 1115 complaint about certificate-based systems is the need for a relying 1116 party to retrieve a current CRL as part of the certificate validation 1117 process. Depending on the size of the CRL, this can cause severe 1118 problems for bandwidth-challenged devices. Depending on the frequency 1119 of CRL issuance, this can also cause timeliness problems. (E.g., if 1120 CRLs are only published weekly, with no interim releases, a 1121 certificate could actually have been revoked for just short of one 1122 week without it being on the current CRL, and thus improper use of 1123 that certificate could still be occurring.) 1125 OCSP attempts to address those problems. It provides a mechanism 1126 whereby a relying party identifies one or more certificates to an 1127 approved OCSP "responder", and the responder sends back the current 1128 status of the certificate(s) - e.g., "revoked", "notRevoked", 1129 "unknown". This can dramatically reduce the bandwidth required to 1130 transmit revocation status - a relying party does not have to 1131 retrieve a CRL of many entries to check the status of one 1132 certificate. It can (although it is not guaranteed to) improve the 1133 timeliness of revocation notification, and thus reduce the window of 1134 opportunity for someone trying to use a revoked certificate. 1136 STATUS: Proposed Standard. 1138 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Operational 1139 Protocols: FTP and HTTP (RFC 2585) 1141 DESCRIPTION: This document describes the use of the File Transfer 1142 Protocol (FTP) and the Hyper-text Transfer Protocol (HTTP) to obtain 1143 certificates and CRLs from PKI repositories. 1145 STATUS: Proposed Standard. 1147 DOCUMENT TITLE: Diffie-Hellman Proof-of-Possession Algorithms 1150 DESCRIPTION: This documents describes two signing algorithms using 1151 the Diffie-Hellman key agreement process to provide a shared secret 1152 as the basis of the signature. It allows Diffie-Hellman, a key 1153 agreement algorithm, to be used instead of requiring that the public 1154 key being requested for certification correspond to an algorithm that 1155 is capable of signing and encrypting. The first algorithm generates a 1156 signature for a specific verifier where the signer and recipient have 1157 the same public key parameters. The second algorithm generates a 1158 signature for arbitrary verifiers where the signer and recipient do 1159 not have the same public key parameters. 1161 STATUS: IETF Last Call. 1163 DOCUMENT TITLE: Limited Attribute Certificate Acquisition Protocol 1164 1166 DESCRIPTION: This document specifies a deliberately limited protocol 1167 for requesting ACs from a server. It is intended to be complementary 1168 to the use of LDAP for AC retrieval, covering those cases where use 1169 of an LDAP server is not suitable due to the type of authorization 1170 model being employed. 1172 STATUS: Under WG review. 1174 4.3 Management Protocols 1176 DOCUMENT TITLE: Certificate Management Messages over CMS 1179 DESCRIPTION: This document defines the means by which PKI clients and 1180 servers may exchange PKI messages when using S/MIME's Cryptographic 1181 Message Syntax [CMS] as a transaction envelope. CMC supports the 1182 certificate request message body specified in the Certificate Request 1183 Message Format [CRMF] documents, as well as a variety of other 1184 certificate management messages. The primary purpose of this 1185 specification is to allow the use of an existing protocol (S/MIME) as 1186 a PKI management protocol, without requiring the development of an 1187 entirely new protocol such as CMP. A secondary purpose is to codify 1188 in IETF standards the current industry practice of using PKCS-10 1189 messages [PKCS10] for certificate requests. 1191 STATUS: IETF Last Call. 1193 DOCUMENT TITLE: Internet X.509 Certificate Request Message Format 1194 (RFC 2511) 1196 DESCRIPTION: CRMF specifies a format recommended for use whenever a 1197 relying party is requesting a certificate from a CA or requesting 1198 that an RA help it get a certificate. The request message format was 1199 needed before many of the other message formats had to be finalized, 1200 and so it was put into a separate document. This document only 1201 specifies the format of a message. Specification of a protocol to 1202 transport that message is beyond the scope of CRMF. 1204 STATUS: Proposed Standard. 1206 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate 1207 Management Protocols (RFC 2510) 1209 DESCRIPTION: This document specifies a new protocol specifically 1210 developed for the purpose of transporting messages like those 1211 specified in CRMF among PKI elements. In general, CMP will be used in 1212 conjunction with CRMF, and will then be run over a transfer service 1213 (e.g., S/MIME, HTTP) to provide a complete PKI management service. 1215 STATUS: Proposed Standard. 1217 DOCUMENT TITLE: Simple Certificate Validation Protocol (SCVP) 1220 DESCRIPTION: The SCVP protocol allows a client to offload certificate 1221 handling to a server. The server can give a variety of valuable 1222 information about the certificate, such as whether or not the 1223 certificate is valid, a chain to a trusted root, and so on. 1225 STATUS: Under WG review. 1227 DOCUMENT TITLE: Using HTTP as a Transport Protocol for CMP 1230 DESCRIPTION: This document describes how to layer [CMP] over [HTTP]. 1231 A simple method for doing so is described in [CMP], but that method 1232 does not accommodate a polling mechanism, which may be required in 1233 some environments. This document specifies an alternative method 1234 which uses the polling protocol defined in [CMP]. A new Content-Type 1235 for messages is also defined. 1237 STATUS: Under WG review. 1239 DOCUMENT TITLE: Using TCP as a Transport Protocol for CMP 1242 DESCRIPTION: This document describes how to layer Certificate 1243 Management Protocols [CMP] over [TCP]. A method for doing so is 1244 described in [CMP], but that method does not solve problems 1245 encountered by implementors. This document specifies an enhanced 1246 method which extends the protocol. 1248 STATUS: Under WG review. 1250 DOCUMENT TITLE: OCSP Extensions 1252 DESCRIPTION: This document defines Internet-standard extensions to 1253 OCSP that enable a client to delegate processing of certificate 1254 acceptance functions to a trusted server. The client may control the 1255 degree to which delegation takes place. In addition limited support 1256 is provided for delegating authorization decisions. 1258 STATUS: Under WG review. 1260 DOCUMENT TITLE: Certificate Management Protocols 1263 DESCRIPTION: This document is an update of [CMP]. 1265 STATUS: Under WG review. 1267 4.4 Policy Outline 1269 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate 1270 Policy and Certification Practices Framework (RFC 2527) 1272 DESCRIPTION: As noted before, the specification and implementation of 1273 certificate profiles, operational protocols, and management protocols 1274 is only part of building a PKI. Equally as important - if not more 1275 important - is the development and enforcement of a certificate 1276 security policy, and a Certification Practice Statement (CPS). The 1277 purpose of this document (PKIX-4) is to establish a clear 1278 relationship between certificate policies and CPSs, and to present a 1279 framework to assist the writers of certificate policies or CPSs with 1280 their tasks. In particular, the framework identifies the elements 1281 that may need to be considered in formulating a certificate policy or 1282 a CPS. The purpose is not to define particular certificate policies 1283 or CPSs, per se. 1285 STATUS: Informational RFC. 1287 4.5 Time-Stamp, Data Validation, and Data Certification Services 1289 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Time Stamp 1290 Protocols 1292 DESCRIPTION: This document defines the specification for a time stamp 1293 service. It defines a Time Stamp Authority, or TSA, a trusted third 1294 party who maintains a reliable time service. When the TSA receives a 1295 time stamp request, it appends the current time to the request and 1296 signs it into a token to certify that the original request existed 1297 prior to the indicated time. This helps provide non-repudiation by 1298 preventing someone (either a legitimate user or an attacker who has 1299 successfully compromised a key) from "back-dating" a transaction. It 1300 also makes it more difficult to challenge a transaction by asserting 1301 that it has been back-dated. Note that the TSA does not provide any 1302 data parsing service; that is, the TSA does not attempt to validate 1303 that which it signs; it merely regards it as a string of bits whose 1304 meaning is unimportant, but existence is vital. 1306 STATUS: In WG Last. 1308 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Data 1309 Certification Server Protocols 1311 DESCRIPTION: This document defines a data validation and 1312 certification service, or DVCS, which can be used to certify both the 1313 existence and correctness of a message or signature. In contrast to 1314 the time stamp service described above, the DVCS certifies possession 1315 of data or the validity of another entity's signature. As part of 1316 this, the DVCS verifies the mathematical correctness of the actual 1317 signature value contained in the request and also checks the full 1318 certification path from the signing entity to a trusted point (e.g., 1319 the DVCS's CA, or the Root CA in a hierarchy). 1321 The DVCS supports non-repudiation in two ways. First, it provides 1322 evidence that a signature or public key certificate was valid at the 1323 time indicated in the token. The token can be used even after the 1324 corresponding public key certificate expires and its revocation 1325 information is no longer available on CRLs (for example). Second, the 1326 production of a data certification token in response to a signed 1327 request for certification of another signature or public key 1328 certificate also provides evidence that due diligence was performed 1329 by the requester in validating the signature or public key 1330 certificate. 1332 STATUS: Under WG review. 1334 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Technical 1335 Requirements for a non-Repudiation Service 1338 DESCRIPTION: This document describes those features of a service 1339 which processes signed documents which must be present in order for 1340 that service to constitute a "technical non-repudiation" service. A 1341 technical non-repudiation service must permit an independent verifier 1342 to determine whether a given signature was applied to a given data 1343 object by the private key associated with a given valid certificate, 1344 at a time later than the signature. The features of a technical non- 1345 repudiation service are expected to be necessary for a full non- 1346 repudiation service, although they may not be sufficient. 1348 This document is intended to clarify the definition of the "non- 1349 repudiation" service in RFC 2459. It should thus serve as a guide to 1350 when the nonRepudiation bit of the keyUsage extension should be set 1351 and to when a Certificate Authority is required to archive CRL's. 1353 STATUS: Under WG Review. 1355 4.6 Expired Documents 1357 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate 1358 Management Message Formats 1360 DESCRIPTION: This document contains the formats for a series of 1361 messages important in certificate and PKI management. These messages 1362 let CA's, RA's, and relying parties communicate with each other. Note 1363 that this document only specifies message formats; it does not 1364 specify a protocol for transferring messages. That protocol can be 1365 either CMP or CMC, or perhaps another custom protocol. 1367 STATUS: Work has been discontinued. All useful information from it 1368 has been moved into [CMP] and [CMC]. 1370 DOCUMENT TITLE: WEB based Certificate Access Protocol-- WebCAP/1.0 1372 DESCRIPTION: This document specifies a set of methods, headers, and 1373 content-types ancillary to HTTP/1.1 to publish, retrieve X.509 1374 certificates and Certificate Revocation Lists. This protocol also 1375 facilitates determining current status of a digital certificate 1376 without the use of CRLs. This protocol defines new methods, request 1377 and response bodies, error codes to HTTP/1.1 protocol for securely 1378 publishing, retrieving, and validating certificates across a 1379 firewall. 1381 STATUS: Expired. 1383 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Enhanced CRL 1384 Distribution Options (OpenCDP) 1386 DESCRIPTION: This document proposes an alternative to the CRL 1387 Distribution Point (CDP) approach documented in [FORMAT]. OCDP 1388 separates the CRL location function from the process of certificate 1389 and CRL validation, and thus claims some benefits over the CDP 1390 approach. 1392 STATUS: Work has been discontinued, as all useful information has 1393 been incorporated into [X.509]. An updated [FORMAT] RFC should 1394 profile the use of the CDP approach. 1396 DOCUMENT TITLE: Internet Public Key Infrastructure: Caching the 1397 Online Certificate Status Protocol 1399 DESCRIPTION: To improve the degree to which it can scale, OCSP allows 1400 caching of responses - e.g., at intermediary servers, or even at the 1401 relying party's end system. This document describes how to support 1402 OCSP caching at intermediary servers. 1404 STATUS: Work has been discontinued. 1406 DOCUMENT TITLE: Basic Event Representation Token 1409 DESCRIPTION: This document defines a finite method of representing a 1410 discrete instant in time as a referable event. The Basic Event 1411 Representation Token (BERT) is a light-weight binary token designed 1412 for use in large numbers over short periods of time. The tokens 1413 contain only a single instance of an event stamp and the trust 1414 process is referenced against an external reference. 1416 STATUS: Expired. 1418 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Extending 1419 trust in non repudiation tokens in time 1422 DESCRIPTION: This document describes a method to maintain the trust 1423 in a token issued by a non-repudiation Trusted Third Party (NR TTP) 1424 (DVCS/TSA/TDA) after the key initially used to establish trust in the 1425 token expires. The document describes a general format for storage of 1426 DVCS/TS/TDA tokens for this purpose, which establishes a chain of 1427 custody for the data. 1429 STATUS: Expired. 1431 5 Advice to Implementors 1433 This section provides guidance to those who would implement various 1434 parts of the PKIX suite of documents. The topics discussed in this 1435 section engendered significant discussion in the working group, and 1436 there, was at times, either widespread disagreement or widespread 1437 misunderstanding of them. Thus, this discussion is provided to help 1438 readers of the PKIX document set understand these issues, in the hope 1439 of fostering greater interoperability among eventual PKIX 1440 implementations. 1442 5.1 Names 1444 PKIX has been referred to as a "name-centric" PKI because the PKCs 1445 associate public keys with names of entities. Each PKC contains at 1446 least one name for the owner of a particular public key. The name can 1447 be an X.500 distinguished name, contained in the subjectDN field of 1448 the PKC. There can also be names such as RFC822 e-mail addresses, DNS 1449 domain names, and uniform resource identifiers (URIs) associated with 1450 the key; these attributes are kept in the subjectAltName extension of 1451 the PKC. A PKC must contain at least one of these name forms, it may 1452 contain multiple forms if deemed appropriate by the CA based on the 1453 intended usage of the PKC. 1455 5.1.1 Name Forms 1457 There are two possible places to put a name in an X.509 v3 PKC. One 1458 is the subject field in the base PKC (often called the "Distinguished 1459 Name" or "DN" field), and the other is in the subjectAltName 1460 extension. 1462 5.1.1.1 Distinguished Names 1463 According to [FORMAT], a CA's PKC must have a non-null value in the 1464 subject field, while EE's PKCs are permitted to have an empty subject 1465 field. If a PKC has a non-null subject field, it MUST contain an 1466 X.500 Distinguished Name. 1468 5.1.1.2 SubjectAltName Forms 1470 In addition to the DN, a PKIX PKC may have one or more values in the 1471 subjectAltName extension. 1473 The subjectAltName extension allows additional identities to be bound 1474 to the subject of the PKC (e.g., it allows "umbc.edu" and 1475 "130.85.1.3" to be associated with a particular subject, as well as 1476 "C=US, O=University of Maryland, L=Baltimore, CN=UMBC"). 1477 X.509-defined options for this extension include: Internet electronic 1478 mail addresses; DNS names; IP addresses; and URIs. Other options can 1479 exist, including locally-defined name forms. 1481 A single subjectAltName extension can include multiple name forms, 1482 and multiple instances of each name form. 1484 Whenever such alternate name forms are to be bound into a PKC, the 1485 subjectAltName (or issuerAltName) extension must be used. It is 1486 technically possible to embed an alternate name form in the subject 1487 field. For example, one could make a DN contain an IP address via a 1488 kludge such as "C=US, L=Baltimore, CN=130.85.1.3". However, this 1489 usage is deprecated; the alternative name extension is the preferred 1490 location for finding such information. As another example, some 1491 legacy implementations exist where an RFC822 name is embedded in the 1492 subject distinguished name as an EmailAddress attribute. Per 1493 [FORMAT], PKIX-compliant implementations generating new PKCs with 1494 electronic mail addresses MUST use the rfc822Name in the 1495 subjectAltName extension to describe such EEs. Simultaneous inclusion 1496 of the EmailAddress attribute in the subject distinguished name to 1497 support legacy implementation is deprecated but permitted. 1499 In line with this, if the only subject identity included in a PKC is 1500 an alternative name form, then the subject distinguished name must be 1501 empty (technically, an empty sequence), and the subjectAltName 1502 extension must be present. If the subject field contains an empty 1503 sequence, the subjectAltName extension must be marked critical. 1505 If the subjectAltName extension is present, the sequence must contain 1506 at least one entry. Unlike the subject field, conforming CAs shall 1507 not issue PKCs with subjectAltNames containing empty GeneralName 1508 fields. For example, an rfc822Name is represented as an IA5String. 1509 While an empty string is a valid IA5String, such an rfc822Name is not 1510 permitted by PKIX. The behavior of clients that encounter such a PKC 1511 when processing a certification path is not defined by this working 1512 group. 1514 Because the subject's alternative name is considered to be 1515 definitively bound to the public key, all parts of the subject's 1516 alternative name must be verified by the CA. 1518 5.1.1.2.1 Internet e-mail addresses 1520 When the subjectAltName extension contains an Internet mail address, 1521 the address is included as an rfc822Name. The format of an rfc822Name 1522 is an "addr-spec" as defined in [RFC-822]. An addr-spec has the form 1523 local-part@domain; it does not have a phrase (such as a common name) 1524 before it, or a comment (text surrounded in parentheses) after it, 1525 and it is not surrounded by "<" and ">". 1527 5.1.1.2.2 DNS Names 1529 When the subjectAltName extension contains a domain name service 1530 label, the domain name is stored in the dNSName attribute(an 1531 IA5String). The string shall be in the "preferred name syntax," as 1532 specified by [DNS]. Note that while upper and lower case letters are 1533 allowed in domain names, no significance is attached to the case. In 1534 addition, while the string " " is a legal domain name, subjectAltName 1535 extensions with a dNSName " " are not permitted. Finally, the use of 1536 the DNS representation for Internet mail addresses (wpolk.nist.gov 1537 instead of wpolk@nist.gov) is not permitted; such identities are to 1538 be encoded as rfc822Name. 1540 5.1.1.2.3 IP addresses 1542 When the subjectAltName extension contains an iPAddress, the address 1543 shall be stored in the octet string in "network byte order," as 1544 specified in [IP]. The least significant bit (LSB) of each octet is 1545 the LSB of the corresponding byte in the network address. For IP 1546 Version 4, as specified in [IP], the octet string must contain 1547 exactly four octets. For IP Version 6, as specified in [IPv6], the 1548 octet string must contain exactly sixteen octets. 1550 5.1.1.2.4 URIs 1552 [FORMAT] notes "When the subjectAltName extension contains a URI, the 1553 name MUST be stored in the uniformResourceIdentifier (an IA5String). 1554 The name MUST be a non-relative URL, and MUST follow the URL syntax 1555 and encoding rules specified in [RFC 1738]. The name must include 1556 both a scheme (e.g., "http" or "ftp") and a scheme-specific-part. The 1557 scheme-specific-part must include a fully qualified domain name or IP 1558 address as the host. As specified in [RFC 1738], the scheme name is 1559 not case-sensitive (e.g., "http" is equivalent to "HTTP"). The host 1560 part is also not case-sensitive, but other components of the scheme- 1561 specific-part may be case-sensitive. When comparing URIs, conforming 1562 implementations MUST compare the scheme and host without regard to 1563 case, but assume the remainder of the scheme-specific-part is case 1564 sensitive." 1566 5.1.2 Scope of Names 1568 The original X.500 work presumed that every subject in the world 1569 would have a globally-unique distinguished name. Thus, every subject 1570 could be easily located, and there would never be a conflict. All 1571 that would be needed is a sufficiently-large name space, and rules 1572 for constructing names based on subordination and location. 1574 Obviously, that is not practical in the real world, for a variety of 1575 reasons. There is no single entity in the world trusted by everybody 1576 to reside at the top of the name space, and there is no way to 1577 enforce uniqueness on names for all entities. (These were among the 1578 reasons for the failure of PEM to be widely implemented.) 1580 This does not mean, however, that a name-based PKI cannot work. It is 1581 important to recognize that the scope of names in PKIX is local; they 1582 need to be defined and unique only within their own domain. 1584 Suppose for example that a Top CA is established with DN "O=IETF, 1585 OU=PKIX, CN=PKIX_CA". That CA will then issue PKCs for subjects 1586 subordinate to it. The only requirement, which can be enforced 1587 procedurally, is that no two distinct entities beneath this Top CA 1588 have the same name. We can't prevent somebody else in the world from 1589 creating her own CA, called "O=IETF, OU=PKIX, CN=PKIX_CA", and it is 1590 not necessary to do so. Within the domain of the original Top CA, 1591 there will be no conflict, and the fact that there is another CA of 1592 the same name in some other domain is irrelevant. 1594 This is analogous to the current DNS or IP address situations. On the 1595 Internet, there is only one node called www.ietf.org. The fact that 1596 there might be 10 different intranets, each with a host given the DNS 1597 name www.ietf.org, is irrelevant and causes no interoperability 1598 problems - those are different domains. However, if there were to be 1599 another node on the Internet with domain name www.ietf.org, then 1600 there would be a problem due to name duplication. 1602 The same applies for IP addresses. As long as only one node on the 1603 Internet responds to the IP address 130.85.1.3, there is no problem, 1604 despite the fact that there are 100 different corporate Intranets, 1605 each using that same IP address. However, if two different nodes on 1606 the Internet each responded to the IP address 130.85.1.3, there would 1607 be a problem. 1609 5.1.3 Certificate Path Construction 1611 Certificate path construction has been the topic of many discussions 1612 in the WG. The issue centered around how best to get a certificate 1613 when the connection between the subject's name and the name of their 1614 CA, as well as the CA's repository (or directory), may not be 1615 obvious. Many proposals were put forth, including implementing a 1616 global X.500 Directory Service, using DNS SRV records, and using an 1617 extension to point to the directory provider. At the end of the 1618 discussion the group decided to use the authority information access 1619 extension defined in [FORMAT], which allows the CA to indicate the 1620 access method and location of CA information and services. The 1621 extension would be included in subject's certificates and could be 1622 used to associate an Internet style identity for the location of 1623 repository to retrieve the issuer's certificate in cases where such a 1624 location is not related to the issuer's name. 1626 Another discussion related to certificate path construction was where 1627 to store the CA and EE PKCs in the directory (specifically LDAPv2 1628 directories). Two camps emerged with different views on where to 1629 store CA and cross-certificates. In the CA's directory entry, one 1630 camp wanted self-issued PKCs stored in the cACertificate attribute, 1631 PKCs issued to this CA stored in the forward element of the 1632 crossCertificatePair, and PKCs issued from this CA for other CAs in 1633 the reverse element of the crossCertificatePair attribute. The other 1634 camp wanted all CA PKCs stored in the cACertificate attribute, and 1635 PKCs issued to and from another domain stored in the 1636 crossCertificatePair attribute. There was a short discussion that the 1637 second was more efficient than first, and that one solution or the 1638 other was more widely deployed. The end result was to indicate that 1639 self-issued PKCs and PKCs issued to the CA by CAs in the same domain 1640 as the CA are stored in the cACertificate attribute. The 1641 crossCertificatePair attribute's forward element will include all but 1642 self-issued PKCs issued to the CA. The reverse element may include a 1643 subset of PKCs issued by the CA to other CAs. With this resolution 1644 both camp's implementations are supported and are free to chose the 1645 location of CA PKCs to best support their implementation. 1647 5.1.4 Name Constraints 1649 A question that has arisen a number of times is "how does one enforce 1650 Name constraints when there is more than one name form in a PKC?" 1651 That is, [FORMAT] states that: 1653 Subject's alternative names may be constrained in the same manner 1654 as subject distinguished names using the name constraints extension 1655 as described in section 4.2.1.11. 1657 What does this mean? Suppose that there is a CA with DN "O=IETF, 1658 OU=PKIX, CN=PKIX_CA", with the subjectAltName extension having 1659 dNSName "PKIX_CA.IETF.ORG". Suppose that that CA has issued a PKC 1660 with an empty DN, with subjectAltName extension having dNSName set to 1661 "PKIX_CA.IETF.ORG", and rfc822Name set to Steve@PKIX_CA.IETF.ORG. The 1662 question is, are name constraints enforced on these two PKCs - is the 1663 name of the EE PKC considered to be properly subordinate to the name 1664 of the CA? 1666 The answer is "yes". The general rules for deciding whether a PKC 1667 meets name constraints are: 1669 - If a PKC complies with name constraints in any one of its name 1670 forms, then the PKC is deemed to comply with name constraints. 1672 - If a PKC contains a name form that its issuer does not, the PKC 1673 is deemed to comply with name constraints for that name form. 1675 In deciding whether a name form meets name constraints, the following 1676 rules apply (in all cases Name B is the name in the name constraints 1677 extension): 1679 5.1.4.1 rfc822Names 1681 Three variations are allowed: 1683 - If the name constraint is specified as "larry@mail.mit.edu", then 1684 Name A is subordinate to Name B (in B's subtree) if Name A 1685 contains all of Name B's name (specifies a particular mailbox). 1686 For example, larry@mail.mit.edu is subordinate, but 1687 larry_sanders@mail.mit.edu is not. 1689 - If the name constraint is specified as "mail.mit.edu", then Name 1690 A is subordinate to Name B (in B's subtree) if Name A contains 1691 all of Name B's name (specified all mailboxes on host 1692 mail.mit.edu). For example, curly@mail.mit.edu and 1693 mo@mail.mit.edu are subordinate, but mo@mail6.mit.edu and 1694 curly@smtp.mail.mit.edu are not. 1696 - If the name constraint is specified as ".mit.edu", then Name A is 1697 subordinate to Name B (in B's subtree) if Name A contains all of 1698 Name B's name, with the addition of zero or more additional host 1699 or domain names to the left of Name B's name. That is, 1700 smtp.mit.edu is subordinate to .mit.edu, as is pop.mit.edu. 1702 However, mit.edu is not subordinate to .mit.edu. When the 1703 constraint begins with a "." it specifies any address within a 1704 domain. In the previous example, "mit.edu" is not in the domain 1705 of ".mit.edu". 1707 Note: If rfc822 names are constrained, but the PKC does not contain a 1708 subjectAltName extension, the EmailAddress attribute will be used to 1709 constrain the name in the subject distinguished name. For example (c 1710 is country, o is organization, ou is organizational unit, and em is 1711 EmailAddress), Name A ("c=US, o=MIT, ou=CS, em=curly@mail.mit.edu") 1712 is subordinate to Name B ("c=US, o=MIT, ou=CS") (in B's subtree) if 1713 Name A contains all of Name B's names. 1715 5.1.4.2 dNSNames 1717 Name A is subordinate to Name B (in B's subtree) if Name A contains 1718 all of Name B's name, with the addition of zero or more additional 1719 domain names to the left of Name B's name. That is, www.mit.edu is 1720 subordinate to mit.edu, as is larry.cs.mit.edu. However, www.mit.edu 1721 is not subordinate to web.mit.edu. 1723 5.1.4.3 x.400 addresses 1725 Name A is subordinate to Name B (in B's subtree) if Name A contains 1726 all of Name B's name. For example (c is country-name, admd is 1727 administrative-domain-name, and o is organization-name, ou is 1728 organizational-unit-name, pn is personal-name, sn=surname, and gn is 1729 given-name in both Name A and B), the mnemonic X.400 address (using 1730 PrintableString choices for c and admd) "c=US, admd=AT&T, o=MIT, 1731 ou=cs, pn='sn=Doe,gn=John'" is subordinate to "c=US, admd=AT&T, 1732 o=MIT, ou=cs" and "c=US, admd=AT&T, o=MIT, pn='sn=DOE,gn=JOHN'" (pn 1733 is a SET that includes, among other things, sn and gn). 1735 5.1.4.5 DNs 1737 Name A is subordinate to Name B (in B's subtree), if Name A contains 1738 all of Name B's name, treating attribute values encoded in different 1739 types as different strings, ignoring case in PrintableString (in all 1740 other types case is not ignored), removing leading and trailing white 1741 space in PrintableString, and converting internal substrings of one 1742 or more consecutive white space characters to a single space. For 1743 example, (c is country, o is organization, ou is organizational unit, 1744 and cn is common name): 1746 - Assuming PrintableString types for all attribute values in Name A 1747 and B, "c=US, o=MIT, ou=CS" is subordinate to "c=us, o=MIT, 1748 ou=cs", as is "c=US, o=MIT, ou=CS, ou=administration". Another 1749 example, "c=US, o=MIT, ou=CS, cn= John Doe" (note the white 1750 spaces) is subordinate to "c=US, o=MIT, ou=CS, cn=John Doe". 1752 - Assuming UTF8String types for all attribute values in Name A and 1753 B, "c=US, o=MIT, ou=CS, ou=administration" is subordinate to 1754 "c=US, o=MIT, ou=CS", but "c=US, o=MIT, ou=cs, 1755 ou=Administration". "c=US, o=MIT, ou=CS, cn= John Smith" (note 1756 the white spaces) is not subordinate to "c=US, o=MIT, ou=CS, cn= 1757 John Smith". 1759 - Assuming UTF8String types for all attribute values in Name A and 1760 PrintableString types for all attribute values in Name B, "c=US, 1761 o=MIT, ou=cs" is subordinate to "c=US, o=MIT, ou=CS" if the 1762 verification software supports the full comparison algorithm in 1763 the X.500 series. "c=US, o=MIT, ou=cs" is NOT subordinate to 1764 "c=US, o=MIT, ou=CS" if the verification software supports the 1765 comparison algorithm in [FORMAT]. 1767 5.1.4.6 URIs 1769 The constraints apply only to the host part of the name. Two 1770 variations are allowed: 1772 - If the name constraint is specified as ".mit.edu", then Name A is 1773 subordinate to Name B (in B's subtree) if Name A contains all of 1774 Name B's name, with the addition of zero or more additional host 1775 or domain names to the left of Name B's name. That is, 1776 www.mit.edu is subordinate to .mit.edu, as is curly.cs.mit.edu. 1777 However, mit.edu is not subordinate to .mit.edu. When the 1778 constraint begins with a "." it specifies a host. 1780 - If the name constraint is specified as "abc.mit.edu", then Name A 1781 is subordinate to Name B (in B's subtree) if Name A contains all 1782 of Name B's name. No leftward expansion of the host or domain 1783 name is allowed. 1785 5.1.4.7 iPaddresses 1787 Two variations are allowed depending on the IP version: 1789 - For IPv4 addresses: Name A (128.32.1.1 encoded as 80 20 01 01) is 1790 subordinate to Name B (128.32.1.0/255.255.255.0 encoded as 80 20 1791 00 00 FF FF FF 00) (in B's subtree) if Name A falls within the 1792 net denoted in Name B's CIDR notation. 1794 - For IPv6 addresses: Name A (4224.0.0.0.8.2048.8204.16762 encoded 1795 as 10 80 00 00 00 00 00 00 00 08 08 00 20 0C 41 7A) is 1796 subordinate to Name B (4224.0.0.0.8.2048.8204.0/ 1797 65535.65535.65535.65535.65535.65535.65535.0 encoded as 10 80 00 1798 00 00 00 00 00 00 08 08 00 20 0C 00 00 FF FF FF FF FF FF FF FF FF 1799 FF FF FF FF FF 00 00) (in B's subtree) if Name A falls within the 1800 net denoted in Name B's CIDR notation. 1802 5.1.4.8 Others 1804 As [FORMAT] does not define requirements for the name forms 1805 otherName, ediPartyName, or registeredID there are no corresponding 1806 name constraints requirements. 1808 5.1.5 Wildcards in Name Forms 1810 A "wildcard" in a name form is a placeholder for a set of names 1811 (e.g., "*.mit.edu" meaning "any domain name ending in .mit.edu", and 1812 *@aol.com meaning "email address that uses aol.com"). There are many 1813 people who believe that allowing wildcards in name forms in PKIX PKCs 1814 would be a useful thing to do, because it would allow a single PKC to 1815 be used by all members of a group. These members would presumably 1816 have attributes in common; e.g., access rights to some set of 1817 resources, and so issuance of a PKC with a wildcard for the group 1818 would simplify management. 1820 After much discussion, the PKIX working group decided to permit the 1821 use of wildcards in PKCs. That is, it is permissible for a PKIX- 1822 conformant CA to issue a PKC with a wildcard. However, the semantics 1823 of subjectAltName extension that include wildcard characters are not 1824 addressed by PKIX. Applications with specific requirements may use 1825 such names but must define the semantics. 1827 5.1.6 Name Encoding 1829 A very important topic that consumed much of the WG's time was the 1830 implementation of the directory string choices. While the long term 1831 goal of the IETF was clear, use UTF8String, the short term goals were 1832 not so clear. Many implementations only use PrintableString, others 1833 use BMPString, and still others use Latin1String (ISO 8859-1) and tag 1834 it as TeletexString (there are others still). To ensure that there is 1835 consistency with encodings [FORMAT] defines a set of rules for the 1836 string choices. PrintableString was kept as the first choice because 1837 of it's widespread support by vendors. BMPString was the second 1838 choice, also for it's widespread vendor support. Failing support by 1839 PrintableString and BMPString, UTF8String must be used. In keeping 1840 with the IETF mandate, UTF8String can be used at any time if the CA 1841 supports it. Also, processing implementations that wish to support 1842 TeletexString should handle the entire ISO 8859-1 character set and 1843 not just the Latin1String subset. 1845 5.1.7 Uniqueness 1847 [Add text in here about the QC uniqueness issues.] 1849 5.2 POP 1851 Proof of Possession, or POP, or also CA POP, means that the CA is 1852 adequately convinced that the entity requesting a PKC containing a 1853 public key Y has access to the private key X corresponding to that 1854 public key. 1856 There has been some debate whether POP was or not needed. 1858 This question needs to be addressed separately considering the 1859 context of use of the key, in particular whether a key is used for an 1860 authentication or non repudiation service, or in a confidentiality 1861 service. Note that this does not map to the key usage bit directly, 1862 since it is possible to use a confidentiality key to perform an 1863 authentication service, e.g. by asking to decrypt an encrypted 1864 challenge. 1866 5.2.1 POP for Signing Keys 1868 It is important to provide POP for keys used to sign material, in 1869 order to provide non-repudiation of transactions. For example, 1870 suppose Alice legitimately has private key X and its corresponding 1871 public key Y. Alice has a PKC from Charlie, a CA, containing Y. Alice 1872 uses X to sign a transaction T. Without POP, Mal could also get a PKC 1873 from Charlie containing the same public key, Y. Now without POP, 1874 there are two possible threats: Mal could claim to have been the real 1875 signer of T; or Alice can falsely deny signing T, claiming that it 1876 was instead Mal. Since no one can reliably prove that Mal did or did 1877 not ever possess X, neither of these claims can be refuted, and thus 1878 the service provided by and the confidence in the PKI has been 1879 defeated. (Of course, if Mal really did possess X, Alice's private 1880 key, then no POP mechanism in the world will help, but that is a 1881 different problem.) 1883 Protection can be gained by having Alice, as the true signer of the 1884 transaction, include in the signed information her PKC or an 1885 identifier of her PKC (e.g., a hash of her PKC). This makes 1886 impossible for Mal to claim authorship because he does not know the 1887 private key from Alice and thus is unable to include his certificate 1888 under the signature. 1890 The adequate protection may be obtained in the general case, by 1891 mandating the inclusion of a reference of the certificate every time 1892 a signature (or non repudiation) key is being used in a protocol. 1894 However, because all the protocols were not doing so, a conservative 1895 measure has been taken by requesting POP to be performed by CAs. It 1896 should thus be understood, that this measure is not strictly 1897 necessary and is only a temporary measure to make old protocols 1898 secure. New protocols or data formats are being developed. If the key 1899 being used is always used in a context where the identifier of the 1900 certificate is included in the protocol, then POP by the CA is not 1901 necessary. The inclusion of the identifier of the certificate in the 1902 protocol or data format may be understood as POP being performed at 1903 the transaction time rather than by the CA, at the registration time 1904 of the user in the PKI. 1906 5.2.2 POP for Key Management Keys 1908 Suppose that Al is a new instructor in the Computer Science 1909 Department of a local University. Al has created a draft final exam 1910 for the Introduction to Networking course he is teaching. He wants to 1911 send a copy of the draft final to Dorothy, the Department Head, for 1912 her review prior to giving the exam. This exam will of course be 1913 encrypted, as several students have access to the computer system. 1914 However, a quick search of the PKC repository (e.g., search the 1915 repository for all records with subjectPublicKey=Dorothy's-value) 1916 turns up the fact that several students have PKCs containing the same 1917 public key management key as Dorothy. At this point, if no POP has 1918 been done by the CA, Al has no way of knowing whether all of the 1919 students have simply created these PKCs without knowing the 1920 corresponding private key (and thus it is safe to send the encrypted 1921 exam to Dorothy), or whether the students have somehow acquired 1922 Dorothy's private key (and thus it is certainly not safe to send the 1923 exam). 1925 The later case may seem unsafe. However, if the other students have 1926 acquired the key, they do not even need to publish their certificates 1927 and can simply decrypt in parallel. 1929 The end story is that, if the key only known to Dorothy, there is no 1930 problem. Thus POP by the CA is not needed. 1932 If the key, like a Diffie-Hellman key, is used for an authentication 1933 service the answer depends from the protocol being used. In the 1934 former example, the decryption was done locally and no data was sent 1935 back on the wire. In an authentication protocol, the story is 1936 different because either some encrypted or decrypted data is sent 1937 back. If the data sent back contains the identifier of the 1938 certificate in a way that it cannot be modified without that 1939 modification being detected, then there is no need for POP. On the 1940 contrary, POP by the CA is needed. 1942 As a conservative measure, POP for encryption keys is recommended, 1943 but it should be realized that it is not always needed. 1945 In general it should be noticed that POP at the time of the 1946 transaction is much superior than POP made by the CA, since it is 1947 possible in real time to be sure that everything is correct, rather 1948 than rely on that verification to be done at the time of registration 1949 by the CA. Should the CA fail in that verification, then there is a 1950 security breach. On the contrary, doing POP at the time of the 1951 transaction, eliminates that problem. 1953 CMP requires that POP be provided for all keys, either through on- 1954 line or out-of-band means. There are any number of ways to provide 1955 POP, and the choice of which to use is a local matter. Additionally, 1956 a PKC requester can provide POP to either a CA or to an RA, if the RA 1957 can adequately assure the CA that POP has been performed. Some of the 1958 acceptable ways to provide POP include: 1960 - Out-of-band means: 1962 - For keys generated by the CA or an RA (e.g., on a token such as 1963 a smart card or PCMCIA card), possession of the token can 1964 provide adequate proof of possession of the private key. 1966 - For user-generated keys, another approach can be used in 1967 environments where "key recovery" requirements force the 1968 requester to provide a copy of the private key to the CA or an 1969 RA. In this case, the CA will not issue the requested PKC until 1970 such time as the requester has provided the private key. This 1971 approach is in general not recommended, as it is extremely 1972 risky (e.g., the system designers need to figure out a way to 1973 protect the private keys from compromise while they are being 1974 sent to the CA/RA/other authority, and how to protect them 1975 there), but it can be used. 1977 - On-line means: 1979 - For signature keys that are generated by an EE, the requester 1980 of a PKC can be required to sign some piece of data (typically, 1981 the PKC request itself) using the private key. The CA will then 1982 use the requested public key to verify the signature. If the 1983 signature verification works, the CA can safely conclude that 1984 the requester had access to the private key. If the signature 1985 verification process fails, the CA can conclude that the 1986 requester did not have access to the correct private key, and 1987 reject the request. 1989 - For key management keys that are generated by the requester, 1990 the CA can send the user the requested public key, along with 1991 the CA's own public key, to encrypt some piece of data, and 1992 send it to the requester to be decrypted. For example, the CA 1993 can generate some random challenge, and require some action to 1994 be taken after decryption (e.g., "decrypt this encrypted random 1995 number and send it back to me"). If the requester does not take 1996 the requested action, the CA concludes that the requester did 1997 not possess the private key, and the PKC is not issued. 1999 Another method of providing POP for key management keys is for the CA 2000 to generate the requested PKC, and then send it to the requester in 2001 encrypted form. If the requester does not have access to the 2002 appropriate private key, the requester cannot decrypt the PKC, and 2003 thus cannot use it. After some period of time in which the PKC is not 2004 used, the CA will revoke the PKC. (This only works if the PKC is not 2005 made available to any untrusted entities until after the requester 2006 has successfully decrypted it.) 2008 5.3 Key Usage Bits 2010 The key usage extension defines the purpose (e.g., encipherment, 2011 signature, certificate signing) of the key contained in the PKC. This 2012 extension is used when a key that could be used for more than one 2013 operation is to be restricted. For example, if a CA's RSA key should 2014 be used only for signing CRLS, the cRLSign bit would be asserted. 2015 Likewise, when an RSA key should be used only for key management, the 2016 keyEncipherment bit would be asserted. When used, this extension 2017 should be marked critical. 2019 [FORMAT] includes some text for how the bits in the KeyUsage type are 2020 used. Developing the text for some of the bits was easy; however, 2021 many discussions were needed to arrive at a common agreement on the 2022 meaning of the digitalSignature (DS bit) and nonRepudiation (NR bit) 2023 bits and when they should be set. The group quickly realized that key 2024 usage extension mixes services and mechanisms. The DS bit indicates a 2025 mechanism - a public key used to verify a digital signature. The NR 2026 bit indicates a service - a public key used to verify a digital 2027 signature and to provide a non-repudiation service. When trying to 2028 indicate when each bit should be indicated arguments were based on: 2030 - The lifetime of the object being singed. Some felt that the DS 2031 bit should be set when the certificate is used to sign ephemeral 2032 objects (e.g., bind tokens) while the NR bit should be set for 2033 things that are survive longer (e.g., documents). Of course, the 2034 problem with this distinction to determine how long is the time 2035 period for ephemeral? 2037 - A concious act taken by the signer. Many felt that the NR bit 2038 should be set only when the subject has expressly acknowledged 2039 that they want to use the private key to sign an object. Signing 2040 a document say where there is a concious decision by the subject 2041 would be appropriate for the key usage extension to contain NR, 2042 but when the key is used for authentication purposes, which can 2043 occur automically and more frequently, the DS bit is more 2044 appropriate. The discussion also concluded that since some 2045 authentication schemes occur automatically, that the DS bit and 2046 NR bit should never be set together in the same certificate. Some 2047 agreed to the differentiation of the bits based on the time, but 2048 did not agree that the two could not be in the same key usage 2049 extension. 2051 - The procedures followed by the CA. Some felt that NR bit was kind 2052 of 'quality mark' indicating to the verifier that the verifier 2053 could be assured that the CA is implementing appropriate 2054 procedures for checking the subject's identity, performing 2055 certificate archival, etc. Other felt that it was not entirely 2056 the CAs job and that some other entity must be involved. 2058 In the end the WG agreed to a few things: 2060 - Provision of the service of non-repudiation requires more than a 2061 single bit set in a PKC. It requires an entire infrastructure of 2062 components to preserve for some period of time the keys, PKCs, 2063 revocation status, signed material, etc., as well as a trusted 2064 source of time. However, the nonRepudiation key usage bit is 2065 provided as an indicator that such keys could be used as a 2066 component of a system providing a non-repudiation service. 2068 - The certificate policy is the appropriate place to indicate the 2069 permitted combinations of key usages. That is, a policy may 2070 indicate that the DS and NR bits can not be set in the same 2071 certificate while another may say that the DS and NR bits can be 2072 set in the same certificate. 2074 [2459bis] includes new text indicating the above agreements. 2076 5.4 Non-Repudiation 2078 The major benefit of the whole DS bit vs NR bit discussion is 2079 development of the Technical Requirements for Non-Repudiation 2080 [TECHNR] draft. To fill this void [TECHNR] was developed to "describe 2081 those features of a service which processes signed documents which 2082 must be present in order for that service to constitute a 'technical 2083 non-repudiation' service." The basic understanding of nonon- 2084 repudiation is that it requires that a digital signature be preserved 2085 in such a manner that it can convince a neutral third party that it 2086 was actually created by someone with access to the private key of a 2087 certified key pair. Whether this definition of non-repudiation is 2088 enough to form a legally bind agreement is still being debated. 2090 [Add text to describe the different modes.] 2092 5.5 Trust Models 2094 An important design decision is where in the PKI the trust point for 2095 a particular EE should be located (i.e., where is the EE's Root CA) . 2096 There are two extremes: the Top CA or the CA who issues the EE's 2097 certificate. Of course, the trust point for a particular EE can be 2098 anywhere in the PKI, but the following presents the advanatages and 2099 disadvantages of locating the the trust point at these two places. 2101 [Rewrite section] 2103 6 Acknowledgements 2105 A lot of the information in this document was taken from the PKIX 2106 source documents; the authors of those deserve the credit for their 2107 own words. Other good material was taken from mail posted to the PKIX 2108 working group mail list (ietf-pkix@imc.org). Among those with good 2109 things to say were (in alphabetical order, with apologies to anybody 2110 we've missed): Sharon Boeyen, Santosh Chokhani, Warwick Ford, Russ 2111 Housley, Steve Kent, Ambarish Malpani, Matt Fite, Michael Myers, Tim 2112 Polk, Stefan Santesson, Dave Simonetti, Paul Hoffman, Denis Pinkas, 2113 Ed Greck, Tom Gindin, Parag Namjoshi, Peter Sylvester, and Michael 2114 Zolotarev. 2116 7 References 2118 [2459bis] Housley, R., Ford, W., Polk, W., and Solo, D., "Internet 2119 X.509 Public Key Infrastructure Certificate and CRL Profile," , 22 October 1999. 2122 [2510bis] Adams, C., Farrell, S., "Internet X.509 Public Key 2123 Infrastructure Certificate Management Protocols", , March 2000. 2126 [AC] S. Farrell, R. HousleyMcNeil, M., and Glassey, T., "An Internet 2127 Attribute Certificate Profile for Authorization," , 08 March 2000. 2130 [CMC] Myers, M., Liu, X., Fox, B., and Weinstein, J., "Certificate 2131 Management Messages over CMS," , 14 July 2132 1999. 2134 [CMP] Adams, C., Farrell, S., "Internet X.509 Public Key 2135 Infrastructure Certificate Management Protocols", RFC 2510, March 2136 1999. 2138 [CMP-HTTP] Tschal"ar, R., Kapoor, A., and Adams, C., "Using HTTP as a 2139 Transport Protocol for CMP", , 2140 August 1999. 2142 [CMP-TCP] Tschal"ar, R., Kapoor, A., and Adams, C., "Using TCP as a 2143 Transport Protocol for CMP", , August 2144 1999. 2146 [INTEROP] Moskowitz, R., "CMP Interoperability Testing: Results and 2147 Agreements", , June 1999. 2149 [CMS] R. Housley, "Cryptographic Message Syntax," RFC 2630, July 2150 1999. 2152 [CRMF] Myers, M., Adams, C., Solo, D., and Kemp, D., "Internet X.509 2153 Certificate Request Message Format," RFC 2511, March 1999. 2155 [DHPOP] Prafullchandra, H., and Schaad, J., "Diffie-Hellman Proof-of- 2156 Possession Algorithms," , 1 October 2157 1999. 2159 [DNS] Mockapetris, P.V., "Domain names - concepts and facilities," 2160 RFC 1034, November 1987. 2162 [DVCS] Adams, C., Sylvester, P., Zolotarev, M., Zuccherato, R., 2163 "Internet X.509 Public Key Infrastructure Data Certification Server 2164 Protocols", , 08 March 2000. 2166 [ECDSA] Bassham, L., Johnson, D., and Polk, W., "Internet x.509 2167 Public Key Infrastructure: Representation of Elliptic Curve Digital 2168 Signature Algorithm (ECDSA) Keys and Signatures in Internet X.509 2169 Public Key Infrastructure Certificates," , 22 October 1999. 2172 [ETNPT] Namjoshi, P., "Internet X.509 Public Key Infrastructure 2173 Extending trust in non repudiation tokens in time," , 28 May 1999. 2176 [IP] Postel, J., "Internet Protocol," RFC 791, September 1981. 2178 [IPv6] Deering, S., and Hinden, R., "Internet Protocol, Version 6 2179 [IPv6] Specification," RFC 1883, December 1995. 2181 [FORMAT] Housley, R., Ford, W., Polk, W., and Solo, D., "Internet 2182 X.509 Public Key Infrastructure Certificate and CRL Profile," RFC 2183 2459, January 1999. 2185 [FTPHTTP] Housley, R., and Hoffman, P., "Internet X.509 Public Key 2186 Infrastructure Operational Protocols: FTP and HTTP," RFC 2585, July 2187 1998. 2189 [KEA] Housley, R., and Polk, W., "Internet X.509 Public Key 2190 Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in 2191 Internet X.509 Public Key Infrastructure Certificates," RFC 2528, 2192 March 1999. 2194 [LAAP] Farrell, S., Chadwick, C.W., "Limited AttributeCertificate 2195 Acquisition Protocol", , 12 Octoboer 2196 1999. 2198 [LDAPv2] Yeong, Y., Howes, T., and Kille, S., "Lightweight Directory 2199 Access Protocol", RFC 1777, March 1995. 2201 [MISPC] Burr, W., Dodson, D., Nazario, N., and Polk, W., "MISPC 2202 Minimum Interoperability Specification for PKI Components, Version 2203 1", , 3 September 1997. 2205 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and Adams, 2206 C., "X.509 Internet Public Key Infrastructure Online Certificate 2207 Status Protocol - OCSP," RFC 2560, June 1999. 2209 [OCSPX] Myers, M., Ankney, R., Malpani, A., Galperin, S., and Adams, 2210 C., "OCSP Extensions," , 3 September 2211 1999. 2213 [PEM] Kent, S., "Privacy Enhancement for Internet Electronic Mail: 2214 Part II: Certificate-Based Key Management," RFC 1422, February 1993. 2216 [PKCS10] RSA Laboratories, "The Public-Key Cryptography 2217 Standards(PKCS)," RSA Data Security Inc., Redwood City, California, 2218 November 1993 Release. 2220 [PKI-LDAPv2] Boeyen, S., Howes, T., and Richard, P., "Internet X.509 2221 Public Key Infrastructure Operational Protocols - LDAPv2," RFC 2559, 2222 April 1999. 2224 [PKI-LDAPv3] Chadwick, D.W., "Internet X.509 Public Key 2225 Infrastructure Operational Protocols - LDAPv3," , August 1999. 2228 [POLPRAC] Chokhani, S., and Ford, W., "Internet X.509 Public Key 2229 Infrastructure Certificate Policy and Certification Practices 2230 Framework," RFC 2527, March 1999. 2232 [QC] Santesson, S., Polk, W., Barzin, P., and Nystrom, M., "Internet 2233 X.509 Public Key Infrastructure Qualified Certificates", , February 2000. 2236 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 2237 Messages," RFC 822, August 1982. 2239 [SCHEMA] Boeyen, S., Howes, T., and Richard, P., "Internet X.509 2240 Public Key Infrastructure LDAPv2 Schema," RFC 2587, June 1999. 2242 [SCVP] Malpani, A., Hoffman, P., "Simple Certificate Validation 2243 Protocol (SCVP)," , 9 August 1999. 2245 [SIMONETTI] Simonetti, D., "Re: German Key Usage", posting to ietf- 2246 pkix@imc.org mailing list, 12 August 1998. 2248 [TECHNR] Internet X.509 Public Key Infrastructure Technical 2249 Requirements for a non-Repudiation Service 2252 [TSP] Adams, C., Cain, P., Pinkas, D., and Zuccherato, R., "Internet 2253 X.509 Public Key Infrastructure Time Stamp Protocols", , 02 March 2000. 2256 [X.509] ITU-T Recommendation X.509 (1997 E): Information Technology - 2257 Open Systems Interconnection - The Directory: Authentication 2258 Framework, June 1997. 2260 [X9.42] ANSI X9.42-199x, Public Key Cryptography for The Financial 2261 Services Industry: Agreement of Symmetric Algorithm Keys Using 2262 Diffie-Hellman (Working Draft), December 1997. 2264 [X9.55] ANSI X9.55-1995, Public Key Cryptography For The Financial 2265 Services Industry: Extensions To Public Key Certificates And 2266 Certificate Revocation Lists, 8 December, 1995. 2268 [X9.57] ANSI X9.57-199x, Public Key Cryptography For The Financial 2269 Services Industry: Certificate Management (Working Draft), 21 June, 2270 1996. 2272 8 Security Considerations 2274 TBSL 2276 9 Editor's Address 2278 Alfred Arsenault U. S. Department of Defense 9800 Savage Road Suite 2279 6734 Fort George G. Meade, MD 20755-6734 (410) 684-7114 2280 awarsen@missi.ncsc.mil 2282 Sean Turner IECA, Inc. 9010 Edgepark Road Vienna, VA 22182 (703) 2283 628-3180 turners@ieca.com 2285 10 Disclaimer 2287 This work constitutes the opinion of the editors only, and may not 2288 reflect the opinions or policies of their employers. 2290 Expires 10 September, 2000