idnits 2.17.00 (12 Aug 2021) /tmp/idnits5646/draft-ietf-pkix-roadmap-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2022-05-14) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 7 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 2848 has weird spacing: '...tion of these...' -- 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 (July 2002) is 7243 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'FORMAT' is mentioned on line 1671, but not defined == Missing Reference: 'DCVS' is mentioned on line 361, but not defined == Missing Reference: 'TRNRS' is mentioned on line 364, but not defined == Missing Reference: 'REP' is mentioned on line 386, but not defined == Missing Reference: 'POLPROC' is mentioned on line 1444, but not defined == Missing Reference: 'RFC2459' is mentioned on line 974, but not defined ** Obsolete undefined reference: RFC 2459 (Obsoleted by RFC 3280) == Missing Reference: 'CMPT' is mentioned on line 1360, but not defined == Missing Reference: 'CMCbis' is mentioned on line 1428, but not defined == Missing Reference: 'DSV' is mentioned on line 1545, but not defined == Missing Reference: 'TS 102023' is mentioned on line 1639, but not defined == Missing Reference: 'HTTP' is mentioned on line 1764, but not defined == Missing Reference: 'TCP' is mentioned on line 1775, but not defined == Missing Reference: 'RFC 1738' is mentioned on line 2000, but not defined ** Obsolete undefined reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) == Unused Reference: 'RFC2119' is defined on line 2640, but no explicit reference was found in the text == Unused Reference: '2527bis' is defined on line 2657, but no explicit reference was found in the text == Unused Reference: 'SIMONETTI' is defined on line 2794, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3280 (ref. '2459bis') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 2510 (Obsoleted by RFC 4210) ** Obsolete normative reference: RFC 2511 (Obsoleted by RFC 4211) ** Obsolete normative reference: RFC 2527 (Obsoleted by RFC 3647) -- Possible downref: Non-RFC (?) normative reference: ref. '2797bis' ** Obsolete normative reference: RFC 3281 (ref. 'AC') (Obsoleted by RFC 5755) -- Possible downref: Non-RFC (?) normative reference: ref. 'ACRMF' -- Possible downref: Non-RFC (?) normative reference: ref. 'ACMC' -- Possible downref: Non-RFC (?) normative reference: ref. 'ADDSCHEMA' ** 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) -- Duplicate reference: RFC2511, mentioned in 'CRMF', was also mentioned in '2511bis'. ** Obsolete normative reference: RFC 2511 (ref. 'CRMF') (Obsoleted by RFC 4211) ** Obsolete normative reference: RFC 2875 (ref. 'DHPOP') (Obsoleted by RFC 6955) -- Possible downref: Non-RFC (?) normative reference: ref. 'DPD' -- Possible downref: Non-RFC (?) normative reference: ref. 'DPV' -- Possible downref: Non-RFC (?) normative reference: ref. 'DPREQ' ** Downref: Normative reference to an Experimental RFC: RFC 3029 (ref. 'DVCS') -- Possible downref: Non-RFC (?) normative reference: ref. 'IPEXT' ** Obsolete normative reference: RFC 1883 (ref. 'IPv6') (Obsoleted by RFC 2460) ** Downref: Normative reference to an Informational RFC: RFC 2528 (ref. 'KEA') -- Possible downref: Non-RFC (?) normative reference: ref. 'LAAP' ** Obsolete normative reference: RFC 1777 (ref. 'LDAPv2') (Obsoleted by RFC 3494) -- Possible downref: Non-RFC (?) normative reference: ref. 'LOGO' ** Obsolete normative reference: RFC 2560 (ref. 'OCSP') (Obsoleted by RFC 6960) -- Possible downref: Non-RFC (?) normative reference: ref. 'OCSPv2' -- Possible downref: Non-RFC (?) normative reference: ref. 'MISPC' ** Downref: Normative reference to an Historic RFC: RFC 1422 (ref. 'PEM') -- Possible downref: Non-RFC (?) normative reference: ref. 'PI' ** Obsolete normative reference: RFC 2559 (ref. 'PKI-LDAPv2') (Obsoleted by RFC 3494) -- Possible downref: Non-RFC (?) normative reference: ref. 'PKI-LDAPv3' -- Duplicate reference: RFC2527, mentioned in 'POLPRAC', was also mentioned in '2527bis'. ** Obsolete normative reference: RFC 2527 (ref. 'POLPRAC') (Obsoleted by RFC 3647) ** Obsolete normative reference: RFC 3039 (ref. 'QC') (Obsoleted by RFC 3739) -- Possible downref: Non-RFC (?) normative reference: ref. 'RLS' ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2587 (ref. 'SCHEMA') (Obsoleted by RFC 4523) -- Possible downref: Non-RFC (?) normative reference: ref. 'SCVP' -- Possible downref: Non-RFC (?) normative reference: ref. 'SIMONETTI' -- Possible downref: Non-RFC (?) normative reference: ref. 'SSKGKA' -- Possible downref: Non-RFC (?) normative reference: ref. 'SUPPALGS' -- Possible downref: Non-RFC (?) normative reference: ref. 'TECHNR' -- Possible downref: Non-RFC (?) normative reference: ref. 'TPCMC' -- Possible downref: Non-RFC (?) normative reference: ref. 'TPCMP' -- Possible downref: Non-RFC (?) normative reference: ref. 'WARR' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS10' Summary: 27 errors (**), 0 flaws (~~), 20 warnings (==), 29 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group A. Arsenault 3 Internet Draft Diversinet 4 Document: draft-ietf-pkix-roadmap-09.txt S. Turner 5 Expires: January, 2003 IECA 6 July 2002 8 Internet X.509 Public Key Infrastructure: Roadmap 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of [RFC2026]. 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This draft is being discussed on the 'ietf-pkix' mailing list. To 32 subscribe, send a message to ietf-pkix-request@imc.org with the 33 single word subscribe in the body of the message. There is a Web 34 site for the mailing list at . 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 development, 47 in hopes of making it easier to build implementations that will 48 actually interoperate. 50 Arsenault, Turner 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............................................11 60 2.4.1 REGISTRATION................................................11 61 2.4.2 INITIALIZATION..............................................12 62 2.4.3 CERTIFICATION...............................................12 63 2.4.4 KEY PAIR RECOVERY...........................................12 64 2.4.5 KEY GENERATION..............................................12 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 & REVOCATION NOTICE DISTRIBUTION & PUBLICATION..15 71 3 PMI.............................................................16 72 3.1 THEORY........................................................16 73 3.2 ARCHITECTURAL MODEL...........................................16 74 3.3 ATTRIBUTE CERTIFICATES........................................17 75 4 PKIX DOCUMENTS..................................................18 76 4.1 PROFILES......................................................18 77 4.2 OPERATIONAL PROTOCOLS.........................................22 78 4.3 MANAGEMENT PROTOCOLS..........................................25 79 4.4 POLICY OUTLINE................................................28 80 4.4 TIME STAMPING AND DATA CERTIFICATION..........................28 81 4.5 EXPIRED DRAFTS................................................32 82 5 IMPLEMENTATION ADVICE...........................................36 83 5.1 NAMES.........................................................36 84 5.1.1 NAME FORMS..................................................36 85 5.1.1.1 DISTINGUISHED NAMES.......................................36 86 5.1.1.2 SUBJECTALTNAME FORMS......................................37 87 5.1.1.2.1 INTERNET E-MAIL ADDRESSES...............................37 88 5.1.1.2.2 DNS NAMES...............................................38 89 5.1.1.2.4 URIS....................................................38 90 5.1.2 SCOPE OF NAMES..............................................38 91 5.1.3 CERTIFICATE PATH CONSTRUCTION...............................39 92 5.1.4 NAME CONSTRAINTS............................................40 93 5.1.4.1 RFC822NAMES...............................................41 94 5.1.4.2 DNSNAMES..................................................41 95 5.1.4.3 X.400 ADDRESSES...........................................42 96 5.1.4.5 DNS.......................................................42 97 5.1.4.6 URIS......................................................42 98 5.1.4.7 IPADDRESSES...............................................43 99 5.1.4.8 OTHERS....................................................43 100 5.1.5 WILDCARDS IN NAME FORMS.....................................43 101 5.1.6 NAME ENCODING...............................................44 102 5.2 POP...........................................................44 103 5.2.1 POP FOR SIGNING KEYS........................................44 105 Arsenault, Turner 2 106 5.2.2 POP FOR KEY MANAGEMENT KEYS.................................45 107 5.3 KEY USAGE BITS................................................47 108 5.4 NON-REPUDIATION...............................................48 109 5.5 TRUST MODELS..................................................49 110 5.5.1 HIERARCHICAL................................................49 111 5.5.2 LOCAL/FEDERATION............................................49 112 5.5.3 ROOT REPOSITORY.............................................50 113 5.5.4 RP'S PERSPECTIVE............................................50 114 6 REFERENCES......................................................50 115 7 SECURITY CONSIDERATIONS.........................................54 116 8 ACKNOWLEDGEMENTS................................................55 117 9 AUTHOR'S ADDRESSES..............................................55 119 1 Introduction 121 1.1 This Document 123 This document is an informational Internet-Draft that provides a 124 "roadmap" to the documents produced by the PKIX working group. It is 125 intended to provide information; there are no requirements or 126 specifications in this document. 128 Section 1.2 of this document defines key terms used in this document. 129 Section 1.3 covers some of the basic history behind the PKIX working 130 group. Section 2 covers Public Key Infrastructure (PKI) theory and 131 functions. Section 3 covers Privilege Management Infrastructure (PMI) 132 theory and functions. Section 4 provides an overview of the various 133 PKIX documents. It identifies which documents address which areas, 134 and describes the relationships among the various documents. Section 135 5 contains "Advice to implementors." Its primary purpose is to 136 capture some of the major issues discussed by the PKIX working group, 137 as a way of explaining why some of the requirements and 138 specifications say what they say. This explaination should cut down 139 on the number of misinterpretations of the documents, and help 140 developers build interoperable implementations. Section 6 contains a 141 list of contributors we wish to thank. Section 7 provides a list 142 references. Section 8 discusses security considerations, and Section 143 9 provides contact information for the editors. 145 1.2 Terminology 147 There are a number of terms used and misused throughout PKI-related, 148 PMI-related, and Time Stamp and Data Certification literature. To 149 limit confusion caused by some of those terms, used throughout this 150 document, we will use the following terms in the following ways: 152 - Attribute Authority (AA) - An authority trusted by one or more 153 users to create and sign attribute certificates. It is important 154 to note that the AA is responsible for the attribute 155 certificates during their whole lifetime, not just for issuing 156 them. 158 Arsenault, Turner 3 159 - Attribute Certificate (AC) - A data structure containing a set of 160 attributes for an end-entity and some other information, which 161 is digitally signed with the private key of the AA which issued 162 it. 164 - Certificate - Can refer to either an AC or a public key 165 certificate. Where there is no distinction made the context 166 should be assumed that the term could apply to both an AC or a 167 public key certificate. 169 - Certification Authority (CA) - An authority trusted by one or 170 more users to create and assign public key certificates. 171 Optionally the CA may create the user's keys. It is important to 172 note that the CA is responsible for the public key certificates 173 during their whole lifetime, not just for issuing them. 175 - Certificate Policy (CP) - A named set of rules that indicates the 176 applicability of a public key certificate to a particular 177 community or class of application with common security 178 requirements. For example, a particular certificate policy might 179 indicate applicability of a type of public key certificate to 180 the authentication of electronic data interchange transactions 181 for the trading of goods within a given price range. 183 - Certification Practice Statement (CPS) - A statement of the 184 practices which a CA employs in issuing public key certificates. 186 - End-entity - A subject of a certificate who is not a CA in the 187 PKI or an AA in the PMI. (An EE from the PKI can be an AA in the 188 PMI.) 190 - Public Key Certificate (PKC) - A data structure containing the 191 public key of an end-entity and some other information, which is 192 digitally signed with the private key of the CA which issued it. 194 - Public Key Infrastructure (PKI) - The set of hardware, software, 195 people, policies and procedures needed to create, manage, store, 196 distribute, and revoke PKCs based on public-key cryptography. 198 - Privilege Management Infrastructure (PMI) - A collection of ACs, 199 with their issuing AA's, subjects, relying parties, and 200 repositories, is referred to as a Privilege Management 201 Infrastructure. 203 - Registration Authority (RA) - An optional entity given 204 responsibility for performing some of the administrative tasks 205 necessary in the registration of subjects, such as: confirming 206 the subject's identity; validating that the subject is entitled 207 to have the values requested in a PKC; and verifying that the 208 subject has possession of the private key associated with the 209 public key requested for a PKC. 211 Arsenault, Turner 4 212 - Relying party - A user or agent (e.g., a client or server) who 213 relies on the data in a certificate in making decisions. 215 - Root CA - A CA that is directly trusted by an EE; that is, 216 securely acquiring the value of a Root CA public key requires 217 some out-of-band step(s). This term is not meant to imply that a 218 Root CA is necessarily at the top of any hierarchy, simply that 219 the CA in question is trusted directly. Note that the term 220 'trust anchor' is commonly used with the same meaning as 'root 221 CA' in this document. 223 - Subordinate CA - A "subordinate CA" is one that is not a Root CA 224 for the EE in question. Often, a subordinate CA will not be a 225 Root CA for any entity but this is not mandatory. 227 - Subject - A subject is the entity (AA, CA, or EE) named in a 228 certificate, either a PKC or AC. Subjects can be human users, 229 computers (as represented by Domain Name Service (DNS) names or 230 Internet Protocol (IP) addresses), or even software agents. 232 - Time Stamp Authority (TSA) - A TSA is a trusted Third Party who 233 provides a "proof-of-existence" for a particular datum prior to 234 an instant in time. 236 - Top CA - A CA that is at the top of a PKI hierarchy. Note: This 237 is often also called a "Root CA," since in data structures terms 238 and in graph theory, the node at the top of a tree is the 239 "root." However, to minimize confusion in this document, we 240 elect to call this node a "Top CA," and reserve "Root CA" where 241 there is a single CA directly trusted by the EE. Readers new to 242 PKIX should be aware that these terms are not used consistently 243 throughout the PKIX documents, as the Internet PKI profile 244 [2459bis] uses "Root CA" to refer to what this and other 245 documents call a "Top CA," and "most-trusted CA" to refer to 246 what this and other documents call a "Root CA." 248 1.3 History 250 The PKIX working group was formed in October of 1995 to develop 251 Internet standards necessary to support PKIs. The first work item was 252 a profile of the ITU-T Recommendation X.509 PKC [FORMAT]. X.509, 253 which is a widely accepted basis for a PKI, including data formats 254 and procedures related to distribution of public keys via PKCs 255 digitally signed by CAs. X.509 does not however include a profile to 256 specify the support requirements for many of the PKC data structure's 257 sub- fields, for any of the extensions, nor for certain data values. 258 The Internet PKI profile [FORMAT] went through many draft versions 259 before becoming an RFC. Other profiles have been developed in PKIX 260 for particular algorithms to make use of the Internet PKI Profile 261 [FORMAT]. There has been no sense of conflict between the authors 262 that developed these profiles as they are seen as complimentary. The 263 Internet PKI profile has been a draft standard for more than six 265 Arsenault, Turner 5 266 months and is currently going through an update process to clarify 267 any inconsistencies and to bolster certain sections, see [2459bis]. 269 In parallel with the profile development, work was undertaken to 270 develop the protocols necessary to manage PKI-related information 271 was. The first developed was the Certificate Management Protocol 272 (CMP). It defines a message protocol to initialize, certify, update, 273 and revoke PKI entities [CMP]. The demand for an enrollment protocol 274 and the desire to use PKCS-10 message format as the certificate 275 request syntax lead to the development of two different documents in 276 two different groups. The Certificate Request Syntax (CRS) draft was 277 developed in the SMIME WG which used PKCS-10 [PKCS10] as the 278 certification request message format. Certificate Request Message 279 Format [CRMF] draft was also developed but in the PKIX WG. It was to 280 define a simple enrollment protocol that would subsume both the CMP 281 and CRS enrollment protocols, but it did not use PKCS-10 as the 282 certificate request message format. Then the certificate management 283 message format document, was developed to define an extended set of 284 management messages that flow between the components of the Internet 285 PKI. Certificate Management Messages over CMS (CMC) was developed to 286 allow the use of an existing protocol (S/MIME) as a PKI management 287 protocol, without requiring the development of an entirely new 288 protocol such as CMP [CMC]. It also included [PKCS10] as the 289 certificate request syntax, which caused work on the CRS draft to 290 stop. Information from the certificate management message format 291 document was moved into [CMP] and [CMC] so work on the certificate 292 management message format document was discontinued. After some 293 operational experience with [CMP], two drafts, one for using HTTP as 294 the transport protocol and one for Transmission Control Protocol 295 (TCP), were written to solve problems encountered by implementors. 296 These drafts were merged into one draft Transport Protocols for CMP 297 [TPCMP]. [CMP] has been a draft standard for more than six months and 298 is currently undergoing revisions to document. The transport section 299 has been removed and will remain in [TPCMP]. 301 Another long debated topic in the WG dealt with certificate 302 revocation. Numerous drafts have been developed to address different 303 issues related certificate revocations. CMP supports revocation 304 request, response, revocation announcement, and requests for CRL 305 messages. CMC defines revocation request, revocation response, and 306 requests for CRL messages, but uses CMS as the encapsulating 307 protocol. [OCSP] was developed to address concerns that not all 308 relying parties want to go through the process checking CRLs from 309 every CA in the certification path. It defines an on-line mechanism 310 to determine the status of a given certificate, which may provide 311 more timely revocation information than is possible with CRLs. The 312 Simple Certification Verification Protocol (SCVP) was produced to 313 allow relying parties to off-load all of their certification 314 verification to another entity [SCVP]. The WG was arguably split over 315 whether such a function should be supported and whether it should be 316 its own protocol or included in OCSP. In response, a draft defining 317 OCSP Extensions was produced to include the functions of SCVP. [OCSP] 318 has been a draft standard for more than six months and is in the 320 Arsenault, Turner 6 321 process of being revised [OCSPv2]. To capture the work from the OCSP 322 Extensions, two drafts were developed: Delegated Path Validation 323 [DPV] and Delegated Path Discovery [DPD]. The WG recognizes an eed to 324 address online delegated path validation and delegated path 325 discovery. At least three candidates currently exist. There are: 326 OCSPv2, SCVP, and DVCS. Given this multiplicity, the WG undertook to 327 produce [DPREQ] in order to factilate selection from among these or 328 possibly others. 330 One other certificate status draft called Open CRL Distribution Point 331 (OCDP) was produced which documented two extensions: one to support 332 an alternative CRL partitioning mechanism to the CRL Distribution 333 Point mechanism documented in the Internet PKI Profile [FORMAT] and 334 one to support identifying other revocation sources available to 335 certificate-users. The work from this draft was subsumed by an ITU-T 336 | ISO/IEC Amendment to X.509, hence work on this draft was halted. 338 Development of the operational protocols has been slightly more 339 straightforward. Four documents for the Light Weight Directory Access 340 Protocol (LDAP) have been developed one for defining LDAPv2 as an 341 access protocol to repositories [PKI-LDAPv2]; two for storing PKI 342 information in an directory [SCHEMA] and [ADDSCHEMA]; and one for 343 LDAPv3 requirements for PKI [PKI-LDAPv3]. Using the File Transfer 344 Protocol (FTP) and the Hyper Text Transmission Protocol (HTTP) to 345 retrieve PKCs and CRLs from PKI repositories was documented in 346 [FTPHTTP]. Recognizing that LDAP directories are not the only 347 repository service, the working group draft a Repository Locator 348 Service [RLS] to make use of DNS SRV records to locate where and how 349 PKI information can be retrieved from a repository. 351 In late 1998 the PKIX charter was revised to include protocols for 352 time stamping and data certification services. [TSP] was developed to 353 define protocols required to interact with a Time Stamp Authority 354 (TSA) who asserts that a datum existed priot to a given time. [DVCS] 355 allows to verify and assert the validity of all signatures attached 356 to the signed document using all appropriate status information and 357 PKCs or to verify and assert the validity of one or more PKCs at the 358 specified time. Both [DVCS] and [TSP] use [CMS] as an encapsulating 359 mechanism (though in [TSP] request for a time stamp are not required 360 to use [CMS]). A draft for extending trust in tokens in time was 361 developed to use [DCVS] to maintain the trust in a token issued by a 362 non- repudiation Trusted Third Party (NR TTP) after the key initially 363 used to establish trust in the token expires; however, this draft has 364 expired. The [TRNRS] draft was developed to describe those features 365 of a service which processes signed documents that must be present in 366 order for that service to constitute a "technical non- repudiation" 367 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 375 Arsenault, Turner 7 376 drafts have since been developed: the Internet Attribute Certificates 377 Profile for Authorizations [AC] and the Limited Attribute Certificate 378 Acquisition Protocol [LAAP]. The first profiles the fields and 379 extensions of the AC and the second provides a deliberately limited 380 protocol to access a repository when LDAP is not appropriate. 382 Other drafts have been produced to address specific issues. [DHPOP] 383 was developed to define two mechanisms by which a signature can 384 produced using a Diffie-Hellman pair. This draft provides a mechanism 385 to use Diffie-Hellam key pairs to authenticate a PKCS-10 386 certification request. [REP] was developed during the revision to the 387 Internet PKI Profile [FORMAT] to separate the definitions of the 388 object identifiers and encoding rules for keys and digital signatures 389 in PKCs. The Qualified Certificates [QC] and Permanent Identifier 390 [PI] drafts were developed to address naming issues. 392 From the alphabet soup above, it is clear why this roadmap is 393 required. 395 2 PKI 397 2.1 Theory 399 At the heart of recent efforts to improve Internet security are a 400 group of security protocols such as Secure Multipurpose Internet Mail 401 Extensions (S/MIME), Transport Layer Security (TLS), and Internet 402 Protocol Security (IPSec). All of these protocols rely on public-key 403 cryptography to provide services such as confidentiality, data 404 integrity, data origin authentication, and non-repudiation. The 405 purpose of a PKI is to provide trusted and efficient key and public 406 key certificate management, thus enabling the use of authentication, 407 non-repudiation, and confidentiality. 409 Users of public key-based systems must be confident that, any time 410 they rely on a public key, the subject that they are communicating 411 with owns the associated private key, this applies whether an 412 encryption or digital signature mechanism is used. This confidence is 413 obtained through the use of PKCs, which are data structures that bind 414 public key values to subjects. The binding is achieved by having a 415 trusted CA verify the subject's identity and digitally sign each PKC. 417 A PKC has a limited valid lifetime, which is indicated in its signed 418 contents. Because a PKC's signature and timeliness can be 419 independently checked by a certificate-using client, PKCs can be 420 distributed via untrusted communications and server systems, and can 421 be cached in unsecured storage in certificate-using systems. 423 PKCs are used in the process of validating signed data. Specifics 424 vary according to which algorithm is used, but the general process 425 works as follows (Note: there is no specific order in which the 426 checks listed below must be made; implementors are free to implement 427 them in the most efficient way for their systems): 429 Arsenault, Turner 8 430 - The recipient of signed data verifies that the claimed identity 431 of the user is in accordance with the identity contained in the 432 PKC; 434 - The recipient validates that no PKC in the path is revoked (e.g., 435 by retrieving a suitably-current Certificate Revocation List 436 (CRL) or querying an on-line certificate status responder), and 437 that all PKCs are within their validity periods at the time the 438 data was signed; 440 - The recipient verifies that the data are not claimed to have any 441 values for which the PKC indicates that the signer is not 442 authorized; 444 - The recipient verifies that the data have not been altered since 445 signing, by using the public key in the PKC. 447 - If all of these checks pass, the recipient can accept that the 448 data was signed by the purported signer. The process for keys 449 used for encryption is similar. 451 Note: It is of course possible that the data was signed by someone 452 very different from the signer, if for example the purported signer's 453 private key was compromised. Security depends on all parts of the 454 certificate-using system, including but not limited to: physical 455 security of the place the computer resides; personnel security (i.e., 456 the trustworthiness of the people who actually develop, install, run, 457 and maintain the system); the security provided by the operating 458 system on which the private key is used; and the security provided 459 the CA. A failure in any one of these areas can cause the entire 460 system security to fail. PKIX is limited in scope, however, and only 461 directly addresses issues related to the operation of the PKI 462 subsystem. For guidance in many of the other areas, see [POLPROC]. 464 2.2 Architecture Model 466 A PKI is defined as: 468 The set of hardware, software, people, policies and procedures needed 469 to create, manage, store, distribute, and revoke PKCs based on 470 public-key cryptography. 472 A PKI consists of five types of components [MISPC]: 474 - Certification Authorities (CAs) that issue and revoke PKCs; 476 - Organizational Registration Authorities (ORAs) that vouch for the 477 binding between public keys and certificate holder identities 478 and other attributes; 480 Arsenault, Turner 9 481 - PKC holders are issued certificates and can sign digital 482 documents and decrypt documents using private keys; 484 - Clients that validate digital signatures and their certification 485 paths from a known public key of a trusted CA and that encrypt 486 document using public key from certificates of PKC holders; 488 - Repositories that store and make available PKCs and Certificate 489 Revocation Lists (CRLs). 491 Figure 1 is a simplified view of the architectural model assumed by 492 the PKIX Working Group. 494 +---+ cert. publish +------------+ 495 | | <--------------------- | End Entity | <------- 496 | C | +------------+ "out-of-band" 497 | | | ^ loading 498 | e | | | initial 499 | r | | | registration/ 500 | t | | | certification 501 | | | | key pair recovery 502 | / | | | key pair update 503 | | | | certificate update 504 | C | PKI "USERS" V | revocation request 505 | R | -------------------+-+-----+-+------+-+------------------- 506 | L | PKI MANAGEMENT | ^ | ^ 507 | | ENTITIES | | | | 508 | | V | | | 509 | R | +------+ | | 510 | e | <------------ | RA | <-----+ | | 511 | p | cert. | | ----+ | | | 512 | o | publish +------+ | | | | 513 | s | | | | | 514 | i | V | V | 515 | t | +------------+ 516 | o | <------------------------| CA |-------> 517 | r | +------------+ "out-of-band" 518 | y | cert. publish | ^ publication 519 | | CRL publish | | 520 +---+ | | cross-certification 521 | | cross-certificate 522 | | update 523 | | 524 V | 525 +------+ 526 | CA-2 | 527 +------+ 529 Figure 1 - PKI Entities 531 Arsenault, Turner 10 532 2.3 Public Key Certificates 534 ITU-T X.509 (formerly CCITT X.509) or ISO|IEC/ITU 9594-8, which was 535 first published in 1988 as part of the X.500 Directory 536 recommendations, defines a standard PKC format [X.509]. The PKC 537 format in the 1988 standard is called the version 1 (v1) format. 539 When X.500 was revised in 1993, two more fields, 540 subjectUniqueIdentifier and issuerUniqueIdentifier were added, 541 resulting in the version 2 (v2) format. These two fields may be used 542 to support directory access control. 544 The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993, 545 include specifications for a public key infrastructure based on X.509 546 v1 public key certificates [PEM]. The experience gained in attempts 547 to deploy [PEM] made it clear that the v1 and v2 public key 548 certificate formats are deficient in several respects. Most 549 importantly, more fields were needed to carry information which PEM 550 design and implementation experience has proven necessary. In 551 response to these new requirements, ISO|IEC, ITU, and ANSI X9 552 developed the X.509 version 3 (v3) PKC format. The v3 format extends 553 the v2 format by adding provision for additional extension fields. 554 Particular extension field types may be specified in standards or may 555 be defined and registered by any organization or community. In June 556 1996, standardization of the basic v3 format was completed [X.509]. 558 ISO|IEC, ITU, and ANSI X9 have also developed standard extensions for 559 use in the v3 extensions field [X.509][X9.55]. These extensions can 560 convey such data as additional subject identification information, 561 key attribute information, policy information, and certification path 562 constraints. However, the ISO/IEC/ITU and ANSI X9 standard extensions 563 are very broad in their applicability. In order to develop 564 interoperable implementations of X.509 v3 systems for Internet use, 565 it is necessary to specify a profile for use of the X.509 v3 566 extensions tailored for the Internet. It is one goal of PKIX to 567 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 584 Arsenault, Turner 11 585 CA (possibly with help from the RA) verifying in accordance with its 586 Certification Practice Statement (CPS) that the name and other 587 attributes are correct. 589 2.4.2 Initialization 591 Initialization is when the subject (e.g., the user or client system) 592 gets the values needed to begin communicating with the PKI. For 593 example, initialization can involve providing the client system with 594 the public key or PKC of a CA, or generating the client system's own 595 public-private key pair. 597 2.4.3 Certification 599 This is the process in which a CA issues a PKC for a subject's public 600 key, and returns that PKC to the subject or posts that PKC in a 601 repository. 603 2.4.4 Key Pair Recovery 605 In some implementations, key exchange or encryption keys will be 606 required by local policy to be "backed up," or recoverable in case 607 the key is lost and access to previously-encrypted information is 608 needed. Such implementations can include those where the private key 609 exchange key is stored on a hardware token that can be lost or 610 broken, or when a private key file is protected by a password which 611 can be forgotten. Often, a company is concerned about being able to 612 read mail encrypted by or for a particular employee when that 613 employee is no longer available because she is ill or no longer works 614 for the company. 616 In these cases, the user's private key can be backed up by a CA or by 617 a separate key backup system. If a user or her employer needs to 618 recover these backed up key materials, the PKI must provide a system 619 that permits the recovery without providing an unacceptable risk of 620 compromise of the private key. 622 2.4.5 Key Generation 624 Depending on the CA's policy, the private-public key pair can either 625 be generated by the user in his local environment, or generated by 626 the CA. In the latter case, the key material may be distributed to 627 the user in an encrypted file or on a physical token (e.g., a smart 628 card or PC card). 630 Arsenault, Turner 12 631 2.4.6 Key Update 633 All key pairs need to be updated regularly (i.e., replaced with a new 634 key pair) and new PKCs issued. This will happen in two cases: 635 normally, when a key has passed its maximum usable lifetime; and 636 exceptionally, when a key has been compromised and must be replaced. 638 2.4.6.1 Key Expiry 640 In the normal case, a PKI needs to provide a facility to gracefully 641 transition from a PKC with an existing key to a new PKC with a new 642 key. This is particularly true when the key to be updated is that of 643 a CA. Users will know in advance that the key will expire on a 644 certain date; the PKI, working together with PKC-using applications, 645 should allow for appropriate keys to work before and after the 646 transition. There are a number of ways to do this; see [CMP] for an 647 example of one. 649 2.4.6.2 Key Compromise 651 In the case of a key compromise, the transition will not be 652 "graceful" in that there will be an unplanned switch of PKCs and 653 keys; users will not have known in advance what was about to happen. 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 the 662 Root CA has been issued a new PKC and the Root CA issues PKCs to 663 users relying upon it, users relying on that Root CA are cut off from 664 the rest of the system, as there is no way to develop a valid 665 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 a 670 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 Arsenault, Turner 13 684 2.4.7 Cross-certification 686 A CA certificate is a certificate in a hierarchy that is neither a 687 self-signed certificate, nor an end-entity certificate. [2459bis] 688 does not make a difference between a CA certificate and a cross 689 certificate since it defines a cross-certificate as "a certificate 690 issued by one CA to another CA". Some people in the WG believe that 691 a cross certificate is a special kind of CA certificate. A cross 692 certificate is issued by a CA under one Top CA for another CA under 693 a different Top CA. CAs in the same hierarchy have part of their 694 names imposed by the Top CA or by the CAs under that Top CAS. When a 695 cross certificate is issued, there is no relationship between the 696 names of the CAs. 698 Typically, a cross-certificate is used to allow client systems or 699 end entities in one administrative domain to communicate securely 700 with client systems or end users in another administrative domain. 701 Use of a cross-certificate issued from CA_1 to CA_2 allows user 702 Alice, who trusts CA_1, to accept a PKC used by Bob, which was 703 issued by CA_2. Cross-certificates can also be issued from one CA to 704 another CA in the same administrative domain, if required. 706 Cross-certificates can be issued in only one direction, or in both 707 directions, between two CA's. That is, just because CA_1 issues a 708 cross-certificate for CA_2, CA_2 does not have to issue a cross- 709 certificate for CA_1. 711 2.4.8 Revocation 713 When a PKC is issued, it is expected to be in use for its entire 714 validity period. However, various circumstances may cause a PKC to 715 become invalid prior to the expiration of the validity period. Such 716 circumstances include change of name, change of association between 717 subject and CA (e.g., an employee terminates employment with an 718 organization), and compromise or suspected compromise of the 719 corresponding private key. Under such circumstances, the CA needs to 720 revoke the PKC. 722 X.509 defines one method of PKC revocation. This method involves each 723 CA periodically issuing a signed data structure called a certificate 724 revocation list (CRL). A CRL is a list that identifies the 725 references of revoked PKCs. This list contains a date of issue and 726 is signed by a CA and made freely available in a public repository. 727 Each revoked PKC is identified in a CRL by its PKC serial number. 728 When a certificate-using system uses a PKC, that system not only 729 checks the PKC signature and validity but also acquires a suitably 730 recent CRL and checks that the PKC serial number is not on that CRL. 731 The meaning of "suitably recent" may vary with local policy, but it 732 usually means the most recently issued CRL. A CA issues a new CRL on 733 a regular periodic basis (e.g., hourly, daily, or weekly). CA's may 735 Arsenault, Turner 14 736 also issue CRLs aperiodically. For example, if an important key is 737 deemed compromised, the CA may issue a new CRL to expedite 738 notification of that fact, even if the next CRL does not have to be 739 issued for some time. (A problem of aperiodic CRL issuance is that 740 end-entities may not know that a new CRL has been issued, and thus 741 may not retrieve it from a repository.) 743 An entry is added to the CRL as part of the next update following 744 notification of revocation. An entry may be removed from the CRL 745 after appearing on one regularly scheduled CRL issued beyond the 746 revoked PKC's validity period. Leaving the revoked PKC on the CRL for 747 this extra period allows for PKCs that are revoked prior to issuing a 748 new CRL and whose invalidity date falls before the CRL issuing time 749 to be accounted for. If the revoked PKC is not retained on the CRL 750 for this extra period then the possibility arises that a revoked PKC 751 may never appear on a CRL. 753 An advantage of the CRL revocation method is that CRLs may be 754 distributed by exactly the same means as PKCs themselves, namely, via 755 untrusted communications and server systems. 757 One limitation of the CRL revocation method, using untrusted 758 communications and servers, is that the time granularity of 759 revocation is limited to the CRL issue period. For example, if a 760 revocation is reported now, that revocation will not be reliably 761 notified to certificate-using systems until the next CRL is issued, 762 which may be up to one hour, one day, or one week depending on the 763 frequency that the CA issues CRLs. 765 As with the X.509 v3 PKC format, in order to facilitate interoperable 766 implementations from multiple vendors, the X.509 v2 CRL format needed 767 to be profiled for Internet use. This was done as part of the 768 Internet PKI Profile [FORMAT]. However, PKIX does not require CAs to 769 issue CRLs. On-line methods of revocation notification may be 770 applicable in some environments as an alternative to the X.509 CRL. 771 PKIX defines a few protocols that support on-line checking. [OCSP], 772 [DVCS], and [SCVP] all support on-line checking of the status of 773 PKCs. 775 On-line revocation checking may significantly reduce the latency 776 between a revocation report and the distribution of the information 777 to relying parties. Once the CA accepts the report as authentic and 778 valid, any query to the on-line service will correctly reflect the 779 PKC validation impacts of the revocation. However, these methods 780 impose new security requirements; the PKC validator must trust the 781 on-line validation service while the repository does not need to be 782 trusted. 784 2.4.9 Certificate & Revocation Notice Distribution & Publication 786 As alluded to in sections 2.1 and 2.5.8 above, the PKI is responsible 787 for the distribution of PKCs and PKC revocation notices (whether in 789 Arsenault, Turner 15 790 CRL form or in some other form) in the system. "Distribution" of PKCs 791 includes transmission of the PKC to its owner, and may also include 792 publication of the PKC in a repository. "Distribution" of revocation 793 notices may involve posting CRLs in a repository, transmitting them 794 to end-entities, or forwarding them to on-line responders. 796 3 PMI 798 3.1 Theory 800 Many systems use the PKC to perform identity based access control 801 decisions (i.e., the identity may be used to support identity-based 802 access control decisions after the client proves that it has access 803 to the private key that corresponds to the public key contained in 804 the PKC). For many systems this is sufficient, but increasingly 805 systems are beginning to find that rule-based and role-based access 806 control is required. These forms of access control decisions require 807 additional information that is normally not included in a PKC, 808 because the lifetime of the information is much shorter than the 809 lifetime of the public-private key pair. To support binding this 810 information to a PKC the Attribute Certificate (AC) was defined in 811 ANSI and later incorporated into ITU-T Recommendation X.509. The AC 812 format allows any additional information to be bound to a PKC by 813 including, in a digitally signed data structure, a reference back to 814 one specific PKC or to multiple PKCs, useful when the subject has the 815 same identity in multiple PKCs. Additionally, the AC can be 816 constructed in such a way that it is only useful at one or more 817 particular targets (e.g., web server, mail host). 819 Users of a PMI must be confident that the identity purporting to 820 posses an attribute has the right to possess that attribute. This 821 confidence may be obtained through the use of PKCs or it may be 822 configured in the AC-using system. If PKCs are used the party making 823 the access control decision can determine "if the AC issuer is 824 trusted to issue ACs containing this attribute." 826 ACs are complicated by the fact that they can point to an identity 827 which may be in more than one PKC. If the RP has multiple 828 certification chains to chose from then it has to make the 829 determination as to which certification path to trust. Regardless, 830 before the RP uses the AC it must make sure that a path from the AC 831 back to its trust point is valid. 833 3.2 Architectural Model 835 A Privilege Management Infrastructure, or PMI, is defined as: 837 The set of hardware, software, people, policies and procedures needed 838 to create, manage, store, distribute, and revoke ACs. 840 A PMI consists of five types of components [AC]: 842 Arsenault, Turner 16 843 - Attribute Authorities (AAs), or Attribute Certificate Issuer, 844 that issue and revoke ACs; 846 Note: AAs may implicitly revoke ACs by using very short validity 847 periods. 849 - Attribute Certificate Users that parses or processes an AC; 851 - Attribute Certificate Verifiers that check the validity of an AC 852 and then makes use of the result; 854 - Clients that request an action for which authorization checks are 855 to be made; 857 - Repositories that store and make available certificates and 858 Certificate Revocation Lists (CRLs). 860 Figure 2 is an example of the exchanges that may involve ACs. 862 +--------------+ 863 | | Server Acquisition 864 | AC issuer +----------------------------+ 865 | | | 866 +--+-----------+ | 867 | | 868 | Client | 869 | Acquisition | 870 | | 871 +--+-----------+ +--+------------+ 872 | | AC "push" | | 873 | Client +-------------------------+ Server | 874 | | (part of app. protocol) | | 875 +--+-----------+ +--+------------+ 876 | | 877 | Client | Server 878 | Lookup +--------------+ | Lookup 879 | | | | 880 +---------------+ Repository +---------+ 881 | | 882 +--------------+ 884 Figure 2: AC Exchanges 886 3.3 Attribute Certificates 888 ANSI X.9 first published the Attribute Certificate format. It defined 889 the standard version 1 (v1) AC format. They later created a version 2 890 (v2) AC by modifying the owner field to point to either an identity 891 or a specific PKC and including an extension mechanism. In 1997 ITU-T 892 included it in [X.509]. 894 Arsenault, Turner 17 895 ANSI, ITU-T, and IETF have developed standard extensions and 896 attributes for use in the v2 ACs. Extensions can convey such 897 information as an audit identity that can be used to create an audit 898 trail, identity specific servers and services where the AC owner can 899 use their AC, point to a specific issuer's key, and indicate where to 900 get revocation information. The AC is generic enough to allow any 901 attribute to be conveyed in the data structure. Without limiting the 902 attributes and extensions that can be included in an AC it is very 903 difficult to develop interoperable implementations for Internet use. 904 It is the goal of PKIX to specify a profile for the Internet, 905 electronic mail, IPSec applications, etc. Environments with 906 additional requirements may build on this profile or replace it. 908 The [AC] profile constrains many of the options allowed in X.509. For 909 example, the AC chains, like their PKC brethren, are allowed by 910 X.509, but the AC profile recommends that they not be supported in to 911 simplify the implementation. 913 4 PKIX Documents 915 This section identifies the five different areas in which the PKIX 916 working group has developed documents. The first area involves 917 profiles of the X.509 v3 PKC standards and the X.509 v2 CRL standards 918 for the Internet. The second area involves operational protocols, in 919 which relying parties can obtain information such as PKCs or PKC 920 status. The third area covers management protocols, in which 921 different entities in the system exchange information needed for 922 proper management of the PKI. The fourth area provides information 923 about certificate policies and certificate practice statements, 924 covering the areas of PKI security not directly addressed in the rest 925 of PKIX. The fifth area deals with providing time stamping and data 926 certification services, which can be used to build such services as 927 non-repudiation. 929 4.1 Profiles 931 An X.509 v3 PKC is a very complex data structure. It consists of 932 basic information fields, plus a number of optional extensions. Many 933 of the fields and numerous extensions can take on a wide range of 934 options. This provides an enormous degree of flexibility, which 935 allows the X.509 v3 PKC format to be used with a wide range of 936 applications in a wide range of environments. Unfortunately, this 937 same flexibility makes it extremely difficult to produce independent 938 implementations that will actually interoperate with one another. In 939 order to build an Internet PKI based on X.509 v3 PKCs, the PKIX 940 working group had to develop a profile of the X.509 v3 PKC 941 specification. 943 A profile of the X.509 v3 PKC specification is a description of the 944 contents of the PKC and which extensions must be supported, which 945 extensions may be supported, and which extensions may not be 947 Arsenault, Turner 18 948 supported. The Internet PKI Profile [FORMAT] provides such a profile 949 of X.509 v3 PKC for the Internet PKI. In addition, the Internet PKI 950 Profile [FORMAT] suggests ranges of values for many of the 951 extensions. 953 The Internet PKI Profile [FORMAT] also provides a profile for Version 954 2 CRLs for use in the Internet PKI. CRLs, like PKCs, have a number of 955 optional extensions. In order to promote interoperability, it is 956 necessary to constrain the choices an implementor supports. 958 In addition to profiling the PKC and CRL formats, it is necessary to 959 define particular Object Identifiers (OIDs) for certain encryption 960 algorithms, because there are a variety of OIDs registered for some 961 algorithm suites. PKIX has produced two documents ([RPKDS] and [KEA]) 962 which provide guidance on the proper implementation of specific 963 algorithms. 965 Some countries are in a process of updating their legal frameworks in 966 order to regulate and incorporate recognition of signatures in 967 electronic form. Many of these frameworks introduce certain basic 968 requirements on PKCs, often termed Qualified Certificates, supporting 969 these types of "legal" signatures. Partly as a result of this there 970 is a need for a specific PKC profile providing standardized support 971 for certain related issues such as a common structure for expressing 972 unambiguous identities of certified subjects (unmistakable identity). 973 In December 1998, PKIX adopted as a work item the development of a 974 refinement of [RFC2459] that further profiles PKIX PKC into qualified 975 certificates. This work is reflected in [QC]. 977 Like the X.509 v3 PKC, the AC also a very complex data structure 978 consisting of basic information fields, a number of optional 979 extensions, and a virtually unlimited number of attributes. Again, 980 many of the fields, extensions, and attributes can take on a wide 981 range of options allowing an enormous degree of flexibility. In order 982 to build an Internet PMI based on ACs, the PKIX working group had to 983 develop a profile of the AC. 985 The AC profile is description of the contents of the AC, the allowed 986 and required extensions, and applicable attributes. [AC] provides 987 such a profile of the X.509 v2 AC. 989 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure 990 Certificate and CRL Profile (RFC2459) [FORMAT] 992 DESCRIPTION: This document describes the profiles to be used for 993 X.509 v3 PKCs and version 2 CRLs by Internet PKI participants. The 994 profiles include the identification of ISO/IEC/ITU and ANSI 995 extensions which may be useful in the Internet PKI. The profiles 996 are presented in the 1988 Abstract Syntax Notation One (ASN.1) 997 rather than the 1994 syntax used in the ISO/IEC/ITU standards. 998 Would-be PKIX implementors and developers of certificate-using 999 applications should start with the Internet PKI Profile [FORMAT] to 1001 Arsenault, Turner 19 1002 ensure that their systems will be able to interoperate with other 1003 users of the PKI. 1005 The Internet PKI Profile [FORMAT] also includes path validation 1006 procedures. The procedures presented are based upon the ISO/IEC/ITU 1007 definition, but the presentation assumes one or more self-signed 1008 trusted CA PKCs. The procedures are provided as examples only. 1009 Implementations are not required to use the procedures provided; 1010 they may implement whichever procedures are efficient for their 1011 situation. However, implementations are required to derive the same 1012 results as the example procedures. 1014 STATUS: Proposed Standard. 1016 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure 1017 Representation of Key Exchange Algorithm (KEA) Keys in Internet 1018 X.509 Public Key Infrastructure Certificates (RFC 2528) [KEA] 1020 DESCRIPTION: This document provides Object Identifiers (OIDs) and 1021 other guidance for IPKI users who use the Key Exchange Algorithm 1022 (KEA). It profiles the format and semantics of the 1023 subjectPublicKeyInfo field and the keyUsage extension in X.509 v3 1024 PKCs containing KEA keys. This document should be used by anyone 1025 wishing to support KEA; others who do not support ECDSA are not 1026 required to comply with it. 1028 STATUS: Informational RFC. 1030 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Qualified 1031 Certificates (RFC 3039) [QC] 1033 DESCRIPTION: This document profiles the format for and defines 1034 requirements on information content in a specific type of PKCs 1035 called Qualified Certificates. A "Qualified Certificate" is a PKC 1036 that is issued to a natural person (i.e., a living human being); 1037 contains an unmistakable identity based on a real name or a 1038 pseudonym of the subject; exclusively indicates non-repudiation as 1039 the key usage for the certificate's public key; and meets a number 1040 of requirements. 1042 STATUS: Proposed Standard. 1044 - DOCUMENT TITLE: An Internet Attribute Certificate Profile for 1045 Authorizations [AC] 1047 DESCRIPTION: This document profiles the format for an defines 1048 requirements on X.509 v2 ACs to support authorization services 1049 required by various Internet protocols (TLS, CMS, and the consumers 1050 of CMS, etc.). Two profiles are defined in support of basic 1051 authorizations and in support of services that can operate via 1052 proxy. 1054 Arsenault, Turner 20 1055 STATUS: Approved as Proposed Standard; in RFC editor's Queue. 1056 Issuance as an RFC blocked until the normative reference [2459bis] 1057 progresses to Proposed Standard as well. (See below.) 1059 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure 1060 Certificate and CRL Profile 1061 [2459bis] 1063 DESCRIPTION: This document is an update of the Internet PKI Profile 1064 [2459bis]. The treatment of path validation is enhanced, and 1065 additional specificity is offered for various certificate and CRL 1066 extensions. This document omits the encoding and identification of 1067 public keys and digital signatures. (See [RPKDS] below.) 1069 STATUS: Tentatively approved by IESG. 1071 - DOCUMENT TITLE: Algorithms and Identifiers for the Internet X.509 1072 Public Key Infrastructure Certificate and CRL Profile [RPKDS] 1075 DESCRIPTION: This document specifies algorithm identifiers and 1076 encoding formats for the representation of cryptographic algorithms 1077 keys, associated parameters, and digital signatures in Internet PKI 1078 and X.509 certificates and certificate revocation lists. This draft 1079 does not attempt to define the cryptographic algorithms themselves. 1080 It instead references other appropriate standards. This draft 1081 incorporates information from Section 7 of RFC 2459 and the 1082 Internet-Draft "Representation of Elliptic Curve Digital Signature 1083 Algorithm (ECDSA) Keys in Internet X.509 Public Infrastructure 1084 Certificates." 1086 STATUS: Tentatively approved by IESG. 1088 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Permanent 1089 Identifier [PI] 1091 DESCRIPTION: This document defines a new form of name, the 1092 permanent identifier, which is a name assigned by an organization, 1093 unique within that organization, that singles out a particular 1094 entity from all other individuals. The permanent identifier is an 1095 optional feature that may be used by a CA to indicate that the 1096 certificate relates to the same individual even if the name or the 1097 affiliation of that entity has changed. The permanent identifier is 1098 important in the context of access control and of non-repudiation. 1100 STATUS: Under AD review. 1102 - DOCUMENT TITLE: Supplemental Algorithms and Identifiers for the 1103 Internet X.509 Public Key Infrastructure Certificate and CRL 1104 Profile [SUPPALGS] 1106 DESCRIPTION: This document supplements [RPKDS], defining specifies 1107 algorithm identifiers and encoding formats for the representation 1109 Arsenault, Turner 21 1110 of emerging cryptographic algorithms and associated keys. The 1111 document encompasses lattice-based public key algorithms as well as 1112 digital signatures using larger hash algorithms (e.g., SHA-256). 1114 STATUS: Under WG review. 1116 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Logotypes 1117 in X.509 Certificate [LOGO] 1119 DESCRIPTION: This document specifies a certificate extension for 1120 including logotypes in public key certificates and attribute 1121 certificates. 1123 STATUS: Under WG review. 1125 - DOCUMENT TITLE: X.509 Extensions for IP Addresses and AS 1126 Identifiers [IPEXT] 1128 DESCRIPTION: This document specifies a certificate extension for 1129 including logotypes in public key certificates and attribute 1130 certificates. 1132 STATUS: Under WG review. 1134 - DOCUMENT TITLE: Warranty Certificate Extension [WARR] 1137 DESCRIPTION: This document describes a certificate extension to 1138 explicitly state the warranty offered by a Certificate Authority 1139 (CA) for the certificate containing the extension. 1141 STATUS: Under WG review. 1143 4.2 Operational Protocols 1145 Operational protocols are required to deliver certificates and CRLs 1146 (or other certificate status information) to certificate using 1147 systems. Provision is needed for a variety of different means of 1148 certificate and CRL delivery, including distribution procedures based 1149 on DNS, LDAP, HTTP, FTP, and X.500. A limited protocol to support AC 1150 retrieval has also been documented. 1152 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure 1153 Operational Protocols - LDAPv2 (RFC 2559) [PKI-LDAPv2] 1155 DESCRIPTION: This document describes the use of LDAPv2 as a 1156 protocol for PKI elements to publish and retrieve certificates and 1157 CRLs from a repository. [LDAPv2] is a protocol that allows 1158 publishing and retrieving of information. 1160 STATUS: Proposed Standard. 1162 Arsenault, Turner 22 1163 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure LDAPv2 1164 Schema (RFC 2587) [SCHEMA] 1166 DESCRIPTION: This document defines a minimal schema necessary to 1167 support the use of LDAPv2 for PKC and CRL retrieval and related 1168 functions for PKIX. This document supplements [LDAPv2] by 1169 identifying the PKIX-related attributes that must be present. 1171 STATUS: Proposed Standard. 1173 - DOCUMENT TITLE: X.509 Internet Public Key Infrastructure Online 1174 Certificate Status Protocol - OCSP (RFC 2560) [OCSP] 1176 DESCRIPTION: This document specifies a protocol useful in 1177 determining the current status of a certificate without the use of 1178 CRLs. A major complaint about certificate-based systems is the need 1179 for a relying party to retrieve a current CRL as part of the 1180 certificate validation process. Depending on the size of the CRL, 1181 this can cause severe problems for bandwidth-challenged devices. 1182 Depending on the frequency of CRL issuance, this can also cause 1183 timeliness problems. (E.g., if CRLs are only published weekly, with 1184 no interim releases, a certificate could actually have been revoked 1185 for just short of one week without it being on the current CRL, and 1186 thus improper use of that certificate could still be occurring.) 1188 OCSP attempts to address those problems. It provides a mechanism 1189 whereby a relying party identifies one or more certificates to an 1190 approved OCSP "responder", and the responder sends back the current 1191 status of the certificate(s) - e.g., "revoked", "notRevoked", 1192 "unknown". This can dramatically reduce the bandwidth required to 1193 transmit revocation status - a relying party does not have to 1194 retrieve a CRL of many entries to check the status of one 1195 certificate. It can (although it is not guaranteed to) improve the 1196 timeliness of revocation notification, and thus reduce the window 1197 of opportunity for someone trying to use a revoked certificate. 1199 STATUS: Proposed Standard. 1201 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure 1202 Operational Protocols: FTP and HTTP (RFC 2585) [FTPHTTP] 1204 DESCRIPTION: This document describes the use of the File Transfer 1205 Protocol (FTP) and the Hyper-text Transfer Protocol (HTTP) to 1206 obtain certificates and CRLs from PKI repositories. 1208 STATUS: Proposed Standard. 1210 - DOCUMENT TITLE: Diffie-Hellman Proof-of-Possession Algorithms (RFC 1211 2875) [DHPOP] 1213 DESCRIPTION: It allows Diffie-Hellman, a key agreement algorithm, 1214 to be used instead of requiring that the public key being requested 1215 for certification correspond to an algorithm that is capable of 1217 Arsenault, Turner 23 1218 signing and encrypting. The first algorithm generates a signature 1219 for a specific verifier where the signer and recipient have the 1220 same public key parameters. The second algorithm generates a 1221 signature for arbitrary verifiers where the signer and recipient do 1222 not have the same public key parameters. 1224 STATUS: Proposed Standard. 1226 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Additional 1227 Schema for PKIs and PMIs 1228 [ADDSCHEMA] 1230 DESCRIPTION: This document describes the Lightweight Directory 1231 Access Protocol (LDAP) schema features that, in addition to RFC 1232 2587, are needed to support a Privilege Management Infrastructure 1233 and a Public Key Infrastructure. It also describes the schema for 1234 the storage and matching of attribute certificates and revocation 1235 lists in an LDAP directory server. This Internet Draft supplements, 1236 rather than revokes, the contents of RFC 2587. 1238 STATUS: Under WG review. 1240 - DOCUMENT TITLE: Delegated Path Validation and Delegated Path 1241 Discovery Protocol Requirements (DPV&DPD-REQ) [DPREQ] 1244 DESCRIPTION: This document specifies requirements for two 1245 request/response pairs. The first, called Delegated Path Validation 1246 (DPV), can be used to fully delegate a path validation processing 1247 to an DPV server. The second, called Delegated Path Discovery 1248 (DPD), can be used to delegate development of a path, including 1249 certificate status information, to a DPD server. 1251 STATUS: Under WG review. 1253 - DOCUMENT TITLE: Simple Certificate Validation Protocol (SCVP) 1254 [SCVP] 1256 DESCRIPTION: The SCVP protocol allows a client to offload 1257 certificate handling to a server. The server can give a variety of 1258 valuable information about the certificate, such as whether or not 1259 the certificate is valid, a chain to a trusted root, and so on. 1261 STATUS: Under WG review. 1263 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure 1264 Operational Protocols - LDAPv3 1265 [PKI-LDAPv3] 1267 DESCRIPTION: This document describes the features of the 1268 Lightweight Directory Access Protocol (LDAP) v3 that are needed in 1269 order to support a public key infrastructure based on x.509 1270 certificates and certificate revocation lists. Because LDAPv2 has a 1272 Arsenault, Turner 24 1273 number of deficiencies that may limit its usefulness in certain 1274 circumstances, the IETF has ceased its standardization and replaced 1275 it with LDAPv3. This document describes the features of LDAPv3 that 1276 are necessary, not required, or are optional for servers to support 1277 a PKI based on X.509. 1279 STATUS: Under WG Review. 1281 4.3 Management Protocols 1283 Management protocols are required to support on-line interactions 1284 between PKI user and management entities. For example, a management 1285 protocol might be used between a CA and a client system with which a 1286 key pair is associated, or between two CAs which cross-certify each 1287 other. A management protocol can be used to carry user or client 1288 system registration information, or a request for revocation of a 1289 certificate. 1291 There are two parts to a "management protocol." The first is the 1292 format of the messages that will be sent, and the second is the 1293 actual protocol that governs the transmission of those messages. 1294 Originally, the PKIX working group developed two documents, [CRMF] 1295 and certificate management message format (CMMF), that together 1296 described the necessary set of message formats, and two other 1297 documents, [CMP] and [CMC], that described protocols for exchanging 1298 those messages. However, the message formats defined in the CMMF 1299 draft were inserted into both [CMP] and [CMC], and thus the (CMMF) 1300 draft has been dropped as a PKIX document. 1302 - DOCUMENT TITLE: Certificate Management Messages over CMS (RFC 2797) 1303 [CMC] 1305 DESCRIPTION: This document defines the means by which PKI clients 1306 and servers may exchange PKI messages when using S/MIME's 1307 Cryptographic Message Syntax [CMS] as a transaction envelope. CMC 1308 supports the certificate request message body specified in the 1309 Certificate Request Message Format [CRMF] documents, as well as a 1310 variety of other certificate management messages. The primary 1311 purpose of this specification is to allow the use of an existing 1312 protocol (S/MIME) as a PKI management protocol, without requiring 1313 the development of an entirely new protocol such as CMP. A 1314 secondary purpose is to codify in IETF standards the current 1315 industry practice of using PKCS-10 messages [PKCS10] for 1316 certificate requests. 1318 STATUS: Proposed Standard. 1320 - DOCUMENT TITLE: Internet X.509 Certificate Request Message Format 1321 (RFC 2511) [CRMF] 1323 DESCRIPTION: CRMF specifies a format recommended for use whenever a 1324 relying party is requesting a certificate from a CA or requesting 1326 Arsenault, Turner 25 1327 that an RA help it get a certificate. The request message format 1328 was needed before many of the other message formats had to be 1329 finalized, and so it was put into a separate document. This 1330 document only specifies the format of a message. Specification of a 1331 protocol to transport that message is beyond the scope of CRMF. 1333 STATUS: Proposed Standard. 1335 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure 1336 Certificate Management Protocols (RFC 2510) [CMP] 1338 DESCRIPTION: This document specifies a new protocol specifically 1339 developed for the purpose of transporting messages like those 1340 specified in CRMF among PKI elements. In general, CMP will be used 1341 in conjunction with CRMF, and will then be run over a transfer 1342 service (e.g., S/MIME, HTTP) to provide a complete PKI management 1343 service. 1345 STATUS: Proposed Standard. 1347 - DOCUMENT TITLE: Certificate Request Message Format [2511bis] 1350 DESCRIPTION: This document is an update of [CRMF] and reflects the 1351 results of interoperability testing. 1353 STATUS: Awaiting documentation of Interoperability Testing results. 1355 - DOCUMENT TITLE: Certificate Management Protocols [2510bis] 1358 DESCRIPTION: This document is an update of [CMP] and reflects the 1359 results of interoperability testing. The document omits the 1360 transport protocols found in [CMP] which are addressed in [CMPT]. 1361 (See below). 1363 STATUS: Awaiting documentation of Interoperability Testing results. 1365 - DOCUMENT TITLE: Transport Protocols for CMP [TPCMP] 1368 DESCRIPTION: This document describes how to layer Certificate 1369 Management Protocols (CMP) over various transport protocols. In 1370 Section 5 of RFC 2510, the process of sending DER-encoded CMP 1371 messages directly over various protocols is specified. Implementers 1372 found that the protocol was lacking in several regards. This 1373 document is an effort to enhance the protocol now in order to avoid 1374 interoperability conflicts later and to make the transport section 1375 a separate draft. 1377 STATUS: Under WG review. 1379 Arsenault, Turner 26 1380 - DOCUMENT TITLE: Certificate Management Messages over CMS [2797bis] 1383 DESCRIPTION: This document is an update to [CMC]. 1385 STATUS: Under WG review. 1387 - DOCUMENT TITLE: CMC Transport 1388 [TPCMC] 1390 DESCRIPTION: This document defines a number of transport mechanisms 1391 that are used to move [CMC] messages. The transport mechanisms 1392 described in the document are: HTTP, file, mail and TCP. 1394 STATUS: Under WG review. 1396 - DOCUMENT TITLE: CMC Extensions: Server Side Key Generation and Key 1397 Archival [SSKGKA] 1399 DESCRIPTION: This document defines a set of extensions to [CMC] 1400 that address the desire for having two additional services: 1401 Server generation of keys, and server-side archival and subsequent 1402 recovery of key material by the server. These services are 1403 provided by the definition of additional control statements within 1404 the CMC architecture. 1406 STATUS: Under WG review. 1408 - DOCUMENT TITLE: Attribute Certificate Request Message Format 1409 [ACRMF] 1411 DESCRIPTION: The Certificate Request Message Format ([CRMF]) 1412 specifies a format for requesting an X.509 public key certificate 1413 from a Certification Authority (CA), possibly with assistance from 1414 an Local Registration Authority (LRA). This specification, ACRMF, 1415 is modeled on CRMF, extending similar functionality to requests 1416 for X.509 attribute certificates from Attribute Authorities (AA), 1417 possibly via an Attribute Registration Authority (ARA). 1419 STATUS: Under WG review. 1421 - DOCUMENT TITLE: Attribute Certificate Management Messages over CMS 1422 [ACMC] 1424 DESCRIPTION: This document specifies modifications to the 1425 Certificate Management Messages over CMS specification ([CMCbis]) 1426 to permit the management of attribute certificates. This document 1427 does not stand alone, but must be used in conjunction with 1428 [CMCbis]. It is expected that the modifications proposed here 1429 will also be used in conjunction with the Attribute Certificate 1430 Request Message Format specification ([ACRMF]). 1432 STATUS: Under WG review. 1434 Arsenault, Turner 27 1435 4.4 Policy Outline 1437 As mentioned before, profiling certificates and specifying 1438 operational and management protocols only addresses a part of the 1439 problem of actually developing and implementing a secure PKI. What is 1440 also needed is the development of a certificate policy (CP) and 1441 certification practice statement (CPS), and then following those 1442 documents. The CP and CPS should address physical and personnel 1443 security, subject identification requirements, revocation policy, and 1444 a number of other topics. [POLPROC] provides a framework for 1445 certification practice statements. 1447 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure 1448 Certificate Policy and Certification Practices Framework (RFC 1449 2527) [POLPRAC] 1451 DESCRIPTION: As noted before, the specification and implementation 1452 of certificate profiles, operational protocols, and management 1453 protocols is only part of building a PKI. Equally as important - if 1454 not more important - is the development and enforcement of a 1455 certificate security policy, and a Certification Practice Statement 1456 (CPS). The purpose of this document (PKIX-4) is to establish a 1457 clear relationship between certificate policies and CPSs, and to 1458 present a framework to assist the writers of certificate policies 1459 or CPSs with their tasks. In particular, the framework identifies 1460 the elements that may need to be considered in formulating a 1461 certificate policy or a CPS. The purpose is not to define 1462 particular certificate policies or CPSs, per se. 1464 STATUS: Informational RFC. 1466 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure 1467 Certificate Policy and Certification Practices Framework 1470 DESCRIPTION: This specification is an update to RFC 2527. As above, 1471 the purpose of this document is to establish a clear relationship 1472 between certificate policies and CPSs, and to present a framework 1473 to assist the writers of certificate policies or CPSs with their 1474 tasks. The framework specified in this documents is basically a 1475 superset of the framework specified in RFC 2527. 1477 STATUS: Under WG Review. 1479 4.4 Time Stamping and Data Certification 1481 In late 1998, the PKIX working group began two efforts that were not 1482 in the original working group charter, but were deemed to be 1483 appropriate because they described infrastructure services that could 1484 be used to provide desired security services. The first of these is 1486 Arsenault, Turner 28 1487 time stamping, described in [TSP]. Time stamping is a service in 1488 which a trusted third party - a Time Stamp Authority, or TSA - signs 1489 a message, in order to provide evidence that it existed prior to a 1490 given time. Time stamping provides some support for non- repudiation, 1491 in that a user cannot claim that a transaction was later forged after 1492 compromise of a private key, because the existence of the signed time 1493 stamp indicates that the transaction in question could not have been 1494 created after the indicated time. 1496 [TSP] also defines the role of a Temporal Data Authority, or TDA. A 1497 TDA is a Trusted Third Party (TTP) that creates a temporal data 1498 token. This temporal data token associates a message with a 1499 particular event and provides supplementary evidence for the time 1500 included in the time stamp token. For example, a TDA could associate 1501 the message with the most recent closing value of the Dow Jones 1502 Average. The temporal data with which the message is associated 1503 should be unpredictable in order to prevent forward dating of tokens. 1504 The third iteration of the draft removed support for TDAs as no one 1505 in the WG expressed a requirement for the role. 1507 At the Minneapolis IETF meeting (IETF 44), it was disclosed that the 1508 materials covered in [TSP] draft may be covered by patent(s). Use of 1509 the material covered by the patent(s) in question has not be granted 1510 by the patent holder. Thus, anyone interested in implementing the 1511 PKIX [TSP] draft must be aware of this intellectual property issue. 1513 The second new effort is the definition of a Data Validation and 1514 Certification Server, or DVCS, protocol [DVCS]. A DVCS is a Trusted 1515 Third Party that verifies the correctness of specific data submitted 1516 to it. It also allows the delegation of trustworthy servers and 1517 allows for chaining of verifications. 1519 This services offered by DVCS are different from the TSP service in 1520 that a TSA will not attempt to parse or verify a message sent to it 1521 for certification; instead, it will merely append a reliable 1522 indication of the current time, and sign the resulting string-of- 1523 bits. This offers an indication that the given string-of-bits existed 1524 at a specified time; it does not offer any indication of the 1525 correctness or relevance of that string of bits. By contrast, the 1526 DVCS certifies possession of data or the validity of another entity's 1527 signature. As part of this, the DVCS verifies the mathematical 1528 correctness of the actual signature value contained in the request 1529 and also checks the full certification path from the signing entity 1530 to a trusted point (e.g., the DVCS's CA, or the Root CA in a 1531 hierarchy). 1533 The DVCS supports non-repudiation in two ways. First, it provides 1534 evidence that a signature or PKC was valid at the time indicated in 1535 the token. The token can be used even after the corresponding PKC 1536 expires and its revocation information is no longer available on CRLs 1537 (for example). Second, the production of a data certification token 1538 in response to a signed request for certification of another 1540 Arsenault, Turner 29 1541 signature or PKC also provides evidence that due diligence was 1542 performed by the requester in validating the signature or PKC. 1544 The concept of a delegated signature validation server was introduced 1545 in [DSV] as an analog to the delegated path validation server. A DSV 1546 services permits the relying party to prove they validated a 1547 digitally signed object, including the certification path, at a 1548 particular time. 1550 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Time Stamp 1551 Protocols (RFC 3161) [TSP] 1553 DESCRIPTION: This document defines the specification for a time 1554 stamp service. It defines a Time Stamp Authority, or TSA, a trusted 1555 third party who maintains a reliable time service. When the TSA 1556 receives a time stamp request, it appends the current time to the 1557 request and signs it into a token to certify that the original 1558 request existed prior to the indicated time. This helps provide 1559 non- repudiation by preventing someone (either a legitimate user or 1560 an attacker who has successfully compromised a key) from "back- 1561 dating" a transaction. It also makes it more difficult to challenge 1562 a transaction by asserting that it has been back-dated. Note that 1563 the TSA does not provide any data parsing service; that is, the TSA 1564 does not attempt to validate that which it signs; it merely regards 1565 it as a string of bits whose meaning is unimportant, but existence 1566 is vital. 1568 STATUS: Proposed Standard. 1570 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Data 1571 Certification Server Protocols (RFC 3029) [DVCS] 1573 DESCRIPTION: This document describes a general Data Validation and 1574 Certification Server (DVCS) and the protocols to be used when 1575 communicating with it. The Data Validation and Certification 1576 Server is a Trusted Third Party (TTP) that can be used as one 1577 component in building reliable non-repudiation services. 1579 Useful Data Validation and Certification Server responsibilities 1580 in a PKI are to assert the validity of signed documents, public 1581 key certificates, and the possession or existence of data. 1583 As a result of the validation, a DVCS generates a Data Validation 1584 Certificate (DVC). The data validation certificate can be used 1585 for constructing evidence of non-repudiation relating to the 1586 validity and correctness of an entity's claim to possess data, the 1587 validity and revocation status of an entity's public key 1588 certificate and the validity and correctness of a digitally signed 1589 document. 1591 The presence of a data validation certificate supports non- 1592 repudiation by providing evidence that a digitally signed document 1594 Arsenault, Turner 30 1595 or public key certificate was valid at the time indicated in the 1596 DVC. 1598 A DVC validating a public key certificate can for example be used 1599 even after the public key certificate expires and its revocation 1600 information is no longer or not easily available. Determining the 1601 validity of a DVC is assumed to be a simpler task, for example, if 1602 the population of DVCS is significantly smaller than the 1603 population of public key certificate owners. 1605 The production of a data validation certificate in response to a 1606 signed request for validation of a signed document or public key 1607 certificate also provides evidence that due diligence was 1608 performed by the requester in validating a digital signature or 1609 public key certificate. 1611 STATUS: Experimental RFC. 1613 - DOCUMENT TITLE: Delegated Signature Validation Protocol 1614 Requirements (DSV-REQ) 1616 DESCRIPTION: This document specifies requirements to fully delegate 1617 the validation of a digital signature to a DSV (Delegated Signature 1618 Validation) server. The validation is performed using a set of 1619 rules, called a signature policy. 1621 It also defines the requirements for two optional request/response 1622 pairs, either for allowing to indicate to a signature validation 1623 server a signature policy, or giving the reference of a signature 1624 policy to obtain the details of an already defined signature 1625 policy. 1627 STATUS: Under WG review. 1629 - DOCUMENT TITLE: Policy Requirements for Time-Stamp Authorities 1630 1632 DESCRIPTION: This document specifies policy requirements relating 1633 to the operation of Time-stamping Authorities (TSAs). It defines 1634 policy requirements on the operation and management practices of 1635 TSAs such that subscribers and relying parties may have confidence 1636 in the operation of the time-stamping services. 1638 The contents of this Informational RFC is technically equivalent 1639 to ETSI TS 102 023 V1.1.1 (2002-01) [TS 102023]. The ETSI TS is 1640 under the ETSI Copyright (C). Individual copies of this ETSI 1641 deliverable can be downloaded from http://www.etsi.org. 1643 STATUS: Under WG review. 1645 Arsenault, Turner 31 1646 4.5 Expired Drafts 1648 There have been numerous drafts that have been produced by the 1649 working group that for some reason or another did not make it to RFC 1650 status. The following is a list of these drafts. 1652 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure 1653 Certificate Management Message Formats 1655 DESCRIPTION: This document contained the formats for a series of 1656 messages important in certificate and PKI management. These 1657 messages let CA's, RA's, and relying parties communicate with each 1658 other. Note that this document only specified message formats; it 1659 did not specify a protocol for transferring messages. That protocol 1660 could have be either CMP or CMC, or perhaps another custom 1661 protocol. 1663 STATUS: Work has been discontinued. All useful information from it 1664 has been moved into [CMP] and [CMC]. 1666 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Enhanced 1667 CRL Distribution Options (OpenCDP) 1669 DESCRIPTION: This document proposed an alternative to the CRL 1670 Distribution Point (CDP) approach documented in the Internet PKI 1671 Profile [FORMAT]. OCDP separates the CRL location function from the 1672 process of certificate and CRL validation, and thus claimed some 1673 benefits over the CDP approach. 1675 STATUS: Work has been discontinued, as all useful information has 1676 been incorporated into [X.509]. An updated the Internet PKI Profile 1677 [2459bis] RFC should profile the use of the CDP approach. 1679 - DOCUMENT TITLE: Internet Public Key Infrastructure: Caching the 1680 Online Certificate Status Protocol 1682 DESCRIPTION: To improve the degree to which it can scale, OCSP 1683 allows caching of responses - e.g., at intermediary servers, or 1684 even at the relying party's end system. This document described how 1685 to support OCSP caching at intermediary servers. 1687 STATUS: Work has been discontinued. 1689 - DOCUMENT TITLE: WEB based Certificate Access Protocol-- WebCAP/1.0 1691 DESCRIPTION: This document specified a set of methods, headers, and 1692 content-types ancillary to HTTP/1.1 to publish, retrieve X.509 PKCs 1693 and Certificate Revocation Lists. This protocol also facilitated 1694 determining current status of a digital certificate without the use 1695 of CRLs. This protocol defined new methods, request and response 1696 bodies, error codes to HTTP/1.1 protocol for securely publishing, 1697 retrieving, and validating certificates across a firewall. 1699 Arsenault, Turner 32 1700 STATUS: Expired. 1702 - DOCUMENT TITLE: Basic Event Representation Token 1704 DESCRIPTION: This document defined a finite method of representing 1705 a discrete instant in time as a referable event. The Basic Event 1706 Representation Token (BERT) was a lightweight binary token designed 1707 for use in large numbers over short periods of time. The tokens 1708 contained only a single instance of an event stamp and the trust 1709 process is referenced against an external reference. 1711 STATUS: Expired. 1713 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Extending 1714 trust in non repudiation tokens in time 1716 DESCRIPTION: This document described a method to maintain the trust 1717 in a token issued by a non-repudiation Trusted Third Party (NR TTP) 1718 (DVCS/TSA/TDA) after the key initially used to establish trust in 1719 the token expires. The document described a general format for 1720 storage of DVCS/TS/TDA tokens for this purpose, which establishes a 1721 chain of custody for the data. 1723 STATUS: Expired. 1725 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure 1726 Representation of Elliptic Curve Digital Signature Algorithm 1727 (ECDSA) Keys and Signatures in Internet X.509 Public Key 1728 Infrastructure Certificates 1730 DESCRIPTION: This document provided Object Identifiers (OIDs) and 1731 other guidance for IPKI users who use the Elliptic Curve Digital 1732 Signature Algorithm (ECDSA). It profiled the format and semantics 1733 of the subjectPublicKeyInfo field and the keyUsage extension in 1734 X.509 v3 PKCs containing ECDSA keys. This document should have been 1735 used by anyone wishing to support ECDSA; others who do not support 1736 ECDSA are not required to comply with it. 1738 STATUS: Finished WG Last Call. Merged into Representation of Public 1739 Keys and Digital Signatures in Internet X.509 Public Key 1740 Infrastructure Certificates. 1742 - DOCUMENT TITLE: A String Representation of General Name 1744 DESCRIPTION: This document specified a string format for the ASN.1 1745 construct GeneralName. 1747 STATUS: Expired. 1749 - DOCUMENT TITLE: OCSP Extensions 1751 DESCRIPTION: This document defined Internet-standard extensions to 1752 OCSP that enable a client to delegate processing of certificate 1754 Arsenault, Turner 33 1755 acceptance functions to a trusted server. The client could control 1756 the degree to which delegation takes place. In addition limited 1757 support was provided for delegating authorization decisions. 1759 STATUS: The work has been incorporated into [DPV] and [DPD]. 1761 - DOCUMENT TITLE: Using HTTP as a Transport Protocol for CMP 1763 DESCRIPTION: This document described how to layer [CMP] over 1764 [HTTP]. A simple method for doing so was described in [CMP], but 1765 that method does not accommodate a polling mechanism, which may be 1766 required in some environments. This document specified an 1767 alternative method that used the polling protocol defined in [CMP]. 1768 A new Content-Type for messages was also defined. 1770 STATUS: The work has been merged into [TPCMP]. 1772 - DOCUMENT TITLE: Using TCP as a Transport Protocol for CMP 1774 DESCRIPTION: This document described how to layer Certificate 1775 Management Protocols [CMP] over [TCP]. A method for doing so is 1776 described in [CMP], but that method did not solve problems 1777 encountered by implementors. This document specified an enhanced 1778 method which extends the protocol. 1780 STATUS: The work has been merged into [TPCMP]. 1782 - DOCUMENT TITLE: Delegated Path Validation 1784 DESCRIPTION: This specification builds on the Online Certificate 1785 Status Protocol (OCSP) framework's extensibility by defining an 1786 Internet-standard extension to OCSP that can be used to fully 1787 delegate all path validation processing to an OCSP server. The 1788 Delegated Path Validation (DVP) extension to OCSP described in this 1789 document accomplishes the task of locating the certificate 1790 validation process within a trusted server. This in turn reduces 1791 the technical footprint of certificate-using applications and may 1792 ease the integration of certificate path processing with other 1793 authorized data. 1795 STATUS: Expired. 1797 - DOCUMENT TITLE: Delegated Path Discovery with OCSP 1799 DESCRIPTION: This document establishes an Internet-standard 1800 extension that enables relying-party software to acquire 1801 certification path data from an OCSP server rather than replicate 1802 the same functionality. This Delegated Path Discovery (DPD) 1803 extension delegates the acquisition process to a separate server, 1804 thereby greatly simplifying and reducing the size of public key 1805 based credential validation systems or other relying party 1806 software. The DPD extension also enables such software to select 1808 Arsenault, Turner 34 1809 from among various trust paths in the event of the existence of 1810 multiple paths. 1812 STATUS: Expired. 1814 - DOCUMENT TITLE: Online Certificate Status Protocol, Version 2 1816 DESCRIPTION: This document is an update to RFC 2560. 1818 STATUS: Expired. 1820 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Repository 1821 Locator Service 1823 DESCRIPTION: This document defines a PKI repository locator 1824 service, which enable certificate-using systems to locate PKI 1825 repositories based on a domain name, to identify the protocols that 1826 can be used to access the repository, and obtain addresses for the 1827 servers that host the repository service. The Internet Draft 1828 defines SRV records for a PKI repository locator service to enable 1829 PKI clients to obtain necessary information to connect to a 1830 domain's repository. It also includes the definition of a SRV RR 1831 format for this service. 1833 STATUS: Expired. 1835 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Technical 1836 Requirements for a non-Repudiation Service 1838 DESCRIPTION: This document describes those features of a service 1839 which processes signed documents which must be present in order for 1840 that service to constitute a "technical non-repudiation" service. A 1841 technical non-repudiation service must permit an independent 1842 verifier to determine whether a given signature was applied to a 1843 given data object by the private key associated with a given valid 1844 certificate, at a time later than the signature. The features of a 1845 technical non-repudiation service are expected to be necessary for 1846 a full non-repudiation service, although they may not be 1847 sufficient. 1849 This document is intended to clarify the definition of the "non- 1850 repudiation" service in RFC 2459. It should thus serve as a guide 1851 to when the nonRepudiation bit of the keyUsage extension should be 1852 set and to when a Certificate Authority is required to archive 1853 CRL's. 1855 STATUS: Expired. 1857 - DOCUMENT TITLE: Limited Attribute Certificate Acquisition Protocol 1858 1860 DESCRIPTION: This document specifies a deliberately limited 1861 protocol for requesting ACs from a server. It is intended to be 1863 Arsenault, Turner 35 1864 complementary to the use of LDAP for AC retrieval, covering those 1865 cases where use of an LDAP server is not suitable due to the type 1866 of authorization model being employed. 1868 STATUS: Expired. 1870 5 Implementation Advice 1872 This section provides guidance to those who would implement various 1873 parts of the PKIX suite of documents. The topics discussed in this 1874 section engendered significant discussion in the working group, and 1875 there, was at times, either widespread disagreement or widespread 1876 misunderstanding of them. Thus, this discussion is provided to help 1877 readers of the PKIX document set understand these issues, in the hope 1878 of fostering greater interoperability among eventual PKIX 1879 implementations. 1881 5.1 Names 1883 PKIX has been referred to as a "name-centric" PKI because the PKCs 1884 associate public keys with names of entities. Each PKC contains at 1885 least one name for the owner of a particular public key. The name can 1886 be an X.500 distinguished name, contained in the subjectDN field of 1887 the PKC. There can also be names such as RFC822 e-mail addresses, DNS 1888 domain names, and uniform resource identifiers (URIs) associated with 1889 the key; these attributes are kept in the subjectAltName extension of 1890 the PKC. A PKC must contain at least one of these name forms, it may 1891 contain multiple forms if deemed appropriate by the CA based on the 1892 intended usage of the PKC. 1894 5.1.1 Name Forms 1896 There are two possible places to put a name in an X.509 v3 PKC. One 1897 is the subject field in the base PKC (often called the "Distinguished 1898 Name" or "DN" field), and the other is in the subjectAltName 1899 extension. 1901 5.1.1.1 Distinguished Names 1903 According to the Internet PKI Profile [2459bis], a CA's PKC must have 1904 a non-null value in the subject field, while EE's PKCs are permitted 1905 to have an empty subject field. If a PKC has a non-null subject 1906 field, it must contain an X.500 Distinguished Name. 1908 Arsenault, Turner 36 1909 5.1.1.2 SubjectAltName Forms 1911 In addition to the DN, a PKIX PKC may have one or more values in the 1912 subjectAltName extension. 1914 The subjectAltName extension allows additional identities to be bound 1915 to the subject of the PKC (e.g., it allows "umbc.edu" and 1916 "130.85.1.3" to be associated with a particular subject, as well as 1917 "C=US, O=University of Maryland, L=Baltimore, CN=UMBC"). X.509- 1918 defined options for this extension include: Internet electronic mail 1919 addresses; DNS names; IP addresses; and URIs. Other options can 1920 exist, including locally-defined name forms. 1922 A single subjectAltName extension can include multiple name forms, 1923 and multiple instances of each name form. 1925 Whenever such alternate name forms are to be bound into a PKC, the 1926 subjectAltName (or issuerAltName) extension must be used. It is 1927 technically possible to embed an alternate name form in the subject 1928 field. For example, one could make a DN contain an IP address via a 1929 kludge such as "C=US, L=Baltimore, CN=130.85.1.3". However, this 1930 usage is deprecated; the alternative name extension is the preferred 1931 location for finding such information. As another example, some 1932 legacy implementations exist where an RFC822 name is embedded in the 1933 subject distinguished name as an EmailAddress attribute. Per Internet 1934 Profile [2459bis], PKIX-compliant implementations generating new PKCs 1935 with electronic mail addresses must use the rfc822Name in the 1936 subjectAltName extension to describe such EEs. Simultaneous inclusion 1937 of the EmailAddress attribute in the subject distinguished name to 1938 support legacy implementation is deprecated but permitted. 1940 In line with this, if the only subject identity included in a PKC is 1941 an alternative name form, then the subject distinguished name must be 1942 empty (technically, an empty sequence), and the subjectAltName 1943 extension must be present. If the subject field contains an empty 1944 sequence, the subjectAltName extension must be marked critical. 1946 If the subjectAltName extension is present, the sequence must contain 1947 at least one entry. Unlike the subject field, conforming CAs shall 1948 not issue PKCs with subjectAltNames containing empty GeneralName 1949 fields. For example, an rfc822Name is represented as an IA5String. 1950 While an empty string is a valid IA5String, such an rfc822Name is not 1951 permitted by PKIX. The behavior of clients that encounter such a PKC 1952 when processing a certification path is not defined by this working 1953 group. Because the subject's alternative name is considered to be 1954 definitively bound to the public key, all parts of the subject's 1955 alternative name must be verified by the CA. 1957 5.1.1.2.1 Internet e-mail addresses 1959 When the subjectAltName extension contains an Internet mail address, 1960 the address is included as an rfc822Name. The format of an rfc822Name 1962 Arsenault, Turner 37 1963 is an "addr-spec" as defined in [RFC-822]. An addr-spec has the form 1964 local-part@domain; it does not have a phrase (such as a common name) 1965 before it, or a comment (text surrounded in parentheses) after it, 1966 and it is not surrounded by "<" and ">". 1968 5.1.1.2.2 DNS Names 1970 When the subjectAltName extension contains a domain name service 1971 label, the domain name is stored in the dNSName attribute(an 1972 IA5String). The string shall be in the "preferred name syntax," as 1973 specified by [DNS]. Note that while upper and lower case letters are 1974 allowed in domain names, no significance is attached to the case. In 1975 addition, while the string " " is a legal domain name, subjectAltName 1976 extensions with a dNSName " " are not permitted. Finally, the use of 1977 the DNS representation for Internet mail addresses (wpolk.nist.gov 1978 instead of wpolk@nist.gov) is not permitted; such identities are to 1979 be encoded as rfc822Name. 1981 5.1.1.2.3 IP addresses 1983 When the subjectAltName extension contains an iPAddress, the address 1984 shall be stored in the octet string in "network byte order," as 1985 specified in [IP]. The least significant bit (LSB) of each octet is 1986 the LSB of the corresponding byte in the network address. For IP 1987 Version 4, as specified in [IP], the octet string must contain 1988 exactly four octets. For IP Version 6, as specified in [IPv6], the 1989 octet string must contain exactly sixteen octets. 1991 5.1.1.2.4 URIs 1993 The Internet PKI Profile [2459bis] notes "When the subjectAltName 1994 extension contains a URI, the name must be stored in the 1995 uniformResourceIdentifier (an IA5String). The name must be a non- 1996 relative URL, and must follow the URL syntax and encoding rules 1997 specified in [RFC 1738]. The name must include both a scheme (e.g., 1998 "http" or "ftp") and a scheme-specific- part. The scheme-specific- 1999 part must include a fully qualified domain name or IP address as the 2000 host. As specified in [RFC 1738], the scheme name is not case- 2001 sensitive (e.g., "http" is equivalent to "HTTP"). The host part is 2002 also not case-sensitive, but other components of the scheme-specific- 2003 part may be case-sensitive. When comparing URIs, conforming 2004 implementations must compare the scheme and host without regard to 2005 case, but assume the remainder of the scheme-specific-part is case 2006 sensitive." 2008 5.1.2 Scope of Names 2010 The original X.500 work presumed that every subject in the world 2011 would have a globally unique distinguished name. Thus, every subject 2013 Arsenault, Turner 38 2014 could be easily located, and there would never be a conflict. All 2015 that would be needed is a sufficiently large name space, and rules 2016 for constructing names based on subordination and location. 2018 Obviously, that is not practical in the real world, for a variety of 2019 reasons. There is no single entity in the world trusted by everybody 2020 to reside at the top of the name space, and there is no way to 2021 enforce uniqueness on names for all entities. (These were among the 2022 reasons for the failure of PEM to be widely implemented.) 2024 This does not mean, however, that a name-based PKI cannot work. It is 2025 important to recognize that the scope of names in PKIX is local; they 2026 need to be defined and unique only within their own domain. 2028 Suppose for example that a Top CA is established with DN "O=IETF, 2029 OU=PKIX, CN=PKIX_CA". That CA will then issue PKCs for subjects 2030 subordinate to it. The only requirement, which can be enforced 2031 procedurally, is that no two distinct entities beneath this Top CA 2032 have the same name. We can't prevent somebody else in the world from 2033 creating her own CA, called "O=IETF, OU=PKIX, CN=PKIX_CA", and it is 2034 not necessary to do so. Within the domain of the original Top CA, 2035 there will be no conflict, and the fact that there is another CA of 2036 the same name in some other domain is irrelevant. 2038 This is analogous to the current DNS or IP address situations. On the 2039 Internet, there is only one node called www.ietf.org. The fact that 2040 there might be 10 different intranets, each with a host given the DNS 2041 name www.ietf.org, is irrelevant and causes no interoperability 2042 problems - those are different domains. However, if there were to be 2043 another node on the Internet with domain name www.ietf.org, then 2044 there would be a problem due to name duplication. 2046 The same applies for IP addresses. As long as only one node on the 2047 Internet responds to the IP address 130.85.1.3, there is no problem, 2048 despite the fact that there are 100 different corporate Intranets, 2049 each using that same IP address. However, if two different nodes on 2050 the Internet each responded to the IP address 130.85.1.3, there would 2051 be a problem. 2053 5.1.3 Certificate Path Construction 2055 Certificate path construction has been the topic of many discussions 2056 in the WG. The issue centered on how best to get a certificate when 2057 the connection between the subject's name and the name of their CA, 2058 as well as the CA's repository (or directory), may not be obvious. 2059 Many proposals were put forth, including implementing a global X.500 2060 Directory Service, using DNS SRV records, and using an extension to 2061 point to the directory provider. At the end of the discussion the 2062 group decided to use the authority information access extension 2063 defined in the Internet PKI Profile [2459bis], which allows the CA to 2064 indicate the access method and location of CA information and 2065 services. The extension would be included in subject's certificates 2067 Arsenault, Turner 39 2068 and could be used to associate an Internet style identity for the 2069 location of repository to retrieve the issuer's certificate in cases 2070 where such a location is not related to the issuer's name. 2072 Another discussion related to certificate path construction was where 2073 to store the CA and EE PKCs in the directory (specifically LDAPv2 2074 directories). Two camps emerged with different views on where to 2075 store CA and cross-certificates. In the CA's directory entry, one 2076 camp wanted self-issued PKCs stored in the cACertificate attribute, 2077 PKCs issued to this CA stored in the forward element of the 2078 crossCertificatePair, and PKCs issued from this CA for other CAs in 2079 the reverse element of the crossCertificatePair attribute. The other 2080 camp wanted all CA PKCs stored in the cACertificate attribute, and 2081 PKCs issued to and from another domain stored in the 2082 crossCertificatePair attribute. There was a short discussion that the 2083 second was more efficient than first and that one solution or the 2084 other was more widely deployed. The end result was to indicate that 2085 self-issued PKCs and PKCs issued to the CA by CAs in the same domain 2086 as the CA are stored in the cACertificate attribute. The 2087 crossCertificatePair attribute's forward element will include all but 2088 self-issued PKCs issued to the CA. The reverse element may include a 2089 subset of PKCs issued by the CA to other CAs. With this resolution 2090 both camp's implementations are supported and are free to choose the 2091 location of CA PKCs to best support their implementation. 2093 5.1.4 Name Constraints 2095 A question that has arisen a number of times is "how does one enforce 2096 Name constraints when there is more than one name form in a PKC?" 2097 That is, the Internet PKI Profile [2459bis] states that: 2099 Subject's alternative names may be constrained in the same manner as 2100 subject distinguished names using the name constraints extension as 2101 described in section 4.2.1.11. 2103 What does this mean? Suppose that there is a CA with DN "O=IETF, 2104 OU=PKIX, CN=PKIX_CA", with the subjectAltName extension having 2105 dNSName "PKIX_CA.IETF.ORG". Suppose that that CA has issued a PKC 2106 with an empty DN, with subjectAltName extension having dNSName set to 2107 "PKIX_CA.IETF.ORG", and rfc822Name set to Steve@PKIX_CA.IETF.ORG. The 2108 question is: are name constraints enforced on these two PKCs - is the 2109 name of the EE PKC considered to be properly subordinate to the name 2110 of the CA? 2112 The answer is "yes". The general rules for deciding whether a PKC 2113 meets name constraints are: 2115 - If a PKC complies with name constraints in any one of its name 2116 forms, then the PKC is deemed to comply with name constraints. 2118 - If a PKC contains a name form that its issuer does not, the PKC is 2119 deemed to comply with name constraints for that name form. 2121 Arsenault, Turner 40 2122 In deciding whether a name form meets name constraints, the following 2123 rules apply (in all cases Name B is the name in the name constraints 2124 extension): 2126 5.1.4.1 rfc822Names 2128 Three variations are allowed: 2130 - If the name constraint is specified as "larry@mail.mit.edu", then 2131 Name A is subordinate to Name B (in B's subtree) if Name A 2132 contains all of Name B's name (specifies a particular mailbox). 2133 For example, larry@mail.mit.edu is subordinate, but 2134 larry_sanders@mail.mit.edu is not. 2136 - If the name constraint is specified as "mail.mit.edu", then Name A 2137 is subordinate to Name B (in B's subtree) if Name A contains all 2138 of Name B's name (specified all mailboxes on host mail.mit.edu). 2139 For example, curly@mail.mit.edu and mo@mail.mit.edu are 2140 subordinate, but mo@mail6.mit.edu and curly@smtp.mail.mit.edu are 2141 not. 2143 - If the name constraint is specified as ".mit.edu", then Name A is 2144 subordinate to Name B (in B's subtree) if Name A contains all of 2145 Name B's name, with the addition of zero or more additional host 2146 or domain names to the left of Name B's name. That is, 2147 smtp.mit.edu is subordinate to .mit.edu, as is pop.mit.edu. 2148 However, mit.edu is not subordinate to .mit.edu. When the 2149 constraint begins with a "." it specifies any address within a 2150 domain. In the previous example, "mit.edu" is not in the domain of 2151 ".mit.edu". 2153 Note: If rfc822 names are constrained, but the PKC does not contain a 2154 subjectAltName extension, the EmailAddress attribute will be used to 2155 constrain the name in the subject distinguished name. For example (c 2156 is country, o is organization, ou is organizational unit, and em is 2157 EmailAddress), Name A ("c=US, o=MIT, ou=CS, em=curly@mail.mit.edu") 2158 is subordinate to Name B ("c=US, o=MIT, ou=CS") (in B's subtree) if 2159 Name A contains all of Name B's names. 2161 5.1.4.2 dNSNames 2163 Name A is subordinate to Name B (in B's subtree) if Name A contains 2164 all of Name B's name, with the addition of zero or more additional 2165 domain names to the left of Name B's name. That is, www.mit.edu is 2166 subordinate to mit.edu, as is larry.cs.mit.edu. However, www.mit.edu 2167 is not subordinate to web.mit.edu. 2169 Arsenault, Turner 41 2170 5.1.4.3 x.400 addresses 2172 Name A is subordinate to Name B (in B's subtree) if Name A contains 2173 all of Name B's name. For example (c is country-name, admd is 2174 administrative-domain-name, and o is organization-name, ou is 2175 organizational-unit-name, pn is personal-name, sn=surname, and gn is 2176 given-name in both Name A and B), the mnemonic X.400 address (using 2177 PrintableString choices for c and admd) "c=US, admd=AT&T, o=MIT, 2178 ou=cs, pn='sn=Doe,gn=John'" is subordinate to "c=US, admd=AT&T, 2179 o=MIT, ou=cs" and "c=US, admd=AT&T, o=MIT, pn='sn=DOE,gn=JOHN'" (pn 2180 is a SET that includes, among other things, sn and gn). 2182 5.1.4.5 DNs 2184 Name A is subordinate to Name B (in B's subtree), if Name A contains 2185 all of Name B's name, treating attribute values encoded in different 2186 types as different strings, ignoring case in PrintableString (in all 2187 other types case is not ignored), removing leading and trailing white 2188 space in PrintableString, and converting internal substrings of one 2189 or more consecutive white space characters to a single space. For 2190 example, (c is country, o is organization, ou is organizational unit, 2191 and cn is common name): 2193 - Assuming PrintableString types for all attribute values in Name A 2194 and B, "c=US, o=MIT, ou=CS" is subordinate to "c=us, o=MIT, 2195 ou=cs", as is "c=US, o=MIT, ou=CS, ou=administration". Another 2196 example, "c=US, o=MIT, ou=CS, cn= John Doe" (note the white 2197 spaces) is subordinate to "c=US, o=MIT, ou=CS, cn=John Doe". 2199 - Assuming UTF8String types for all attribute values in Name A and B, 2200 "c=US, o=MIT, ou=CS, ou=administration" is subordinate to "c=US, 2201 o=MIT, ou=CS", but "c=US, o=MIT, ou=cs, ou=Administration". "c=US, 2202 o=MIT, ou=CS, cn= John Smith" (note the white spaces) is not 2203 subordinate to "c=US, o=MIT, ou=CS, cn= John Smith". 2205 - Assuming UTF8String types for all attribute values in Name A and 2206 PrintableString types for all attribute values in Name B, "c=US, 2207 o=MIT, ou=cs" is subordinate to "c=US, o=MIT, ou=CS" if the 2208 verification software supports the full comparison algorithm in 2209 the X.500 series. "c=US, o=MIT, ou=cs" is NOT subordinate to 2210 "c=US, o=MIT, ou=CS" if the verification software supports the 2211 comparison algorithm in the Internet PKI Profile [2459bis]. 2213 5.1.4.6 URIs 2215 The constraints apply only to the host part of the name. Two 2216 variations are allowed: 2218 - If the name constraint is specified as ".mit.edu", then Name A is 2219 subordinate to Name B (in B's subtree) if Name A contains all of 2220 Name B's name, with the addition of zero or more additional host 2222 Arsenault, Turner 42 2223 or domain names to the left of Name B's name. That is, www.mit.edu 2224 is subordinate to .mit.edu, as is curly.cs.mit.edu. However, 2225 mit.edu is not subordinate to .mit.edu. When the constraint begins 2226 with a "." it specifies a host. 2228 - If the name constraint is specified as "abc.mit.edu", then Name A 2229 is subordinate to Name B (in B's subtree) if Name A contains all 2230 of Name B's name. No leftward expansion of the host or domain name 2231 is allowed. 2233 5.1.4.7 iPaddresses 2235 Two variations are allowed depending on the IP version: 2237 - For IPv4 addresses: Name A (128.32.1.1 encoded as 80 20 01 01) is 2238 subordinate to Name B (128.32.1.0/255.255.255.0 encoded as 80 20 2239 00 00 FF FF FF 00) (in B's subtree) if Name A falls within the net 2240 denoted in Name B's CIDR notation. 2242 - For IPv6 addresses: Name A (4224.0.0.0.8.2048.8204.16762 encoded as 2243 10 80 00 00 00 00 00 00 00 08 08 00 20 0C 41 7A) is subordinate to 2244 Name B (4224.0.0.0.8.2048.8204.0/ 2245 65535.65535.65535.65535.65535.65535.65535.0 encoded as 10 80 00 00 2246 00 00 00 00 00 08 08 00 20 0C 00 00 FF FF FF FF FF FF FF FF FF FF 2247 FF FF FF FF 00 00) (in B's subtree) if Name A falls within the net 2248 denoted in Name B's CIDR notation. 2250 5.1.4.8 Others 2252 As the Internet PKI Profile [2459bis] does not define requirements 2253 for the name forms otherName, ediPartyName, or registeredID there are 2254 no corresponding name constraints requirements. 2256 5.1.5 Wildcards in Name Forms 2258 A "wildcard" in a name form is a placeholder for a set of names 2259 (e.g., "*.mit.edu" meaning "any domain name ending in .mit.edu", and 2260 *@aol.com meaning "email address that uses aol.com"). There are many 2261 people who believe that allowing wildcards in name forms in PKIX PKCs 2262 would be a useful thing to do, because it would allow a single PKC to 2263 be used by all members of a group. These members would presumably 2264 have attributes in common; e.g., access rights to some set of 2265 resources, and so issuance of a PKC with a wildcard for the group 2266 would simplify management. 2268 After much discussion, the PKIX working group decided to permit the 2269 use of wildcards in PKCs. That is, it is permissible for a PKIX- 2270 conformant CA to issue a PKC with a wildcard. However, the semantics 2271 of subjectAltName extension that include wildcard characters are not 2273 Arsenault, Turner 43 2274 addressed by PKIX. Applications with specific requirements may use 2275 such names but must define the semantics. 2277 5.1.6 Name Encoding 2279 A very important topic that consumed much of the WG's time was the 2280 implementation of the directory string choices. While the long term 2281 goal of the IETF was clear, use UTF8String, the short term goals were 2282 not so clear. Many implementations only use PrintableString, others 2283 use BMPString, and still others use Latin1String (ISO 8859-1) and tag 2284 it as TeletexString (there are others still). To ensure that there is 2285 consistency with encodings the Internet PKI Profile [2459bis] defines 2286 a set of rules for the string choices. PrintableString was kept as 2287 the first choice because of it's widespread support by vendors. 2288 BMPString was the second choice, also for it's widespread vendor 2289 support. Failing support by PrintableString and BMPString, UTF8String 2290 must be used. In keeping with the IETF mandate, UTF8String can be 2291 used at any time if the CA supports it. Also, processing 2292 implementations that wish to support TeletexString should handle the 2293 entire ISO 8859-1 character set and not just the Latin1String subset. 2295 5.2 POP 2297 Proof of Possession, or POP, or also CA POP, means that the CA is 2298 adequately convinced that the entity requesting a PKC containing a 2299 public key Y has access to the private key X corresponding to that 2300 public key. 2302 There has been some debate whether POP was or not needed. 2304 This question needs to be addressed separately considering the 2305 context of use of the key, in particular whether a key is used for an 2306 authentication or non repudiation service, or in a confidentiality 2307 service. Note that this does not map to the key usage bit directly, 2308 since it is possible to use a confidentiality key to perform an 2309 authentication service, e.g. by asking to decrypt an encrypted 2310 challenge. 2312 5.2.1 POP for Signing Keys 2314 It is important to provide POP for keys used to sign material, in 2315 order to provide non-repudiation of transactions. For example, 2316 suppose Alice legitimately has private key X and its corresponding 2317 public key Y. Alice has a PKC from Charlie, a CA, containing Y. Alice 2318 uses X to sign a transaction T. Without POP, Mal could also get a PKC 2319 from Charlie containing the same public key, Y. Now without POP, 2320 there are two possible threats: Mal could claim to have been the real 2321 signer of T; or Alice can falsely deny signing T, claiming that it 2322 was instead Mal. Since no one can reliably prove that Mal did or did 2323 not ever possess X, neither of these claims can be refuted, and thus 2325 Arsenault, Turner 44 2326 the service provided by and the confidence in the PKI has been 2327 defeated. (Of course, if Mal really did possess X, Alice's private 2328 key, then no POP mechanism in the world will help, but that is a 2329 different problem.) 2331 Protection can be gained by having Alice, as the true signer of the 2332 transaction, include in the signed information her PKC or an 2333 identifier of her PKC (e.g., a hash of her PKC). This makes 2334 impossible for Mal to claim authorship because he does not know the 2335 private key from Alice and thus is unable to include his certificate 2336 under the signature. 2338 The adequate protection may be obtained in the general case, by 2339 mandating the inclusion of a reference of the certificate every time 2340 a signature (or non repudiation) key is being used in a protocol. 2342 However, because all the protocols were not doing so, a conservative 2343 measure has been taken by requesting POP to be performed by CAs. It 2344 should thus be understood, that this measure is not strictly 2345 necessary and is only a temporary measure to make old protocols 2346 secure. New protocols or data formats are being developed. If the key 2347 being used is always used in a context where the identifier of the 2348 certificate is included in the protocol, then POP by the CA is not 2349 necessary. The inclusion of the identifier of the certificate in the 2350 protocol or data format may be understood as POP being performed at 2351 the transaction time rather than by the CA, at the registration time 2352 of the user in the PKI. 2354 5.2.2 POP for Key Management Keys 2356 Suppose that Al is a new instructor in the Computer Science 2357 Department of a local University. Al has created a draft final exam 2358 for the Introduction to Networking course he is teaching. He wants to 2359 send a copy of the draft final to Dorothy, the Department Head, for 2360 her review prior to giving the exam. This exam will of course be 2361 encrypted, as several students have access to the computer system. 2362 However, a quick search of the PKC repository (e.g., search the 2363 repository for all records with subjectPublicKey=Dorothy's-value) 2364 turns up the fact that several students have PKCs containing the same 2365 public key management key as Dorothy. At this point, if no POP has 2366 been done by the CA, Al has no way of knowing whether all of the 2367 students have simply created these PKCs without knowing the 2368 corresponding private key (and thus it is safe to send the encrypted 2369 exam to Dorothy), or whether the students have somehow acquired 2370 Dorothy's private key (and thus it is certainly not safe to send the 2371 exam). 2373 The later case may seem unsafe. However, if the other students have 2374 acquired the key, they do not even need to publish their certificates 2375 and can simply decrypt in parallel. 2377 Arsenault, Turner 45 2378 The end story is that, if the key only known to Dorothy, there is no 2379 problem. Thus POP by the CA is not needed. 2381 If the key, like a Diffie-Hellman key, is used for an authentication 2382 service the answer depends from the protocol being used. In the 2383 former example, the decryption was done locally and no data was sent 2384 back on the wire. In an authentication protocol, the story is 2385 different because either some encrypted or decrypted data is sent 2386 back. If the data sent back contains the identifier of the 2387 certificate in a way that it cannot be modified without that 2388 modification being detected, then there is no need for POP. On the 2389 contrary, POP by the CA is needed. 2391 As a conservative measure, POP for encryption keys is recommended, 2392 but it should be realized that it is not always needed. 2394 In general it should be noticed that POP at the time of the 2395 transaction is much superior than POP made by the CA, since it is 2396 possible in real time to be sure that everything is correct, rather 2397 than rely on that verification to be done at the time of registration 2398 by the CA. Should the CA fail in that verification, then there is a 2399 security breach. On the contrary, doing POP at the time of the 2400 transaction, eliminates that problem. 2402 CMP requires that POP be provided for all keys, either through on- 2403 line or out-of-band means. There are any number of ways to provide 2404 POP, and the choice of which to use is a local matter. Additionally, 2405 a PKC requester can provide POP to either a CA or to an RA, if the RA 2406 can adequately assure the CA that POP has been performed. Some of the 2407 acceptable ways to provide POP include: 2409 - Out-of-band means: 2411 - For keys generated by the CA or an RA (e.g., on a token such as 2412 a smart card or PCMCIA card), possession of the token can 2413 provide adequate proof of possession of the private key. 2415 - For user-generated keys, another approach can be used in 2416 environments where "key recovery" requirements force the 2417 requester to provide a copy of the private key to the CA or an 2418 RA. In this case, the CA will not issue the requested PKC until 2419 such time as the requester has provided the private key. This 2420 approach is in general not recommended, as it is extremely risky 2421 (e.g., the system designers need to figure out a way to protect 2422 the private keys from compromise while they are being sent to 2423 the CA/RA/other authority, and how to protect them there), but 2424 it can be used. 2426 - On-line means: 2428 - For signature keys that are generated by an EE, the requester of 2429 a PKC can be required to sign some piece of data (typically, the 2430 PKC request itself) using the private key. The CA will then use 2432 Arsenault, Turner 46 2433 the requested public key to verify the signature. If the 2434 signature verification works, the CA can safely conclude that 2435 the requester had access to the private key. If the signature 2436 verification process fails, the CA can conclude that the 2437 requester did not have access to the correct private key, and 2438 reject the request. 2440 - For key management keys that are generated by the requester, the 2441 CA can send the user the requested public key, along with the 2442 CA's own public key, to encrypt some piece of data, and send it 2443 to the requester to be decrypted. For example, the CA can 2444 generate some random challenge, and require some action to be 2445 taken after decryption (e.g., "decrypt this encrypted random 2446 number and send it back to me"). If the requester does not take 2447 the requested action, the CA concludes that the requester did 2448 not possess the private key, and the PKC is not issued. 2450 Another method of providing POP for key management keys is for the CA 2451 to generate the requested PKC, and then send it to the requester in 2452 encrypted form. If the requester does not have access to the 2453 appropriate private key, the requester cannot decrypt the PKC, and 2454 thus cannot use it. After some period of time in which the PKC is not 2455 used, the CA will revoke the PKC. (This only works if the PKC is not 2456 made available to any untrusted entities until after the requester 2457 has successfully decrypted it.) 2459 5.3 Key Usage Bits 2461 The key usage extension defines the purpose (e.g., encipherment, 2462 signature, certificate signing) of the key contained in the PKC. This 2463 extension is used when a key that could be used for more than one 2464 operation is to be restricted. For example, if a CA's RSA key should 2465 be used only for signing CRLS, the cRLSign bit would be asserted. 2466 Likewise, when an RSA key should be used only for key management, the 2467 keyEncipherment bit would be asserted. When used, this extension 2468 should be marked critical. 2470 The Internet PKI Profile [2459bis] includes some text for how the 2471 bits in the KeyUsage type are used. Developing the text for some of 2472 the bits was easy; however, many discussions were needed to arrive at 2473 a common agreement on the meaning of the digitalSignature (DS bit) 2474 and nonRepudiation (NR bit) bits and when they should be set. The 2475 group quickly realized that key usage extension mixes services and 2476 mechanisms. The DS bit indicates a mechanism - a public key used to 2477 verify a digital signature. The NR bit indicates a service - a public 2478 key used to verify a digital signature and to provide a non- 2479 repudiation service. When trying to indicate when each bit should be 2480 indicated arguments were based on: 2482 The lifetime of the object being signed. Some felt that the DS bit 2483 should be set when the certificate is used to sign ephemeral objects 2484 (e.g., bind tokens) while the NR bit should be set for things that 2486 Arsenault, Turner 47 2487 are survive longer (e.g., documents). Of course, the problem with 2488 this distinction to determine how long is the time period for 2489 ephemeral? 2491 A conscious act taken by the signer. Many felt that the NR bit should 2492 be set only when the subject has expressly acknowledged that they 2493 want to use the private key to sign an object. Signing a document say 2494 where there is a conscious decision by the subject would be 2495 appropriate for the key usage extension to contain NR, but when the 2496 key is used for authentication purposes, which can occur 2497 automatically and more frequently, the DS bit is more appropriate. 2498 The discussion also concluded that since some authentication schemes 2499 occur automatically, that the DS bit and NR bit should never be set 2500 together in the same certificate. Some agreed to the differentiation 2501 of the bits based on the time, but did not agree that the two could 2502 not be in the same key usage extension. 2504 The procedures followed by the CA. Some felt that NR bit was kind of 2505 'quality mark' indicating to the verifier that the verifier could be 2506 assured that the CA is implementing appropriate procedures for 2507 checking the subject's identity, performing certificate archival, 2508 etc. Other felt that it was not entirely the CAs job and that some 2509 other entity must be involved. 2511 In the end the WG agreed to a few things: 2513 - Provision of the service of non-repudiation requires more than a 2514 single bit set in a PKC. It requires an entire infrastructure of 2515 components to preserve for some period of time the keys, PKCs, 2516 revocation status, signed material, etc., as well as a trusted 2517 source of time. However, the nonRepudiation key usage bit is 2518 provided as an indicator that such keys could be used as a 2519 component of a system providing a non-repudiation service. 2521 - The certificate policy is the appropriate place to indicate the 2522 permitted combinations of key usages. That is, a policy may 2523 indicate that the DS and NR bits can not be set in the same 2524 certificate while another may say that the DS and NR bits can be 2525 set in the same certificate. 2527 [2459bis] includes new text indicating the above agreements. 2529 5.4 Non-Repudiation 2531 The major benefit of the whole DS bit vs NR bit discussion is 2532 development of the Technical Requirements for Non-Repudiation 2533 [TECHNR] draft. To fill this void [TECHNR] was developed to "describe 2534 those features of a service which processes signed documents which 2535 must be present in order for that service to constitute a 'technical 2536 non-repudiation' service." The basic understanding of non-repudiation 2537 is that it requires that a digital signature be preserved in such a 2538 manner that it can convince a neutral third party that it was 2540 Arsenault, Turner 48 2541 actually created by someone with access to the private key of a 2542 certified key pair. Whether this definition of non-repudiation is 2543 enough to form a legally bind agreement is still being debated. 2545 5.5 Trust Models 2547 An important design decision is, for a given application, where the 2548 particular EE's trust points are located (i.e. what are the Top 2549 CAs). There are a number of models that have been developed and 2550 depending on the environment some models may be more suited than 2551 others. The following provides some background on the models. 2553 5.5.1 Hierarchical 2555 One of the initial trust models proposed was the hierarchical model. 2556 In this model the trust point or root CA for an entire domain is the 2557 top most CA. The root CA in turn issues certificates to subordinate 2558 CAs, and the subordinate CAs issue certificates to EEs. When 2559 verifying a PKC, the RP must verify ever certificate in the path from 2560 the EE's PKC to the root CA. 2562 The main benefit of the hierarchical model is the fact that controls 2563 imposed from the top down. For example, name constraints can be 2564 included in the subordinate CAs to limit the name space in which they 2565 are allowed to issue certificates. Further, the root CA ensure domain 2566 wide policies on cross-certification (though there are no controls to 2567 prevent another PKI from issuing PKCs to members of the domain, but 2568 then those members could be thought of as members of two distinct 2569 PKIs). 2571 Interoperability is achieved through the use of cross-certificates. 2572 Cross-certificates can be issued by the root CA or if allowed by 2573 subordinate CAs. 2575 5.5.2 Local/Federation 2577 Another model that has been around a long time is the local trust 2578 model. In this model, the RPs trust the CA that issued their 2579 certificate to them. The idea is that since the CA is local and 2580 probably known to the RP, that there is more trust rather than with 2581 some distant unknown CA. 2583 In order for EEs under different CAs to communicate the CAs issue 2584 each other certificates thereby creating a certification path from 2585 one EE to another. The process of the CAs issuing one another PKCs 2586 forms a kind of federation 2588 The main benefit of the local model is its flexibility. Many believe 2589 that the local CA knows best how to support its user community and 2591 Arsenault, Turner 49 2592 should be given cart blanche to generate certificates as it sees fit 2593 to allow the user community to perform their functions. 2595 5.5.3 Root Repository 2597 A model made famous in the web browser community is the root 2598 repository. This model uses a file to store the PKCs of many CAs. The 2599 RP then trusts any PKC included in the file. The PKC included in the 2600 root repository may be a root CA for some other domain or subordinate 2601 CA, but when included in the trust file whatever type of PKC it is in 2602 the other domain, it becomes a root CA for the RP. Obviously, the 2603 main advantage is the fact that cross-certification is not required. 2604 If the RP does not have the root CA's certificate and it is included 2605 in with the object, the RP can just add it to the file to "trust" it 2606 (this should only be done if the RP truly trusts the root CA). 2608 5.5.4 RP's Perspective 2610 Another model recently getting attention is the model where instead 2611 of the CA imposing restraints on the RP (in the PKC), the RP instead 2612 makes the determination as to which certificates to trust. The RP 2613 determines which domain it will accept certificates from, which key 2614 usages it will accept, etc. Cross-certification is also not required 2615 because the RP can just chose to trust a particular PKC or domain of 2616 PKCs. This obviously turns the first three models on their heads. 2617 Special care must be taken to ensure that the RP is properly 2618 configured. 2620 5.5.5 Validation Policies 2622 Another model considers a set of rules that apply to an application 2623 context. Every application context may have a different set of 2624 rules. When choosing to use certificates in the context of that 2625 application, the EE selects the set of rules for that context. In a 2626 set of rules, one or more Top CAs may be trusted, each one may be 2627 associated with different constraints, like the certificate policies 2628 that are trusted or the naming constraints that apply. These 2629 constrains may be specified either in self-signed certificates or in 2630 addition to self-signed certificates when they do not incorporate 2631 these constraints. This set of rules is called a validation policy 2632 (when validating a certificate) or a signature policy (when 2633 validating a digital signature). 2635 6 References 2637 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 2638 3", BCP 9, RFC 2026, October 1996. 2640 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2641 Requirement Levels", BCP 14, RFC 2119, March 1997. 2643 Arsenault, Turner 50 2645 [2459bis] Housley, R., Ford, W., Polk, W., and Solo, D., "Internet 2646 X.509 Public Key Infrastructure Certificate and CRL Profile," RFC 2647 3280, April 2002. 2649 [2510bis] Adams, C., Farrell, S., "Internet X.509 Public Key 2650 Infrastructure Certificate Management Protocols," , December 2001. 2653 [2511bis] Myers, M., Adams, C., Solo, D., and Kemp D. "Internet X.509 2654 Public Key Infrastructure Certificate Request Message Format 2655 (CRMF)," , December 2001. 2657 [2527bis] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and Wu, 2658 S., "Internet X.509 Public Key Infrastructure Certificate Policy and 2659 Certification Practices Framework," , January 2002. 2662 [2797bis] Myers, M., Liu, X., Fox, B., and Weinstein, J., 2663 "Certificate Management Messages over CMS," , February 2002. 2666 [AC] Farrell, S., and Housley, R., "An Internet Attribute Certificate 2667 Profile for Authorization," RFC 3281, April 2002. 2669 [ACRMF] Yee, P., "Attribute Certificate Request Message Format," 2670 , March 2002. 2672 [ACMC] Yee, P., "Attribute Certificate Management Messages over CMS," 2673 , March 2002. 2675 [ADDSCHEMA] Chadwick, D., Legg, S., "Internet X.509 Public Key 2676 Infrastructure Additional LDAP Schema for PKIs and PMIs," , November 2001. 2679 [CMC] Myers, M., Liu, X., Schaad, J., and Weinstein, J., "Certificate 2680 Management Messages over CMS," (RFC 2797), April 2000. 2682 [CMP] Adams, C., Farrell, S., "Internet X.509 Public Key 2683 Infrastructure Certificate Management Protocols," RFC 2510, March 2684 1999. 2686 [CMS] R. Housley, "Cryptographic Message Syntax," RFC 2630, July 2687 1999. 2689 [CRMF] Myers, M., Adams, C., Solo, D., and Kemp, D., "Internet X.509 2690 Certificate Request Message Format," RFC 2511, March 1999. 2692 [DNS] Mockapetris, P.V., "Domain names - concepts and facilities," 2693 RFC 1034, November 1987. 2695 [DHPOP] Prafullchandra, H., and Schaad, J., "Diffie-Hellman Proof- 2696 of-Possession Algorithms," RFC 2875, July 2000 1999. 2698 Arsenault, Turner 51 2700 [DPD] Myers, M., Adams, C., Farrell, S., "Delegated Path Discovery 2701 with OCSP". 2703 [DPV] Myers, M., Adams, C., Farrell, S., "Delegated Path Validation". 2705 [DPREQ] Pinaks, D., Housley, R., "Delegated Path Validation and 2706 Delegated Path Discovery Protocol Requirements (DPV&DPD-REQ)," 2707 , April 2002. 2709 [DVCS] Adams, C., Sylvester, P., Zolotarev, M., Zuccherato, R., 2710 "Internet X.509 Public Key Infrastructure Data Certification Server 2711 Protocols", RFC 3029, February 2001. 2713 [FTPHTTP] Housley, R., and Hoffman, P., "Internet X.509 Public Key 2714 Infrastructure Operational Protocols: FTP and HTTP," RFC 2585, July 2715 1998. 2717 [IP] Postel, J., "Internet Protocol," RFC 791, September 1981. 2719 [IPEXT] Lynn, C., Kent, S., Seo, K., "X.509 Extensions for IP 2720 Addresses and AS Identifiers," , February 2002. 2723 [IPv6] Deering, S., and Hinden, R., "Internet Protocol, Version 6 2724 [IPv6] Specification," RFC 1883, December 1995. 2726 [KEA] Housley, R., and Polk, W., "Internet X.509 Public Key 2727 Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in 2728 Internet X.509 Public Key Infrastructure Certificates," RFC 2528, 2729 March 1999. 2731 [LAAP] Farrell, S., Chadwick, C.W., "Limited Attribute Certificate 2732 Acquisition Protocol". 2734 [LDAPv2] Yeong, Y., Howes, T., and Kille, S., "Lightweight Directory 2735 Access Protocol", RFC 1777, March 1995. 2737 [LOGO] Santesson, S. Housley, R., Freeman, T., "X.509 Internet Public 2738 Key Infrastructure Logotypes in X.509 Certificates," , April 2002. 2741 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and Adams, 2742 C., "X.509 Internet Public Key Infrastructure Online Certificate 2743 Status Protocol - OCSP," RFC 2560, June 1999. 2745 [OCSPv2] Myers, M., Ankney, R., Adams, C., "Online Certificate Status 2746 Protocol, version 2," , March 2001. 2748 [MISPC] Burr, W., Dodson, D., Nazario, N., and Polk, W., "MISPC 2749 Minimum Interoperability Specification for PKI Components, Version 2750 1", , 3 September 1997. 2752 Arsenault, Turner 52 2754 [PEM] Kent, S., "Privacy Enhancement for Internet Electronic Mail: 2755 Part II: Certificate-Based Key Management," RFC 1422, February 1993. 2757 [PI] Pinka, D., Gindin, T., "Internet X.509 Public Key Infrastructure 2758 Permanent Identifier," , February 2002. 2760 [PKI-LDAPv2] Boeyen, S., Howes, T., and Richard, P., "Internet X.509 2761 Public Key Infrastructure Operational Protocols - LDAPv2," RFC 2559, 2762 April 1999. 2764 [PKI-LDAPv3] Chadwick, D.W., "Internet X.509 Public Key 2765 Infrastructure Operational Protocols - LDAPv3," , January 2002. 2768 [POLPRAC] Chokhani, S., and Ford, W., "Internet X.509 Public Key 2769 Infrastructure Certificate Policy and Certification Practices 2770 Framework," RFC 2527, March 1999. 2772 [QC] Santesson, S., Polk, W., Barzin, P., and Nystrom, M., "Internet 2773 X.509 Public Key Infrastructure Qualified Certificates," RFC 3039, 2774 January 2001. 2776 [RLS] Boeyen, S., Hallam-Baker, P., "Internet X.509 Public Key 2777 Infrastructure Repository Locator Service," , July 2000. 2780 [RPKDS] Bassham, L., Housley, R., Polk, W., "Algorithms and 2781 Identifiers for the Internet X.509 Public Key Infrastructure 2782 Certificate and CRL Profile," RFC 3279, April 2002. 2784 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 2785 Messages," RFC 822, August 1982. 2787 [SCHEMA] Boeyen, S., Howes, T., and Richard, P., "Internet X.509 2788 Public Key Infrastructure LDAPv2 Schema," RFC 2587, June 1999. 2790 [SCVP] Malpani, A., Hoffman, P., Housley, R., and Freeman, T., 2791 "Simple Certificate Validation Protocol (SCVP)," , March 2002. 2794 [SIMONETTI] Simonetti, D., "Re: German Key Usage", posting to ietf- 2795 pkix@imc.org mailing list, 12 August 1998. 2797 [SSKGKA] Schaad, J., " CMC Extensions: Server Side Key Generation and 2798 Key Archival," , July 2001. 2800 [SUPPALGS] Singer, A., and Whyte, W., "Supplemental Algorithms and 2801 Identifiers for the Internet X.509 Public Key Infrastructure 2802 Certificate and CRL Profile," , 2803 March 2002. 2805 [TECHNR] Gindin, T., "Internet X.509 Public Key Infrastructure 2806 Technical Requirements for a non-Repudiation Service," December 2000. 2808 Arsenault, Turner 53 2810 [TPCMC] Schaad, J. Myers, M., Liu, X., Weinstein, J., "CMC 2811 Transport," , March 2002. 2813 [TPCMP] Kapoor , A., Tschalaer, R., "Transport Protocols for CMP," 2814 , November 2000. 2816 [TSP] Adams, C., Cain, P., Pinkas, D., and Zuccherato, R., "Internet 2817 X.509 Public Key Infrastructure Time Stamp Protocols", RFC 3161, 2818 August 2001. 2820 [X.509] ITU-T Recommendation X.509 (1997 E): Information Technology - 2821 Open Systems Interconnection - The Directory: Authentication 2822 Framework, June 1997. 2824 [X9.42] ANSI X9.42-199x, Public Key Cryptography for The Financial 2825 Services Industry: Agreement of Symmetric Algorithm Keys Using 2826 Diffie-Hellman (Working Draft), December 1997. 2828 [X9.55] ANSI X9.55-1995, Public Key Cryptography For The Financial 2829 Services Industry: Extensions To Public Key Certificates And 2830 Certificate Revocation Lists, 8 December, 1995. 2832 [X9.57] ANSI X9.57-199x, Public Key Cryptography For The Financial 2833 Services Industry: Certificate Management (Working Draft), 21 June, 2834 1996. 2836 [WARR] Linsenbardt, D., Pontius, S., "Warranty Certificate 2837 Extension," , April 2002. 2839 [PKCS10] RSA Laboratories, "The Public-Key Cryptography 2840 Standards(PKCS)," RSA Data Security Inc., Redwood City, California, 2841 November 1993 Release. 2843 7 Security Considerations 2845 This document records the history and design philosophy of the of 2846 standards to support in a particular infrastructure or application. 2847 Individual PKIX documents specify a variety of message formats and 2848 protocols; a selection of these formats and protocols will be 2849 necessary to construct a complete infrastructure. 2851 This specification does not specify security considerations, since 2852 they are determined by selection of formats and protocols. However, 2853 each PKIX document specifies security considerations that are 2854 associated with the message formats or protocols defined in that 2855 particular standard. These security considerations must be 2856 considered in aggregate when deploying or designing a particular 2857 infrastructure or PKI-enabled application protocol. 2859 Arsenault, Turner 54 2860 8 Acknowledgements 2862 A lot of the information in this document was taken from the PKIX 2863 source documents; the authors of those deserve the credit for their 2864 own words. Other good material was taken from mail posted to the PKIX 2865 working group mail list (ietf-pkix@imc.org). Among those with good 2866 things to say were (with apologies to anybody we've missed): Sharon 2867 Boeyen, Santosh Chokhani, Warwick Ford, Russ Housley, Steve Kent, 2868 Ambarish Malpani, Matt Fite, Michael Myers, Tim Polk, Stefan 2869 Santesson, Dave Simonetti, Paul Hoffman, Denis Pinkas, Ed Gerck, Tom 2870 Gindin, Parag Namjoshi, Peter Sylvester, and Michael Zolotarev. 2872 9 Author's Addresses 2874 Alfred W. Arsenault 2875 Diversinet Corp. 2876 P.O. Box 6530 2877 Ellicott City, MD 21042-0530 2878 aarsenault@dvnet.com 2880 Sean Turner 2881 IECA, Inc. 2882 9010 Edgepark Road Vienna, VA 22182 2883 (703) 628-3180 2884 turners@ieca.com 2886 Expires January 2003 2888 Arsenault, Turner 55