idnits 2.17.00 (12 Aug 2021) /tmp/idnits15862/draft-ietf-pkix-roadmap-06.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 page length should not exceed 58 lines per page, but there was 50 longer pages, the longest (page 2) being 59 lines 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 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 1690: '... has a non-null subject field, it MUST...' RFC 2119 keyword, line 1719: '...c mail addresses MUST use the rfc822Na...' RFC 2119 keyword, line 1779: '... the name MUST be stored in the unif...' RFC 2119 keyword, line 1780: '...tring). The name MUST be a non-relativ...' RFC 2119 keyword, line 1788: '... 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 -- 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 (November 2000) is 7856 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'DCVS' is mentioned on line 359, but not defined == Missing Reference: 'TRNRS' is mentioned on line 362, but not defined == Missing Reference: 'REP' is mentioned on line 385, but not defined == Missing Reference: 'POLPROC' is mentioned on line 1362, but not defined == Missing Reference: 'RFC2459' is mentioned on line 965, but not defined ** Obsolete undefined reference: RFC 2459 (Obsoleted by RFC 3280) == Missing Reference: 'HTTP' is mentioned on line 1632, but not defined == Missing Reference: 'TCP' is mentioned on line 1646, but not defined == Missing Reference: 'RFC 1738' is mentioned on line 1784, but not defined ** Obsolete undefined reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) == Unused Reference: '2510bis' is defined on line 2426, but no explicit reference was found in the text == Unused Reference: 'POLPRAC' is defined on line 2520, but no explicit reference was found in the text == Unused Reference: 'SIMONETTI' is defined on line 2559, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2510 (Obsoleted by RFC 4210) ** Obsolete normative reference: RFC 2797 (ref. 'CMC') (Obsoleted by RFC 5272) -- Duplicate reference: RFC2510, mentioned in 'CMP', was also mentioned in '2510bis'. ** Obsolete normative reference: RFC 2510 (ref. 'CMP') (Obsoleted by RFC 4210) ** Obsolete normative reference: RFC 2630 (ref. 'CMS') (Obsoleted by RFC 3369, RFC 3370) ** Obsolete normative reference: RFC 2511 (ref. 'CRMF') (Obsoleted by RFC 4211) ** Obsolete normative reference: RFC 2875 (ref. 'DHPOP') (Obsoleted by RFC 6955) ** Obsolete normative reference: RFC 2459 (ref. 'FORMAT') (Obsoleted by RFC 3280) ** Obsolete normative reference: RFC 1883 (ref. 'IPv6') (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 1777 (ref. 'LDAPv2') (Obsoleted by RFC 3494) ** Obsolete normative reference: RFC 2560 (ref. 'OCSP') (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 2559 (ref. 'PKI-LDAPv2') (Obsoleted by RFC 3494) ** Obsolete normative reference: RFC 2527 (ref. 'POLPRAC') (Obsoleted by RFC 3647) ** Obsolete normative reference: RFC 2587 (ref. 'SCHEMA') (Obsoleted by RFC 4523) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) Summary: 23 errors (**), 0 flaws (~~), 15 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PKIX Working Group A. Aresenault 2 Internet Draft Diversinet 3 Document: draft-ietf-pkix-roadmap-06.txt S. Turner 4 Category: Informational IECA 5 Expires: May, 2001 November 2000 7 Internet X.509 Public Key Infrastructure 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of 6 months 20 and may be updated, replaced, or may become obsolete by other 21 documents at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of current Internet-Drafts Shadow Directories can be 28 accessed at http://www.ietf.org/shadow.html 30 This Internet-Draft will expire in May, 2000. Comments or 31 suggestions for improvement may be made on the "ietf-pkix" mailing 32 list, or directly to the authors. 34 Copyright (C) The Internet Society (2000). All Rights Reserved. 36 Abstract 38 This document provides an overview or "roadmap" of the work done by 39 the IETF PKIX working group. It describes some of the terminology 40 used in the working group's documents, and the theory behind an 41 X.509-based Public Key Infrastructure, Privilege Management 42 Infrastructure (PMI), and Time Stamping and Data Certification 43 Infrastructures. It identifies each document developed by the PKIX 44 working group, and describes the relationships among the various 45 documents. It also provides advice to would-be PKIX implementors 46 about some of the issues discussed at length during PKIX 47 development, in hopes of making it easier to build implementations 48 that will actually interoperate. 50 Aresenault, Turner November 2000 1 51 1 Introduction.....................................................3 52 1.1 This Document..................................................3 53 1.2 Terminology....................................................3 54 1.3 History........................................................5 55 2 PKI..............................................................8 56 2.1 Theory.........................................................8 57 2.2 Architecture Model.............................................9 58 2.3 Public Key Certificates.......................................11 59 2.4 Functions of a PKI............................................12 60 2.4.1 Registration................................................12 61 2.4.2 Initialization..............................................12 62 2.4.3 Certification...............................................12 63 2.4.4 Key Pair Recovery...........................................13 64 2.4.5 Key Generation..............................................13 65 2.4.6 Key Update..................................................13 66 2.4.6.1 Key Expiry................................................13 67 2.4.6.2 Key Compromise............................................13 68 2.4.7 Cross-certification.........................................14 69 2.4.8 Revocation..................................................14 70 2.4.9 Certificate and Revocation Notice Distribution and Publication 71 ..................................................................16 72 3 PMI.............................................................16 73 3.1 Theory........................................................16 74 3.2 Architectural Model...........................................17 75 3.3 Attribute Certificates........................................18 76 4 PKIX Documents..................................................19 77 4.1 Profiles......................................................19 78 4.2 Operational Protocols.........................................22 79 4.3 Management Protocols..........................................25 80 4.4 Policy Outline................................................27 81 4.4 Time Stamping and Data Certification..........................28 82 4.5 Expired Drafts................................................30 83 5 Implementation Advice...........................................33 84 5.1 Names.........................................................33 85 5.1.1 Name Forms..................................................33 86 5.1.1.1 Distinguished Names.......................................33 87 5.1.1.2 SubjectAltName Forms......................................34 88 5.1.1.2.1 Internet e-mail addresses...............................35 89 5.1.1.2.2 DNS Names...............................................35 90 5.1.1.2.3 IP addresses............................................35 91 5.1.1.2.4 URIs....................................................35 92 5.1.2 Scope of Names..............................................36 93 5.1.3 Certificate Path Construction...............................36 94 5.1.4 Name Constraints............................................37 95 5.1.4.1 rfc822Names...............................................38 96 5.1.4.2 dNSNames..................................................39 97 5.1.4.3 x.400 addresses...........................................39 98 5.1.4.5 DNs.......................................................39 99 5.1.4.6 URIs......................................................40 100 5.1.4.7 iPaddresses...............................................40 101 5.1.4.8 Others....................................................40 103 Aresenault, Turner November, 2000 2 104 5.1.5 Wildcards in Name Forms.....................................40 105 5.1.6 Name Encoding...............................................41 106 5.2 POP...........................................................41 107 5.2.1 POP for Signing Keys........................................41 108 5.2.2 POP for Key Management Keys.................................42 109 5.3 Key Usage Bits................................................44 110 5.4 Non-Repudiation...............................................46 111 5.5 Trust Models..................................................46 112 5.5.1 Hierarchical................................................46 113 5.5.2 Local/Federation............................................46 114 5.5.3 Root Repository.............................................47 115 5.5.4 RP's Perspective............................................47 116 6 Acknowledgements................................................47 117 7 References......................................................48 118 8 Security Considerations.........................................51 119 9 Editor's Address................................................51 121 1 Introduction 123 1.1 This Document 125 This document is an informational Internet-Draft that provides a 126 "roadmap" to the documents produced by the PKIX working group. It is 127 intended to provide information; there are no requirements or 128 specifications in this document. 130 Section 1.2 of this document defines key terms used in this 131 document. Section 1.3 covers some of the basic history behind the 132 PKIC working group. Section 2 covers Public Key Infrastructure (PKI) 133 theory and functions. Section 3 covers Privilege Management 134 Infrastructure (PMI) theory and functions. Sections 2 through 5 135 attempts to explain the PKIX working group's basic assumptions in 136 each of the areas. Section 4 provides an overview of the various 137 PKIX documents. It identifies which documents address which areas, 138 and describes the relationships among the various documents. Section 139 5 contains "Advice to implementors." Its primary purpose is to 140 capture some of the major issues discussed by the PKIX working 141 group, as a way of explaining WHY some of the requirements and 142 specifications say what they say. This should cut down on the number 143 of misinterpretations of the documents, and help developers build 144 interoperable implementations. Section 6 contains a list of 145 contributors we wish to thank. Section 7 provides a list references. 146 Section 8 discusses security considerations, and Section 9 provides 147 contact information for the editors. Finally, Section 10 provides a 148 disclaimer. 150 1.2 Terminology 152 There are a number of terms used and misused throughout PKI-related, 153 PMI-related, and Time Stamp and Data Certification literature. To 155 Aresenault, Turner November, 2000 3 156 limit confusion caused by some of those terms, used throughout this 157 document, we will use the following terms in the following ways: 159 - Attribute Authority (AA) - An authority trusted by one or more 160 users to create and sign attribute certificates. It is important 161 to note that the AA is responsible for the attribute certificates 162 during their whole lifetime, not just for issuing them. 164 - Attribute Certificate (AC) - A data structure containing a set of 165 attributes for an end-entity and some other information, which is 166 digitally signed with the private key of the AA which issued it. 168 - Certificate - Can refer to either an AC or a public key 169 certificate. Where there is no distinction made the context 170 should be assumed that the term could apply to both an AC or a 171 public key certificate. 173 - Certification Authority (CA) - An authority trusted by one or 174 more users to create and assign public key certificates. 175 Optionally the CA may create the user's keys. It is important to 176 note that the CA is responsible for the public key certificates 177 during their whole lifetime, not just for issuing them. 179 - Certificate Policy (CP) - A named set of rules that indicates the 180 applicability of a public key certificate to a particular 181 community or class of application with common security 182 requirements. For example, a particular certificate policy might 183 indicate applicability of a type of public key certificate to the 184 authentication of electronic data interchange transactions for 185 the trading of goods within a given price range. 187 - Certification Practice Statement (CPS) - A statement of the 188 practices which a CA employs in issuing public key certificates. 190 - End-entity - A subject of a certificate who is not a CA in the 191 PKIC or an AA in the PMI. (An EE from the PKI can be an AA in the 192 PMI.) 194 - Public Key Certificate (PKC) - A data structure containing the 195 public key of an end-entity and some other information, which is 196 digitally signed with the private key of the CA which issued it. 198 - Public Key Infrastructure (PKI) - The set of hardware, software, 199 people, policies and procedures needed to create, manage, store, 200 distribute, and revoke PKCs based on public-key cryptography. 202 - Privilege Management Infrastructure (PMI) - A collection of ACs, 203 with their issuing AA's, subjects, relying parties, and 204 repositories, is referred to as a Privilege Management 205 Infrastructure. 207 Aresenault, Turner November, 2000 4 208 - Registration Authority (RA) - An optional entity given 209 responsibility for performing some of the administrative tasks 210 necessary in the registration of subjects, such as: confirming 211 the subject's identity; validating that the subject is entitled 212 to have the values requested in a PKC; and verifying that the 213 subject has possession of the private key associated with the 214 public key requested for a PKC. 216 - Relying party - A user or agent (e.g., a client or server) who 217 relies on the data in a certificate in making decisions. 219 - Root CA - A CA that is directly trusted by an EE; that is, 220 securely acquiring the value of a Root CA public key requires 221 some out-of-band step(s). This term is not meant to imply that a 222 Root CA is necessarily at the top of any hierarchy, simply that 223 the CA in question is trusted directly. 225 - Subordinate CA - A "subordinate CA" is one that is not a Root CA 226 for the EE in question. Often, a subordinate CA will not be a 227 Root CA for any entity but this is not mandatory. 229 - Subject - A subject is the entity (AA, CA, or EE) named in a 230 certificate, either a PKC or AC. Subjects can be human users, 231 computers (as represented by Domain Name Service (DNS) names or 232 Internet Protocol (IP) addresses), or even software agents. 234 - Time Stamp Authority (TSA) - A TSA is a trusted Third Party who 235 provides a "proof-of-existence" for a particular datum at an 236 instant in time. 238 - Top CA - A CA that is at the top of a PKI hierarchy. 240 Note: This is often also called a "Root CA," since in data 241 structures terms and in graph theory, the node at the top of a 242 tree is the "root." However, to minimize confusion in this 243 document, we elect to call this node a "Top CA," and reserve 244 "Root CA" for the CA directly trusted by the EE. Readers new to 245 PKIX should be aware that these terms are not used consistently 246 throughout the PKIX documents, as [FORMAT] uses "Root CA" to 247 refer to what this and other documents call a "Top CA," and 248 "most-trusted CA" to refer to what this and other documents call 249 a "Root CA." 251 1.3 History 253 The PKIX working group was formed in October of 1995 to develop 254 Internet standards necessary to support PKIs. The first work item 255 was a profile of the ITU-T Recommendation X.509 PKC. X.509, which is 256 a widely accepted basis for a PKI, including data formats and 257 procedures related to distribution of public keys via PKCs digitally 258 signed by CAs. X.509 does not however include a profile to specify 260 Aresenault, Turner November, 2000 5 261 the support requirements for many of the PKC data structure's sub- 262 fields, for any of the extensions, nor for certain data values. The 263 Internet PKI profile [FORMAT] went through eleven draft versions 264 before becoming an RFC. Other profiles have been developed in PKIX 265 for particular algorithms to make use of [FORMAT]. There has been no 266 sense of conflict between the authors that developed these profiles 267 as they are seen as complimentary. The Internet PKI profile has been 268 a draft standard for more than six months and is currently going 269 through an update process to clarify any inconsistencies and to 270 bolster certain sections. 272 In parallel with the profile development, work was undertaken to 273 develop the protocols necessary to manage PKI-related information 274 was. The first developed was the Certificate Management Protocol 275 (CMP). It defines a message protocol to initializing, certifying, 276 updating, and revoking PKI entities [CMP]. The demand for an 277 enrollment protocol and the desire to use PKCS-10 message format as 278 the certificate request syntax lead to the development of two 279 different documents in two different groups. The Certificate Request 280 Syntax (CRS) draft was developed in the SMIME WG which used PKCS-10 281 [PKCS10] as the certification request message format. Certificate 282 Request Message Format [CRMF] draft was also developed but in the 283 PKIX WG. It was to define a simple enrollment protocol that would 284 subsume both the CMP and CRS enrollment protocols, but it did not 285 use PKCS-10 as the certificate request message format. Then the 286 certificate management message format document, was developed to 287 define an extended set of management messages that flow between the 288 components of the Internet PKI. Certificate Management Messages over 289 CMS (CMC) was developed to allow the use of an existing protocol 290 (S/MIME) as a PKI management protocol, without requiring the 291 development of an entirely new protocol such as CMP [CMC]. It also 292 included [PKCS10] as the certificate request syntax, which caused 293 work on the CRS draft to stop. Information from the certificate 294 management message format document was moved into [CMP] and [CMC] so 295 work on the certificate management message format document was 296 discontinued. After some operational experience with [CMP], two 297 drafts, one for using HTTP as the transport protocol and one for 298 Transmission Control Protocol (TCP), were written to solve problems 299 encountered by implementors. These drafts were merged into one draft 300 Transport Protocols for CMP [TPCMP]. [CMP] has been a draft standard 301 for more than six months and is currently undergoing revisions to 302 document. The transport section has been removed and will remain in 303 [TPCMP]. 305 Another long debated topic in the WG dealt with certificate 306 revocation. Numerous drafts have been developed to address different 307 issues related certificate revocations. CMP supports revocation 308 request, response, revocation announcement, and requests for CRL 309 messages. CMC defines revocation request, revocation response, and 310 requests for CRL messages, but uses CMS as the encapsulating 311 protocol. [OCSP] was developed to address concerns that not all 313 Aresenault, Turner November, 2000 6 314 relying parties want to go through the process checking CRLs from 315 every CA in the certification path. It defines an on-line mechanism 316 to determine the status of a given certificate, which may provide 317 more timely revocation information than is possible with CRLs. The 318 Simple Certification Verification Protocol (SCVP) was produced to 319 allow relying parties to off-load all of their certification 320 verification to another entity [SCVP]. The WG was arguable split 321 over whether such a function should be supported and whether it 322 should be its own protocol or included in OCSP. In response, a draft 323 defining OCSP Extensions was produced to include the functions of 324 SCVP. [OCSP] has been a draft standard for more than six months and 325 is in the process of being revised [OCSPv2]. To capture the work 326 from the OCSP Extensions, two drafts have been developed: Delegated 327 Path Validation [DPV] and Delegated Path Discovery [DPD]. One other 328 draft called Open CRL Distribution Point (OCDP) was produced which 329 documented two extensions: one to support an alternative CRL 330 partitioning mechanism to the CRL Distribution Point mechanism 331 documented in [FORMAT] and one to support identifying other 332 revocation sources available to certificate-users. The work from 333 this draft was subsumed by an ITU-T | ISO/IEC Amendment to X.509, 334 hence work on this draft was halted. 336 Development of the operational protocols has been slightly more 337 straightforward. Four documents for the Light Weight Directory 338 Access Protocol (LDAP) have been developed one for defining LDAPv2 339 as an access protocol to repositories [PKI-LDAPv2]; two for storing 340 PKI information in an directory [SCHEMA] and [ADDSCHEMA]; and one 341 for LDAPv3 requirements for PKI [PKI-LDAPv3]. Using the File 342 Transfer Protocol (FTP) and the Hyper Text Transmission Protocol 343 (HTTP) to retrieve PKCs and CRLs from PKI repositories was 344 documented in [FTPHTTP]. Recognizing that LDAP directories are not 345 the only repository service, the working group draft a Repository 346 Locator Service [RLS] to make use of DNS SRV records to locate where 347 and how PKI information can be retrieved from a repository. 349 In late 1998 the PKIX charter was revised to include protocols for 350 time stamping and data certification services. [TSP] was developed 351 to define protocols required to interact with a Time Stamp Authority 352 (TSA) who asserts that a datum existed at a given time. [DVCS] 353 allows to verify and assert the validity of all signatures attached 354 to the signed document using all appropriate status information and 355 PKCs or to verify and assert the validity of one or more PKCs at the 356 specified time. Both [DVCS] and [TSP] use [CMS] as an encapsulating 357 (though in [TSP] request for a time stamp are not required to use 358 [CMS]). A draft for extending trust in tokens in time was developed 359 to use [DCVS] to maintain the trust in a token issued by a non- 360 repudiation Trusted Third Party (NR TTP) after the key initially 361 used to establish trust in the token expires; however, this draft 362 has expired. The [TRNRS] draft was developed to describe those 363 features of a service which processes signed documents that must be 365 Aresenault, Turner November, 2000 7 366 present in order for that service to constitute a "technical non- 367 repudiation" service. 369 Around the same time, a work item for ACs, defined in [X.509], was 370 added. ACs are similar to PKCs, but they do not bind public keys to 371 identities rather they bind attributes to identities. The attributes 372 bound to the identity can represent anything, but are mostly used to 373 support rule-based and role-based access control decisions. Two 374 drafts have since been developed: the Internet Attribute 375 Certificates Profile for Authorizations [AC] and the Limited 376 Attribute Certificate Acquisition Protocol [LAAP]. The first 377 profiles the fields and extensions of the AC and the second provides 378 a deliberately limited protocol to access a repository when LDAP is 379 not appropriate. 381 Other drafts have been produced to address specific issues. [DHPOP] 382 was developed to define two mechanisms by which a signature can 383 produced using a Diffie-Hellman pair. This draft provides a 384 mechanism to Diffie-Hellam key pairs to issue a PKCS-10 385 certification request. [REP] was developed during the revision to 386 [FORMAT] to separate the definitions of the object identifiers and 387 encoding rules for keys and digital signatures in PKCs. The 388 Qualified Certificates [QC] and Permanent Identifier [PI] drafts 389 were developed to address naming issues. 391 From the alphabet soup above, it is clear why this roadmap is 392 required. 394 2 PKI 396 2.1 Theory 398 At the heart of recent efforts to improve Internet security are a 399 group of security protocols such as Secure Multipurpose Internet 400 Mail Extensions (S/MIME), Transport Layer Security (TLS), and 401 Internet Protocol Security (IPSec). All of these protocols rely on 402 public-key cryptography to provide services such as confidentiality, 403 data integrity, data origin authentication, and non-repudiation. The 404 purpose of a PKI is to provide trusted and efficient key and public 405 key certificate management, thus enabling the use of authentication, 406 non-repudiation, and confidentiality. 408 Users of public key-based systems must be confident that, any time 409 they rely on a public key, the subject that they are communicating 410 with owns the associated private key, this applies whether an 411 encryption or digital signature mechanism is used. This confidence 412 is obtained through the use of PKCs, which are data structures that 413 bind public key values to subjects. The binding is achieved by 414 having a trusted CA verify the subject's identity and digitally sign 415 each PKC. 417 Aresenault, Turner November, 2000 8 418 A PKC has a limited valid lifetime, which is indicated in its signed 419 contents. Because a PKC's signature and timeliness can be 420 independently checked by a certificate-using client, PKCs can be 421 distributed via untrusted communications and server systems, and can 422 be cached in unsecured storage in certificate-using systems. 424 PKCs are used in the process of validating signed data. Specifics 425 vary according to which algorithm is used, but the general process 426 works as follows: 428 Note: there is no specific order in which the checks listed below 429 must be made; implementors are free to implement them in the most 430 efficient way for their systems. 432 - The recipient of signed data verifies that the claimed identity 433 of the user is in accordance with the identity contained in the 434 PKC; 436 - The recipient validates that no PKC in the path is revoked (e.g., 437 by retrieving a suitably-current Certificate Revocation List 438 (CRL) or querying an on-line certificate status responder), and 439 that all PKCs are within their validity periods at the time the 440 data was signed; 442 - The recipient verifies that the data are not claimed to have any 443 values for which the PKC indicates that the signer is not 444 authorized; 446 - The recipient verifies that the data have not been altered since 447 signing, by using the public key in the PKC. 449 - If all of these checks pass, the recipient can accept that the 450 data was signed by the purported signer. The process for keys 451 used for encryption is similar. 453 Note: It is of course possible that the data was signed by 454 someone very different from the signer, if for example the 455 purported signer's private key was compromised. Security depends 456 on all parts of the certificate-using system, including but not 457 limited to: physical security of the place the computer resides; 458 personnel security (i.e., the trustworthiness of the people who 459 actually develop, install, run, and maintain the system); the 460 security provided by the operating system on which the private 461 key is used; and the security provided the CA. A failure in any 462 one of these areas can cause the entire system security to fail. 463 PKIX is limited in scope, however, and only directly addresses 464 issues related to the operation of the PKI subsystem. For 465 guidance in many of the other areas, see [POLPROC]. 467 2.2 Architecture Model 469 Aresenault, Turner November, 2000 9 470 A PKI is defined as: 472 The set of hardware, software, people, policies and procedures 473 needed to create, manage, store, distribute, and revoke PKCs based 474 on public-key cryptography. 476 A PKI consists of five types of components [MISPC]: 478 - Certification Authorities (CAs) that issue and revoke PKCs; 480 - Organizational Registration Authorities (ORAs) that vouch for the 481 binding between public keys and certificate holder identities and 482 other attributes; 484 - PKC holders that are issued certificates and can sign digital 485 documents and encrypt documents; 487 - Clients that validate digital signatures and their certification 488 paths from a known public key of a trusted CA; 490 - Repositories that store and make available PKCs and Certificate 491 Revocation Lists (CRLs). 493 Figure 1 is a simplified view of the architectural model assumed by 494 the PKIX Working Group. 496 Aresenault, Turner November, 2000 10 497 +---+ 498 | C | +------------+ 499 | e | <-------------------->| End entity | 500 | r | Operational +------------+ 501 | t | transactions ^ 502 | | and management | Management 503 | / | transactions | transactions 504 | | | PKI users 505 | C | v 506 | R | -------------------+--+-----------+-------------- 507 | L | ^ ^ PKI 508 | | | | management 509 | | v | entities 510 | R | +------+ | 511 | e | <---------------------| RA | <---+ | 512 | p | Publish certificate +------+ | | 513 | o | | | 514 | s | | | 515 | I | v v 516 | t | +------------+ 517 | o | <------------------------------| CA | 518 | r | Publish certificate +------------+ 519 | y | Publish CRL ^ 520 | | | 521 +---+ Management | 522 transactions | 523 v 524 +------+ 525 | CA | 526 +------+ 527 Figure 1 - PKI Entities 529 2.3 Public Key Certificates 531 ITU-T X.509 (formerly CCITT X.509) or ISO|IEC/ITU 9594-8, which was 532 first published in 1988 as part of the X.500 Directory 533 recommendations, defines a standard PKC format [X.509]. The PKC 534 format in the 1988 standard is called the version 1 (v1) format. 536 When X.500 was revised in 1993, two more fields, 537 subjectUniqueIdentifier and issuerUniqueIdentifier were added, 538 resulting in the version 2 (v2) format. These two fields may be used 539 to support directory access control. 541 The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993, 542 include specifications for a public key infrastructure based on 543 X.509 v1 public key certificates [PEM]. The experience gained in 544 attempts to deploy [PEM] made it clear that the v1 and v2 public key 545 certificate formats are deficient in several respects. Most 546 importantly, more fields were needed to carry information which PEM 548 Aresenault, Turner November, 2000 11 549 design and implementation experience has proven necessary. In 550 response to these new requirements, ISO|IEC, ITU, and ANSI X9 551 developed the X.509 version 3 (v3) PKC format. The v3 format extends 552 the v2 format by adding provision for additional extension fields. 553 Particular extension field types may be specified in standards or 554 may be defined and registered by any organization or community. In 555 June 1996, standardization of the basic v3 format was completed 556 [X.509]. 558 ISO|IEC, ITU, and ANSI X9 have also developed standard extensions 559 for use in the v3 extensions field [X.509][X9.55]. These extensions 560 can convey such data as additional subject identification 561 information, key attribute information, policy information, and 562 certification path constraints. However, the ISO/IEC/ITU and ANSI X9 563 standard extensions are very broad in their applicability. In order 564 to develop interoperable implementations of X.509 v3 systems for 565 Internet use, it is necessary to specify a profile for use of the 566 X.509 v3 extensions tailored for the Internet. It is one goal of 567 PKIX to specify a profile for Internet, electronic mail, and IPSec 568 applications, etc. Environments with additional requirements may 569 build on this profile or may replace it. 571 2.4 Functions of a PKI 573 This section describes the major functions of a PKI. In some cases, 574 PKIs may provide extra functions. 576 2.4.1 Registration 578 This is the process whereby a subject first makes itself known to a 579 CA (directly, or through an RA), prior to that CA issuing a PKC or 580 PKCs for that subject. Registration involves the subject providing 581 its name (e.g., common name, fully-qualified domain name, IP 582 address), and other attributes to be put in the PKC, followed by the 583 CA (possibly with help from the RA) verifying in accordance with its 584 Certification Practice Statement (CPS) that the name and other 585 attributes are correct. 587 2.4.2 Initialization 589 Initialization is when the subject (e.g., the user or client system) 590 gets the values needed to begin communicating with the PKI. For 591 example, initialization can involve providing the client system with 592 the public key or PKC of a CA, or generating the client system's own 593 public-private key pair. 595 2.4.3 Certification 597 This is the process in which a CA issues a PKC for a subject's 598 public key, and returns that PKC to the subject or posts that PKC in 599 a repository. 601 Aresenault, Turner November, 2000 12 602 2.4.4 Key Pair Recovery 604 In some implementations, key exchange or encryption keys will be 605 required by local policy to be "backed up," or recoverable in case 606 the key is lost and access to previously-encrypted information is 607 needed. Such implementations can include those where the private key 608 exchange key is stored on a hardware token that can be lost or 609 broken, or when a private key file is protected by a password which 610 can be forgotten. Often, a company is concerned about being able to 611 read mail encrypted by or for a particular employee when that 612 employee is no longer available because she is ill or no longer 613 works for the company. 615 In these cases, the user's private key can be backed up by a CA or 616 by a separate key backup system. If a user or her employer needs to 617 recover these backed up key materials, the PKI must provide a system 618 that permits the recovery without providing an unacceptable risk of 619 compromise of the private key. 621 2.4.5 Key Generation 623 Depending on the CA's policy, the private-public key pair can either 624 be generated by the user in his local environment, or generated by 625 the CA. In the latter case, the key material may be distributed to 626 the user in an encrypted file or on a physical token (e.g., a smart 627 card or PC card). 629 2.4.6 Key Update 631 All key pairs need to be updated regularly (i.e., replaced with a 632 new key pair) and new PKCs issued. This will happen in two cases: 633 normally, when a key has passed its maximum usable lifetime; and 634 exceptionally, when a key has been compromised and must be replaced. 636 2.4.6.1 Key Expiry 638 In the normal case, a PKI needs to provide a facility to gracefully 639 transition from a PKC with an existing key to a new PKC with a new 640 key. This is particularly true when the key to be updated is that of 641 a CA. Users will know in advance that the key will expire on a 642 certain date; the PKI, working together with PKC-using applications, 643 should allow for appropriate keys to work before and after the 644 transition. There are a number of ways to do this; see [CMP] for an 645 example of one. 647 2.4.6.2 Key Compromise 649 In the case of a key compromise, the transition will not be 650 "graceful" in that there will be an unplanned switch of PKCs and 651 keys; users will not have known in advance what was about to happen. 653 Aresenault, Turner November, 2000 13 654 Still, the PKI must support the ability to declare that the previous 655 PKC is now invalid and shall not be used, and to announce the 656 validity and availability of the new PKC. 658 Note: compromise of a private key associated with a Root CA is 659 catastrophic for users relying on that Root CA. If a Root CA's 660 private key is compromised, that CA's PKC must be revoked and all 661 PKCs subordinate to it must also be revoked. Until such time as 662 the Root CA has been issued a new PKC and the Root CA issues PKCs 663 to users relying upon it, users relying on that Root CA are cut 664 off from the rest of the system, as there is no way to develop a 665 valid certification path back to a trusted node. 667 Further, users will likely have to be notified by out-of-band 668 mechanisms about the change in CA keys. If the old key is 669 compromised, any "update" message telling subordinates to switch to 670 a new key could have come from an attacker in possession of the old 671 key, and could point to a new public key for which the attacker 672 already has the private key. It is possible to have anticipated this 673 event, and "pre-placed" replacement Root CA keys with all relying 674 parties, but some secure, out-of-band mechanism will have to be used 675 to tell users to make the switch, and this will only help if the 676 replacement key has not been compromised. 678 Additionally, once the Root CA is brought back up with a new key, it 679 will likely be necessary to re-issue PKCs, signed with the new key, 680 to all subordinate users, since their current PKC would be signed 681 with a now-revoked key. 683 2.4.7 Cross-certification 685 A cross-certificate is a PKC issued by one CA to another CA which 686 contains a public CA key associated with the private CA signature 687 key used for issuing PKCs. Typically, a cross-certificate is used to 688 allow client systems or end entities in one administrative domain to 689 communicate securely with client systems or end users in another 690 administrative domain. Use of a cross-certificate issued from CA_1 691 to CA_2 allows user Alice, who trusts CA_1, to accept a PKC used by 692 Bob, which was issued by CA_2. Cross-certificates can also be issued 693 from one CA to another CA in the same administrative domain, if 694 required. 696 Cross-certificates can be issued in only one direction, or in both 697 directions, between two CA's. That is, just because CA_1 issues a 698 cross-certificate for CA_2, CA_2 does not have to issue a cross- 699 certificate for CA_1. 701 2.4.8 Revocation 703 When a PKC is issued, it is expected to be in use for its entire 704 validity period. However, various circumstances may cause a PKC to 706 Aresenault, Turner November, 2000 14 707 become invalid prior to the expiration of the validity period. Such 708 circumstances include change of name, change of association between 709 subject and CA (e.g., an employee terminates employment with an 710 organization), and compromise or suspected compromise of the 711 corresponding private key. Under such circumstances, the CA needs to 712 revoke the PKC. 714 X.509 defines one method of PKC revocation. This method involves 715 each CA periodically issuing a signed data structure called a 716 certificate revocation list (CRL). A CRL is a time stamped list 717 identifying revoked PKCs that is signed by a CA and made freely 718 available in a public repository. Each revoked PKC is identified in 719 a CRL by its PKC serial number. When a certificate-using system uses 720 a PKC, that system not only checks the PKC signature and validity 721 but also acquires a suitably recent CRL and checks that the PKC 722 serial number is not on that CRL. The meaning of "suitably recent" 723 may vary with local policy, but it usually means the most recently 724 issued CRL. A CA issues a new CRL on a regular periodic basis (e.g., 725 hourly, daily, or weekly). CA's may also issue CRLs aperiodically. 726 For example, if an important key is deemed compromised, the CA may 727 issue a new CRL to expedite notification of that fact, even if the 728 next CRL does not have to be issued for some time. (A problem of 729 aperiodic CRL issuance is that end-entities may not know that a new 730 CRL has been issued, and thus may not retrieve it from a 731 repository.) 733 An entry is added to the CRL as part of the next update following 734 notification of revocation. An entry may be removed from the CRL 735 after appearing on one regularly scheduled CRL issued beyond the 736 revoked PKC's validity period. Leaving the revoked PKC on the CRL 737 for this extra period allows for PKCs that are revoked prior to 738 issuing a new CRL and whose invalidity date falls before the CRL 739 issuing time to be accounted for. If the revoked PKC is not retained 740 on the CRL for this extra period then the possibility arises that a 741 revoked PKC may never appear on a CRL. 743 An advantage of the CRL revocation method is that CRLs may be 744 distributed by exactly the same means as PKCs themselves, namely, 745 via untrusted communications and server systems. 747 One limitation of the CRL revocation method, using untrusted 748 communications and servers, is that the time granularity of 749 revocation is limited to the CRL issue period. For example, if a 750 revocation is reported now, that revocation will not be reliably 751 notified to certificate-using systems until the next CRL is issued, 752 which may be up to one hour, one day, or one week depending on the 753 frequency that the CA issues CRLs. 755 As with the X.509 v3 PKC format, in order to facilitate 756 interoperable implementations from multiple vendors, the X.509 v2 757 CRL format needed to be profiled for Internet use. This was done as 759 Aresenault, Turner November, 2000 15 760 part of [FORMAT]. However, PKIX does not require CAs to issue CRLs. 761 On-line methods of revocation notification may be applicable in some 762 environments as an alternative to the X.509 CRL. PKIX defines a few 763 protocols that support on-line checking. [OCSP], [DVCS], and [SCVP] 764 all support on-line checking of the status of PKCs. 766 On-line revocation checking may significantly reduce the latency 767 between a revocation report and the distribution of the information 768 to relying parties. Once the CA accepts the report as authentic and 769 valid, any query to the on-line service will correctly reflect the 770 PKC validation impacts of the revocation. However, these methods 771 impose new security requirements; the PKC validator must trust the 772 on-line validation service while the repository does not need to be 773 trusted. 775 2.4.9 Certificate and Revocation Notice Distribution and Publication 777 As alluded to in sections 2.1 and 2.5.8 above, the PKI is 778 responsible for the distribution of PKCs and PKC revocation notices 779 (whether in CRL form or in some other form) in the system. 780 "Distribution" of PKCs includes transmission of the PKC to its 781 owner, and may also include publication of the PKC in a repository. 782 "Distribution" of revocation notices may involve posting CRLs in a 783 repository, transmitting them to end-entities, or forwarding them to 784 on-line responders. 786 3 PMI 788 3.1 Theory 790 Many systems use the PKC to perform identity based access control 791 decisions (i.e., the identity may be used to support identity-based 792 access control decisions after the client proves that it has access 793 to the private key that corresponds to the public key contained in 794 the PKC). For many systems this is sufficient, but increasingly 795 systems are beginning to find that rule-based and role-based access 796 control is required. These forms of access control decisions require 797 additional information that is normally not included in a PKC, 798 because the lifetime of the information is much shorter than the 799 lifetime of the public-private key pair. To support binding this 800 information to a PKC the Attribute Certificate (AC) was defined in 801 ANSI and later incorporated into ITU-T Recommendation X.509. The AC 802 format allows any additional information to be bound to a PKC by 803 including, in a digitally signed data structure, a reference back to 804 one specific PKC or to multiple PKCs, useful when the subject has 805 the same identity in multiple PKCs. Additionally, the AC can be 806 constructed in such a way that it is only useful at one or more 807 particular targets (e.g., web server, mail host). 809 Users of a PMI must be confident that the identity purporting to 810 posses an attribute has the right to possess that attribute. This 812 Aresenault, Turner November, 2000 16 813 confidence may be obtained through the use of PKCs or it may be 814 configured in the AC-using system. If PKCs are used the party making 815 the access control decision can determine "if the AC issuer is 816 trusted to issue ACs containing this attribute." 818 ACs are complicated by the fact that they can point to an identity 819 which may be in more than one PKC. If the RP has multiple 820 certification chains to chose from then it has to make the 821 determination as to which certification path to trust. Regardless, 822 before the RP uses the AC it must make sure that a path from the AC 823 back to its trust point is valid. 825 3.2 Architectural Model 827 A Privilege Management Infrastructure, or PMI, is defined as: 829 The set of hardware, software, people, policies and procedures 830 needed to create, manage, store, distribute, and revoke ACs. 832 A PMI consists of five types of components [AC]: 834 - Attribute Authorities (AAs), or Attribute Certificate Issuer, 835 that issue and revoke ACs; 837 Note: AAs may implicitly revoke ACs by using very short validity 838 periods. 840 - Attribute Certificate Users that parses or processes an AC; 842 - Attribute Certificate Verifiers that check the validity of an AC 843 and then makes use of the result; 845 - Clients that request an action for which authorization checks are 846 to be made; 848 - Repositories that store and make available certificates and 849 Certificate Revocation Lists (CRLs). 851 Figure 2 is an example of the exchanges that may involve ACs. 853 Aresenault, Turner November, 2000 17 854 +--------------+ 855 | | Server Acquisition 856 | AC Issuer +----------------------------+ 857 | | | 858 +--+-----------+ | 859 | | 860 | Client | 861 | Acquisition | 862 | | 863 +--+-----------+ +--+------------+ 864 | | AC "push" | | 865 | Client +-------------------------+ Server | 866 | | (part of app. protocol) | | 867 +--+-----------+ +--+------------+ 868 | | 869 | Client | Server 870 | Lookup +--------------+ | Lookup 871 | | | | 872 +---------------+ Repository +---------+ 873 | | 874 +--------------+ 876 Figure 2: AC Exchanges 878 3.3 Attribute Certificates 880 ANSI X.9 first published the Attribute Certificate format. It 881 defined the standard version 1 (v1) AC format. They later created a 882 version 2 (v2) AC by modifying the owner field to point to either an 883 identity or a specific PKC and including an extension mechanism. In 884 1997 ITU-T included it in [X.509]. 886 ANSI, ITU-T, and IETF have developed standard extensions and 887 attributes for use in the v2 ACs. Extensions can convey such 888 information as an audit identity that can be used to create an audit 889 trail, identity specific servers and services where the AC owner can 890 use their AC, point to a specific issuer's key, and indicate where 891 to get revocation information. The AC is generic enough to allow any 892 attribute to be conveyed in the data structure. Without limiting the 893 attributes and extensions that can be included in an AC it is very 894 difficult to develop interoperable implementations for Internet use. 895 It is the goal of PKIX to specify a profile for the Internet, 896 electronic mail, IPSec applications, etc. Environments with 897 additional requirements may build on this profile or replace it. 899 The [AC] profile constrains many of the options allowed in X.509. 900 For example, the AC chains, like their PKC brethren, are allowed by 901 X.509, but the AC profile recommends that they not be supported in 902 to simplify the implementation. 904 Aresenault, Turner November, 2000 18 905 4 PKIX Documents 907 This section identifies the five different areas in which the PKIX 908 working group has developed documents. The first area involves 909 profiles of the X.509 v3 PKC standards and the X.509 v2 CRL 910 standards for the Internet. The second area involves operational 911 protocols, in which relying parties can obtain information such as 912 PKCs or PKC status. The third area covers management protocols, in 913 which different entities in the system exchange information needed 914 for proper management of the PKI. The fourth area provides 915 information about certificate policies and certificate practice 916 statements, covering the areas of PKI security not directly 917 addressed in the rest of PKIX. The fifth area deals with providing 918 time stamping and data certification services, which can be used to 919 build such services as non-repudiation. 921 4.1 Profiles 923 An X.509 v3 PKC is a very complex data structure. It consists of 924 basic information fields, plus a number of optional extensions. Many 925 of the fields and numerous extensions can take on a wide range of 926 options. This provides an enormous degree of flexibility, which 927 allows the X.509 v3 PKC format to be used with a wide range of 928 applications in a wide range of environments. Unfortunately, this 929 same flexibility makes it extremely difficult to produce independent 930 implementations that will actually interoperate with one another. In 931 order to build an Internet PKI based on X.509 v3 PKCs, the PKIX 932 working group had to develop a profile of the X.509 v3 PKC 933 specification. 935 A profile of the X.509 v3 PKC specification is a description of the 936 contents of the PKC and which extensions must be supported, which 937 extensions may be supported, and which extensions may not be 938 supported. [FORMAT] provides such a profile of X.509 v3 PKC for the 939 Internet PKI. In addition, [FORMAT] suggests ranges of values for 940 many of the extensions. 942 [FORMAT] also provides a profile for Version 2 CRLs for use in the 943 Internet PKI. CRLs, like PKCs, have a number of optional extensions. 944 In order to promote interoperability, it is necessary to constrain 945 the choices an implementor supports. 947 In addition to profiling the PKC and CRL formats, it is necessary to 948 define particular Object Identifiers (OIDs) for certain encryption 949 algorithms, because there are a variety of OIDs registered for some 950 algorithm suites. PKIX has produced two documents ([RPKDS] and 951 [KEA]) which provide guidance on the proper implementation of 952 specific algorithms. 954 Some countries are in a process of updating their legal frameworks 955 in order to regulate and incorporate recognition of signatures in 957 Aresenault, Turner November, 2000 19 958 electronic form. Many of these frameworks introduce certain basic 959 requirements on PKCs, often termed Qualified Certificates, 960 supporting these types of "legal" signatures. Partly as a result of 961 this there is a need for a specific PKC profile providing 962 standardized support for certain related issues such as a common 963 structure for expressing unambiguous identities of certified 964 subjects (unmistakable identity). In December 1998, PKIX adopted as 965 a work item the development of a refinement of [RFC2459] that 966 further profiles PKIX PKC into qualified certificates. This work is 967 reflected in [QC]. 969 Like the X.509 v3 PKC, the AC also a very complex data structure 970 consisting of basic information fields, a number of optional 971 extensions, and a virtually unlimited number of attributes. Again, 972 many of the fields, extensions, and attributes can take on a wide 973 range of options allowing an enormous degree of flexibility. In 974 order to build an Internet PMI based on ACs, the PKIX working group 975 had to develop a profile of the AC. 977 The AC profile is description of the contents of the AC, the allowed 978 and required extensions, and applicable attributes. [AC] provides 979 such a profile of the X.509 v2 AC. 981 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate 982 and CRL Profile (RFC 2459) 984 DESCRIPTION: This document describes the profiles to be used for 985 X.509 v3 PKCs and version 2 CRLs by Internet PKI participants. The 986 profiles include the identification of ISO/IEC/ITU and ANSI 987 extensions which may be useful in the Internet PKI. The profiles are 988 presented in the 1988 Abstract Syntax Notation One (ASN.1) rather 989 than the 1994 syntax used in the ISO/IEC/ITU standards. Would-be 990 PKIX implementors and developers of certificate-using applications 991 should start with [FORMAT] to ensure that their systems will be able 992 to interoperate with other users of the PKI. 994 [FORMAT] also includes path validation procedures. The procedures 995 presented are based upon the ISO/IEC/ITU definition, but the 996 presentation assumes one or more self-signed trusted CA PKCs. The 997 procedures are provided as examples only. Implementations are not 998 required to use the procedures provided; they may implement 999 whichever procedures are efficient for their situation. However, 1000 implementations are required to derive the same results as the 1001 example procedures. 1003 STATUS: Proposed Standard. 1005 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure 1006 Representation of Key Exchange Algorithm (KEA) Keys in Internet 1007 X.509 Public Key Infrastructure Certificates (RFC 2528) 1009 Aresenault, Turner November, 2000 20 1010 DESCRIPTION: This document provides Object Identifiers (OIDs) and 1011 other guidance for IPKI users who use the Key Exchange Algorithm 1012 (KEA). It profiles the format and semantics of the 1013 subjectPublicKeyInfo field and the keyUsage extension in X.509 v3 1014 PKCs containing KEA keys. This document should be used by anyone 1015 wishing to support KEA; others who do not support ECDSA are not 1016 required to comply with it. 1018 STATUS: Informational RFC. 1020 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Qualified 1021 Certificates 1023 DESCRIPTION: This document profiles the format for and defines 1024 requirements on information content in a specific type of PKCs 1025 called Qualified Certificates. A "Qualified Certificate" is a PKC 1026 that is issued to a natural person (i.e., a living human being); 1027 contains an unmistakable identity based on a real name or a 1028 pseudonym of the subject; exclusively indicates non-repudiation as 1029 the key usage for the certificate's public key; and meets a number 1030 of requirements. 1032 STATUS: WG Last Call. 1034 DOCUMENT TITLE: An Internet Attribute Certificate Profile for 1035 Authorizations 1037 DESCRIPTION: This document profiles the format for an defines 1038 requirements on X.509 v2 ACs to support authorization services 1039 required by various Internet protocols (TLS, CMS, and the consumers 1040 of CMS, etc.). Two profiles are defined in support of basic 1041 authorizations and in support of services that can operate via 1042 proxy. 1044 STATUS: Under WG review. 1046 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate 1047 and CRL Profile 1049 DESCRIPTION: This document is an update of [FORMAT]. 1051 STATUS: Under WG review. 1053 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Permanent 1054 Identifier 1056 DESCRIPTION: This document defines a new form of name, the permanent 1057 identifier, which is a name assigned by an organization, unique 1058 within that organization, that singles out a particular individual 1059 fro all other individuals. The permanent identifier is an optional 1060 feature that may be used by a CA to indicate that the certificate 1062 Aresenault, Turner November, 2000 21 1063 relates to the same individual even if the name or the affiliation 1064 of that individual has changed. The permanent identifier is 1065 important in the context of access control and of non-repudiation. 1067 STATUS: Under WG review. 1069 DOCUMENT TITLE: Representation of Public Keys and Digital Signatures 1070 in Internet X.509 Public Key Infrastructure Certificates 1071 1073 DESCRIPTION: This document specifies algorithm identifiers and 1074 encoding formats for the representation of cryptographic algorithms 1075 keys, associated parameters, and digital signatures in Internet PKI 1076 and X.509 certificates and certificate revocation lists. This draft 1077 does not attempt to define the cryptographic algorithms themselves. 1078 It instead references other appropriate standards. This draft 1079 incorporates information from Section 7 of RFC 2459 and the 1080 Internet-Draft _Representation of Elliptic Curve Digital Signature 1081 Algorithm (ECDSA) Keys in Internet X.509 Public Infrastructure 1082 Certificates._ 1084 STATUS: Under WG review. 1086 4.2 Operational Protocols 1088 Operational protocols are required to deliver certificates and CRLs 1089 (or other certificate status information) to certificate using 1090 systems. Provision is needed for a variety of different means of 1091 certificate and CRL delivery, including distribution procedures 1092 based on DNS, LDAP, HTTP, FTP, and X.500. A limited protocol to 1093 support AC retrieval has also been documented. 1095 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Operational 1096 Protocols - LDAPv2 (RFC 2559) 1098 DESCRIPTION: This document describes the use of LDAPv2 as a protocol 1099 for PKI elements to publish and retrieve certificates and CRLs from 1100 a repository. [LDAPv2] is a protocol that allows publishing and 1101 retrieving of information. 1103 STATUS: Proposed Standard. 1105 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure LDAPv2 1106 Schema (RFC 2587) 1108 DESCRIPTION: This document defines a minimal schema necessary to 1109 support the use of LDAPv2 for PKC and CRL retrieval and related 1110 functions for PKIX. This document supplements [LDAPv2] by 1111 identifying the PKIX-related attributes that must be present. 1113 STATUS: Proposed Standard. 1115 Aresenault, Turner November, 2000 22 1116 DOCUMENT TITLE: X.509 Internet Public Key Infrastructure Online 1117 Certificate Status Protocol - OCSP (RFC 2560) 1119 DESCRIPTION: This document specifies a protocol useful in 1120 determining the current status of a certificate without the use of 1121 CRLs. A major complaint about certificate-based systems is the need 1122 for a relying party to retrieve a current CRL as part of the 1123 certificate validation process. Depending on the size of the CRL, 1124 this can cause severe problems for bandwidth-challenged devices. 1125 Depending on the frequency of CRL issuance, this can also cause 1126 timeliness problems. (E.g., if CRLs are only published weekly, with 1127 no interim releases, a certificate could actually have been revoked 1128 for just short of one week without it being on the current CRL, and 1129 thus improper use of that certificate could still be occurring.) 1131 OCSP attempts to address those problems. It provides a mechanism 1132 whereby a relying party identifies one or more certificates to an 1133 approved OCSP "responder", and the responder sends back the current 1134 status of the certificate(s) - e.g., "revoked", "notRevoked", 1135 "unknown". This can dramatically reduce the bandwidth required to 1136 transmit revocation status - a relying party does not have to 1137 retrieve a CRL of many entries to check the status of one 1138 certificate. It can (although it is not guaranteed to) improve the 1139 timeliness of revocation notification, and thus reduce the window of 1140 opportunity for someone trying to use a revoked certificate. 1142 STATUS: Proposed Standard. 1144 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Operational 1145 Protocols: FTP and HTTP (RFC 2585) 1147 DESCRIPTION: This document describes the use of the File Transfer 1148 Protocol (FTP) and the Hyper-text Transfer Protocol (HTTP) to obtain 1149 certificates and CRLs from PKI repositories. 1151 STATUS: Proposed Standard. 1153 DOCUMENT TITLE: Diffie-Hellman Proof-of-Possession Algorithms (RFC 1154 2875) as the basis of the signature. It allows Diffie-Hellman, a key 1155 agreement algorithm, to be used instead of requiring that the public 1156 key being requested for certification correspond to an algorithm 1157 that is capable of signing and encrypting. The first algorithm 1158 generates a signature for a specific verifier where the signer and 1159 recipient have the same public key parameters. The second algorithm 1160 generates a signature for arbitrary verifiers where the signer and 1161 recipient do not have the same public key parameters. 1163 STATUS: Proposed Standard. 1165 Aresenault, Turner November, 2000 23 1166 DOCUMENT TITLE: Limited Attribute Certificate Acquisition Protocol 1167 1169 DESCRIPTION: This document specifies a deliberately limited protocol 1170 for requesting ACs from a server. It is intended to be complementary 1171 to the use of LDAP for AC retrieval, covering those cases where use 1172 of an LDAP server is not suitable due to the type of authorization 1173 model being employed. 1175 STATUS: Under WG review. 1177 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Additional 1178 Schema for PKIs and PMIs 1180 DESCRIPTION: This document describes the Lightweight Directory 1181 Access Protocol (LDAP) schema features that, in addition to RFC 1182 2587, are needed to support a Privilege Management Infrastructure 1183 and a Public Key Infrastructure. It also describes the schema for 1184 the storage and matching of attribute certificates and revocation 1185 lists in an LDAP directory server. This Internet Draft supplements, 1186 rather than revokes, the contents of RFC 2587. 1188 STATUS: Under WG review. 1190 DOCUMENT TITLE: Simple Certificate Validation Protocol (SCVP) 1191 1193 DESCRIPTION: The SCVP protocol allows a client to offload 1194 certificate handling to a server. The server can give a variety of 1195 valuable information about the 1196 certificate, such as whether or not the certificate is valid, a 1197 chain to a trusted root, and so on. 1199 STATUS: Under WG review. 1201 DOCUMENT TITLE: Online Certificate Status Protocol, Version 2 1202 1204 DESCRIPTION: This document is an update to RFC 2560. 1206 STATUS: Under WG review. 1208 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Repository 1209 Locator Service 1211 DESCRIPTION: This document defines a PKI repository locator service, 1212 which enable certificate-using systems to locate PKI repositories 1213 based on a domain name, to identify the protocols that can be used 1214 to access the repository, and obtain addresses for the servers that 1215 host the repository service. The Internet Draft defines SRV records 1216 for a PKI repository locator service to enable PKI clients to obtain 1218 Aresenault, Turner November, 2000 24 1219 necessary information to connect to a domain's repository. It also 1220 includes the definition of a SRV RR format for this service. 1222 STATUS: Under WG review. 1224 DOCUMENT TITLE: Delegated Path Validation 1227 DESCRIPTION: This specification builds on the Online Certificate 1228 Status Protocol (OSCP) framework's extensibility by defining an 1229 Internet-standard extension to OCSP that can be used to fully 1230 delegate all path validation processing to an OCSP server. The 1231 Delegated Path Validation (DVP) extension to OCSP described in this 1232 document accomplishes the task of locating the certificate 1233 validation process within a trusted server. This in turn reduces 1234 the technical footprint of certificate-using applications and may 1235 ease the integration of certificate path processing with other 1236 authorized data. 1238 STATUS: Under WG review. 1240 DOCUMENT TITLE: Delegated Path Discovery with OCSP 1243 DESCRIPTION: This document establishes an Internet-standard 1244 extension that enables relying-party software to acquire 1245 certification path data from an OCSP server rather than replicate 1246 the same functionality. This Delegated Path Discovery (DPD) 1247 extension delegates the acquisition process to a separate server, 1248 thereby greatly simplifying and reducing the size of public key 1249 based credential validation systems or other relying party software. 1250 The DPD extension also enables such software to select from among 1251 various trust paths in the event of the existence of multiple paths. 1253 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Operational 1254 Protocols - LDAPv3 1256 DESCRIPTION: This document describes the features of the Lightweight 1257 Directory Access Protocol (LDAP) v3 that are needed in order to 1258 support a public key infrastructure based on x.509 certificates and 1259 certificate revocation lists. Because LDAPv2 has a number of 1260 deficiencies that may limit its usefulness in certain circumstances, 1261 the IETF has ceased its standardization and replaced it with LDAPv3. 1262 This document describes the features of LDAPv3 that are necessary, 1263 not required, or are optional for servers to support a PKI based on 1264 X.509. 1266 STATUS: Under WG Review. 1268 4.3 Management Protocols 1270 Aresenault, Turner November, 2000 25 1271 Management protocols are required to support on-line interactions 1272 between PKI user and management entities. For example, a management 1273 protocol might be used between a CA and a client system with which a 1274 key pair is associated, or between two CAs which cross-certify each 1275 other. A management protocol can be used to carry user or client 1276 system registration information, or a request for revocation of a 1277 certificate. 1279 There are two parts to a "management protocol." The first is the 1280 format of the messages that will be sent, and the second is the 1281 actual protocol that governs the transmission of those messages. 1282 Originally, the PKIX working group developed two documents, [CRMF] 1283 and certificate management message format (CMMF), that together 1284 described the necessary set of message formats, and two other 1285 documents, [CMP] and [CMC], that described protocols for exchanging 1286 those messages. However, the message formats defined in the CMMF 1287 draft were inserted into both [CMP] and [CMC], and thus the (CMMF) 1288 draft has been dropped as a PKIX document. 1290 DOCUMENT TITLE: Certificate Management Messages over CMS (RFC 2797) 1292 DESCRIPTION: This document defines the means by which PKI clients 1293 and servers may exchange PKI messages when using S/MIME's 1294 Cryptographic Message Syntax [CMS] as a transaction envelope. CMC 1295 supports the certificate request message body specified in the 1296 Certificate Request Message Format [CRMF] documents, as well as a 1297 variety of other certificate management messages. The primary 1298 purpose of this specification is to allow the use of an existing 1299 protocol (S/MIME) as a PKI management protocol, without requiring 1300 the development of an entirely new protocol such as CMP. A secondary 1301 purpose is to codify in IETF standards the current industry practice 1302 of using PKCS-10 messages [PKCS10] for certificate requests. 1304 STATUS: Proposed Standard. 1306 DOCUMENT TITLE: Internet X.509 Certificate Request Message Format 1307 (RFC 2511) 1309 DESCRIPTION: CRMF specifies a format recommended for use whenever a 1310 relying party is requesting a certificate from a CA or requesting 1311 that an RA help it get a certificate. The request message format was 1312 needed before many of the other message formats had to be finalized, 1313 and so it was put into a separate document. This document only 1314 specifies the format of a message. Specification of a protocol to 1315 transport that message is beyond the scope of CRMF. 1317 STATUS: Proposed Standard. 1319 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate 1320 Management Protocols (RFC 2510) 1322 Aresenault, Turner November, 2000 26 1323 DESCRIPTION: This document specifies a new protocol specifically 1324 developed for the purpose of transporting messages like those 1325 specified in CRMF among PKI elements. In general, CMP will be used 1326 in conjunction with CRMF, and will then be run over a transfer 1327 service (e.g., S/MIME, HTTP) to provide a complete PKI management 1328 service. 1330 STATUS: Proposed Standard. 1332 DOCUMENT TITLE: Certificate Management Protocols 1335 DESCRIPTION: This document is an update of [CMP]. 1337 STATUS: Under WG review. 1339 DOCUMENT TITLE: Transport Protocols for CMP 1342 DESCRIPTION: This document describes how to layer Certificate 1343 Management Protocols (CMP) over various transport protocols. In 1344 Section 5 of RFC 2510, the process of sending DER-encoded CMP 1345 messages directly over various protocols is specified. Implementers 1346 found that the protocol was lacking in several regards. This 1347 document is an effort to enhance the protocol now in order to avoid 1348 interoperability conflicts later and to make the transport section a 1349 separate draft. 1351 STATUS: Under WG review. 1353 4.4 Policy Outline 1355 As mentioned before, profiling certificates and specifying 1356 operational and management protocols only addresses a part of the 1357 problem of actually developing and implementing a secure PKI. What 1358 is also needed is the development of a certificate policy (CP) and 1359 certification practice statement (CPS), and then following those 1360 documents. The CP and CPS should address physical and personnel 1361 security, subject identification requirements, revocation policy, 1362 and a number of other topics. [POLPROC] provides a framework for 1363 certification practice statements. 1365 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate 1366 Policy and Certification Practices Framework (RFC 2527) 1368 DESCRIPTION: As noted before, the specification and implementation 1369 of certificate profiles, operational protocols, and management 1370 protocols is only part of building a PKI. Equally as important - if 1371 not more important - is the development and enforcement of a 1372 certificate security policy, and a Certification Practice Statement 1373 (CPS). The purpose of this document (PKIX-4) is to establish a clear 1375 Aresenault, Turner November, 2000 27 1376 relationship between certificate policies and CPSs, and to present a 1377 framework to assist the writers of certificate policies or CPSs with 1378 their tasks. In particular, the framework identifies the elements 1379 that may need to be considered in formulating a certificate policy 1380 or a CPS. The purpose is not to define particular certificate 1381 policies or CPSs, per se. 1383 STATUS: Informational RFC. 1385 4.4 Time Stamping and Data Certification 1387 In late 1998, the PKIX working group began two efforts that were not 1388 in the original working group charter, but were deemed to be 1389 appropriate because they described infrastructure services that 1390 could be used to provide desired security services. The first of 1391 these is time stamping, described in [TSP]. Time stamping is a 1392 service in which a trusted third party - a Time Stamp Authority, or 1393 TSA - signs a message, in order to provide evidence that it existed 1394 prior to a given time. Time stamping provides some support for non- 1395 repudiation, in that a user cannot claim that a transaction was 1396 later forged after compromise of a private key, because the 1397 existence of the signed time stamp indicates that the transaction in 1398 question could not have been created after the indicated time. 1400 [TSP] also defines the role of a Temporal Data Authority, or TDA. A 1401 TDA is a Trusted Third Party (TTP) that creates a temporal data 1402 token. This temporal data token associates a message with a 1403 particular event and provides supplementary evidence for the time 1404 included in the time stamp token. For example, a TDA could associate 1405 the message with the most recent closing value of the Dow Jones 1406 Average. The temporal data with which the message is associated 1407 should be unpredictable in order to prevent forward dating of 1408 tokens. The third iteration of the draft removed support for TDAs as 1409 no one in the WG expressed a requirement for the role. 1411 At the Minneapolis IETF meeting, it was disclosed that the materials 1412 covered in [TSP] draft may be covered by patent(s). Use of the 1413 material covered by the patent(s) in question has not be granted by 1414 the patent holder. Thus, anyone interested in implementing the PKIX 1415 [TSP] draft must be aware of this intellectual property issue. 1417 The second new effort is the definition of a Data Validation and 1418 Certification Server, or DVCS, protocol [DVCS]. A DVCS is a Trusted 1419 Third Party that verifies the correctness of specific data submitted 1420 to it. It also allows the delegation of trustworthy servers and 1421 allows for chaining of verifications. 1423 This services offered by DVCS are different from the TSP service in 1424 that a TSA will not attempt to parse or verify a message sent to it 1425 for certification; instead, it will merely append a reliable 1426 indication of the current time, and sign the resulting string-of- 1428 Aresenault, Turner November, 2000 28 1429 bits. This offers an indication that the given string-of-bits 1430 existed at a specified time; it does not offer any indication of the 1431 correctness or relevance of that string of bits. By contrast, the 1432 DVCS certifies possession of data or the validity of another 1433 entity's signature. As part of this, the DVCS verifies the 1434 mathematical correctness of the actual signature value contained in 1435 the request and also checks the full certification path from the 1436 signing entity to a trusted point (e.g., the DVCS's CA, or the Root 1437 CA in a hierarchy). 1439 The DVCS supports non-repudiation in two ways. First, it provides 1440 evidence that a signature or PKC was valid at the time indicated in 1441 the token. The token can be used even after the corresponding PKC 1442 expires and its revocation information is no longer available on 1443 CRLs (for example). Second, the production of a data certification 1444 token in response to a signed request for certification of another 1445 signature or PKC also provides evidence that due diligence was 1446 performed by the requester in validating the signature or PKC. 1448 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Time Stamp 1449 Protocols 1451 DESCRIPTION: This document defines the specification for a time 1452 stamp service. It defines a Time Stamp Authority, or TSA, a trusted 1453 third party who maintains a reliable time service. When the TSA 1454 receives a time stamp request, it appends the current time to the 1455 request and signs it into a token to certify that the original 1456 request existed prior to the indicated time. This helps provide non- 1457 repudiation by preventing someone (either a legitimate user or an 1458 attacker who has successfully compromised a key) from "back-dating" 1459 a transaction. It also makes it more difficult to challenge a 1460 transaction by asserting that it has been back-dated. Note that the 1461 TSA does not provide any data parsing service; that is, the TSA does 1462 not attempt to validate that which it signs; it merely regards it as 1463 a string of bits whose meaning is unimportant, but existence is 1464 vital. 1466 STATUS: In WG Last. 1468 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Data 1469 Certification Server Protocols 1471 DESCRIPTION: This document defines a data validation and 1472 certification service, or DVCS, which can be used to certify both 1473 the existence and correctness of a message or signature. In contrast 1474 to the time stamp service described above, the DVCS certifies 1475 possession of data or the validity of another entity's signature. As 1476 part of this, the DVCS verifies the mathematical correctness of the 1477 actual signature value contained in the request and also checks the 1478 full certification path from the signing entity to a trusted point 1479 (e.g., the DVCS's CA, or the Root CA in a hierarchy). 1481 Aresenault, Turner November, 2000 29 1482 The DVCS supports non-repudiation in two ways. First, it provides 1483 evidence that a signature or public key certificate was valid at the 1484 time indicated in the token. The token can be used even after the 1485 corresponding public key certificate expires and its revocation 1486 information is no longer available on CRLs (for example). Second, 1487 the production of a data certification token in response to a signed 1488 request for certification of another signature or public key 1489 certificate also provides evidence that due diligence was performed 1490 by the requester in validating the signature or public key 1491 certificate. 1493 STATUS: Under WG review. 1495 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Technical 1496 Requirements for a non-Repudiation Service 1499 DESCRIPTION: This document describes those features of a service 1500 which processes signed documents which must be present in order for 1501 that service to constitute a "technical non-repudiation" service. A 1502 technical non-repudiation service must permit an independent 1503 verifier to determine whether a given signature was applied to a 1504 given data object by the private key associated with a given valid 1505 certificate, at a time later than the signature. The features of a 1506 technical non-repudiation service are expected to be necessary for a 1507 full non-repudiation service, although they may not be sufficient. 1509 This document is intended to clarify the definition of the "non- 1510 repudiation" service in RFC 2459. It should thus serve as a guide 1511 to when the nonRepudiation bit of the keyUsage extension should be 1512 set and to when a Certificate Authority is required to archive 1513 CRL's. 1515 STATUS: Under WG Review. 1517 4.5 Expired Drafts 1519 There have been numerous drafts that have been produced by the 1520 working group that for some reason or another did not make it to RFC 1521 status. The following is a list of these drafts. 1523 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate 1524 Management Message Formats 1526 DESCRIPTION: This document contained the formats for a series of 1527 messages important in certificate and PKI management. These messages 1528 let CA's, RA's, and relying parties communicate with each other. 1529 Note that this document only specified message formats; it did not 1530 specify a protocol for transferring messages. That protocol could 1531 have be either CMP or CMC, or perhaps another custom protocol. 1533 Aresenault, Turner November, 2000 30 1534 STATUS: Work has been discontinued. All useful information from it 1535 has been moved into [CMP] and [CMC]. 1537 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Enhanced 1538 CRL Distribution Options (OpenCDP) 1540 DESCRIPTION: This document proposed an alternative to the CRL 1541 Distribution Point (CDP) approach documented in [FORMAT]. OCDP 1542 separates the CRL location function from the process of certificate 1543 and CRL validation, and thus claimed some benefits over the CDP 1544 approach. 1546 STATUS: Work has been discontinued, as all useful information has 1547 been incorporated into [X.509]. An updated [FORMAT] RFC should 1548 profile the use of the CDP approach. 1550 DOCUMENT TITLE: Internet Public Key Infrastructure: Caching the 1551 Online Certificate Status Protocol 1553 DESCRIPTION: To improve the degree to which it can scale, OCSP 1554 allows caching of responses - e.g., at intermediary servers, or even 1555 at the relying party's end system. This document described how to 1556 support OCSP caching at intermediary servers. 1558 STATUS: Work has been discontinued. 1560 DOCUMENT TITLE: WEB based Certificate Access Protocol-- WebCAP/1.0 1562 DESCRIPTION: This document specified a set of methods, headers, and 1563 content-types ancillary to HTTP/1.1 to publish, retrieve X.509 PKCs 1564 and Certificate Revocation Lists. This protocol also facilitated 1565 determining current status of a digital certificate without the use 1566 of CRLs. This protocol defined new methods, request and response 1567 bodies, error codes to HTTP/1.1 protocol for securely publishing, 1568 retrieving, and validating certificates across a firewall. 1570 STATUS: Expired. 1572 DOCUMENT TITLE: Basic Event Representation Token 1574 DESCRIPTION: This document defined a finite method of representing a 1575 discrete instant in time as a referable event. The Basic Event 1576 Representation Token (BERT) was a light-weight binary token designed 1577 for use in large numbers over short periods of time. The tokens 1578 contained only a single instance of an event stamp and the trust 1579 process is referenced against an external reference. 1581 STATUS: Expired. 1583 Aresenault, Turner November, 2000 31 1584 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Extending 1585 trust in non repudiation tokens in time 1587 DESCRIPTION: This document described a method to maintain the trust 1588 in a token issued by a non-repudiation Trusted Third Party (NR TTP) 1589 (DVCS/TSA/TDA) after the key initially used to establish trust in 1590 the token expires. The document described a general format for 1591 storage of DVCS/TS/TDA tokens for this purpose, which establishes a 1592 chain of custody for the data. 1594 STATUS: Expired. 1596 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure 1597 Representation of Elliptic Curve Digital Signature Algorithm (ECDSA) 1598 Keys and Signatures in Internet X.509 Public Key Infrastructure 1599 Certificates 1601 DESCRIPTION: This document provided Object Identifiers (OIDs) and 1602 other guidance for IPKI users who use the Elliptic Curve Digital 1603 Signature Algorithm (ECDSA). It profiled the format and semantics of 1604 the subjectPublicKeyInfo field and the keyUsage extension in X.509 1605 v3 PKCs containing ECDSA keys. This document should have been used 1606 by anyone wishing to support ECDSA; others who do not support ECDSA 1607 are not required to comply with it. 1609 STATUS: Finished WG Last Call. Merged into Representation of Public 1610 Keys and Digital Signatures in Internet X.509 Public Key 1611 Infrastructure Certificates. 1613 DOCUMENT TITLE: A String Representation of General Name 1615 DESCRIPTION: This document specified a string format for the ASN.1 1616 construct GeneralName. 1618 STATUS: Expired. 1620 DOCUMENT TITLE: OCSP Extensions 1622 DESCRIPTION: This document defined Internet-standard extensions to 1623 OCSP that enable a client to delegate processing of certificate 1624 acceptance functions to a trusted server. The client could control 1625 the degree to which delegation takes place. In addition limited 1626 support was provided for delegating authorization decisions. 1628 STATUS: The work has been incorporated into [DPV] and [DPD]. 1630 DOCUMENT TITLE: Using HTTP as a Transport Protocol for CMP 1632 DESCRIPTION: This document described how to layer [CMP] over [HTTP]. 1633 A simple method for doing so was described in [CMP], but that method 1634 does not accommodate a polling mechanism, which may be required in 1636 Aresenault, Turner November, 2000 32 1637 some environments. This document specified an alternative method 1638 that used the polling protocol defined in [CMP]. A new Content-Type 1639 for messages was also defined. 1641 STATUS: The work has been merged into [TPCMP]. 1643 DOCUMENT TITLE: Using TCP as a Transport Protocol for CMP 1645 DESCRIPTION: This document described how to layer Certificate 1646 Management Protocols [CMP] over [TCP]. A method for doing so is 1647 described in [CMP], but that method did not solve problems 1648 encountered by implementors. This document specified an enhanced 1649 method which extends the protocol. 1651 STATUS: The work has been merged into [TPCMP]. 1653 5 Implementation Advice 1655 This section provides guidance to those who would implement various 1656 parts of the PKIX suite of documents. The topics discussed in this 1657 section engendered significant discussion in the working group, and 1658 there, was at times, either widespread disagreement or widespread 1659 misunderstanding of them. Thus, this discussion is provided to help 1660 readers of the PKIX document set understand these issues, in the 1661 hope of fostering greater interoperability among eventual PKIX 1662 implementations. 1664 5.1 Names 1666 PKIX has been referred to as a "name-centric" PKI because the PKCs 1667 associate public keys with names of entities. Each PKC contains at 1668 least one name for the owner of a particular public key. The name 1669 can be an X.500 distinguished name, contained in the subjectDN field 1670 of the PKC. There can also be names such as RFC822 e-mail addresses, 1671 DNS domain names, and uniform resource identifiers (URIs) associated 1672 with the key; these attributes are kept in the subjectAltName 1673 extension of the PKC. A PKC must contain at least one of these name 1674 forms, it may contain multiple forms if deemed appropriate by the CA 1675 based on the intended usage of the PKC. 1677 5.1.1 Name Forms 1679 There are two possible places to put a name in an X.509 v3 PKC. One 1680 is the subject field in the base PKC (often called the 1681 "Distinguished Name" or "DN" field), and the other is in the 1682 subjectAltName extension. 1684 5.1.1.1 Distinguished Names 1686 According to [FORMAT], a CA's PKC must have a non-null value in the 1687 subject field, while EE's PKCs are permitted to have an empty 1689 Aresenault, Turner November, 2000 33 1690 subject field. If a PKC has a non-null subject field, it MUST 1691 contain an X.500 Distinguished Name. 1693 5.1.1.2 SubjectAltName Forms 1695 In addition to the DN, a PKIX PKC may have one or more values in the 1696 subjectAltName extension. 1698 The subjectAltName extension allows additional identities to be 1699 bound to the subject of the PKC (e.g., it allows "umbc.edu" and 1700 "130.85.1.3" to be associated with a particular subject, as well as 1701 "C=US, O=University of Maryland, L=Baltimore, CN=UMBC"). X.509- 1702 defined options for this extension include: Internet electronic mail 1703 addresses; DNS names; IP addresses; and URIs. Other options can 1704 exist, including locally-defined name forms. 1706 A single subjectAltName extension can include multiple name forms, 1707 and multiple instances of each name form. 1709 Whenever such alternate name forms are to be bound into a PKC, the 1710 subjectAltName (or issuerAltName) extension must be used. It is 1711 technically possible to embed an alternate name form in the subject 1712 field. For example, one could make a DN contain an IP address via a 1713 kludge such as "C=US, L=Baltimore, CN=130.85.1.3". However, this 1714 usage is deprecated; the alternative name extension is the preferred 1715 location for finding such information. As another example, some 1716 legacy implementations exist where an RFC822 name is embedded in the 1717 subject distinguished name as an EmailAddress attribute. Per 1718 [FORMAT], PKIX-compliant implementations generating new PKCs with 1719 electronic mail addresses MUST use the rfc822Name in the 1720 subjectAltName extension to describe such EEs. Simultaneous 1721 inclusion of the EmailAddress attribute in the subject distinguished 1722 name to support legacy implementation is deprecated but permitted. 1724 In line with this, if the only subject identity included in a PKC is 1725 an alternative name form, then the subject distinguished name must 1726 be empty (technically, an empty sequence), and the subjectAltName 1727 extension must be present. If the subject field contains an empty 1728 sequence, the subjectAltName extension must be marked critical. 1730 If the subjectAltName extension is present, the sequence must 1731 contain at least one entry. Unlike the subject field, conforming CAs 1732 shall not issue PKCs with subjectAltNames containing empty 1733 GeneralName fields. For example, an rfc822Name is represented as an 1734 IA5String. While an empty string is a valid IA5String, such an 1735 rfc822Name is not permitted by PKIX. The behavior of clients that 1736 encounter such a PKC when processing a certification path is not 1737 defined by this working group. 1739 Aresenault, Turner November, 2000 34 1740 Because the subject's alternative name is considered to be 1741 definitively bound to the public key, all parts of the subject's 1742 alternative name must be verified by the CA. 1744 5.1.1.2.1 Internet e-mail addresses 1746 When the subjectAltName extension contains an Internet mail address, 1747 the address is included as an rfc822Name. The format of an 1748 rfc822Name is an "addr-spec" as defined in [RFC-822]. An addr-spec 1749 has the form local-part@domain; it does not have a phrase (such as a 1750 common name) before it, or a comment (text surrounded in 1751 parentheses) after it, and it is not surrounded by "<" and ">". 1753 5.1.1.2.2 DNS Names 1755 When the subjectAltName extension contains a domain name service 1756 label, the domain name is stored in the dNSName attribute(an 1757 IA5String). The string shall be in the "preferred name syntax," as 1758 specified by [DNS]. Note that while upper and lower case letters are 1759 allowed in domain names, no significance is attached to the case. In 1760 addition, while the string " " is a legal domain name, 1761 subjectAltName extensions with a dNSName " " are not permitted. 1762 Finally, the use of the DNS representation for Internet mail 1763 addresses (wpolk.nist.gov instead of wpolk@nist.gov) is not 1764 permitted; such identities are to be encoded as rfc822Name. 1766 5.1.1.2.3 IP addresses 1768 When the subjectAltName extension contains an iPAddress, the address 1769 shall be stored in the octet string in "network byte order," as 1770 specified in [IP]. The least significant bit (LSB) of each octet is 1771 the LSB of the corresponding byte in the network address. For IP 1772 Version 4, as specified in [IP], the octet string must contain 1773 exactly four octets. For IP Version 6, as specified in [IPv6], the 1774 octet string must contain exactly sixteen octets. 1776 5.1.1.2.4 URIs 1778 [FORMAT] notes "When the subjectAltName extension contains a URI, 1779 the name MUST be stored in the uniformResourceIdentifier (an 1780 IA5String). The name MUST be a non-relative URL, and MUST follow the 1781 URL syntax and encoding rules specified in [RFC 1738]. The name must 1782 include both a scheme (e.g., "http" or "ftp") and a scheme-specific- 1783 part. The scheme-specific-part must include a fully qualified domain 1784 name or IP address as the host. As specified in [RFC 1738], the 1785 scheme name is not case-sensitive (e.g., "http" is equivalent to 1786 "HTTP"). The host part is also not case-sensitive, but other 1787 components of the scheme-specific-part may be case-sensitive. When 1788 comparing URIs, conforming implementations MUST compare the scheme 1789 and host without regard to case, but assume the remainder of the 1790 scheme-specific-part is case sensitive." 1792 Aresenault, Turner November, 2000 35 1793 5.1.2 Scope of Names 1795 The original X.500 work presumed that every subject in the world 1796 would have a globally unique distinguished name. Thus, every subject 1797 could be easily located, and there would never be a conflict. All 1798 that would be needed is a sufficiently large name space, and rules 1799 for constructing names based on subordination and location. 1801 Obviously, that is not practical in the real world, for a variety of 1802 reasons. There is no single entity in the world trusted by everybody 1803 to reside at the top of the name space, and there is no way to 1804 enforce uniqueness on names for all entities. (These were among the 1805 reasons for the failure of PEM to be widely implemented.) 1807 This does not mean, however, that a name-based PKI cannot work. It 1808 is important to recognize that the scope of names in PKIX is local; 1809 they need to be defined and unique only within their own domain. 1811 Suppose for example that a Top CA is established with DN "O=IETF, 1812 OU=PKIX, CN=PKIX_CA". That CA will then issue PKCs for subjects 1813 subordinate to it. The only requirement, which can be enforced 1814 procedurally, is that no two distinct entities beneath this Top CA 1815 have the same name. We can't prevent somebody else in the world from 1816 creating her own CA, called "O=IETF, OU=PKIX, CN=PKIX_CA", and it is 1817 not necessary to do so. Within the domain of the original Top CA, 1818 there will be no conflict, and the fact that there is another CA of 1819 the same name in some other domain is irrelevant. 1821 This is analogous to the current DNS or IP address situations. On 1822 the Internet, there is only one node called www.ietf.org. The fact 1823 that there might be 10 different intranets, each with a host given 1824 the DNS name www.ietf.org, is irrelevant and causes no 1825 interoperability problems - those are different domains. However, if 1826 there were to be another node on the Internet with domain name 1827 www.ietf.org, then there would be a problem due to name duplication. 1829 The same applies for IP addresses. As long as only one node on the 1830 Internet responds to the IP address 130.85.1.3, there is no problem, 1831 despite the fact that there are 100 different corporate Intranets, 1832 each using that same IP address. However, if two different nodes on 1833 the Internet each responded to the IP address 130.85.1.3, there 1834 would be a problem. 1836 5.1.3 Certificate Path Construction 1838 Certificate path construction has been the topic of many discussions 1839 in the WG. The issue centered on how best to get a certificate when 1840 the connection between the subject's name and the name of their CA, 1841 as well as the CA's repository (or directory), may not be obvious. 1842 Many proposals were put forth, including implementing a global X.500 1844 Aresenault, Turner November, 2000 36 1845 Directory Service, using DNS SRV records, and using an extension to 1846 point to the directory provider. At the end of the discussion the 1847 group decided to use the authority information access extension 1848 defined in [FORMAT], which allows the CA to indicate the access 1849 method and location of CA information and services. The extension 1850 would be included in subject's certificates and could be used to 1851 associate an Internet style identity for the location of repository 1852 to retrieve the issuer's certificate in cases where such a location 1853 is not related to the issuer's name. 1855 Another discussion related to certificate path construction was 1856 where to store the CA and EE PKCs in the directory (specifically 1857 LDAPv2 directories). Two camps emerged with different views on where 1858 to store CA and cross-certificates. In the CA's directory entry, one 1859 camp wanted self-issued PKCs stored in the cACertificate attribute, 1860 PKCs issued to this CA stored in the forward element of the 1861 crossCertificatePair, and PKCs issued from this CA for other CAs in 1862 the reverse element of the crossCertificatePair attribute. The other 1863 camp wanted all CA PKCs stored in the cACertificate attribute, and 1864 PKCs issued to and from another domain stored in the 1865 crossCertificatePair attribute. There was a short discussion that 1866 the second was more efficient than first and that one solution or 1867 the other was more widely deployed. The end result was to indicate 1868 that self-issued PKCs and PKCs issued to the CA by CAs in the same 1869 domain as the CA are stored in the cACertificate attribute. The 1870 crossCertificatePair attribute's forward element will include all 1871 but self-issued PKCs issued to the CA. The reverse element may 1872 include a subset of PKCs issued by the CA to other CAs. With this 1873 resolution both camp's implementations are supported and are free to 1874 choose the location of CA PKCs to best support their implementation. 1876 5.1.4 Name Constraints 1878 A question that has arisen a number of times is "how does one 1879 enforce Name constraints when there is more than one name form in a 1880 PKC?" That is, [FORMAT] states that: 1882 Subject's alternative names may be constrained in the same manner as 1883 subject distinguished names using the name constraints extension as 1884 described in section 4.2.1.11. 1886 What does this mean? Suppose that there is a CA with DN "O=IETF, 1887 OU=PKIX, CN=PKIX_CA", with the subjectAltName extension having 1888 dNSName "PKIX_CA.IETF.ORG". Suppose that that CA has issued a PKC 1889 with an empty DN, with subjectAltName extension having dNSName set 1890 to "PKIX_CA.IETF.ORG", and rfc822Name set to Steve@PKIX_CA.IETF.ORG. 1891 The question is: are name constraints enforced on these two PKCs - 1892 is the name of the EE PKC considered to be properly subordinate to 1893 the name of the CA? 1895 Aresenault, Turner November, 2000 37 1896 The answer is "yes". The general rules for deciding whether a PKC 1897 meets name constraints are: 1899 - If a PKC complies with name constraints in any one of its name 1900 forms, then the PKC is deemed to comply with name constraints. 1902 - If a PKC contains a name form that its issuer does not, the PKC 1903 is deemed to comply with name constraints for that name form. 1905 In deciding whether a name form meets name constraints, the 1906 following rules apply (in all cases Name B is the name in the name 1907 constraints extension): 1909 5.1.4.1 rfc822Names 1911 Three variations are allowed: 1913 - If the name constraint is specified as "larry@mail.mit.edu", then 1914 Name A is subordinate to Name B (in B's subtree) if Name A 1915 contains all of Name B's name (specifies a particular mailbox). 1916 For example, larry@mail.mit.edu is subordinate, but 1917 larry_sanders@mail.mit.edu is not. 1919 - If the name constraint is specified as "mail.mit.edu", then Name 1920 A is subordinate to Name B (in B's subtree) if Name A contains 1921 all of Name B's name (specified all mailboxes on host 1922 mail.mit.edu). For example, curly@mail.mit.edu and 1923 mo@mail.mit.edu are subordinate, but mo@mail6.mit.edu and 1924 curly@smtp.mail.mit.edu are not. 1926 - If the name constraint is specified as ".mit.edu", then Name A is 1927 subordinate to Name B (in B's subtree) if Name A contains all of 1928 Name B's name, with the addition of zero or more additional host 1929 or domain names to the left of Name B's name. That is, 1930 smtp.mit.edu is subordinate to .mit.edu, as is pop.mit.edu. 1931 However, mit.edu is not subordinate to .mit.edu. When the 1932 constraint begins with a "." it specifies any address within a 1933 domain. In the previous example, "mit.edu" is not in the domain 1934 of ".mit.edu". 1936 Note: If rfc822 names are constrained, but the PKC does not 1937 contain a subjectAltName extension, the EmailAddress attribute 1938 will be used to constrain the name in the subject distinguished 1939 name. For example (c is country, o is organization, ou is 1940 organizational unit, and em is EmailAddress), Name A ("c=US, 1941 o=MIT, ou=CS, em=curly@mail.mit.edu") is subordinate to Name B 1942 ("c=US, o=MIT, ou=CS") (in B's subtree) if Name A contains all of 1943 Name B's names. 1945 Aresenault, Turner November, 2000 38 1946 5.1.4.2 dNSNames 1948 Name A is subordinate to Name B (in B's subtree) if Name A contains 1949 all of Name B's name, with the addition of zero or more additional 1950 domain names to the left of Name B's name. That is, www.mit.edu is 1951 subordinate to mit.edu, as is larry.cs.mit.edu. However, www.mit.edu 1952 is not subordinate to web.mit.edu. 1954 5.1.4.3 x.400 addresses 1956 Name A is subordinate to Name B (in B's subtree) if Name A contains 1957 all of Name B's name. For example (c is country-name, admd is 1958 administrative-domain-name, and o is organization-name, ou is 1959 organizational-unit-name, pn is personal-name, sn=surname, and gn is 1960 given-name in both Name A and B), the mnemonic X.400 address (using 1961 PrintableString choices for c and admd) "c=US, admd=AT&T, o=MIT, 1962 ou=cs, pn='sn=Doe,gn=John'" is subordinate to "c=US, admd=AT&T, 1963 o=MIT, ou=cs" and "c=US, admd=AT&T, o=MIT, pn='sn=DOE,gn=JOHN'" (pn 1964 is a SET that includes, among other things, sn and gn). 1966 5.1.4.5 DNs 1968 Name A is subordinate to Name B (in B's subtree), if Name A contains 1969 all of Name B's name, treating attribute values encoded in different 1970 types as different strings, ignoring case in PrintableString (in all 1971 other types case is not ignored), removing leading and trailing 1972 white space in PrintableString, and converting internal substrings 1973 of one or more consecutive white space characters to a single space. 1974 For example, (c is country, o is organization, ou is organizational 1975 unit, and cn is common name): 1977 - Assuming PrintableString types for all attribute values in Name A 1978 and B, "c=US, o=MIT, ou=CS" is subordinate to "c=us, o=MIT, 1979 ou=cs", as is "c=US, o=MIT, ou=CS, ou=administration". Another 1980 example, "c=US, o=MIT, ou=CS, cn= John Doe" (note the white 1981 spaces) is subordinate to "c=US, o=MIT, ou=CS, cn=John Doe". 1983 - Assuming UTF8String types for all attribute values in Name A and 1984 B, "c=US, o=MIT, ou=CS, ou=administration" is subordinate to 1985 "c=US, o=MIT, ou=CS", but "c=US, o=MIT, ou=cs, 1986 ou=Administration". "c=US, o=MIT, ou=CS, cn= John Smith" (note 1987 the white spaces) is not subordinate to "c=US, o=MIT, ou=CS, cn= 1988 John Smith". 1990 - Assuming UTF8String types for all attribute values in Name A and 1991 PrintableString types for all attribute values in Name B, "c=US, 1992 o=MIT, ou=cs" is subordinate to "c=US, o=MIT, ou=CS" if the 1993 verification software supports the full comparison algorithm in 1994 the X.500 series. "c=US, o=MIT, ou=cs" is NOT subordinate to 1995 "c=US, o=MIT, ou=CS" if the verification software supports the 1996 comparison algorithm in [FORMAT]. 1998 Aresenault, Turner November, 2000 39 1999 5.1.4.6 URIs 2001 The constraints apply only to the host part of the name. Two 2002 variations are allowed: 2004 - If the name constraint is specified as ".mit.edu", then Name A is 2005 subordinate to Name B (in B's subtree) if Name A contains all of 2006 Name B's name, with the addition of zero or more additional host 2007 or domain names to the left of Name B's name. That is, 2008 www.mit.edu is subordinate to .mit.edu, as is curly.cs.mit.edu. 2009 However, mit.edu is not subordinate to .mit.edu. When the 2010 constraint begins with a "." it specifies a host. 2012 - If the name constraint is specified as "abc.mit.edu", then Name A 2013 is subordinate to Name B (in B's subtree) if Name A contains all 2014 of Name B's name. No leftward expansion of the host or domain 2015 name is allowed. 2017 5.1.4.7 iPaddresses 2019 Two variations are allowed depending on the IP version: 2021 - For IPv4 addresses: Name A (128.32.1.1 encoded as 80 20 01 01) is 2022 subordinate to Name B (128.32.1.0/255.255.255.0 encoded as 80 20 2023 00 00 FF FF FF 00) (in B's subtree) if Name A falls within the net 2024 denoted in Name B's CIDR notation. 2026 - For IPv6 addresses: Name A (4224.0.0.0.8.2048.8204.16762 encoded 2027 as 10 80 00 00 00 00 00 00 00 08 08 00 20 0C 41 7A) is subordinate 2028 to Name B (4224.0.0.0.8.2048.8204.0/ 2029 65535.65535.65535.65535.65535.65535.65535.0 encoded as 2030 10 80 00 00 00 00 00 00 00 08 08 00 20 0C 00 00 2031 FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 00) (in B's subtree) 2032 if Name A falls within the net denoted in Name B's CIDR notation. 2034 5.1.4.8 Others 2036 As [FORMAT] does not define requirements for the name forms 2037 otherName, ediPartyName, or registeredID there are no corresponding 2038 name constraints requirements. 2040 5.1.5 Wildcards in Name Forms 2042 A "wildcard" in a name form is a placeholder for a set of names 2043 (e.g., "*.mit.edu" meaning "any domain name ending in .mit.edu", and 2044 *@aol.com meaning "email address that uses aol.com"). There are many 2045 people who believe that allowing wildcards in name forms in PKIX 2046 PKCs would be a useful thing to do, because it would allow a single 2047 PKC to be used by all members of a group. These members would 2048 presumably have attributes in common; e.g., access rights to some 2050 Aresenault, Turner November, 2000 40 2051 set of resources, and so issuance of a PKC with a wildcard for the 2052 group would simplify management. 2054 After much discussion, the PKIX working group decided to permit the 2055 use of wildcards in PKCs. That is, it is permissible for a PKIX- 2056 conformant CA to issue a PKC with a wildcard. However, the semantics 2057 of subjectAltName extension that include wildcard characters are not 2058 addressed by PKIX. Applications with specific requirements may use 2059 such names but must define the semantics. 2061 5.1.6 Name Encoding 2063 A very important topic that consumed much of the WG's time was the 2064 implementation of the directory string choices. While the long term 2065 goal of the IETF was clear, use UTF8String, the short term goals 2066 were not so clear. Many implementations only use PrintableString, 2067 others use BMPString, and still others use Latin1String (ISO 8859-1) 2068 and tag it as TeletexString (there are others still). To ensure that 2069 there is consistency with encodings [FORMAT] defines a set of rules 2070 for the string choices. PrintableString was kept as the first choice 2071 because of it's widespread support by vendors. BMPString was the 2072 second choice, also for it's widespread vendor support. Failing 2073 support by PrintableString and BMPString, UTF8String must be used. 2074 In keeping with the IETF mandate, UTF8String can be used at any time 2075 if the CA supports it. Also, processing implementations that wish to 2076 support TeletexString should handle the entire ISO 8859-1 character 2077 set and not just the Latin1String subset. 2079 5.2 POP 2081 Proof of Possession, or POP, or also CA POP, means that the CA is 2082 adequately convinced that the entity requesting a PKC containing a 2083 public key Y has access to the private key X corresponding to that 2084 public key. 2086 There has been some debate whether POP was or not needed. 2088 This question needs to be addressed separately considering the 2089 context of use of the key, in particular whether a key is used for 2090 an authentication or non repudiation service, or in a 2091 confidentiality service. Note that this does not map to the key 2092 usage bit directly, since it is possible to use a confidentiality 2093 key to perform an authentication service, e.g. by asking to decrypt 2094 an encrypted challenge. 2096 5.2.1 POP for Signing Keys 2098 It is important to provide POP for keys used to sign material, in 2099 order to provide non-repudiation of transactions. For example, 2100 suppose Alice legitimately has private key X and its corresponding 2101 public key Y. Alice has a PKC from Charlie, a CA, containing Y. 2103 Aresenault, Turner November, 2000 41 2104 Alice uses X to sign a transaction T. Without POP, Mal could also 2105 get a PKC from Charlie containing the same public key, Y. Now 2106 without POP, there are two possible threats: Mal could claim to have 2107 been the real signer of T; or Alice can falsely deny signing T, 2108 claiming that it was instead Mal. Since no one can reliably prove 2109 that Mal did or did not ever possess X, neither of these claims can 2110 be refuted, and thus the service provided by and the confidence in 2111 the PKI has been defeated. (Of course, if Mal really did possess X, 2112 Alice's private key, then no POP mechanism in the world will help, 2113 but that is a different problem.) 2115 Protection can be gained by having Alice, as the true signer of the 2116 transaction, include in the signed information her PKC or an 2117 identifier of her PKC (e.g., a hash of her PKC). This makes 2118 impossible for Mal to claim authorship because he does not know the 2119 private key from Alice and thus is unable to include his certificate 2120 under the signature. 2122 The adequate protection may be obtained in the general case, by 2123 mandating the inclusion of a reference of the certificate every time 2124 a signature (or non repudiation) key is being used in a protocol. 2126 However, because all the protocols were not doing so, a conservative 2127 measure has been taken by requesting POP to be performed by CAs. It 2128 should thus be understood, that this measure is not strictly 2129 necessary and is only a temporary measure to make old protocols 2130 secure. New protocols or data formats are being developed. If the 2131 key being used is always used in a context where the identifier of 2132 the certificate is included in the protocol, then POP by the CA is 2133 not necessary. The inclusion of the identifier of the certificate in 2134 the protocol or data format may be understood as POP being performed 2135 at the transaction time rather than by the CA, at the registration 2136 time of the user in the PKI. 2138 5.2.2 POP for Key Management Keys 2140 Suppose that Al is a new instructor in the Computer Science 2141 Department of a local University. Al has created a draft final exam 2142 for the Introduction to Networking course he is teaching. He wants 2143 to send a copy of the draft final to Dorothy, the Department Head, 2144 for her review prior to giving the exam. This exam will of course be 2145 encrypted, as several students have access to the computer system. 2146 However, a quick search of the PKC repository (e.g., search the 2147 repository for all records with subjectPublicKey=Dorothy's-value) 2148 turns up the fact that several students have PKCs containing the 2149 same public key management key as Dorothy. At this point, if no POP 2150 has been done by the CA, Al has no way of knowing whether all of the 2151 students have simply created these PKCs without knowing the 2152 corresponding private key (and thus it is safe to send the encrypted 2153 exam to Dorothy), or whether the students have somehow acquired 2155 Aresenault, Turner November, 2000 42 2156 Dorothy's private key (and thus it is certainly not safe to send the 2157 exam). 2159 The later case may seem unsafe. However, if the other students have 2160 acquired the key, they do not even need to publish their 2161 certificates and can simply decrypt in parallel. 2163 The end story is that, if the key only known to Dorothy, there is no 2164 problem. Thus POP by the CA is not needed. 2166 If the key, like a Diffie-Hellman key, is used for an authentication 2167 service the answer depends from the protocol being used. In the 2168 former example, the decryption was done locally and no data was sent 2169 back on the wire. In an authentication protocol, the story is 2170 different because either some encrypted or decrypted data is sent 2171 back. If the data sent back contains the identifier of the 2172 certificate in a way that it cannot be modified without that 2173 modification being detected, then there is no need for POP. On the 2174 contrary, POP by the CA is needed. 2176 As a conservative measure, POP for encryption keys is recommended, 2177 but it should be realized that it is not always needed. 2179 In general it should be noticed that POP at the time of the 2180 transaction is much superior than POP made by the CA, since it is 2181 possible in real time to be sure that everything is correct, rather 2182 than rely on that verification to be done at the time of 2183 registration by the CA. Should the CA fail in that verification, 2184 then there is a security breach. On the contrary, doing POP at the 2185 time of the transaction, eliminates that problem. 2187 CMP requires that POP be provided for all keys, either through on- 2188 line or out-of-band means. There are any number of ways to provide 2189 POP, and the choice of which to use is a local matter. Additionally, 2190 a PKC requester can provide POP to either a CA or to an RA, if the 2191 RA can adequately assure the CA that POP has been performed. Some of 2192 the acceptable ways to provide POP include: 2194 - Out-of-band means: 2196 - For keys generated by the CA or an RA (e.g., on a token such as 2197 a smart card or PCMCIA card), possession of the token can 2198 provide adequate proof of possession of the private key. 2200 - For user-generated keys, another approach can be used in 2201 environments where "key recovery" requirements force the 2202 requester to provide a copy of the private key to the CA or an 2203 RA. In this case, the CA will not issue the requested PKC until 2204 such time as the requester has provided the private key. This 2205 approach is in general not recommended, as it is extremely 2206 risky (e.g., the system designers need to figure out a way to 2208 Aresenault, Turner November, 2000 43 2209 protect the private keys from compromise while they are being 2210 sent to the CA/RA/other authority, and how to protect them 2211 there), but it can be used. 2213 - On-line means: 2215 - For signature keys that are generated by an EE, the requester 2216 of a PKC can be required to sign some piece of data (typically, 2217 the PKC request itself) using the private key. The CA will then 2218 use the requested public key to verify the signature. If the 2219 signature verification works, the CA can safely conclude that 2220 the requester had access to the private key. If the signature 2221 verification process fails, the CA can conclude that the 2222 requester did not have access to the correct private key, and 2223 reject the request. 2225 - For key management keys that are generated by the requester, 2226 the CA can send the user the requested public key, along with 2227 the CA's own public key, to encrypt some piece of data, and 2228 send it to the requester to be decrypted. For example, the CA 2229 can generate some random challenge, and require some action to 2230 be taken after decryption (e.g., "decrypt this encrypted random 2231 number and send it back to me"). If the requester does not take 2232 the requested action, the CA concludes that the requester did 2233 not possess the private key, and the PKC is not issued. 2235 Another method of providing POP for key management keys is for the 2236 CA to generate the requested PKC, and then send it to the requester 2237 in encrypted form. If the requester does not have access to the 2238 appropriate private key, the requester cannot decrypt the PKC, and 2239 thus cannot use it. After some period of time in which the PKC is 2240 not used, the CA will revoke the PKC. (This only works if the PKC is 2241 not made available to any untrusted entities until after the 2242 requester has successfully decrypted it.) 2244 5.3 Key Usage Bits 2246 The key usage extension defines the purpose (e.g., encipherment, 2247 signature, certificate signing) of the key contained in the PKC. 2248 This extension is used when a key that could be used for more than 2249 one operation is to be restricted. For example, if a CA's RSA key 2250 should be used only for signing CRLS, the cRLSign bit would be 2251 asserted. Likewise, when an RSA key should be used only for key 2252 management, the keyEncipherment bit would be asserted. When used, 2253 this extension should be marked critical. 2255 [FORMAT] includes some text for how the bits in the KeyUsage type 2256 are used. Developing the text for some of the bits was easy; 2257 however, many discussions were needed to arrive at a common 2258 agreement on the meaning of the digitalSignature (DS bit) and 2259 nonRepudiation (NR bit) bits and when they should be set. The group 2261 Aresenault, Turner November, 2000 44 2262 quickly realized that key usage extension mixes services and 2263 mechanisms. The DS bit indicates a mechanism - a public key used to 2264 verify a digital signature. The NR bit indicates a service - a 2265 public key used to verify a digital signature and to provide a non- 2266 repudiation service. When trying to indicate when each bit should be 2267 indicated arguments were based on: 2269 The lifetime of the object being singed. Some felt that the DS bit 2270 should be set when the certificate is used to sign ephemeral objects 2271 (e.g., bind tokens) while the NR bit should be set for things that 2272 are survive longer (e.g., documents). Of course, the problem with 2273 this distinction to determine how long is the time period for 2274 ephemeral? 2276 A conscious act taken by the signer. Many felt that the NR bit 2277 should be set only when the subject has expressly acknowledged that 2278 they want to use the private key to sign an object. Signing a 2279 document say where there is a conscious decision by the subject 2280 would be appropriate for the key usage extension to contain NR, but 2281 when the key is used for authentication purposes, which can occur 2282 automatically and more frequently, the DS bit is more appropriate. 2283 The discussion also concluded that since some authentication schemes 2284 occur automatically, that the DS bit and NR bit should never be set 2285 together in the same certificate. Some agreed to the differentiation 2286 of the bits based on the time, but did not agree that the two could 2287 not be in the same key usage extension. 2289 The procedures followed by the CA. Some felt that NR bit was kind of 2290 'quality mark' indicating to the verifier that the verifier could be 2291 assured that the CA is implementing appropriate procedures for 2292 checking the subject's identity, performing certificate archival, 2293 etc. Other felt that it was not entirely the CAs job and that some 2294 other entity must be involved. 2296 In the end the WG agreed to a few things: 2298 - Provision of the service of non-repudiation requires more than a 2299 single bit set in a PKC. It requires an entire infrastructure of 2300 components to preserve for some period of time the keys, PKCs, 2301 revocation status, signed material, etc., as well as a trusted 2302 source of time. However, the nonRepudiation key usage bit is 2303 provided as an indicator that such keys could be used as a 2304 component of a system providing a non-repudiation service. 2306 - The certificate policy is the appropriate place to indicate the 2307 permitted combinations of key usages. That is, a policy may 2308 indicate that the DS and NR bits can not be set in the same 2309 certificate while another may say that the DS and NR bits can be 2310 set in the same certificate. 2312 [2459bis] includes new text indicating the above agreements. 2314 Aresenault, Turner November, 2000 45 2315 5.4 Non-Repudiation 2317 The major benefit of the whole DS bit vs NR bit discussion is 2318 development of the Technical Requirements for Non-Repudiation 2319 [TECHNR] draft. To fill this void [TECHNR] was developed to 2320 "describe those features of a service which processes signed 2321 documents which must be present in order for that service to 2322 constitute a 'technical non-repudiation' service." The basic 2323 understanding of non-repudiation is that it requires that a digital 2324 signature be preserved in such a manner that it can convince a 2325 neutral third party that it was actually created by someone with 2326 access to the private key of a certified key pair. Whether this 2327 definition of non-repudiation is enough to form a legally bind 2328 agreement is still being debated. 2330 5.5 Trust Models 2332 An important design decision is where a particular EE's trust point 2333 is located (i.e., where is the EE's Root CA). There are a number of 2334 models that have been developed and depending on the environment 2335 some models may be more suited than others. The following provides 2336 some background on the models. 2338 5.5.1 Hierarchical 2340 One of the initial trust models proposed was the hierarchical model. 2341 In this model the trust point or root CA for an entire domain is the 2342 top most CA. The root CA in turn issues certificates to subordinate 2343 CAs, and the subordinate CAs issue certificates to EEs. When 2344 verifying a PKC, the RP must verify ever certificate in the path 2345 from the EE's PKC to the root CA. 2347 The main benefit of the hierarchical model is the fact that controls 2348 imposed from the top down. For example, name constraints can be 2349 included in the subordinate CAs to limit the name space in which 2350 they are allowed to issue certificates. Further, the root CA ensure 2351 domain wide policies on cross-certification (though there are no 2352 controls to prevent another PKI from issuing PKCs to members of the 2353 domain, but then those members could be thought of as members of two 2354 distinct PKIs). 2356 Interoperability is achieved through the use of cross-certificates. 2357 Cross-certificates can be issued by the root CA or if allowed by 2358 subordinate CAs. 2360 5.5.2 Local/Federation 2362 Another model that has been around a long time is the local trust 2363 model. In this model, the RPs trust the CA that issued their 2364 certificate to them. The idea is that since the CA is local and 2366 Aresenault, Turner November, 2000 46 2367 probably known to the RP, that there is more trust rather than with 2368 some distant unknown CA. 2370 In order for EEs under different CAs to communicate the CAs issue 2371 each other certificates thereby creating a certification path from 2372 one EE to another. The process of the CAs issuing one another PKCs 2373 forms a kind of federation 2375 The main benefit of the local model is its flexibility. Many believe 2376 that the local CA knows best how to support its user community and 2377 should be given cart blanche to generate certificates as it sees fit 2378 to allow the user community to perform their functions. 2380 5.5.3 Root Repository 2382 A model made famous in the web browser community is the root 2383 repository. This model uses a file to store the PKCs of many CAs. 2384 The RP then trusts any PKC included in the file. The PKC included in 2385 the root repository may be a root CA for some other domain or 2386 subordinate CA, but when included in the trust file whatever type of 2387 PKC it is in the other domain, it becomes a root CA for the RP. 2388 Obviously, the main advantage is the fact that cross-certification 2389 is not required. If the RP does not have the root CA's certificate 2390 and it is included in with the object, the RP can just add it to the 2391 file to _trust_ it (this should only be done if the RP truly trusts 2392 the root CA). 2394 5.5.4 RP's Perspective 2396 Another model recently getting attention is the model where instead 2397 of the CA imposing restraints on the RP (in the PKC), the RP instead 2398 makes the determination as to which certificates to trust. The RP 2399 determines which domain it will accept certificates from, which key 2400 usages it will accept, etc. Cross-certification is also not required 2401 because the RP can just chose to trust a particular PKC or domain of 2402 PKCs. This obviously turns the first three models on their heads. 2403 Special care must be taken to ensure that the RP is properly 2404 configured. 2406 6 Acknowledgements 2408 A lot of the information in this document was taken from the PKIX 2409 source documents; the authors of those deserve the credit for their 2410 own words. Other good material was taken from mail posted to the 2411 PKIX working group mail list (ietf-pkix@imc.org). Among those with 2412 good things to say were (in alphabetical order, with apologies to 2413 anybody we've missed): Sharon Boeyen, Santosh Chokhani, Warwick 2414 Ford, Russ Housley, Steve Kent, Ambarish Malpani, Matt Fite, Michael 2415 Myers, Tim Polk, Stefan Santesson, Dave Simonetti, Paul Hoffman, 2416 Denis Pinkas, Ed Greck, Tom Gindin, Parag Namjoshi, Peter Sylvester, 2417 and Michael Zolotarev. 2419 Aresenault, Turner November, 2000 47 2420 7 References 2422 [2459bis] Housley, R., Ford, W., Polk, W., and Solo, D., "Internet 2423 X.509 Public Key Infrastructure Certificate and CRL Profile," 2424 , 14 July 2000. 2426 [2510bis] Adams, C., Farrell, S., _Internet X.509 Public Key 2427 Infrastructure Certificate Management Protocols,_ , July 2000. 2430 [AC] S. Farrell, R. HousleyMcNeil, M., and Glassey, T., "An Internet 2431 Attribute Certificate Profile for Authorization," , 08 August 2000. 2434 [ADDSCHEMA] Chadwick, D., Legg, S., _Internet X.509 Public Key 2435 Infrastructure Additional LDAP Schema for PKIs and PMIs,_ , 8 September 2000. 2438 [CMC] Myers, M., Liu, X., Fox, B., and Weinstein, J., "Certificate 2439 Management Messages over CMS," (RFC 2797), April 2000. 2441 [CMP] Adams, C., Farrell, S., "Internet X.509 Public Key 2442 Infrastructure Certificate Management Protocols," RFC 2510, March 2443 1999. 2445 [CMS] R. Housley, "Cryptographic Message Syntax," RFC 2630, July 2446 1999. 2448 [CRMF] Myers, M., Adams, C., Solo, D., and Kemp, D., "Internet X.509 2449 Certificate Request Message Format," RFC 2511, March 1999. 2451 [DNS] Mockapetris, P.V., "Domain names - concepts and facilities," 2452 RFC 1034, November 1987. 2454 [DHPOP] Prafullchandra, H., and Schaad, J., "Diffie-Hellman Proof- 2455 of-Possession Algorithms," RFC 2875, July 2000 1999. 2457 [DPD] Myers, M., Adams, C., Farrell, S., _Delegated Path Discovery 2458 with OCSP,_ , September 2000. 2460 [DPV] Myers, M., Adams, C., Farrell, S., _Delegated Path 2461 Validation,_ , August 2000. 2463 [DVCS] Adams, C., Sylvester, P., Zolotarev, M., Zuccherato, R., 2464 "Internet X.509 Public Key Infrastructure Data Certification Server 2465 Protocols", , 05 October 2000. 2467 [FORMAT] Housley, R., Ford, W., Polk, W., and Solo, D., "Internet 2468 X.509 Public Key Infrastructure Certificate and CRL Profile," RFC 2469 2459, January 1999. 2471 Aresenault, Turner November, 2000 48 2473 [FTPHTTP] Housley, R., and Hoffman, P., "Internet X.509 Public Key 2474 Infrastructure Operational Protocols: FTP and HTTP," RFC 2585, July 2475 1998. 2477 [IP] Postel, J., "Internet Protocol," RFC 791, September 1981. 2479 [IPv6] Deering, S., and Hinden, R., "Internet Protocol, Version 6 2480 [IPv6] Specification," RFC 1883, December 1995. 2482 [KEA] Housley, R., and Polk, W., "Internet X.509 Public Key 2483 Infrastructure Representation of Key Exchange Algorithm (KEA) Keys 2484 in Internet X.509 Public Key Infrastructure Certificates," RFC 2528, 2485 March 1999. 2487 [LAAP] Farrell, S., Chadwick, C.W., "Limited AttributeCertificate 2488 Acquisition Protocol", , 14 July 2000. 2490 [LDAPv2] Yeong, Y., Howes, T., and Kille, S., "Lightweight Directory 2491 Access Protocol", RFC 1777, March 1995. 2493 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and Adams, 2494 C., "X.509 Internet Public Key Infrastructure Online Certificate 2495 Status Protocol - OCSP," RFC 2560, June 1999. 2497 [OCSPv2] Myers, M., Ankney, R., Adams, C., _Online Certificate 2498 Status Protocol, version 2,_ , 2499 September 2000. 2501 [MISPC] Burr, W., Dodson, D., Nazario, N., and Polk, W., "MISPC 2502 Minimum Interoperability Specification for PKI Components, Version 2503 1", , 3 September 1997. 2505 [PEM] Kent, S., "Privacy Enhancement for Internet Electronic Mail: 2506 Part II: Certificate-Based Key Management," RFC 1422, February 1993. 2508 [PI] Pinka, D., Gindin, T., _Internet X.509 Public Key 2509 Infrastructure Permanent Identifier,_ , 2510 August 2000. 2512 [PKI-LDAPv2] Boeyen, S., Howes, T., and Richard, P., "Internet X.509 2513 Public Key Infrastructure Operational Protocols - LDAPv2," RFC 2559, 2514 April 1999. 2516 [PKI-LDAPv3] Chadwick, D.W., "Internet X.509 Public Key 2517 Infrastructure Operational Protocols - LDAPv3," , 2 September 2000. 2520 [POLPRAC] Chokhani, S., and Ford, W., "Internet X.509 Public Key 2521 Infrastructure Certificate Policy and Certification Practices 2522 Framework," RFC 2527, March 1999. 2524 Aresenault, Turner November, 2000 49 2526 [QC] Santesson, S., Polk, W., Barzin, P., and Nystrom, M., "Internet 2527 X.509 Public Key Infrastructure Qualified Certificates," , August 2000. 2530 [RLS] Boeyen, S., Hallam-Baker, P., _Internet X.509 Public Key 2531 Infrastructure Repository Locator Service,_ , July 2000. 2534 [RPKDS] Bassham, L., Housley, R., Polk, N., _Internet X.509 Public 2535 Key Infrastructure Representation of Public Keys and Digital 2536 Signatures in Internet X.509 Public Key Infrastructure 2537 Certificates,_ , 14 June, 2000. 2539 [SCHEMA] Boeyen, S., Howes, T., and Richard, P., "Internet X.509 2540 Public Key Infrastructure LDAPv2 Schema," RFC 2587, June 1999. 2542 [SCVP] Malpani, A., Hoffman, P., "Simple Certificate Validation 2543 Protocol (SCVP)," , 12 June 2000. 2545 [TECHNR] Gindin, T., _Internet X.509 Public Key Infrastructure 2546 Technical Requirements for a non-Repudiation Service,_ , July 2000. 2549 [TPCMP] Kapoor , A., Tschal, R., _Transport Protocols for CMP,_ 2550 , 03 October 2000. 2552 [TSP] Adams, C., Cain, P., Pinkas, D., and Zuccherato, R., "Internet 2553 X.509 Public Key Infrastructure Time Stamp Protocols", , Octoboer 2000. 2556 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet 2557 Text Messages," RFC 822, August 1982. 2559 [SIMONETTI] Simonetti, D., "Re: German Key Usage", posting to ietf- 2560 pkix@imc.org mailing list, 12 August 1998. 2562 [X.509] ITU-T Recommendation X.509 (1997 E): Information Technology 2563 - Open Systems Interconnection - The Directory: Authentication 2564 Framework, June 1997. 2566 [X9.42] ANSI X9.42-199x, Public Key Cryptography for The Financial 2567 Services Industry: Agreement of Symmetric Algorithm Keys Using 2568 Diffie-Hellman (Working Draft), December 1997. 2570 [X9.55] ANSI X9.55-1995, Public Key Cryptography For The Financial 2571 Services Industry: Extensions To Public Key Certificates And 2572 Certificate Revocation Lists, 8 December, 1995. 2574 Aresenault, Turner November, 2000 50 2576 [X9.57] ANSI X9.57-199x, Public Key Cryptography For The Financial 2577 Services Industry: Certificate Management (Working Draft), 21 June, 2578 1996. 2580 [PKCS10] RSA Laboratories, "The Public-Key Cryptography 2581 Standards(PKCS)," RSA Data Security Inc., Redwood City, California, 2582 November 1993 Release. 2584 8 Security Considerations 2586 There are not requirements in this document. 2588 9 Editor's Address 2590 Alfred W. Arsenault 2591 Diversinet Corp. 2592 P.O. Box 6530 2593 Ellicott City, MD 21042-0530 2594 aarsenault@dvnet.com 2596 Sean Turner 2597 IECA, Inc. 2598 9010 Edgepark Road 2599 Vienna, VA 22182 2600 (703) 628-3180 2601 turners@ieca.com 2603 Expires May 2000 2605 Aresenault, Turner November, 2000 51