idnits 2.17.1 draft-ietf-pkix-ipki-new-rfc2527-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 39) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 81 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 72 characters in excess of 72. ** There are 4 instances of lines with control characters in the document. ** The abstract seems to contain references ([CPF]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document obsoletes RFC2527, but the abstract doesn't seem to directly say this. It does mention RFC2527 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The first octets (the first characters of the first line) of this draft are 'PK', which can make Internet Explorer erroneously think that it is a zip file. It is recommended that you change this, for instance by inserting a blank line before the line starting with 'PK'. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 22, 2003) is 7646 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ABA1' -- Possible downref: Non-RFC (?) normative reference: ref. 'ABA2' -- Possible downref: Non-RFC (?) normative reference: ref. 'BAU1' -- Possible downref: Non-RFC (?) normative reference: ref. 'ETS' -- Possible downref: Non-RFC (?) normative reference: ref. 'GOC' -- Possible downref: Non-RFC (?) normative reference: ref. 'IDT' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO1' ** Downref: Normative reference to an Historic RFC: RFC 1422 (ref. 'PEM1') ** Obsolete normative reference: RFC 2459 (ref. 'PKI1') (Obsoleted by RFC 3280) ** Obsolete normative reference: RFC 2527 (ref. 'CPF') (Obsoleted by RFC 3647) Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PKIX Working Group S. Chokhani (Orion Security Solutions, Inc.) 2 Internet Draft W. Ford (VeriSign, Inc.) 3 Obsoletes: 2527 R. Sabett (Cooley Godward LLP) 4 C. Merrill (McCarter & English, LLP) 5 S. Wu (Infoliance, Inc.) 7 Expires in six months from April 22, 2003 9 Internet X.509 Public Key Infrastructure 11 Certificate Policy and Certification Practices Framework 13 < draft-ietf-pkix-ipki-new-rfc2527-02.txt > 15 Status of this Memo 17 This document is an Internet-Draft and is subject to all provisions 18 of Section 10 of RFC2026. Internet-Drafts are working documents of 19 the Internet Engineering Task Force (IETF), its areas, and its working 20 groups. Note that other groups may also distribute working documents 21 as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of 6 months 24 and may be updated, replaced, or may become obsolete by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as work in 27 progress. 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 To view the entire list of current Internet-Drafts, please check the 36 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 37 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 38 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 39 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 41 Copyright (C) The Internet Society 2003. All Rights Reserved. 43 Abstract 45 This document presents a framework to assist the writers of 46 certificate policies or certification practice statements for 47 participants within public key infrastructures, such as 48 certification authorities, policy authorities, and communities of 49 interest that wish to rely on certificates. In particular, the 50 framework provides a comprehensive list of topics that potentially 51 (at the writer's discretion) need to be covered in a certificate 52 policy or a certification practice statement. This document is 53 being submitted to the RFC Editor with a request for publication as 54 an Informational RFC that will supersede RFC 2527 [CPF]. 56 TABLE OF CONTENTS 57 1. INTRODUCTION 3 58 1.1 BACKGROUND 3 59 1.2 PURPOSE 5 60 1.3 SCOPE 5 61 2. DEFINITIONS 6 62 3. CONCEPTS 8 63 3.1 CERTIFICATE POLICY 8 64 3.2 CERTIFICATE POLICY EXAMPLES 10 65 3.3 X.509 CERTIFICATE FIELDS 10 66 3.3.1 Certificate Policies Extension 10 67 3.3.2 Policy Mappings Extension 11 68 3.3.3 Policy Constraints Extension 12 69 3.3.4 Policy Qualifiers 12 70 3.4 CERTIFICATION PRACTICE STATEMENT 13 71 3.5 RELATIONSHIP BETWEEN CP AND CPS 14 72 3.6 RELATIONSHIP AMONG CPs, CPSs, AGREEMENTS, AND 73 OTHER DOCUMENTS 15 74 3.7 SET OF PROVISIONS 17 75 4. CONTENTS OF A SET OF PROVISIONS 19 76 4.1 INTRODUCTION 19 77 4.1.1 Overview 19 78 4.1.2 Document Name and Identification 20 79 4.1.3 PKI Participants 20 80 4.1.4 Certificate usage 21 81 4.1.5 Policy Administration 21 82 4.1.6 Definitions and acronyms 21 83 4.2 PUBLICATION AND REPOSITORY RESPONSIBILITIES 21 84 4.3 IDENTIFICATION AND AUTHENTICATION (I&A) 22 85 4.3.1 Naming 22 86 4.3.2 Initial Identity Validation 22 87 4.3.3 I&A for Re-key Requests 23 88 4.3.4 I&A for Revocation Requests 23 89 4.4 CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS 24 90 4.4.1 Certificate Application 24 91 4.4.2 Certificate Application Processing 24 92 4.4.3 Certificate Issuance 24 93 4.4.4 Certificate Acceptance 25 94 4.4.5 Key Pair and Certificate Usage 25 95 4.4.6 Certificate Renewal 26 96 4.4.7 Certificate Re-key 26 97 4.4.8 Certificate Modification 27 98 4.4.9 Certificate Revocation and Suspension 27 99 4.4.10 Certificate Status Services 28 100 4.4.11 End of Subscription 28 101 4.4.12 Key Escrow and Recovery 29 102 4.5 FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS 29 103 4.5.1 Physical Security Controls 29 104 4.5.2 Procedural Controls 30 105 4.5.3 Personnel Controls 30 106 4.5.4 Audit Logging Procedures 31 107 4.5.5 Records Archival 31 108 4.5.6 Key Changeover 32 109 4.5.7 Compromise and Disaster Recovery 32 110 4.5.8 CA or RA Termination 33 112 4.6 TECHNICAL SECURITY CONTROLS 33 113 4.6.1 Key Pair Generation and Installation 33 114 4.6.2 Private Key Protection and Cryptographic 115 Module Engineering Controls 34 116 4.6.3 Other Aspects of Key Pair Management 36 117 4.6.4 Activation Data 36 118 4.6.5 Computer Security Controls 36 119 4.6.6 Life Cycle Security Controls 37 120 4.6.7 Network Security Controls 37 121 4.6.8 Timestamping 37 122 4.7 CERTIFICATE, CRL, AND OCSP PROFILES 37 123 4.7.1 Certificate Profile 37 124 4.7.2 CRL Profile 38 125 4.7.3 OCSP Profile 38 126 4.8 COMPLIANCE AUDIT AND OTHER ASSESSMENT 38 127 4.9 OTHER BUSINESS AND LEGAL MATTERS 39 128 4.9.1 Fees 40 129 4.9.2 Financial Responsibility 40 130 4.9.3 Confidentiality of Business Information 40 131 4.9.4 Privacy of Personal Information 41 132 4.9.5 Intellectual Property Rights 41 133 4.9.6 Representations and Warranties 41 134 4.9.7 Disclaimers of Warranties 42 135 4.9.8 Limitations of Liability 42 136 4.9.9 Indemnities 42 137 4.9.10 Term and Termination 42 138 4.9.11 Individual notices and communications 139 with participants 43 140 4.9.12 Amendments 43 141 4.9.13 Dispute Resolution Procedures 44 142 4.9.14 Governing Law 44 143 4.9.15 Compliance with Applicable Law 44 144 4.9.16 Miscellaneous Provisions 44 145 4.9.17 Other Provisions 45 146 5. SECURITY CONSIDERATIONS 45 147 6. OUTLINE OF A SET OF PROVISIONS 45 148 7. COMPARISON TO RFC 2527 52 149 8. ACKNOWLEDGMENTS 77 150 9. REFERENCES 78 151 10. AUTHORS' ADDRESSES 78 152 NOTES 79 153 LIST OF ACRONYMS 80 155 ----------------------------------------------------------------- 157 1. INTRODUCTION 159 1.1 BACKGROUND 161 In general, a public-key certificate (hereinafter "certificate") 162 binds a public key held by an entity (such as person, organization, 163 account, device, or site) to a set of information that identifies 164 the entity associated with use of the corresponding private key. In 165 most cases involving identity certificates, this entity is known as 166 the "subject" or "subscriber" of the certificate. Two exceptions, 168 however, include devices (in which the subscriber is usually the 169 individual or organization controlling the device) and anonymous 171 certificates (in which the identity of the individual or 172 organization is not available from the certificate itself). 173 Other types of certificates bind public keys to attributes of an 174 entity other than the entity's identity, such as a role, a title, or 175 creditworthiness information. 177 A certificate is used by a "certificate user" or "relying party" 178 that needs to use, and rely upon the accuracy of, the binding 179 between the subject public key distributed via that certificate and 180 the identity and/or other attributes of the subject contained in 181 that certificate. A relying party is frequently an entity that 182 verifies a digital signature from the certificate's subject where 183 the digital signature is associated with an email, web form, 184 electronic document, or other data. Other examples of relying 185 parties can include a sender of encrypted email to the subscriber, a 186 user of a web browser relying on a server certificate during a 187 secure sockets layer (SSL) session, and an entity operating a server 188 that controls access to online information using client certificates 189 as an access control mechanism. In summary, a relying party is an 190 entity that uses a public key in a certificate (for signature 191 verification and/or encryption). The degree to which a relying 192 party can trust the binding embodied in a certificate depends on 193 several factors. These factors can include the practices followed 194 by the certification authority (CA) in authenticating the subject; 195 the CA's operating policy, procedures, and security controls; the 196 scope of the subscriber's responsibilities (for example, in 197 protecting the private key); and the stated responsibilities and 198 liability terms and conditions of the CA (for example, warranties, 199 disclaimers of warranties, and limitations of liability). 201 A Version 3 X.509 certificate may contain a field declaring that one 202 or more specific certificate policies apply to that certificate 203 [ISO1]. According to X.509, a certificate policy (CP) is "a named 204 set of rules that indicates the applicability of a certificate to a 205 particular community and/or class of applications with common 206 security requirements." A CP may be used by a relying party to help 207 in deciding whether a certificate, and the binding therein, are 208 sufficiently trustworthy and otherwise appropriate for a particular 209 application. The CP concept is an outgrowth of the policy statement 210 concept developed for Internet Privacy Enhanced Mail [PEM1] and 211 expanded upon in [BAU1]. The legal and liability aspects presented 212 in Section 4.9 are outcome of a collaborative effort between IETF 213 PKIX working group and the American Bar Association (ABA) members 214 who have worked on legal acceptance of digital signature and role of 215 PKI in that acceptance. 217 A more detailed description of the practices followed by a CA in 218 issuing and otherwise managing certificates may be contained in a 219 certification practice statement (CPS) published by or referenced by 220 the CA. According to the American Bar Association Information 221 Security Committee's Digital Signature Guidelines (hereinafter 222 "DSG")(1) and the Information Security Committee's PKI Assessment 224 Guidelines (hereinafter "PAG")(2), "a CPS is a statement of the 225 practices which a certification authority employs in issuing 226 certificates." [ABA1, ABA2] In general, CPSs also describe practices 227 relating to all certificate lifecycle services (e.g., issuance, 228 management, revocation, and renewal or re-keying), and CPSs provide 229 details concerning other business, legal, and technical matters. 230 The terms contained in a CP or CPS may or may not be binding upon a 231 PKI's participants as a contract. A CP or CPS may itself purport to 232 be a contract. More commonly, however, an agreement may incorporate 233 a CP or CPS by reference and therefore attempt to bind the parties of 234 the agreement to some or all of its terms. For example, some PKIs 235 may utilize a CP or (more commonly) a CPS that is incorporated by 236 reference in the agreement between a subscriber and a CA or RA 237 (called a "subscriber agreement") or the agreement between a relying 238 party and a CA (called a "relying party agreement" or "RPA"). In 239 other cases, however, a CP or CPS has no contractual significance at 240 all. A PKI may intend these CPs and CPSs to be strictly 241 informational or disclosure documents. 243 1.2 PURPOSE 245 The purpose of this document is twofold. First, the document aims 246 to explain the concepts of a CP and a CPS, describe the differences 247 between these two concepts, and describe their relationship to 248 subscriber and relying party agreements. Second, this document aims 249 to present a framework to assist the writers and users of 250 certificate policies or CPSs in drafting and understanding these 251 documents. In particular, the framework identifies the elements 252 that may need to be considered in formulating a CP or a CPS. The 253 purpose is not to define particular certificate policies or CPSs, 254 per se. Moreover, this document does not aim to provide legal advice 255 or recommendations as to particular requirements or practices that 256 should be contained within CPs or CPSs. (Such recommendations, 257 however, appear in [ABA2].) 259 1.3 SCOPE 261 The scope of this document is limited to discussion of the topics 262 that can be covered in a CP (as defined in X.509) or CPS (as defined 263 in the DSG and PAG). In particular, this document describes the 264 types of information that should be considered for inclusion in a CP 265 or a CPS. While the framework as presented generally assumes use of 266 the X.509 version 3 certificate format for the purpose of providing 267 assurances of identity, it is not intended that the material be 268 restricted to use of that certificate format or identity 269 certificates. Rather, it is intended that this framework be 270 adaptable to other certificate formats and to certificates providing 271 assurances other than identity that may come into use. 273 The scope does not extend to defining security policies generally 274 (such as organization security policy, system security policy, or 275 data labeling policy). Further, this document does not define a 276 specific CP or CPS. Moreover, in presenting a framework, this 277 document should be viewed and used as a flexible tool presenting 278 topics that should be considered of particular relevance to CPs or 280 CPSs, and not as a rigid formula for producing CPs or CPSs. 282 This document assumes that the reader is familiar with the general 283 concepts of digital signatures, certificates, and public-key 284 infrastructure (PKI), as used in X.509, the DSG, and the PAG. 286 2. DEFINITIONS 288 This document makes use of the following defined terms: 290 Activation data - Data values, other than keys, that are required to 291 operate cryptographic modules and that need to be protected (e.g., a 292 PIN, a passphrase, or a manually-held key share). 294 Authentication - The process of establishing that individuals, 295 organizations, or things are who or what they claim to be. In the 296 context of a PKI, authentication can be the process of establishing 297 that that an individual or organization applying for or seeking 298 access to something under a certain name is, in fact, the proper 299 individual or organization. This process corresponds to the second 300 process involved with identification, as shown in the definition of 301 "identification" below. Authentication can also refer to a security 302 service that provides assurances that individuals, organizations, or 303 things are who or what they claim to be or that a message or other 304 data originated from a specific individual, organization, or device. 305 Thus, it is said that a digital signature of a message authenticates 306 the message's sender. 308 CA-certificate - A certificate for one CA's public key issued by 309 another CA. 311 Certificate policy (CP) - A named set of rules that indicates the 312 applicability of a certificate to a particular community and/or 313 class of application with common security requirements. For 314 example, a particular CP might indicate applicability of a type of 315 certificate to the authentication of parties engaging in business- 316 to-business transactions for the trading of goods or services within 317 a given price range. 319 Certification path - An ordered sequence of certificates that, 320 together with the public key of the initial object in the path, can 321 be processed to obtain that of the final object in the path. 323 Certification Practice Statement (CPS) - A statement of the 324 practices that a certification authority employs in issuing, 325 managing, revoking, and renewing or re-keying certificates. 327 CPS Summary (or CPS Abstract) - A subset of the provisions of a 328 complete CPS that is made public by a CA. 330 Identification - The process of establishing the identity of an 331 individual or organization, i.e., to show that an individual or 332 organization is a specific individual or organization. In the 333 context of a PKI, identification refers to two processes: (1) 334 establishing that a given name of an individual or organization 336 corresponds to a real-world identity of an individual or 337 organization, and (2) establishing that an individual or 338 organization applying for or seeking access to something under that 339 name is, in fact, the named individual or organization. A person 340 seeking identification may be a certificate applicant, an applicant 341 for employment in a trusted position within a PKI participant, or 342 a person seeking access to a network or software application, such 343 as a CA administrator seeking access to CA systems. 345 Issuing certification authority (issuing CA) - In the context of a 346 particular certificate, the issuing CA is the CA that issued the 347 certificate (see also Subject certification authority). 349 Participant - An individual or organization that plays a role within 350 a given PKI as a subscriber, relying party, CA, RA, certificate 351 manufacturing authority, repository service provider, or similar 352 entity. 354 PKI Disclosure Statement (PDS) - An instrument that supplements a CP 355 or CPS by disclosing critical information about the policies and 356 practices of a CA/PKI. A PDS is a vehicle for disclosing and 357 emphasizing information normally covered in detail by associated CP 358 and/or CPS documents. Consequently, a PDS is not intended to 359 replace a CP or CPS. 361 Policy qualifier - Policy-dependent information that may accompany a 362 CP identifier in an X.509 certificate. Such information can include 363 a pointer to the URL of the applicable CPS or relying party 364 agreement. It may also include text (or number causing the 365 appearance of text) that contains terms of the use of the 366 certificate or other legal information. 368 Registration authority (RA) - An entity that is responsible for one 369 or more of the following functions: the identification and 370 authentication of certificate applicants, the approval or rejection 371 of certificate applications, initiating certificate revocations or 372 suspensions under certain circumstances, processing subscriber 373 requests to revoke or suspend their certificates, and approving or 374 rejecting requests by subscribers to renew or re-key their 375 certificates. RAs, however, do not sign or issue certificates 376 (i.e., an RA is delegated certain tasks on behalf of a CA). [Note: 377 The term Local Registration Authority (LRA) is sometimes used in 378 other documents for the same concept.] 380 Relying party - A recipient of a certificate who acts in reliance on 381 that certificate and/or any digital signatures verified using that 382 certificate. In this document, the terms "certificate user" and 383 "relying party" are used interchangeably. 385 Relying party agreement (RPA) - An agreement between a certification 386 authority and relying party that typically establishes the rights 387 and responsibilities between those parties regarding the 388 verification of digital signatures or other uses of certificates. 390 Set of provisions - A collection of practice and/or policy 392 statements, spanning a range of standard topics, for use in 393 expressing a CP or CPS employing the approach described in this 394 framework. 396 Subject certification authority (subject CA) - In the context of 397 a particular CA-certificate, the subject CA is the CA whose public 398 key is certified in the certificate (see also Issuing certification 399 authority). 401 Subscriber - A subject of a certificate who is issued a certificate. 403 Subscriber Agreement - An agreement between a CA and a subscriber 404 that establishes the right and responsibilities of the parties 405 regarding the issuance and management of certificates. 407 Validation - The process of identification of certificate 408 applicants. "Validation" is a subset of "identification" and refers 409 to identification in the context of establishing the identity of 410 certificate applicants. 412 3. CONCEPTS 414 This section explains the concepts of CP and CPS, and describes 415 their relationship with other PKI documents, such as subscriber 416 agreements and relying party agreements. Other related concepts are 417 also described. Some of the material covered in this section and in 418 some other sections is specific to certificate policies extensions 419 as defined X.509 version 3. Except for those sections, this 420 framework is intended to be adaptable to other certificate formats 421 that may come into use. 423 3.1 CERTIFICATE POLICY 425 When a certification authority issues a certificate, it is providing 426 a statement to a certificate user (i.e., a relying party) that a 427 particular public key is bound to the identity and/or other 428 attributes of a particular entity (the certificate subject, which is 429 usually also the subscriber). The extent to which the relying party 430 should rely on that statement by the CA, however, needs to be 432 assessed by the relying party or entity controlling or coordinating 433 the way relying parties or relying party applications use 434 certificates. Different certificates are issued following different 435 practices and procedures, and may be suitable for different 436 applications and/or purposes. 438 The X.509 standard defines a CP as "a named set of rules that 439 indicates the applicability of a certificate to a particular 440 community and/or class of application with common security 441 requirements" [ISO1]. An X.509 Version 3 certificate may identify a 442 specific applicable CP, which may be used by a relying party to 443 decide whether or not to trust a certificate, associated public key, 444 or any digital signatures verified using the public key for a 445 particular purpose. 447 CPs typically fall into two major categories. First, some CPs 449 "indicate the applicability of a certificate to a particular 450 community" [ISO1]. These CPs set forth requirements for 451 certificate usage and requirements on members of a community. 452 For instance, a CP may focus on the needs of a geographical community, 453 such as the ETSI policy requirements for CAs issuing qualified 454 certificates [ETS]. Also, a CP of this kind may focus on the 455 needs of a specific vertical-market community, such as 456 financial services [IDT]. 458 The second category of typical CPs "indicate the applicability of a 459 certificate to a . . . class of application with common security 460 requirements." These CPs identify a set of applications or uses for 461 certificates and say that these applications or uses require a 462 certain level of security. They then set forth PKI requirements 463 that are appropriate for these applications or uses. A CP within 464 this category often makes sets requirements appropriate for a 465 certain "level of assurance" provided by certificates, relative to 466 certificates issued pursuant to related CPs. These levels of 467 assurance may correspond to "classes" or "types" of certificates. 469 For instance, the Government of Canada PKI Policy Management 470 Authority (GOC PMA) has established eight certificate policies in a 471 single document [GOC], four policies for certificates used for 472 digital signatures and four policies for certificates used for 473 confidentiality encryption. For each of these applications, the 474 document establishes four levels of assurances: rudimentary, basic, 475 medium, and high. The GOC PMA described certain types of digital 476 signature and confidentiality uses in the document, each with a 477 certain set of security requirements, and grouped them into eight 478 categories. The GOC PMA then established PKI requirements for each 479 of these categories, thereby creating eight types of certificates, 480 each providing rudimentary, basic, medium, or high levels of 481 assurance. The progression from rudimentary to high levels 482 corresponds to increasing security requirements and corresponding 483 increasing levels of assurance. 485 A CP is represented in a certificate by a unique number called 486 an "Object Identifier" (OID). That OID, or at least an "arc", can be 487 registered. An "arc" is the beginning of the numerical sequence of 488 an OID and is assigned to a particular organization. The 489 registration process follows the procedures specified in ISO/IEC and 490 ITU standards. The party that registers the OID or arc also can 491 publish the text of the CP, for examination by relying parties. Any 492 one certificate will typically declare a single CP or, possibly, be 493 issued consistent with a small number of different policies. Such 494 declaration appears in the Certificate Policies extension of a X.509 495 Version 3 certificate. When a CA places multiple CPs within a 496 certificate's Certificate Policies extension, the CA is asserting 497 that the certificate is appropriate for use in accordance with any 498 of the listed CPs. 500 CPs also constitute a basis for an audit, accreditation, or another 501 assessment of a CA. Each CA can be assessed against one or more 502 certificate policies or CPSs that it is recognized as implementing. 503 When one CA issues a CA-certificate for another CA, the issuing CA 505 must assess the set of certificate policies for which it trusts the 506 subject CA (such assessment may be based upon an assessment with 507 respect to the certificate policies involved). The assessed set of 508 certificate policies is then indicated by the issuing CA in the 509 CA-certificate. The X.509 certification path processing logic 510 employs these CP indications in its well-defined trust model. 512 3.2 CERTIFICATE POLICY EXAMPLES 514 For example purposes, suppose that the International Air Transport 515 Association (IATA) undertakes to define some certificate policies 516 for use throughout the airline industry, in a PKI operated by IATA 517 in combination with PKIs operated by individual airlines. Two CPs 518 might be defined - the IATA General-Purpose CP, and the IATA 519 Commercial-Grade CP. 521 The IATA General-Purpose CP could be used by industry personnel for 522 protecting routine information (e.g., casual electronic mail) and 523 for authenticating connections from World Wide Web browsers to 524 servers for general information retrieval purposes. The key pairs 525 may be generated, stored, and managed using low-cost, software-based 526 systems, such as commercial browsers. Under this policy, a 527 certificate may be automatically issued to anybody listed as an 528 employee in the corporate directory of IATA or any member airline 529 who submits a signed certificate request form to a network 530 administrator in his or her organization. 532 The IATA Commercial-Grade CP could be used to protect financial 533 transactions or binding contractual exchanges between airlines. 534 Under this policy, IATA could require that certified key pairs be 535 generated and stored in approved cryptographic hardware tokens. 536 Certificates and tokens could be provided to airline employees with 537 disbursement authority. These authorized individuals might then be 538 required to present themselves to the corporate security office, 539 show a valid identification badge, and sign a subscriber agreement 540 requiring them to protect the token and use it only for authorized 541 purposes, as a condition of being issued a token and a certificate. 543 3.3 X.509 CERTIFICATE FIELDS 545 The following extension fields in an X.509 certificate are used to 546 support CPs: 548 * Certificate Policies extension; 549 * Policy Mappings extension; and 550 * Policy Constraints extension. 552 3.3.1 Certificate Policies Extension 554 A Certificate Policies field lists CPs that the certification 555 authority declares are applicable. Using the example of the IATA 556 General-Purpose and Commercial-Grade policies defined in Section 557 3.2, the certificates issued to regular airline employees would 558 contain the object identifier for General-Purpose policy. The 559 certificates issued to the employees with disbursement authority 561 would contain the object identifiers for both the General-Purpose 562 policy and the Commercial-Grade policy. The inclusion of both 564 object identifiers in the certificates means that they would be 565 appropriate for either the General-Purpose or Commercial-Grade 567 policies. The Certificate Policies field may also optionally convey 568 qualifier values for each identified policy; the use of qualifiers 569 is discussed in Section 3.4. 571 When processing a certification path, a CP that is acceptable to the 572 relying party application must be present in every certificate in 573 the path, i.e., in CA-certificates as well as end entity 574 certificates. 576 If the Certificate Policies field is flagged critical, it serves the 577 same purpose as described above but also has an additional role. 578 Specifically, it indicates that the use of the certificate is 579 restricted to one of the identified policies, i.e., the 580 certification authority is declaring that the certificate must only 581 be used in accordance with the provisions of at least one of the 582 listed CPs. This field is intended to protect the certification 583 authority against claims for damages asserted by a relying party who 584 has used the certificate for an inappropriate purpose or in an 585 inappropriate manner, as stipulated in the applicable CP. 587 For example, the Internal Revenue Service might issue certificates 588 to taxpayers for the purpose of protecting tax filings. The 589 Internal Revenue Service understands and can accommodate the risks 590 of erroneously issuing a bad certificate, e.g., to an imposter. 591 Suppose, however, that someone used an Internal Revenue Service tax- 592 filing certificate as the basis for encrypting multi-million-dollar- 593 value proprietary trade secrets, which subsequently fell into the 594 wrong hands because of a cryptanalytic attack by an attacker who is 595 able to decrypt the message. The Internal Revenue Service may want 596 to defend itself against claims for damages in such circumstances by 597 pointing to the criticality of the Certificate Policies extension to 598 show that the subscriber and relying party misused the certificate. 599 The critical-flagged Certificate Policies extension is intended to 600 mitigate the risk to the CA in such situations. 602 3.3.2 Policy Mappings Extension 604 The Policy Mappings extension may only be used in CA-certificates. 605 This field allows a certification authority to indicate that certain 606 policies in its own domain can be considered equivalent to certain 607 other policies in the subject certification authority's domain. 609 For example, suppose that for purposes of facilitating 610 interoperability, the ACE Corporation establishes an agreement with 611 the ABC Corporation to cross-certify the public keys of each others' 612 certification authorities for the purposes of mutually securing 613 their respective business-to-business exchanges. Further, suppose 614 that both companies have pre-existing financial transaction 615 protection policies called ace-e-commerce and abc-e-commerce, 616 respectively. One can see that simply generating cross-certificates 618 between the two domains will not provide the necessary 619 interoperability, as the two companies' applications are configured 620 with, and employee certificates are populated with, their 621 respective certificate policies. One possible solution is to 622 reconfigure all of the financial applications to require either 623 policy and to reissue all the certificates with both policies 624 appearing in their Certificate Policies extensions. Another 625 solution, which may be easier to administer, uses the Policy Mapping 626 field. If this field is included in a cross-certificate for the ABC 627 Corporation certification authority issued by the ACE Corporation 628 certification authority, it can provide a statement that the ABC's 629 financial transaction protection policy (i.e., abc-e-commerce) can 630 be considered equivalent to that of the ACE Corporation (i.e., ace- 631 e-commerce). With such a statement included in the cross- 632 certificate issued to ABC, relying party applications in the ACE 633 domain requiring the presence of the object identifier for the ace- 634 e-commerce CP can also accept, process, and rely upon certificates 635 issued within the ABC domain containing the object identifier for 636 the abc-e-commerce CP. 638 3.3.3 Policy Constraints Extension 640 The Policy Constraints extension supports two optional features. 641 The first is the ability for a certification authority to require 642 that explicit CP indications be present in all subsequent 643 certificates in a certification path. Certificates at the start of 644 a certification path may be considered by a relying party to be part 645 of a trusted domain, i.e., certification authorities are trusted for 646 all purposes so no particular CP is needed in the Certificate 647 Policies extension. Such certificates need not contain explicit 648 indications of CP. When a certification authority in the trusted 649 domain, however, certifies outside the domain, it can activate the 650 requirement that a specific CP's object identifier appear in 651 subsequent certificates in the certification path. 653 The other optional feature in the Policy Constraints field is the 654 ability for a certification authority to disable policy mapping by 655 subsequent certification authorities in a certification path. It 656 may be prudent to disable policy mapping when certifying outside the 657 domain. This can assist in controlling risks due to transitive 658 trust, e.g., a domain A trusts domain B, domain B trusts domain C, 659 but domain A does not want to be forced to trust domain C. 661 3.3.4 Policy Qualifiers 663 The Certificate Policies extension field has a provision for 664 conveying, along with each CP identifier, additional policy- 665 dependent information in a qualifier field. The X.509 standard does 666 not mandate the purpose for which this field is to be used, nor does 667 it prescribe the syntax for this field. Policy qualifier types can 668 be registered by any organization. 670 The following policy qualifier types are defined in PKIX RFC 2459 671 [PKI1]: 672 (a) The CPS Pointer qualifier contains a pointer to a CPS, CPS 674 Summary, RPA, or PDS published by the CA. The pointer is in the 675 form of a uniform resource identifier (URI). 677 (b) The User Notice qualifier contains a text string that is to be 678 displayed to subscribers and relying parties prior to the use of the 679 certificate. The text string may be an IA5String or a BMPString - a 680 subset of the ISO 100646-1 multiple octet coded character set. A CA 681 may invoke a procedure that requires that the relying party 682 acknowledge that the applicable terms and conditions have been 683 disclosed and/or accepted. 685 Policy qualifiers can be used to support the definition of generic, 686 or parameterized, CPs. Provided the base CP so provides, policy 687 qualifier types can be defined to convey, on a per-certificate 688 basis, additional specific policy details that fill in the generic 689 definition. 691 3.4 CERTIFICATION PRACTICE STATEMENT 693 The term certification practice statement (CPS) is defined by the 694 DSG and PAG as: "A statement of the practices which a certification 695 authority employs in issuing certificates." [ABA1, ABA2] As stated 696 above, a CPS establishes practices concerning lifecycle services in 697 addition to issuance, such as certificate management (including 698 publication and archiving), revocation, and renewal or re-keying. In 699 the DSG, the ABA expands this definition with the following comments: 701 "A certification practice statement may take the form of a 702 declaration by the certification authority of the details of its 703 trustworthy system and the practices it employs in its operations 704 and in support of issuance of a certificate . . . ." This form of 705 CPS is the most common type, and can vary in length and level of 706 detail. 708 Some PKIs may not have the need to create a thorough and detailed 709 statement of practices. For example, the CA may itself be the 710 relying party and would already be aware of the nature and 711 trustworthiness of its services. In other cases, a PKI may provide 712 certificates providing only a very low level of assurances where the 713 applications being secured may pose only marginal risks if 714 compromised. In these cases, an organization establishing a PKI 715 may only want to write or have CAs use a subscriber agreement, 716 relying party agreement, or agreement combining subscriber and 717 relying party terms, depending on the role of the different PKI 718 participants. In such a PKI, that agreement may serve as the only 719 "statement of practices" used by one or more CAs within that PKI. 720 Consequently, that agreement may also be considered a CPS and can 721 be entitled or subtitled as such. 723 Likewise, since a detailed CPS may contain sensitive details of its 724 system, a CA may elect not to publish its entire CPS. It may 725 instead opt to publish a CPS Summary (or CPS Abstract). The CPS 726 Summary would contain only those provisions from the CPS that the CA 727 considers to be relevant to the participants in the PKI (such as the 728 responsibilities of the parties or the stages of the certificate 730 lifecycle). A CPS Summary, however, would not contain those 731 sensitive provisions of the full CPS that might provide an 732 attacker with useful information about the CA's operations. 733 Throughout this document, the use of "CPS" includes both a detailed 734 CPS and a CPS Summary (unless otherwise specified). 736 CPSs do not automatically constitute contracts and do not 737 automatically bind PKI participants as a contract would. Where a 738 document serves the dual purpose of being a subscriber or relying 739 party agreement and CPS, the document is intended to be a contract 740 and constitutes a binding contract to the extent that a subscriber 741 or relying party agreement would ordinarily be considered as such. 742 Most CPSs, however, do not serve such a dual purpose. Therefore, in 743 most cases, a CPS's terms have a binding effect as contract terms 744 only if a separate document creates a contractual relationship 745 between the parties and that document incorporates part or all of 746 the CPS by reference. Further, if a particular PKI employs a CPS 747 Summary (as opposed to the entire CPS), the CPS Summary could be 748 incorporated into any applicable subscriber or relying party 749 agreement. 751 In the future, a court or applicable statutory or regulatory law may 752 declare that a certificate itself is a document that is capable of 753 creating a contractual relationship, to the extent its mechanisms 754 designed for incorporation by reference (such as the Certificate 755 Policies extension and its qualifiers) indicate that terms of its 756 use appear in certain documents. In the meantime, however, some 757 subscriber agreements and relying party agreements may incorporate a 758 CPS by reference and therefore make its terms binding on the parties 759 to such agreements. 761 3.5 RELATIONSHIP BETWEEN CERTIFICATE POLICY AND CERTIFICATION 762 PRACTICE STATEMENT 764 The CP and CPS address the same set of topics that are of interest 765 to the relying party in terms of the degree to and purpose for which 766 a public key certificate should be trusted. Their primary 767 difference is in the focus of their provisions. A CP sets forth the 768 requirements and standards imposed by the PKI with respect to the 769 various topics. In other words, the purpose of the CP is to 770 establish what participants must do. A CPS, by contrast, states how 771 a CA and other participants in a given domain implement procedures 772 and controls to meet the requirements stated in the CP. In other 773 words, the purpose of the CPS is to disclose how the participants 774 perform their functions and implement controls. 776 An additional difference between a CP and CPS relates the scope of 777 coverage of the two kinds of documents. Since a CP is a statement 778 of requirements, it best serves as the vehicle for communicating 779 minimum operating guidelines that must be met by interoperating PKIs. 780 Thus, a CP generally applies to multiple CAs, multiple organizations, 781 or multiple domains. By contrast, a CPS applies only to a single CA 782 or single organization and is not generally a vehicle to facilitate 783 interoperation. 785 A CA with a single CPS may support multiple CPs (used for 786 different application purposes and/or by different relying party 787 communities). Also, multiple CAs, with non-identical CPSs, may 788 support the same CP. 790 For example, the Federal Government might define a government-wide 791 CP for handling confidential human resources information. The CP 792 will be a broad statement of the general requirements for 793 participants within the Government's PKI, and an indication of the 794 types of applications for which it is suitable for use. Each 795 department or agency wishing to operate a certification authority in 796 this PKI may be required to write its own certification practice 797 statement to support this CP by explaining how it meets the 798 requirements of the CP. At the same time, a department's or 799 agency's CPS may support other certificate policies. 801 An additional difference between a CP and CPS concerns the level of 802 detail of the provisions in each. Although the level of detail may 803 vary among CPSs, a CPS will generally be more detailed than a CP. A 804 CPS provides a detailed description of procedures and controls in 805 place to meet the CP requirements, while a CP is more general. 807 The main differences between CPs and CPSs can therefore be 808 summarized as follows: 810 (a) A PKI uses a CP to establish requirements that state what 811 participants within it must do. A single CA or organization can use 812 a CPS to disclose how it meets the requirements of a CP or how it 813 implements its practices and controls. 815 (b) A CP facilitates interoperation through cross-certification, 816 unilateral certification, or other means. Therefore, it is intended 817 to cover multiple CAs. By contrast, a CPS is a statement of a 818 single CA or organization. Its purpose is not to facilitate 819 interoperation (since doing so is the function of a CP). 821 (c) A CPS is generally more detailed than a CP and specifies how 822 the CA meets the requirements specified in the one or more CPs under 823 which it issues certificates. 825 In addition to populating the certificate policies extension with 826 the applicable CP object identifier, a certification authority may 827 include, in certificates it issues, a reference to its certification 828 practice statement. A standard way to do this, using a CP 829 qualifier, is described in Section 3.4. 831 3.6 RELATIONSHIP AMONG CPs, CPSs, AGREEMENTS, AND OTHER DOCUMENTS 833 CPs and CPSs play a central role in documenting the requirements and 834 practices of a PKI. Nonetheless, they are not the only documents 835 relevant to a PKI. For instance, subscriber agreements and relying 836 party agreements play a critical role in allocating responsibilities 837 to subscribers and relying parties relating to the use of 838 certificates and key pairs, and establish the terms and conditions 840 under which certificates are issued, managed, and used. The term 841 subscriber agreement is defined by the PAG as: "An agreement 842 between a CA and a subscriber that establishes the right and 843 obligations of the parties regarding the issuance and management of 844 certificates." [ABA2] The PAG defines a relying party agreement as: 845 "An agreement between a certification authority and relying party 846 that typically establishes the rights and obligations between those 847 parties regarding the verification of digital signatures or other 848 uses of certificates." [ABA2] 850 As mentioned in Section 3.5, a subscriber agreement, relying party 851 agreement, or an agreement that combines subscriber and relying 852 party terms may also serve as a CPS. In other PKIs, however, a 853 subscriber or relying party agreement may incorporate some or all of 854 the terms of a CP or CPS by reference. Yet other PKIs may distill 855 from a CP and/or CPS the terms that are applicable to a subscriber 856 and place such terms in a self-contained subscriber agreement, 857 without incorporating a CP or CPS by reference. They may use the 858 same method to distill relying party terms from a CP and/or CPS and 859 place such terms in a self-contained relying party agreement. 860 Creating such self-contained agreements has the advantage of 861 creating documents that are easier for consumers to review. In some 862 cases, subscribers or relying parties may be deemed to be 863 "consumers" under applicable law, who are subject to certain 864 statutory or regulatory protections. Under the legal systems of 865 civil law countries, incorporating a CP or CPS by reference may not 866 be effective to bind consumers to the terms of an incorporated CP or 867 CPS. 869 CPs and CPSs may be incorporated by reference in other documents, 870 including: 871 * Interoperability agreements (including agreements between CAs for 872 cross-certification, unilateral certification, or other forms of 873 interoperation), 874 * Vendor agreements (under which a PKI vendor agrees to meet 875 standards set forth in a CP or CPS), or 876 * A PDS. 877 See [ABA2] 879 A PDS serves a similar function to a CPS Summary. It is a 880 relatively short document containing only a subset of critical 881 details about a PKI or CA. It may differ from a CPS Summary, 882 however, in that its purpose is to act as a summary of information 883 about the overall nature of the PKI, as opposed to simply a 884 condensed form of the CPS. Moreover, its purpose is to distill 885 information about the PKI, as opposed to protecting security 886 sensitive information contained in an unpublished CPS, although a 887 PDS could also serve that function. 889 Just as writers may wish to refer to a CP or CPS or incorporate it 890 by reference in an agreement or PDS, a CP or CPS may refer to other 891 documents when establishing requirements or making disclosures. For 892 instance, a CP may set requirements for certificate content by 893 referring to an external document setting forth a standard 895 certificate profile. Referencing external documents permits a CP 896 or CPS to impose detailed requirements or make detailed disclosures 897 without having to reprint lengthy provisions from other documents 898 within the CP or CPS. Moreover, referencing a document in a CP or 899 CPS is another useful way of dividing disclosures between public 900 information and security sensitive confidential information (in 901 addition to or as an alternative to publishing a CPS Summary). For 902 example, a PKI may want to publish a CP or CPS, but maintain site 903 construction parameters for CA high security zones as confidential 904 information. In that case, the CP or CPS could reference an 905 external manual or document containing the detailed site 906 construction parameters. 908 Documents that a PKI may wish to refer to in a CP or CPS include: 909 * A security policy, 910 * Training, operational, installation, and user manuals (which may 911 contain operational requirements), 912 * Standards documents that apply to particular aspects of the PKI 913 (such as standards specifying the level of protection offered by any 914 hardware tokens used in the PKI or standards applicable to the site 915 construction), 916 * Key management plans, 917 * Human resource guides and employment manuals (which may describe 918 some aspects of personnel security practices), and 919 * E-mail policies (which may discuss subscriber and relying party 920 responsibilities, as well as the implications of key management, if 921 applicable). 922 See [ABA2] 924 3.7 SET OF PROVISIONS 926 A set of provisions is a collection of practice and/or policy 927 statements, spanning a range of standard topics, for use in 928 expressing a CP or CPS employing the approach described in this 929 framework by covering the topic appearing in Section 5 below, which 930 are described in detail in Section 4 below. 932 A CP can be expressed as a single set of provisions. 934 A CPS can be expressed as a single set of provisions with each 935 component addressing the requirements of one or more certificate 936 policies, or, alternatively, as an organized collection of sets of 937 provisions. For example, a CPS could be expressed as a combination 938 of the following: 940 (a) a list of certificate policies supported by the CPS; 942 (b) for each CP in (a), a set of provisions that contains 943 statements responding to that CP by filling in details not 944 stipulated in that policy or expressly left to the discretion of the 945 CA (in its CPS) ; such statements serve to state how this particular 946 CPS implements the requirements of the particular CP; or 948 (c) a set of provisions that contains statements regarding the 949 certification practices on the CA, regardless of CP. 951 The statements provided in (b) and (c) may augment or refine the 952 stipulations of the applicable CP, but generally must not conflict 953 with any of the stipulations of such CP. In certain cases, however, 954 a policy authority may permit exceptions to the requirements in a 955 CP, because certain compensating controls of the CA are disclosed in 956 its CPS that allow the CA to provide assurances that are equivalent 957 to the assurances provided by CAs that are in full compliance with 958 the CP. 960 This framework outlines the contents of a set of provisions, in 961 terms of nine primary components, as follows: 963 1. Introduction 964 2. Publication and Repository 965 3. Identification and Authentication 966 4. Certificate Life-Cycle Operational Requirements 967 5. Facilities, Management, and Operational Controls 968 6. Technical Security Controls 969 7. Certificate, CRL, and OCSP Profile 970 8. Compliance audit 971 9. Other Business and Legal Matters 973 PKIs can use this simple framework of nine primary components to 974 write a simple CP or CPS. Moreover, a CA can use this same 975 framework to write a subscriber agreement, relying party agreement, 976 or agreement containing subscriber and relying party terms. If a CA 977 uses this simple framework to construct an agreement, it can use 978 paragraph 1 as an introduction or recitals, it can set forth the 979 responsibilities of the parties in paragraphs 2-8, and it can use 980 paragraph 9 to cover the business and legal issues described in more 981 detail in, and using the ordering of, Section 4.9 below (such as 982 representations and warranties, disclaimers, and liability 983 limitations). The ordering of topics in this simple framework and 984 the business and legal matters Section 4.9 is the same as (or 985 similar to) the ordering of topics in a typical software or other 986 technology agreement. Therefore, a PKI can establish a set of core 987 documents (with a CP, CPS, subscriber agreement, and relying party 988 agreement) all having the same structure and ordering of topics, 989 thereby facilitating comparisons and mappings among these documents 990 and among the corresponding documents of other PKIs. 992 This simple framework may also be useful for agreements other than 993 subscriber agreements and relying party agreements. For instance, a 994 CA wishing to outsource certain services to an RA or certificate 995 manufacturing authority (CMA) may find it useful to use this 996 framework as a checklist to write a registration authority agreement 997 or outsourcing agreement. Similarly, two CAs may wish to use this 998 simple framework for the purpose of drafting a cross-certification, 999 unilateral certification, or other interoperability agreement. 1001 In short, the primary components of the simple framework 1002 (specified above) may meet the needs of drafters of short CPs, CPSs, 1003 subscriber agreements, and relying party agreements. Nonetheless, 1004 this framework is extensible, and its coverage of the nine 1005 components is flexible enough to meet the needs of drafters of 1006 comprehensive CPs and CPSs. Specifically, components appearing above 1007 can be further divided into subcomponents, and a subcomponent may 1008 comprise multiple elements. Section 4 provides a more detailed 1009 description of the contents of the above components, and their 1010 subcomponents. Drafters of CPs and CPSs are permitted to add 1011 additional levels of subcomponents below the subcomponents described 1012 in Section 4 for the purpose of meeting the needs of the drafter's 1013 particular PKI. 1015 4. CONTENTS OF A SET OF PROVISIONS 1017 This section expands upon the contents of the simple framework of 1018 provisions, as introduced in Section 3.7. The topics identified in 1019 this section are, consequently, candidate topics for inclusion in a 1020 detailed CP or CPS. 1022 While many topics are identified, it is not necessary for a CP or a 1023 CPS to include a concrete statement for every such topic. Rather, a 1024 particular CP or CPS may state "no stipulation" for a component, 1025 subcomponent, or element on which the particular CP or CPS imposes 1026 no requirements or makes no disclosure. In this sense, the list of 1027 topics can be considered a checklist of topics for consideration by 1028 the CP or CPS writer. 1030 It is recommended that each and every component and subcomponent be 1031 included in a CP or CPS, even if there is "no stipulation"; this 1032 will indicate to the reader that a conscious decision was made to 1033 include or exclude a provision concerning that topic. This drafting 1034 style protects against inadvertent omission of a topic, while 1035 facilitating comparison of different certificate policies or CPSs, 1036 e.g., when making policy mapping decisions. 1038 In a CP, it is possible to leave certain components, subcomponents, 1039 and/or elements unspecified, and to stipulate that the required 1040 information will be indicated in a policy qualifier, or the document 1041 to which a policy qualifier points. Such CPs can be considered 1042 parameterized definitions. The set of provisions should reference 1043 or define the required policy qualifier types and should specify any 1044 applicable default values. 1046 4.1 INTRODUCTION 1048 This component identifies and introduces the set of provisions, and 1049 indicates the types of entities and applications for which the 1050 document (either the CP or the CPS being written) is targeted. 1052 4.1.1 Overview 1054 This subcomponent provides a general introduction to the document 1055 being written. This subcomponent can also be used to provide a 1057 synopsis of the PKI to which the CP or CPS applies. For example, 1058 it may set out different levels of assurance provided by 1059 certificates within the PKI. Depending on the complexity and scope 1060 of the particular PKI, a diagrammatic representation of the PKI 1061 might be useful here. 1063 4.1.2 Document Name and Identification 1065 This subcomponent provides any applicable names or other 1066 identifiers, including ASN.1 object identifiers, for the document. 1067 An example of such a document name would be the US Federal 1068 Government Policy for Secure E-mail. 1070 4.1.3 PKI Participants 1072 This subcomponent describes the identity or types of entities that 1073 fill the roles of participants within a PKI, namely: 1075 * Certification authorities, i.e., the entities that issue 1076 certificates. A CA is the issuing CA with respect to the 1077 certificates it issues and is the subject CA with respect to the CA 1078 certificate issued to it. CAs may be organized in a hierarchy in 1079 which an organization's CA issues certificates to CAs operated by 1080 subordinate organizations, such as a branch, division, or department 1081 within a larger organization. 1083 * Registration authorities, i.e., the entities that establishment 1084 enrollment procedures for end-user certificate applicants, perform 1085 identification and authentication of certificate applicants, 1086 initiate or pass along revocation requests for certificates, and 1087 approve applications for renewal or re-keying certificates on behalf 1088 of a CA. Subordinate organizations within a larger organization can 1089 act as RAs for the CA serving the entire organization, but RAs may 1090 also be external to the CA. 1092 * Subscribers. Examples of subscribers who receive certificates 1093 from a CA include employees of an organization with its own CA, 1094 banking or brokerage customers, organizations hosting e-commerce 1095 sites, organizations participating in a business-to-business 1096 exchange, and members of the public receiving certificates from a CA 1097 issuing certificates to the public at large. 1099 * Relying parties. Examples of relying parties include employees of 1100 an organization having its own CA who receive digitally signed e- 1101 mails from other employees, persons buying goods and services from 1102 e-commerce sites, organizations participating in a business-to- 1103 business exchange who receive bids or orders from other 1104 participating organizations, and individuals and organizations doing 1105 business with subscribers who have received their certificates from 1106 a CA issuing certificates to the public. Relying parties may or may 1107 not also be subscribers within a given PKI. 1109 * Other participants, such as certificate manufacturing 1110 authorities, providers of repository services, and other entities 1111 providing PKI-related services. 1113 4.1.4 Certificate usage 1115 This subcomponent contains: 1117 * A list or the types of applications for which the issued 1118 certificates are suitable, such as electronic mail, retail 1119 transactions, contracts, and a travel order, and/or 1121 * A list or the types of applications for which use of the issued 1122 certificates is prohibited. 1124 In the case of a CP or CPS describing different levels of assurance, 1125 this subcomponent can describe applications or types of applications 1126 that are appropriate or inappropriate for the different levels of 1127 assurance. 1129 4.1.5 Policy Administration 1131 This subcomponent includes the name and mailing address of the 1132 organization that is responsible for the drafting, registering, 1133 maintaining, and updating of this CP or CPS. It also includes the 1134 name, electronic mail address, telephone number, and fax number of a 1135 contact person. As an alternative to naming an actual person, the 1136 document may name a title or role, an e-mail alias, and other 1137 generalized contact information. In some cases, the organization may 1138 state that its contact person, alone or in combination with others, 1139 is available to answer questions about the document. 1141 Moreover, when a formal or informal policy authority is responsible 1142 for determining whether a CA should be allowed to operate within or 1143 interoperate with a PKI, it may wish to approve the CPS of the CA as 1144 being suitable for the policy authority's CP. If so, this 1145 subcomponent can include the name or title, electronic mail address 1146 (or alias), telephone number, fax number, and other generalized 1147 information of the entity in charge of making such a determination. 1148 Finally, in this case, this subcomponent also includes the 1149 procedures by which this determination is made. 1151 4.1.6 Definitions and acronyms 1152 This subcomponent contains a list of definitions for defined terms 1153 used within the document, as well as a list of acronyms in the 1154 document and their meanings. 1156 4.2 PUBLICATION AND REPOSITORY RESPONSIBILITIES 1158 This component contains any applicable provisions regarding: 1159 * An identification of the entity or entities that operate 1160 repositories within the PKI, such as a CA, certificate manufacturing 1161 authority, or independent repository service provider; 1163 *The responsibility of a PKI participant to publish information 1164 regarding its practices, certificates, and the current status of 1165 such certificates, which may include the responsibilities of making 1166 the CP or CPS publicly available using various mechanisms and of 1168 identifying components, subcomponents, and elements of such 1169 documents that exist but are not made publicly available, for 1170 instance, security controls, clearance procedures, or trade secret 1171 information due to their sensitivity; 1173 * When information must be published and the frequency of 1174 publication; and 1176 * Access control on published information objects including CPs, 1177 CPS, certificates, certificate status, and CRLs. 1179 4.3 IDENTIFICATION AND AUTHENTICATION 1181 This component describes the procedures used to authenticate the 1182 identity and/or other attributes of an end-user certificate 1183 applicant to a CA or RA prior to certificate issuance. In addition, 1184 the component sets forth the procedures for authenticating the 1185 identity and the criteria for accepting applicants of entities 1186 seeking to become CAs, RAs, or other entities operating in or 1187 interoperating with a PKI. It also describes how parties requesting 1188 re-key or revocation are authenticated. This component also 1189 addresses naming practices, including the recognition of trademark 1191 rights in certain names. 1193 4.3.1 Naming 1195 This subcomponent includes the following elements regarding naming 1196 and identification of the subscribers: 1198 * Types of names assigned to the subject, such as X.500 1199 distinguished names; RFC-822 names; and X.400 names; 1201 * Whether names have to be meaningful or not;(3) 1203 * Whether or not subscribers can be anonymous or pseudonymous, and, 1204 if they can, what names are assigned to or can be used by anonymous 1205 subscribers; 1207 * Rules for interpreting various name forms, such as the X.500 1208 standard and RFC-822; 1210 * Whether names have to be unique; and 1212 * Recognition, authentication, and role of trademarks. 1214 4.3.2 Initial Identity Validation 1216 This subcomponent contains the following elements for the 1217 identification and authentication procedures for the initial 1218 registration for each subject type (CA, RA, subscriber, or other 1219 participant): 1221 * If and how the subject must prove possession of the companion 1222 private key for the public key being registered, for example, a 1223 digital signature in the certificate request message;(4) 1225 * Identification and authentication requirements for 1226 organizational identity of subscriber or participant (CA; RA; 1227 subscriber (in the case of certificates issued to organizations or 1228 devices controlled by an organization), or other participant), for 1229 example, consulting the database of a service that identifies 1230 organizations or inspecting an organization's articles of 1231 incorporation; 1233 * Identification and authentication requirements for an individual 1234 subscriber or a person acting on behalf of an organizational 1235 subscriber or participant (CA, RA, in the case of certificates 1236 issued to organizations or devices controlled by an organization, 1237 the subscriber, or other participant),(5) including: 1239 * Type of documentation and/or number of identification credentials 1240 required; 1241 * How a CA or RA authenticates the identity of the organization or 1242 individual based on the documentation or credentials provided; 1243 * If the individual must present personally to the authenticating CA 1244 or RA; 1245 * How an individual as an organizational person is authenticated, 1246 such as by reference to duly signed authorization documents or a 1247 corporate identification badge. 1249 * List of subscriber information that is not verified (called "non- 1250 verified subscriber information") during the initial registration; 1252 * Validation of authority involves a determination of whether a 1253 person has specific rights, entitlements, or permissions, including 1254 the permission to act on behalf of an organization to obtain a 1255 certificate; and 1257 * In the case of applications by a CA wishing to operate within, or 1258 interoperate with, a PKI, this subcomponent contains the criteria by 1259 which a PKI, CA, or policy authority determines whether or not the 1260 CA is suitable for such operations or interoperation. Such 1261 interoperation may include cross-certification, unilateral 1262 certification, or other forms of interoperation. 1264 4.3.3 Identification and Authentication for Re-key Requests 1266 This subcomponent addresses the following elements for the 1267 identification and authentication procedures for re-key for each 1268 subject type (CA, RA, subscriber, and other participants): 1270 * Identification and authentication requirements for routine re-key, 1271 such as a re-key request that contains the new key and is signed 1272 using the current valid key; and 1274 * Identification and authentication requirements for re-key after 1275 certificate revocation. One example is the use of the same process 1276 as the initial identity validation. 1278 4.3.4 Identification and Authentication for Revocation Requests 1280 This subcomponent describes the identification and authentication 1281 procedures for a revocation request by each subject type (CA, RA, 1282 subscriber, and other participant). Examples include a revocation 1283 request digitally signed with the private key whose companion public 1284 key needs to be revoked and a digitally signed request by the RA. 1286 4.4 CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS 1288 This component is used to specify requirements imposed upon issuing 1289 CA, subject CAs, RAs, subscribers, or other participants with 1290 respect to the life-cycle of certificate. 1292 Within each subcomponent, separate consideration may need to be 1293 given to subject CAs, RAs, subscribers, and other participants. 1295 4.4.1 Certificate Application 1297 This subcomponent is used to address the following requirements 1298 regarding subject certificate application: 1300 * Who can submit a certificate application, such as a certificate 1301 subject or the RA; and 1303 * Enrollment process used by subjects to submit certificate 1304 applications and responsibilities in connection with this process. 1305 An example of this process is where the subject generates the key 1306 pair and sends a certificate request to the RA. The RA validates 1307 and signs the request and sends it to the CA. A CA or RA may have 1308 the responsibility to establish an enrollment process in order to 1309 receive certificate applications. Likewise, certificate applicants 1310 may have the responsibility to provide accurate information on their 1311 certificate applications. 1313 4.4.2 Certificate Application Processing 1315 This subcomponent is used to describe the procedure for processing 1316 certificate applications. For example, the issuing CA and RA may 1317 perform identification and authentication procedures to validate the 1318 certificate application. Following such steps, the CA or RA will 1319 either approve or reject the certificate application, perhaps upon 1320 the application of certain criteria. Finally, this subcomponent 1321 sets for the time in which a CA and/or RA must act on and process a 1322 certificate application. 1324 4.4.3 Certificate Issuance 1326 This subcomponent is used to describe the following certificate 1327 issuance related elements: 1329 * Actions performed by the CA during the issuance of the 1330 certificate, for example a procedure whereby the CA validates the RA 1331 signature and RA authority and generates a certificate; and 1333 * Notification mechanisms, if any, used by the CA to notify the 1334 subscriber of the issuance of the certificate; an example is a 1335 procedure under which the CA e-mails the certificate to the 1336 subscriber or the RA or e-mails information permitting the 1337 subscriber to download the certificate from a web site. 1339 4.4.4 Certificate Acceptance 1341 This subcomponent addresses the following: 1343 * The conduct of an applicant that will be deemed to constitute 1344 acceptance of the certificate. Such conduct may include affirmative 1345 steps to indicate acceptance, actions implying acceptance, or a 1346 failure to object to the certificate or its content. For instance, 1347 acceptance may be deemed to occur if the CA does not receive any 1348 notice from the subscriber within a certain time period; a 1349 subscriber may send a signed message accepting the certificate; or a 1350 subscriber may send a signed message rejecting the certificate where 1351 the message includes the reason for rejection and identifies the 1352 fields in the certificate that are incorrect or incomplete. 1354 * Publication of the certificate by the CA. For example, the CA may 1355 post the certificate to an X.500 or LDAP repository. 1357 * Notification of certificate issuance by the CA to other entities. 1358 As an example, the CA may send the certificate to the RA. 1360 4.4.5 Key Pair and Certificate Usage 1362 This subcomponent is used to describe the responsibilities relating 1363 to the use of keys and certificates, including: 1365 * Subscriber responsibilities relating to use of the subscriber's 1366 private key and certificate. For example, the subscriber may be 1367 required to use a private key and certificate only for appropriate 1368 applications as set forth in the CP and consistent with applicable 1369 certificate content (e.g., key usage field), use of a private key 1370 and certificate are subject to the terms of the subscriber 1371 agreement, the use of a private key is permitted only after the 1372 subscriber has accepted the corresponding certificate, or subscriber 1373 must discontinue use of the private key following expiration or 1374 revocation of the certificate. 1376 * Relying party responsibilities relating to the use of a 1377 subscriber's public key and certificate. For instance, a relying 1378 party may be obligated to rely on certificates only for appropriate 1379 applications as set forth in the CP and consistent with applicable 1380 certificate content (e.g., key usage field), successfully perform 1381 public key operations as a condition of relying on a certificate, 1382 responsibility to check the status of certificate using one of the 1383 required or permitted mechanisms set forth in the CP/CPS (see 1384 Section 4.4.9 below), and assent to the terms of the applicable 1385 relying party agreement as a condition of relying on the 1386 certificate. 1388 4.4.6 Certificate Renewal 1390 This subcomponent is used to describe the following elements related 1391 to certificate renewal. Certificate renewal means issuance of a new 1392 certificate to the subscriber without changing the subscriber or 1393 other participant's public key or any other information in the 1394 certificate: 1396 * Circumstances under which certificate renewal takes place, such as 1397 where the certificate life has expired, but the policy permits the 1398 same key pair to be reused; 1400 * Who may request certificate renewal, for instance, the subscriber, 1401 RA, or the CA may automatically renew an end-user subscriber 1402 certificate; 1404 * A CA or RA's procedures to process renewal requests to issue the 1405 new certificate, for example, the use of a token, such as a 1406 password, to re-authenticate the subscriber, or procedures that are 1407 the same as the initial certificate issuance; 1409 * Notification of the new certificate to the subscriber; 1411 * Conduct constituting acceptance of the certificate; 1413 * Publication of the certificate by the CA; and 1415 * Notification of certificate issuance by the CA to other entities. 1417 4.4.7 Certificate Re-key 1419 This subcomponent is used to describe the following elements related 1420 to a subscriber or other participant generating a new key pair and 1421 applying for the issuance of new certificate that certifies the new 1422 public key: 1424 * Circumstances under which certificate re-key can or must take 1425 place, such as after a certificate is revoked for the reasons of key 1426 compromise or after a certificate has expired and the usage period 1427 of the key pair has also expired; 1429 * Who may request certificate re-key, for example, the subscriber; 1431 * A CA or RA's procedures to process re-keying requests to issue the 1432 new certificate, such as procedures that are the same as the initial 1433 certificate issuance; 1435 * Notification of the new certificate to the subscriber; 1437 * Conduct constituting acceptance of the certificate; 1439 * Publication of the certificate by the CA; and 1441 * Notification of certificate issuance by the CA to other 1442 entities. 1444 4.4.8 Certificate Modification 1446 This subcomponent is used to describe the following elements related 1447 to issuance of a new certificate (6) due to changes in the 1448 information in the certificate other than the subscriber public key: 1450 * Circumstances under which certificate modification can take 1451 place, such as name change, role change, reorganization resulting a 1452 change in the DN; 1454 * Who may request certificate modification, for instance, 1455 subscribers, human resources personnel, or the RA; 1457 * A CA or RA's procedures to process modification requests to issue 1458 the new certificate, such as procedures that are the same as the 1459 initial certificate issuance; 1461 * Notification of the new certificate to the subscriber; 1463 * Conduct constituting acceptance of the certificate; 1465 * Publication of the certificate by the CA; and 1467 * Notification of certificate issuance by the CA to other entities. 1469 4.4.9 Certificate Revocation and Suspension 1471 This subcomponent addresses the following: 1473 * Circumstances under which a certificate may be and circumstances 1474 under which it must be revoked, for instance, in cases of subscriber 1475 employment termination, loss of cryptographic token, or suspected 1476 compromise of the private key; 1478 * Who can request the revocation of the participant's certificate, 1479 for example, the subscriber, RA, or CA in the case of an end-user 1480 subscriber certificate. 1482 * Procedures used for certificate revocation request, such as a 1483 digitally signed message from the RA, a digitally signed message 1484 from the subscriber, or a phone call from the RA; 1486 * The grace period available to the subscriber, within which the 1487 subscriber must make a revocation request; 1489 * The time within which CA must process the revocation request; 1491 * The mechanisms, if any, that a relying party may use or must use 1492 in order to check the status of certificates on which they wish to 1493 rely; 1495 * If a CRL mechanism is used, the issuance frequency; 1497 * If a CRL mechanism is used, maximum latency between the generation 1498 of CRLs and posting of the CRLs to the repository (in other words, 1499 the maximum amount of processing- and communication-related delays 1500 in posting CRLs to the repository after the CRLs are generated); 1502 * On-line revocation/status checking availability, for instance, 1503 OCSP and a web site to which status inquiries can be submitted; 1505 * Requirements on relying parties to perform on-line 1506 revocation/status checks; 1508 * Other forms of revocation advertisements available; 1510 * Any variations on the above stipulations when the suspension or 1511 revocation is the result of private key compromise (as opposed to 1512 other reasons for suspension or revocation). 1514 * Circumstances under which a certificate may be suspended; 1516 * Who can request the suspension of a certificate, for example, the 1517 subscriber, human resources personnel, a supervisor of the 1518 subscriber, or the RA in the case of an end-user subscriber 1519 certificate; 1521 * Procedures to request certificate suspension, such as a digitally 1522 signed message from subscriber or RA, or a phone call from RA; and 1524 * How long the suspension may last. 1526 4.4.10 Certificate Status Services 1528 This subcomponent addresses the certificate status checking services 1529 available to the relying parties, including: 1531 * The operational characteristics of certificate status checking 1532 services; 1534 * The availability of such services, and any applicable policies on 1535 unavailability; and 1537 * Any optional features of such services. 1539 4.4.11 End of Subscription 1541 This subcomponent addresses procedures used by the subscriber to end 1542 subscription to the CA services, including: 1544 * The revocation of certificates at the end of subscription (which 1545 may differ, depending on whether the end of subscription was due to 1546 expiration of the certificate or termination of the service). 1548 4.4.12 Key Escrow and Recovery 1550 This subcomponent contains the following elements to identify the 1551 policies and practices relating to the escrowing, and/or recovery of 1552 private keys where private key escrow services are available 1553 (through the CA or other trusted third parties): 1555 * Identification of the document containing private key escrow and 1556 recovery policies and practices or a listing of the such policies 1557 and practices; and 1559 * Identification of the document containing session key 1560 encapsulation and recovery policies and practices or a listing of 1561 such policies and practices. 1563 4.5 MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS 1565 This component describes non-technical security controls (that is, 1566 physical, procedural, and personnel controls) used by the issuing CA 1567 to perform securely the functions of key generation, subject 1568 authentication, certificate issuance, certificate revocation, audit, 1569 and archival. 1571 This component can also be used to define non-technical security 1572 controls on repository, subject CAs, RAs, subscribers, and other 1573 participants. The non-technical security controls for the subject 1574 CAs, RAs, subscribers, and other participants could be the same, 1575 similar, or very different. 1577 These non-technical security controls are critical to trusting the 1578 certificates since lack of security may compromise CA operations 1579 resulting, for example, in the creation of certificates or CRLs with 1580 erroneous information or in the compromise of the CA private key. 1582 Within each subcomponent, separate consideration will, in general, 1583 need to be given to each entity type, that is, issuing CA, 1584 repository, subject CAs, RAs, subscribers, and other participants. 1586 4.5.1 Physical Security Controls 1588 In this subcomponent, the physical controls on the facility housing 1589 the entity systems are described. Topics addressed may include: 1591 * Site location and construction, such as the construction 1592 requirements for high-security zones and the use of locked rooms, 1593 cages, safes, and cabinets; 1595 * Physical access, i.e., mechanisms to control access from one area 1596 of the facility to another or access into high-security zones, such 1597 as locating CA operations in a secure computer room monitored by 1598 guards or security alarms and requiring movement from zone to zone 1599 to be accomplished using a token, biometric readers, and/or access 1600 control lists; 1602 * Power and air conditioning; 1604 * Water exposures; 1606 * Fire prevention and protection; 1608 * Media storage, for example, requiring the storage of backup media 1609 in a separate location that is physically secure and protected from 1610 fire and water damages; 1612 * Waste disposal; and 1614 * Off-site backup. 1616 4.5.2 Procedural Controls 1618 In this subcomponent, requirements for recognizing trusted roles are 1619 described, together with the responsibilities for each role. 1620 Examples of trusted roles include system administrators, security 1621 officers, and system auditors. 1623 For each task identified for each role, it should also be stated how 1624 many individuals are required to perform the task (n out m rule). 1625 Identification and authentication requirements for each role may 1626 also be defined. 1628 This components also includes the separation of duties in terms of 1629 the roles that cannot be performed by the same individuals. 1631 4.5.3 Personnel Security Controls 1633 This subcomponent addresses the following: 1635 * Qualifications, experience, and clearances that personnel must 1636 have as a condition of filling trusted roles or other important 1637 roles. Examples include credentials, job experiences, and official 1638 government clearances that candidates for these positions must have 1639 before being hired; 1641 * Background checks and clearance procedures that are required in 1642 connection with the hiring of personnel filling trusted roles or 1643 perhaps other important roles, such as requirements that trusted 1644 personnel undergo checks of their criminal records, references, and 1645 additional clearances that a participant undertakes after a decision 1646 has been made to hire a particular person; 1648 * Training requirements and training procedures for each role 1649 following the hiring of personnel; 1651 * Any retraining period and retraining procedures for each role 1652 after completion of initial training; 1654 * Frequency and sequence for job rotation among various roles; 1656 * Sanctions against personnel for unauthorized actions, 1657 unauthorized use of authority, and unauthorized use of entity 1659 systems for the purpose of imposing accountability on a 1660 participant's personnel; 1662 * Controls on personnel that are independent contractors rather than 1663 employees of the entity; examples include: 1665 - Bonding requirements on contract personnel; 1666 - Contractual requirements including indemnification for damages due 1667 to the actions of the contractor personnel; 1668 - Audit and monitoring of contractor personnel; and 1669 - Other controls on contracting personnel. 1671 * Documentation to be supplied to personnel, during initial 1672 training, retraining, or otherwise. 1674 4.5.4 Audit Logging Procedures 1676 This subcomponent is used to describe event logging and audit 1677 systems, implemented for the purpose of maintaining a secure 1678 environment. Elements include the following: 1680 * Types of events recorded, such as certificate lifecycle 1681 operations, attempts to access the system, and requests made to the 1682 system; 1684 * Frequency with which audit logs are processed or archived, for 1685 example, weekly, following an alarm or anomalous event, or when ever 1686 the audit log is n% full; 1688 * Period for which audit logs are kept; 1690 * Protection of audit logs: 1692 - Who can view audit logs, for example only the audit administrator; 1693 - Protection against modification of audit log, for instance a 1694 requirement that no one may modify or delete the audit records or 1695 that only an audit administrator may delete the audit file as part 1696 of rotating the audit file; and 1697 - Protection against deletion of audit log. 1699 * Audit log back up procedures; 1701 * Whether the audit log accumulation system is internal or external 1702 to the entity; 1704 * Whether the subject who caused an audit event to occur is notified 1705 of the audit action; and 1707 * Vulnerability assessments, for example, where audit data is run 1708 through a tool that identifies potential attempts to breach the 1709 security of the system. 1711 4.5.5 Records Archival 1713 This subcomponent is used to describe general records archival (or 1715 records retention) policies, including the following: 1717 * Types of records that are archived, for example, all audit data, 1718 certificate application information, and documentation supporting 1719 certificate applications; 1721 * Retention period for archive; 1723 * Protection of archive: 1725 - Who can view the archive, for example, a requirement that only the 1726 audit administrator may view the archive; 1727 - Protection against modification of archive, such as securely 1728 storing the data on a write once medium; 1729 - Protection against deletion of archive; 1730 - Protection against deterioration of the media on which the archive 1731 is stored, such as a requirement for data to be migrated 1732 periodically to fresh media; and 1733 - Protection against obsolescence of hardware, operating systems, and 1734 other software, by, for example, retaining as part of the archive the 1735 hardware, operating systems, and/or other software in order to permit 1736 access to and use of archived records over time. 1738 * Archive backup procedures; 1740 * Requirements for time-stamping of records; 1742 * Whether the archive collection system is internal or external; and 1744 * Procedures to obtain and verify archive information, such as a 1745 requirement that two separate copies of the archive data be kept 1746 under the control of two persons, and that the two copies be 1747 compared in order to ensure that the archive information is 1748 accurate. 1750 4.5.6 Key Changeover 1752 This subcomponent describes the procedures to provide a new public 1753 key to a CA's users following a re-key by the CA. These procedures 1754 may be the same as the procedure for providing the current key. 1755 Also, the new key may be certified in a certificate signed using the 1756 old key. 1758 4.5.7 Compromise and Disaster Recovery 1760 This subcomponent describes requirements relating to notification 1761 and recovery procedures in the event of compromise or disaster. 1762 Each of the following may need to be addressed separately: 1764 * Identification or listing of the applicable incident and 1765 compromise reporting and handling procedures. 1767 * The recovery procedures used if computing resources, software, 1768 and/or data are corrupted or suspected to be corrupted. These 1769 procedures describe how a secure environment is reestablished, which 1771 certificates are revoked, whether the entity key is revoked, how 1772 the new entity public key is provided to the users, and how the 1773 subjects are re-certified. 1775 * The recovery procedures used if the entity key is compromised. 1776 These procedures describe how a secure environment is reestablished, 1777 how the new entity public key is provided to the users, and how the 1778 subjects are re-certified. 1780 * The entity's capabilities to ensure business continuity following 1781 a natural or other disaster. Such capabilities may include the 1782 availability of a remote hot-site at which operations may be 1783 recovered. They may also include procedures for securing its 1784 facility during the period of time following a natural or other 1785 disaster and before a secure environment is reestablished either at 1786 the original site or at a remote site. For example, procedures to 1787 protect against theft of sensitive materials from an earthquake- 1788 damaged site. 1790 4.5.8 CA or RA Termination 1792 This subcomponent describes requirements relating to procedures for 1793 termination and for termination notification of a CA or RA, 1794 including the identity of the custodian of CA and RA archival 1795 records. 1797 4.6 TECHNICAL SECURITY CONTROLS 1799 This component is used to define the security measures taken by the 1800 issuing CA to protect its cryptographic keys and activation data 1801 (e.g., PINs, passwords, or manually-held key shares). This 1802 component may also be used to impose constraints on repositories, 1803 subject CAs, subscribers, and other participants to protect their 1804 private keys, activation data for their private keys, and critical 1805 security parameters. Secure key management is critical to ensure 1806 that all secret and private keys and activation data are protected 1807 and used only by authorized personnel. 1809 This component also describes other technical security controls used 1810 by the issuing CA to perform securely the functions of key 1811 generation, user authentication, certificate registration, 1812 certificate revocation, audit, and archival. Technical controls 1813 include life-cycle security controls (including software development 1814 environment security, trusted software development methodology) and 1815 operational security controls. 1817 This component can also be used to define other technical security 1818 controls on repositories, subject CAs, RAs, subscribers, and other 1819 participants. 1821 4.6.1 Key Pair Generation and Installation 1823 Key pair generation and installation need to be considered for the 1825 issuing CA, repositories, subject CAs, RAs, and subscribers. For 1826 each of these types of entities, the following questions 1827 potentially need to be answered: 1829 1. Who generates the entity public, private key pair? Possibilities 1830 include the subscriber, RA, or CA. Also, how is the key generation 1831 performed? Is the key generation performed in hardware or software? 1833 2. How is the private key provided securely to the entity? 1835 Possibilities include a situation where the entity has generated it 1836 and therefore already has it, handing the entity the private key 1837 physically, mailing a token containing the private key securely, or 1838 delivering it in a SSL session. 1840 3. How is the entity's public key provided securely to the 1841 certification authority? Some possibilities are in an online SSL 1842 session or in a message signed by the RA. 1844 4. In the case of issuing CAs, how is the CA's public key provided 1845 securely to potential relying parties? Possibilities include 1846 handing the public key to the relying party securely in person, 1847 physically mailing a copy securely to the relying party, or 1848 delivering it in a SSL session. 1850 5. What are the key sizes? Examples include a 1,024 bit RSA modulus 1851 and a 1,024 bit DSA large prime. 1853 6. Who generates the public key parameters, and is the quality of 1854 the parameters checked during key generation? 1856 7. For what purposes may the key be used, or for what purposes 1857 should usage of the key be restricted? For X.509 certificates, 1858 these purposes should map to the key usage flags in X.509 Version 3 1859 certificates. 1861 4.6.2 Private Key Protection and Cryptographic Module Engineering 1862 Controls 1864 Requirements for private key protection and cryptographic module 1865 need to be considered for the issuing CA, repositories, subject CAs, 1866 RAs, and subscribers. For each of these types of entity, the 1867 following questions potentially need to be answered: 1869 1. What standards, if any, are required for the cryptographic 1870 module used to generate the keys? A cryptographic module can be 1871 composed of hardware, software, firmware, or any combination of 1872 them. For example, are the keys certified by the infrastructure 1873 required to be generated using modules compliant with the US FIPS 1874 140-1? If so, what is the required FIPS 140-1 level of the module? 1875 Are there any other engineering or other controls relating to a 1876 cryptographic module, such as the identification of the 1877 cryptographic module boundary, input/output, roles and services, 1878 finite state machine, physical security, software security, 1879 operating system security, algorithm compliance, electromagnetic 1881 compatibility, and self tests. 1883 2. Is the private key under n out of m multi-person control?(7) 1884 If yes, provide n and m (two person control is a special case of n 1885 out of m, where n = m = 2)? 1887 3. Is the private key escrowed?(8) If so, who is the escrow agent, 1888 what form is the key escrowed in (examples include plaintext, 1889 encrypted, split key), and what are the security controls on the 1890 escrow system? 1892 4. Is the private key backed up? If so, who is the backup agent, 1893 what form is the key backed up in (examples include plaintext, 1894 encrypted, split key), and what are the security controls on the 1895 backup system? 1897 5. Is the private key archived? If so, who is the archival agent, 1898 what form is the key archived in (examples include plaintext, 1899 encrypted, split key), and what are the security controls on the 1900 archival system? 1902 6. Under what circumstances, if any, can a private key be 1903 transferred into or from a cryptographic module? Who is permitted 1904 to perform such a transfer operation? In what form is the private 1905 key during the transfer (i.e., plaintext, encrypted, or split key)? 1907 7. How is the private key stored in the module (i.e., plaintext, 1908 encrypted, or split key)? 1910 8. Who can activate (use) the private key? What actions must be 1911 performed to activate the private key (e.g., login, power on, supply 1912 PIN, insert token/key, automatic, etc.)? Once the key is activated, 1913 is the key active for an indefinite period, active for one time, or 1914 active for a defined time period? 1916 9. Who can deactivate the private key and how? Examples of methods 1917 of deactivating private keys include logging out, turning the power 1918 off, removing the token/key, automatic deactivation, and time 1919 expiration. 1921 10. Who can destroy the private key and how? Examples of methods of 1922 destroying private keys include token surrender, token destruction, 1923 and overwriting the key. 1925 11. Provide the capabilities of the cryptographic module in the 1926 following areas: identification of the cryptographic module 1927 boundary, input/output, roles and services, finite state machine, 1928 physical security, software security, operating system security, 1929 algorithm compliance, electromagnetic compatibility, and self tests. 1930 Capability may be expressed through reference to compliance with a 1931 standard such as U.S. FIPS 140-1, associated level, and rating. 1933 4.6.3 Other Aspects of Key Pair Management 1935 Other aspects of key management need to be considered for the 1936 issuing CA, repositories, subject CAs, RAs, subscribers, and other 1937 participants. For each of these types of entity, the following 1938 questions potentially need to be answered: 1940 1. Is the public key archived? If so, who is the archival agent and 1941 what are the security controls on the archival system? Also, what 1942 software and hardware need to be preserved as part of the archive to 1943 permit use of the public key over time? Note: this subcomponent is 1944 not limited to requiring or describing the use of digital signatures 1945 with archival data, but rather can address integrity controls other 1946 than digital signatures when an archive requires tamper protection. 1947 Digital signatures do not provide tamper protection or protect the 1948 integrity of data; they merely verify data integrity. Moreover, the 1949 archival period may be greater than the cryptanalysis period for 1950 the public key needed to verify any digital signature applied to 1951 archival data. 1953 2. What is the operational period of the certificates issued to the 1954 subscriber. What are the usage periods, or active lifetimes, for 1955 the subscriber's key pair? 1957 4.6.4 Activation Data 1959 Activation data refers to data values other than whole private keys 1960 that are required to operate private keys or cryptographic modules 1961 containing private keys, such as a PIN, passphrase, or portions of a 1962 private key used in a key-splitting scheme. Protection of 1963 activation data prevents unauthorized use of the private key, and 1964 potentially needs to be considered for the issuing CA, subject CAs, 1965 RAs, and subscribers. Such consideration potentially needs to 1966 address the entire life-cycle of the activation data from generation 1967 through archival and destruction. For each of the entity types 1968 (issuing CA, repository, subject CA, RA, subscriber, and other 1969 participants) all of the questions listed in 4.6.1 through 4.6.3 1970 potentially need to be answered with respect to activation data 1971 rather than with respect to keys. 1973 4.6.5 Computer Security Controls 1975 This subcomponent is used to describe computer security controls 1976 such as: use of the trusted computing base concept, discretionary 1977 access control, labels, mandatory access controls, object reuse, 1978 audit, identification and authentication, trusted path, security 1979 testing, and penetration testing. Product assurance may also be 1980 addressed. 1982 A computer security rating for computer systems may be required. 1983 The rating could be based, for example, on the Trusted System 1984 Evaluation Criteria (TCSEC), Canadian Trusted Products Evaluation 1985 Criteria, European Information Technology Security Evaluation 1986 Criteria (ITSEC), or the Common Criteria for Information Technology 1987 Security Evaluation, ISO/IEC 15408:1999. This subcomponent can also 1989 address requirements for product evaluation analysis, testing, 1990 profiling, product certification, and/or product accreditation 1991 related activity undertaken. 1993 4.6.6 Life Cycle Security Controls 1995 This subcomponent addresses system development controls and 1996 security management controls. 1998 System development controls include development environment 1999 security, development personnel security, configuration management 2001 security during product maintenance, software engineering practices, 2002 software development methodology, modularity, layering, use of 2003 failsafe design and implementation techniques (e.g., defensive 2004 programming) and development facility security. 2006 Security management controls include execution of tools and 2007 procedures to ensure that the operational systems and networks 2008 adhere to configured security. These tools and procedures include 2009 checking the integrity of the security software, firmware, and 2010 hardware to ensure their correct operation. 2012 This subcomponent can also address life-cycle security ratings 2013 based, for example, on the Trusted Software Development Methodology 2014 (TSDM) level IV and V, independent life-cycle security controls 2015 audit, and the Software Engineering Institute's Capability Maturity 2016 Model (SEI-CMM). 2018 4.6.7 Network Security Controls 2020 This subcomponent addresses network security related controls, 2021 including firewalls. 2023 4.6.8 Time-stamping 2025 This subcomponent addresses requirements or practices relating to 2026 the use of timestamps on various data. It may also discuss whether 2027 or not the time-stamping application must use a trusted time source. 2029 4.7 CERTIFICATE AND CRL PROFILES 2031 This component is used to specify the certificate format and, if 2032 CRLs and/or OCSP are used, the CRL and/or OCSP format. This 2033 includes information on profiles, versions, and extensions used. 2035 4.7.1 Certificate Profile 2037 This subcomponent addresses such topics as the following 2039 (potentially by reference to a separate profile definition, such as 2040 the one defined in IETF PKIX RFC 2459): 2042 * Version number(s) supported; 2044 * Certificate extensions populated and their criticality; 2046 * Cryptographic algorithm object identifiers; 2048 * Name forms used for the CA, RA, and subscriber names; 2050 * Name constraints used and the name forms used in the name 2051 constraints; 2053 * Applicable CP OID(s); 2055 * Usage of the policy constraints extension; 2057 * Policy qualifiers syntax and semantics; and 2059 * Processing semantics for the critical CP extension. 2061 4.7.2 CRL Profile 2063 This subcomponent addresses such topics as the following 2064 (potentially by reference to a separate profile definition, such as 2065 the one defined in IETF PKIX RFC 2459): 2067 * Version numbers supported for CRLs; and 2069 * CRL and CRL entry extensions populated and their criticality. 2071 4.7.3 OCSP Profile 2073 This subcomponent addresses such topics as the following 2074 (potentially by reference to a separate profile definition, such as 2075 the IETF RFC 2560 profile): 2077 * Version of OCSP that is being used as the basis for establishing 2078 an OCSP system; and 2080 * OCSP extensions populated and their criticality. 2082 4.8 COMPLIANCE AUDIT AND OTHER ASSESSMENT 2084 This component addresses the following: 2086 * The list of topics covered by the assessment and/or the assessment 2087 methodology used to perform the assessment; examples include 2088 WebTrust for CAs (9) and SAS 70 (10). 2090 * Frequency of compliance audit or other assessment for each entity 2091 that must be assessed pursuant to a CP or CPS, or the circumstances 2092 that will trigger an assessment; possibilities include an annual 2093 audit, pre-operational assessment as a condition of allowing an 2094 entity to being operations, or investigation following a possible or 2095 actual compromise of security. 2097 * The identity and/or qualifications of the personnel performing the 2098 audit or other assessment. 2100 * The relationship between the assessor and the entity being 2102 assessed, including the degree of independence of the assessor. 2104 * Actions taken as a result of deficiencies found during the 2105 assessment; examples include a temporary suspension of operations 2106 until deficiencies are corrected, revocation of certificates issued 2107 to the assessed entity, changes in personnel, triggering special 2108 investigations or more frequent subsequent compliance assessments, 2109 and claims for damages against the assessed entity. 2111 * Who is entitled to see results of an assessment (e.g., assessed 2112 entity, other participants, the general public), who provides them 2113 (e.g., the assessor or the assessed entity), and how they are 2114 communicated. 2116 4.9 OTHER BUSINESS AND LEGAL MATTERS 2118 This component covers general business and legal matters. Sections 2119 9.1 and 9.2 of the framework discuss the business issues of fees to 2120 be charged for various services and the financial responsibility of 2121 participants to maintain resources for ongoing operations and for 2122 paying judgments or settlements in response to claims asserted 2123 against them. The remaining sections are generally concerned with 2124 legal topics. 2126 Starting with Section 9.3 of the framework, the ordering of topics 2127 is the same as or similar to the ordering of topics in a typical 2128 software licensing agreement or other technology agreement. 2129 Consequently, this framework may not only be used for CPs and CPSs, 2131 but also associated PKI-related agreements, especially subscriber 2132 agreements and relying party agreements. This ordering is intended 2133 help lawyers review CPs, CPSs, and other documents adhering to this 2134 framework. 2136 With respect to many of the legal subcomponents within this 2137 component, a CP or CPS drafter may choose to include in the document 2138 terms and conditions that apply directly to subscribers or relying 2139 parties. For instance, a CP or CPS may set forth limitations of 2140 liability that apply to subscribers and relying parties. The 2141 inclusion of terms and conditions is likely to be appropriate where 2142 the CP or CPS is itself a contract or part of a contract. 2144 In other cases, however, the CP or CPS is not a contract or part of 2145 a contract; instead, it is configured so that its terms and 2146 conditions are applied to the parties by separate documents, which 2147 may include associated agreements, such as subscriber or relying 2148 party agreements. In that event, a CP drafter may write a CP so as 2150 to require that certain legal terms and conditions appear (or not 2151 appear) in such associated agreements. For example, a CP might 2152 include a subcomponent stating that a certain limitation of 2153 liability term must appear in a CA's subscriber and relying party 2154 agreements. Another example is a CP that contains a subcomponent 2155 prohibiting the use of a subscriber or relying party agreement 2156 containing a limitation upon CA liability inconsistent with the 2157 provisions of the CP. A CPS drafter may use legal subcomponents to 2158 disclose that certain terms and conditions appear in associated 2160 subscriber, relying party, or other agreements in use by the CA. A 2161 CPS might explain, for instance, that the CA writing it uses an 2162 associated subscriber or relying party agreement that applies a 2163 particular provision for limiting liability. 2165 4.9.1 Fees 2167 This subcomponent contains any applicable provisions regarding fees 2168 charged by CAs, repositories, or RAs, such as: 2170 * Certificate issuance or renewal fees; 2172 * Certificate access fees; 2174 * Revocation or status information access fees; 2176 * Fees for other services such as providing access to the relevant 2177 CP or CPS; and 2179 * Refund policy. 2181 4.9.2 Financial Responsibility 2183 This subcomponent contains requirements or disclosures relating to 2184 the resources available to CAs, RAs, and other participants 2185 providing certification services to support performance of their 2186 operational PKI responsibilities, and to remain solvent and pay 2187 damages in the event they are liable to pay a judgment or settlement 2188 in connection with a claim arising out of such operations. Such 2189 provisions include: 2191 * A statement that the participant maintains a certain amount of 2192 insurance coverage for its liabilities to other participants; 2194 * A statement that a participant has access to other resources to 2195 support operations and pay damages for potential liability, which 2196 may be couched in terms of a minimum level of assets necessary to 2197 operate and cover contingencies that might occur within a PKI, where 2198 examples include assets on the balance sheet of an organization, a 2199 surety bond, a letter of credit, and a right under an agreement 2200 to an indemnity under certain circumstances; and 2202 * A statement that a participant has a program that offers first- 2203 party insurance or warranty protection to other participants in 2204 connection with their use of the PKI. 2206 4.9.3 Confidentiality of Business Information 2208 This subcomponent contains provisions relating to the treatment of 2209 confidential business information that participants may communicate 2210 to each other, such as business plans, sales information, trade 2211 secrets, and information received from a third party under a 2212 nondisclosure agreement. Specifically, this subcomponent addresses: 2214 * The scope of what is considered confidential information, 2216 * The types of information that are considered to be outside the 2217 scope of confidential information, and 2219 * The responsibilities of participants that receive confidential 2220 information to secure it from compromise, and refrain from using it 2221 or disclosing it to third parties. 2223 4.9.4 Privacy of Personal Information 2225 This subcomponent relates to the protection that participants, 2226 particularly CAs, RAs, and repositories, may be required to afford 2227 to personally identifiable private information of certificate 2228 applicants, subscribers, and other participants. In specific, this 2229 subcomponent addresses the following, to the extent pertinent under 2230 applicable law: 2232 * The designation and disclosure of the applicable privacy plan that 2233 applies to a participant's activities, if required by applicable law 2234 or policy; 2236 * Information that is or is not considered private within the PKI; 2238 * Any responsibility of participants that receive private 2239 information to secure it, and refrain from using it and from 2240 disclosing it to third parties; 2242 * Any requirements as to notices to, or consent from individuals 2243 regarding use or disclosure of private information; and 2245 * Any circumstances under which a participant is entitled or 2246 required to disclose private information pursuant to judicial, 2247 administrative process in a private or governmental proceeding, or 2248 in any legal proceeding. 2250 4.9.5 Intellectual Property Rights 2252 This subcomponent addresses the intellectual property rights, 2253 such as copyright, patent, trademarks, or trade secrets, that 2254 certain participants may have or claim in a CP, CPS, certificates, 2255 names, and keys, or are the subject of a license to or from 2256 participants. 2258 4.9.6 Representations and Warranties 2260 This subcomponent can include representations and warranties of 2261 various entities that are being made pursuant to the CP or CPS. For 2262 example, a CPS that serves as a contract might contain a CA's 2263 warranty that information contained in the certificate is accurate. 2264 Alternatively, a CPS might contain a less extensive warranty to the 2265 effect that the information in the certificate is true to the best 2266 of the CA's knowledge after performing certain identity 2267 authentication procedures with due diligence. This subcomponent can 2268 also include requirements that representations and warranties appear 2269 in certain agreements, such as subscriber or relying party 2270 agreements. For instance, a CP may contain a requirement that all 2272 CAs utilize a subscriber agreement, and that a subscriber agreement 2273 must contain a warranty by the CA that information in the 2274 certificate is accurate. Participants that may make representations 2275 and warranties include CAs, RAs, subscribers, relying parties, and 2276 other participants. 2278 4.9.7 Disclaimers of Warranties 2280 This subcomponent can include disclaimers of express warranties that 2281 may otherwise be deemed to exist in an agreement, and disclaimers of 2282 implied warranties that may otherwise be imposed by applicable law, 2283 such as warranties of merchantability or fitness for a particular 2284 purpose. The CP or CPS may directly impose such disclaimers, or the 2285 CP or CPS may contain a requirement that disclaimers appear in 2286 associated agreements, such as subscriber or relying party agreements. 2288 4.9.8 Limitations of Liability 2290 This subcomponent can include limitations of liability in a CP or 2291 CPS or limitations that appear or must appear in an agreement 2292 associated with the CP or CPS, such as a subscriber or relying party 2293 agreement. These limitations may fall into one of two categories: 2294 limitations on the elements of damages recoverable and limitations 2295 on the amount of damages recoverable, also known as liability caps. 2296 Often, contracts contain clauses preventing the recovery of elements 2297 of damages such as incidental and consequential damages, and 2298 sometimes punitive damages. Frequently, contracts contain clauses 2299 that limit the possible recovery of one party or the other to an 2300 amount certain or to an amount corresponding to a benchmark, such as 2301 the amount a vendor was paid under the contract. 2303 4.9.9 Indemnities 2305 This subcomponent includes provisions by which one party makes a 2306 second party whole for losses or damage incurred by the second 2307 party, typically arising out of the first party's conduct. They may 2308 appear in a CP, CPS, or agreement. For example, a CP may require 2309 that subscriber agreements contain a term under which a subscriber 2310 is responsible for indemnifying a CA for losses the CA sustains 2311 arising out of a subscriber's fraudulent misrepresentations on the 2312 certificate application under which the CA issued the subscriber 2313 an inaccurate certificate. Similarly, a CPS may say that a CA uses 2314 a relying party agreement, under which relying parties are 2315 responsible for indemnifying a CA for losses the CA sustains arising 2316 out of use of a certificate without properly checking revocation 2317 information or use of a certificate for purposes beyond what the CA 2318 permits. 2320 4.9.10 Term and Termination 2322 This subcomponent can include the time period in which a CP or a CPS 2323 remains in force and the circumstances under which the document, 2324 portions of the document, or its applicability to a particular 2325 participant can be terminated. In addition or alternatively, the CP 2326 or CPS may include requirements that certain term and termination 2328 clauses appear in agreements, such as subscriber or relying party 2329 agreements. In particular, such terms can include: 2331 * The term of a document or agreement, that is, when the document 2332 becomes effective and when it expires if it is not terminated 2333 earlier. 2335 * Termination provisions stating circumstances under which the 2336 document, certain portions of it, or its application to a particular 2337 participant ceases to remain in effect. 2339 * Any consequences of termination of the document. For example, 2340 certain provisions of an agreement may survive its termination and 2341 remain in force. Examples include acknowledgements of intellectual 2342 property rights and confidentiality provisions. Also, termination 2343 may trigger a responsibility of parties to return confidential 2344 information to the party that disclosed it. 2346 4.9.11 Individual notices and communications with participants 2348 This subcomponent discusses the way in which one participant can or 2349 must communicate with another participant on a one-to-one basis in 2350 order for such communications to be legally effective. For example, 2351 an RA may wish to inform the CA that it wishes to terminate its 2352 agreement with the CA. This subcomponent is different from 2353 publication and repository functions, because unlike individual 2354 communications described in this subcomponent, publication and 2355 posting to a repository are for the purpose of communicating to a 2356 wide audience of recipients, such as all relying parties. This 2357 subcomponent may establish mechanisms for communication and indicate 2358 the contact information to be used to route such communications, 2359 such as digitally signed e-mail notices to a specified address, 2360 followed by a signed e-mail acknowledgement of receipt. 2362 4.9.12 Amendments 2364 It will occasionally be necessary to amend a CP or CPS. Some of 2365 these changes will not materially reduce the assurance that a CP or 2367 its implementation provides, and will be judged by the policy 2368 administrator to have an insignificant effect on the acceptability 2369 of certificates. Such changes to a CP or CPS need not require a 2370 change in the CP OID or the CPS pointer (URL). On the other hand, 2371 some changes to a specification will materially change the 2372 acceptability of certificates for specific purposes, and these 2373 changes may require corresponding changes to the CP OID or CPS 2374 pointer qualifier (URL). 2376 This subcomponent may also contain the following information: 2378 * The procedures by which the CP or CPS and/or other documents must, 2379 may be, or are amended. In the case of CP or CPS amendments, change 2380 procedures may include a notification mechanism to provide notice of 2381 proposed amendments to affected parties, such as subscribers and 2382 relying parties; a comment period; a mechanism by which comments are 2384 received, reviewed and incorporated into the document; and a 2385 mechanism by which amendments become final and effective. 2387 * The circumstances under which amendments to the CP or CPS would 2388 require a change in CP OID or CPS pointer (URL). 2390 4.9.13 Dispute Resolution Procedures 2392 This subcomponent discusses procedures utilized to resolve disputes 2393 arising out of the CP, CPS, and/or agreements. Examples of such 2394 procedures include requirements that disputes be resolved in a 2395 certain forum or by alternative dispute resolution mechanisms. 2397 4.9.14 Governing Law 2399 This subcomponent sets forth a statement that the law of a certain 2400 jurisdiction governs the interpretation and enforcement of the 2401 subject CP or CPS or agreements. 2403 4.9.15 Compliance with Applicable Law 2405 This subcomponent relates to stated requirements that participants 2406 comply with applicable law, for example laws relating to 2407 cryptographic hardware and software that may be subject to the 2408 export control laws of a given jurisdiction. The CP or CPS could 2409 purport to impose such requirements or may require that such 2410 provisions appear in other agreements. 2412 4.9.16 Miscellaneous Provisions 2414 This subcomponent contains miscellaneous provisions sometimes called 2415 "boilerplate provisions" in contracts. The clauses covered in this 2416 subcomponent may appear in a CP, CPS, or agreements and include: 2418 * An entire agreement clause, which typically identifies the 2419 document or documents comprising the entire agreement between the 2420 parties and states that such agreements supersedes all prior and 2421 contemporaneous written or oral understandings relating to the same 2422 subject matter; 2424 * An assignment clause, which may act to limit the ability of a 2425 party to an agreement to assign its rights under the agreement to 2426 another party (such as the right to receive a stream of payments in 2427 the future) or the ability of a party to delegate its obligations 2428 under the agreement; 2430 * A severability clause, which sets forth the intentions of the 2431 parties in the event a court or other tribunal determines that a 2432 clause within an agreement is, for some reason, invalid or 2433 unenforceable, and whose purpose is frequently to prevent the 2434 unenforceability of one clause from causing the whole agreement to 2435 be unenforceable; and 2437 * An enforcement clause, which may state that a party prevailing in 2438 any dispute arising out of an agreement is entitled to attorneys' 2440 fees as part of its recovery, or may state that a party's waiver of 2441 one breach of contract does not constitute a continuing waiver or a 2442 future waiver of other breaches of contract. 2444 * A force majeure clause, commonly used to excuse the performance 2445 of one or more parties to an agreement due to an event outside the 2446 reasonable control of the affected party or parties. Typically, 2447 the duration of the excused performance is commensurate with the 2448 duration of the delay caused by the event. The clause may also 2449 provide for the termination of the agreement under specified 2450 circumstances and conditions. Events considered to constitute a 2451 "force majeure" may include so-called "Acts of God," wars, terrorism, 2452 strikes, natural disasters, failures of suppliers or vendors to 2453 perform, or failures of the Internet or other infrastructure. Force 2454 majeure clauses should be drafted so as to be consistent with other 2455 portions of the framework and applicable service level agreements. 2456 For instance, responsibilities and capabilities for business 2457 continuity and disaster recovery may place some events within the 2458 reasonable control of the parties, such as an obligation to maintain 2459 backup electrical power in the face of power outages. 2461 4.9.17 Other Provisions 2463 This subcomponent is a "catchall" location where additional 2464 responsibilities and terms can be imposed on PKI participants that 2465 do not neatly fit within one of the other components or 2466 subcomponents of the framework. CP and CPS writers can place any 2467 provision within this subcomponent that is not covered by another 2468 subcomponent. 2470 5. Security Considerations 2472 According to X.509, a certificate policy (CP) is "a named set of 2473 rules that indicates the applicability of a certificate to a 2474 particular community and/or class of applications with common 2475 security requirements." A CP may be used by a relying party to help 2476 in deciding whether a certificate, and the binding therein, are 2477 sufficiently trustworthy and otherwise appropriate for a particular 2478 application. 2480 The degree to which a relying party can trust the binding embodied 2481 in a certificate depends on several factors. These factors can 2482 include the practices followed by the certification authority (CA) 2483 in authenticating the subject; the CA's operating policy, procedures, 2484 and technical security controls (including the scope of the 2485 subscriber's responsibilities (for example, in protecting the private 2486 key); and the stated responsibilities and liability terms and 2487 conditions of the CA (for example, warranties, disclaimers of warranties, 2488 and limitations of liability). 2490 This document provides a framework to address technical, procedural, 2491 personnel, and physical security aspects of Certification Authorities. 2492 Registration Authorities, repositories, subscribers, and relying party 2493 cryptographic modules in order to ensure that the certificate 2494 generation, publication, renewal, re-key, usage, and revocation is done 2496 in a secure manner. Specifically, Section 4.3 IDENTIFICATION AND 2497 AUTHENTICATION (I&A); Section 4.4 CERTIFICATE LIFE-CYCLE 2498 OPERATIONAL REQUIREMENTS; Section 4.5 FACILITY, 2499 MANAGEMENT, AND OPERATIONAL CONTROLS; Section 4.6 2500 TECHNICAL SECURITY CONTROLS; Section 4.7 CERTIFICATE, 2501 CRL, AND OCSP PROFILES; and Section 4.8 COMPLIANCE AUDIT 2502 AND OTHER ASSESSMENT are oriented towards ensuring secure 2503 operation of the PKI entities such as CA, RA, repository, 2504 subscriber systems, and relying party systems. 2506 6. OUTLINE OF A SET OF PROVISIONS 2508 This section contains a recommended outline for a set of provisions, 2509 intended to serve as a checklist or (with some further development) 2510 a standard template for use by CP or CPS writers. Such a common 2511 outline will facilitate: 2513 (a) Comparison of two certificate policies during cross- 2514 certification or other forms of interoperation (for the purpose of 2515 equivalency mapping). 2516 (b) Comparison of a CPS with a CP to ensure that the CPS faithfully 2517 implements the policy. 2518 (c) Comparison of two CPSs. 2520 In order to comply with the RFC, the drafters of a compliant CP or 2521 CPS are strongly advised to adhere to this outline. While use of 2522 alternate outline is discouraged, it may be accepted if a proper 2523 justification is provided for the deviation and a mapping table is 2524 provided to readily discern where each of the items described in 2525 this outline is provided. 2527 1. INTRODUCTION 2529 1.1 Overview 2531 1.2 Document name and identification 2533 1.3 PKI participants 2534 1.3.1 Certification authorities 2535 1.3.2 Registration authorities 2536 1.3.3 Subscribers 2537 1.3.4 Relying parties 2538 1.3.5 Other participants 2540 1.4 Certificate usage 2541 1.4.1. Appropriate certificate uses 2542 1.4.2 Prohibited certificate uses 2544 1.5 Policy administration 2545 1.5.1 Organization administering the document 2546 1.5.2 Contact person 2547 1.5.3 Person determining CPS suitability for the policy 2548 1.5.4 CPS approval procedures 2550 1.6 Definitions and acronyms 2552 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES 2554 2.1 Repositories 2556 2.2 Publication of certification information 2558 2.3 Time or frequency of publication 2560 2.4 Access controls on repositories 2562 3. IDENTIFICATION AND AUTHENTICATION (11) 2564 3.1 Naming 2565 3.1.1 Types of names 2566 3.1.2 Need for names to be meaningful 2567 3.1.3 Anonymity or pseudonymity of subscribers 2568 3.1.4 Rules for interpreting various name forms 2569 3.1.5 Uniqueness of names 2570 3.1.6 Recognition, authentication, and role of trademarks 2572 3.2 Initial identity validation 2573 3.2.1 Method to prove possession of private key 2574 3.2.2 Authentication of organization identity 2575 3.2.3 Authentication of individual identity 2576 3.2.4 Non-verified subscriber information 2577 3.2.5 Validation of authority 2578 3.2.6 Criteria for interoperation 2580 3.3 Identification and authentication for re-key requests 2581 3.3.1 Identification and authentication for routine re-key 2582 3.3.2 Identification and authentication for re-key after revocation 2584 3.4 Identification and authentication for revocation request 2586 4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS (11) 2588 4.1 Certificate Application 2589 4.1.1 Who can submit a certificate application 2590 4.1.2 Enrollment process and responsibilities 2592 4.2 Certificate application processing 2593 4.2.1 Performing identification and authentication functions 2594 4.2.2 Approval or rejection of certificate applications 2595 4.2.3 Time to process certificate applications 2597 4.3 Certificate issuance 2598 4.3.1 CA actions during certificate issuance 2599 4.3.2 Notification to subscriber by the CA of issuance of 2600 certificate 2602 4.4 Certificate acceptance 2603 4.4.1 Conduct constituting certificate acceptance 2604 4.4.2 Publication of the certificate by the CA 2606 4.4.3 Notification of certificate issuance by the CA to other 2607 entities 2609 4.5 Key pair and certificate usage 2610 4.5.1 Subscriber private key and certificate usage 2611 4.5.2 Relying party public key and certificate usage 2613 4.6 Certificate renewal 2614 4.6.1 Circumstance for certificate renewal 2615 4.6.2 Who may request renewal 2616 4.6.3 Processing certificate renewal requests 2617 4.6.4 Notification of new certificate issuance to subscriber 2618 4.6.5 Conduct constituting acceptance of a renewal certificate 2619 4.6.6 Publication of the renewal certificate by the CA 2620 4.6.7 Notification of certificate issuance by the CA to other 2621 entities 2623 4.7 Certificate re-key 2624 4.7.1 Circumstance for certificate re-key 2625 4.7.2 Who may request certification of a new public key 2626 4.7.3 Processing certificate re-keying requests 2627 4.7.4 Notification of new certificate issuance to subscriber 2628 4.7.5 Conduct constituting acceptance of a re-keyed certificate 2629 4.7.6 Publication of the re-keyed certificate by the CA 2630 4.7.7 Notification of certificate issuance by the CA to other 2631 entities 2633 4.8 Certificate modification 2634 4.8.1 Circumstance for certificate modification 2635 4.8.2 Who may request certificate modification 2636 4.8.3 Processing certificate modification requests 2637 4.8.4 Notification of new certificate issuance to subscriber 2638 4.8.5 Conduct constituting acceptance of modified certificate 2639 4.8.6 Publication of the modified certificate by the CA 2640 4.8.7 Notification of certificate issuance by the CA to other 2641 entities 2643 4.9 Certificate revocation and suspension 2644 4.9.1 Circumstances for revocation 2645 4.9.2 Who can request revocation 2646 4.9.3 Procedure for revocation request 2647 4.9.4 Revocation request grace period 2648 4.9.5 Time within which CA must process the revocation request 2649 4.9.6 Revocation checking requirement for relying parties 2650 4.9.7 CRL issuance frequency (if applicable) 2651 4.9.8 Maximum latency for CRLs (if applicable) 2652 4.9.9 On-line revocation/status checking availability 2653 4.9.10 On-line revocation checking requirements 2654 4.9.11 Other forms of revocation advertisements available 2655 4.9.12 Special requirements re key compromise 2656 4.9.13 Circumstances for suspension 2657 4.9.14 Who can request suspension 2658 4.9.15 Procedure for suspension request 2659 4.9.16 Limits on suspension period 2661 4.10 Certificate status services 2662 4.10.1 Operational characteristics 2663 4.10.2 Service availability 2664 4.10.3 Optional features 2666 4.11 End of subscription 2668 4.12 Key escrow and recovery 2669 4.12.1 Key escrow and recovery policy and practices 2670 4.12.2 Session key encapsulation and recovery policy and practices 2672 5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS (11) 2674 5.1 Physical controls 2675 5.1.1 Site location and construction 2676 5.1.2 Physical access 2677 5.1.3 Power and air conditioning 2678 5.1.4 Water exposures 2679 5.1.5 Fire prevention and protection 2680 5.1.6 Media storage 2681 5.1.7 Waste disposal 2682 5.1.8 Off-site backup 2684 5.2 Procedural controls 2685 5.2.1 Trusted roles 2686 5.2.2 Number of persons required per task 2687 5.2.3 Identification and authentication for each role 2688 5.2.4 Roles requiring separation of duties 2690 5.3 Personnel controls 2691 5.3.1 Qualifications, experience, and clearance requirements 2692 5.3.2 Background check procedures 2693 5.3.3 Training requirements 2694 5.3.4 Retraining frequency and requirements 2695 5.3.5 Job rotation frequency and sequence 2696 5.3.6 Sanctions for unauthorized actions 2697 5.3.7 Independent contractor requirements 2698 5.3.8 Documentation supplied to personnel 2700 5.4 Audit logging procedures 2701 5.4.1 Types of events recorded 2702 5.4.2 Frequency of processing log 2703 5.4.3 Retention period for audit log 2704 5.4.4 Protection of audit log 2705 5.4.5 Audit log backup procedures 2706 5.4.6 Audit collection system (internal vs. external) 2707 5.4.7 Notification to event-causing subject 2708 5.4.8 Vulnerability assessments 2710 5.5 Records archival 2711 5.5.1 Types of records archived 2712 5.5.2 Retention period for archive 2714 5.5.3 Protection of archive 2715 5.5.4 Archive backup procedures 2717 5.5.5 Requirements for time-stamping of records 2718 5.5.6 Archive collection system (internal or external) 2719 5.5.7 Procedures to obtain and verify archive information 2721 5.6 Key changeover 2723 5.7 Compromise and disaster recovery 2724 5.7.1 Incident and compromise handling procedures 2725 5.7.2 Computing resources, software, and/or data are corrupted 2726 5.7.3 Entity private key compromise procedures 2727 5.7.4 Business continuity capabilities after a disaster 2729 5.8 CA or RA termination 2731 6. TECHNICAL SECURITY CONTROLS (11) 2733 6.1 Key pair generation and installation 2734 6.1.1 Key pair generation 2735 6.1.2 Private key delivery to subscriber 2736 6.1.3 Public key delivery to certificate issuer 2737 6.1.4 CA public key delivery to relying parties 2738 6.1.5 Key sizes 2739 6.1.6 Public key parameters generation and quality checking 2740 6.1.7 Key usage purposes (as per X.509 v3 key usage field) 2742 6.2 Private Key Protection and Cryptographic Module Engineering 2743 Controls 2745 6.2.1 Cryptographic module standards and controls 2746 6.2.2 Private key (n out of m) multi-person control 2747 6.2.3 Private key escrow 2748 6.2.4 Private key backup 2749 6.2.5 Private key archival 2750 6.2.6 Private key transfer into or from a cryptographic module 2751 6.2.7 Private key storage on cryptographic module 2752 6.2.8 Method of activating private key 2753 6.2.9 Method of deactivating private key 2754 6.2.10 Method of destroying private key 2755 6.2.11 Cryptographic Module Rating 2757 6.3 Other aspects of key pair management 2758 6.3.1 Public key archival 2759 6.3.2 Certificate operational periods and key pair usage periods 2761 6.4 Activation data 2762 6.4.1 Activation data generation and installation 2763 6.4.2 Activation data protection 2764 6.4.3 Other aspects of activation data 2766 6.5 Computer security controls 2767 6.5.1 Specific computer security technical requirements 2768 6.5.2 Computer security rating 2770 6.6 Life cycle technical controls 2771 6.6.1 System development controls 2773 6.6.2 Security management controls 2774 6.6.3 Life cycle security controls 2776 6.7 Network security controls 2778 6.8 Time-stamping 2780 7. CERTIFICATE, CRL, AND OCSP PROFILES 2782 7.1 Certificate profile 2783 7.1.1 Version number(s) 2784 7.1.2 Certificate extensions 2785 7.1.3 Algorithm object identifiers 2786 7.1.4 Name forms 2787 7.1.5 Name constraints 2788 7.1.6 Certificate policy object identifier 2789 7.1.7 Usage of Policy Constraints extension 2790 7.1.8 Policy qualifiers syntax and semantics 2791 7.1.9 Processing semantics for the critical Certificate Policies 2792 extension 2794 7.2 CRL profile 2795 7.2.1 Version number(s) 2796 7.2.2 CRL and CRL entry extensions 2798 7.3 OCSP profile 2799 7.3.1 Version number(s) 2801 7.3.2 OCSP extensions 2803 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS 2804 8.1 Frequency or circumstances of assessment 2805 8.2 Identity/qualifications of assessor 2806 8.3 Assessor's relationship to assessed entity 2807 8.4 Topics covered by assessment 2808 8.5 Actions taken as a result of deficiency 2809 8.6 Communication of results 2811 9. OTHER BUSINESS AND LEGAL MATTERS 2813 9.1 Fees 2814 9.1.1 Certificate issuance or renewal fees 2815 9.1.2 Certificate access fees 2816 9.1.3 Revocation or status information access fees 2817 9.1.4 Fees for other services 2818 9.1.5 Refund policy 2820 9.2 Financial responsibility 2821 9.2.1 Insurance coverage 2822 9.2.2 Other assets 2823 9.2.3 Insurance or warranty coverage for end-entities 2825 9.3 Confidentiality of business information 2826 9.3.1 Scope of confidential information 2827 9.3.2 Information not within the scope of confidential information 2828 9.3.3 Responsibility to protect confidential information 2830 9.4 Privacy of personal information 2832 9.4.1 Privacy plan 2833 9.4.2 Information treated as private 2834 9.4.3 Information not deemed private 2835 9.4.4 Responsibility to protect private information 2836 9.4.5 Notice and consent to use private information 2837 9.4.6 Disclosure pursuant to judicial or administrative process 2838 9.4.7 Other information disclosure circumstances 2840 9.5 Intellectual property rights 2842 9.6 Representations and warranties 2843 9.6.1 CA representations and warranties 2844 9.6.2 RA representations and warranties 2845 9.6.3 Subscriber representations and warranties 2846 9.6.4 Relying party representations and warranties 2847 9.6.5 Representations and warranties of other participants 2849 9.7 Disclaimers of warranties 2851 9.8 Limitations of liability 2853 9.9 Indemnities 2855 9.10 Term and termination 2856 9.10.1 Term 2857 9.10.2 Termination 2858 9.10.3 Effect of termination and survival 2860 9.11 Individual notices and communications with participants 2862 9.12 Amendments 2863 9.12.1 Procedure for amendment 2864 9.12.2 Notification mechanism and period 2865 9.12.3 Circumstances under which OID must be changed 2867 9.13 Dispute resolution provisions 2869 9.14 Governing law 2871 9.15 Compliance with applicable law 2873 9.16 Miscellaneous provisions 2874 9.16.1 Entire agreement 2875 9.16.2 Assignment 2876 9.16.3 Severability 2877 9.16.4 Enforcement (attorneys' fees and waiver of rights) 2878 9.16.5 Force Majeure 2879 9.17 Other provisions 2881 7. COMPARISON TO RFC 2527 2883 This framework represents an incremental improvement over RFC 2527. 2884 The new framework benefits from the experience gained in the course 2886 of deploying CP and CPS documents under RFC 2527. Further, this new 2887 framework is based on coordination with the American Bar Association 2888 Information Security Committee within the Section of Science and 2889 Technology Law. The ISC wrote the PKI Assessment Guidelines [ABA2], 2890 which embodies a great deal of technical, business, and legal 2891 experience in PKI operations. In particular, representatives of the 2892 ISC made changes to the framework to make it better suited to the 2893 legal environment and more accessible to lawyers. 2895 >From a technical perspective, the changes to the RFC 2527 framework 2896 were minimal and incremental, rather than revolutionary. Sections 2897 3-7 have largely been preserved, with modest reorganization and new 2898 topics. For example, the new framework includes a revision of 2899 Section 4 of the framework to include a full treatment of the 2900 certificate life-cycle, the addition of key escrow, key 2901 encapsulation, and key recovery policies and practices, and OCSP. 2902 Section 2 audit functions now appear alone in Section 8, and 2903 Section 2 focuses exclusively on repository functions. The 2904 business and legal matters in RFC 2527's Section 2 now appear in a 2905 new Section 9. 2907 >From a legal perspective, the new Section 9 is useful because it 2908 places topics in the framework in an ordering that is similar to 2909 software licensing and other technology agreements and thus is 2910 familiar to technology lawyers. Moreover, the framework as a whole 2911 can double as a framework for a subscriber, relying party, or other 2912 PKI-related agreement. The changes are intended to make legal 2913 review of, and input into, CP and CPS documents more efficient. 2914 Section 9 also adds new legal topics, such as the privacy of 2915 personal information, liability terms, and duration of the 2916 effectiveness of the document. 2918 Section 1 of the new framework is largely the same as RFC 2527, 2919 although it increases coverage of PKI participants by breaking out 2920 subscribers from relying parties and adding a section for other 2921 participants. It changes the "applicability" section to one 2922 covering appropriate and prohibited uses of certificates. Also, it 2923 moves CPS approval procedures from RFC 2527's Section 8.3 into a 2924 collected policy administration section. Finally, Section 1.6 adds 2925 a place to list definitions and acronyms. 2927 Section 2 of the new framework is a reorganization of Section 2.6 2928 of the old framework. Section 3 of the new framework is based on 2929 a division of the old Section 3.1 into two parts for naming and 2930 identification and authentication issues. It adds new issues, such 2931 as the permissibility of pseudonyms and anonymity. Old Section 4 2932 topics on audit logging, records archival, key changeover, 2933 compromise and disaster recovery, and CA termination have moved to 2934 Section 5. The remaining Section 4 topics have been expanded and 2935 reorganized to cover a complete certificate lifecycle. New topics 2936 include items implicit in the RFC 2527 Section 4, but now explicit, 2937 such as certificate application processing, certificate 2938 modification, and the end of subscription. 2940 New Sections 5.1 through 5.3 are almost identical to their 2942 counterparts in RFC 2527. The remainder of the new Section 5 is 2943 the topics moved from RFC 2527's Section 4, in the order that they 2944 had appeared in Section 4. Section 6 of the new framework is 2945 almost the same as the old Section 6, with some exceptions, such as 2946 the consolidation of old Section 6.8 (cryptographic module 2947 engineering controls) into Section 6.2.1 (now called "cryptographic 2948 module standards and controls") and the addition of time-stamping in 2949 a new Section 6.8. Section 7 is almost identical to the old Section 2950 7, the major change being the addition of a section covering OCSP 2951 profile. Section 8 is almost identical to RFC 2527's Section 2.7. 2953 New Section 9 contains business and legal topics that had been 2954 covered in RFC 2527's Section 2, including fees, financial 2955 responsibility, confidentiality, and intellectual property. It adds 2956 a section on the privacy of personal information, which has become a 2957 significant policy issue. The "liability" Section 2.2 in RFC 2527 2958 now appears in Sections 9.6 through 9.9, covering representations 2959 and warranties, disclaimers, limitations of liability, and 2960 indemnities. Section 9.10 adds a section concerning the duration of 2961 the effectiveness of documentation. Section 9.12 collects terms 2962 concerning the way in which a document (CP, CPS, agreement, or other 2963 document) may be amended, formerly appearing in Section 8.1. 2964 Section 9 includes "legal boilerplate" topics, some of which had 2965 been in the old Section 2. Finally, Section 9.17 is a catch-all 2966 "other provisions" section where drafters can place information that 2967 does not fit well into any other section of the framework. 2969 The following matrix shows the sections in the old RFC 2527 2970 framework and their successor sections in the new framework. 2972 ORIGINAL RFC 2527 NEW RFC SECTION 2973 SECTION 2974 ------------------------------------------------------ 2975 1. Introduction 1. 2976 ------------------------------------------------------ 2977 1.1 Overview 1.1 2978 ------------------------------------------------------ 2979 1.2 Identification 1.2 2980 ------------------------------------------------------ 2981 1.3 Community and 2982 Applicability 1.3 2983 ------------------------------------------------------ 2984 1.3.1 Certification 2985 Authorities 1.3.1 2986 ------------------------------------------------------ 2987 1.3.2 Registration Authorities 1.3.2 2988 ------------------------------------------------------ 2989 1.3.3 End entities 1.3.3, 2990 1.3.4 2991 ------------------------------------------------------ 2992 1.3.4 Applicability 1.4, 4.5 2993 ------------------------------------------------------ 2994 1.4 Contact Details 1.5 2996 ------------------------------------------------------ 2997 1.4.1 Specification Administration 2998 Organization 1.5.1 2999 ------------------------------------------------------ 3000 1.4.2 Contact Person 1.5.2 3001 ------------------------------------------------------ 3002 1.4.3 Person Determining CPS 3003 Suitability for the Policy 1.5.3 3004 ------------------------------------------------------ 3005 2. General Provisions 2, 8, 9 3006 ------------------------------------------------------ 3007 2.1 Obligations 2.6.4 3008 ------------------------------------------------------ 3009 2.1.1 1A Obligations Integrated 3010 throughout 3011 portions of the 3012 framework that 3013 apply to CAs 3014 ------------------------------------------------------ 3015 2.1.2 RA Obligations Integrated 3016 throughout 3017 portions of the 3018 framework that 3019 apply to RAs 3020 ------------------------------------------------------ 3021 2.1.3 Subscriber Obligations 4.1.2, 4.4, 4.5, 3022 4.5.1, 4.6.5, 3023 4.7.5, 4.8.1, 3024 4.8.5, 4.9.1, 3025 4.9.2, 4.9.13, 3026 4.9.15, 5., 6., 3027 9.6.3, 9.9 3028 ------------------------------------------------------ 3029 2.1.4 Relying Party Obligations 4.5, 4.5.2, 4.9.6, 3030 5., 6., 9.6.4, 9.9 3031 ------------------------------------------------------ 3032 2.1.5 Repository Obligations 2., 4.4.2, 4.4.3, 3033 4.6.6, 4.6.7, 3034 4.7.6, 4.7.7, 3035 4.8.6, 4.8.7 3036 ------------------------------------------------------ 3037 2.2 Liability 9.6, 9.7, 9.8, 9.9 3038 ------------------------------------------------------ 3039 2.2.1 CA Liability 9.6.1, 9.7., 9.8, 3040 9.9 3041 ------------------------------------------------------ 3042 2.2.2 RA Liability 9.6.2, 9.7, 9.8, 9.9 3043 ------------------------------------------------------ 3044 2.3 Financial Responsibility 9.2 3045 ------------------------------------------------------ 3046 2.3.1 Indemnification by Relying 3047 Parties 9.9 3048 ------------------------------------------------------ 3049 2.3.2 Fiduciary Relationships 9.7 3051 ------------------------------------------------------ 3052 2.4 Interpretation and Enforcement 9.16 3053 ------------------------------------------------------ 3054 2.4.1 Governing Law 9.14, 9.15 3055 ------------------------------------------------------ 3056 2.4.2 Severability, Survival, 3057 Merger, Notice 9.10.3, 9.11, 3058 9.16.1,9.16.3 3059 ------------------------------------------------------ 3060 2.4.3 Dispute Resolution 3061 Procedures 9.13, 9.16.4 3062 ------------------------------------------------------ 3063 2.5 Fees 9.1 3064 ------------------------------------------------------ 3065 2.5.1 Certificate Issuance 3066 or Renewal Fees 9.1.1 3067 ------------------------------------------------------ 3068 2.5.2 Certificate Access Fees 9.1.2 3069 ------------------------------------------------------ 3070 2.5.3 Revocation or Status 3071 Information Access Fees 9.1.3 3072 ------------------------------------------------------ 3073 2.5.4 Fees for Other Services Such 3074 as Policy Information 9.1.4 3075 ------------------------------------------------------ 3076 2.5.5 Refund Policy 9.1.5 3077 ------------------------------------------------------ 3078 2.6 Publication and Repository 2. 3079 ------------------------------------------------------ 3080 2.6.1 Publication of CA 3081 Information 2.2, 4.4.2, 3082 4.4.3, 4.6.6, 3083 4.6.7, 4.7.6, 3084 4.7.7, 4.8.6, 3085 4.8.7 3086 ------------------------------------------------------ 3087 2.6.2 Frequency of Publication 2.3 3088 ------------------------------------------------------ 3089 2.6.3 Access Controls 2.4 3090 ------------------------------------------------------ 3091 2.6.4 Repositories 2.1 3092 ------------------------------------------------------ 3093 2.7 Compliance Audit 8. 3094 ------------------------------------------------------ 3095 2.7.1 Frequency of Entity Compliance 3096 Audit 8.1 3097 ------------------------------------------------------ 3098 2.7.2 Identity/Qualifications of 3099 Auditor 8.2 3100 ------------------------------------------------------ 3101 2.7.3 Auditor's Relationship to Audited 3102 Party 8.3 3103 ------------------------------------------------------ 3105 2.7.4 Topics Covered by Audit 8.4 3106 ------------------------------------------------------ 3107 2.7.5 Actions Taken as a Result of 3108 Deficiency 8.5 3109 ------------------------------------------------------ 3110 2.7.6 Communications of Results 8.6 3111 ------------------------------------------------------ 3112 2.8 Confidentiality 9.3, 9.4 3113 ------------------------------------------------------ 3114 2.8.1 Types of Information to be 3115 Kept Confidential 9.3.1, 9.4.2 3116 ------------------------------------------------------ 3117 2.8.2 Types of Information Not 3118 Considered Confidential 9.3.2, 9.4.3 3119 ------------------------------------------------------ 3120 2.8.3 Disclosure of Certificate 3121 Revocation/Suspension 3122 Information 9.3.1, 9.3.2, 3123 9.3.3, 9.4.2, 3124 9.4.3, 9.4.4 3125 ------------------------------------------------------ 3126 2.8.4 Release to Law Enforcement 3127 Officials 9.3.3, 9.4.6 3128 ------------------------------------------------------ 3129 2.8.5 Release as Part of Civil 3130 Discovery 9.3.3, 9.4.6 3131 ------------------------------------------------------ 3132 2.8.6 Disclosure Upon Owner's 3133 Request 9.3.3, 9.4.7 3134 ------------------------------------------------------ 3135 2.8.7 Other Information Release 3136 Circumstances 9.3.3, 9.4.7 3137 ------------------------------------------------------ 3138 2.9 Intellectual Property Rights 9.5 3139 ------------------------------------------------------ 3140 3. Identification and Authentication 3. 3141 ------------------------------------------------------ 3142 3.1 Initial Registration 3.1, 3.2 3143 ------------------------------------------------------ 3144 3.1.1 Type of Names 3.1.1 3145 ------------------------------------------------------ 3146 3.1.2 Need for Names to be 3147 Meaningful 3.1.2, 3.1.3 3148 ------------------------------------------------------ 3149 3.1.3 Rules for Interpreting 3150 Various Name Forms 3.1.4 3151 ------------------------------------------------------ 3152 3.1.4 Uniqueness of Names 3.1.5 3153 ------------------------------------------------------ 3154 3.1.5 Name Claim Dispute 3155 Resolution Procedure 3.1.6 3156 ------------------------------------------------------ 3157 3.1.6 Recognition, Authentication, 3158 and Role of Trademarks 3.1.6 3160 ------------------------------------------------------ 3161 3.1.7 Method to Prove Possession 3162 of Private Key 3.2.1 3163 ------------------------------------------------------ 3164 3.1.8 Authentication of 3165 Organization Identity 3.2.2 3166 ------------------------------------------------------ 3167 3.1.9 Authentication of 3168 Individual Identity 3.2.3 3169 ------------------------------------------------------ 3170 3.2 Routine Rekey 3.3.1, 4.6, 4.7 3171 ------------------------------------------------------ 3172 3.3 Rekey After Revocation 3.3.2 3173 ------------------------------------------------------ 3174 3.4 Revocation Request 3.4 3175 ------------------------------------------------------ 3176 4. Operational Requirements 4., 5. 3177 ------------------------------------------------------ 3178 4.1 Certificate Application 4.1, 4.2, 4.6, 3179 4.7 3180 ------------------------------------------------------ 3181 4.2 Certificate Issuance 4.2, 4.3, 4.4.3, 3182 4.6, 4.7, 4.8.4, 3183 4.8.6, 4.8.7 3184 ------------------------------------------------------ 3185 4.3 Certificate Acceptance 4.3.2, 4.4, 4.6, 3186 4.7, 4.8.4-4.8.7 3187 ------------------------------------------------------ 3188 4.4 Certificate Suspension 3189 and Revocation 4.8, 4.9 3190 ------------------------------------------------------ 3191 4.4.1 Circumstances for Revocation 4.8.1, 4.9.1 3192 ------------------------------------------------------ 3193 4.4.2 Who Can Request Revocation 4.8.2, 4.9.2 3194 ------------------------------------------------------ 3195 4.4.3 Procedure for Revocation 3196 Request 4.8.3-4.8.7, 3197 4.9.3 3198 ------------------------------------------------------ 3199 4.4.4 Revocation Request 3200 Grace Period 4.9.4 3201 ------------------------------------------------------ 3202 4.4.5 Circumstances for Suspension 4.9.13 3203 ------------------------------------------------------ 3204 4.4.6 Who Can Request Suspension 4.9.14 3205 ------------------------------------------------------ 3206 4.4.7 Procedure for Suspension 3207 Request 4.9.15 3208 ------------------------------------------------------ 3209 4.4.8 Limits on Suspension Period 4.9.16 3210 ------------------------------------------------------ 3211 4.4.9 CRL Issuance Frequency 3212 (If Applicable) 4.9.7, 4.9.8, 3213 4.10 3215 ------------------------------------------------------ 3216 4.4.10 CRL Checking Requirements 4.9.6, 4.10 3217 ------------------------------------------------------ 3218 4.4.11 On-Line Revocation/ 3219 Status Checking 3220 Availability 4.9.9, 4.10 3221 ------------------------------------------------------ 3222 4.4.12 On-Line Revocation 3223 Checking Requirements 4.9.6, 4.9.10, 3224 4.10 3225 ------------------------------------------------------ 3226 4.4.13 Other Forms 3227 of Revocation 3228 Advertisements 4.9.11, 4.10 3229 ------------------------------------------------------ 3230 4.4.14 Checking Requirements 3231 for Other Forms of 3232 Revocation 3233 Advertisements 4.9.6, 4.9.11, 3234 4.10 3235 ------------------------------------------------------ 3236 4.4.15 Special Requirements re 3237 Key Compromise 4.9.12 3238 ------------------------------------------------------ 3239 4.5 Security Audit Procedures 5.4 3240 ------------------------------------------------------ 3241 4.5.1 Types of Events Recorded 5.4.1 3242 ------------------------------------------------------ 3243 4.5.2 Frequency of Processing Log 5.4.2 3244 ------------------------------------------------------ 3245 4.5.3 Retention Period for Audit 3246 Log 5.4.3 3247 ------------------------------------------------------ 3248 4.5.4 Protection of Audit Log 5.4.4 3249 ------------------------------------------------------ 3250 4.5.5 Audit Log Backup Procedures 5.4.5 3251 ------------------------------------------------------ 3252 4.5.6 Audit Collection System 3253 (Internal vs. External) 5.4.6 3254 ------------------------------------------------------ 3255 4.5.7 Notification to Event-Causing 3256 Subject 5.4.7 3257 ------------------------------------------------------ 3258 4.5.8 Vulnerability Assessments 5.4.8 3259 ------------------------------------------------------ 3260 4.6 Records Archival 5.5 3261 ------------------------------------------------------ 3262 4.6.1 Types of Records Archived 5.5.1 3263 ------------------------------------------------------ 3264 4.6.2 Retention Period for Archive 5.5.2 3265 ------------------------------------------------------ 3266 4.6.3 Protection of Archive 5.5.3 3267 ------------------------------------------------------ 3268 4.6.4 Archive Backup Procedures 5.5.4 3270 ------------------------------------------------------ 3271 4.6.5 Requirements for 3272 Time-Stamping of Records 5.5.5 3273 ------------------------------------------------------ 3274 4.6.6 Archive Collection System 3275 (Internal or External) 5.5.6 3276 ------------------------------------------------------ 3277 4.6.6 Procedures to Obtain and 3278 Verify Archive Information 5.5.7 3279 ------------------------------------------------------ 3280 4.7 Key Changeover 5.6 3281 ------------------------------------------------------ 3282 4.8 Compromise and Disaster 3283 Recovery 5.7, 5.7.1 3284 ------------------------------------------------------ 3285 4.8.1 Computing Resources, Software, 3286 and/or Data Are Corrupted 5.7.2 3287 ------------------------------------------------------ 3288 4.8.2 Entity Public 3289 Key is Revoked 4.9.7, 4.9.9, 3290 4.9.11 3291 ------------------------------------------------------ 3292 4.8.3 Entity Key is Compromised 5.7.3 3293 ------------------------------------------------------ 3294 4.8.4 Secure Facility After a Natural 3295 or Other Type of Disaster 5.7.4 3296 ------------------------------------------------------ 3297 4.9 CA Termination 5.8 3298 ------------------------------------------------------ 3299 5. Physical, Procedural, and 3300 Personnel Security Controls 5. 3301 ------------------------------------------------------ 3302 5.1 Physical Controls 5.1 3303 ------------------------------------------------------ 3304 5.1.1 Site Location and Construction 5.1.1 3305 ------------------------------------------------------ 3306 5.1.2 Physical Access 5.1.2 3307 ------------------------------------------------------ 3308 5.1.3 Power and Air Conditioning 5.1.3 3309 ------------------------------------------------------ 3311 5.1.4 Water Exposures 5.1.4 3312 ------------------------------------------------------ 3313 5.1.5 Fire Prevention and Protection 5.1.5 3314 ------------------------------------------------------ 3315 5.1.6 Media Storage 5.1.6 3316 ------------------------------------------------------ 3317 5.1.7 Waste Disposal 5.1.7 3318 ------------------------------------------------------ 3319 5.1.8 Off-Site Backup 5.1.8 3320 ------------------------------------------------------ 3321 5.2 Procedural Controls 5.2 3322 ------------------------------------------------------ 3323 5.2.1 Trusted Roles 5.2.1, 5.2.4 3325 ------------------------------------------------------ 3326 5.2.2 Number of Persons 3327 Required per Task 5.2.2, 5.2.4 3328 ------------------------------------------------------ 3329 5.2.3 Identification and 3330 Authentication for Each Role 5.2.3 3331 ------------------------------------------------------ 3332 5.3 Personnel Controls 5.3 3333 ------------------------------------------------------ 3334 5.3.1 Background, Qualifications, 3335 Experience, and Clearance 3336 Requirements 5.3.1 3337 ------------------------------------------------------ 3338 5.3.2 Background Check Procedures 5.3.2 3339 ------------------------------------------------------ 3340 5.3.3 Training Requirements 5.3.3 3341 ------------------------------------------------------ 3342 5.3.4 Retraining Frequency 3343 and Requirements 5.3.4 3344 ------------------------------------------------------ 3345 5.3.5 Job Rotation Frequency 3346 and Sequence 5.3.5 3347 ------------------------------------------------------ 3348 5.3.6 Sanctions for 3349 Unauthorized Actions 5.3.6 3350 ------------------------------------------------------ 3351 5.3.7 Contracting Personnel 3352 Requirements 5.3.7 3353 ------------------------------------------------------ 3354 5.3.8 Documentation Supplied to 3355 Personnel 5.3.8 3356 ------------------------------------------------------ 3357 6. Technical Security Controls 6. 3358 ------------------------------------------------------ 3359 6.1 Key Pair Generation and 3360 Installation 6.1 3361 ------------------------------------------------------ 3362 6.1.1 Key Pair Generation 6.1.1 3363 ------------------------------------------------------ 3364 6.1.2 Private Key Delivery to Entity 6.1.2 3365 ------------------------------------------------------ 3366 6.1.3 Public Key Delivery to 3367 Certificate Issuer 6.1.3 3368 ------------------------------------------------------ 3369 6.1.4 CA Public Key Delivery to Users 6.1.4 3370 ------------------------------------------------------ 3371 6.1.5 Key Sizes 6.1.5 3372 ------------------------------------------------------ 3373 6.1.6 Public Key Parameters Generation 6.1.6 3374 ------------------------------------------------------ 3375 6.1.7 Parameter Quality Checking 6.1.6 3376 ------------------------------------------------------ 3377 6.1.8 Hardware/Software Key Generation 6.1.1 3379 ------------------------------------------------------ 3380 6.1.9 Key Usage Purposes 3381 (as per X.509 v3 Key Usage Field) 6.1.9 3382 ------------------------------------------------------ 3383 6.2 Private Key Protection 6.2 3384 ------------------------------------------------------ 3385 6.2.1 Standards for Cryptographic 3386 Module 6.2.1 3387 ------------------------------------------------------ 3389 6.2.2 Private Key (n out of m) 3390 Multi-Person Control 6.2.2 3391 ------------------------------------------------------ 3392 6.2.3 Private Key Escrow 6.2.3 3393 ------------------------------------------------------ 3394 6.2.4 Private Key Backup 6.2.4 3395 ------------------------------------------------------ 3396 6.2.5 Private Key Archival 6.2.5 3397 ------------------------------------------------------ 3398 6.2.6 Private Key Entry Into 3399 Cryptographic Module 6.2.6, 6.2.7 3400 ------------------------------------------------------ 3401 6.2.7 Method of Activating 3402 Private Key 6.2.8 3403 ------------------------------------------------------ 3404 6.2.8 Method of Deactivating 3405 Private Key 6.2.9 3406 ------------------------------------------------------ 3407 6.2.9 Method of Destroying Private 3408 Key 6.2.10 3409 ------------------------------------------------------ 3410 6.3 Other Aspects of Key Pair 3411 Management 6.3 3412 ------------------------------------------------------ 3413 6.3.1 Public Key Archival 6.3.1 3414 ------------------------------------------------------ 3415 6.3.2 Usage Periods for the Public 3416 and Private Keys 6.3.2 3417 ------------------------------------------------------ 3418 6.4 Activation Data 6.4 3419 ------------------------------------------------------ 3420 6.4.1 Activation Data Generation 3421 and Installation 6.4.1 3422 ------------------------------------------------------ 3423 6.4.2 Activation Data Protection 6.4.2 3424 ------------------------------------------------------ 3425 6.4.3 Other Aspects of Activation 3426 Data 6.4.3 3427 ------------------------------------------------------ 3428 6.5 Computer Security Controls 6.5 3429 ------------------------------------------------------ 3430 6.5.1 Specific Computer Security 3431 Technical Requirements 6.5.1 3432 ------------------------------------------------------ 3433 6.5.2 Computer Security Rating 6.5.2 3435 ------------------------------------------------------ 3436 6.6 Life Cycle Technical Controls 6.6 3437 ------------------------------------------------------ 3438 6.6.1 System Development Controls 6.6.1 3439 ------------------------------------------------------ 3440 6.6.2 Security Management Controls 6.6.2 3441 ------------------------------------------------------ 3442 6.6.3 Life Cycle Security Controls 6.6.3 3443 ------------------------------------------------------ 3444 6.7 Network Security Controls 6.7 3445 ------------------------------------------------------ 3446 6.8 Cryptographic Module 3447 Engineering Controls 6.2.1, 6.2, 3448 6.2.1, 6.2.11 3449 ------------------------------------------------------ 3450 7.Certificate and CRL Profiles 7. 3451 ------------------------------------------------------ 3452 7.1 Certificate Profile 7.1 3453 ------------------------------------------------------ 3454 7.1.1 Version Number(s) 7.1.1 3455 ------------------------------------------------------ 3456 7.1.2 Certificate Extensions 7.1.2 3457 ------------------------------------------------------ 3458 7.1.3 Algorithm Object Identifiers 7.1.3 3459 ------------------------------------------------------ 3460 7.1.4 Name Forms 7.1.4 3461 ------------------------------------------------------ 3462 7.1.5 Name Constraints 7.1.5 3463 ------------------------------------------------------ 3464 7.1.6 Certificate Policy Object 3465 Identifier 7.1.6 3466 ------------------------------------------------------ 3467 7.1.7 Usage of Policy Constraints 3468 Extension 7.1.7 3469 ------------------------------------------------------ 3470 7.1.8 Policy Qualifiers Syntax 3471 and Semantics 7.1.8 3472 ------------------------------------------------------ 3473 7.1.9 Processing Semantics for 3474 the Critical Certificate 3475 Policies Extension 7.1.9 3476 ------------------------------------------------------ 3477 7.2 CRL Profile 7.2 3478 ------------------------------------------------------ 3479 7.2.1 Version Number(s) 7.2.1 3480 ------------------------------------------------------ 3481 7.2.2 CRL and CRL Entry Extensions 7.2.1 3482 ------------------------------------------------------ 3483 8. Specification Administration N/A 3484 ------------------------------------------------------ 3485 8.1 Specification Change 3486 Procedures 9.12 3488 ------------------------------------------------------ 3489 8.2 Publication and Notification 3490 Policies 2.2, 2.3 3491 ------------------------------------------------------ 3492 8.3 CPS Approval Procedures 1.5.4 3493 ------------------------------------------------------ 3495 The following matrix shows the sections in the new framework and the sections in RFC 2527 to which the headings in the new framework correspond. 3497 NEW RFC SECTION ORIGINAL RFC 2527 3498 SECTION 3499 ------------------------------------------------------ 3500 1. Introduction 1. 3501 ------------------------------------------------------ 3502 1.1 Overview 1.1 3503 ------------------------------------------------------ 3504 1.2 Document Name and Identification 1.2 3505 ------------------------------------------------------ 3506 1.3 PKI Participants 1.3 3507 ------------------------------------------------------ 3508 1.3.1 Certification Authorities 1.3.1 3509 ------------------------------------------------------ 3510 1.3.2 Registration Authorities 1.3.2 3511 ------------------------------------------------------ 3512 1.3.3 Subscribers 1.3.3 3513 ------------------------------------------------------ 3514 1.3.4 Relying Parties 1.3.3 3515 ------------------------------------------------------ 3516 1.3.5 Other Participants N/A 3517 ------------------------------------------------------ 3518 1.4 Certificate Usage 1.3.4 3519 ------------------------------------------------------ 3520 1.4.1 Appropriate Certificate Uses 1.3.4 3521 ------------------------------------------------------ 3522 1.4.2 Prohibited Certificate Uses 1.3.4 3523 ------------------------------------------------------ 3524 1.5 Policy Administration 1.4 3525 ------------------------------------------------------ 3526 1.5.1 Organization Administering 3527 the Document 1.4.1 3528 ------------------------------------------------------ 3529 1.5.2 Contact Person 1.4.2 3530 ------------------------------------------------------ 3531 1.5.3 Person Determining CPS 3532 Suitability for the Policy 1.4.3 3533 ------------------------------------------------------ 3534 1.5.4 CPS Approval Procedures 8.3 3535 ------------------------------------------------------ 3536 1.6 Definitions and Acronyms N/A 3537 ------------------------------------------------------ 3538 2. Publication and Repository 3539 Responsibilities 2.1.5, 2.6 3541 ------------------------------------------------------ 3542 2.1 Repositories 2.6.4 3543 ------------------------------------------------------ 3544 2.2 Publication of Certification 3545 Information 2.6.1, 8.2 3546 ------------------------------------------------------ 3547 2.3 Time or Frequency of 3548 Publication 2.6.2, 8.2 3549 ------------------------------------------------------ 3550 2.4 Access Controls on Repositories 2.6.3 3551 ------------------------------------------------------ 3552 3. Identification and Authentication 3. 3553 ------------------------------------------------------ 3554 3.1 Naming 3.1 3555 ------------------------------------------------------ 3556 3.1.1 Type of Names 3.1.1 3557 ------------------------------------------------------ 3558 3.1.2 Need for Names to be Meaningful 3.1.2 3559 ------------------------------------------------------ 3560 3.1.3. Anonymity or Pseudonymity of 3561 Subscribers 3.1.2 3562 ------------------------------------------------------ 3563 3.1.4 Rules for Interpreting Various 3564 Name Forms 3.1.3 3565 ------------------------------------------------------ 3566 3.1.5 Uniqueness of Names 3.1.4 3567 ------------------------------------------------------ 3568 3.1.6 Recognition, Authentication, 3569 and Role of Trademarks 3.1.5, 3.1.6 3570 ------------------------------------------------------ 3571 3.2 Initial Identity Validation 3.1 3572 ------------------------------------------------------ 3573 3.2.1 Method to Prove Possession 3574 of Private Key 3.1.7 3575 ------------------------------------------------------ 3576 3.2.2 Authentication of 3577 Organization Identity 3.1.8 3578 ------------------------------------------------------ 3579 3.2.3 Authentication of Individual 3580 Identity 3.1.9 3581 ------------------------------------------------------ 3582 3.2.4 Non-Verified Subscriber 3583 Information N/A 3584 ------------------------------------------------------ 3585 3.2.5 Validation of Authority 3.1.9 3586 ------------------------------------------------------ 3587 3.2.6 Criteria for Interoperation 4.1 3588 ------------------------------------------------------ 3589 3.3 Identification and Authentication 3590 for Re-Key Requests 3.2, 3.3 3591 ------------------------------------------------------ 3592 3.3.1 Identification and 3593 Authentication for Routine 3594 Re-Key 3.2 3596 ------------------------------------------------------ 3597 3.3.2 Identification and 3598 Authentication for Re-Key 3599 After Revocation 3.3 3600 ------------------------------------------------------ 3601 3.4 Identification and Authentication 3602 for Revocation Request 3.4 3603 ------------------------------------------------------ 3604 4. Certificate Life-Cycle 3605 Operational Requirements 4. 3606 ------------------------------------------------------ 3607 4.1 Certificate Application 4.1 3608 ------------------------------------------------------ 3609 4.1.1 Who Can Submit a Certificate 3610 Application 4.1 3611 ------------------------------------------------------ 3612 4.1.2 Enrollment Process and 3613 Responsibilities 2.1.3, 4.1 3614 ------------------------------------------------------ 3615 4.2 Certificate Application 3616 Processing 4.1, 4.2 3617 ------------------------------------------------------ 3618 4.2.1 Performing Identification 3619 and Authentication Functions 4.1, 4.2 3620 ------------------------------------------------------ 3621 4.2.2 Approval or Rejection of 3622 Certificate Applications 4.1, 4.2 3623 ------------------------------------------------------ 3624 4.2.3 Time to Process 3625 Certificate Applications 4.1, 4.2 3626 ------------------------------------------------------ 3627 4.3 Certificate Issuance 4.2 3628 ------------------------------------------------------ 3629 4.3.1 CA Actions During 3630 Certificate Issuance 4.2 3631 ------------------------------------------------------ 3632 4.3.2 Notifications to Subscriber by 3633 the CA of Issuance of Certificate 4.2, 4.3 3634 ------------------------------------------------------ 3635 4.4 Certificate Acceptance 2.1.3, 4.3 3636 ------------------------------------------------------ 3637 4.4.1 Conduct Constituting 3638 Certificate Acceptance 4.3 3639 ------------------------------------------------------ 3640 4.4.2 Publication of the 3641 Certificate by the CA 2.1.5, 2.6.1, 4.3 3642 ------------------------------------------------------ 3643 4.4.3 Notification of 3644 Certificate Issuance by 3645 the CA to Other Entities 2.1.5, 2.6.1, 3646 4.2, 4.3 3648 ------------------------------------------------------ 3649 4.5 Key Pair and 3650 Certificate Usage 1.3.4, 2.1.3, 3651 2.1.4 3652 ------------------------------------------------------ 3653 4.5.1 Subscriber Private Key 3654 and Certificate Usage 1.3.4, 2.1.3 3655 ------------------------------------------------------ 3656 4.5.2 Relying Party Public 3657 Key and Certificate 3658 Usage 1.3.4, 2.1.4 3659 ------------------------------------------------------ 3660 4.6 Certificate Renewal 3.2, 4.1, 4.2, 3661 4.3 3662 ------------------------------------------------------ 3663 4.6.1 Circumstances for 3664 Certificate Renewal 3.2, 4.1 3665 ------------------------------------------------------ 3666 4.6.2 Who May Request Renewal 3.2, 4.1 3667 ------------------------------------------------------ 3668 4.6.3 Processing Certificate 3669 Renewal Requests 3.2, 4.1, 4.2 3670 ------------------------------------------------------ 3671 4.6.4 Notification of New 3672 Certificate Issuance to 3673 Subscriber 3.2, 4.2, 4.3 3674 ------------------------------------------------------ 3675 4.6.5 Conduct Constituting 3676 Acceptance of a Renewal 3677 Certificate 2.1.3, 3.2, 4.3 3678 ------------------------------------------------------ 3679 4.6.6 Publication of the 3680 Renewal Certificate 3681 by the CA 2.1.5, 2.6.1, 3682 3.2, 4.3 3683 ------------------------------------------------------ 3684 4.6.7 Notification of 3685 Certificate Issuance by 3686 the CA to Other Entities 2.1.5, 2.6.1, 3.2, 3687 4.2, 4.3 3688 ------------------------------------------------------ 3689 4.7 Certificate Re-Key 3.2, 4.1, 4.2, 4.3 3690 ------------------------------------------------------ 3691 4.7.1 Circumstances for 3692 Certificate Re-Key 3.2, 4.1 3693 ------------------------------------------------------ 3694 4.7.2 Who May Request Certification 3695 of a New Public Key 3.2, 4.1 3696 ------------------------------------------------------ 3697 4.7.3 Processing Certificate 3698 Re-Keying Requests 3.2, 4.1, 4.2 3700 ------------------------------------------------------ 3701 4.7.4 Notification of New 3702 Certificate Issuance to 3703 Subscriber 3.2, 4.2, 4.3 3704 ------------------------------------------------------ 3705 4.7.5 Conduct Constituting 3706 Acceptance of a 3707 Re-Keyed Certificate 2.1.3, 3.2, 4.3 3708 ------------------------------------------------------ 3709 4.7.6 Publication of the 3710 Re-Keyed Certificate 3711 by the CA 2.1.5, 2.6.1, 3712 3.2, 4.3 3713 ------------------------------------------------------ 3714 4.7.7 Notification of Certificate 3715 Issuance by the CA 3716 to Other Entities 2.1.5, 2.6.1, 3717 3.2, 4.2, 4.3 3718 ------------------------------------------------------ 3719 4.8 Certificate Modification 4.4 3720 ------------------------------------------------------ 3721 4.8.1 Circumstances for 3722 Certificate Modification 2.1.3, 4.4.1 3723 ------------------------------------------------------ 3724 4.8.2 Who May Request Certificate 3725 Modification 4.4.2 3726 ------------------------------------------------------ 3727 4.8.3 Processing Certificate 3728 Modification Requests 4.4.3 3729 ------------------------------------------------------ 3730 4.8.4 Notification of New 3731 Certificate Issuance to 3732 Subscriber 4.2, 4.3, 4.4.3 3733 ------------------------------------------------------ 3734 4.8.5 Conduct Constituting 3735 Acceptance of Modified 3736 Certificate 2.1.3, 4.3, 4.4.3 3737 ------------------------------------------------------ 3738 4.8.6 Publication of the Modified 3739 Certificate by 3740 the CA 2.1.5, 2.6.1, 3741 4.2, 4.3, 4.4.3 3742 ------------------------------------------------------ 3743 4.8.7 Notification of 3744 Certificate Issuance by 3745 the CA to Other 3746 Entities 2.1.5, 2.6.1, 3747 4.2, 4.3, 4.4.3 3748 ------------------------------------------------------ 3749 4.9 Certificate Revocation 3750 and Suspension 4.4 3751 ------------------------------------------------------ 3752 4.9.1 Circumstances for Revocation 2.1.3, 4.4.1 3754 ------------------------------------------------------ 3755 4.9.2 Who Can Request Revocation 4.4.2 3756 ------------------------------------------------------ 3757 4.9.3 Procedure for Revocation 3758 Request 2.1.3, 4.4.3 3759 ------------------------------------------------------ 3760 4.9.4 Revocation Request Grace 3761 Period 4.4.4 3762 ------------------------------------------------------ 3763 4.9.5 Time Within Which CA Must 3764 Process the Revocation Request N/A 3765 ------------------------------------------------------ 3766 4.9.6 Revocation Checking 3767 Requirements for Relying 3768 Parties 2.1.4, 4.4.10, 3769 4.4.12, 4.4.14 3770 ------------------------------------------------------ 3771 4.9.7 CRL Issuance Frequency 4.4.9, 4.8.3 3772 ------------------------------------------------------ 3773 4.9.8 Maximum Latency for CRLs 4.4.9 3774 ------------------------------------------------------ 3775 4.9.9 On-Line Revocation/Status 3776 Checking Availability 4.4.11, 4.8.3 3777 ------------------------------------------------------ 3778 4.9.10 On-Line Revocation 3779 Checking Requirements 4.4.12 3780 ------------------------------------------------------ 3781 4.9.11 Other Forms of Revocation 3782 Advertisements Available 4.4.13, 4.4.14, 3783 4.8.3 3784 ------------------------------------------------------ 3785 4.9.12 Special Requirements re 3786 Key Compromise 4.4.15 3787 ------------------------------------------------------ 3788 4.9.13 Circumstances for Suspension 2.1.3, 4.4.5 3789 ------------------------------------------------------ 3790 4.9.14 Who Can Request Suspension 4.4.6 3791 ------------------------------------------------------ 3792 4.9.15 Procedure for 3793 Suspension Request 2.1.3, 4.4.7 3794 ------------------------------------------------------ 3795 4.9.16 Limits on Suspension Period 4.4.8 3796 ------------------------------------------------------ 3797 4.10 Certificate Status Services 4.4.9-4.4.14 3798 ------------------------------------------------------ 3799 4.10.1 Operational 3800 Characteristics 4.4.9, 4.4.11, 3801 4.4.13 3802 ------------------------------------------------------ 3803 4.10.2 Service Availability 4.4.9, 4.4.11, 3804 4.4.13 3805 ------------------------------------------------------ 3806 4.10.3 Operational Features 4.4.9, 4.4.11, 3807 4.4.13 3809 ------------------------------------------------------ 3810 4.11 End of Subscription N/A 3811 ------------------------------------------------------ 3812 4.12 Key Escrow and Recovery 6.2.3 3813 ------------------------------------------------------ 3814 4.12.1 Key Escrow and Recovery Policy 3815 and Practices 6.2.3 3816 ------------------------------------------------------ 3817 4.12.2 Session Key Encapsulation 3818 and Recovery Policy and 3819 Practices 6.2.3 3820 ------------------------------------------------------ 3821 5. Facility, Management, and 3822 Operational Controls 2.1.3, 2.1.4, 3823 4., 5. 3824 ------------------------------------------------------ 3825 5.1 Physical Controls 5.1 3826 ------------------------------------------------------ 3827 5.1.1 Site Location and Construction 5.1.1 3828 ------------------------------------------------------ 3829 5.1.2 Physical Access 5.1.2 3830 ------------------------------------------------------ 3831 5.1.3 Power and Air Conditioning 5.1.3 3832 ------------------------------------------------------ 3833 5.1.4 Water Exposures 5.1.4 3834 ------------------------------------------------------ 3835 5.1.5 Fire Prevention and Protection 5.1.5 3836 ------------------------------------------------------ 3837 5.1.6 Media Storage 5.1.6 3838 ------------------------------------------------------ 3839 5.1.7 Waste Disposal 5.1.7 3840 ------------------------------------------------------ 3841 5.1.8 Off-Site Backup 5.1.8 3842 ------------------------------------------------------ 3843 5.2 Procedural Controls 5.2 3844 ------------------------------------------------------ 3845 5.2.1 Trusted Roles 5.2.1 3846 ------------------------------------------------------ 3847 5.2.2 Number of Persons Required 3848 per Task 5.2.2 3849 ------------------------------------------------------ 3850 5.2.3 Identification and 3851 Authentication for Each Role 5.2.3 3852 ------------------------------------------------------ 3853 5.2.4 Roles Requiring Separation 3854 of Duties 5.2.1, 5.2.2 3855 ------------------------------------------------------ 3856 5.3 Personnel Controls 5.3 3857 ------------------------------------------------------ 3858 5.3.1 Qualifications, Experience, 3859 and Clearance Requirements 5.3.1 3860 ------------------------------------------------------ 3861 5.3.2 Background Check Procedures 5.3.2 3863 ------------------------------------------------------ 3864 5.3.3 Training Requirements 5.3.3 3865 ------------------------------------------------------ 3866 5.3.4 Retraining Frequency 3867 and Requirements 5.3.4 3868 ------------------------------------------------------ 3869 5.3.5 Job Rotation Frequency 3870 and Sequence 5.3.5 3871 ------------------------------------------------------ 3872 5.3.6 Sanctions for Unauthorized 3873 Actions 5.3.6 3874 ------------------------------------------------------ 3875 5.3.7 Independent Contractor 3876 Requirements 5.3.7 3877 ------------------------------------------------------ 3878 5.3.8 Documentation Supplied to 3879 Personnel 5.3.8 3880 ------------------------------------------------------ 3881 5.4 Audit Logging Procedures 4.5 3882 ------------------------------------------------------ 3883 5.4.1 Types of Events Recorded 4.5.1 3884 ------------------------------------------------------ 3885 5.4.2 Frequency of Processing Log 4.5.2 3886 ------------------------------------------------------ 3887 5.4.3 Retention Period for Audit 3888 Log 4.5.3 3889 ------------------------------------------------------ 3890 5.4.4 Protection of Audit Log 4.5.4 3891 ------------------------------------------------------ 3892 5.4.5 Audit Log Backup Procedures 4.5.5 3893 ------------------------------------------------------ 3894 5.4.6 Audit Collection System 3895 (Internal vs. External) 4.5.6 3896 ------------------------------------------------------ 3897 5.4.7 Notification to Event-Causing 3898 Subject 4.5.7 3899 ------------------------------------------------------ 3900 5.4.8 Vulnerability Assessments 4.5.8 3901 ------------------------------------------------------ 3902 5.5 Records Archival 4.6 3903 ------------------------------------------------------ 3904 5.5.1 Types of Records Archived 4.6.1 3905 ------------------------------------------------------ 3906 5.5.2 Retention Period for Archive 4.6.2 3907 ------------------------------------------------------ 3908 5.5.3 Protection of Archive 4.6.3 3909 ------------------------------------------------------ 3910 5.5.4 Archive Backup Procedures 4.6.4 3911 ------------------------------------------------------ 3912 5.5.5 Requirements for Time-Stamping 3913 of Records 4.6.5 3914 ------------------------------------------------------ 3915 5.5.6 Archive Collection System 3916 (Internal or External) 4.6.6 3918 ------------------------------------------------------ 3919 5.5.7 Procedures to Obtain and 3920 Verify Archive 3921 Information 4.6.7 3923 ------------------------------------------------------ 3924 5.6 Key Changeover 4.7 3925 ------------------------------------------------------ 3926 5.7 Compromise and Disaster Recovery 4.8 3927 ------------------------------------------------------ 3928 5.7.1 Incident and Compromise 3929 Handling Procedures 4.8 3930 ------------------------------------------------------ 3931 5.7.2 Computing Resources, Software, 3932 and/or Data Are Corrupted 4.8.1 3933 ------------------------------------------------------ 3934 5.7.3 Entity Private Key 3935 Compromise Procedures 4.8.3 3936 ------------------------------------------------------ 3937 5.7.4 Business Continuity 3938 Capabilities After a 3939 Disaster 4.8.4 3941 ------------------------------------------------------ 3942 5.8 CA or RA Termination 4.9 3943 ------------------------------------------------------ 3944 6. Technical Security Controls 2.1.3, 2.1.4, 3945 6. 3946 ------------------------------------------------------ 3947 6.1 Key Pair Generation and 3948 Installation 6.1 3949 ------------------------------------------------------ 3950 6.1.1 Key Pair Generation 6.1.1, 6.1.8 3951 ------------------------------------------------------ 3952 6.1.2 Private Key Delivery to 3953 Subscriber 6.1.2 3954 ------------------------------------------------------ 3955 6.1.3 Public Key Delivery to 3956 Certificate Issuer 6.1.3 3957 ------------------------------------------------------ 3958 6.1.4 CA Public Key Delivery to 3959 Relying Parties 6.1.4 3960 ------------------------------------------------------ 3961 6.1.5 Key Sizes 6.1.5 3962 ------------------------------------------------------ 3963 6.1.6 Public Key Parameters Generation 3964 and Quality Checking 6.1.6, 6.1.7 3965 ------------------------------------------------------ 3966 6.1.7 Key Usage Purposes 3967 (as per X.509 v3 3968 Key Usage Field) 6.1.9 3969 ------------------------------------------------------ 3970 6.2 Private Key Protection and 3971 Cryptographic Module 3972 Engineering Controls 6.2, 6.8 3974 ------------------------------------------------------ 3975 6.2.1 Cryptographic Module Standards 3976 and Controls 6.2.1, 6.8 3977 ------------------------------------------------------ 3978 6.2.2 Private Key (n out of m) 3979 Multi-Person Control 6.2.2 3980 ------------------------------------------------------ 3981 6.2.3 Private Key Escrow 6.2.3 3982 ------------------------------------------------------ 3983 6.2.4 Private Key Backup 6.2.4 3984 ------------------------------------------------------ 3985 6.2.5 Private Key Archival 6.2.5 3986 ------------------------------------------------------ 3987 6.2.6 Private Key Transfer Into 3988 or From a Cryptographic 3989 Module 6.2.6 3990 ------------------------------------------------------ 3991 6.2.7 Private Key Storage on 3992 Cryptographic Module 6.2.6 3993 ------------------------------------------------------ 3994 6.2.8 Method of Activating Private 3995 Key 6.2.7 3996 ------------------------------------------------------ 3997 6.2.9 Method of Deactivating 3998 Private Key 6.2.8 3999 ------------------------------------------------------ 4000 6.2.10 Method of Destroying 4001 Private Key 6.2.9 4002 ------------------------------------------------------ 4003 6.2.11 Cryptographic Module Rating 6.2.1, 6.8 4004 ------------------------------------------------------ 4005 6.3 Other Aspects of Key Pair 4006 Management 6.3 4007 ------------------------------------------------------ 4008 6.3.1 Public Key Archival 6.3.1 4009 ------------------------------------------------------ 4010 6.3.2 Certificate Operational 4011 Periods and Key Pair Usage 4012 Periods 6.3.2 4013 ------------------------------------------------------ 4014 6.4 Activation Data 6.4 4015 ------------------------------------------------------ 4016 6.4.1 Activation Data Generation 4017 and Installation 6.4.1 4018 ------------------------------------------------------ 4019 6.4.2 Activation Data Protection 6.4.2 4020 ------------------------------------------------------ 4021 6.4.3 Other Aspects of Activation 4022 Data 6.4.3 4023 ------------------------------------------------------ 4024 6.5 Computer Security Controls 6.5 4025 ------------------------------------------------------ 4026 6.5.1 Specific Computer Security 4027 Technical Requirements 6.5.1 4028 ------------------------------------------------------ 4030 ------------------------------------------------------ 4031 6.5.2 Computer Security Rating 6.5.2 4032 ------------------------------------------------------ 4033 6.6 Life Cycle Technical Controls 6.6 4034 ------------------------------------------------------ 4035 6.6.1 System Development Controls 6.6.1 4036 ------------------------------------------------------ 4037 6.6.2 Security Management Controls 6.6.2 4038 ------------------------------------------------------ 4039 6.6.3 Life Cycle Security Controls 6.6.3 4040 ------------------------------------------------------ 4041 6.7 Network Security Controls 6.7 4042 ------------------------------------------------------ 4043 6.8 Time-Stamping N/A 4044 ------------------------------------------------------ 4045 7. Certificate, CRL, and 4046 OCSP Profiles 7. 4047 ------------------------------------------------------ 4048 7.1 Certificate Profile 7.1 4049 ------------------------------------------------------ 4050 7.1.1 Version Number(s) 7.1.1 4051 ------------------------------------------------------ 4052 7.1.2 Certificate Extensions 7.1.2 4053 ------------------------------------------------------ 4054 7.1.3 Algorithm Object Identifiers 7.1.3 4055 ------------------------------------------------------ 4056 7.1.4 Name Forms 7.1.4 4057 ------------------------------------------------------ 4058 7.1.5 Name Constraints 7.1.5 4059 ------------------------------------------------------ 4060 7.1.6 Certificate Policy 4061 Object Identifier 7.1.6 4062 ------------------------------------------------------ 4063 7.1.7 Usage of Policy Constraints 4064 Extension 7.1.7 4065 ------------------------------------------------------ 4066 7.1.8 Policy Qualifiers Syntax 4067 and Semantics 7.1.8 4068 ------------------------------------------------------ 4069 7.1.9 Processing Semantics for the 4070 Critical Certificate Policies 4071 Extension 7.1.9 4072 ------------------------------------------------------ 4073 7.2 CRL Profile 7.2 4074 ------------------------------------------------------ 4075 7.2.1 Version Number(s) 7.2.1 4076 ------------------------------------------------------ 4077 7.2.2 CRL and CRL Entry Extesions 7.2.1 4078 ------------------------------------------------------ 4079 7.3 OCSP Profile N/A 4080 ------------------------------------------------------ 4081 7.3.1 Version Number(s) N/A 4082 ------------------------------------------------------ 4083 7.3.2 OCSP Extensions N/A 4085 ------------------------------------------------------ 4086 8. Compliance Audit and Other 4087 Assessments 2.7 4088 ------------------------------------------------------ 4089 8.1 Frequency and Circumstances 4090 of Assessment 2.7.1 4091 ------------------------------------------------------ 4092 8.2 Identity/Qualifications of 4093 Assessor 2.7.2 4094 ------------------------------------------------------ 4095 8.3 Assessor's Relationship to 4096 Assessed Entity 2.7.3 4097 ------------------------------------------------------ 4098 8.4 Topics Covered by Assessment 2.7.4 4099 ------------------------------------------------------ 4100 8.5 Actions Taken as a Result 4101 of Deficiency 2.7.5 4102 ------------------------------------------------------ 4103 8.6 Communications of Results 2.7.6 4104 ------------------------------------------------------ 4105 9. Other Business and Legal 4106 Matters 2. 4108 ------------------------------------------------------ 4109 9.1 Fees 2.5 4110 ------------------------------------------------------ 4111 9.1.1 Certificate Issuance or 4112 Renewal Fees 2.5.1 4113 ------------------------------------------------------ 4114 9.1.2 Certificate Access Fees 2.5.2 4115 ------------------------------------------------------ 4116 9.1.3 Revocation or Status 4117 Information Access Fees 2.5.3 4118 ------------------------------------------------------ 4119 9.1.4 Fees for Other Services 2.5.4 4120 ------------------------------------------------------ 4121 9.1.5 Refund Policy 2.5.5 4122 ------------------------------------------------------ 4123 9.2 Financial Responsibility 2.3 4124 ------------------------------------------------------ 4125 9.2.1 Insurance Coverage 2.3 4126 ------------------------------------------------------ 4127 9.2.2 Other Assets 2.3 4128 ------------------------------------------------------ 4129 9.2.3 Insurance or Warranty Coverage 4130 for End-Entities 2.3 4131 ------------------------------------------------------ 4132 9.3 Confidentiality of Business 4133 Information 2.8 4134 ------------------------------------------------------ 4135 9.3.1 Scope of Confidential 4136 Information 2.8.1, 2.8.3 4138 ------------------------------------------------------ 4139 9.3.2 Information Not Within the 4140 Scope of Confidential 4141 Information 2.8.2, 2.8.3 4142 ------------------------------------------------------ 4143 9.3.3 Responsibility to Protect 4144 Confidential Information 2.8, 4146 2.8.3-2.8.7 4147 ------------------------------------------------------ 4148 9.4 Privacy of Personal Information 2.8 4149 ------------------------------------------------------ 4150 9.4.1 Privacy Plan N/A 4151 ------------------------------------------------------ 4152 9.4.2 Information Treated as Private 2.8.1, 2.8.3 4153 ------------------------------------------------------ 4154 9.4.3 Information Not Deemed Private 2.8.2, 2.8.3 4155 ------------------------------------------------------ 4156 9.4.4 Responsibility to Protect 4157 Private Information 2.8, 2.8.1, 4158 2.8.3 4159 ------------------------------------------------------ 4160 9.4.5 Notice and Consent to Use 4161 Private Information N/A 4162 ------------------------------------------------------ 4163 9.4.6 Disclosure Pursuant to 4164 Judicial or Administrative 4165 Process 2.8.4-2.8.5 4166 ------------------------------------------------------ 4167 9.4.7 Other Information Disclosure 4168 Circumstances 2.8.6-2.8.7 4169 ------------------------------------------------------ 4170 9.5 Intellectual Property rights 2.9 4171 ------------------------------------------------------ 4172 9.6 Representations and Warranties 2.2 4173 ------------------------------------------------------ 4174 9.6.1 CA Representations and 4175 Warranties 2.2.1 4176 ------------------------------------------------------ 4177 9.6.2 RA Representations and 4178 Warranties 2.2.2 4179 ------------------------------------------------------ 4180 9.6.3 Subscriber Representations 4181 and Warranties 2.1.3 4182 ------------------------------------------------------ 4184 9.6.4 Relying Party Representations 4185 and Warranties 2.1.4 4186 ------------------------------------------------------ 4187 9.6.5 Representations and Warranties 4188 of Other Participants N/A 4189 ------------------------------------------------------ 4190 9.7 Disclaimers of Warranties 2.2, 2.3.2 4191 ------------------------------------------------------ 4192 9.8 Limitations of Liability 2.2 4193 ------------------------------------------------------ 4195 ------------------------------------------------------ 4196 9.9 Indemnities 2.1.3, 2.1.4, 4197 2.2, 2.3.1 4198 ------------------------------------------------------ 4199 9.10 Term and Termination N/A 4200 ------------------------------------------------------ 4201 9.10.1 Term N/A 4202 ------------------------------------------------------ 4203 9.10.2 Termination N/A 4204 ------------------------------------------------------ 4205 9.10.3 Effect of Termination and 4206 Survival N/A 4207 ------------------------------------------------------ 4208 9.11 Individual Notices and 4209 Communications with Participants 2.4.2 4210 ------------------------------------------------------ 4211 9.12 Amendments 8.1 4212 ------------------------------------------------------ 4213 9.12.1 Procedure for Amendment 8.1 4214 ------------------------------------------------------ 4215 9.12.2 Notification Mechanism 4216 and Period 8.1 4217 ------------------------------------------------------ 4218 9.12.3 Circumstances Under Which OID 4219 Must be Changed 8.1 4220 ------------------------------------------------------ 4221 9.13 Dispute Resolution Provisions 2.4.3 4222 ------------------------------------------------------ 4223 9.14 Governing Law 2.4.1 4224 ------------------------------------------------------ 4225 9.15 Compliance with Applicable Law 2.4.1 4226 ------------------------------------------------------ 4227 9.16 Miscellaneous Provisions 2.4 4228 ------------------------------------------------------ 4229 9.16.1 Entire Agreement 2.4.2 4230 ------------------------------------------------------ 4231 9.16.2 Assignment N/A 4232 ------------------------------------------------------ 4233 9.16.3 Severability 2.4.2 4234 ------------------------------------------------------ 4235 9.16.4 Enforcement (Attorney's Fees 4236 and Waiver of Rights) 2.4.3 4237 ------------------------------------------------------ 4238 9.17 Other Provisions N/A 4239 ------------------------------------------------------ 4241 8. ACKNOWLEDGMENTS 4242 The development of the predecessor document (RFC 2527) was supported 4243 by the Government of Canada's Policy Management Authority (PMA) 4244 Committee, the National Security Agency, the National Institute of 4245 Standards and Technology (NIST), and the American Bar Association 4246 Information Security Committee Accreditation Working Group. 4248 This revision effort is largely a result of constant inspiration 4249 from Michael Baum. Michael Power, Mike Jenkins, and Alice Sturgeon 4250 have also made several contributions. 4252 9. REFERENCES 4254 [ABA1] American Bar Association, Digital Signature Guidelines: 4255 Legal Infrastructure for Certification Authorities and Secure 4256 Electronic Commerce, 1996. 4258 [ABA2] American Bar Association, PKI Assessment Guidelines, v0.30, 4259 Public Draft For Comment, June 2001. 4261 [BAU1] Michael. S. Baum, Federal Certification Authority Liability 4262 and Policy, NIST-GCR-94-654, June 1994, available at 4263 http://www.verisign.com/repository/pubs/index.html. 4265 [ETS] European Telecommunications Standards Institute, "Policy 4266 Requirements for Certification Authorities Issuing Qualified 4267 Certificates," ETSI TS 101 456, Version 1.1.1, December 2000. 4269 [GOC] Government of Canada PKI Policy Management Authority, 4270 "Digital Signature and Confidentiality Certificate Policies for the 4271 Government of Canada Public Key Infrastructure," v.3.02, April 1999. 4273 [IDT] Identrus, LLC, "Identrus Identity Certificate Policy" IP-IPC 4274 Version 1.7, March 2001. 4276 [ISO1] ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information 4277 Technology - Open Systems Interconnection: The Directory: 4278 Authentication Framework," 1997 edition. (Pending publication of 4279 2000 edition, use 1997 edition.) 4281 [PEM1] S. Kent, "Privacy Enhancement for Internet Electronic Mail, 4282 Part II: Certificate-Based Key Management," Internet RFC 1422, 1993. 4284 [PKI1] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509 Public 4285 Key Infrastructure, Certificate and CRL Profile," RFC 2459 1998. 4287 [CPF] S. Chokhani and W. Ford, "Internet X.509 Public Key 4288 Infrastructure, Certificate Policy and Certification Practices 4289 Statement Framework," RFC 2527, April 1998. 4291 10. AUTHORS' ADDRESSES 4293 Santosh Chokhani 4294 Orion Security Solutions, Inc. 4295 3410 N. Buchanan Street, Arlington, VA 22207 4296 (703) 237-4621 (O) 4297 (703) 237-4920 (Fax) 4298 chokhani@orionsec.com 4300 Warwick Ford 4301 VeriSign, Inc. 4302 401 Edgewater Place, Suite 280, Wakefield, MA 01880 4303 Phone: (781) 245-6996 x225 4304 Fax: (781) 245-6006 4305 EMail: wford@verisign.com 4307 Randy V. Sabett, J.D., CISSP 4308 Cooley Godward LLP 4309 One Freedom Square, Reston Town Center 4310 11951 Freedom Drive, Reston, VA 20190-5656 4311 Phone: (703) 456-8137 4312 Fax: (703) 456-8100 4313 EMail: rsabett@cooley.com 4315 Charles (Chas) R. Merrill 4316 McCarter & English, LLP 4317 Four Gateway Center 4318 100 Mulberry Street, Newark, New Jersey 07101-0652 4319 Phone: (973) 622-4444 4320 Fax: (973) 624-7070 4321 EMail: cmerrill@mccarter.com 4323 Stephen S. Wu 4324 Infoliance, Inc. 4325 101 First St. # 725, Los Altos, CA 94022 4326 Phone: (650) 917-8045 4327 Fax: (650) 618-1454 4328 EMail: swu@infoliance.com 4330 NOTES 4331 1 A paper copy of the ABA Digital Signature Guidelines can be 4332 purchased from the ABA. See http://www.abanet.com for ordering 4333 details. The DSG may also be downloaded without charge from the ABA 4334 website at 4335 http://www.abanet.org/scitech/ec/isc/digital_signature.html. 4337 2 A draft of the PKI Assessment Guidelines may be downloaded 4338 without charge from the ABA website at 4339 http://www.abanet.org/scitech/ec/isc/pag/pag.html. 4341 3 The term "meaningful" means that the name form has commonly 4342 understood semantics to determine identity of the person and/or 4343 organization. Directory names and RFC 822 names may be more or less 4344 meaningful. 4346 4 The subject may not need to prove to the CA that the subject has 4347 possession of the private key corresponding to the public key being 4348 registered if the CA generates the subject's key pair on the 4349 subject's behalf. 4351 5 Examples of means to identify and authenticate individuals include 4352 biometric means (such as thumb print, ten finger print, and scan of 4353 the face, palm, or retina), a driver's license, a credit card, a 4354 company badge, and a government badge. 4356 6 Certificate "modification" does not refer to making a change to an 4357 existing certificate, since this would prevent the verification of 4358 any digital signatures on the certificate and cause the certificate 4359 to be invalid. Rather, the concept of "modification" refers to a 4360 situation where the information referred to in the certificate has 4362 changed or should be changed, and the CA issues a new certificate 4363 containing the modified information. One example is a subscriber 4364 that changes his or her name, which would necessitate the issuance 4365 of a new certificate containing the new name. 4367 7 The n out of m rule allows a private key to be split in m parts. 4368 The m parts may be given to m different individuals. Any n parts 4369 out of the m parts may be used to fully reconstitute the private 4370 key, but having any n-1 parts provides one with no information about 4371 the private key. 4373 8 A private key may be escrowed, backed up, or archived. Each of 4374 these functions has a different purpose. Thus, a private key may go 4375 through any subset of these functions depending on the requirements. 4376 The purpose of escrow is to allow a third party (such as an 4377 organization or government) to obtain the private key without the 4378 cooperation of the subscriber. The purpose of back up is to allow 4379 the subscriber to reconstitute the key in case of the destruction or 4380 corruption of the key for business continuity purposes. The 4381 purpose of archive is to provide for reuse of the private key in 4382 future, e.g., use to decrypt a document. 4384 9 WebTrust refers to the "WebTrust Program for Certification 4385 Authorities," from the American Institute of Certified Public 4386 Accountants, Inc., and the Canadian Institute of Chartered 4387 Accountants. 4389 10 See . 4391 11 All or some of the following items may be different for the 4392 various types of entities, i.e., CA, RA, and end entities. 4394 LIST OF ACRONYMS 4395 ABA - American Bar Association 4396 CA - Certification Authority 4397 CP - Certificate Policy 4398 CPS - Certification Practice Statement 4399 CRL - Certificate Revocation List 4400 DAM - Draft Amendment 4401 FIPS - Federal Information Processing Standard 4402 I&A - Identification and Authentication 4403 IEC - International Electrotechnical Commission 4404 IETF - Internet Engineering Task Force 4405 IP - Internet Protocol 4406 ISO - International Organization for Standardization 4407 ITU - International Telecommunications Union 4408 NIST - National Institute of Standards and Technology 4409 OID - Object Identifier 4410 PIN - Personal Identification Number 4411 PKI - Public Key Infrastructure 4412 PKIX - Public Key Infrastructure (X.509) (IETF Working Group) 4413 RA - Registration Authority 4414 RFC - Request For Comment 4415 URL - Uniform Resource Locator 4416 US - United States 4418 < draft-ietf-pkix-ipki-new-rfc2527-02.txt > 4420 Expires in six months from April 22, 2003