idnits 2.17.00 (12 Aug 2021) /tmp/idnits704/draft-ietf-pkix-ipki-new-rfc2527-01.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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 55 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 98 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. 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 (January 3, 2002) is 7442 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 (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PKIX Working Group S. Chokhani (CygnaCom Solutions, Inc.) 2 Internet Draft W. Ford (VeriSign, Inc.) 3 R. Sabett (Cooley Godward LLP) 4 C. Merrill (McCarter & English, LLP) 5 S. Wu (Infoliance, Inc.) 7 Expires in six months from January 3, 2002 9 Internet X.509 Public Key Infrastructure 11 Certificate Policy and Certification Practices Framework 13 < draft-ietf-pkix-ipki-new-rfc2527-01.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 2001. 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 supercede 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. OUTLINE OF A SET OF PROVISIONS 45 147 6. ACKNOWLEDGMENTS 51 148 7. REFERENCES 52 149 8. AUTHORS' ADDRESSES 53 150 NOTES 53 151 LIST OF ACRONYMS 54 153 ----------------------------------------------------------------- 155 1. INTRODUCTION 157 1.1 BACKGROUND 159 In general, a public-key certificate (hereinafter "certificate") 160 binds a public key held by an entity (such as person, organization, 161 account, device, or site) to a set of information that identifies 162 the entity associated with use of the corresponding private key. In 163 most cases involving identity certificates, this entity is known as 164 the "subject" or "subscriber" of the certificate. Two exceptions, 165 however, include devices (in which the subscriber is usually the 166 individual or organization controlling the device) and anonymous 168 certificates (in which the identity of the individual or 169 organization is not available from the certificate itself). 170 Other types of certificates bind public keys to attributes of an 171 entity other than the entity's identity, such as a role, a title, or 172 creditworthiness information. 174 A certificate is used by a "certificate user" or "relying party" 175 that needs to use, and rely upon the accuracy of, the binding 176 between the subject public key distributed via that certificate and 177 the identity and/or other attributes of the subject contained in 178 that certificate. A relying party is frequently an entity that 179 verifies a digital signature from the certificate's subject where 180 the digital signature is associated with an email, web form, 181 electronic document, or other data. Other examples of relying 182 parties can include a sender of encrypted email to the subscriber, a 183 user of a web browser relying on a server certificate during a 184 secure sockets layer (SSL) session, and an entity operating a server 185 that controls access to online information using client certificates 186 as an access control mechanism. In summary, a relying party is an 187 entity that uses a public key in a certificate (for signature 188 verification and/or encryption). The degree to which a relying 189 party can trust the binding embodied in a certificate depends on 190 several factors. These factors can include the practices followed 191 by the certification authority (CA) in authenticating the subject; 192 the CA's operating policy, procedures, and security controls; the 193 scope of the subscriber's responsibilities (for example, in 194 protecting the private key); and the stated responsibilities and 195 liability terms and conditions of the CA (for example, warranties, 196 disclaimers of warranties, and limitations of liability). 198 A Version 3 X.509 certificate may contain a field declaring that one 199 or more specific certificate policies apply to that certificate 200 [ISO1]. According to X.509, a certificate policy (CP) is "a named 201 set of rules that indicates the applicability of a certificate to a 202 particular community and/or class of applications with common 203 security requirements." A CP may be used by a relying party to help 204 in deciding whether a certificate, and the binding therein, are 205 sufficiently trustworthy and otherwise appropriate for a particular 206 application. The CP concept is an outgrowth of the policy statement 207 concept developed for Internet Privacy Enhanced Mail [PEM1] and 208 expanded upon in [BAU1]. 210 A more detailed description of the practices followed by a CA in 211 issuing and otherwise managing certificates may be contained in a 212 certification practice statement (CPS) published by or referenced by 213 the CA. According to the American Bar Association Information 214 Security Committee's Digital Signature Guidelines (hereinafter 215 "DSG")(1) and the Information Security Committee's PKI Assessment 216 Guidelines (hereinafter "PAG")(2), "a CPS is a statement of the 217 practices which a certification authority employs in issuing 218 certificates." [ABA1, ABA2] In general, CPSs also describe practices 219 relating to all certificate lifecycle services (e.g., issuance, 220 management, revocation, and renewal or re-keying), and CPSs provide 221 details concerning other business, legal, and technical matters. 223 The terms contained in a CP or CPS may or may not be binding upon a 224 PKI's participants as a contract. A CP or CPS may itself purport to 225 be a contract. More commonly, however, an agreement may incorporate 226 a CP or CPS by reference and therefore attempt to bind the parties of 227 the agreement to some or all of its terms. For example, some PKIs 228 may utilize a CP or (more commonly) a CPS that is incorporated by 229 reference in the agreement between a subscriber and a CA or RA 230 (called a "subscriber agreement") or the agreement between a relying 231 party and a CA (called a "relying party agreement" or "RPA"). In 232 other cases, however, a CP or CPS has no contractual significance at 233 all. A PKI may intend these CPs and CPSs to be strictly 234 informational or disclosure documents. 236 1.2 PURPOSE 238 The purpose of this document is twofold. First, the document aims 239 to explain the concepts of a CP and a CPS, describe the differences 240 between these two concepts, and describe their relationship to 241 subscriber and relying party agreements. Second, this document aims 242 to present a framework to assist the writers and users of 243 certificate policies or CPSs in drafting and understanding these 244 documents. In particular, the framework identifies the elements 245 that may need to be considered in formulating a CP or a CPS. The 246 purpose is not to define particular certificate policies or CPSs, 247 per se. Moreover, this document does not aim to provide legal advice 248 or recommendations as to particular requirements or practices that 249 should be contained within CPs or CPSs. (Such recommendations, 250 however, appear in [ABA2].) 252 1.3 SCOPE 254 The scope of this document is limited to discussion of the topics 255 that can be covered in a CP (as defined in X.509) or CPS (as defined 256 in the DSG and PAG). In particular, this document describes the 257 types of information that should be considered for inclusion in a CP 258 or a CPS. While the framework as presented generally assumes use of 259 the X.509 version 3 certificate format for the purpose of providing 260 assurances of identity, it is not intended that the material be 261 restricted to use of that certificate format or identity 262 certificates. Rather, it is intended that this framework be 263 adaptable to other certificate formats and to certificates providing 264 assurances other than identity that may come into use. 266 The scope does not extend to defining security policies generally 267 (such as organization security policy, system security policy, or 268 data labeling policy). Further, this document does not define a 269 specific CP or CPS. Moreover, in presenting a framework, this 270 document should be viewed and used as a flexible tool presenting 271 topics that should be considered of particular relevance to CPs or 272 CPSs, and not as a rigid formula for producing CPs or CPSs. 274 This document assumes that the reader is familiar with the general 275 concepts of digital signatures, certificates, and public-key 276 infrastructure (PKI), as used in X.509, the DSG, and the PAG. 278 2. DEFINITIONS 280 This document makes use of the following defined terms: 282 Activation data - Data values, other than keys, that are required to 283 operate cryptographic modules and that need to be protected (e.g., a 284 PIN, a passphrase, or a manually-held key share). 286 Authentication - The process of establishing that individuals, 287 organizations, or things are who or what they claim to be. In the 288 context of a PKI, authentication can be the process of establishing 289 that that an individual or organization applying for or seeking 290 access to something under a certain name is, in fact, the proper 291 individual or organization. This process corresponds to the second 292 process involved with identification, as shown in the definition of 293 "identification" below. Authentication can also refer to a security 294 service that provides assurances that individuals, organizations, or 295 things are who or what they claim to be or that a message or other 296 data originated from a specific individual, organization, or device. 297 Thus, it is said that a digital signature of a message authenticates 298 the message's sender. 300 CA-certificate - A certificate for one CA's public key issued by 301 another CA. 303 Certificate policy (CP) - A named set of rules that indicates the 304 applicability of a certificate to a particular community and/or 305 class of application with common security requirements. For 306 example, a particular CP might indicate applicability of a type of 307 certificate to the authentication of parties engaging in business- 308 to-business transactions for the trading of goods or services within 309 a given price range. 311 Certification path - An ordered sequence of certificates that, 312 together with the public key of the initial object in the path, can 313 be processed to obtain that of the final object in the path. 315 Certification Practice Statement (CPS) - A statement of the 316 practices that a certification authority employs in issuing, 317 managing, revoking, and renewing or re-keying certificates. 319 CPS Summary (or CPS Abstract) - A subset of the provisions of a 320 complete CPS that is made public by a CA. 322 Identification - The process of establishing the identity of an 323 individual or organization, i.e., to show that an individual or 324 organization is a specific individual or organization. In the 325 context of a PKI, identification refers to two processes: (1) 326 establishing that a given name of an individual or organization 327 corresponds to a real-world identity of an individual or 328 organization, and (2) establishing that an individual or 329 organization applying for or seeking access to something under that 330 name is, in fact, the named individual or organization. A person 332 seeking identification may be a certificate applicant, an applicant 333 for employment in a trusted position within a PKI participant, or 334 a person seeking access to a network or software application, such 335 as a CA administrator seeking access to CA systems. 337 Issuing certification authority (issuing CA) - In the context of a 338 particular certificate, the issuing CA is the CA that issued the 339 certificate (see also Subject certification authority). 341 Participant - An individual or organization that plays a role within 342 a given PKI as a subscriber, relying party, CA, RA, certificate 343 manufacturing authority, repository service provider, or similar 344 entity. 346 PKI Disclosure Statement (PDS) - An instrument that supplements a CP 347 or CPS by disclosing critical information about the policies and 348 practices of a CA/PKI. A PDS is a vehicle for disclosing and 349 emphasizing information normally covered in detail by associated CP 350 and/or CPS documents. Consequently, a PDS is not intended to 351 replace a CP or CPS. 353 Policy qualifier - Policy-dependent information that may accompany a 354 CP identifier in an X.509 certificate. Such information can include 355 a pointer to the URL of the applicable CPS or relying party 356 agreement. It may also include text (or number causing the 357 appearance of text) that contains terms of the use of the 358 certificate or other legal information. 360 Registration authority (RA) - An entity that is responsible for one 361 or more of the following functions: the identification and 362 authentication of certificate applicants, the approval or rejection 363 of certificate applications, initiating certificate revocations or 364 suspensions under certain circumstances, processing subscriber 365 requests to revoke or suspend their certificates, and approving or 366 rejecting requests by subscribers to renew or re-key their 367 certificates. RAs, however, do not sign or issue certificates 368 (i.e., an RA is delegated certain tasks on behalf of a CA). [Note: 369 The term Local Registration Authority (LRA) is sometimes used in 370 other documents for the same concept.] 372 Relying party - A recipient of a certificate who acts in reliance on 373 that certificate and/or any digital signatures verified using that 374 certificate. In this document, the terms "certificate user" and 375 "relying party" are used interchangeably. 377 Relying party agreement (RPA) - An agreement between a certification 378 authority and relying party that typically establishes the rights 379 and responsibilities between those parties regarding the 380 verification of digital signatures or other uses of certificates. 382 Set of provisions - A collection of practice and/or policy 383 statements, spanning a range of standard topics, for use in 384 expressing a CP or CPS employing the approach described in this 385 framework. 387 Subject certification authority (subject CA) - In the context of 388 a particular CA-certificate, the subject CA is the CA whose public 389 key is certified in the certificate (see also Issuing certification 390 authority). 392 Subscriber - A subject of a certificate who is issued a certificate. 394 Subscriber Agreement - An agreement between a CA and a subscriber 395 that establishes the right and responsibilities of the parties 396 regarding the issuance and management of certificates. 398 Validation - The process of identification of certificate 399 applicants. "Validation" is a subset of "identification" and refers 400 to identification in the context of establishing the identity of 401 certificate applicants. 403 3. CONCEPTS 405 This section explains the concepts of CP and CPS, and describes 406 their relationship with other PKI documents, such as subscriber 407 agreements and relying party agreements. Other related concepts are 408 also described. Some of the material covered in this section and in 409 some other sections is specific to certificate policies extensions 410 as defined X.509 version 3. Except for those sections, this 411 framework is intended to be adaptable to other certificate formats 412 that may come into use. 414 3.1 CERTIFICATE POLICY 416 When a certification authority issues a certificate, it is providing 417 a statement to a certificate user (i.e., a relying party) that a 418 particular public key is bound to the identity and/or other 419 attributes of a particular entity (the certificate subject, which is 420 usually also the subscriber). The extent to which the relying party 421 should rely on that statement by the CA, however, needs to be 422 assessed by the relying party or entity controlling or coordinating 423 the way relying parties or relying party applications use 424 certificates. Different certificates are issued following different 425 practices and procedures, and may be suitable for different 426 applications and/or purposes. 428 The X.509 standard defines a CP as "a named set of rules that 429 indicates the applicability of a certificate to a particular 430 community and/or class of application with common security 431 requirements" [ISO1]. An X.509 Version 3 certificate may identify a 432 specific applicable CP, which may be used by a relying party to 433 decide whether or not to trust a certificate, associated public key, 434 or any digital signatures verified using the public key for a 435 particular purpose. 437 CPs typically fall into two major categories. First, some CPs 438 "indicate the applicability of a certificate to a particular 439 community" [ISO1]. These CPs set forth requirements for 440 certificate usage and requirements on members of a community. 441 For instance, a CP may focus on the needs of a geographical community, 443 such as the ETSI policy requirements for CAs issuing qualified 444 certificates [ETS]. Also, a CP of this kind may focus on the 445 needs of a specific vertical-market community, such as 446 financial services [IDT]. 448 The second category of typical CPs "indicate the applicability of a 449 certificate to a . . . class of application with common security 450 requirements." These CPs identify a set of applications or uses for 451 certificates and say that these applications or uses require a 452 certain level of security. They then set forth PKI requirements 453 that are appropriate for these applications or uses. A CP within 454 this category often makes sets requirements appropriate for a 455 certain "level of assurance" provided by certificates, relative to 456 certificates issued pursuant to related CPs. These levels of 457 assurance may correspond to "classes" or "types" of certificates. 459 For instance, the Government of Canada PKI Policy Management 460 Authority (GOC PMA) has established eight certificate policies in a 461 single document [GOC], four policies for certificates used for 462 digital signatures and four policies for certificates used for 463 confidentiality encryption. For each of these applications, the 464 document establishes four levels of assurances: rudimentary, basic, 465 medium, and high. The GOC PMA described certain types of digital 466 signature and confidentiality uses in the document, each with a 467 certain set of security requirements, and grouped them into eight 468 categories. The GOC PMA then established PKI requirements for each 469 of these categories, thereby creating eight types of certificates, 470 each providing rudimentary, basic, medium, or high levels of 471 assurance. The progression from rudimentary to high levels 472 corresponds to increasing security requirements and corresponding 473 increasing levels of assurance. 475 A CP is represented in a certificate by a unique number called 476 an "Object Identifier" (OID). That OID, or at least an "arc", can be 477 registered. An "arc" is the beginning of the numerical sequence of 478 an OID and is assigned to a particular organization. The 479 registration process follows the procedures specified in ISO/IEC and 480 ITU standards. The party that registers the OID or arc also can 481 publish the text of the CP, for examination by relying parties. Any 482 one certificate will typically declare a single CP or, possibly, be 483 issued consistent with a small number of different policies. Such 484 declaration appears in the Certificate Policies extension of a X.509 485 Version 3 certificate. When a CA places multiple CPs within a 486 certificate's Certificate Policies extension, the CA is asserting 487 that the certificate is appropriate for use in accordance with any 488 of the listed CPs. 490 CPs also constitute a basis for an audit, accreditation, or another 491 assessment of a CA. Each CA can be assessed against one or more 492 certificate policies or CPSs that it is recognized as implementing. 493 When one CA issues a CA-certificate for another CA, the issuing CA 494 must assess the set of certificate policies for which it trusts the 495 subject CA (such assessment may be based upon an assessment with 496 respect to the certificate policies involved). The assessed set of 498 certificate policies is then indicated by the issuing CA in the 499 CA-certificate. The X.509 certification path processing logic 500 employs these CP indications in its well-defined trust model. 502 3.2 CERTIFICATE POLICY EXAMPLES 504 For example purposes, suppose that the International Air Transport 505 Association (IATA) undertakes to define some certificate policies 506 for use throughout the airline industry, in a PKI operated by IATA 507 in combination with PKIs operated by individual airlines. Two CPs 508 might be defined - the IATA General-Purpose CP, and the IATA 509 Commercial-Grade CP. 511 The IATA General-Purpose CP could be used by industry personnel for 512 protecting routine information (e.g., casual electronic mail) and 513 for authenticating connections from World Wide Web browsers to 514 servers for general information retrieval purposes. The key pairs 515 may be generated, stored, and managed using low-cost, software-based 516 systems, such as commercial browsers. Under this policy, a 517 certificate may be automatically issued to anybody listed as an 518 employee in the corporate directory of IATA or any member airline 519 who submits a signed certificate request form to a network 520 administrator in his or her organization. 522 The IATA Commercial-Grade CP could be used to protect financial 523 transactions or binding contractual exchanges between airlines. 524 Under this policy, IATA could require that certified key pairs be 525 generated and stored in approved cryptographic hardware tokens. 526 Certificates and tokens could be provided to airline employees with 527 disbursement authority. These authorized individuals might then be 528 required to present themselves to the corporate security office, 529 show a valid identification badge, and sign a subscriber agreement 530 requiring them to protect the token and use it only for authorized 531 purposes, as a condition of being issued a token and a certificate. 533 3.3 X.509 CERTIFICATE FIELDS 535 The following extension fields in an X.509 certificate are used to 536 support CPs: 538 * Certificate Policies extension; 539 * Policy Mappings extension; and 540 * Policy Constraints extension. 542 3.3.1 Certificate Policies Extension 544 A Certificate Policies field lists CPs that the certification 545 authority declares are applicable. Using the example of the IATA 546 General-Purpose and Commercial-Grade policies defined in Section 547 3.2, the certificates issued to regular airline employees would 548 contain the object identifier for General-Purpose policy. The 549 certificates issued to the employees with disbursement authority 550 would contain the object identifiers for both the General-Purpose 551 policy and the Commercial-Grade policy. The inclusion of both 553 object identifiers in the certificates means that they would be 554 appropriate for either the General-Purpose or Commercial-Grade 555 policies. The Certificate Policies field may also optionally convey 556 qualifier values for each identified policy; the use of qualifiers 557 is discussed in Section 3.4. 559 When processing a certification path, a CP that is acceptable to the 560 relying party application must be present in every certificate in 561 the path, i.e., in CA-certificates as well as end entity 562 certificates. 564 If the Certificate Policies field is flagged critical, it serves the 565 same purpose as described above but also has an additional role. 566 Specifically, it indicates that the use of the certificate is 567 restricted to one of the identified policies, i.e., the 568 certification authority is declaring that the certificate must only 569 be used in accordance with the provisions of at least one of the 570 listed CPs. This field is intended to protect the certification 571 authority against claims for damages asserted by a relying party who 572 has used the certificate for an inappropriate purpose or in an 573 inappropriate manner, as stipulated in the applicable CP. 575 For example, the Internal Revenue Service might issue certificates 576 to taxpayers for the purpose of protecting tax filings. The 577 Internal Revenue Service understands and can accommodate the risks 578 of erroneously issuing a bad certificate, e.g., to an imposter. 579 Suppose, however, that someone used an Internal Revenue Service tax- 580 filing certificate as the basis for encrypting multi-million-dollar- 581 value proprietary trade secrets, which subsequently fell into the 582 wrong hands because of a cryptanalytic attack by an attacker who is 583 able to decrypt the message. The Internal Revenue Service may want 584 to defend itself against claims for damages in such circumstances by 585 pointing to the criticality of the Certificate Policies extension to 586 show that the subscriber and relying party misused the certificate. 587 The critical-flagged Certificate Policies extension is intended to 588 mitigate the risk to the CA in such situations. 590 3.3.2 Policy Mappings Extension 592 The Policy Mappings extension may only be used in CA-certificates. 593 This field allows a certification authority to indicate that certain 594 policies in its own domain can be considered equivalent to certain 595 other policies in the subject certification authority's domain. 597 For example, suppose that for purposes of facilitating 598 interoperability, the ACE Corporation establishes an agreement with 599 the ABC Corporation to cross-certify the public keys of each others' 600 certification authorities for the purposes of mutually securing 601 their respective business-to-business exchanges. Further, suppose 602 that both companies have pre-existing financial transaction 603 protection policies called ace-e-commerce and abc-e-commerce, 604 respectively. One can see that simply generating cross-certificates 605 between the two domains will not provide the necessary 606 interoperability, as the two companies' applications are configured 608 with, and employee certificates are populated with, their 609 respective certificate policies. One possible solution is to 610 reconfigure all of the financial applications to require either 611 policy and to reissue all the certificates with both policies 612 appearing in their Certificate Policies extensions. Another 613 solution, which may be easier to administer, uses the Policy Mapping 614 field. If this field is included in a cross-certificate for the ABC 615 Corporation certification authority issued by the ACE Corporation 616 certification authority, it can provide a statement that the ABC's 617 financial transaction protection policy (i.e., abc-e-commerce) can 618 be considered equivalent to that of the ACE Corporation (i.e., ace- 619 e-commerce). With such a statement included in the cross- 620 certificate issued to ABC, relying party applications in the ACE 621 domain requiring the presence of the object identifier for the ace- 622 e-commerce CP can also accept, process, and rely upon certificates 623 issued within the ABC domain containing the object identifier for 624 the abc-e-commerce CP. 626 3.3.3 Policy Constraints Extension 628 The Policy Constraints extension supports two optional features. 629 The first is the ability for a certification authority to require 630 that explicit CP indications be present in all subsequent 631 certificates in a certification path. Certificates at the start of 632 a certification path may be considered by a relying party to be part 633 of a trusted domain, i.e., certification authorities are trusted for 634 all purposes so no particular CP is needed in the Certificate 635 Policies extension. Such certificates need not contain explicit 636 indications of CP. When a certification authority in the trusted 637 domain, however, certifies outside the domain, it can activate the 638 requirement that a specific CP's object identifier appear in 639 subsequent certificates in the certification path. 641 The other optional feature in the Policy Constraints field is the 642 ability for a certification authority to disable policy mapping by 643 subsequent certification authorities in a certification path. It 644 may be prudent to disable policy mapping when certifying outside the 645 domain. This can assist in controlling risks due to transitive 646 trust, e.g., a domain A trusts domain B, domain B trusts domain C, 647 but domain A does not want to be forced to trust domain C. 649 3.3.4 Policy Qualifiers 651 The Certificate Policies extension field has a provision for 652 conveying, along with each CP identifier, additional policy- 653 dependent information in a qualifier field. The X.509 standard does 654 not mandate the purpose for which this field is to be used, nor does 655 it prescribe the syntax for this field. Policy qualifier types can 656 be registered by any organization. 658 The following policy qualifier types are defined in PKIX RFC 2459 659 [PKI1]: 661 (a) The CPS Pointer qualifier contains a pointer to a CPS, CPS 662 Summary, RPA, or PDS published by the CA. The pointer is in the 664 form of a uniform resource identifier (URI). 666 (b) The User Notice qualifier contains a text string that is to be 667 displayed to subscribers and relying parties prior to the use of the 668 certificate. The text string may be an IA5String or a BMPString - a 669 subset of the ISO 100646-1 multiple octet coded character set. A CA 670 may invoke a procedure that requires that the relying party 671 acknowledge that the applicable terms and conditions have been 672 disclosed and/or accepted. 674 Policy qualifiers can be used to support the definition of generic, 675 or parameterized, CPs. Provided the base CP so provides, policy 676 qualifier types can be defined to convey, on a per-certificate 677 basis, additional specific policy details that fill in the generic 678 definition. 680 3.4 CERTIFICATION PRACTICE STATEMENT 682 The term certification practice statement (CPS) is defined by the 683 DSG and PAG as: "A statement of the practices which a certification 684 authority employs in issuing certificates." [ABA1, ABA2] As stated 685 above, a CPS establishes practices concerning lifecycle services in 686 addition to issuance, such as certificate management (including 687 publication and archiving), revocation, and renewal or re-keying. In 688 the DSG, the ABA expands this definition with the following comments: 690 "A certification practice statement may take the form of a 691 declaration by the certification authority of the details of its 692 trustworthy system and the practices it employs in its operations 693 and in support of issuance of a certificate . . . ." This form of 694 CPS is the most common type, and can vary in length and level of 695 detail. 697 Some PKIs may not have the need to create a thorough and detailed 698 statement of practices. For example, the CA may itself be the 699 relying party and would already be aware of the nature and 700 trustworthiness of its services. In other cases, a PKI may provide 701 certificates providing only a very low level of assurances where the 702 applications being secured may pose only marginal risks if 703 compromised. In these cases, an organization establishing a PKI 704 may only want to write or have CAs use a subscriber agreement, 705 relying party agreement, or agreement combining subscriber and 706 relying party terms, depending on the role of the different PKI 707 participants. In such a PKI, that agreement may serve as the only 708 "statement of practices" used by one or more CAs within that PKI. 709 Consequently, that agreement may also be considered a CPS and can 710 be entitled or subtitled as such. 712 Likewise, since a detailed CPS may contain sensitive details of its 713 system, a CA may elect not to publish its entire CPS. It may 714 instead opt to publish a CPS Summary (or CPS Abstract). The CPS 715 Summary would contain only those provisions from the CPS that the CA 716 considers to be relevant to the participants in the PKI (such as the 717 responsibilities of the parties or the stages of the certificate 718 lifecycle). A CPS Summary, however, would not contain those 720 sensitive provisions of the full CPS that might provide an 721 attacker with useful information about the CA's operations. 722 Throughout this document, the use of "CPS" includes both a detailed 723 CPS and a CPS Summary (unless otherwise specified). 725 CPSs do not automatically constitute contracts and do not 726 automatically bind PKI participants as a contract would. Where a 727 document serves the dual purpose of being a subscriber or relying 728 party agreement and CPS, the document is intended to be a contract 729 and constitutes a binding contract to the extent that a subscriber 730 or relying party agreement would ordinarily be considered as such. 731 Most CPSs, however, do not serve such a dual purpose. Therefore, in 732 most cases, a CPS's terms have a binding effect as contract terms 733 only if a separate document creates a contractual relationship 734 between the parties and that document incorporates part or all of 735 the CPS by reference. Further, if a particular PKI employs a CPS 736 Summary (as opposed to the entire CPS), the CPS Summary could be 737 incorporated into any applicable subscriber or relying party 738 agreement. 740 In the future, a court or applicable statutory or regulatory law may 741 declare that a certificate itself is a document that is capable of 742 creating a contractual relationship, to the extent its mechanisms 743 designed for incorporation by reference (such as the Certificate 744 Policies extension and its qualifiers) indicate that terms of its 745 use appear in certain documents. In the meantime, however, some 746 subscriber agreements and relying party agreements may incorporate a 747 CPS by reference and therefore make its terms binding on the parties 748 to such agreements. 750 3.5 RELATIONSHIP BETWEEN CERTIFICATE POLICY AND CERTIFICATION 751 PRACTICE STATEMENT 753 The CP and CPS address the same set of topics that are of interest 754 to the relying party in terms of the degree to and purpose for which 755 a public key certificate should be trusted. Their primary 756 difference is in the focus of their provisions. A CP sets forth the 757 requirements and standards imposed by the PKI with respect to the 758 various topics. In other words, the purpose of the CP is to 759 establish what participants must do. A CPS, by contrast, states how 760 a CA and other participants in a given domain implement procedures 761 and controls to meet the requirements stated in the CP. In other 762 words, the purpose of the CPS is to disclose how the participants 763 perform their functions and implement controls. 765 An additional difference between a CP and CPS relates the scope of 766 coverage of the two kinds of documents. Since a CP is a statement 767 of requirements, it best serves as the vehicle for communicating 768 minimum operating guidelines that must be met by interoperating PKIs. 769 Thus, a CP generally applies to multiple CAs, multiple organizations, 770 or multiple domains. By contrast, a CPS applies only to a single CA 771 or single organization and is not generally a vehicle to facilitate 772 interoperation. 774 A CA with a single CPS may support multiple CPs (used for 775 different application purposes and/or by different relying party 776 communities). Also, multiple CAs, with non-identical CPSs, may 777 support the same CP. 779 For example, the Federal Government might define a government-wide 780 CP for handling confidential human resources information. The CP 781 will be a broad statement of the general requirements for 782 participants within the Government's PKI, and an indication of the 783 types of applications for which it is suitable for use. Each 784 department or agency wishing to operate a certification authority in 785 this PKI may be required to write its own certification practice 786 statement to support this CP by explaining how it meets the 787 requirements of the CP. At the same time, a department's or 788 agency's CPS may support other certificate policies. 790 An additional difference between a CP and CPS concerns the level of 791 detail of the provisions in each. Although the level of detail may 792 vary among CPSs, a CPS will generally be more detailed than a CP. A 793 CPS provides a detailed description of procedures and controls in 794 place to meet the CP requirements, while a CP is more general. 796 The main differences between CPs and CPSs can therefore be 797 summarized as follows: 799 (a) A PKI uses a CP to establish requirements that state what 800 participants within it must do. A single CA or organization can use 801 a CPS to disclose how it meets the requirements of a CP or how it 802 implements its practices and controls. 804 (b) A CP facilitates interoperation through cross-certification, 805 unilateral certification, or other means. Therefore, it is intended 806 to cover multiple CAs. By contrast, a CPS is a statement of a 807 single CA or organization. Its purpose is not to facilitate 808 interoperation (since doing so is the function of a CP). 810 (c) A CPS is generally more detailed than a CP and specifies how 811 the CA meets the requirements specified in the one or more CPs under 812 which it issues certificates. 814 In addition to populating the certificate policies extension with 815 the applicable CP object identifier, a certification authority may 816 include, in certificates it issues, a reference to its certification 817 practice statement. A standard way to do this, using a CP 818 qualifier, is described in Section 3.4. 820 3.6 RELATIONSHIP AMONG CPs, CPSs, AGREEMENTS, AND OTHER DOCUMENTS 822 CPs and CPSs play a central role in documenting the requirements and 823 practices of a PKI. Nonetheless, they are not the only documents 824 relevant to a PKI. For instance, subscriber agreements and relying 825 party agreements play a critical role in allocating responsibilities 826 to subscribers and relying parties relating to the use of 827 certificates and key pairs, and establish the terms and conditions 829 under which certificates are issued, managed, and used. The term 830 subscriber agreement is defined by the PAG as: "An agreement 831 between a CA and a subscriber that establishes the right and 832 obligations of the parties regarding the issuance and management of 833 certificates." [ABA2] The PAG defines a relying party agreement as: 834 "An agreement between a certification authority and relying party 835 that typically establishes the rights and obligations between those 836 parties regarding the verification of digital signatures or other 837 uses of certificates." [ABA2] 839 As mentioned in Section 3.5, a subscriber agreement, relying party 840 agreement, or an agreement that combines subscriber and relying 841 party terms may also serve as a CPS. In other PKIs, however, a 842 subscriber or relying party agreement may incorporate some or all of 843 the terms of a CP or CPS by reference. Yet other PKIs may distill 844 from a CP and/or CPS the terms that are applicable to a subscriber 845 and place such terms in a self-contained subscriber agreement, 846 without incorporating a CP or CPS by reference. They may use the 847 same method to distill relying party terms from a CP and/or CPS and 848 place such terms in a self-contained relying party agreement. 849 Creating such self-contained agreements has the advantage of 850 creating documents that are easier for consumers to review. In some 851 cases, subscribers or relying parties may be deemed to be 852 "consumers" under applicable law, who are subject to certain 853 statutory or regulatory protections. Under the legal systems of 854 civil law countries, incorporating a CP or CPS by reference may not 855 be effective to bind consumers to the terms of an incorporated CP or 856 CPS. 858 CPs and CPSs may be incorporated by reference in other documents, 859 including: 860 * Interoperability agreements (including agreements between CAs for 861 cross-certification, unilateral certification, or other forms of 862 interoperation), 863 * Vendor agreements (under which a PKI vendor agrees to meet 864 standards set forth in a CP or CPS), or 865 * A PDS. 866 See [ABA2] 868 A PDS serves a similar function to a CPS Summary. It is a 869 relatively short document containing only a subset of critical 870 details about a PKI or CA. It may differ from a CPS Summary, 871 however, in that its purpose is to act as a summary of information 872 about the overall nature of the PKI, as opposed to simply a 873 condensed form of the CPS. Moreover, its purpose is to distill 874 information about the PKI, as opposed to protecting security 875 sensitive information contained in an unpublished CPS, although a 876 PDS could also serve that function. 878 Just as writers may wish to refer to a CP or CPS or incorporate it 879 by reference in an agreement or PDS, a CP or CPS may refer to other 880 documents when establishing requirements or making disclosures. For 881 instance, a CP may set requirements for certificate content by 882 referring to an external document setting forth a standard 884 certificate profile. Referencing external documents permits a CP 885 or CPS to impose detailed requirements or make detailed disclosures 886 without having to reprint lengthy provisions from other documents 887 within the CP or CPS. Moreover, referencing a document in a CP or 888 CPS is another useful way of dividing disclosures between public 889 information and security sensitive confidential information (in 890 addition to or as an alternative to publishing a CPS Summary). For 891 example, a PKI may want to publish a CP or CPS, but maintain site 892 construction parameters for CA high security zones as confidential 893 information. In that case, the CP or CPS could reference an 894 external manual or document containing the detailed site 895 construction parameters. 897 Documents that a PKI may wish to refer to in a CP or CPS include: 898 * A security policy, 899 * Training, operational, installation, and user manuals (which may 900 contain operational requirements), 901 * Standards documents that apply to particular aspects of the PKI 902 (such as standards specifying the level of protection offered by any 903 hardware tokens used in the PKI or standards applicable to the site 904 construction), 905 * Key management plans, 906 * Human resource guides and employment manuals (which may describe 907 some aspects of personnel security practices), and 908 * E-mail policies (which may discuss subscriber and relying party 909 responsibilities, as well as the implications of key management, if 910 applicable). 911 See [ABA2] 913 3.7 SET OF PROVISIONS 915 A set of provisions is a collection of practice and/or policy 916 statements, spanning a range of standard topics, for use in 917 expressing a CP or CPS employing the approach described in this 918 framework by covering the topic appearing in Section 5 below, which 919 are described in detail in Section 4 below. 921 A CP can be expressed as a single set of provisions. 923 A CPS can be expressed as a single set of provisions with each 924 component addressing the requirements of one or more certificate 925 policies, or, alternatively, as an organized collection of sets of 926 provisions. For example, a CPS could be expressed as a combination 927 of the following: 929 (a) a list of certificate policies supported by the CPS; 931 (b) for each CP in (a), a set of provisions that contains 932 statements responding to that CP by filling in details not 933 stipulated in that policy or expressly left to the discretion of the 934 CA (in its CPS) ; such statements serve to state how this particular 935 CPS implements the requirements of the particular CP; or 937 (c) a set of provisions that contains statements regarding the 938 certification practices on the CA, regardless of CP. 940 The statements provided in (b) and (c) may augment or refine the 941 stipulations of the applicable CP, but generally must not conflict 942 with any of the stipulations of such CP. In certain cases, however, 943 a policy authority may permit exceptions to the requirements in a 944 CP, because certain compensating controls of the CA are disclosed in 945 its CPS that allow the CA to provide assurances that are equivalent 946 to the assurances provided by CAs that are in full compliance with 947 the CP. 949 This framework outlines the contents of a set of provisions, in 950 terms of nine primary components, as follows: 952 1. Introduction 953 2. Publication and Repository 954 3. Identification and Authentication 955 4. Certificate Life-Cycle Operational Requirements 956 5. Facilities, Management, and Operational Controls 957 6. Technical Security Controls 958 7. Certificate, CRL, and OCSP Profile 959 8. Compliance audit 960 9. Other Business and Legal Matters 962 PKIs can use this simple framework of nine primary components to 963 write a simple CP or CPS. Moreover, a CA can use this same 964 framework to write a subscriber agreement, relying party agreement, 965 or agreement containing subscriber and relying party terms. If a CA 966 uses this simple framework to construct an agreement, it can use 967 paragraph 1 as an introduction or recitals, it can set forth the 968 responsibilities of the parties in paragraphs 2-8, and it can use 969 paragraph 9 to cover the business and legal issues described in more 970 detail in, and using the ordering of, Section 4.9 below (such as 971 representations and warranties, disclaimers, and liability 972 limitations). The ordering of topics in this simple framework and 973 the business and legal matters Section 4.9 is the same as (or 974 similar to) the ordering of topics in a typical software or other 975 technology agreement. Therefore, a PKI can establish a set of core 976 documents (with a CP, CPS, subscriber agreement, and relying party 977 agreement) all having the same structure and ordering of topics, 978 thereby facilitating comparisons and mappings among these documents 979 and among the corresponding documents of other PKIs. 981 This simple framework may also be useful for agreements other than 982 subscriber agreements and relying party agreements. For instance, a 983 CA wishing to outsource certain services to an RA or certificate 984 manufacturing authority (CMA) may find it useful to use this 985 framework as a checklist to write a registration authority agreement 986 or outsourcing agreement. Similarly, two CAs may wish to use this 987 simple framework for the purpose of drafting a cross-certification, 988 unilateral certification, or other interoperability agreement. 990 In short, the primary components of the simple framework 991 (specified above) may meet the needs of drafters of short CPs, CPSs, 992 subscriber agreements, and relying party agreements. Nonetheless, 993 this framework is extensible, and its coverage of the nine 994 components is flexible enough to meet the needs of drafters of 995 comprehensive CPs and CPSs. Specifically, components appearing above 996 can be further divided into subcomponents, and a subcomponent may 997 comprise multiple elements. Section 4 provides a more detailed 998 description of the contents of the above components, and their 999 subcomponents. Drafters of CPs and CPSs are permitted to add 1000 additional levels of subcomponents below the subcomponents described 1001 in Section 4 for the purpose of meeting the needs of the drafter's 1002 particular PKI. 1004 4. CONTENTS OF A SET OF PROVISIONS 1006 This section expands upon the contents of the simple framework of 1007 provisions, as introduced in Section 3.7. The topics identified in 1008 this section are, consequently, candidate topics for inclusion in a 1009 detailed CP or CPS. 1011 While many topics are identified, it is not necessary for a CP or a 1012 CPS to include a concrete statement for every such topic. Rather, a 1013 particular CP or CPS may state "no stipulation" for a component, 1014 subcomponent, or element on which the particular CP or CPS imposes 1015 no requirements or makes no disclosure. In this sense, the list of 1016 topics can be considered a checklist of topics for consideration by 1017 the CP or CPS writer. 1019 It is recommended that each and every component and subcomponent be 1020 included in a CP or CPS, even if there is "no stipulation"; this 1021 will indicate to the reader that a conscious decision was made to 1022 include or exclude a provision concerning that topic. This drafting 1023 style protects against inadvertent omission of a topic, while 1024 facilitating comparison of different certificate policies or CPSs, 1025 e.g., when making policy mapping decisions. 1027 In a CP, it is possible to leave certain components, subcomponents, 1028 and/or elements unspecified, and to stipulate that the required 1029 information will be indicated in a policy qualifier, or the document 1030 to which a policy qualifier points. Such CPs can be considered 1031 parameterized definitions. The set of provisions should reference 1032 or define the required policy qualifier types and should specify any 1033 applicable default values. 1035 4.1 INTRODUCTION 1037 This component identifies and introduces the set of provisions, and 1038 indicates the types of entities and applications for which the 1039 document (either the CP or the CPS being written) is targeted. 1041 4.1.1 Overview 1043 This subcomponent provides a general introduction to the document 1044 being written. This subcomponent can also be used to provide a 1046 synopsis of the PKI to which the CP or CPS applies. For example, 1047 it may set out different levels of assurance provided by 1048 certificates within the PKI. Depending on the complexity and scope 1049 of the particular PKI, a diagrammatic representation of the PKI 1050 might be useful here. 1052 4.1.2 Document Name and Identification 1054 This subcomponent provides any applicable names or other 1055 identifiers, including ASN.1 object identifiers, for the document. 1056 An example of such a document name would be the US Federal 1057 Government Policy for Secure E-mail. 1059 4.1.3 PKI Participants 1061 This subcomponent describes the identity or types of entities that 1062 fill the roles of participants within a PKI, namely: 1064 * Certification authorities, i.e., the entities that issue 1065 certificates. A CA is the issuing CA with respect to the 1066 certificates it issues and is the subject CA with respect to the CA 1067 certificate issued to it. CAs may be organized in a hierarchy in 1068 which an organization's CA issues certificates to CAs operated by 1069 subordinate organizations, such as a branch, division, or department 1070 within a larger organization. 1072 * Registration authorities, i.e., the entities that establishment 1073 enrollment procedures for end-user certificate applicants, perform 1074 identification and authentication of certificate applicants, 1075 initiate or pass along revocation requests for certificates, and 1076 approve applications for renewal or re-keying certificates on behalf 1077 of a CA. Subordinate organizations within a larger organization can 1078 act as RAs for the CA serving the entire organization, but RAs may 1079 also be external to the CA. 1081 * Subscribers. Examples of subscribers who receive certificates 1082 from a CA include employees of an organization with its own CA, 1083 banking or brokerage customers, organizations hosting e-commerce 1084 sites, organizations participating in a business-to-business 1085 exchange, and members of the public receiving certificates from a CA 1086 issuing certificates to the public at large. 1088 * Relying parties. Examples of relying parties include employees of 1089 an organization having its own CA who receive digitally signed e- 1090 mails from other employees, persons buying goods and services from 1091 e-commerce sites, organizations participating in a business-to- 1092 business exchange who receive bids or orders from other 1093 participating organizations, and individuals and organizations doing 1094 business with subscribers who have received their certificates from 1095 a CA issuing certificates to the public. Relying parties may or may 1096 not also be subscribers within a given PKI. 1098 * Other participants, such as certificate manufacturing 1099 authorities, providers of repository services, and other entities 1100 providing PKI-related services. 1102 4.1.4 Certificate usage 1104 This subcomponent contains: 1106 * A list or the types of applications for which the issued 1107 certificates are suitable, such as electronic mail, retail 1108 transactions, contracts, and a travel order, and/or 1110 * A list or the types of applications for which use of the issued 1111 certificates is prohibited. 1113 In the case of a CP or CPS describing different levels of assurance, 1114 this subcomponent can describe applications or types of applications 1115 that are appropriate or inappropriate for the different levels of 1116 assurance. 1118 4.1.5 Policy Administration 1120 This subcomponent includes the name and mailing address of the 1121 organization that is responsible for the drafting, registering, 1122 maintaining, and updating of this CP or CPS. It also includes the 1123 name, electronic mail address, telephone number, and fax number of a 1124 contact person. As an alternative to naming an actual person, the 1125 document may name a title or role, an e-mail alias, and other 1126 generalized contact information. In some cases, the organization may 1127 state that its contact person, alone or in combination with others, 1128 is available to answer questions about the document. 1130 Moreover, when a formal or informal policy authority is responsible 1131 for determining whether a CA should be allowed to operate within or 1132 interoperate with a PKI, it may wish to approve the CPS of the CA as 1133 being suitable for the policy authority's CP. If so, this 1134 subcomponent can include the name or title, electronic mail address 1135 (or alias), telephone number, fax number, and other generalized 1136 information of the entity in charge of making such a determination. 1137 Finally, in this case, this subcomponent also includes the 1138 procedures by which this determination is made. 1140 4.1.6 Definitions and acronyms 1141 This subcomponent contains a list of definitions for defined terms 1142 used within the document, as well as a list of acronyms in the 1143 document and their meanings. 1145 4.2 PUBLICATION AND REPOSITORY RESPONSIBILITIES 1147 This component contains any applicable provisions regarding: 1148 * An identification of the entity or entities that operate 1149 repositories within the PKI, such as a CA, certificate manufacturing 1150 authority, or independent repository service provider; 1152 *The responsibility of a PKI participant to publish information 1153 regarding its practices, certificates, and the current status of 1154 such certificates, which may include the responsibilities of making 1155 the CP or CPS publicly available using various mechanisms and of 1157 identifying components, subcomponents, and elements of such 1158 documents that exist but are not made publicly available, for 1159 instance, security controls, clearance procedures, or trade secret 1160 information due to their sensitivity; 1162 * When information must be published and the frequency of 1163 publication; and 1165 * Access control on published information objects including CPs, 1166 CPS, certificates, certificate status, and CRLs. 1168 4.3 IDENTIFICATION AND AUTHENTICATION 1170 This component describes the procedures used to authenticate the 1171 identity and/or other attributes of an end-user certificate 1172 applicant to a CA or RA prior to certificate issuance. In addition, 1173 the component sets forth the procedures for authenticating the 1174 identity and the criteria for accepting applicants of entities 1175 seeking to become CAs, RAs, or other entities operating in or 1176 interoperating with a PKI. It also describes how parties requesting 1177 re-key or revocation are authenticated. This component also 1178 addresses naming practices, including the recognition of trademark 1179 rights in certain names. 1181 4.3.1 Naming 1183 This subcomponent includes the following elements regarding naming 1184 and identification of the subscribers: 1186 * Types of names assigned to the subject, such as X.500 1187 distinguished names; RFC-822 names; and X.400 names; 1189 * Whether names have to be meaningful or not;(3) 1191 * Whether or not subscribers can be anonymous or pseudonymous, and, 1192 if they can, what names are assigned to or can be used by anonymous 1193 subscribers; 1195 * Rules for interpreting various name forms, such as the X.500 1196 standard and RFC-822; 1198 * Whether names have to be unique; and 1200 * Recognition, authentication, and role of trademarks. 1202 4.3.2 Initial Identity Validation 1204 This subcomponent contains the following elements for the 1205 identification and authentication procedures for the initial 1206 registration for each subject type (CA, RA, subscriber, or other 1207 participant): 1209 * If and how the subject must prove possession of the companion 1210 private key for the public key being registered, for example, a 1211 digital signature in the certificate request message;(4) 1213 * Identification and authentication requirements for 1214 organizational identity of subscriber or participant (CA; RA; 1215 subscriber (in the case of certificates issued to organizations or 1216 devices controlled by an organization), or other participant), for 1217 example, consulting the database of a service that identifies 1218 organizations or inspecting an organization's articles of 1219 incorporation; 1221 * Identification and authentication requirements for an individual 1222 subscriber or a person acting on behalf of an organizational 1223 subscriber or participant (CA, RA, in the case of certificates 1224 issued to organizations or devices controlled by an organization, 1225 the subscriber, or other participant),(5) including: 1227 * Type of documentation and/or number of identification credentials 1228 required; 1229 * How a CA or RA authenticates the identity of the organization or 1230 individual based on the documentation or credentials provided; 1231 * If the individual must present personally to the authenticating CA 1232 or RA; 1233 * How an individual as an organizational person is authenticated, 1234 such as by reference to duly signed authorization documents or a 1235 corporate identification badge. 1237 * List of subscriber information that is not verified (called "non- 1238 verified subscriber information") during the initial registration; 1240 * Validation of authority involves a determination of whether a 1241 person has specific rights, entitlements, or permissions, including 1242 the permission to act on behalf of an organization to obtain a 1243 certificate; and 1245 * In the case of applications by a CA wishing to operate within, or 1246 interoperate with, a PKI, this subcomponent contains the criteria by 1247 which a PKI, CA, or policy authority determines whether or not the 1248 CA is suitable for such operations or interoperation. Such 1249 interoperation may include cross-certification, unilateral 1250 certification, or other forms of interoperation. 1252 4.3.3 Identification and Authentication for Re-key Requests 1254 This subcomponent addresses the following elements for the 1255 identification and authentication procedures for re-key for each 1256 subject type (CA, RA, subscriber, and other participants): 1258 * Identification and authentication requirements for routine re-key, 1259 such as a re-key request that contains the new key and is signed 1260 using the current valid key; and 1262 * Identification and authentication requirements for re-key after 1263 certificate revocation. One example is the use of the same process 1264 as the initial identity validation. 1266 4.3.4 Identification and Authentication for Revocation Requests 1268 This subcomponent describes the identification and authentication 1269 procedures for a revocation request by each subject type (CA, RA, 1270 subscriber, and other participant). Examples include a revocation 1271 request digitally signed with the private key whose companion public 1272 key needs to be revoked and a digitally signed request by the RA. 1274 4.4 CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS 1276 This component is used to specify requirements imposed upon issuing 1277 CA, subject CAs, RAs, subscribers, or other participants with 1278 respect to the life-cycle of certificate. 1280 Within each subcomponent, separate consideration may need to be 1281 given to subject CAs, RAs, subscribers, and other participants. 1283 4.4.1 Certificate Application 1285 This subcomponent is used to address the following requirements 1286 regarding subject certificate application: 1288 * Who can submit a certificate application, such as a certificate 1289 subject or the RA; and 1291 * Enrollment process used by subjects to submit certificate 1292 applications and responsibilities in connection with this process. 1293 An example of this process is where the subject generates the key 1294 pair and sends a certificate request to the RA. The RA validates 1295 and signs the request and sends it to the CA. A CA or RA may have 1296 the responsibility to establish an enrollment process in order to 1297 receive certificate applications. Likewise, certificate applicants 1298 may have the responsibility to provide accurate information on their 1299 certificate applications. 1301 4.4.2 Certificate Application Processing 1303 This subcomponent is used to describe the procedure for processing 1304 certificate applications. For example, the issuing CA and RA may 1305 perform identification and authentication procedures to validate the 1306 certificate application. Following such steps, the CA or RA will 1307 either approve or reject the certificate application, perhaps upon 1308 the application of certain criteria. Finally, this subcomponent 1309 sets for the time in which a CA and/or RA must act on and process a 1310 certificate application. 1312 4.4.3 Certificate Issuance 1314 This subcomponent is used to describe the following certificate 1315 issuance related elements: 1317 * Actions performed by the CA during the issuance of the 1318 certificate, for example a procedure whereby the CA validates the RA 1319 signature and RA authority and generates a certificate; and 1321 * Notification mechanisms, if any, used by the CA to notify the 1322 subscriber of the issuance of the certificate; an example is a 1323 procedure under which the CA e-mails the certificate to the 1324 subscriber or the RA or e-mails information permitting the 1325 subscriber to download the certificate from a web site. 1327 4.4.4 Certificate Acceptance 1329 This subcomponent addresses the following: 1331 * The conduct of an applicant that will be deemed to constitute 1332 acceptance of the certificate. Such conduct may include affirmative 1333 steps to indicate acceptance, actions implying acceptance, or a 1334 failure to object to the certificate or its content. For instance, 1335 acceptance may be deemed to occur if the CA does not receive any 1336 notice from the subscriber within a certain time period; a 1337 subscriber may send a signed message accepting the certificate; or a 1338 subscriber may send a signed message rejecting the certificate where 1339 the message includes the reason for rejection and identifies the 1340 fields in the certificate that are incorrect or incomplete. 1342 * Publication of the certificate by the CA. For example, the CA may 1343 post the certificate to an X.500 or LDAP repository. 1345 * Notification of certificate issuance by the CA to other entities. 1346 As an example, the CA may send the certificate to the RA. 1348 4.4.5 Key Pair and Certificate Usage 1350 This subcomponent is used to describe the responsibilities relating 1351 to the use of keys and certificates, including: 1353 * Subscriber responsibilities relating to use of the subscriber's 1354 private key and certificate. For example, the subscriber may be 1355 required to use a private key and certificate only for appropriate 1356 applications as set forth in the CP and consistent with applicable 1357 certificate content (e.g., key usage field), use of a private key 1358 and certificate are subject to the terms of the subscriber 1359 agreement, the use of a private key is permitted only after the 1360 subscriber has accepted the corresponding certificate, or subscriber 1361 must discontinue use of the private key following expiration or 1362 revocation of the certificate. 1364 * Relying party responsibilities relating to the use of a 1365 subscriber's public key and certificate. For instance, a relying 1366 party may be obligated to rely on certificates only for appropriate 1367 applications as set forth in the CP and consistent with applicable 1368 certificate content (e.g., key usage field), successfully perform 1369 public key operations as a condition of relying on a certificate, 1370 responsibility to check the status of certificate using one of the 1371 required or permitted mechanisms set forth in the CP/CPS (see 1372 Section 4.4.9 below), and assent to the terms of the applicable 1373 relying party agreement as a condition of relying on the 1374 certificate. 1376 4.4.6 Certificate Renewal 1378 This subcomponent is used to describe the following elements related 1379 to certificate renewal. Certificate renewal means issuance of a new 1380 certificate to the subscriber without changing the subscriber or 1381 other participant's public key or any other information in the 1382 certificate: 1384 * Circumstances under which certificate renewal takes place, such as 1385 where the certificate life has expired, but the policy permits the 1386 same key pair to be reused; 1388 * Who may request certificate renewal, for instance, the subscriber, 1389 RA, or the CA may automatically renew an end-user subscriber 1390 certificate; 1392 * A CA or RA's procedures to process renewal requests to issue the 1393 new certificate, for example, the use of a token, such as a 1394 password, to re-authenticate the subscriber, or procedures that are 1395 the same as the initial certificate issuance; 1397 * Notification of the new certificate to the subscriber; 1399 * Conduct constituting acceptance of the certificate; 1401 * Publication of the certificate by the CA; and 1403 * Notification of certificate issuance by the CA to other entities. 1405 4.4.7 Certificate Re-key 1407 This subcomponent is used to describe the following elements related 1408 to a subscriber or other participant generating a new key pair and 1409 applying for the issuance of new certificate that certifies the new 1410 public key: 1412 * Circumstances under which certificate re-key can or must take 1413 place, such as after a certificate is revoked for the reasons of key 1414 compromise or after a certificate has expired and the usage period 1415 of the key pair has also expired; 1417 * Who may request certificate re-key, for example, the subscriber; 1419 * A CA or RA's procedures to process re-keying requests to issue the 1420 new certificate, such as procedures that are the same as the initial 1421 certificate issuance; 1423 * Notification of the new certificate to the subscriber; 1425 * Conduct constituting acceptance of the certificate; 1427 * Publication of the certificate by the CA; and 1429 * Notification of certificate issuance by the CA to other 1430 entities. 1432 4.4.8 Certificate Modification 1434 This subcomponent is used to describe the following elements related 1435 to issuance of a new certificate (6) due to changes in the 1436 information in the certificate other than the subscriber public key: 1438 * Circumstances under which certificate modification can take 1439 place, such as name change, role change, reorganization resulting a 1440 change in the DN; 1442 * Who may request certificate modification, for instance, 1443 subscribers, human resources personnel, or the RA; 1445 * A CA or RA's procedures to process modification requests to issue 1446 the new certificate, such as procedures that are the same as the 1447 initial certificate issuance; 1449 * Notification of the new certificate to the subscriber; 1451 * Conduct constituting acceptance of the certificate; 1453 * Publication of the certificate by the CA; and 1455 * Notification of certificate issuance by the CA to other entities. 1457 4.4.9 Certificate Revocation and Suspension 1459 This subcomponent addresses the following: 1461 * Circumstances under which a certificate may be and circumstances 1462 under which it must be revoked, for instance, in cases of subscriber 1463 employment termination, loss of cryptographic token, or suspected 1464 compromise of the private key; 1466 * Who can request the revocation of the participant's certificate, 1467 for example, the subscriber, RA, or CA in the case of an end-user 1468 subscriber certificate. 1470 * Procedures used for certificate revocation request, such as a 1471 digitally signed message from the RA, a digitally signed message 1472 from the subscriber, or a phone call from the RA; 1474 * The grace period available to the subscriber, within which the 1475 subscriber must make a revocation request; 1477 * The time within which CA must process the revocation request; 1479 * The mechanisms, if any, that a relying party may use or must use 1480 in order to check the status of certificates on which they wish to 1481 rely; 1483 * If a CRL mechanism is used, the issuance frequency; 1485 * If a CRL mechanism is used, maximum latency between the generation 1486 of CRLs and posting of the CRLs to the repository (in other words, 1487 the maximum amount of processing- and communication-related delays 1488 in posting CRLs to the repository after the CRLs are generated); 1490 * On-line revocation/status checking availability, for instance, 1491 OCSP and a web site to which status inquiries can be submitted; 1493 * Requirements on relying parties to perform on-line 1494 revocation/status checks; 1496 * Other forms of revocation advertisements available; 1498 * Any variations on the above stipulations when the suspension or 1499 revocation is the result of private key compromise (as opposed to 1500 other reasons for suspension or revocation). 1502 * Circumstances under which a certificate may be suspended; 1504 * Who can request the suspension of a certificate, for example, the 1505 subscriber, human resources personnel, a supervisor of the 1506 subscriber, or the RA in the case of an end-user subscriber 1507 certificate; 1509 * Procedures to request certificate suspension, such as a digitally 1510 signed message from subscriber or RA, or a phone call from RA; and 1512 * How long the suspension may last. 1514 4.4.10 Certificate Status Services 1516 This subcomponent addresses the certificate status checking services 1517 available to the relying parties, including: 1519 * The operational characteristics of certificate status checking 1520 services; 1522 * The availability of such services, and any applicable policies on 1523 unavailability; and 1525 * Any optional features of such services. 1527 4.4.11 End of Subscription 1529 This subcomponent addresses procedures used by the subscriber to end 1530 subscription to the CA services, including: 1532 * The revocation of certificates at the end of subscription (which 1533 may differ, depending on whether the end of subscription was due to 1534 expiration of the certificate or termination of the service). 1536 4.4.12 Key Escrow and Recovery 1538 This subcomponent contains the following elements to identify the 1539 policies and practices relating to the escrowing, and/or recovery of 1540 private keys where private key escrow services are available 1541 (through the CA or other trusted third parties): 1543 * Identification of the document containing private key escrow and 1544 recovery policies and practices or a listing of the such policies 1545 and practices; and 1547 * Identification of the document containing session key 1548 encapsulation and recovery policies and practices or a listing of 1549 such policies and practices. 1551 4.5 MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS 1553 This component describes non-technical security controls (that is, 1554 physical, procedural, and personnel controls) used by the issuing CA 1555 to perform securely the functions of key generation, subject 1556 authentication, certificate issuance, certificate revocation, audit, 1557 and archival. 1559 This component can also be used to define non-technical security 1560 controls on repository, subject CAs, RAs, subscribers, and other 1561 participants. The non-technical security controls for the subject 1562 CAs, RAs, subscribers, and other participants could be the same, 1563 similar, or very different. 1565 These non-technical security controls are critical to trusting the 1566 certificates since lack of security may compromise CA operations 1567 resulting, for example, in the creation of certificates or CRLs with 1568 erroneous information or in the compromise of the CA private key. 1570 Within each subcomponent, separate consideration will, in general, 1571 need to be given to each entity type, that is, issuing CA, 1572 repository, subject CAs, RAs, subscribers, and other participants. 1574 4.5.1 Physical Security Controls 1576 In this subcomponent, the physical controls on the facility housing 1577 the entity systems are described. Topics addressed may include: 1579 * Site location and construction, such as the construction 1580 requirements for high-security zones and the use of locked rooms, 1581 cages, safes, and cabinets; 1583 * Physical access, i.e., mechanisms to control access from one area 1584 of the facility to another or access into high-security zones, such 1585 as locating CA operations in a secure computer room monitored by 1586 guards or security alarms and requiring movement from zone to zone 1587 to be accomplished using a token, biometric readers, and/or access 1588 control lists; 1590 * Power and air conditioning; 1592 * Water exposures; 1594 * Fire prevention and protection; 1596 * Media storage, for example, requiring the storage of backup media 1597 in a separate location that is physically secure and protected from 1598 fire and water damages; 1600 * Waste disposal; and 1602 * Off-site backup. 1604 4.5.2 Procedural Controls 1606 In this subcomponent, requirements for recognizing trusted roles are 1607 described, together with the responsibilities for each role. 1608 Examples of trusted roles include system administrators, security 1609 officers, and system auditors. 1611 For each task identified for each role, it should also be stated how 1612 many individuals are required to perform the task (n out m rule). 1613 Identification and authentication requirements for each role may 1614 also be defined. 1616 This components also includes the separation of duties in terms of 1617 the roles that cannot be performed by the same individuals. 1619 4.5.3 Personnel Security Controls 1621 This subcomponent addresses the following: 1623 * Qualifications, experience, and clearances that personnel must 1624 have as a condition of filling trusted roles or other important 1625 roles. Examples include credentials, job experiences, and official 1626 government clearances that candidates for these positions must have 1627 before being hired; 1629 * Background checks and clearance procedures that are required in 1630 connection with the hiring of personnel filling trusted roles or 1631 perhaps other important roles, such as requirements that trusted 1632 personnel undergo checks of their criminal records, references, and 1633 additional clearances that a participant undertakes after a decision 1634 has been made to hire a particular person; 1636 * Training requirements and training procedures for each role 1637 following the hiring of personnel; 1639 * Any retraining period and retraining procedures for each role 1640 after completion of initial training; 1642 * Frequency and sequence for job rotation among various roles; 1644 * Sanctions against personnel for unauthorized actions, 1645 unauthorized use of authority, and unauthorized use of entity 1647 systems for the purpose of imposing accountability on a 1648 participant's personnel; 1650 * Controls on personnel that are independent contractors rather than 1651 employees of the entity; examples include: 1653 - Bonding requirements on contract personnel; 1654 - Contractual requirements including indemnification for damages due 1655 to the actions of the contractor personnel; 1656 - Audit and monitoring of contractor personnel; and 1657 - Other controls on contracting personnel. 1659 * Documentation to be supplied to personnel, during initial 1660 training, retraining, or otherwise. 1662 4.5.4 Audit Logging Procedures 1664 This subcomponent is used to describe event logging and audit 1665 systems, implemented for the purpose of maintaining a secure 1666 environment. Elements include the following: 1668 * Types of events recorded, such as certificate lifecycle 1669 operations, attempts to access the system, and requests made to the 1670 system; 1672 * Frequency with which audit logs are processed or archived, for 1673 example, weekly, following an alarm or anomalous event, or when ever 1674 the audit log is n% full; 1676 * Period for which audit logs are kept; 1678 * Protection of audit logs: 1680 - Who can view audit logs, for example only the audit administrator; 1681 - Protection against modification of audit log, for instance a 1682 requirement that no one may modify or delete the audit records or 1683 that only an audit administrator may delete the audit file as part 1684 of rotating the audit file; and 1685 - Protection against deletion of audit log. 1687 * Audit log back up procedures; 1689 * Whether the audit log accumulation system is internal or external 1690 to the entity; 1692 * Whether the subject who caused an audit event to occur is notified 1693 of the audit action; and 1695 * Vulnerability assessments, for example, where audit data is run 1696 through a tool that identifies potential attempts to breach the 1697 security of the system. 1699 4.5.5 Records Archival 1701 This subcomponent is used to describe general records archival (or 1703 records retention) policies, including the following: 1705 * Types of records that are archived, for example, all audit data, 1706 certificate application information, and documentation supporting 1707 certificate applications; 1709 * Retention period for archive; 1711 * Protection of archive: 1713 - Who can view the archive, for example, a requirement that only the 1714 audit administrator may view the archive; 1715 - Protection against modification of archive, such as securely 1716 storing the data on a write once medium; 1717 - Protection against deletion of archive; 1718 - Protection against deterioration of the media on which the archive 1719 is stored, such as a requirement for data to be migrated 1720 periodically to fresh media; and 1721 - Protection against obsolescence of hardware, operating systems, and 1722 other software, by, for example, retaining as part of the archive the 1723 hardware, operating systems, and/or other software in order to permit 1724 access to and use of archived records over time. 1726 * Archive backup procedures; 1728 * Requirements for time-stamping of records; 1730 * Whether the archive collection system is internal or external; and 1732 * Procedures to obtain and verify archive information, such as a 1733 requirement that two separate copies of the archive data be kept 1734 under the control of two persons, and that the two copies be 1735 compared in order to ensure that the archive information is 1736 accurate. 1738 4.5.6 Key Changeover 1740 This subcomponent describes the procedures to provide a new public 1741 key to a CA's users following a re-key by the CA. These procedures 1742 may be the same as the procedure for providing the current key. 1743 Also, the new key may be certified in a certificate signed using the 1744 old key. 1746 4.5.7 Compromise and Disaster Recovery 1748 This subcomponent describes requirements relating to notification 1749 and recovery procedures in the event of compromise or disaster. 1750 Each of the following may need to be addressed separately: 1752 * Identification or listing of the applicable incident and 1753 compromise reporting and handling procedures. 1755 * The recovery procedures used if computing resources, software, 1756 and/or data are corrupted or suspected to be corrupted. These 1757 procedures describe how a secure environment is reestablished, which 1759 certificates are revoked, whether the entity key is revoked, how 1760 the new entity public key is provided to the users, and how the 1761 subjects are re-certified. 1763 * The recovery procedures used if the entity key is compromised. 1764 These procedures describe how a secure environment is reestablished, 1765 how the new entity public key is provided to the users, and how the 1766 subjects are re-certified. 1768 * The entity's capabilities to ensure business continuity following 1769 a natural or other disaster. Such capabilities may include the 1770 availability of a remote hot-site at which operations may be 1771 recovered. They may also include procedures for securing its 1772 facility during the period of time following a natural or other 1773 disaster and before a secure environment is reestablished either at 1774 the original site or at a remote site. For example, procedures to 1775 protect against theft of sensitive materials from an earthquake- 1776 damaged site. 1778 4.5.8 CA or RA Termination 1780 This subcomponent describes requirements relating to procedures for 1781 termination and for termination notification of a CA or RA, 1782 including the identity of the custodian of CA and RA archival 1783 records. 1785 4.6 TECHNICAL SECURITY CONTROLS 1787 This component is used to define the security measures taken by the 1788 issuing CA to protect its cryptographic keys and activation data 1789 (e.g., PINs, passwords, or manually-held key shares). This 1790 component may also be used to impose constraints on repositories, 1791 subject CAs, subscribers, and other participants to protect their 1792 private keys, activation data for their private keys, and critical 1793 security parameters. Secure key management is critical to ensure 1794 that all secret and private keys and activation data are protected 1795 and used only by authorized personnel. 1797 This component also describes other technical security controls used 1798 by the issuing CA to perform securely the functions of key 1799 generation, user authentication, certificate registration, 1800 certificate revocation, audit, and archival. Technical controls 1801 include life-cycle security controls (including software development 1802 environment security, trusted software development methodology) and 1803 operational security controls. 1805 This component can also be used to define other technical security 1806 controls on repositories, subject CAs, RAs, subscribers, and other 1807 participants. 1809 4.6.1 Key Pair Generation and Installation 1811 Key pair generation and installation need to be considered for the 1813 issuing CA, repositories, subject CAs, RAs, and subscribers. For 1814 each of these types of entities, the following questions 1815 potentially need to be answered: 1817 1. Who generates the entity public, private key pair? Possibilities 1818 include the subscriber, RA, or CA. Also, how is the key generation 1819 performed? Is the key generation performed in hardware or software? 1821 2. How is the private key provided securely to the entity? 1822 Possibilities include a situation where the entity has generated it 1823 and therefore already has it, handing the entity the private key 1824 physically, mailing a token containing the private key securely, or 1825 delivering it in a SSL session. 1827 3. How is the entity's public key provided securely to the 1828 certification authority? Some possibilities are in an online SSL 1829 session or in a message signed by the RA. 1831 4. In the case of issuing CAs, how is the CA's public key provided 1832 securely to potential relying parties? Possibilities include 1833 handing the public key to the relying party securely in person, 1834 physically mailing a copy securely to the relying party, or 1835 delivering it in a SSL session. 1837 5. What are the key sizes? Examples include a 1,024 bit RSA modulus 1838 and a 1,024 bit DSA large prime. 1840 6. Who generates the public key parameters, and is the quality of 1841 the parameters checked during key generation? 1843 7. For what purposes may the key be used, or for what purposes 1844 should usage of the key be restricted? For X.509 certificates, 1845 these purposes should map to the key usage flags in X.509 Version 3 1846 certificates. 1848 4.6.2 Private Key Protection and Cryptographic Module Engineering 1849 Controls 1851 Requirements for private key protection and cryptographic module 1852 need to be considered for the issuing CA, repositories, subject CAs, 1853 RAs, and subscribers. For each of these types of entity, the 1854 following questions potentially need to be answered: 1856 1. What standards, if any, are required for the cryptographic 1857 module used to generate the keys? A cryptographic module can be 1858 composed of hardware, software, firmware, or any combination of 1859 them. For example, are the keys certified by the infrastructure 1860 required to be generated using modules compliant with the US FIPS 1861 140-1? If so, what is the required FIPS 140-1 level of the module? 1862 Are there any other engineering or other controls relating to a 1863 cryptographic module, such as the identification of the 1864 cryptographic module boundary, input/output, roles and services, 1865 finite state machine, physical security, software security, 1866 operating system security, algorithm compliance, electromagnetic 1868 compatibility, and self tests. 1870 2. Is the private key under n out of m multi-person control?(7) 1871 If yes, provide n and m (two person control is a special case of n 1872 out of m, where n = m = 2)? 1874 3. Is the private key escrowed?(8) If so, who is the escrow agent, 1875 what form is the key escrowed in (examples include plaintext, 1876 encrypted, split key), and what are the security controls on the 1877 escrow system? 1879 4. Is the private key backed up? If so, who is the backup agent, 1880 what form is the key backed up in (examples include plaintext, 1881 encrypted, split key), and what are the security controls on the 1882 backup system? 1884 5. Is the private key archived? If so, who is the archival agent, 1885 what form is the key archived in (examples include plaintext, 1886 encrypted, split key), and what are the security controls on the 1887 archival system? 1889 6. Under what circumstances, if any, can a private key be 1890 transferred into or from a cryptographic module? Who is permitted 1891 to perform such a transfer operation? In what form is the private 1892 key during the transfer (i.e., plaintext, encrypted, or split key)? 1894 7. How is the private key stored in the module (i.e., plaintext, 1895 encrypted, or split key)? 1897 8. Who can activate (use) the private key? What actions must be 1898 performed to activate the private key (e.g., login, power on, supply 1899 PIN, insert token/key, automatic, etc.)? Once the key is activated, 1900 is the key active for an indefinite period, active for one time, or 1901 active for a defined time period? 1903 9. Who can deactivate the private key and how? Examples of methods 1904 of deactivating private keys include logging out, turning the power 1905 off, removing the token/key, automatic deactivation, and time 1906 expiration. 1908 10. Who can destroy the private key and how? Examples of methods of 1909 destroying private keys include token surrender, token destruction, 1910 and overwriting the key. 1912 11. Provide the capabilities of the cryptographic module in the 1913 following areas: identification of the cryptographic module 1914 boundary, input/output, roles and services, finite state machine, 1915 physical security, software security, operating system security, 1916 algorithm compliance, electromagnetic compatibility, and self tests. 1917 Capability may be expressed through reference to compliance with a 1918 standard such as U.S. FIPS 140-1, associated level, and rating. 1920 4.6.3 Other Aspects of Key Pair Management 1922 Other aspects of key management need to be considered for the 1923 issuing CA, repositories, subject CAs, RAs, subscribers, and other 1924 participants. For each of these types of entity, the following 1925 questions potentially need to be answered: 1927 1. Is the public key archived? If so, who is the archival agent and 1928 what are the security controls on the archival system? Also, what 1929 software and hardware need to be preserved as part of the archive to 1930 permit use of the public key over time? Note: this subcomponent is 1931 not limited to requiring or describing the use of digital signatures 1932 with archival data, but rather can address integrity controls other 1933 than digital signatures when an archive requires tamper protection. 1934 Digital signatures do not provide tamper protection or protect the 1935 integrity of data; they merely verify data integrity. Moreover, the 1936 archival period may be greater than the cryptanalysis period for 1937 the public key needed to verify any digital signature applied to 1938 archival data. 1940 2. What is the operational period of the certificates issued to the 1941 subscriber. What are the usage periods, or active lifetimes, for 1942 the subscriber's key pair? 1944 4.6.4 Activation Data 1946 Activation data refers to data values other than whole private keys 1947 that are required to operate private keys or cryptographic modules 1948 containing private keys, such as a PIN, passphrase, or portions of a 1949 private key used in a key-splitting scheme. Protection of 1950 activation data prevents unauthorized use of the private key, and 1951 potentially needs to be considered for the issuing CA, subject CAs, 1952 RAs, and subscribers. Such consideration potentially needs to 1953 address the entire life-cycle of the activation data from generation 1954 through archival and destruction. For each of the entity types 1955 (issuing CA, repository, subject CA, RA, subscriber, and other 1956 participants) all of the questions listed in 4.6.1 through 4.6.3 1957 potentially need to be answered with respect to activation data 1958 rather than with respect to keys. 1960 4.6.5 Computer Security Controls 1962 This subcomponent is used to describe computer security controls 1963 such as: use of the trusted computing base concept, discretionary 1964 access control, labels, mandatory access controls, object reuse, 1965 audit, identification and authentication, trusted path, security 1966 testing, and penetration testing. Product assurance may also be 1967 addressed. 1969 A computer security rating for computer systems may be required. 1970 The rating could be based, for example, on the Trusted System 1971 Evaluation Criteria (TCSEC), Canadian Trusted Products Evaluation 1972 Criteria, European Information Technology Security Evaluation 1973 Criteria (ITSEC), or the Common Criteria for Information Technology 1974 Security Evaluation, ISO/IEC 15408:1999. This subcomponent can also 1976 address requirements for product evaluation analysis, testing, 1977 profiling, product certification, and/or product accreditation 1978 related activity undertaken. 1980 4.6.6 Life Cycle Security Controls 1982 This subcomponent addresses system development controls and 1983 security management controls. 1985 System development controls include development environment 1986 security, development personnel security, configuration management 1987 security during product maintenance, software engineering practices, 1988 software development methodology, modularity, layering, use of 1989 failsafe design and implementation techniques (e.g., defensive 1990 programming) and development facility security. 1992 Security management controls include execution of tools and 1993 procedures to ensure that the operational systems and networks 1994 adhere to configured security. These tools and procedures include 1995 checking the integrity of the security software, firmware, and 1996 hardware to ensure their correct operation. 1998 This subcomponent can also address life-cycle security ratings 1999 based, for example, on the Trusted Software Development Methodology 2000 (TSDM) level IV and V, independent life-cycle security controls 2001 audit, and the Software Engineering Institute's Capability Maturity 2002 Model (SEI-CMM). 2004 4.6.7 Network Security Controls 2006 This subcomponent addresses network security related controls, 2007 including firewalls. 2009 4.6.8 Time-stamping 2011 This subcomponent addresses requirements or practices relating to 2012 the use of timestamps on various data. It may also discuss whether 2013 or not the time-stamping application must use a trusted time source. 2015 4.7 CERTIFICATE AND CRL PROFILES 2017 This component is used to specify the certificate format and, if 2018 CRLs and/or OCSP are used, the CRL and/or OCSP format. This 2019 includes information on profiles, versions, and extensions used. 2021 4.7.1 Certificate Profile 2023 This subcomponent addresses such topics as the following 2024 (potentially by reference to a separate profile definition, such as 2025 the one defined in IETF PKIX RFC 2459): 2027 * Version number(s) supported; 2029 * Certificate extensions populated and their criticality; 2031 * Cryptographic algorithm object identifiers; 2033 * Name forms used for the CA, RA, and subscriber names; 2035 * Name constraints used and the name forms used in the name 2036 constraints; 2038 * Applicable CP OID(s); 2040 * Usage of the policy constraints extension; 2042 * Policy qualifiers syntax and semantics; and 2044 * Processing semantics for the critical CP extension. 2046 4.7.2 CRL Profile 2048 This subcomponent addresses such topics as the following 2049 (potentially by reference to a separate profile definition, such as 2050 the one defined in IETF PKIX RFC 2459): 2052 * Version numbers supported for CRLs; and 2054 * CRL and CRL entry extensions populated and their criticality. 2056 4.7.3 OCSP Profile 2058 This subcomponent addresses such topics as the following 2059 (potentially by reference to a separate profile definition, such as 2060 the IETF RFC 2560 profile): 2062 * Version of OCSP that is being used as the basis for establishing 2063 an OCSP system; and 2065 * OCSP extensions populated and their criticality. 2067 4.8 COMPLIANCE AUDIT AND OTHER ASSESSMENT 2069 This component addresses the following: 2071 * The list of topics covered by the assessment and/or the assessment 2072 methodology used to perform the assessment; examples include 2073 WebTrust for CAs (9) and SAS 70 (10). 2075 * Frequency of compliance audit or other assessment for each entity 2076 that must be assessed pursuant to a CP or CPS, or the circumstances 2077 that will trigger an assessment; possibilities include an annual 2078 audit, pre-operational assessment as a condition of allowing an 2079 entity to being operations, or investigation following a possible or 2080 actual compromise of security. 2082 * The identity and/or qualifications of the personnel performing the 2083 audit or other assessment. 2085 * The relationship between the assessor and the entity being 2087 assessed, including the degree of independence of the assessor. 2089 * Actions taken as a result of deficiencies found during the 2090 assessment; examples include a temporary suspension of operations 2091 until deficiencies are corrected, revocation of certificates issued 2092 to the assessed entity, changes in personnel, triggering special 2093 investigations or more frequent subsequent compliance assessments, 2094 and claims for damages against the assessed entity. 2096 * Who is entitled to see results of an assessment (e.g., assessed 2097 entity, other participants, the general public), who provides them 2098 (e.g., the assessor or the assessed entity), and how they are 2099 communicated. 2101 4.9 OTHER BUSINESS AND LEGAL MATTERS 2103 This component covers general business and legal matters. Sections 2104 9.1 and 9.2 of the framework discuss the business issues of fees to 2105 be charged for various services and the financial responsibility of 2106 participants to maintain resources for ongoing operations and for 2107 paying judgments or settlements in response to claims asserted 2108 against them. The remaining sections are generally concerned with 2109 legal topics. 2111 Starting with Section 9.3 of the framework, the ordering of topics 2112 is the same as or similar to the ordering of topics in a typical 2113 software licensing agreement or other technology agreement. 2114 Consequently, this framework may not only be used for CPs and CPSs, 2115 but also associated PKI-related agreements, especially subscriber 2116 agreements and relying party agreements. This ordering is intended 2117 help lawyers review CPs, CPSs, and other documents adhering to this 2118 framework. 2120 With respect to many of the legal subcomponents within this 2121 component, a CP or CPS drafter may choose to include in the document 2122 terms and conditions that apply directly to subscribers or relying 2123 parties. For instance, a CP or CPS may set forth limitations of 2124 liability that apply to subscribers and relying parties. The 2125 inclusion of terms and conditions is likely to be appropriate where 2126 the CP or CPS is itself a contract or part of a contract. 2128 In other cases, however, the CP or CPS is not a contract or part of 2129 a contract; instead, it is configured so that its terms and 2130 conditions are applied to the parties by separate documents, which 2131 may include associated agreements, such as subscriber or relying 2132 party agreements. In that event, a CP drafter may write a CP so as 2133 to require that certain legal terms and conditions appear (or not 2134 appear) in such associated agreements. For example, a CP might 2135 include a subcomponent stating that a certain limitation of 2136 liability term must appear in a CA's subscriber and relying party 2137 agreements. Another example is a CP that contains a subcomponent 2138 prohibiting the use of a subscriber or relying party agreement 2139 containing a limitation upon CA liability inconsistent with the 2140 provisions of the CP. A CPS drafter may use legal subcomponents to 2141 disclose that certain terms and conditions appear in associated 2143 subscriber, relying party, or other agreements in use by the CA. A 2144 CPS might explain, for instance, that the CA writing it uses an 2145 associated subscriber or relying party agreement that applies a 2146 particular provision for limiting liability. 2148 4.9.1 Fees 2150 This subcomponent contains any applicable provisions regarding fees 2151 charged by CAs, repositories, or RAs, such as: 2153 * Certificate issuance or renewal fees; 2155 * Certificate access fees; 2157 * Revocation or status information access fees; 2159 * Fees for other services such as providing access to the relevant 2160 CP or CPS; and 2162 * Refund policy. 2164 4.9.2 Financial Responsibility 2166 This subcomponent contains requirements or disclosures relating to 2167 the resources available to CAs, RAs, and other participants 2168 providing certification services to support performance of their 2169 operational PKI responsibilities, and to remain solvent and pay 2170 damages in the event they are liable to pay a judgment or settlement 2171 in connection with a claim arising out of such operations. Such 2172 provisions include: 2174 * A statement that the participant maintains a certain amount of 2175 insurance coverage for its liabilities to other participants; 2177 * A statement that a participant has access to other resources to 2178 support operations and pay damages for potential liability, which 2179 may be couched in terms of a minimum level of assets necessary to 2180 operate and cover contingencies that might occur within a PKI, where 2181 examples include assets on the balance sheet of an organization, a 2182 surety bond, a letter of credit, and a right under an agreement 2183 to an indemnity under certain circumstances; and 2185 * A statement that a participant has a program that offers first- 2186 party insurance or warranty protection to other participants in 2187 connection with their use of the PKI. 2189 4.9.3 Confidentiality of Business Information 2191 This subcomponent contains provisions relating to the treatment of 2192 confidential business information that participants may communicate 2193 to each other, such as business plans, sales information, trade 2194 secrets, and information received from a third party under a 2195 nondisclosure agreement. Specifically, this subcomponent addresses: 2197 * The scope of what is considered confidential information, 2199 * The types of information that are considered to be outside the 2200 scope of confidential information, and 2202 * The responsibilities of participants that receive confidential 2203 information to secure it from compromise, and refrain from using it 2204 or disclosing it to third parties. 2206 4.9.4 Privacy of Personal Information 2208 This subcomponent relates to the protection that participants, 2209 particularly CAs, RAs, and repositories, may be required to afford 2210 to personally identifiable private information of certificate 2211 applicants, subscribers, and other participants. In specific, this 2212 subcomponent addresses the following, to the extent pertinent under 2213 applicable law: 2215 * The designation and disclosure of the applicable privacy plan that 2216 applies to a participant's activities, if required by applicable law 2217 or policy; 2219 * Information that is or is not considered private within the PKI; 2221 * Any responsibility of participants that receive private 2222 information to secure it, and refrain from using it and from 2223 disclosing it to third parties; 2225 * Any requirements as to notices to, or consent from individuals 2226 regarding use or disclosure of private information; and 2228 * Any circumstances under which a participant is entitled or 2229 required to disclose private information pursuant to judicial, 2230 administrative process in a private or governmental proceeding, or 2231 in any legal proceeding. 2233 4.9.5 Intellectual Property Rights 2235 This subcomponent addresses the intellectual property rights, 2236 such as copyright, patent, trademarks, or trade secrets, that 2237 certain participants may have or claim in a CP, CPS, certificates, 2238 names, and keys, or are the subject of a license to or from 2239 participants. 2241 4.9.6 Representations and Warranties 2243 This subcomponent can include representations and warranties of 2244 various entities that are being made pursuant to the CP or CPS. For 2245 example, a CPS that serves as a contract might contain a CA's 2246 warranty that information contained in the certificate is accurate. 2247 Alternatively, a CPS might contain a less extensive warranty to the 2248 effect that the information in the certificate is true to the best 2249 of the CA's knowledge after performing certain identity 2250 authentication procedures with due diligence. This subcomponent can 2251 also include requirements that representations and warranties appear 2252 in certain agreements, such as subscriber or relying party 2253 agreements. For instance, a CP may contain a requirement that all 2255 CAs utilize a subscriber agreement, and that a subscriber agreement 2256 must contain a warranty by the CA that information in the 2257 certificate is accurate. Participants that may make representations 2258 and warranties include CAs, RAs, subscribers, relying parties, and 2259 other participants. 2261 4.9.7 Disclaimers of Warranties 2263 This subcomponent can include disclaimers of express warranties that 2264 may otherwise be deemed to exist in an agreement, and disclaimers of 2265 implied warranties that may otherwise be imposed by applicable law, 2266 such as warranties of merchantability or fitness for a particular 2267 purpose. The CP or CPS may directly impose such disclaimers, or the 2268 CP or CPS may contain a requirement that disclaimers appear in 2269 associated agreements, such as subscriber or relying party agreements. 2271 4.9.8 Limitations of Liability 2273 This subcomponent can include limitations of liability in a CP or 2274 CPS or limitations that appear or must appear in an agreement 2275 associated with the CP or CPS, such as a subscriber or relying party 2276 agreement. These limitations may fall into one of two categories: 2277 limitations on the elements of damages recoverable and limitations 2278 on the amount of damages recoverable, also known as liability caps. 2279 Often, contracts contain clauses preventing the recovery of elements 2280 of damages such as incidental and consequential damages, and 2281 sometimes punitive damages. Frequently, contracts contain clauses 2282 that limit the possible recovery of one party or the other to an 2283 amount certain or to an amount corresponding to a benchmark, such as 2284 the amount a vendor was paid under the contract. 2286 4.9.9 Indemnities 2288 This subcomponent includes provisions by which one party makes a 2289 second party whole for losses or damage incurred by the second 2290 party, typically arising out of the first party's conduct. They may 2291 appear in a CP, CPS, or agreement. For example, a CP may require 2292 that subscriber agreements contain a term under which a subscriber 2293 is responsible for indemnifying a CA for losses the CA sustains 2294 arising out of a subscriber's fraudulent misrepresentations on the 2295 certificate application under which the CA issued the subscriber 2296 an inaccurate certificate. Similarly, a CPS may say that a CA uses 2297 a relying party agreement, under which relying parties are 2298 responsible for indemnifying a CA for losses the CA sustains arising 2299 out of use of a certificate without properly checking revocation 2300 information or use of a certificate for purposes beyond what the CA 2301 permits. 2303 4.9.10 Term and Termination 2305 This subcomponent can include the time period in which a CP or a CPS 2306 remains in force and the circumstances under which the document, 2307 portions of the document, or its applicability to a particular 2308 participant can be terminated. In addition or alternatively, the CP 2309 or CPS may include requirements that certain term and termination 2311 clauses appear in agreements, such as subscriber or relying party 2312 agreements. In particular, such terms can include: 2314 * The term of a document or agreement, that is, when the document 2315 becomes effective and when it expires if it is not terminated 2316 earlier. 2318 * Termination provisions stating circumstances under which the 2319 document, certain portions of it, or its application to a particular 2320 participant ceases to remain in effect. 2322 * Any consequences of termination of the document. For example, 2323 certain provisions of an agreement may survive its termination and 2324 remain in force. Examples include acknowledgements of intellectual 2325 property rights and confidentiality provisions. Also, termination 2326 may trigger a responsibility of parties to return confidential 2327 information to the party that disclosed it. 2329 4.9.11 Individual notices and communications with participants 2331 This subcomponent discusses the way in which one participant can or 2332 must communicate with another participant on a one-to-one basis in 2333 order for such communications to be legally effective. For example, 2334 an RA may wish to inform the CA that it wishes to terminate its 2335 agreement with the CA. This subcomponent is different from 2336 publication and repository functions, because unlike individual 2337 communications described in this subcomponent, publication and 2338 posting to a repository are for the purpose of communicating to a 2339 wide audience of recipients, such as all relying parties. This 2340 subcomponent may establish mechanisms for communication and indicate 2341 the contact information to be used to route such communications, 2342 such as digitally signed e-mail notices to a specified address, 2343 followed by a signed e-mail acknowledgement of receipt. 2345 4.9.12 Amendments 2347 It will occasionally be necessary to amend a CP or CPS. Some of 2348 these changes will not materially reduce the assurance that a CP or 2350 its implementation provides, and will be judged by the policy 2351 administrator to have an insignificant effect on the acceptability 2352 of certificates. Such changes to a CP or CPS need not require a 2353 change in the CP OID or the CPS pointer (URL). On the other hand, 2354 some changes to a specification will materially change the 2355 acceptability of certificates for specific purposes, and these 2356 changes may require corresponding changes to the CP OID or CPS 2357 pointer qualifier (URL). 2359 This subcomponent may also contain the following information: 2361 * The procedures by which the CP or CPS and/or other documents must, 2362 may be, or are amended. In the case of CP or CPS amendments, change 2363 procedures may include a notification mechanism to provide notice of 2364 proposed amendments to affected parties, such as subscribers and 2365 relying parties; a comment period; a mechanism by which comments are 2367 received, reviewed and incorporated into the document; and a 2368 mechanism by which amendments become final and effective. 2370 * The circumstances under which amendments to the CP or CPS would 2371 require a change in CP OID or CPS pointer (URL). 2373 4.9.13 Dispute Resolution Procedures 2375 This subcomponent discusses procedures utilized to resolve disputes 2376 arising out of the CP, CPS, and/or agreements. Examples of such 2377 procedures include requirements that disputes be resolved in a 2378 certain forum or by alternative dispute resolution mechanisms. 2380 4.9.14 Governing Law 2382 This subcomponent sets forth a statement that the law of a certain 2383 jurisdiction governs the interpretation and enforcement of the 2384 subject CP or CPS or agreements. 2386 4.9.15 Compliance with Applicable Law 2388 This subcomponent relates to stated requirements that participants 2389 comply with applicable law, for example laws relating to 2390 cryptographic hardware and software that may be subject to the 2391 export control laws of a given jurisdiction. The CP or CPS could 2392 purport to impose such requirements or may require that such 2393 provisions appear in other agreements. 2395 4.9.16 Miscellaneous Provisions 2397 This subcomponent contains miscellaneous provisions sometimes called 2398 "boilerplate provisions" in contracts. The clauses covered in this 2399 subcomponent may appear in a CP, CPS, or agreements and include: 2401 * An entire agreement clause, which typically identifies the 2402 document or documents comprising the entire agreement between the 2403 parties and states that such agreements supersedes all prior and 2404 contemporaneous written or oral understandings relating to the same 2405 subject matter; 2407 * An assignment clause, which may act to limit the ability of a 2408 party to an agreement to assign its rights under the agreement to 2409 another party (such as the right to receive a stream of payments in 2410 the future) or the ability of a party to delegate its obligations 2411 under the agreement; 2413 * A severability clause, which sets forth the intentions of the 2414 parties in the event a court or other tribunal determines that a 2415 clause within an agreement is, for some reason, invalid or 2416 unenforceable, and whose purpose is frequently to prevent the 2417 unenforceability of one clause from causing the whole agreement to 2418 be unenforceable; and 2420 * An enforcement clause, which may state that a party prevailing in 2421 any dispute arising out of an agreement is entitled to attorneys' 2423 fees as part of its recovery, or may state that a party's waiver of 2424 one breach of contract does not constitute a continuing waiver or a 2425 future waiver of other breaches of contract. 2427 4.9.17 Other Provisions 2429 This subcomponent is a "catchall" location where additional 2430 responsibilities and terms can be imposed on PKI participants that 2431 do not neatly fit within one of the other components or 2432 subcomponents of the framework. CP and CPS writers can place any 2433 provision within this subcomponent that is not covered by another 2434 subcomponent. 2436 5. OUTLINE OF A SET OF PROVISIONS 2438 This section contains a recommended outline for a set of provisions, 2439 intended to serve as a checklist or (with some further development) 2440 a standard template for use by CP or CPS writers. Such a common 2441 outline will facilitate: 2443 (a) Comparison of two certificate policies during cross- 2444 certification or other forms of interoperation (for the purpose of 2445 equivalency mapping). 2446 (b) Comparison of a CPS with a CP to ensure that the CPS faithfully 2447 implements the policy. 2448 (c) Comparison of two CPSs. 2450 In order to comply with the RFC, the drafters of a compliant CP or 2451 CPS are strongly advised to adhere to this outline. While use of 2452 alternate outline is discouraged, it may be accepted if a proper 2453 justification is provided for the deviation and a mapping table is 2454 provided to readily discern where each of the items described in 2455 this outline is provided. 2457 1. INTRODUCTION 2459 1.1 Overview 2461 1.2 Document name and identification 2463 1.3 PKI participants 2464 1.3.1 Certification authorities 2465 1.3.2 Registration authorities 2466 1.3.3 Subscribers 2467 1.3.4 Relying parties 2468 1.3.5 Other participants 2470 1.4 Certificate usage 2471 1.4.1. Appropriate certificate uses 2472 1.4.2 Prohibited certificate uses 2474 1.5 Policy administration 2475 1.5.1 Organization administering the document 2476 1.5.2 Contact person 2477 1.5.3 Person determining CPS suitability for the policy 2479 1.5.4 CPS approval procedures 2481 1.6 Definitions and acronyms 2483 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES 2485 2.1 Repositories 2487 2.2 Publication of certification information 2489 2.3 Time or frequency of publication 2491 2.4 Access controls on repositories 2493 3. IDENTIFICATION AND AUTHENTICATION (11) 2495 3.1 Naming 2496 3.1.1 Types of names 2497 3.1.2 Need for names to be meaningful 2498 3.1.3 Anonymity or pseudonymity of subscribers 2499 3.1.4 Rules for interpreting various name forms 2500 3.1.5 Uniqueness of names 2501 3.1.6 Recognition, authentication, and role of trademarks 2503 3.2 Initial identity validation 2504 3.2.1 Method to prove possession of private key 2505 3.2.2 Authentication of organization identity 2506 3.2.3 Authentication of individual identity 2507 3.2.4 Non-verified subscriber information 2508 3.2.5 Validation of authority 2509 3.2.6 Criteria for interoperation 2511 3.3 Identification and authentication for re-key requests 2512 3.3.1 Identification and authentication for routine re-key 2513 3.3.2 Identification and authentication for re-key after revocation 2515 3.4 Identification and authentication for revocation request 2517 4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS (11) 2519 4.1 Certificate Application 2520 4.1.1 Who can submit a certificate application 2521 4.1.2 Enrollment process and responsibilities 2523 4.2 Certificate application processing 2524 4.2.1 Performing identification and authentication functions 2525 4.2.2 Approval or rejection of certificate applications 2526 4.2.3 Time to process certificate applications 2528 4.3 Certificate issuance 2529 4.3.1 CA actions during certificate issuance 2530 4.3.2 Notification to subscriber by the CA of issuance of 2531 certificate 2533 4.4 Certificate acceptance 2535 4.4.1 Conduct constituting certificate acceptance 2536 4.4.2 Publication of the certificate by the CA 2537 4.4.3 Notification of certificate issuance by the CA to other 2538 entities 2540 4.5 Key pair and certificate usage 2541 4.5.1 Subscriber private key and certificate usage 2542 4.5.2 Relying party public key and certificate usage 2544 4.6 Certificate renewal 2545 4.6.1 Circumstance for certificate renewal 2546 4.6.2 Who may request renewal 2547 4.6.3 Processing certificate renewal requests 2548 4.6.4 Notification of new certificate issuance to subscriber 2549 4.6.5 Conduct constituting acceptance of a renewal certificate 2550 4.6.6 Publication of the renewal certificate by the CA 2551 4.6.7 Notification of certificate issuance by the CA to other 2552 entities 2554 4.7 Certificate re-key 2555 4.7.1 Circumstance for certificate re-key 2556 4.7.2 Who may request certification of a new public key 2557 4.7.3 Processing certificate re-keying requests 2558 4.7.4 Notification of new certificate issuance to subscriber 2559 4.7.5 Conduct constituting acceptance of a re-keyed certificate 2560 4.7.6 Publication of the re-keyed certificate by the CA 2561 4.7.7 Notification of certificate issuance by the CA to other 2562 entities 2564 4.8 Certificate modification 2565 4.8.1 Circumstance for certificate modification 2566 4.8.2 Who may request certificate modification 2567 4.8.3 Processing certificate modification requests 2568 4.8.4 Notification of new certificate issuance to subscriber 2569 4.8.5 Conduct constituting acceptance of modified certificate 2570 4.8.6 Publication of the modified certificate by the CA 2571 4.8.7 Notification of certificate issuance by the CA to other 2572 entities 2574 4.9 Certificate revocation and suspension 2575 4.9.1 Circumstances for revocation 2576 4.9.2 Who can request revocation 2577 4.9.3 Procedure for revocation request 2578 4.9.4 Revocation request grace period 2579 4.9.5 Time within which CA must process the revocation request 2580 4.9.6 Revocation checking requirement for relying parties 2581 4.9.7 CRL issuance frequency (if applicable) 2582 4.9.8 Maximum latency for CRLs (if applicable) 2583 4.9.9 On-line revocation/status checking availability 2584 4.9.10 On-line revocation checking requirements 2585 4.9.11 Other forms of revocation advertisements available 2586 4.9.12 Special requirements re key compromise 2587 4.9.13 Circumstances for suspension 2588 4.9.14 Who can request suspension 2589 4.9.15 Procedure for suspension request 2591 4.9.16 Limits on suspension period 2593 4.10 Certificate status services 2594 4.10.1 Operational characteristics 2595 4.10.2 Service availability 2596 4.10.3 Optional features 2598 4.11 End of subscription 2600 4.12 Key escrow and recovery 2601 4.12.1 Key escrow and recovery policy and practices 2602 4.12.2 Session key encapsulation and recovery policy and practices 2604 5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS (11) 2606 5.1 Physical controls 2607 5.1.1 Site location and construction 2608 5.1.2 Physical access 2609 5.1.3 Power and air conditioning 2610 5.1.4 Water exposures 2611 5.1.5 Fire prevention and protection 2612 5.1.6 Media storage 2613 5.1.7 Waste disposal 2614 5.1.8 Off-site backup 2616 5.2 Procedural controls 2617 5.2.1 Trusted roles 2618 5.2.2 Number of persons required per task 2619 5.2.3 Identification and authentication for each role 2620 5.2.4 Roles requiring separation of duties 2622 5.3 Personnel controls 2623 5.3.1 Qualifications, experience, and clearance requirements 2624 5.3.2 Background check procedures 2625 5.3.3 Training requirements 2626 5.3.4 Retraining frequency and requirements 2627 5.3.5 Job rotation frequency and sequence 2628 5.3.6 Sanctions for unauthorized actions 2629 5.3.7 Independent contractor requirements 2630 5.3.8 Documentation supplied to personnel 2632 5.4 Audit logging procedures 2633 5.4.1 Types of event recorded 2634 5.4.2 Frequency of processing log 2635 5.4.3 Retention period for audit log 2636 5.4.4 Protection of audit log 2637 5.4.5 Audit log backup procedures 2638 5.4.6 Audit collection system (internal vs. external) 2639 5.4.7 Notification to event-causing subject 2640 5.4.8 Vulnerability assessments 2642 5.5 Records archival 2643 5.5.1 Types of records archived 2644 5.5.2 Retention period for archive 2645 5.5.3 Protection of archive 2647 5.5.4 Archive backup procedures 2648 5.5.5 Requirements for time-stamping of records 2649 5.5.6 Archive collection system (internal or external) 2650 5.5.7 Procedures to obtain and verify archive information 2652 5.6 Key changeover 2654 5.7 Compromise and disaster recovery 2655 5.7.1 Incident and compromise handling procedures 2656 5.7.2 Computing resources, software, and/or data are corrupted 2657 5.7.3 Entity private key compromise procedures 2658 5.7.4 Business continuity capabilities after a disaster 2660 5.8 CA or RA termination 2662 6. TECHNICAL SECURITY CONTROLS (11) 2664 6.1 Key pair generation and installation 2665 6.1.1 Key pair generation 2666 6.1.2 Private key delivery to subscriber 2667 6.1.3 Public key delivery to certificate issuer 2668 6.1.4 CA public key delivery to relying parties 2669 6.1.5 Key sizes 2670 6.1.6 Public key parameters generation and quality checking 2671 6.1.7 Key usage purposes (as per X.509 v3 key usage field) 2673 6.2 Private Key Protection and Cryptographic Module Engineering 2674 Controls 2676 6.2.1 Cryptographic module standards and controls 2677 6.2.2 Private key (n out of m) multi-person control 2678 6.2.3 Private key escrow 2679 6.2.4 Private key backup 2680 6.2.5 Private key archival 2681 6.2.6 Private key transfer into or from a cryptographic module 2682 6.2.7 Private key storage on cryptographic module 2683 6.2.8 Method of activating private key 2684 6.2.9 Method of deactivating private key 2685 6.2.10 Method of destroying private key 2686 6.2.11 Cryptographic Module Rating 2688 6.3 Other aspects of key pair management 2689 6.3.1 Public key archival 2690 6.3.2 Certificate operational periods and key pair usage periods 2692 6.4 Activation data 2693 6.4.1 Activation data generation and installation 2694 6.4.2 Activation data protection 2695 6.4.3 Other aspects of activation data 2697 6.5 Computer security controls 2698 6.5.1 Specific computer security technical requirements 2699 6.5.2 Computer security rating 2701 6.6 Life cycle technical controls 2703 6.6.1 System development controls 2704 6.6.2 Security management controls 2705 6.6.3 Life cycle security controls 2707 6.7 Network security controls 2709 6.8 Time-stamping 2711 7. CERTIFICATE, CRL, AND OCSP PROFILES 2713 7.1 Certificate profile 2714 7.1.1 Version number(s) 2715 7.1.2 Certificate extensions 2716 7.1.3 Algorithm object identifiers 2717 7.1.4 Name forms 2718 7.1.5 Name constraints 2719 7.1.6 Certificate policy object identifier 2720 7.1.7 Usage of Policy Constraints extension 2721 7.1.8 Policy qualifiers syntax and semantics 2722 7.1.9 Processing semantics for the critical Certificate Policies 2723 extension 2725 7.2 CRL profile 2726 7.2.1 Version number(s) 2727 7.2.2 CRL and CRL entry extensions 2729 7.3 OCSP profile 2730 7.3.1 Version number(s) 2731 7.3.2 OCSP extensions 2733 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS 2734 8.1 Frequency or circumstances of assessment 2735 8.2 Identity/qualifications of assessor 2736 8.3 Assessor's relationship to assessed entity 2737 8.4 Topics covered by assessment 2738 8.5 Actions taken as a result of deficiency 2739 8.6 Communication of results 2741 9. OTHER BUSINESS AND LEGAL MATTERS 2743 9.1 Fees 2744 9.1.1 Certificate issuance or renewal fees 2745 9.1.2 Certificate access fees 2746 9.1.3 Revocation or status information access fees 2747 9.1.4 Fees for other services 2748 9.1.5 Refund policy 2750 9.2 Financial responsibility 2751 9.2.1 Insurance coverage 2752 9.2.2 Other assets 2753 9.2.3 Insurance or warranty coverage for end-entities 2755 9.3 Confidentiality of business information 2756 9.3.1 Scope of confidential information 2757 9.3.2 Information not within the scope of confidential information 2759 9.3.3 Responsibility to protect confidential information 2761 9.4 Privacy of personal information 2762 9.4.1 Privacy plan 2763 9.4.2 Information treated as private 2764 9.4.3 Information not deemed private 2765 9.4.4 Responsibility to protect private information 2766 9.4.5 Notice and consent to use private information 2767 9.4.6 Disclosure pursuant to judicial or administrative process 2768 9.4.7 Other information disclosure circumstances 2770 9.5 Intellectual property rights 2772 9.6 Representations and warranties 2773 9.6.1 CA representations and warranties 2774 9.6.2 RA representations and warranties 2775 9.6.3 Subscriber representations and warranties 2776 9.6.4 Relying party representations and warranties 2777 9.6.5 Representations and warranties of other participants 2779 9.7 Disclaimers of warranties 2781 9.8 Limitations of liability 2783 9.9 Indemnities 2785 9.10 Term and termination 2786 9.10.1 Term 2787 9.10.2 Termination 2788 9.10.3 Effect of termination and survival 2790 9.11 Individual notices and communications with participants 2792 9.12 Amendments 2793 9.12.1 Procedure for amendment 2794 9.12.2 Notification mechanism and period 2795 9.12.3 Circumstances under which OID must be changed 2797 9.13 Dispute resolution provisions 2799 9.14 Governing law 2801 9.15 Compliance with applicable law 2803 9.16 Miscellaneous provisions 2804 9.16.1 Entire agreement 2805 9.16.2 Assignment 2806 9.16.3 Severability 2807 9.16.4 Enforcement (attorneys' fees and waiver of rights) 2809 9.17 Other provisions 2811 6. ACKNOWLEDGMENTS 2812 The development of the predecessor document (RFC 2527) was supported 2813 by the Government of Canada's Policy Management Authority (PMA) 2815 Committee, the National Security Agency, the National Institute of 2816 Standards and Technology (NIST), and the American Bar Association 2817 Information Security Committee Accreditation Working Group. 2819 This revision effort is largely a result of constant inspiration 2820 from Michael Baum. Michael Power, Mike Jenkins, and Alice Sturgeon 2821 have also made several contributions. 2823 7. REFERENCES 2825 [ABA1] American Bar Association, Digital Signature Guidelines: 2826 Legal Infrastructure for Certification Authorities and Secure 2827 Electronic Commerce, 1996. 2829 [ABA2] American Bar Association, PKI Assessment Guidelines, v0.30, 2830 Public Draft For Comment, June 2001. 2832 [BAU1] Michael. S. Baum, Federal Certification Authority Liability 2833 and Policy, NIST-GCR-94-654, June 1994, available at 2834 http://www.verisign.com/repository/pubs/index.html. 2836 [ETS] European Telecommunications Standards Institute, "Policy 2837 Requirements for Certification Authorities Issuing Qualified 2838 Certificates," ETSI TS 101 456, Version 1.1.1, December 2000. 2840 [GOC] Government of Canada PKI Policy Management Authority, 2841 "Digital Signature and Confidentiality Certificate Policies for the 2842 Government of Canada Public Key Infrastructure," v.3.02, April 1999. 2844 [IDT] Identrus, LLC, "Identrus Identity Certificate Policy" IP-IPC 2845 Version 1.7, March 2001. 2847 [ISO1] ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information 2848 Technology - Open Systems Interconnection: The Directory: 2849 Authentication Framework," 1997 edition. (Pending publication of 2850 2000 edition, use 1997 edition.) 2852 [PEM1] S. Kent, "Privacy Enhancement for Internet Electronic Mail, 2853 Part II: Certificate-Based Key Management," Internet RFC 1422, 1993. 2855 [PKI1] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509 Public 2856 Key Infrastructure, Certificate and CRL Profile," RFC 2459 1998. 2858 [CPF] S. Chokhani and W. Ford, "Internet X.509 Public Key 2859 Infrastructure, Certificate Policy and Certification Practices 2860 Statement Framework," RFC 2527, April 1998. 2862 8. AUTHORS' ADDRESSES 2864 Santosh Chokhani 2865 CygnaCom Solutions, Inc., an Entrust company 2866 7927 Jones Branch Drive, Suite 100 West 2867 McLean, VA 22102 2868 Phone: (703) 270-3520 2869 Fax: (703) 848-0960 2870 EMail: chokhani@cygnacom.com 2872 Warwick Ford 2873 VeriSign, Inc. 2874 401 Edgewater Place, Suite 280 2875 Wakefield, MA 01880 2876 Phone: (781) 245-6996 x225 2877 Fax: (781) 245-6006 2878 EMail: wford@verisign.com 2880 Randy V. Sabett, J.D., CISSP 2881 Cooley Godward LLP 2882 One Freedom Square, Reston Town Center 2883 11951 Freedom Drive 2884 Reston, VA 20190-5601 2885 Phone: (703) 456-8137 2886 Fax: (703) 456-8100 2887 EMail: rsabett@cooley.com 2889 Charles (Chas) R. Merrill 2890 McCarter & English, LLP 2891 Four Gateway Center 2892 100 Mulberry Street 2893 Newark, New Jersey 07101-0652 2894 Phone: (973) 622-4444 2895 Fax: (973) 624-7070 2896 EMail: cmerrill@concentric.net 2898 Stephen S. Wu 2899 Infoliance, Inc. 2900 101 First St. # 725 2901 Los Altos, CA 94022 2902 Phone: (650) 917-8045 2903 Fax: (650) 618-1454 2904 EMail: swu@infoliance.com 2906 NOTES 2907 1 A paper copy of the ABA Digital Signature Guidelines can be 2908 purchased from the ABA. See http://www.abanet.com for ordering 2909 details. The DSG may also be downloaded without charge from the ABA 2910 website at 2911 http://www.abanet.org/scitech/ec/isc/digital_signature.html. 2913 2 A draft of the PKI Assessment Guidelines may be downloaded 2914 without charge from the ABA website at 2915 http://www.abanet.org/scitech/ec/isc/pag/pag.html. 2917 3 The term "meaningful" means that the name form has commonly 2918 understood semantics to determine identity of the person and/or 2919 organization. Directory names and RFC 822 names may be more or less 2920 meaningful. 2922 4 The subject may not need to prove to the CA that the subject has 2923 possession of the private key corresponding to the public key being 2924 registered if the CA generates the subject's key pair on the 2925 subject's behalf. 2927 5 Examples of means to identify and authenticate individuals include 2928 biometric means (such as thumb print, ten finger print, and scan of 2929 the face, palm, or retina), a driver's license, a credit card, a 2930 company badge, and a government badge. 2932 6 Certificate "modification" does not refer to making a change to an 2933 existing certificate, since this would prevent the verification of 2934 any digital signatures on the certificate and cause the certificate 2935 to be invalid. Rather, the concept of "modification" refers to a 2936 situation where the information referred to in the certificate has 2937 changed or should be changed, and the CA issues a new certificate 2938 containing the modified information. One example is a subscriber 2939 that changes his or her name, which would necessitate the issuance 2940 of a new certificate containing the new name. 2942 7 The n out of m rule allows a private key to be split in m parts. 2943 The m parts may be given to m different individuals. Any n parts 2944 out of the m parts may be used to fully reconstitute the private 2945 key, but having any n-1 parts provides one with no information about 2946 the private key. 2948 8 A private key may be escrowed, backed up, or archived. Each of 2949 these functions has a different purpose. Thus, a private key may go 2950 through any subset of these functions depending on the requirements. 2951 The purpose of escrow is to allow a third party (such as an 2952 organization or government) to obtain the private key without the 2953 cooperation of the subscriber. The purpose of back up is to allow 2954 the subscriber to reconstitute the key in case of the destruction or 2955 corruption of the key for business continuity purposes. The 2956 purpose of archive is to provide for reuse of the private key in 2957 future, e.g., use to decrypt a document. 2959 9 WebTrust refers to the "WebTrust Program for Certification 2960 Authorities," from the American Institute of Certified Public 2961 Accountants, Inc., and the Canadian Institute of Chartered 2962 Accountants. 2964 10 See . 2966 11 All or some of the following items may be different for the 2967 various types of entities, i.e., CA, RA, and end entities. 2969 LIST OF ACRONYMS 2970 ABA - American Bar Association 2971 CA - Certification Authority 2973 CPS - Certification Practice Statement 2974 CRL - Certificate Revocation List 2975 DAM - Draft Amendment 2976 FIPS - Federal Information Processing Standard 2977 I&A - Identification and Authentication 2978 IEC - International Electrotechnical Commission 2979 IETF - Internet Engineering Task Force 2980 IP - Internet Protocol 2981 ISO - International Organization for Standardization 2982 ITU - International Telecommunications Union 2983 NIST - National Institute of Standards and Technology 2984 OID - Object Identifier 2985 PIN - Personal Identification Number 2986 PKI - Public Key Infrastructure 2987 PKIX - Public Key Infrastructure (X.509) (IETF Working Group) 2988 RA - Registration Authority 2989 RFC - Request For Comment 2990 URL - Uniform Resource Locator 2991 US - United States 2993 < draft-ietf-pkix-ipki-new-rfc2527-01.txt > 2995 Expires in six months from January 3, 2002