idnits 2.17.00 (12 Aug 2021) /tmp/idnits13671/draft-ietf-pkix-roadmap-07.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-20) 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. == There are 25 instances of lines with non-ascii characters in the document. == 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: ---------------------------------------------------------------------------- -- 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 (January 2002) is 7430 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: 'DCVS' is mentioned on line 367, but not defined == Missing Reference: 'TRNRS' is mentioned on line 372, but not defined == Missing Reference: 'REP' is mentioned on line 392, but not defined == Missing Reference: 'POLPROC' is mentioned on line 1368, but not defined == Missing Reference: 'RFC2459' is mentioned on line 972, but not defined ** Obsolete undefined reference: RFC 2459 (Obsoleted by RFC 3280) == Missing Reference: 'CMPT' is mentioned on line 1346, but not defined == Missing Reference: 'DSV' is mentioned on line 1468, but not defined == Missing Reference: 'HTTP' is mentioned on line 1653, but not defined == Missing Reference: 'TCP' is mentioned on line 1666, but not defined == Missing Reference: 'RFC 1738' is mentioned on line 1878, but not defined ** Obsolete undefined reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) == Unused Reference: '2527bis' is defined on line 2518, but no explicit reference was found in the text == Unused Reference: 'POLPRAC' is defined on line 2614, but no explicit reference was found in the text == Unused Reference: 'SIMONETTI' is defined on line 2659, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2459bis' ** Obsolete normative reference: RFC 2510 (Obsoleted by RFC 4210) ** 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. 'AC' -- 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') ** 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) ** 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'RPKDS' ** 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. 'SUPPALGS' -- Possible downref: Non-RFC (?) normative reference: ref. 'TECHNR' -- Possible downref: Non-RFC (?) normative reference: ref. 'TPCMP' ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) -- Possible downref: Non-RFC (?) normative reference: ref. 'SIMONETTI' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS10' Summary: 25 errors (**), 0 flaws (~~), 17 warnings (==), 24 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group A. Aresenault 3 Internet Draft Diversinet 4 Document: draft-ietf-pkix-roadmap-07.txt S. Turner 5 Expires: July, 2002 IECA 6 January 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-smime' mailing list. To 32 subscribe, send a message to ietf-smime-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 Turner 1 51 Conventions used in this document 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in [RFC2119]. 57 1 INTRODUCTION.....................................................3 58 1.1 THIS DOCUMENT..................................................3 59 1.2 TERMINOLOGY....................................................4 60 1.3 HISTORY........................................................5 61 2 PKI..............................................................8 62 2.1 THEORY.........................................................8 63 2.2 ARCHITECTURE MODEL............................................10 64 2.3 PUBLIC KEY CERTIFICATES.......................................11 65 2.4 FUNCTIONS OF A PKI............................................12 66 2.4.1 REGISTRATION................................................12 67 2.4.2 INITIALIZATION..............................................12 68 2.4.3 CERTIFICATION...............................................13 69 2.4.4 KEY PAIR RECOVERY...........................................13 70 2.4.5 KEY GENERATION..............................................13 71 2.4.6 KEY UPDATE..................................................13 72 2.4.6.1 KEY EXPIRY................................................13 73 2.4.6.2 KEY COMPROMISE............................................14 74 2.4.7 CROSS-CERTIFICATION.........................................14 75 2.4.8 REVOCATION..................................................15 76 2.4.9 CERTIFICATE & REVOCATION NOTICE DISTRIBUTION & PUBLICATION..16 77 3 PMI.............................................................16 78 3.1 THEORY........................................................16 79 3.2 ARCHITECTURAL MODEL...........................................17 80 3.3 ATTRIBUTE CERTIFICATES........................................18 81 4 PKIX DOCUMENTS..................................................19 82 4.1 PROFILES......................................................19 83 4.2 OPERATIONAL PROTOCOLS.........................................22 84 4.3 MANAGEMENT PROTOCOLS..........................................25 85 4.4 POLICY OUTLINE................................................27 86 4.4 TIME STAMPING AND DATA CERTIFICATION..........................28 87 4.5 EXPIRED DRAFTS................................................30 88 5 IMPLEMENTATION ADVICE...........................................34 89 5.1 NAMES.........................................................35 90 5.1.1 NAME FORMS..................................................35 91 5.1.1.1 DISTINGUISHED NAMES.......................................35 92 5.1.1.2 SUBJECTALTNAME FORMS......................................35 93 5.1.1.2.1 INTERNET E-MAIL ADDRESSES...............................36 94 5.1.1.2.2 DNS NAMES...............................................36 95 5.1.1.2.4 URIS....................................................37 96 5.1.2 SCOPE OF NAMES..............................................37 97 5.1.3 CERTIFICATE PATH CONSTRUCTION...............................38 98 5.1.4 NAME CONSTRAINTS............................................39 99 5.1.4.1 RFC822NAMES...............................................39 100 5.1.4.2 DNSNAMES..................................................40 101 5.1.4.3 X.400 ADDRESSES...........................................40 102 5.1.4.5 DNS.......................................................40 104 Arsenault, Turner 2 105 5.1.4.6 URIS......................................................41 106 5.1.4.7 IPADDRESSES...............................................41 107 5.1.4.8 OTHERS....................................................42 108 5.1.5 WILDCARDS IN NAME FORMS.....................................42 109 5.1.6 NAME ENCODING...............................................42 110 5.2 POP...........................................................43 111 5.2.1 POP FOR SIGNING KEYS........................................43 112 5.2.2 POP FOR KEY MANAGEMENT KEYS.................................44 113 5.3 KEY USAGE BITS................................................46 114 5.4 NON-REPUDIATION...............................................47 115 5.5 TRUST MODELS..................................................47 116 5.5.1 HIERARCHICAL................................................47 117 5.5.2 LOCAL/FEDERATION............................................48 118 5.5.3 ROOT REPOSITORY.............................................48 119 5.5.4 RP'S PERSPECTIVE............................................49 120 6 REFERENCES......................................................49 121 7 SECURITY CONSIDERATIONS.........................................52 122 8 ACKNOWLEDGEMENTS................................................52 123 9 AUTHOR'S ADDRESSES..............................................53 125 1 Introduction 127 1.1 This Document 129 This document is an informational Internet-Draft that provides a 130 "roadmap" to the documents produced by the PKIX working group. It is 131 intended to provide information; there are no requirements or 132 specifications in this document. 134 Section 1.2 of this document defines key terms used in this document. 135 Section 1.3 covers some of the basic history behind the PKIC working 136 group. Section 2 covers Public Key Infrastructure (PKI) theory and 137 functions. Section 3 covers Privilege Management Infrastructure (PMI) 138 theory and functions. Sections 2 through 5 attempts to explain the 139 PKIX working group's basic assumptions in each of the areas. Section 140 4 provides an overview of the various PKIX documents. It identifies 141 which documents address which areas, and describes the relationships 142 among the various documents. Section 5 contains "Advice to 143 implementors." Its primary purpose is to capture some of the major 144 issues discussed by the PKIX working group, as a way of explaining 145 WHY some of the requirements and specifications say what they say. 146 This should cut down on the number of misinterpretations of the 147 documents, and help developers build interoperable implementations. 148 Section 6 contains a list of contributors we wish to thank. Section 7 149 provides a list references. Section 8 discusses security 150 considerations, and Section 9 provides contact information for the 151 editors. Finally, Section 10 provides a disclaimer. 153 Arsenault, Turner 3 154 1.2 Terminology 156 There are a number of terms used and misused throughout PKI-related, 157 PMI-related, and Time Stamp and Data Certification literature. To 158 limit confusion caused by some of those terms, used throughout this 159 document, we will use the following terms in the following ways: 161 - Attribute Authority (AA) - An authority trusted by one or more 162 users to create and sign attribute certificates. It is important 163 to note that the AA is responsible for the attribute 164 certificates during their whole lifetime, not just for issuing 165 them. 167 - Attribute Certificate (AC) - A data structure containing a set of 168 attributes for an end-entity and some other information, which 169 is digitally signed with the private key of the AA which issued 170 it. 172 - Certificate - Can refer to either an AC or a public key 173 certificate. Where there is no distinction made the context 174 should be assumed that the term could apply to both an AC or a 175 public key certificate. 177 - Certification Authority (CA) - An authority trusted by one or 178 more users to create and assign public key certificates. 179 Optionally the CA may create the user's keys. It is important to 180 note that the CA is responsible for the public key certificates 181 during their whole lifetime, not just for issuing them. 183 - Certificate Policy (CP) - A named set of rules that indicates the 184 applicability of a public key certificate to a particular 185 community or class of application with common security 186 requirements. For example, a particular certificate policy might 187 indicate applicability of a type of public key certificate to 188 the authentication of electronic data interchange transactions 189 for the trading of goods within a given price range. 191 - Certification Practice Statement (CPS) - A statement of the 192 practices which a CA employs in issuing public key certificates. 194 - End-entity - A subject of a certificate who is not a CA in the 195 PKIC or an AA in the PMI. (An EE from the PKI can be an AA in 196 the PMI.) 198 - Public Key Certificate (PKC) - A data structure containing the 199 public key of an end-entity and some other information, which is 200 digitally signed with the private key of the CA which issued it. 202 - Public Key Infrastructure (PKI) - The set of hardware, software, 203 people, policies and procedures needed to create, manage, store, 204 distribute, and revoke PKCs based on public-key cryptography. 206 Arsenault, Turner 4 207 - Privilege Management Infrastructure (PMI) - A collection of ACs, 208 with their issuing AA's, subjects, relying parties, and 209 repositories, is referred to as a Privilege Management 210 Infrastructure. 212 - Registration Authority (RA) - An optional entity given 213 responsibility for performing some of the administrative tasks 214 necessary in the registration of subjects, such as: confirming 215 the subject's identity; validating that the subject is entitled 216 to have the values requested in a PKC; and verifying that the 217 subject has possession of the private key associated with the 218 public key requested for a PKC. 220 - Relying party - A user or agent (e.g., a client or server) who 221 relies on the data in a certificate in making decisions. 223 - Root CA - A CA that is directly trusted by an EE; that is, 224 securely acquiring the value of a Root CA public key requires 225 some out-of-band step(s). This term is not meant to imply that a 226 Root CA is necessarily at the top of any hierarchy, simply that 227 the CA in question is trusted directly. 229 - Subordinate CA - A "subordinate CA" is one that is not a Root CA 230 for the EE in question. Often, a subordinate CA will not be a 231 Root CA for any entity but this is not mandatory. 233 - Subject - A subject is the entity (AA, CA, or EE) named in a 234 certificate, either a PKC or AC. Subjects can be human users, 235 computers (as represented by Domain Name Service (DNS) names or 236 Internet Protocol (IP) addresses), or even software agents. 238 - Time Stamp Authority (TSA) - A TSA is a trusted Third Party who 239 provides a "proof-of-existence" for a particular datum at an 240 instant in time. 242 - Top CA - A CA that is at the top of a PKI hierarchy. 244 Note: This is often also called a "Root CA," since in data structures 245 terms and in graph theory, the node at the top of a tree is the 246 "root." However, to minimize confusion in this document, we elect to 247 call this node a "Top CA," and reserve "Root CA" for the CA directly 248 trusted by the EE. Readers new to PKIX should be aware that these 249 terms are not used consistently throughout the PKIX documents, as the 250 Internet PKI profile [2459bis] uses "Root CA" to refer to what this 251 and other documents call a "Top CA," and "most-trusted CA" to refer 252 to what this and other documents call a "Root CA." 254 1.3 History 256 The PKIX working group was formed in October of 1995 to develop 257 Internet standards necessary to support PKIs. The first work item was 258 a profile of the ITU-T Recommendation X.509 PKC. X.509, which is a 260 Arsenault, Turner 5 261 widely accepted basis for a PKI, including data formats and 262 procedures related to distribution of public keys via PKCs digitally 263 signed by CAs. X.509 does not however include a profile to specify 264 the support requirements for many of the PKC data structure's sub- 265 fields, for any of the extensions, nor for certain data values. The 266 Internet PKI profile [2459bis] went through eleven draft versions 267 before becoming an RFC. Other profiles have been developed in PKIX 268 for particular algorithms to make use of the Internet PKI Profile 269 [2459bis]. There has been no sense of conflict between the authors 270 that developed these profiles as they are seen as complimentary. The 271 Internet PKI profile has been a draft standard for more than six 272 months and is currently going through an update process to clarify 273 any inconsistencies and to bolster certain sections. 275 In parallel with the profile development, work was undertaken to 276 develop the protocols necessary to manage PKI-related information 277 was. The first developed was the Certificate Management Protocol 278 (CMP). It defines a message protocol to initializing, certifying, 279 updating, and revoking PKI entities [CMP]. The demand for an 280 enrollment protocol and the desire to use PKCS-10 message format as 281 the certificate request syntax lead to the development of two 282 different documents in two different groups. The Certificate Request 283 Syntax (CRS) draft was developed in the SMIME WG which used PKCS-10 284 [PKCS10] as the certification request message format. Certificate 285 Request Message Format [CRMF] draft was also developed but in the 286 PKIX WG. It was to define a simple enrollment protocol that would 287 subsume both the CMP and CRS enrollment protocols, but it did not use 288 PKCS-10 as the certificate request message format. Then the 289 certificate management message format document, was developed to 290 define an extended set of management messages that flow between the 291 components of the Internet PKI. Certificate Management Messages over 292 CMS (CMC) was developed to allow the use of an existing protocol 293 (S/MIME) as a PKI management protocol, without requiring the 294 development of an entirely new protocol such as CMP [CMC]. It also 295 included [PKCS10] as the certificate request syntax, which caused 296 work on the CRS draft to stop. Information from the certificate 297 management message format document was moved into [CMP] and [CMC] so 298 work on the certificate management message format document was 299 discontinued. After some operational experience with [CMP], two 300 drafts, one for using HTTP as the transport protocol and one for 301 Transmission Control Protocol (TCP), were written to solve problems 302 encountered by implementors. These drafts were merged into one draft 303 Transport Protocols for CMP [TPCMP]. [CMP] has been a draft standard 304 for more than six months and is currently undergoing revisions to 305 document. The transport section has been removed and will remain in 306 [TPCMP]. 308 Another long debated topic in the WG dealt with certificate 309 revocation. Numerous drafts have been developed to address different 310 issues related certificate revocations. CMP supports revocation 311 request, response, revocation announcement, and requests for CRL 312 messages. CMC defines revocation request, revocation response, and 313 requests for CRL messages, but uses CMS as the encapsulating 315 Arsenault, Turner 6 316 protocol. [OCSP] was developed to address concerns that not all 317 relying parties want to go through the process checking CRLs from 318 every CA in the certification path. It defines an on-line mechanism 319 to determine the status of a given certificate, which may provide 320 more timely revocation information than is possible with CRLs. The 321 Simple Certification Verification Protocol (SCVP) was produced to 322 allow relying parties to off-load all of their certification 323 verification to another entity [SCVP]. The WG was arguably split over 324 whether such a function should be supported and whether it should be 325 its own protocol or included in OCSP. In response, a draft defining 326 OCSP Extensions was produced to include the functions of SCVP. [OCSP] 327 has been a draft standard for more than six months and is in the 328 process of being revised [OCSPv2]. To capture the work from the OCSP 329 Extensions, two drafts were developed: Delegated Path Validation 330 [DPV] and Delegated Path Discovery [DPD]. After considerable debate, 331 the WG selected SCVP as the PKIX protocol for delegated path 332 validation and delegated path discovery. A requirements document has 333 been developed, and is currently under WG review. [DPREQ] Upon 334 completion of [DPREQ], the SCVP protocol will be completed. 336 One other certificate status draft called Open CRL Distribution Point 337 (OCDP) was produced which documented two extensions: one to support 338 an alternative CRL partitioning mechanism to the CRL Distribution 339 Point mechanism documented in the Internet PKI Profile [2459bis] and 340 one to support identifying other revocation sources available to 341 certificate-users. The work from this draft was subsumed by an ITU-T 342 | ISO/IEC Amendment to X.509, hence work on this draft was halted. 344 Development of the operational protocols has been slightly more 345 straightforward. Four documents for the Light Weight Directory Access 346 Protocol (LDAP) have been developed one for defining LDAPv2 as an 347 access protocol to repositories [PKI-LDAPv2]; two for storing PKI 348 information in an directory [SCHEMA] and [ADDSCHEMA]; and one for 349 LDAPv3 requirements for PKI [PKI-LDAPv3]. Using the File Transfer 350 Protocol (FTP) and the Hyper Text Transmission Protocol (HTTP) to 351 retrieve PKCs and CRLs from PKI repositories was documented in 352 [FTPHTTP]. Recognizing that LDAP directories are not the only 353 repository service, the working group draft a Repository Locator 354 Service [RLS] to make use of DNS SRV records to locate where and how 355 PKI information can be retrieved from a repository. 357 In late 1998 the PKIX charter was revised to include protocols for 358 time stamping and data certification services. [TSP] was developed to 359 define protocols required to interact with a Time Stamp Authority 360 (TSA) who asserts that a datum existed at a given time. [DVCS] allows 361 to verify and assert the validity of all signatures attached to the 362 signed document using all appropriate status information and PKCs or 363 to verify and assert the validity of one or more PKCs at the 364 specified time. Both [DVCS] and [TSP] use [CMS] as an encapsulating 365 (though in [TSP] request for a time stamp are not required to use 366 [CMS]). A draft for extending trust in tokens in time was developed 367 to use [DCVS] to maintain the trust in a token issued by a non- 368 repudiation Trusted Third Party (NR TTP) after the key initially used 370 Arsenault, Turner 7 371 to establish trust in the token expires; however, this draft has 372 expired. The [TRNRS] draft was developed to describe those features 373 of a service which processes signed documents that must be present in 374 order for that service to constitute a "technical non- repudiation" 375 service. 377 Around the same time, a work item for ACs, defined in [X.509], was 378 added. ACs are similar to PKCs, but they do not bind public keys to 379 identities rather they bind attributes to identities. The attributes 380 bound to the identity can represent anything, but are mostly used to 381 support rule-based and role-based access control decisions. Two 382 drafts have since been developed: the Internet Attribute Certificates 383 Profile for Authorizations [AC] and the Limited Attribute Certificate 384 Acquisition Protocol [LAAP]. The first profiles the fields and 385 extensions of the AC and the second provides a deliberately limited 386 protocol to access a repository when LDAP is not appropriate. 388 Other drafts have been produced to address specific issues. [DHPOP] 389 was developed to define two mechanisms by which a signature can 390 produced using a Diffie-Hellman pair. This draft provides a mechanism 391 to use Diffie-Hellam key pairs to authenticate a PKCS-10 392 certification request. [REP] was developed during the revision to the 393 Internet PKI Profile [2459bis] to separate the definitions of the 394 object identifiers and encoding rules for keys and digital signatures 395 in PKCs. The Qualified Certificates [QC] and Permanent Identifier 396 [PI] drafts were developed to address naming issues. 398 From the alphabet soup above, it is clear why this roadmap is 399 required. 401 2 PKI 403 2.1 Theory 405 At the heart of recent efforts to improve Internet security are a 406 group of security protocols such as Secure Multipurpose Internet Mail 407 Extensions (S/MIME), Transport Layer Security (TLS), and Internet 408 Protocol Security (IPSec). All of these protocols rely on public-key 409 cryptography to provide services such as confidentiality, data 410 integrity, data origin authentication, and non-repudiation. The 411 purpose of a PKI is to provide trusted and efficient key and public 412 key certificate management, thus enabling the use of authentication, 413 non-repudiation, and confidentiality. 415 Users of public key-based systems must be confident that, any time 416 they rely on a public key, the subject that they are communicating 417 with owns the associated private key, this applies whether an 418 encryption or digital signature mechanism is used. This confidence is 419 obtained through the use of PKCs, which are data structures that bind 420 public key values to subjects. The binding is achieved by having a 421 trusted CA verify the subject's identity and digitally sign each PKC. 423 Arsenault, Turner 8 424 A PKC has a limited valid lifetime, which is indicated in its signed 425 contents. Because a PKC's signature and timeliness can be 426 independently checked by a certificate-using client, PKCs can be 427 distributed via untrusted communications and server systems, and can 428 be cached in unsecured storage in certificate-using systems. 430 PKCs are used in the process of validating signed data. Specifics 431 vary according to which algorithm is used, but the general process 432 works as follows: 433 Note: there is no specific order in which the checks listed below 434 must be made; implementors are free to implement them in the most 435 efficient way for their systems. 437 - The recipient of signed data verifies that the claimed identity 438 of the user is in accordance with the identity contained in the 439 PKC; 441 - The recipient validates that no PKC in the path is revoked (e.g., 442 by retrieving a suitably-current Certificate Revocation List 443 (CRL) or querying an on-line certificate status responder), and 444 that all PKCs are within their validity periods at the time the 445 data was signed; 447 - The recipient verifies that the data are not claimed to have any 448 values for which the PKC indicates that the signer is not 449 authorized; 451 - The recipient verifies that the data have not been altered since 452 signing, by using the public key in the PKC. 454 - If all of these checks pass, the recipient can accept that the 455 data was signed by the purported signer. The process for keys 456 used for encryption is similar. 458 Note: It is of course possible that the data was signed by someone 459 very different from the signer, if for example the purported signer's 460 private key was compromised. Security depends on all parts of the 461 certificate-using system, including but not limited to: physical 462 security of the place the computer resides; personnel security (i.e., 463 the trustworthiness of the people who actually develop, install, run, 464 and maintain the system); the security provided by the operating 465 system on which the private key is used; and the security provided 466 the CA. A failure in any one of these areas can cause the entire 467 system security to fail. PKIX is limited in scope, however, and only 468 directly addresses issues related to the operation of the PKI 469 subsystem. For guidance in many of the other areas, see [POLPROC]. 471 Arsenault, Turner 9 472 2.2 Architecture Model 474 A PKI is defined as: 476 The set of hardware, software, people, policies and procedures needed 477 to create, manage, store, distribute, and revoke PKCs based on 478 public-key cryptography. 480 A PKI consists of five types of components [MISPC]: 482 - Certification Authorities (CAs) that issue and revoke PKCs; 484 - Organizational Registration Authorities (ORAs) that vouch for the 485 binding between public keys and certificate holder identities 486 and other attributes; 488 - PKC holders that are issued certificates and can sign digital 489 documents and encrypt documents; 491 - Clients that validate digital signatures and their certification 492 paths from a known public key of a trusted CA; 494 - Repositories that store and make available PKCs and Certificate 495 Revocation Lists (CRLs). 497 Figure 1 is a simplified view of the architectural model assumed by 498 the PKIX Working Group. 500 Arsenault, Turner 10 501 +---+ cert. publish +------------+ 502 | | <--------------------- | End Entity | <------- 503 | C | +------------+ "out-of-band" 504 | | | ^ loading 505 | e | | | initial 506 | r | | | registration/ 507 | t | | | certification 508 | | | | key pair recovery 509 | / | | | key pair update 510 | | | | certificate update 511 | C | PKI "USERS" V | revocation request 512 | R | -------------------+-+-----+-+------+-+------------------- 513 | L | PKI MANAGEMENT | ^ | ^ 514 | | ENTITIES | | | | 515 | | V | | | 516 | R | +------+ | | 517 | e | <------------ | RA | <-----+ | | 518 | p | cert. | | ----+ | | | 519 | o | publish +------+ | | | | 520 | s | | | | | 521 | i | V | V | 522 | t | +------------+ 523 | o | <------------------------| CA |-------> 524 | r | +------------+ "out-of-band" 525 | y | cert. publish | ^ publication 526 | | CRL publish | | 527 +---+ | | cross-certification 528 | | cross-certificate 529 | | update 530 | | 531 V | 532 +------+ 533 | CA-2 | 534 +------+ 536 Figure 1 - PKI Entities 538 2.3 Public Key Certificates 540 ITU-T X.509 (formerly CCITT X.509) or ISO|IEC/ITU 9594-8, which was 541 first published in 1988 as part of the X.500 Directory 542 recommendations, defines a standard PKC format [X.509]. The PKC 543 format in the 1988 standard is called the version 1 (v1) format. 545 When X.500 was revised in 1993, two more fields, 546 subjectUniqueIdentifier and issuerUniqueIdentifier were added, 547 resulting in the version 2 (v2) format. These two fields may be used 548 to support directory access control. 550 The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993, 551 include specifications for a public key infrastructure based on X.509 552 v1 public key certificates [PEM]. The experience gained in attempts 554 Arsenault, Turner 11 555 to deploy [PEM] made it clear that the v1 and v2 public key 556 certificate formats are deficient in several respects. Most 557 importantly, more fields were needed to carry information which PEM 558 design and implementation experience has proven necessary. In 559 response to these new requirements, ISO|IEC, ITU, and ANSI X9 560 developed the X.509 version 3 (v3) PKC format. The v3 format extends 561 the v2 format by adding provision for additional extension fields. 562 Particular extension field types may be specified in standards or may 563 be defined and registered by any organization or community. In June 564 1996, standardization of the basic v3 format was completed [X.509]. 566 ISO|IEC, ITU, and ANSI X9 have also developed standard extensions for 567 use in the v3 extensions field [X.509][X9.55]. These extensions can 568 convey such data as additional subject identification information, 569 key attribute information, policy information, and certification path 570 constraints. However, the ISO/IEC/ITU and ANSI X9 standard extensions 571 are very broad in their applicability. In order to develop 572 interoperable implementations of X.509 v3 systems for Internet use, 573 it is necessary to specify a profile for use of the X.509 v3 574 extensions tailored for the Internet. It is one goal of PKIX to 575 specify a profile for Internet, electronic mail, and IPSec 576 applications, etc. Environments with additional requirements may 577 build on this profile or may replace it. 579 2.4 Functions of a PKI 581 This section describes the major functions of a PKI. In some cases, 582 PKIs may provide extra functions. 584 2.4.1 Registration 586 This is the process whereby a subject first makes itself known to a 587 CA (directly, or through an RA), prior to that CA issuing a PKC or 588 PKCs for that subject. Registration involves the subject providing 589 its name (e.g., common name, fully-qualified domain name, IP 590 address), and other attributes to be put in the PKC, followed by the 591 CA (possibly with help from the RA) verifying in accordance with its 592 Certification Practice Statement (CPS) that the name and other 593 attributes are correct. 595 2.4.2 Initialization 597 Initialization is when the subject (e.g., the user or client system) 598 gets the values needed to begin communicating with the PKI. For 599 example, initialization can involve providing the client system with 600 the public key or PKC of a CA, or generating the client system's own 601 public-private key pair. 603 Arsenault, Turner 12 604 2.4.3 Certification 606 This is the process in which a CA issues a PKC for a subject's public 607 key, and returns that PKC to the subject or posts that PKC in a 608 repository. 610 2.4.4 Key Pair Recovery 612 In some implementations, key exchange or encryption keys will be 613 required by local policy to be "backed up," or recoverable in case 614 the key is lost and access to previously-encrypted information is 615 needed. Such implementations can include those where the private key 616 exchange key is stored on a hardware token that can be lost or 617 broken, or when a private key file is protected by a password which 618 can be forgotten. Often, a company is concerned about being able to 619 read mail encrypted by or for a particular employee when that 620 employee is no longer available because she is ill or no longer works 621 for the company. 623 In these cases, the user's private key can be backed up by a CA or by 624 a separate key backup system. If a user or her employer needs to 625 recover these backed up key materials, the PKI must provide a system 626 that permits the recovery without providing an unacceptable risk of 627 compromise of the private key. 629 2.4.5 Key Generation 631 Depending on the CA's policy, the private-public key pair can either 632 be generated by the user in his local environment, or generated by 633 the CA. In the latter case, the key material may be distributed to 634 the user in an encrypted file or on a physical token (e.g., a smart 635 card or PC card). 637 2.4.6 Key Update 639 All key pairs need to be updated regularly (i.e., replaced with a new 640 key pair) and new PKCs issued. This will happen in two cases: 641 normally, when a key has passed its maximum usable lifetime; and 642 exceptionally, when a key has been compromised and must be replaced. 644 2.4.6.1 Key Expiry 646 In the normal case, a PKI needs to provide a facility to gracefully 647 transition from a PKC with an existing key to a new PKC with a new 648 key. This is particularly true when the key to be updated is that of 649 a CA. Users will know in advance that the key will expire on a 650 certain date; the PKI, working together with PKC-using applications, 651 should allow for appropriate keys to work before and after the 653 Arsenault, Turner 13 654 transition. There are a number of ways to do this; see [CMP] for an 655 example of one. 657 2.4.6.2 Key Compromise 659 In the case of a key compromise, the transition will not be 660 "graceful" in that there will be an unplanned switch of PKCs and 661 keys; users will not have known in advance what was about to happen. 662 Still, the PKI must support the ability to declare that the previous 663 PKC is now invalid and shall not be used, and to announce the 664 validity and availability of the new PKC. 666 Note: compromise of a private key associated with a Root CA is 667 catastrophic for users relying on that Root CA. If a Root CA's 668 private key is compromised, that CA's PKC must be revoked and all 669 PKCs subordinate to it must also be revoked. Until such time as the 670 Root CA has been issued a new PKC and the Root CA issues PKCs to 671 users relying upon it, users relying on that Root CA are cut off from 672 the rest of the system, as there is no way to develop a valid 673 certification path back to a trusted node. 675 Further, users will likely have to be notified by out-of-band 676 mechanisms about the change in CA keys. If the old key is 677 compromised, any "update" message telling subordinates to switch to a 678 new key could have come from an attacker in possession of the old 679 key, and could point to a new public key for which the attacker 680 already has the private key. It is possible to have anticipated this 681 event, and "pre-placed" replacement Root CA keys with all relying 682 parties, but some secure, out-of-band mechanism will have to be used 683 to tell users to make the switch, and this will only help if the 684 replacement key has not been compromised. 686 Additionally, once the Root CA is brought back up with a new key, it 687 will likely be necessary to re-issue PKCs, signed with the new key, 688 to all subordinate users, since their current PKC would be signed 689 with a now-revoked key. 691 2.4.7 Cross-certification 693 A cross-certificate is a PKC issued by one CA to another CA which 694 contains a public CA key associated with the private CA signature key 695 used for issuing PKCs. Typically, a cross-certificate is used to 696 allow client systems or end entities in one administrative domain to 697 communicate securely with client systems or end users in another 698 administrative domain. Use of a cross-certificate issued from CA_1 to 699 CA_2 allows user Alice, who trusts CA_1, to accept a PKC used by Bob, 700 which was issued by CA_2. Cross-certificates can also be issued from 701 one CA to another CA in the same administrative domain, if required. 703 Cross-certificates can be issued in only one direction, or in both 704 directions, between two CA's. That is, just because CA_1 issues a 706 Arsenault, Turner 14 707 cross-certificate for CA_2, CA_2 does not have to issue a cross- 708 certificate for CA_1. 710 2.4.8 Revocation 712 When a PKC is issued, it is expected to be in use for its entire 713 validity period. However, various circumstances may cause a PKC to 714 become invalid prior to the expiration of the validity period. Such 715 circumstances include change of name, change of association between 716 subject and CA (e.g., an employee terminates employment with an 717 organization), and compromise or suspected compromise of the 718 corresponding private key. Under such circumstances, the CA needs to 719 revoke the PKC. 721 X.509 defines one method of PKC revocation. This method involves each 722 CA periodically issuing a signed data structure called a certificate 723 revocation list (CRL). A CRL is a time stamped list identifying 724 revoked PKCs that is signed by a CA and made freely available in a 725 public repository. Each revoked PKC is identified in a CRL by its PKC 726 serial number. When a certificate-using system uses a PKC, that 727 system not only checks the PKC signature and validity but also 728 acquires a suitably recent CRL and checks that the PKC serial number 729 is not on that CRL. The meaning of "suitably recent" may vary with 730 local policy, but it usually means the most recently issued CRL. A CA 731 issues a new CRL on a regular periodic basis (e.g., hourly, daily, or 732 weekly). CA's may also issue CRLs aperiodically. For example, if an 733 important key is deemed compromised, the CA may issue a new CRL to 734 expedite notification of that fact, even if the next CRL does not 735 have to be issued for some time. (A problem of aperiodic CRL issuance 736 is that end-entities may not know that a new CRL has been issued, and 737 thus may not retrieve it from a repository.) 739 An entry is added to the CRL as part of the next update following 740 notification of revocation. An entry may be removed from the CRL 741 after appearing on one regularly scheduled CRL issued beyond the 742 revoked PKC's validity period. Leaving the revoked PKC on the CRL for 743 this extra period allows for PKCs that are revoked prior to issuing a 744 new CRL and whose invalidity date falls before the CRL issuing time 745 to be accounted for. If the revoked PKC is not retained on the CRL 746 for this extra period then the possibility arises that a revoked PKC 747 may never appear on a CRL. 749 An advantage of the CRL revocation method is that CRLs may be 750 distributed by exactly the same means as PKCs themselves, namely, via 751 untrusted communications and server systems. 753 One limitation of the CRL revocation method, using untrusted 754 communications and servers, is that the time granularity of 755 revocation is limited to the CRL issue period. For example, if a 756 revocation is reported now, that revocation will not be reliably 757 notified to certificate-using systems until the next CRL is issued, 759 Arsenault, Turner 15 760 which may be up to one hour, one day, or one week depending on the 761 frequency that the CA issues CRLs. 763 As with the X.509 v3 PKC format, in order to facilitate interoperable 764 implementations from multiple vendors, the X.509 v2 CRL format needed 765 to be profiled for Internet use. This was done as part of the 766 Internet PKI Profile [2459bis]. However, PKIX does not require CAs to 767 issue CRLs. On-line methods of revocation notification may be 768 applicable in some environments as an alternative to the X.509 CRL. 769 PKIX defines a few protocols that support on-line checking. [OCSP], 770 [DVCS], and [SCVP] all support on-line checking of the status of 771 PKCs. 773 On-line revocation checking may significantly reduce the latency 774 between a revocation report and the distribution of the information 775 to relying parties. Once the CA accepts the report as authentic and 776 valid, any query to the on-line service will correctly reflect the 777 PKC validation impacts of the revocation. However, these methods 778 impose new security requirements; the PKC validator must trust the 779 on-line validation service while the repository does not need to be 780 trusted. 782 2.4.9 Certificate & Revocation Notice Distribution & Publication 784 As alluded to in sections 2.1 and 2.5.8 above, the PKI is responsible 785 for the distribution of PKCs and PKC revocation notices (whether in 786 CRL form or in some other form) in the system. "Distribution" of PKCs 787 includes transmission of the PKC to its owner, and may also include 788 publication of the PKC in a repository. "Distribution" of revocation 789 notices may involve posting CRLs in a repository, transmitting them 790 to end-entities, or forwarding them to on-line responders. 792 3 PMI 794 3.1 Theory 796 Many systems use the PKC to perform identity based access control 797 decisions (i.e., the identity may be used to support identity-based 798 access control decisions after the client proves that it has access 799 to the private key that corresponds to the public key contained in 800 the PKC). For many systems this is sufficient, but increasingly 801 systems are beginning to find that rule-based and role-based access 802 control is required. These forms of access control decisions require 803 additional information that is normally not included in a PKC, 804 because the lifetime of the information is much shorter than the 805 lifetime of the public-private key pair. To support binding this 806 information to a PKC the Attribute Certificate (AC) was defined in 807 ANSI and later incorporated into ITU-T Recommendation X.509. The AC 808 format allows any additional information to be bound to a PKC by 809 including, in a digitally signed data structure, a reference back to 810 one specific PKC or to multiple PKCs, useful when the subject has the 812 Arsenault, Turner 16 813 same identity in multiple PKCs. Additionally, the AC can be 814 constructed in such a way that it is only useful at one or more 815 particular targets (e.g., web server, mail host). 817 Users of a PMI must be confident that the identity purporting to 818 posses an attribute has the right to possess that attribute. This 819 confidence may be obtained through the use of PKCs or it may be 820 configured in the AC-using system. If PKCs are used the party making 821 the access control decision can determine "if the AC issuer is 822 trusted to issue ACs containing this attribute." 824 ACs are complicated by the fact that they can point to an identity 825 which may be in more than one PKC. If the RP has multiple 826 certification chains to chose from then it has to make the 827 determination as to which certification path to trust. Regardless, 828 before the RP uses the AC it must make sure that a path from the AC 829 back to its trust point is valid. 831 3.2 Architectural Model 833 A Privilege Management Infrastructure, or PMI, is defined as: 835 The set of hardware, software, people, policies and procedures needed 836 to create, manage, store, distribute, and revoke ACs. 838 A PMI consists of five types of components [AC]: 840 - Attribute Authorities (AAs), or Attribute Certificate Issuer, 841 that issue and revoke ACs; 843 Note: AAs may implicitly revoke ACs by using very short validity 844 periods. 846 - Attribute Certificate Users that parses or processes an AC; 848 - Attribute Certificate Verifiers that check the validity of an AC 849 and then makes use of the result; 851 - Clients that request an action for which authorization checks are 852 to be made; 854 - Repositories that store and make available certificates and 855 Certificate Revocation Lists (CRLs). 857 Figure 2 is an example of the exchanges that may involve ACs. 859 Arsenault, Turner 17 860 +--------------+ 861 | | Server Acquisition 862 | AC issuer +----------------------------+ 863 | | | 864 +--+-----------+ | 865 | | 866 | Client | 867 | Acquisition | 868 | | 869 +--+-----------+ +--+------------+ 870 | | AC "push" | | 871 | Client +-------------------------+ Server | 872 | | (part of app. protocol) | | 873 +--+-----------+ +--+------------+ 874 | | 875 | Client | Server 876 | Lookup +--------------+ | Lookup 877 | | | | 878 +---------------+ Repository +---------+ 879 | | 880 +--------------+ 882 Figure 2: AC Exchanges 884 3.3 Attribute Certificates 886 ANSI X.9 first published the Attribute Certificate format. It defined 887 the standard version 1 (v1) AC format. They later created a version 2 888 (v2) AC by modifying the owner field to point to either an identity 889 or a specific PKC and including an extension mechanism. In 1997 ITU-T 890 included it in [X.509]. 892 ANSI, ITU-T, and IETF have developed standard extensions and 893 attributes for use in the v2 ACs. Extensions can convey such 894 information as an audit identity that can be used to create an audit 895 trail, identity specific servers and services where the AC owner can 896 use their AC, point to a specific issuer's key, and indicate where to 897 get revocation information. The AC is generic enough to allow any 898 attribute to be conveyed in the data structure. Without limiting the 899 attributes and extensions that can be included in an AC it is very 900 difficult to develop interoperable implementations for Internet use. 901 It is the goal of PKIX to specify a profile for the Internet, 902 electronic mail, IPSec applications, etc. Environments with 903 additional requirements may build on this profile or replace it. 905 The [AC] profile constrains many of the options allowed in X.509. For 906 example, the AC chains, like their PKC brethren, are allowed by 907 X.509, but the AC profile recommends that they not be supported in to 908 simplify the implementation. 910 Arsenault, Turner 18 911 4 PKIX Documents 913 This section identifies the five different areas in which the PKIX 914 working group has developed documents. The first area involves 915 profiles of the X.509 v3 PKC standards and the X.509 v2 CRL standards 916 for the Internet. The second area involves operational protocols, in 917 which relying parties can obtain information such as PKCs or PKC 918 status. The third area covers management protocols, in which 919 different entities in the system exchange information needed for 920 proper management of the PKI. The fourth area provides information 921 about certificate policies and certificate practice statements, 922 covering the areas of PKI security not directly addressed in the rest 923 of PKIX. The fifth area deals with providing time stamping and data 924 certification services, which can be used to build such services as 925 non-repudiation. 927 4.1 Profiles 929 An X.509 v3 PKC is a very complex data structure. It consists of 930 basic information fields, plus a number of optional extensions. Many 931 of the fields and numerous extensions can take on a wide range of 932 options. This provides an enormous degree of flexibility, which 933 allows the X.509 v3 PKC format to be used with a wide range of 934 applications in a wide range of environments. Unfortunately, this 935 same flexibility makes it extremely difficult to produce independent 936 implementations that will actually interoperate with one another. In 937 order to build an Internet PKI based on X.509 v3 PKCs, the PKIX 938 working group had to develop a profile of the X.509 v3 PKC 939 specification. 941 A profile of the X.509 v3 PKC specification is a description of the 942 contents of the PKC and which extensions must be supported, which 943 extensions may be supported, and which extensions may not be 944 supported. The Internet PKI Profile [2459bis] provides such a profile 945 of X.509 v3 PKC for the Internet PKI. In addition, the Internet PKI 946 Profile [2459bis] suggests ranges of values for many of the 947 extensions. 949 The Internet PKI Profile [2459bis] also provides a profile for 950 Version 2 CRLs for use in the Internet PKI. CRLs, like PKCs, have a 951 number of optional extensions. In order to promote interoperability, 952 it is necessary to constrain the choices an implementor supports. 954 In addition to profiling the PKC and CRL formats, it is necessary to 955 define particular Object Identifiers (OIDs) for certain encryption 956 algorithms, because there are a variety of OIDs registered for some 957 algorithm suites. PKIX has produced two documents ([RPKDS] and [KEA]) 958 which provide guidance on the proper implementation of specific 959 algorithms. 961 Some countries are in a process of updating their legal frameworks in 962 order to regulate and incorporate recognition of signatures in 964 Arsenault, Turner 19 965 electronic form. Many of these frameworks introduce certain basic 966 requirements on PKCs, often termed Qualified Certificates, supporting 967 these types of "legal" signatures. Partly as a result of this there 968 is a need for a specific PKC profile providing standardized support 969 for certain related issues such as a common structure for expressing 970 unambiguous identities of certified subjects (unmistakable identity). 971 In December 1998, PKIX adopted as a work item the development of a 972 refinement of [RFC2459] that further profiles PKIX PKC into qualified 973 certificates. This work is reflected in [QC]. 975 Like the X.509 v3 PKC, the AC also a very complex data structure 976 consisting of basic information fields, a number of optional 977 extensions, and a virtually unlimited number of attributes. Again, 978 many of the fields, extensions, and attributes can take on a wide 979 range of options allowing an enormous degree of flexibility. In order 980 to build an Internet PMI based on ACs, the PKIX working group had to 981 develop a profile of the AC. 983 The AC profile is description of the contents of the AC, the allowed 984 and required extensions, and applicable attributes. [AC] provides 985 such a profile of the X.509 v2 AC. 987 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure 988 Certificate and CRL Profile [2459bis] 990 DESCRIPTION: This document describes the profiles to be used for 991 X.509 v3 PKCs and version 2 CRLs by Internet PKI participants. The 992 profiles include the identification of ISO/IEC/ITU and ANSI 993 extensions which may be useful in the Internet PKI. The profiles 994 are presented in the 1988 Abstract Syntax Notation One (ASN.1) 995 rather than the 1994 syntax used in the ISO/IEC/ITU standards. 996 Would-be PKIX implementors and developers of certificate-using 997 applications should start with the Internet PKI Profile [2459bis] 998 to ensure that their systems will be able to interoperate with 999 other users of the PKI. 1001 The Internet PKI Profile [2459bis] also includes path validation 1002 procedures. The procedures presented are based upon the ISO/IEC/ITU 1003 definition, but the presentation assumes one or more self-signed 1004 trusted CA PKCs. The procedures are provided as examples only. 1005 Implementations are not required to use the procedures provided; 1006 they may implement whichever procedures are efficient for their 1007 situation. However, implementations are required to derive the same 1008 results as the example procedures. 1010 STATUS: Proposed Standard. 1012 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure 1013 Representation of Key Exchange Algorithm (KEA) Keys in Internet 1014 X.509 Public Key Infrastructure Certificates (RFC 2528) [KEA] 1016 DESCRIPTION: This document provides Object Identifiers (OIDs) and 1017 other guidance for IPKI users who use the Key Exchange Algorithm 1019 Arsenault, Turner 20 1020 (KEA). It profiles the format and semantics of the 1021 subjectPublicKeyInfo field and the keyUsage extension in X.509 v3 1022 PKCs containing KEA keys. This document should be used by anyone 1023 wishing to support KEA; others who do not support ECDSA are not 1024 required to comply with it. 1026 STATUS: Informational RFC. 1028 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Qualified 1029 Certificates (RFC 3039) [QC] 1031 DESCRIPTION: This document profiles the format for and defines 1032 requirements on information content in a specific type of PKCs 1033 called Qualified Certificates. A "Qualified Certificate" is a PKC 1034 that is issued to a natural person (i.e., a living human being); 1035 contains an unmistakable identity based on a real name or a 1036 pseudonym of the subject; exclusively indicates non-repudiation as 1037 the key usage for the certificate's public key; and meets a number 1038 of requirements. 1040 STATUS: Proposed Standard. 1042 - DOCUMENT TITLE: An Internet Attribute Certificate Profile for 1043 Authorizations [AC] 1045 DESCRIPTION: This document profiles the format for an defines 1046 requirements on X.509 v2 ACs to support authorization services 1047 required by various Internet protocols (TLS, CMS, and the consumers 1048 of CMS, etc.). Two profiles are defined in support of basic 1049 authorizations and in support of services that can operate via 1050 proxy. 1052 STATUS: Approved as Proposed Standard; in RFC editorÆs Queue. 1053 Issuance as an RFC blocked until the normative reference [2459bis] 1054 progresses to Proposed Standard as well. (See below.) 1056 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure 1057 Certificate and CRL Profile 1058 [2459bis] 1060 DESCRIPTION: This document is an update of the Internet PKI Profile 1061 [2459bis]. The treatment of path validation is enhanced, and 1062 additional specificity is offered for various certificate and CRL 1063 extensions. This document omits the encoding and identification of 1064 public keys and digital signatures. (See [RPKDS] below.) 1066 STATUS: Tentatively approved by IESG. 1068 Arsenault, Turner 21 1069 - DOCUMENT TITLE: Representation of Public Keys and Digital 1070 Signatures in Internet X.509 Public Key Infrastructure 1071 Certificates [RPKDS] 1073 DESCRIPTION: This document specifies algorithm identifiers and 1074 encoding formats for the representation of cryptographic algorithms 1075 keys, associated parameters, and digital signatures in Internet PKI 1076 and X.509 certificates and certificate revocation lists. This draft 1077 does not attempt to define the cryptographic algorithms themselves. 1078 It instead references other appropriate standards. This draft 1079 incorporates information from Section 7 of RFC 2459 and the 1080 Internet-Draft ôRepresentation of Elliptic Curve Digital Signature 1081 Algorithm (ECDSA) Keys in Internet X.509 Public Infrastructure 1082 Certificates.ö 1084 STATUS: Tentatively approved by IESG. 1086 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Permanent 1087 Identifier [PI] 1089 DESCRIPTION: This document defines a new form of name, the 1090 permanent identifier, which is a name assigned by an organization, 1091 unique within that organization, that singles out a particular 1092 individual fro all other individuals. The permanent identifier is 1093 an optional feature that may be used by a CA to indicate that the 1094 certificate relates to the same individual even if the name or the 1095 affiliation of that individual has changed. The permanent 1096 identifier is important in the context of access control and of 1097 non-repudiation. 1099 STATUS: Under AD review. 1101 - DOCUMENT TITLE: Supplemental Algorithms and Identifiers for the 1102 Internet X.509 Public Key Infrastructure Certificate and CRL 1103 Profile [SUPPALGS] 1105 DESCRIPTION: This document supplements [RPKDS], defining specifies 1106 algorithm identifiers and encoding formats for the representation 1107 of emerging cryptographic algorithms and associated keys. The 1108 document encompasses 1109 lattice-based public key algorithms as well as digital signatures 1110 using larger hash algorithms (e.g., SHA-256). 1112 STATUS: Under WG review. 1114 4.2 Operational Protocols 1116 Operational protocols are required to deliver certificates and CRLs 1117 (or other certificate status information) to certificate using 1118 systems. Provision is needed for a variety of different means of 1119 certificate and CRL delivery, including distribution procedures based 1121 Arsenault, Turner 22 1122 on DNS, LDAP, HTTP, FTP, and X.500. A limited protocol to support AC 1123 retrieval has also been documented. 1125 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure 1126 Operational Protocols - LDAPv2 (RFC 2559) 1128 DESCRIPTION: This document describes the use of LDAPv2 as a 1129 protocol for PKI elements to publish and retrieve certificates and 1130 CRLs from a repository. [LDAPv2] is a protocol that allows 1131 publishing and retrieving of information. 1133 STATUS: Proposed Standard. 1135 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure LDAPv2 1136 Schema (RFC 2587) 1138 DESCRIPTION: This document defines a minimal schema necessary to 1139 support the use of LDAPv2 for PKC and CRL retrieval and related 1140 functions for PKIX. This document supplements [LDAPv2] by 1141 identifying the PKIX-related attributes that must be present. 1143 STATUS: Proposed Standard. 1145 - DOCUMENT TITLE: X.509 Internet Public Key Infrastructure Online 1146 Certificate Status Protocol - OCSP (RFC 2560) 1148 DESCRIPTION: This document specifies a protocol useful in 1149 determining the current status of a certificate without the use of 1150 CRLs. A major complaint about certificate-based systems is the need 1151 for a relying party to retrieve a current CRL as part of the 1152 certificate validation process. Depending on the size of the CRL, 1153 this can cause severe problems for bandwidth-challenged devices. 1154 Depending on the frequency of CRL issuance, this can also cause 1155 timeliness problems. (E.g., if CRLs are only published weekly, with 1156 no interim releases, a certificate could actually have been revoked 1157 for just short of one week without it being on the current CRL, and 1158 thus improper use of that certificate could still be occurring.) 1160 OCSP attempts to address those problems. It provides a mechanism 1161 whereby a relying party identifies one or more certificates to an 1162 approved OCSP "responder", and the responder sends back the current 1163 status of the certificate(s) - e.g., "revoked", "notRevoked", 1164 "unknown". This can dramatically reduce the bandwidth required to 1165 transmit revocation status - a relying party does not have to 1166 retrieve a CRL of many entries to check the status of one 1167 certificate. It can (although it is not guaranteed to) improve the 1168 timeliness of revocation notification, and thus reduce the window 1169 of opportunity for someone trying to use a revoked certificate. 1171 STATUS: Proposed Standard. 1173 Arsenault, Turner 23 1174 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure 1175 Operational Protocols: FTP and HTTP (RFC 2585) 1177 DESCRIPTION: This document describes the use of the File Transfer 1178 Protocol (FTP) and the Hyper-text Transfer Protocol (HTTP) to 1179 obtain certificates and CRLs from PKI repositories. 1181 STATUS: Proposed Standard. 1183 - DOCUMENT TITLE: Diffie-Hellman Proof-of-Possession Algorithms (RFC 1184 2875). 1186 DESCRIPTION: It allows Diffie-Hellman, a key agreement algorithm, 1187 to be used instead of requiring that the public key being requested 1188 for certification correspond to an algorithm that is capable of 1189 signing and encrypting. The first algorithm generates a signature 1190 for a specific verifier where the signer and recipient have the 1191 same public key parameters. The second algorithm generates a 1192 signature for arbitrary verifiers where the signer and recipient do 1193 not have the same public key parameters. 1195 STATUS: Proposed Standard. 1197 - DOCUMENT TITLE: Limited Attribute Certificate Acquisition Protocol 1198 1200 DESCRIPTION: This document specifies a deliberately limited 1201 protocol for requesting ACs from a server. It is intended to be 1202 complementary to the use of LDAP for AC retrieval, covering those 1203 cases where use of an LDAP server is not suitable due to the type 1204 of authorization model being employed. 1206 STATUS: Under WG review. 1208 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Additional 1209 Schema for PKIs and PMIs 1211 DESCRIPTION: This document describes the Lightweight Directory 1212 Access Protocol (LDAP) schema features that, in addition to RFC 1213 2587, are needed to support a Privilege Management Infrastructure 1214 and a Public Key Infrastructure. It also describes the schema for 1215 the storage and matching of attribute certificates and revocation 1216 lists in an LDAP directory server. This Internet Draft supplements, 1217 rather than revokes, the contents of RFC 2587. 1219 STATUS: Under WG review. 1221 - DOCUMENT TITLE: Delegated Path Validation and Delegated Path 1222 Discovery Protocol Requirements (DPV&DPD-REQ) [DPREQ] 1225 DESCRIPTION: This document specifies requirements for two 1226 request/response pairs. The first, called Delegated Path Validation 1228 Arsenault, Turner 24 1229 (DPV), can be used to fully delegate a path validation processing 1230 to an DPV server. The second, called Delegated Path Discovery 1231 (DPD), can be used to delegate development of a path, including 1232 certificate status information, to a DPD server. 1234 STATUS: Under WG review. 1236 - DOCUMENT TITLE: Simple Certificate Validation Protocol (SCVP) 1237 1239 DESCRIPTION: The SCVP protocol allows a client to offload 1240 certificate handling to a server. The server can give a variety of 1241 valuable information about the certificate, such as whether or not 1242 the certificate is valid, a chain to a trusted root, and so on. 1244 STATUS: Under WG review. 1246 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure 1247 Operational Protocols - LDAPv3 1249 DESCRIPTION: This document describes the features of the 1250 Lightweight Directory Access Protocol (LDAP) v3 that are needed in 1251 order to support a public key infrastructure based on x.509 1252 certificates and certificate revocation lists. Because LDAPv2 has a 1253 number of deficiencies that may limit its usefulness in certain 1254 circumstances, the IETF has ceased its standardization and replaced 1255 it with LDAPv3. This document describes the features of LDAPv3 that 1256 are necessary, not required, or are optional for servers to support 1257 a PKI based on X.509. 1259 STATUS: Under WG Review. 1261 4.3 Management Protocols 1263 Management protocols are required to support on-line interactions 1264 between PKI user and management entities. For example, a management 1265 protocol might be used between a CA and a client system with which a 1266 key pair is associated, or between two CAs which cross-certify each 1267 other. A management protocol can be used to carry user or client 1268 system registration information, or a request for revocation of a 1269 certificate. 1271 There are two parts to a "management protocol." The first is the 1272 format of the messages that will be sent, and the second is the 1273 actual protocol that governs the transmission of those messages. 1274 Originally, the PKIX working group developed two documents, [CRMF] 1275 and certificate management message format (CMMF), that together 1276 described the necessary set of message formats, and two other 1277 documents, [CMP] and [CMC], that described protocols for exchanging 1278 those messages. However, the message formats defined in the CMMF 1279 draft were inserted into both [CMP] and [CMC], and thus the (CMMF) 1280 draft has been dropped as a PKIX document. 1282 Arsenault, Turner 25 1283 - DOCUMENT TITLE: Certificate Management Messages over CMS (RFC 2797) 1284 [CMC] 1286 DESCRIPTION: This document defines the means by which PKI clients 1287 and servers may exchange PKI messages when using S/MIME's 1288 Cryptographic Message Syntax [CMS] as a transaction envelope. CMC 1289 supports the certificate request message body specified in the 1290 Certificate Request Message Format [CRMF] documents, as well as a 1291 variety of other certificate management messages. The primary 1292 purpose of this specification is to allow the use of an existing 1293 protocol (S/MIME) as a PKI management protocol, without requiring 1294 the development of an entirely new protocol such as CMP. A 1295 secondary purpose is to codify in IETF standards the current 1296 industry practice of using PKCS-10 messages [PKCS10] for 1297 certificate requests. 1299 STATUS: Proposed Standard. 1301 - DOCUMENT TITLE: Internet X.509 Certificate Request Message Format 1302 (RFC 2511) [CRMF] 1304 DESCRIPTION: CRMF specifies a format recommended for use whenever a 1305 relying party is requesting a certificate from a CA or requesting 1306 that an RA help it get a certificate. The request message format 1307 was needed before many of the other message formats had to be 1308 finalized, and so it was put into a separate document. This 1309 document only specifies the format of a message. Specification of a 1310 protocol to transport that message is beyond the scope of CRMF. 1312 STATUS: Proposed Standard. 1314 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure 1315 Certificate Management Protocols (RFC 2510) [CMP] 1317 DESCRIPTION: This document specifies a new protocol specifically 1318 developed for the purpose of transporting messages like those 1319 specified in CRMF among PKI elements. In general, CMP will be used 1320 in conjunction with CRMF, and will then be run over a transfer 1321 service (e.g., S/MIME, HTTP) to provide a complete PKI management 1322 service. 1324 STATUS: Proposed Standard. 1326 - DOCUMENT TITLE: Certificate Request Message Format [2511bis] 1329 DESCRIPTION: This document is an update of [CRMF] and reflects the 1330 results of interoperability testing. 1332 STATUS: Awaiting documentation of Interoperability Testing results. 1334 Arsenault, Turner 26 1335 - DOCUMENT TITLE: Certificate Management Protocols [2510bis] 1338 DESCRIPTION: This document is an update of [CMP] and reflects the 1339 results of interoperability testing. The document omits the 1340 transport protocols found in [CMP] which are addressed in [CMPT]. 1341 (See below). 1343 STATUS: Awaiting documentation of Interoperability Testing results. 1345 - DOCUMENT TITLE: Transport Protocols for CMP [CMPT] 1348 DESCRIPTION: This document describes how to layer Certificate 1349 Management Protocols (CMP) over various transport protocols. In 1350 Section 5 of RFC 2510, the process of sending DER-encoded CMP 1351 messages directly over various protocols is specified. Implementers 1352 found that the protocol was lacking in several regards. This 1353 document is an effort to enhance the protocol now in order to avoid 1354 interoperability conflicts later and to make the transport section 1355 a separate draft. 1357 STATUS: Under WG review. 1359 4.4 Policy Outline 1361 As mentioned before, profiling certificates and specifying 1362 operational and management protocols only addresses a part of the 1363 problem of actually developing and implementing a secure PKI. What is 1364 also needed is the development of a certificate policy (CP) and 1365 certification practice statement (CPS), and then following those 1366 documents. The CP and CPS should address physical and personnel 1367 security, subject identification requirements, revocation policy, and 1368 a number of other topics. [POLPROC] provides a framework for 1369 certification practice statements. 1371 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure 1372 Certificate Policy and Certification Practices Framework (RFC 1373 2527) 1375 DESCRIPTION: As noted before, the specification and implementation 1376 of certificate profiles, operational protocols, and management 1377 protocols is only part of building a PKI. Equally as important - if 1378 not more important - is the development and enforcement of a 1379 certificate security policy, and a Certification Practice Statement 1380 (CPS). The purpose of this document (PKIX-4) is to establish a 1381 clear relationship between certificate policies and CPSs, and to 1382 present a framework to assist the writers of certificate policies 1383 or CPSs with their tasks. In particular, the framework identifies 1384 the elements that may need to be considered in formulating a 1385 certificate policy or a CPS. The purpose is not to define 1386 particular certificate policies or CPSs, per se. 1388 Arsenault, Turner 27 1389 STATUS: Informational RFC. 1391 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure 1392 Certificate Policy and Certification Practices Framework 1395 DESCRIPTION: This specification is an update to RFC 2527. As above, 1396 the purpose of this document is to establish a clear relationship 1397 between certificate policies and CPSs, and to present a framework 1398 to assist the writers of certificate policies or CPSs with their 1399 tasks. The framework specified in this documents is basically a 1400 superset of the framework specified in RFC 2527. 1402 STATUS: Under WG Review. 1404 4.4 Time Stamping and Data Certification 1406 In late 1998, the PKIX working group began two efforts that were not 1407 in the original working group charter, but were deemed to be 1408 appropriate because they described infrastructure services that could 1409 be used to provide desired security services. The first of these is 1410 time stamping, described in [TSP]. Time stamping is a service in 1411 which a trusted third party - a Time Stamp Authority, or TSA - signs 1412 a message, in order to provide evidence that it existed prior to a 1413 given time. Time stamping provides some support for non- repudiation, 1414 in that a user cannot claim that a transaction was later forged after 1415 compromise of a private key, because the existence of the signed time 1416 stamp indicates that the transaction in question could not have been 1417 created after the indicated time. 1419 [TSP] also defines the role of a Temporal Data Authority, or TDA. A 1420 TDA is a Trusted Third Party (TTP) that creates a temporal data 1421 token. This temporal data token associates a message with a 1422 particular event and provides supplementary evidence for the time 1423 included in the time stamp token. For example, a TDA could associate 1424 the message with the most recent closing value of the Dow Jones 1425 Average. The temporal data with which the message is associated 1426 should be unpredictable in order to prevent forward dating of tokens. 1427 The third iteration of the draft removed support for TDAs as no one 1428 in the WG expressed a requirement for the role. 1430 At the Minneapolis IETF meeting, it was disclosed that the materials 1431 covered in [TSP] draft may be covered by patent(s). Use of the 1432 material covered by the patent(s) in question has not be granted by 1433 the patent holder. Thus, anyone interested in implementing the PKIX 1434 [TSP] draft must be aware of this intellectual property issue. 1436 The second new effort is the definition of a Data Validation and 1437 Certification Server, or DVCS, protocol [DVCS]. A DVCS is a Trusted 1438 Third Party that verifies the correctness of specific data submitted 1440 Arsenault, Turner 28 1441 to it. It also allows the delegation of trustworthy servers and 1442 allows for chaining of verifications. 1444 This services offered by DVCS are different from the TSP service in 1445 that a TSA will not attempt to parse or verify a message sent to it 1446 for certification; instead, it will merely append a reliable 1447 indication of the current time, and sign the resulting string-of- 1448 bits. This offers an indication that the given string-of-bits existed 1449 at a specified time; it does not offer any indication of the 1450 correctness or relevance of that string of bits. By contrast, the 1451 DVCS certifies possession of data or the validity of another entity's 1452 signature. As part of this, the DVCS verifies the mathematical 1453 correctness of the actual signature value contained in the request 1454 and also checks the full certification path from the signing entity 1455 to a trusted point (e.g., the DVCS's CA, or the Root CA in a 1456 hierarchy). 1458 The DVCS supports non-repudiation in two ways. First, it provides 1459 evidence that a signature or PKC was valid at the time indicated in 1460 the token. The token can be used even after the corresponding PKC 1461 expires and its revocation information is no longer available on CRLs 1462 (for example). Second, the production of a data certification token 1463 in response to a signed request for certification of another 1464 signature or PKC also provides evidence that due diligence was 1465 performed by the requester in validating the signature or PKC. 1467 The concept of a delegated signature validation server was introduced 1468 in [DSV] as an analog to the delegated path validation server. A DSV 1469 services permits the relying party to prove they validated a 1470 digitally signed object, including the certification path, at a 1471 particular time. 1473 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Time Stamp 1474 Protocols (RFC 3161) 1476 DESCRIPTION: This document defines the specification for a time 1477 stamp service. It defines a Time Stamp Authority, or TSA, a trusted 1478 third party who maintains a reliable time service. When the TSA 1479 receives a time stamp request, it appends the current time to the 1480 request and signs it into a token to certify that the original 1481 request existed prior to the indicated time. This helps provide 1482 non- repudiation by preventing someone (either a legitimate user or 1483 an attacker who has successfully compromised a key) from "back- 1484 dating" a transaction. It also makes it more difficult to challenge 1485 a transaction by asserting that it has been back-dated. Note that 1486 the TSA does not provide any data parsing service; that is, the TSA 1487 does not attempt to validate that which it signs; it merely regards 1488 it as a string of bits whose meaning is unimportant, but existence 1489 is vital. 1491 STATUS: Proposed Standard. 1493 Arsenault, Turner 29 1494 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Data 1495 Certification Server Protocols (RFC 3029) 1497 DESCRIPTION: This document defines a data validation and 1498 certification service, or DVCS, which can be used to certify both 1499 the existence and correctness of a message or signature. In 1500 contrast to the time stamp service described above, the DVCS 1501 certifies possession of data or the validity of another entity's 1502 signature. As part of this, the DVCS verifies the mathematical 1503 correctness of the actual signature value contained in the request 1504 and also checks the full certification path from the signing entity 1505 to a trusted point (e.g., the DVCS's CA, or the Root CA in a 1506 hierarchy). The DVCS supports non-repudiation in two ways. First, 1507 it provides evidence that a signature or public key certificate was 1508 valid at the time indicated in the token. The token can be used 1509 even after the corresponding public key certificate expires and its 1510 revocation information is no longer available on CRLs (for 1511 example). Second, the production of a data certification token in 1512 response to a signed request for certification of another signature 1513 or public key certificate also provides evidence that due diligence 1514 was performed by the requester in validating the signature or 1515 public key certificate. 1517 STATUS: Experimental RFC. 1519 - DOCUMENT TITLE: Delegated Signature Validation Protocol 1520 Requirements (DSV-REQ) 1522 DESCRIPTION: This document specifies requirements to fully delegate 1523 the validation of a digital signature to a DSV (Delegated Signature 1524 Validation) server. The validation is performed using a set of 1525 rules, called a signature policy. 1527 It also defines the requirements for two optional request/response 1528 pairs, either for allowing to indicate to a signature validation 1529 server a signature policy, or giving the reference of a signature 1530 policy to obtain the details of an already defined signature 1531 policy. 1533 STATUS: Under WG review. 1535 4.5 Expired Drafts 1537 There have been numerous drafts that have been produced by the 1538 working group that for some reason or another did not make it to RFC 1539 status. The following is a list of these drafts. 1541 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure 1542 Certificate Management Message Formats 1544 DESCRIPTION: This document contained the formats for a series of 1545 messages important in certificate and PKI management. These 1547 Arsenault, Turner 30 1548 messages let CA's, RA's, and relying parties communicate with each 1549 other. Note that this document only specified message formats; it 1550 did not specify a protocol for transferring messages. That protocol 1551 could have be either CMP or CMC, or perhaps another custom 1552 protocol. 1554 STATUS: Work has been discontinued. All useful information from it 1555 has been moved into [CMP] and [CMC]. 1557 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Enhanced 1558 CRL Distribution Options (OpenCDP) 1560 DESCRIPTION: This document proposed an alternative to the CRL 1561 Distribution Point (CDP) approach documented in the Internet PKI 1562 Profile [2459bis]. OCDP separates the CRL location function from 1563 the process of certificate and CRL validation, and thus claimed 1564 some benefits over the CDP approach. 1566 STATUS: Work has been discontinued, as all useful information has 1567 been incorporated into [X.509]. An updated the Internet PKI Profile 1568 [2459bis] RFC should profile the use of the CDP approach. 1570 - DOCUMENT TITLE: Internet Public Key Infrastructure: Caching the 1571 Online Certificate Status Protocol 1573 DESCRIPTION: To improve the degree to which it can scale, OCSP 1574 allows caching of responses - e.g., at intermediary servers, or 1575 even at the relying party's end system. This document described how 1576 to support OCSP caching at intermediary servers. 1578 STATUS: Work has been discontinued. 1580 - DOCUMENT TITLE: WEB based Certificate Access Protocol-- WebCAP/1.0 1582 DESCRIPTION: This document specified a set of methods, headers, and 1583 content-types ancillary to HTTP/1.1 to publish, retrieve X.509 PKCs 1584 and Certificate Revocation Lists. This protocol also facilitated 1585 determining current status of a digital certificate without the use 1586 of CRLs. This protocol defined new methods, request and response 1587 bodies, error codes to HTTP/1.1 protocol for securely publishing, 1588 retrieving, and validating certificates across a firewall. 1590 STATUS: Expired. 1592 - DOCUMENT TITLE: Basic Event Representation Token 1594 DESCRIPTION: This document defined a finite method of representing 1595 a discrete instant in time as a referable event. The Basic Event 1596 Representation Token (BERT) was a lightweight binary token designed 1597 for use in large numbers over short periods of time. The tokens 1598 contained only a single instance of an event stamp and the trust 1599 process is referenced against an external reference. 1601 Arsenault, Turner 31 1602 STATUS: Expired. 1604 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Extending 1605 trust in non repudiation tokens in time 1607 DESCRIPTION: This document described a method to maintain the trust 1608 in a token issued by a non-repudiation Trusted Third Party (NR TTP) 1609 (DVCS/TSA/TDA) after the key initially used to establish trust in 1610 the token expires. The document described a general format for 1611 storage of DVCS/TS/TDA tokens for this purpose, which establishes a 1612 chain of custody for the data. 1614 STATUS: Expired. 1616 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure 1617 Representation of Elliptic Curve Digital Signature Algorithm 1618 (ECDSA) Keys and Signatures in Internet X.509 Public Key 1619 Infrastructure Certificates 1621 DESCRIPTION: This document provided Object Identifiers (OIDs) and 1622 other guidance for IPKI users who use the Elliptic Curve Digital 1623 Signature Algorithm (ECDSA). It profiled the format and semantics 1624 of the subjectPublicKeyInfo field and the keyUsage extension in 1625 X.509 v3 PKCs containing ECDSA keys. This document should have been 1626 used by anyone wishing to support ECDSA; others who do not support 1627 ECDSA are not required to comply with it. 1629 STATUS: Finished WG Last Call. Merged into Representation of Public 1630 Keys and Digital Signatures in Internet X.509 Public Key 1631 Infrastructure Certificates. 1633 - DOCUMENT TITLE: A String Representation of General Name 1635 DESCRIPTION: This document specified a string format for the ASN.1 1636 construct GeneralName. 1638 STATUS: Expired. 1640 - DOCUMENT TITLE: OCSP Extensions 1642 DESCRIPTION: This document defined Internet-standard extensions to 1643 OCSP that enable a client to delegate processing of certificate 1644 acceptance functions to a trusted server. The client could control 1645 the degree to which delegation takes place. In addition limited 1646 support was provided for delegating authorization decisions. 1648 STATUS: The work has been incorporated into [DPV] and [DPD]. 1650 - DOCUMENT TITLE: Using HTTP as a Transport Protocol for CMP 1652 DESCRIPTION: This document described how to layer [CMP] over 1653 [HTTP]. A simple method for doing so was described in [CMP], but 1654 that method does not accommodate a polling mechanism, which may be 1656 Arsenault, Turner 32 1657 required in some environments. This document specified an 1658 alternative method that used the polling protocol defined in [CMP]. 1659 A new Content-Type for messages was also defined. 1661 STATUS: The work has been merged into [TPCMP]. 1663 - DOCUMENT TITLE: Using TCP as a Transport Protocol for CMP 1665 DESCRIPTION: This document described how to layer Certificate 1666 Management Protocols [CMP] over [TCP]. A method for doing so is 1667 described in [CMP], but that method did not solve problems 1668 encountered by implementors. This document specified an enhanced 1669 method which extends the protocol. 1671 STATUS: The work has been merged into [TPCMP]. 1673 - DOCUMENT TITLE: Delegated Path Validation 1675 DESCRIPTION: This specification builds on the Online Certificate 1676 Status Protocol (OSCP) framework's extensibility by defining an 1677 Internet-standard extension to OCSP that can be used to fully 1678 delegate all path validation processing to an OCSP server. The 1679 Delegated Path Validation (DVP) extension to OCSP described in this 1680 document accomplishes the task of locating the certificate 1681 validation process within a trusted server. This in turn reduces 1682 the technical footprint of certificate-using applications and may 1683 ease the integration of certificate path processing with other 1684 authorized data. 1686 STATUS: Expired. 1688 - DOCUMENT TITLE: Delegated Path Discovery with OCSP 1690 DESCRIPTION: This document establishes an Internet-standard 1691 extension that enables relying-party software to acquire 1692 certification path data from an OCSP server rather than replicate 1693 the same functionality. This Delegated Path Discovery (DPD) 1694 extension delegates the acquisition process to a separate server, 1695 thereby greatly simplifying and reducing the size of public key 1696 based credential validation systems or other relying party 1697 software. The DPD extension also enables such software to select 1698 from among various trust paths in the event of the existence of 1699 multiple paths. 1701 STATUS: Expired. 1703 - DOCUMENT TITLE: Online Certificate Status Protocol, Version 2 1705 DESCRIPTION: This document is an update to RFC 2560. 1707 STATUS: Expired. 1709 Arsenault, Turner 33 1710 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Repository 1711 Locator Service 1713 DESCRIPTION: This document defines a PKI repository locator 1714 service, which enable certificate-using systems to locate PKI 1715 repositories based on a domain name, to identify the protocols that 1716 can be used to access the repository, and obtain addresses for the 1717 servers that host the repository service. The Internet Draft 1718 defines SRV records for a PKI repository locator service to enable 1719 PKI clients to obtain necessary information to connect to a 1720 domain's repository. It also includes the definition of a SRV RR 1721 format for this service. 1723 STATUS: Expired. 1725 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Technical 1726 Requirements for a non-Repudiation Service 1728 DESCRIPTION: This document describes those features of a service 1729 which processes signed documents which must be present in order for 1730 that service to constitute a "technical non-repudiation" service. A 1731 technical non-repudiation service must permit an independent 1732 verifier to determine whether a given signature was applied to a 1733 given data object by the private key associated with a given valid 1734 certificate, at a time later than the signature. The features of a 1735 technical non-repudiation service are expected to be necessary for 1736 a full non-repudiation service, although they may not be 1737 sufficient. 1739 This document is intended to clarify the definition of the "non- 1740 repudiation" service in RFC 2459. It should thus serve as a guide 1741 to when the nonRepudiation bit of the keyUsage extension should be 1742 set and to when a Certificate Authority is required to archive 1743 CRL's. 1745 STATUS: Expired. 1747 5 Implementation Advice 1749 This section provides guidance to those who would implement various 1750 parts of the PKIX suite of documents. The topics discussed in this 1751 section engendered significant discussion in the working group, and 1752 there, was at times, either widespread disagreement or widespread 1753 misunderstanding of them. Thus, this discussion is provided to help 1754 readers of the PKIX document set understand these issues, in the hope 1755 of fostering greater interoperability among eventual PKIX 1756 implementations. 1758 Arsenault, Turner 34 1759 5.1 Names 1761 PKIX has been referred to as a "name-centric" PKI because the PKCs 1762 associate public keys with names of entities. Each PKC contains at 1763 least one name for the owner of a particular public key. The name can 1764 be an X.500 distinguished name, contained in the subjectDN field of 1765 the PKC. There can also be names such as RFC822 e-mail addresses, DNS 1766 domain names, and uniform resource identifiers (URIs) associated with 1767 the key; these attributes are kept in the subjectAltName extension of 1768 the PKC. A PKC must contain at least one of these name forms, it may 1769 contain multiple forms if deemed appropriate by the CA based on the 1770 intended usage of the PKC. 1772 5.1.1 Name Forms 1774 There are two possible places to put a name in an X.509 v3 PKC. One 1775 is the subject field in the base PKC (often called the "Distinguished 1776 Name" or "DN" field), and the other is in the subjectAltName 1777 extension. 1779 5.1.1.1 Distinguished Names 1781 According to the Internet PKI Profile [2459bis], a CA's PKC must have 1782 a non-null value in the subject field, while EE's PKCs are permitted 1783 to have an empty subject field. If a PKC has a non-null subject 1784 field, it MUST contain an X.500 Distinguished Name. 1786 5.1.1.2 SubjectAltName Forms 1788 In addition to the DN, a PKIX PKC may have one or more values in the 1789 subjectAltName extension. 1791 The subjectAltName extension allows additional identities to be bound 1792 to the subject of the PKC (e.g., it allows "umbc.edu" and 1793 "130.85.1.3" to be associated with a particular subject, as well as 1794 "C=US, O=University of Maryland, L=Baltimore, CN=UMBC"). X.509- 1795 defined options for this extension include: Internet electronic mail 1796 addresses; DNS names; IP addresses; and URIs. Other options can 1797 exist, including locally-defined name forms. 1799 A single subjectAltName extension can include multiple name forms, 1800 and multiple instances of each name form. 1802 Whenever such alternate name forms are to be bound into a PKC, the 1803 subjectAltName (or issuerAltName) extension must be used. It is 1804 technically possible to embed an alternate name form in the subject 1805 field. For example, one could make a DN contain an IP address via a 1806 kludge such as "C=US, L=Baltimore, CN=130.85.1.3". However, this 1807 usage is deprecated; the alternative name extension is the preferred 1808 location for finding such information. As another example, some 1810 Arsenault, Turner 35 1811 legacy implementations exist where an RFC822 name is embedded in the 1812 subject distinguished name as an EmailAddress attribute. Per Internet 1813 Profile [2459bis], PKIX-compliant implementations generating new 1814 PKCs with electronic mail addresses MUST use the rfc822Name in the 1815 subjectAltName extension to describe such EEs. Simultaneous inclusion 1816 of the EmailAddress attribute in the subject distinguished name to 1817 support legacy implementation is deprecated but permitted. 1819 In line with this, if the only subject identity included in a PKC is 1820 an alternative name form, then the subject distinguished name must be 1821 empty (technically, an empty sequence), and the subjectAltName 1822 extension must be present. If the subject field contains an empty 1823 sequence, the subjectAltName extension must be marked critical. 1825 If the subjectAltName extension is present, the sequence must contain 1826 at least one entry. Unlike the subject field, conforming CAs shall 1827 not issue PKCs with subjectAltNames containing empty GeneralName 1828 fields. For example, an rfc822Name is represented as an IA5String. 1829 While an empty string is a valid IA5String, such an rfc822Name is not 1830 permitted by PKIX. The behavior of clients that encounter such a PKC 1831 when processing a certification path is not defined by this working 1832 group. Because the subject's alternative name is considered to be 1833 definitively bound to the public key, all parts of the subject's 1834 alternative name must be verified by the CA. 1836 5.1.1.2.1 Internet e-mail addresses 1838 When the subjectAltName extension contains an Internet mail address, 1839 the address is included as an rfc822Name. The format of an rfc822Name 1840 is an "addr-spec" as defined in [RFC-822]. An addr-spec has the form 1841 local-part@domain; it does not have a phrase (such as a common name) 1842 before it, or a comment (text surrounded in parentheses) after it, 1843 and it is not surrounded by "<" and ">". 1845 5.1.1.2.2 DNS Names 1847 When the subjectAltName extension contains a domain name service 1848 label, the domain name is stored in the dNSName attribute(an 1849 IA5String). The string shall be in the "preferred name syntax," as 1850 specified by [DNS]. Note that while upper and lower case letters are 1851 allowed in domain names, no significance is attached to the case. In 1852 addition, while the string " " is a legal domain name, subjectAltName 1853 extensions with a dNSName " " are not permitted. Finally, the use of 1854 the DNS representation for Internet mail addresses (wpolk.nist.gov 1855 instead of wpolk@nist.gov) is not permitted; such identities are to 1856 be encoded as rfc822Name. 1858 Arsenault, Turner 36 1859 5.1.1.2.3 IP addresses 1861 When the subjectAltName extension contains an iPAddress, the address 1862 shall be stored in the octet string in "network byte order," as 1863 specified in [IP]. The least significant bit (LSB) of each octet is 1864 the LSB of the corresponding byte in the network address. For IP 1865 Version 4, as specified in [IP], the octet string must contain 1866 exactly four octets. For IP Version 6, as specified in [IPv6], the 1867 octet string must contain exactly sixteen octets. 1869 5.1.1.2.4 URIs 1871 The Internet PKI Profile [2459bis] notes "When the subjectAltName 1872 extension contains a URI, the name MUST be stored in the 1873 uniformResourceIdentifier (an IA5String). The name MUST be a non- 1874 relative URL, and MUST follow the URL syntax and encoding rules 1875 specified in [RFC 1738]. The name must include both a scheme (e.g., 1876 "http" or "ftp") and a scheme-specific- part. The scheme-specific- 1877 part must include a fully qualified domain name or IP address as the 1878 host. As specified in [RFC 1738], the scheme name is not case- 1879 sensitive (e.g., "http" is equivalent to "HTTP"). The host part is 1880 also not case-sensitive, but other components of the scheme-specific- 1881 part may be case-sensitive. When comparing URIs, conforming 1882 implementations MUST compare the scheme and host without regard to 1883 case, but assume the remainder of the scheme-specific-part is case 1884 sensitive." 1886 5.1.2 Scope of Names 1888 The original X.500 work presumed that every subject in the world 1889 would have a globally unique distinguished name. Thus, every subject 1890 could be easily located, and there would never be a conflict. All 1891 that would be needed is a sufficiently large name space, and rules 1892 for constructing names based on subordination and location. 1894 Obviously, that is not practical in the real world, for a variety of 1895 reasons. There is no single entity in the world trusted by everybody 1896 to reside at the top of the name space, and there is no way to 1897 enforce uniqueness on names for all entities. (These were among the 1898 reasons for the failure of PEM to be widely implemented.) 1900 This does not mean, however, that a name-based PKI cannot work. It is 1901 important to recognize that the scope of names in PKIX is local; they 1902 need to be defined and unique only within their own domain. 1904 Suppose for example that a Top CA is established with DN "O=IETF, 1905 OU=PKIX, CN=PKIX_CA". That CA will then issue PKCs for subjects 1906 subordinate to it. The only requirement, which can be enforced 1907 procedurally, is that no two distinct entities beneath this Top CA 1908 have the same name. We can't prevent somebody else in the world from 1909 creating her own CA, called "O=IETF, OU=PKIX, CN=PKIX_CA", and it is 1911 Arsenault, Turner 37 1912 not necessary to do so. Within the domain of the original Top CA, 1913 there will be no conflict, and the fact that there is another CA of 1914 the same name in some other domain is irrelevant. 1916 This is analogous to the current DNS or IP address situations. On the 1917 Internet, there is only one node called www.ietf.org. The fact that 1918 there might be 10 different intranets, each with a host given the DNS 1919 name www.ietf.org, is irrelevant and causes no interoperability 1920 problems - those are different domains. However, if there were to be 1921 another node on the Internet with domain name www.ietf.org, then 1922 there would be a problem due to name duplication. 1924 The same applies for IP addresses. As long as only one node on the 1925 Internet responds to the IP address 130.85.1.3, there is no problem, 1926 despite the fact that there are 100 different corporate Intranets, 1927 each using that same IP address. However, if two different nodes on 1928 the Internet each responded to the IP address 130.85.1.3, there would 1929 be a problem. 1931 5.1.3 Certificate Path Construction 1933 Certificate path construction has been the topic of many discussions 1934 in the WG. The issue centered on how best to get a certificate when 1935 the connection between the subject's name and the name of their CA, 1936 as well as the CA's repository (or directory), may not be obvious. 1937 Many proposals were put forth, including implementing a global X.500 1938 Directory Service, using DNS SRV records, and using an extension to 1939 point to the directory provider. At the end of the discussion the 1940 group decided to use the authority information access extension 1941 defined in the Internet PKI Profile [2459bis], which allows the CA to 1942 indicate the access method and location of CA information and 1943 services. The extension would be included in subject's certificates 1944 and could be used to associate an Internet style identity for the 1945 location of repository to retrieve the issuer's certificate in cases 1946 where such a location is not related to the issuer's name. 1948 Another discussion related to certificate path construction was where 1949 to store the CA and EE PKCs in the directory (specifically LDAPv2 1950 directories). Two camps emerged with different views on where to 1951 store CA and cross-certificates. In the CA's directory entry, one 1952 camp wanted self-issued PKCs stored in the cACertificate attribute, 1953 PKCs issued to this CA stored in the forward element of the 1954 crossCertificatePair, and PKCs issued from this CA for other CAs in 1955 the reverse element of the crossCertificatePair attribute. The other 1956 camp wanted all CA PKCs stored in the cACertificate attribute, and 1957 PKCs issued to and from another domain stored in the 1958 crossCertificatePair attribute. There was a short discussion that the 1959 second was more efficient than first and that one solution or the 1960 other was more widely deployed. The end result was to indicate that 1961 self-issued PKCs and PKCs issued to the CA by CAs in the same domain 1962 as the CA are stored in the cACertificate attribute. The 1963 crossCertificatePair attribute's forward element will include all but 1965 Arsenault, Turner 38 1966 self-issued PKCs issued to the CA. The reverse element may include a 1967 subset of PKCs issued by the CA to other CAs. With this resolution 1968 both camp's implementations are supported and are free to choose the 1969 location of CA PKCs to best support their implementation. 1971 5.1.4 Name Constraints 1973 A question that has arisen a number of times is "how does one enforce 1974 Name constraints when there is more than one name form in a PKC?" 1975 That is, the Internet PKI Profile [2459bis] states that: 1977 Subject's alternative names may be constrained in the same manner as 1978 subject distinguished names using the name constraints extension as 1979 described in section 4.2.1.11. 1981 What does this mean? Suppose that there is a CA with DN "O=IETF, 1982 OU=PKIX, CN=PKIX_CA", with the subjectAltName extension having 1983 dNSName "PKIX_CA.IETF.ORG". Suppose that that CA has issued a PKC 1984 with an empty DN, with subjectAltName extension having dNSName set to 1985 "PKIX_CA.IETF.ORG", and rfc822Name set to Steve@PKIX_CA.IETF.ORG. The 1986 question is: are name constraints enforced on these two PKCs - is the 1987 name of the EE PKC considered to be properly subordinate to the name 1988 of the CA? 1990 The answer is "yes". The general rules for deciding whether a PKC 1991 meets name constraints are: 1993 - If a PKC complies with name constraints in any one of its name 1994 forms, then the PKC is deemed to comply with name constraints. 1996 - If a PKC contains a name form that its issuer does not, the PKC is 1997 deemed to comply with name constraints for that name form. 1999 In deciding whether a name form meets name constraints, the following 2000 rules apply (in all cases Name B is the name in the name constraints 2001 extension): 2003 5.1.4.1 rfc822Names 2005 Three variations are allowed: 2007 - If the name constraint is specified as "larry@mail.mit.edu", then 2008 Name A is subordinate to Name B (in B's subtree) if Name A 2009 contains all of Name B's name (specifies a particular mailbox). 2010 For example, larry@mail.mit.edu is subordinate, but 2011 larry_sanders@mail.mit.edu is not. 2013 - If the name constraint is specified as "mail.mit.edu", then Name A 2014 is subordinate to Name B (in B's subtree) if Name A contains all 2015 of Name B's name (specified all mailboxes on host mail.mit.edu). 2016 For example, curly@mail.mit.edu and mo@mail.mit.edu are 2018 Arsenault, Turner 39 2019 subordinate, but mo@mail6.mit.edu and curly@smtp.mail.mit.edu are 2020 not. 2022 - If the name constraint is specified as ".mit.edu", then Name A is 2023 subordinate to Name B (in B's subtree) if Name A contains all of 2024 Name B's name, with the addition of zero or more additional host 2025 or domain names to the left of Name B's name. That is, 2026 smtp.mit.edu is subordinate to .mit.edu, as is pop.mit.edu. 2027 However, mit.edu is not subordinate to .mit.edu. When the 2028 constraint begins with a "." it specifies any address within a 2029 domain. In the previous example, "mit.edu" is not in the domain of 2030 ".mit.edu". 2032 Note: If rfc822 names are constrained, but the PKC does not contain a 2033 subjectAltName extension, the EmailAddress attribute will be used to 2034 constrain the name in the subject distinguished name. For example (c 2035 is country, o is organization, ou is organizational unit, and em is 2036 EmailAddress), Name A ("c=US, o=MIT, ou=CS, em=curly@mail.mit.edu") 2037 is subordinate to Name B ("c=US, o=MIT, ou=CS") (in B's subtree) if 2038 Name A contains all of Name B's names. 2040 5.1.4.2 dNSNames 2042 Name A is subordinate to Name B (in B's subtree) if Name A contains 2043 all of Name B's name, with the addition of zero or more additional 2044 domain names to the left of Name B's name. That is, www.mit.edu is 2045 subordinate to mit.edu, as is larry.cs.mit.edu. However, www.mit.edu 2046 is not subordinate to web.mit.edu. 2048 5.1.4.3 x.400 addresses 2050 Name A is subordinate to Name B (in B's subtree) if Name A contains 2051 all of Name B's name. For example (c is country-name, admd is 2052 administrative-domain-name, and o is organization-name, ou is 2053 organizational-unit-name, pn is personal-name, sn=surname, and gn is 2054 given-name in both Name A and B), the mnemonic X.400 address (using 2055 PrintableString choices for c and admd) "c=US, admd=AT&T, o=MIT, 2056 ou=cs, pn='sn=Doe,gn=John'" is subordinate to "c=US, admd=AT&T, 2057 o=MIT, ou=cs" and "c=US, admd=AT&T, o=MIT, pn='sn=DOE,gn=JOHN'" (pn 2058 is a SET that includes, among other things, sn and gn). 2060 5.1.4.5 DNs 2062 Name A is subordinate to Name B (in B's subtree), if Name A contains 2063 all of Name B's name, treating attribute values encoded in different 2064 types as different strings, ignoring case in PrintableString (in all 2065 other types case is not ignored), removing leading and trailing white 2066 space in PrintableString, and converting internal substrings of one 2067 or more consecutive white space characters to a single space. For 2069 Arsenault, Turner 40 2070 example, (c is country, o is organization, ou is organizational unit, 2071 and cn is common name): 2073 - Assuming PrintableString types for all attribute values in Name A 2074 and B, "c=US, o=MIT, ou=CS" is subordinate to "c=us, o=MIT, 2075 ou=cs", as is "c=US, o=MIT, ou=CS, ou=administration". Another 2076 example, "c=US, o=MIT, ou=CS, cn= John Doe" (note the white 2077 spaces) is subordinate to "c=US, o=MIT, ou=CS, cn=John Doe". 2079 - Assuming UTF8String types for all attribute values in Name A and B, 2080 "c=US, o=MIT, ou=CS, ou=administration" is subordinate to "c=US, 2081 o=MIT, ou=CS", but "c=US, o=MIT, ou=cs, ou=Administration". "c=US, 2082 o=MIT, ou=CS, cn= John Smith" (note the white spaces) is not 2083 subordinate to "c=US, o=MIT, ou=CS, cn= John Smith". 2085 - Assuming UTF8String types for all attribute values in Name A and 2086 PrintableString types for all attribute values in Name B, "c=US, 2087 o=MIT, ou=cs" is subordinate to "c=US, o=MIT, ou=CS" if the 2088 verification software supports the full comparison algorithm in 2089 the X.500 series. "c=US, o=MIT, ou=cs" is NOT subordinate to 2090 "c=US, o=MIT, ou=CS" if the verification software supports the 2091 comparison algorithm in the Internet PKI Profile [2459bis]. 2093 5.1.4.6 URIs 2095 The constraints apply only to the host part of the name. Two 2096 variations are allowed: 2098 - If the name constraint is specified as ".mit.edu", then Name A is 2099 subordinate to Name B (in B's subtree) if Name A contains all of 2100 Name B's name, with the addition of zero or more additional host 2101 or domain names to the left of Name B's name. That is, www.mit.edu 2102 is subordinate to .mit.edu, as is curly.cs.mit.edu. However, 2103 mit.edu is not subordinate to .mit.edu. When the constraint begins 2104 with a "." it specifies a host. 2106 - If the name constraint is specified as "abc.mit.edu", then Name A 2107 is subordinate to Name B (in B's subtree) if Name A contains all 2108 of Name B's name. No leftward expansion of the host or domain name 2109 is allowed. 2111 5.1.4.7 iPaddresses 2113 Two variations are allowed depending on the IP version: 2115 - For IPv4 addresses: Name A (128.32.1.1 encoded as 80 20 01 01) is 2116 subordinate to Name B (128.32.1.0/255.255.255.0 encoded as 80 20 2117 00 00 FF FF FF 00) (in B's subtree) if Name A falls within the net 2118 denoted in Name B's CIDR notation. 2120 Arsenault, Turner 41 2121 - For IPv6 addresses: Name A (4224.0.0.0.8.2048.8204.16762 encoded as 2122 10 80 00 00 00 00 00 00 00 08 08 00 20 0C 41 7A) is subordinate to 2123 Name B (4224.0.0.0.8.2048.8204.0/ 2124 65535.65535.65535.65535.65535.65535.65535.0 encoded as 10 80 00 00 2125 00 00 00 00 00 08 08 00 20 0C 00 00 FF FF FF FF FF FF FF FF FF FF 2126 FF FF FF FF 00 00) (in B's subtree) if Name A falls within the net 2127 denoted in Name B's CIDR notation. 2129 5.1.4.8 Others 2131 As the Internet PKI Profile [2459bis] does not define requirements 2132 for the name forms otherName, ediPartyName, or registeredID there are 2133 no corresponding name constraints requirements. 2135 5.1.5 Wildcards in Name Forms 2137 A "wildcard" in a name form is a placeholder for a set of names 2138 (e.g., "*.mit.edu" meaning "any domain name ending in .mit.edu", and 2139 *@aol.com meaning "email address that uses aol.com"). There are many 2140 people who believe that allowing wildcards in name forms in PKIX PKCs 2141 would be a useful thing to do, because it would allow a single PKC to 2142 be used by all members of a group. These members would presumably 2143 have attributes in common; e.g., access rights to some set of 2144 resources, and so issuance of a PKC with a wildcard for the group 2145 would simplify management. 2147 After much discussion, the PKIX working group decided to permit the 2148 use of wildcards in PKCs. That is, it is permissible for a PKIX- 2149 conformant CA to issue a PKC with a wildcard. However, the semantics 2150 of subjectAltName extension that include wildcard characters are not 2151 addressed by PKIX. Applications with specific requirements may use 2152 such names but must define the semantics. 2154 5.1.6 Name Encoding 2156 A very important topic that consumed much of the WG's time was the 2157 implementation of the directory string choices. While the long term 2158 goal of the IETF was clear, use UTF8String, the short term goals were 2159 not so clear. Many implementations only use PrintableString, others 2160 use BMPString, and still others use Latin1String (ISO 8859-1) and tag 2161 it as TeletexString (there are others still). To ensure that there is 2162 consistency with encodings the Internet PKI Profile [2459bis] defines 2163 a set of rules for the string choices. PrintableString was kept as 2164 the first choice because of it's widespread support by vendors. 2165 BMPString was the second choice, also for it's widespread vendor 2166 support. Failing support by PrintableString and BMPString, UTF8String 2167 must be used. In keeping with the IETF mandate, UTF8String can be 2168 used at any time if the CA supports it. Also, processing 2169 implementations that wish to support TeletexString should handle the 2170 entire ISO 8859-1 character set and not just the Latin1String subset. 2172 Arsenault, Turner 42 2173 5.2 POP 2175 Proof of Possession, or POP, or also CA POP, means that the CA is 2176 adequately convinced that the entity requesting a PKC containing a 2177 public key Y has access to the private key X corresponding to that 2178 public key. 2180 There has been some debate whether POP was or not needed. 2182 This question needs to be addressed separately considering the 2183 context of use of the key, in particular whether a key is used for an 2184 authentication or non repudiation service, or in a confidentiality 2185 service. Note that this does not map to the key usage bit directly, 2186 since it is possible to use a confidentiality key to perform an 2187 authentication service, e.g. by asking to decrypt an encrypted 2188 challenge. 2190 5.2.1 POP for Signing Keys 2192 It is important to provide POP for keys used to sign material, in 2193 order to provide non-repudiation of transactions. For example, 2194 suppose Alice legitimately has private key X and its corresponding 2195 public key Y. Alice has a PKC from Charlie, a CA, containing Y. Alice 2196 uses X to sign a transaction T. Without POP, Mal could also get a PKC 2197 from Charlie containing the same public key, Y. Now without POP, 2198 there are two possible threats: Mal could claim to have been the real 2199 signer of T; or Alice can falsely deny signing T, claiming that it 2200 was instead Mal. Since no one can reliably prove that Mal did or did 2201 not ever possess X, neither of these claims can be refuted, and thus 2202 the service provided by and the confidence in the PKI has been 2203 defeated. (Of course, if Mal really did possess X, Alice's private 2204 key, then no POP mechanism in the world will help, but that is a 2205 different problem.) 2207 Protection can be gained by having Alice, as the true signer of the 2208 transaction, include in the signed information her PKC or an 2209 identifier of her PKC (e.g., a hash of her PKC). This makes 2210 impossible for Mal to claim authorship because he does not know the 2211 private key from Alice and thus is unable to include his certificate 2212 under the signature. 2214 The adequate protection may be obtained in the general case, by 2215 mandating the inclusion of a reference of the certificate every time 2216 a signature (or non repudiation) key is being used in a protocol. 2218 However, because all the protocols were not doing so, a conservative 2219 measure has been taken by requesting POP to be performed by CAs. It 2220 should thus be understood, that this measure is not strictly 2221 necessary and is only a temporary measure to make old protocols 2222 secure. New protocols or data formats are being developed. If the key 2224 Arsenault, Turner 43 2225 being used is always used in a context where the identifier of the 2226 certificate is included in the protocol, then POP by the CA is not 2227 necessary. The inclusion of the identifier of the certificate in the 2228 protocol or data format may be understood as POP being performed at 2229 the transaction time rather than by the CA, at the registration time 2230 of the user in the PKI. 2232 5.2.2 POP for Key Management Keys 2234 Suppose that Al is a new instructor in the Computer Science 2235 Department of a local University. Al has created a draft final exam 2236 for the Introduction to Networking course he is teaching. He wants to 2237 send a copy of the draft final to Dorothy, the Department Head, for 2238 her review prior to giving the exam. This exam will of course be 2239 encrypted, as several students have access to the computer system. 2240 However, a quick search of the PKC repository (e.g., search the 2241 repository for all records with subjectPublicKey=Dorothy's-value) 2242 turns up the fact that several students have PKCs containing the same 2243 public key management key as Dorothy. At this point, if no POP has 2244 been done by the CA, Al has no way of knowing whether all of the 2245 students have simply created these PKCs without knowing the 2246 corresponding private key (and thus it is safe to send the encrypted 2247 exam to Dorothy), or whether the students have somehow acquired 2248 Dorothy's private key (and thus it is certainly not safe to send the 2249 exam). 2251 The later case may seem unsafe. However, if the other students have 2252 acquired the key, they do not even need to publish their certificates 2253 and can simply decrypt in parallel. 2255 The end story is that, if the key only known to Dorothy, there is no 2256 problem. Thus POP by the CA is not needed. 2258 If the key, like a Diffie-Hellman key, is used for an authentication 2259 service the answer depends from the protocol being used. In the 2260 former example, the decryption was done locally and no data was sent 2261 back on the wire. In an authentication protocol, the story is 2262 different because either some encrypted or decrypted data is sent 2263 back. If the data sent back contains the identifier of the 2264 certificate in a way that it cannot be modified without that 2265 modification being detected, then there is no need for POP. On the 2266 contrary, POP by the CA is needed. 2268 As a conservative measure, POP for encryption keys is recommended, 2269 but it should be realized that it is not always needed. 2271 In general it should be noticed that POP at the time of the 2272 transaction is much superior than POP made by the CA, since it is 2273 possible in real time to be sure that everything is correct, rather 2274 than rely on that verification to be done at the time of registration 2275 by the CA. Should the CA fail in that verification, then there is a 2277 Arsenault, Turner 44 2278 security breach. On the contrary, doing POP at the time of the 2279 transaction, eliminates that problem. 2281 CMP requires that POP be provided for all keys, either through on- 2282 line or out-of-band means. There are any number of ways to provide 2283 POP, and the choice of which to use is a local matter. Additionally, 2284 a PKC requester can provide POP to either a CA or to an RA, if the RA 2285 can adequately assure the CA that POP has been performed. Some of the 2286 acceptable ways to provide POP include: 2288 - Out-of-band means: 2290 - For keys generated by the CA or an RA (e.g., on a token such as 2291 a smart card or PCMCIA card), possession of the token can 2292 provide adequate proof of possession of the private key. 2294 - For user-generated keys, another approach can be used in 2295 environments where "key recovery" requirements force the 2296 requester to provide a copy of the private key to the CA or an 2297 RA. In this case, the CA will not issue the requested PKC until 2298 such time as the requester has provided the private key. This 2299 approach is in general not recommended, as it is extremely risky 2300 (e.g., the system designers need to figure out a way to protect 2301 the private keys from compromise while they are being sent to 2302 the CA/RA/other authority, and how to protect them there), but 2303 it can be used. 2305 - On-line means: 2307 - For signature keys that are generated by an EE, the requester of 2308 a PKC can be required to sign some piece of data (typically, the 2309 PKC request itself) using the private key. The CA will then use 2310 the requested public key to verify the signature. If the 2311 signature verification works, the CA can safely conclude that 2312 the requester had access to the private key. If the signature 2313 verification process fails, the CA can conclude that the 2314 requester did not have access to the correct private key, and 2315 reject the request. 2317 - For key management keys that are generated by the requester, the 2318 CA can send the user the requested public key, along with the 2319 CA's own public key, to encrypt some piece of data, and send it 2320 to the requester to be decrypted. For example, the CA can 2321 generate some random challenge, and require some action to be 2322 taken after decryption (e.g., "decrypt this encrypted random 2323 number and send it back to me"). If the requester does not take 2324 the requested action, the CA concludes that the requester did 2325 not possess the private key, and the PKC is not issued. 2327 Another method of providing POP for key management keys is for the CA 2328 to generate the requested PKC, and then send it to the requester in 2329 encrypted form. If the requester does not have access to the 2330 appropriate private key, the requester cannot decrypt the PKC, and 2332 Arsenault, Turner 45 2333 thus cannot use it. After some period of time in which the PKC is not 2334 used, the CA will revoke the PKC. (This only works if the PKC is not 2335 made available to any untrusted entities until after the requester 2336 has successfully decrypted it.) 2338 5.3 Key Usage Bits 2340 The key usage extension defines the purpose (e.g., encipherment, 2341 signature, certificate signing) of the key contained in the PKC. This 2342 extension is used when a key that could be used for more than one 2343 operation is to be restricted. For example, if a CA's RSA key should 2344 be used only for signing CRLS, the cRLSign bit would be asserted. 2345 Likewise, when an RSA key should be used only for key management, the 2346 keyEncipherment bit would be asserted. When used, this extension 2347 should be marked critical. 2349 The Internet PKI Profile [2459bis] includes some text for how the 2350 bits in the KeyUsage type are used. Developing the text for some of 2351 the bits was easy; however, many discussions were needed to arrive at 2352 a common agreement on the meaning of the digitalSignature (DS bit) 2353 and nonRepudiation (NR bit) bits and when they should be set. The 2354 group quickly realized that key usage extension mixes services and 2355 mechanisms. The DS bit indicates a mechanism - a public key used to 2356 verify a digital signature. The NR bit indicates a service - a public 2357 key used to verify a digital signature and to provide a non- 2358 repudiation service. When trying to indicate when each bit should be 2359 indicated arguments were based on: 2361 The lifetime of the object being singed. Some felt that the DS bit 2362 should be set when the certificate is used to sign ephemeral objects 2363 (e.g., bind tokens) while the NR bit should be set for things that 2364 are survive longer (e.g., documents). Of course, the problem with 2365 this distinction to determine how long is the time period for 2366 ephemeral? 2368 A conscious act taken by the signer. Many felt that the NR bit should 2369 be set only when the subject has expressly acknowledged that they 2370 want to use the private key to sign an object. Signing a document say 2371 where there is a conscious decision by the subject would be 2372 appropriate for the key usage extension to contain NR, but when the 2373 key is used for authentication purposes, which can occur 2374 automatically and more frequently, the DS bit is more appropriate. 2375 The discussion also concluded that since some authentication schemes 2376 occur automatically, that the DS bit and NR bit should never be set 2377 together in the same certificate. Some agreed to the differentiation 2378 of the bits based on the time, but did not agree that the two could 2379 not be in the same key usage extension. 2381 The procedures followed by the CA. Some felt that NR bit was kind of 2382 'quality mark' indicating to the verifier that the verifier could be 2383 assured that the CA is implementing appropriate procedures for 2384 checking the subject's identity, performing certificate archival, 2386 Arsenault, Turner 46 2387 etc. Other felt that it was not entirely the CAs job and that some 2388 other entity must be involved. 2390 In the end the WG agreed to a few things: 2392 - Provision of the service of non-repudiation requires more than a 2393 single bit set in a PKC. It requires an entire infrastructure of 2394 components to preserve for some period of time the keys, PKCs, 2395 revocation status, signed material, etc., as well as a trusted 2396 source of time. However, the nonRepudiation key usage bit is 2397 provided as an indicator that such keys could be used as a 2398 component of a system providing a non-repudiation service. 2400 - The certificate policy is the appropriate place to indicate the 2401 permitted combinations of key usages. That is, a policy may 2402 indicate that the DS and NR bits can not be set in the same 2403 certificate while another may say that the DS and NR bits can be 2404 set in the same certificate. 2406 [2459bis] includes new text indicating the above agreements. 2408 5.4 Non-Repudiation 2410 The major benefit of the whole DS bit vs NR bit discussion is 2411 development of the Technical Requirements for Non-Repudiation 2412 [TECHNR] draft. To fill this void [TECHNR] was developed to "describe 2413 those features of a service which processes signed documents which 2414 must be present in order for that service to constitute a 'technical 2415 non-repudiation' service." The basic understanding of non-repudiation 2416 is that it requires that a digital signature be preserved in such a 2417 manner that it can convince a neutral third party that it was 2418 actually created by someone with access to the private key of a 2419 certified key pair. Whether this definition of non-repudiation is 2420 enough to form a legally bind agreement is still being debated. 2422 5.5 Trust Models 2424 An important design decision is where a particular EE's trust point 2425 is located (i.e., where is the EE's Root CA). There are a number of 2426 models that have been developed and depending on the environment some 2427 models may be more suited than others. The following provides some 2428 background on the models. 2430 5.5.1 Hierarchical 2432 One of the initial trust models proposed was the hierarchical model. 2433 In this model the trust point or root CA for an entire domain is the 2434 top most CA. The root CA in turn issues certificates to subordinate 2435 CAs, and the subordinate CAs issue certificates to EEs. When 2437 Arsenault, Turner 47 2438 verifying a PKC, the RP must verify ever certificate in the path from 2439 the EE's PKC to the root CA. 2441 The main benefit of the hierarchical model is the fact that controls 2442 imposed from the top down. For example, name constraints can be 2443 included in the subordinate CAs to limit the name space in which they 2444 are allowed to issue certificates. Further, the root CA ensure domain 2445 wide policies on cross-certification (though there are no controls to 2446 prevent another PKI from issuing PKCs to members of the domain, but 2447 then those members could be thought of as members of two distinct 2448 PKIs). 2450 Interoperability is achieved through the use of cross-certificates. 2451 Cross-certificates can be issued by the root CA or if allowed by 2452 subordinate CAs. 2454 5.5.2 Local/Federation 2456 Another model that has been around a long time is the local trust 2457 model. In this model, the RPs trust the CA that issued their 2458 certificate to them. The idea is that since the CA is local and 2459 probably known to the RP, that there is more trust rather than with 2460 some distant unknown CA. 2462 In order for EEs under different CAs to communicate the CAs issue 2463 each other certificates thereby creating a certification path from 2464 one EE to another. The process of the CAs issuing one another PKCs 2465 forms a kind of federation 2467 The main benefit of the local model is its flexibility. Many believe 2468 that the local CA knows best how to support its user community and 2469 should be given cart blanche to generate certificates as it sees fit 2470 to allow the user community to perform their functions. 2472 5.5.3 Root Repository 2474 A model made famous in the web browser community is the root 2475 repository. This model uses a file to store the PKCs of many CAs. The 2476 RP then trusts any PKC included in the file. The PKC included in the 2477 root repository may be a root CA for some other domain or subordinate 2478 CA, but when included in the trust file whatever type of PKC it is in 2479 the other domain, it becomes a root CA for the RP. Obviously, the 2480 main advantage is the fact that cross-certification is not required. 2481 If the RP does not have the root CA's certificate and it is included 2482 in with the object, the RP can just add it to the file to ôtrustö it 2483 (this should only be done if the RP truly trusts the root CA). 2485 Arsenault, Turner 48 2486 5.5.4 RP's Perspective 2488 Another model recently getting attention is the model where instead 2489 of the CA imposing restraints on the RP (in the PKC), the RP instead 2490 makes the determination as to which certificates to trust. The RP 2491 determines which domain it will accept certificates from, which key 2492 usages it will accept, etc. Cross-certification is also not required 2493 because the RP can just chose to trust a particular PKC or domain of 2494 PKCs. This obviously turns the first three models on their heads. 2495 Special care must be taken to ensure that the RP is properly 2496 configured. 2498 6 References 2500 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 2501 3", BCP 9, RFC 2026, October 1996. 2503 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2504 Requirement Levels", BCP 14, RFC 2119, March 1997. 2506 [2459bis] Housley, R., Ford, W., Polk, W., and Solo, D., "Internet 2507 X.509 Public Key Infrastructure Certificate and CRL Profile," , October 2001. 2510 [2510bis] Adams, C., Farrell, S., ôInternet X.509 Public Key 2511 Infrastructure Certificate Management Protocols,ö , November 2001. 2514 [2511bis] Myers, M., Adams, C., Solo, D., and Kemp D. öInternet X.509 2515 Public Key Infrastructure Certificate Request Message Format 2516 (CRMF),ö , November 2001. 2518 [2527bis] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and Wu, 2519 S., "Internet X.509 Public Key Infrastructure Certificate Policy and 2520 Certification Practices Framework," , 12 July 2001. 2523 [AC] Farrell, S., and Housley, R., "An Internet Attribute Certificate 2524 Profile for Authorization," , June 2525 2001. 2527 [ADDSCHEMA] Chadwick, D., Legg, S., ôInternet X.509 Public Key 2528 Infrastructure Additional LDAP Schema for PKIs and PMIs,ö , November 2001. 2531 [CMC] Myers, M., Liu, X., Fox, B., and Weinstein, J., "Certificate 2532 Management Messages over CMS," (RFC 2797), April 2000. 2534 [CMP] Adams, C., Farrell, S., "Internet X.509 Public Key 2535 Infrastructure Certificate Management Protocols," RFC 2510, March 2536 1999. 2538 Arsenault, Turner 49 2540 [CMS] R. Housley, "Cryptographic Message Syntax," RFC 2630, July 2541 1999. 2543 [CRMF] Myers, M., Adams, C., Solo, D., and Kemp, D., "Internet X.509 2544 Certificate Request Message Format," RFC 2511, March 1999. 2546 [DNS] Mockapetris, P.V., "Domain names - concepts and facilities," 2547 RFC 1034, November 1987. 2549 [DHPOP] Prafullchandra, H., and Schaad, J., "Diffie-Hellman Proof- 2550 of-Possession Algorithms," RFC 2875, July 2000 1999. 2552 [DPD] Myers, M., Adams, C., Farrell, S., ôDelegated Path Discovery 2553 with OCSP,ö , September 2000. 2555 [DPV] Myers, M., Adams, C., Farrell, S., ôDelegated Path Validation,ö 2556 , August 2000. 2558 [DPREQ] Pinaks, D., "Delegated Path Validation and Delegated Path 2559 Discovery Protocol Requirements (DPV&DPD-REQ)," , November 2001. 2562 [DVCS] Adams, C., Sylvester, P., Zolotarev, M., Zuccherato, R., 2563 "Internet X.509 Public Key Infrastructure Data Certification Server 2564 Protocols", RFC 3029, February 2001. 2566 [FTPHTTP] Housley, R., and Hoffman, P., "Internet X.509 Public Key 2567 Infrastructure Operational Protocols: FTP and HTTP," RFC 2585, July 2568 1998. 2570 [IP] Postel, J., "Internet Protocol," RFC 791, September 1981. 2572 [IPv6] Deering, S., and Hinden, R., "Internet Protocol, Version 6 2573 [IPv6] Specification," RFC 1883, December 1995. 2575 [KEA] Housley, R., and Polk, W., "Internet X.509 Public Key 2576 Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in 2577 Internet X.509 Public Key Infrastructure Certificates," RFC 2528, 2578 March 1999. 2580 [LAAP] Farrell, S., Chadwick, C.W., "Limited Attribute Certificate 2581 Acquisition Protocol", , 14 July 2000. 2583 [LDAPv2] Yeong, Y., Howes, T., and Kille, S., "Lightweight Directory 2584 Access Protocol", RFC 1777, March 1995. 2586 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and Adams, 2587 C., "X.509 Internet Public Key Infrastructure Online Certificate 2588 Status Protocol - OCSP," RFC 2560, June 1999. 2590 [OCSPv2] Myers, M., Ankney, R., Adams, C., ôOnline Certificate Status 2591 Protocol, version 2,ö , September 2592 2000. 2594 Arsenault, Turner 50 2596 [MISPC] Burr, W., Dodson, D., Nazario, N., and Polk, W., "MISPC 2597 Minimum Interoperability Specification for PKI Components, Version 2598 1", , 3 September 1997. 2600 [PEM] Kent, S., "Privacy Enhancement for Internet Electronic Mail: 2601 Part II: Certificate-Based Key Management," RFC 1422, February 1993. 2603 [PI] Pinka, D., Gindin, T., ôInternet X.509 Public Key Infrastructure 2604 Permanent Identifier,ö , April 2001. 2606 [PKI-LDAPv2] Boeyen, S., Howes, T., and Richard, P., "Internet X.509 2607 Public Key Infrastructure Operational Protocols - LDAPv2," RFC 2559, 2608 April 1999. 2610 [PKI-LDAPv3] Chadwick, D.W., "Internet X.509 Public Key 2611 Infrastructure Operational Protocols - LDAPv3," , 20 November 2001. 2614 [POLPRAC] Chokhani, S., and Ford, W., "Internet X.509 Public Key 2615 Infrastructure Certificate Policy and Certification Practices 2616 Framework," RFC 2527, March 1999. 2618 [QC] Santesson, S., Polk, W., Barzin, P., and Nystrom, M., "Internet 2619 X.509 Public Key Infrastructure Qualified Certificates," RFC 3039, 2620 January 2001. 2622 [RLS] Boeyen, S., Hallam-Baker, P., ôInternet X.509 Public Key 2623 Infrastructure Repository Locator Service,ö , July 2000. 2626 [RPKDS] Bassham, L., Housley, R., Polk, W., ôInternet X.509 Public 2627 Key Infrastructure Representation of Public Keys and Digital 2628 Signatures in Internet X.509 Public Key Infrastructure Certificates,ö 2629 , 14 June, 2001. 2631 [SCHEMA] Boeyen, S., Howes, T., and Richard, P., "Internet X.509 2632 Public Key Infrastructure LDAPv2 Schema," RFC 2587, June 1999. 2634 [SCVP] Malpani, A., Hoffman, P., Housley, R., and Freeman, T., 2635 "Simple Certificate Validation Protocol (SCVP)," , July 2001. 2638 [SUPPALGS] Singer, A., and Whyte, W., "Supplemental Algorithms and 2639 Identifiers for the Internet X.509 Public Key Infrastructure 2640 Certificate and CRL Profile,ö , 2641 July 2001. 2643 [TECHNR] Gindin, T., ôInternet X.509 Public Key Infrastructure 2644 Technical Requirements for a non-Repudiation Service,ö , July 2000. 2647 Arsenault, Turner 51 2649 [TPCMP] Kapoor , A., Tschal, R., ôTransport Protocols for CMP,ö 2650 , November 2000. 2652 [TSP] Adams, C., Cain, P., Pinkas, D., and Zuccherato, R., "Internet 2653 X.509 Public Key Infrastructure Time Stamp Protocols", RFC 3161, 2654 August 2001. 2656 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 2657 Messages," RFC 822, August 1982. 2659 [SIMONETTI] Simonetti, D., "Re: German Key Usage", posting to ietf- 2660 pkix@imc.org mailing list, 12 August 1998. 2662 [SUPPALGS] Supplemental Algorithms and Identifiers for the Internet 2663 X.509 Public Key Infrastructure Certificate and CRL Profile , xxx 2001. 2666 [X.509] ITU-T Recommendation X.509 (1997 E): Information Technology - 2667 Open Systems Interconnection - The Directory: Authentication 2668 Framework, June 1997. 2670 [X9.42] ANSI X9.42-199x, Public Key Cryptography for The Financial 2671 Services Industry: Agreement of Symmetric Algorithm Keys Using 2672 Diffie-Hellman (Working Draft), December 1997. 2674 [X9.55] ANSI X9.55-1995, Public Key Cryptography For The Financial 2675 Services Industry: Extensions To Public Key Certificates And 2676 Certificate Revocation Lists, 8 December, 1995. 2678 [X9.57] ANSI X9.57-199x, Public Key Cryptography For The Financial 2679 Services Industry: Certificate Management (Working Draft), 21 June, 2680 1996. 2682 [PKCS10] RSA Laboratories, "The Public-Key Cryptography 2683 Standards(PKCS)," RSA Data Security Inc., Redwood City, California, 2684 November 1993 Release. 2686 7 Security Considerations 2688 There are not requirements in this document. 2690 8 Acknowledgements 2692 A lot of the information in this document was taken from the PKIX 2693 source documents; the authors of those deserve the credit for their 2694 own words. Other good material was taken from mail posted to the PKIX 2695 working group mail list (ietf-pkix@imc.org). Among those with good 2696 things to say were (in alphabetical order, with apologies to anybody 2697 we've missed): Sharon Boeyen, Santosh Chokhani, Warwick Ford, Russ 2698 Housley, Steve Kent, Ambarish Malpani, Matt Fite, Michael Myers, Tim 2699 Polk, Stefan Santesson, Dave Simonetti, Paul Hoffman, Denis Pinkas, 2701 Arsenault, Turner 52 2702 Ed Greck, Tom Gindin, Parag Namjoshi, Peter Sylvester, and Michael 2703 Zolotarev. 2705 9 Author's Addresses 2707 Alfred W. Arsenault 2708 Diversinet Corp. 2709 P.O. Box 6530 2710 Ellicott City, MD 21042-0530 2711 aarsenault@dvnet.com 2713 Sean Turner 2714 IECA, Inc. 2715 9010 Edgepark Road Vienna, VA 22182 2716 (703) 628-3180 2717 turners@ieca.com 2719 Expires July 2002 2721 Arsenault, Turner 53