idnits 2.17.1 draft-ietf-pkix-ipki-part4-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 44 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 45 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1.1 Overview' ) ** 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 649 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** The abstract seems to contain references ([ABA1], [BAU1], [PEM1], [ISO1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 14 has weird spacing: '... This docum...' == Line 15 has weird spacing: '...), its areas...' == Line 16 has weird spacing: '... and its w...' == Line 20 has weird spacing: '... and may b...' == Line 24 has weird spacing: '... To learn ...' == (644 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 3, 1997) is 9794 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. 'BAU1' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO1' ** Downref: Normative reference to an Historic RFC: RFC 1422 (ref. 'PEM1') == Outdated reference: A later version (-11) exists of draft-ietf-pkix-ipki-part1-03 Summary: 13 errors (**), 0 flaws (~~), 10 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group S. Chokhani (CygnaCom Solutions, Inc.) 3 Internet Draft W. Ford (VeriSign, Inc.) 5 Expires in six months from July 3, 1997 7 Internet Public Key Infrastructure 8 Part IV: Certificate Policy and Certification Practices Framework 10 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of 6 months 20 and may be updated, replaced, or may become obsolete by other 21 documents at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as work in progress. 24 To learn the current status of any Internet-Draft, please check the 25 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za(Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Abstract 32 This document presents a framework to assist the writers of 33 certificate policies or certification practice statements for 34 certification authorities and public key infrastructures. In 35 particular, the framework provides a comprehensive list of topics 36 that potentially (at the writer's discretion) need to be covered in a 37 certificate policy definition or a certification practice statement. 38 It is intended that this document, when fully developed, be published 39 as an Informational RFC. 41 1. INTRODUCTION 43 1.1 BACKGROUND 45 A public-key certificate (hereinafter "certificate") binds a 46 public-key value to a set of information that identifies the 47 entity (such as person, organization, account, or site) associated 48 with use of the corresponding private key (this entity is known as 49 the "subject" of the certificate). A certificate is used by a 50 "certificate user" or "relying party" that needs to use, and rely 51 upon the accuracy of, the public key distributed via that 52 certificate (a certificate user is typically an entity that is 53 verifying a digital signature from the certificate's subject or an 54 entity sending encrypted data to the subject). The degree to 55 which a certificate user can trust the binding embodied in a 56 certificate depends on several factors. These factors include the 57 practices followed by the certification authority (CA) in 58 authenticating the subject; the CA's operating policy, procedures, 59 and security controls; the subject's obligations (for example, in 60 protecting the private key); and the stated undertakings and legal 61 obligations of the CA (for example, warranties and limitations on 62 liability). 64 A Version 3 X.509 certificate may contain a field declaring that 65 one or more specific certificate policies applies to that 66 certificate [ISO1]. According to X.509, a certificate policy is 67 "a named set of rules that indicates the applicability of a 68 certificate to a particular community and/or class of application 69 with common security requirements." A certificate policy may be 70 used by a certificate user to help in deciding whether a 71 certificate, and the binding therein, is sufficiently trustworthy 72 for a particular application. The certificate policy concept is 73 an outgrowth of the policy statement concept developed for 74 Internet Privacy Enhanced Mail [PEM1] and expanded upon in [BAU1]. 76 A more detailed description of the practices followed by a CA in 77 issuing and otherwise managing certificates may be contained in a 78 certification practice statement (CPS) published by or referenced 79 by the CA. According to the American Bar Association Digital 80 Signature Guidelines (hereinafter "ABA Guidelines"), "a CPS is a 81 statement of the practices which a certification authority employs 82 in issuing certificates." [ABA1] 84 1.2 PURPOSE 86 The purpose of this document is to establish a clear relationship 87 between certificate policies and CPSs, and to present a framework 88 to assist the writers of certificate policies or CPSs with their 89 tasks. In particular, the framework identifies the elements that 90 may need to be considered in formulating a certificate policy or a 91 CPS. The purpose is not to define particular certificate policies 92 or CPSs, per se. 94 1.3 SCOPE 96 The scope of this document is limited to discussion of the 97 contents of a certificate policy (as defined in X.509) or CPS (as 98 defined in the ABA Guidelines). In particular, this document 99 describes the types of information that should be considered for 100 inclusion in a certificate policy definition or a CPS. While the 101 framework as presented generally assumes use of the X.509 version 102 3 certificate format, it is not intended that the material be 103 restricted to use of that certificate format. Rather, it is 104 intended that this framework be adaptable to other certificate 105 formats that may come into use. 107 The scope does not extend to defining security policies generally 108 (such as organization security policy, system security policy, or 109 data labeling policy) beyond the policy elements that are 110 considered of particular relevance to certificate policies or 111 CPSs. 113 This document does not define a specific certificate policy or 114 CPS. 116 It is assumed that the reader is familiar with the general 117 concepts of digital signatures, certificates, and public-key 118 infrastructure, as used in X.509 and the ABA Guidelines. 120 2. DEFINITIONS 122 This document makes use of the following defined terms: 124 Activation data - Data values, other than keys, that are required 125 to operate cryptographic modules and that need to be protected 126 (e.g., a PIN, a passphrase, or a manually-held key share). 128 CA-certificate - A certificate for one CA's public key issued by 129 another CA. 131 Certificate policy - A named set of rules that indicates the 132 applicability of a certificate to a particular community and/or 133 class of application with common security requirements. For 134 example, a particular certificate policy might indicate 135 applicability of a type of certificate to the authentication of 136 electronic data interchange transactions for the trading of goods 137 within a given price range. 139 Certification path - An ordered sequence of certificates which, 140 together with the public key of the initial object in the path, 141 can be processed to obtain that of the final object in the path. 143 Certification Practice Statement (CPS) - A statement of the 144 practices which a certification authority employs in issuing 145 certificates. 147 Issuing certification authority (issuing CA) - In the context of a 148 particular certificate, the issuing CA is the CA that issued the 149 certificate (see also Subject certification authority). 151 Policy qualifier - Policy-dependent information that accompanies a 152 certificate policy identifier in an X.509 certificate. 154 Practices and policy specification - A list of practice and/or 155 policy statements, spanning a range of standard topics, for use in 156 expressing a certificate policy definition or CPS employing the 157 approach described in this framework. 159 Registration authority (RA) - An entity that is responsible for 160 identification and authentication of certificate subjects, but 161 that does not sign or issue certificates (i.e., an RA is delegated 162 certain tasks on behalf of a CA). 164 Relying party - A recipient of a certificate who acts in reliance 165 on that certificate and/or digital signatures verified using that 166 certificate. In this document, the terms "certificate user" and 167 "relying party" are used interchangeably. 169 Subject certification authority (subject CA) - In the context of a 170 particular CA-certificate, the subject CA is the CA whose public 171 key is certified in the certificate (see also Issuing 172 certification authority). 174 3. CONCEPTS 176 This section explains the concepts of certificate policy and CPS, and 177 describes their relationship. Other related concepts are also 178 described. Some of the material covered in this section and in some 179 other sections is specific to certificate policies extensions as 180 defined X.509 version 3. Except for those sections, this framework 181 is intended to be adaptable to other certificate formats that may 182 come into use. 184 3.1 CERTIFICATE POLICY 186 When a certification authority issues a certificate, it is 187 providing a statement to a certificate user (i.e., a relying 188 party) that a particular public key is bound to a particular 189 entity (the certificate subject). However, the extent to which 190 the certificate user should rely on that statement by the CA needs 191 to be assessed by the certificate user. Different certificates 192 are issued following different practices and procedures, and may 193 be suitable for different applications and/or purposes. 195 The X.509 standard defines a certificate policy as "a named set of 196 rules that indicates the applicability of a certificate to a 197 particular community and/or class of application with common 198 security requirements"[ISO1]. An X.509 Version 3 certificate may 199 contain an indication of certificate policy, which may be used by 200 a certificate user to decide whether or not to trust a certificate 201 for a particular purpose. 203 A certificate policy, which needs to be recognized by both the 204 issuer and user of a certificate, is represented in a certificate 205 by a unique, registered Object Identifier. The registration 206 process follows the procedures specified in ISO/IEC and ITU 207 standards. The party that registers the Object Identifier also 208 publishes a textual specification of the certificate policy, for 209 examination by certificate users. Any one certificate will 210 typically declare a single certificate policy or, possibly, be 211 issued consistent with a small number of different policies. 213 Certificate policies also constitute a basis for accreditation of 214 CAs. Each CA is accredited against one or more certificate 215 policies which it is recognized as implementing. When one CA 216 issues a CA-certificate for another CA, the issuing CA must assess 217 the set of certificate policies for which it trusts the subject CA 218 (such assessment may be based upon accreditation with respect to 219 the certificate policies involved). The assessed set of 220 certificate policies is then indicated by the issuing CA in the 221 CA-certificate. The X.509 certification path processing logic 222 employs these certificate policy indications in its well-defined 223 trust model. 225 3.2 CERTIFICATE POLICY EXAMPLES 227 For example purposes, suppose that IATA undertakes to define some 228 certificate policies for use throughout the airline industry, in a 229 public-key infrastructure operated by IATA in combination with 230 public-key infrastructures operated by individual airlines. Two 231 certificate policies are defined - the IATA General-Purpose 232 policy, and the IATA Commercial-Grade policy. 234 The IATA General-Purpose policy is intended for use by industry 235 personnel for protecting routine information (e.g., casual 236 electronic mail) and for authenticating connections from World 237 Wide Web browsers to servers for general information retrieval 238 purposes. The key pairs may be generated, stored, and managed 239 using low-cost, software-based systems, such as commercial 240 browsers. Under this policy, a certificate may be automatically 241 issued to anybody listed as an employee in the corporate directory 242 of IATA or any member airline who submits a signed certificate 243 request form to a network administrator in his or her 244 organization. 246 The IATA Commercial-Grade policy is used to protect financial 247 transactions or binding contractual exchanges between airlines. 248 Under this policy, IATA requires that certified key pairs be 249 generated and stored in approved cryptographic hardware tokens. 250 Certificates and tokens are provided to airline employees with 251 disbursement authority. These authorized individuals are required 252 to present themselves to the corporate security office, show a 253 valid identification badge, and sign an undertaking to protect the 254 token and use it only for authorized purposes, before a token and 255 a certificate are issued. 257 3.3 X.509 CERTIFICATE FIELDS 259 The following extension fields in an X.509 certificate are used to 260 support certificate policies: 262 * Certificate Policies extension; 263 * Policy Mappings extension; and 264 * Policy Constraints extension. 266 3.3.1 Certificate Policies Extension 268 The Certificate Policies extension has two variants - one with 269 the field flagged non- critical and one with the field flagged 270 critical. The purpose of the field is different in the two 271 cases. 273 A non-critical Certificate Policies field lists certificate 274 policies that the certification authority declares are 275 applicable. However, use of the certificate is not restricted 276 to the purposes indicated by the applicable policies. Using 277 the example of the IATA General- Purpose and Commercial-Grade 278 policies defined in Section 3.2, the certificates issued to 279 regular airline employees will contain the object identifier 280 for certificate policy for the General-Purpose policy. The 281 certificates issued to the employees with disbursement 282 authority will contain the object identifiers for both the 283 General-Purpose policy and the Commercial-Grade policy. The 284 Certificate Policies field may also optionally convey qualifier 285 values for each identified policy; use of qualifiers is 286 discussed in Section 3.4. 288 The non-critical Certificate Policies field is designed to be 289 used by applications as follows. Each application is pre- 290 configured to know what policy it requires. Using the example 291 in Section 3.2, electronic mail applications and Web servers 292 will be configured to require the General-Purpose policy. 293 However, an airline's financial applications will be configured 294 to require the Commercial-Grade policy for validating financial 295 transactions over a certain dollar value. 297 When processing a certification path, a certificate policy that 298 is acceptable to the certificate-using application must be 299 present in every certificate in the path, i.e., in CA- 300 certificates as well as end entity certificates. 302 If the Certificate Policies field is flagged critical, it 303 serves the same purpose as described above but also has an 304 additional role. It indicates that the use of the certificate 305 is restricted to one of the identified policies, i.e., the 306 certification authority is declaring that the certificate must 307 only be used in accordance with the provisions of one of the 308 listed certificate policies. This field is intended to protect 309 the certification authority against damage claims by a relying 310 party who has used the certificate for an inappropriate purpose 311 or in an inappropriate manner, as stipulated in the applicable 312 certificate policy definition. 314 For example, the Internal Revenue Service might issue 315 certificates to taxpayers for the purpose of protecting tax 316 filings. The Internal Revenue Service understands and can 317 accommodate the risks of accidentally issuing a bad 318 certificate, e.g., to a wrongly- authenticated person. 319 However, suppose someone used an Internal Revenue Service tax- 320 filing certificate as the basis for encrypting multi-million- 321 dollar-value proprietary secrets which subsequently fell into 322 the wrong hands because of an error in issuing the Internal 323 Revenue Service certificate. The Internal Revenue Service may 324 want to protect itself against claims for damages in such 325 circumstances. The critical-flagged Certificate Policies 326 extension is intended to mitigate the risk to the certificate 327 issuer in such situations. 329 3.3.2 Policy Mappings Extension 331 The Policy Mappings extension may only be used in CA- 332 certificates. This field allows a certification authority to 333 indicate that certain policies in its own domain can be 334 considered equivalent to certain other policies in the subject 335 certification authority's domain. 337 For example, suppose the ACE Corporation establishes an 338 agreement with the ABC Corporation to cross-certify each 339 others' public-key infrastructures for the purposes of mutually 340 protecting electronic data interchange (EDI). Further, suppose 341 that both companies have pre-existing financial transaction 342 protection policies called ace-e- commerce and abc-e-commerce, 343 respectively. One can see that simply generating cross 344 certificates between the two domains will not provide the 345 necessary interoperability, as the two companies' applications 346 are configured with and employee certificates are populated 347 with their respective certificate policies. One possible 348 solution is to reconfigure all of the financial applications to 349 require either policy and to reissue all the certificates with 350 both policies. Another solution, which may be easier to 351 administer, uses the Policy Mapping field. If this field is 352 included in a cross-certificate for the ABC Corporation 353 certification authority issued by the ACE Corporation 354 certification authority, it can provide a statement that the 355 ABC's financial transaction protection policy (i.e., abc-e- 356 commerce) can be considered equivalent to that of the ACE 357 Corporation (i.e., ace-e- commerce). 359 3.3.3 Policy Constraints Extension 361 The Policy Constraints extension supports two optional 362 features. The first is the ability for a certification 363 authority to require that explicit certificate policy 364 indications be present in all subsequent certificates in a 365 certification path. Certificates at the start of a 366 certification path may be considered by a certificate user to 367 be part of a trusted domain, i.e., certification authorities 368 are trusted for all purposes so no particular certificate 369 policy is needed in the Certificate Policies extension. Such 370 certificates need not contain explicit indications of 371 certificate policy. However, when a certification authority in 372 the trusted domain certifies outside the domain, it can 373 activate the requirement for explicit certificate policy in 374 subsequent certificates in the certification path. 376 The other optional feature in the Policy Constraints field is 377 the ability for a certification authority to disable policy 378 mapping by subsequent certification authorities in a 379 certification path. It may be prudent to disable policy 380 mapping when certifying outside the domain. This can assist in 381 controlling risks due to transitive trust, e.g., a domain A 382 trusts domain B, domain B trusts domain C, but domain A does 383 not want to be forced to trust domain C. 385 3.4 POLICY QUALIFIERS 387 The Certificate Policies extension field has a provision for 388 conveying, along with each certificate policy identifier, 389 additional policy-dependent information in a qualifier field. The 390 X.509 standard does not mandate the purpose for which this field 391 is to be used, nor does it prescribe the syntax for this field. 392 Policy qualifier types can be registered by any organization. 394 The following policy qualifier types are defined in PKIX Part I 395 [PKI1]: 397 (a) The CPS Pointer qualifier contains a pointer to a 398 Certification Practice Statement (CPS) published by the CA. 399 The pointer is in the form of a uniform resource identifier 400 (URI). 402 (b) The User Notice qualifier contains a text string that is to 403 be displayed to a certificate user (including subscribers and 404 relying parties) prior to the use of the certificate. The text 405 string may be an IA5String or a BMPString - a subset of the ISO 406 100646-1 multiple octet coded character set. A CA may invoke a 407 procedure that requires that the certficate user acknowledge 408 that the applicable terms and conditions have been disclosed or 409 accepted. 411 Policy qualifiers can be used to support the definition of 412 generic, or parameterized, certificate policy definitions. 413 Provided the base certificate policy definition so provides, 414 policy qualifier types can be defined to convey, on a per- 415 certificate basis, additional specific policy details that fill in 416 the generic definition. 417 3.5 CERTIFICATION PRACTICE STATEMENT 419 The term certification practice statement (CPS) is defined by the 420 ABA Guidelines as: "A statement of the practices which a 421 certification authority employs in issuing certificates." [ABA1] 422 In the 1995 draft of the ABA guidelines, the ABA expands this 423 definition with the following comments: 425 A certification practice statement may take the form of a 426 declaration by the certification authority of the details of 427 its trustworthy system and the practices it employs in its 428 operations and in support of issuance of a certificate, or it 429 may be a statute or regulation applicable to the certification 430 authority and covering similar subject matter. It may also be 431 part of the contract between the certification authority and 432 the subscriber. A certification practice statement may also be 433 comprised of multiple documents, a combination of public law, 434 private contract, and/or declaration. 436 Certain forms for legally implementing certification practice 437 statements lend themselves to particular relationships. For 438 example, when the legal relationship between a certification 439 authority and subscriber is consensual, a contract would 440 ordinarily be the means of giving effect to a certification 441 practice statement. The certification authority's duties to a 442 relying person are generally based on the certification 443 authority's representations, which may include a certification 444 practice statement. 446 Whether a certification practice statement is binding on a 447 relying person depends on whether the relying person has 448 knowledge or notice of the certification practice statement. A 449 relying person has knowledge or at least notice of the contents 450 of the certificate used by the relying person to verify a 451 digital signature, including documents incorporated into the 452 certificate by reference. It is therefore advisable to 453 incorporate a certification practice statement into a 454 certificate by reference. 456 As much as possible, a certification practice statement should 457 indicate any of the widely recognized standards to which the 458 certification authority's practices conform. Reference to 459 widely recognized standards may indicate concisely the 460 suitability of the certification authority's practices for 461 another person's purposes, as well as the potential 462 technological compatibility of the certificates issued by the 463 certification authority with repositories and other systems. 465 3.6 RELATIONSHIP BETWEEN CERTIFICATE POLICY AND CERTIFICATION 466 PRACTICE STATEMENT 468 The concepts of certificate policy and CPS come from different 469 sources and were developed for different reasons. However, their 470 interrelationship is important. 472 A certification practice statement is a detailed statement by a 473 certification authority as to its practices, that potentially 474 needs to be understood and consulted by subscribers and 475 certificate users (relying parties). Although the level of detail 476 may vary among CPSs, they will generally be more detailed than 477 certificate policy definitions. Indeed, CPSs may be quite 478 comprehensive, robust documents providing a description of the 479 precise service offerings, detailed procedures of the life-cycle 480 management of certificates, and more - a level of detail which 481 weds the CPS to a particular (proprietary) implementation of a 482 service offering. 484 Although such detail may be indispensable to adequately disclose, 485 and to make a full assessment of trustworthiness in the absence of 486 accreditation or other recognized quality metrics, a detailed CPS 487 does not form a suitable basis for interoperability between CAs 488 operated by different organizations. Rather, certificate policies 489 best serve as the vehicle on which to base common interoperability 490 standards and common assurance criteria on an industry-wide (or 491 possibly more global) basis. A CA with a single CPS may support 492 multiple certificate policies (used for different application 493 purposes and/or by different certificate user communities). Also, 494 multiple different CAs, with non-identical certification practice 495 statements, may support the same certificate policy. 497 For example, the Federal Government might define a government-wide 498 certificate policy for handling confidential human resources 499 information. The certificate policy definition will be a broad 500 statement of the general characteristics of that certificate 501 policy, and an indication of the types of applications for which 502 it is suitable for use. Different departments or agencies that 503 operate certification authorities with different certification 504 practice statements might support this certificate policy. At the 505 same time, such certification authorities may support other 506 certificate policies. 508 The main difference between certificate policy and CPS can 509 therefore be summarized as follows: 511 (a) Most organizations that operate public or inter- 512 organizational certification authorities will document their 513 own practices in CPSs or similar statements. The CPS is one of 514 the organization's means of protecting itself and positioning 515 its business relationships with subscribers and other entities. 517 (b) There is strong incentive, on the other hand, for a 518 certificate policy to apply more broadly than to just a single 519 organization. If a particular certificate policy is widely 520 recognized and imitated, it has great potential as the basis of 521 automated certificate acceptance in many systems, including 522 unmanned systems and systems that are manned by people not 523 independently empowered to determine the acceptability of 524 different presented certificates. 526 In addition to populating the certificate policies field with the 527 certificate policy identifier, a certification authority may 528 include, in certificates it issues, a reference to its 529 certification practice statement. A standard way to do this, 530 using a certificate policy qualifier, is described in Section 3.4. 532 3.7 PRACTICES AND POLICY SPECIFICATION 534 A practices and policy specification is a list of practice and/or 535 policy statements, spanning a range of standard topics, for use in 536 expressing a certificate policy definition or CPS employing the 537 approach described in this framework. 539 A certificate policy can be expressed as a single practices and 540 policy specification. 542 A CPS can be expressed as a single practices and policy 543 specification with each component addressing the requirements of 544 one or more certificate policies, or, alternatively, as an 545 organized collection of practices and policy specifications. For 546 example, a CPS could be expressed as a combination of the 547 following: 549 (a) a list of certificate policies supported by the CPS; 551 (b) for each certificate policy in (a), a practices and policy 552 specification which contains statements that refine that 553 certificate policy by filling in details not stipulated in that 554 policy or expressly left to the discretion of the CPS by that 555 certificate policy; such statements serve to state how this 556 particular CPS implements the requirements of the particular 557 certificate policy; 559 (c) a practices and policy specification that contains 560 statements regarding the certification practices on the CA, 561 regardless of certificate policy. 563 The statements provided in (b) and (c) may augment or refine the 564 stipulations of the applicable certificate policy definition, but 565 must not conflict with any of the stipulations of such certificate 566 policy definition. 568 This framework outlines the contents of a practices and policy 569 specification, in terms of eight primary components, as follows: 571 * Introduction; 573 * General Provisions; 575 * Identification and Authentication; 577 * Operational Requirements; 579 * Physical, Procedural, and Personnel Security Controls; 581 * Technical Security Controls; 583 * Certificate and CRL Profile; and 585 * Specification Administration. 587 Components can be further divided into subcomponents, and a 588 subcomponent may comprise multiple elements. Section 4 provides a 589 more detailed description of the contents of the above components, 590 and their subcomponents. 592 4. PRACTICES AND POLICY SPECIFICATION TOPICS 594 This section expands upon the contents of a practices and policy 595 specification, as introduced in Section 3.7. The topics identified 596 in this section are, consequently, candidate topics for inclusion in 597 a certificate policy definition or CPS. 599 While many topics are identified, it is not necessary for a 600 certificate policy or a CPS to include a concrete statement for every 601 such topic. Rather, a particular certificate policy or CPS may 602 state "no stipulation" for a component, subcomponent, or element on 603 which the particular certificate policy or CPS imposes no 604 requirements. In this sense, the list of topics can be considered a 605 checklist of topics for consideration by the certificate policy or 606 CPS writer. It is recommended that each and every component and 607 subcomponent be included in a certificate policy or CPS, even if 608 there is "no stipulation"; this will indicate to the reader that a 609 conscious decision was made to include or exclude that topic. This 610 protects against inadvertent omission of a topic, while facilitating 611 comparison of different certificate policies or CPSs, e.g., when 612 making policy mapping decisions. 614 In a certificate policy definition, it is possible to leave certain 615 components, subcomponents, and/or elements unspecified, and to 616 stipulate that the required information will be indicated in a policy 617 qualifier. Such certificate policy definitions can be considered 618 parameterized definitions. The practices and policy specification 619 should reference or define the required policy qualifier types and 620 should specify any applicable default values. 622 4.1 INTRODUCTION 624 This component identifies and introduces the practices and policy 625 specification, and indicates the types of entities and 626 applications for which the specification is targeted. 628 This component has the following subcomponents: 629 * Overview; 631 * Identification; 633 * Community and Applicability; and 635 * Contact Details. 637 4.1.1 Overview 639 This subcomponent provides a general introduction to the 640 specification. 642 4.1.2 Identification 644 This subcomponent provides any applicable names or other 645 identifiers, including ASN.1 object identifiers, for the 646 specification. 648 4.1.3 Community and Applicability 650 This subcomponent describes the types of entities that issue 651 certificates or that are certified as subject CAs (2, 3), the 652 types of entities that perform RA functions (4), and the types 653 of entities that are certified as subject end entities or 654 subscribers. (5, 6) 656 This subcomponent also contains: 658 * A list of applications for which the issued certificates 659 are suitable. 661 * A list of applications for which use of the issued 662 certificates is restricted. (This list implicitly prohibits 663 all other uses for the certificates.) 665 * A list of applications for which use of the issued 666 certificates is prohibited. 668 4.1.4 Contact Details 670 This subcomponent includes the name and mailing address of the 671 authority that is responsible for the registration, 672 maintenance, and interpretation of this certificate policy or 673 CPS. It also includes the name, electronic mail address, 674 telephone number, and fax number of a contact person. 676 4.2 GENERAL PROVISIONS 678 This component specifies any applicable presumptions on a range of 679 legal and general practices topics. 681 This component contains the following subcomponents: 683 * Liability; 685 * Obligations; 687 * Financial Responsibility; 689 * Interpretation and Enforcement; 691 * Fees; 693 * Publication and Repositories; 695 * Compliance Audit; 697 * Confidentiality; and 699 * Intellectual Property Rights. 701 Each subcomponent may need to separately state provisions applying 702 to the entity types: CA, repository, RA, subscriber, and relying 703 party. (Specific provisions regarding subscribers and relying 704 parties are only applicable in the Liability and Obligations 705 subcomponents.) 706 4.2.1 Liability 708 This subcomponent contains, for each entity type, any 709 applicable provisions regarding apportionment of liability, 710 such as: 712 * Warranties and limitations on warranties; 714 * Kinds of damages covered (e.g., indirect, special, 715 consequential, incidental, punitive, liquidated damages, 716 negligence and fraud) and disclaimers; 718 * Loss limitations (caps) per certificate or per 719 transaction; and 721 * Other exclusions (e.g., Acts of God, other party 722 responsibilities). 724 4.2.2 Obligations 726 This subcomponent contains, for each entity type, any 727 applicable provisions regarding the entity's obligations to 728 other entities. Such provisions may include: 730 * CA and/or RA obligations: 731 * Notification of issuance of a certificate to the 732 subscriber who is the subject of the certificate being 733 issued; 734 * Notification of issuance of a certificate to others 735 than the subject of the certificate; 736 * Notification of revocation or suspension of a 737 certificate to the subscriber whose certificate is being 738 revoked or suspended; and 739 * Notification of revocation or suspension of a 740 certificate to others than the subject whose certificate 741 is being revoked or suspended. 742 * Subscriber obligations: 744 * Accuracy of representations in certificate application; 745 * Protection of the entity's private key; 746 * Restrictions on private key and certificate use; and 747 * Notification upon private key compromise. 749 * Relying party obligations: 751 * Purposes for which certificate is used; 752 * Digital signature verification responsibilities; 753 * Revocation and suspension checking responsibilities; 754 and 755 * Acknowledgment of applicable liability caps and 756 warranties. 757 * Repository obligations 758 * Timely publication of certificates and revocation 759 information 761 4.2.3 Financial Responsibility 763 This subcomponent contains, for CAs, repository, and RAs, any 764 applicable provisions regarding financial responsibilities, 765 such as: 767 * Indemnification of CA and/or RA by relying parties; 769 * Fiduciary relationships (or lack thereof) between the 770 various entities; and 772 * Administrative processes (e.g., accounting, audit). 774 4.2.4 Interpretation and Enforcement 776 This subcomponent contains any applicable provisions regarding 777 interpretation and enforcement of the certificate policy or 778 CPS, addressing such topics as: 780 * Governing law; 782 * Severability of provisions, survival, merger, and notice; 783 and 785 * Dispute resolution procedures. 787 4.2.5 Fees 789 This subcomponent contains any applicable provisions regarding 790 fees charged by CAs, repositories, or RAs, such as: 792 * Certificate issuance or renewal fees; 794 * Certificate access fee; 796 * Revocation or status information access fee; 798 * Fees for other services such as policy information; and 800 * Refund policy. 802 4.2.6 Publication and Repositories 804 This subcomponent contains any applicable provisions regarding: 806 * A CA's obligations to publish information regarding its 807 practices, its certificates, and the current status of such 808 certificates; 810 * Frequency of publication; 812 * Access control on published information objects including 813 certificate policy definitions, CPS, certificates, 814 certificate status, and CRLs; and 816 * Requirements pertaining to the use of repositories 817 operated by CAs or by other independent parties. 819 4.2.7 Compliance Audit 821 This subcomponent addresses the following: 823 * Frequency of compliance audit for each entity; 825 * Identity of the auditor; 827 * Auditor's relationship to the entity being audited; (30) 829 * List of topics covered under the compliance audit; (31) 831 * Actions taken as a result of a deficiency found during 832 compliance audit; (32) 834 * Compliance audit results: who they are shared with (e.g., 835 subject CA, RA, and/or end entities), who provides them 836 (e.g., entity being audited or auditor), how they are 837 communicated. 839 4.2.8 Confidentiality Policy 841 This subcomponent addresses the following: 843 * Types of information that must be kept confidential by CA 844 or RA; 846 * Types of information that are not considered confidential; 848 * Who is entitled to be informed of reasons for revocation 849 and suspension of certificates; 850 * Policy on release of information to law enforcement 851 officials; 853 * Information that can be revealed as part of civil 854 discovery; 856 * Conditions upon which CA or RA may disclose upon owner's 857 request; and 859 * Any other circumstances under which confidential 860 information may be disclosed. 862 4.2.9 Intellectual Property Rights 864 This subcomponent addresses ownership rights of certificates, 865 practice/policy specifications, names, and keys. 867 4.3 IDENTIFICATION AND AUTHENTICATION 869 This component describes the procedures used to authenticate a 870 certificate applicant to a CA or RA prior to certificate issuance. 871 It also describes how parties requesting rekey or revocation are 872 authenticated. This component also addresses naming practices, 873 including name ownership recognition and name dispute resolution. 875 This component has the following subcomponents: 877 * Initial Registration; 879 * Routine Rekey; 881 * Rekey After Revocation; and 883 * Revocation Request. 885 4.3.1 Initial Registration 887 This subcomponent includes the following elements regarding 888 identification and authentication procedures during entity 889 registration or certificate issuance: 891 * Types of names assigned to the subject (7); 893 * Whether names have to be meaningful or not (8); 895 * Rules for interpreting various name forms; 897 * Whether names have to be unique; 898 * How name claim disputes are resolved; 900 * Recognition, authentication, and role of trademarks; 902 * If and how the subject must prove possession of the 903 companion private key for the public key being registered 904 (9); 906 * Authentication requirements for organizational identity of 907 subject (CA, RA, or end entity) (10); 909 * Authentication requirements for a person acting on behalf 910 of a subject (CA, RA, or end entity) (11), including: 912 * Number of pieces of identification required; 913 * How a CA or RA validates the pieces of identification 914 provided; 915 * If the individual must present personally to the 916 authenticating CA or RA; 917 * How an individual as an organizational person is 918 authenticated (12). 920 4.3.2 Routine Rekey 922 This subcomponent describes the identification and 923 authentication procedures for routine rekey for each subject 924 type (CA, RA, and end entity). (13) 926 4.3.3 Rekey After Revocation -- No Key Compromise 928 This subcomponent describes the identification and 929 authentication procedures for rekey for each subject type (CA, 930 RA, and end entity) after the subject certificate has been 931 revoked. (14) 933 4.3.4 Revocation Request 935 This subcomponent describes the identification and 936 authentication procedures for a revocation request by each 937 subject type (CA, RA, and end entity). (16) 939 4.4 OPERATIONAL REQUIREMENTS 941 This component is used to specify requirements imposed upon 942 issuing CA, subject CAs, RAs, or end entities with respect to 943 various operational activities. 945 This component consists of the following subcomponents: 947 * Certificate Application; 949 * Certificate Issuance; 951 * Certificate Acceptance; 953 * Certificate Suspension and Revocation; 955 * Security Audit Procedures; 957 * Records Archival; 959 * Key Changeover; 961 * Compromise and Disaster Recovery; and 963 * CA Termination. 965 Within each subcomponent, separate consideration may need to be 966 given to issuing CA, repository, subject CAs, RAs, and end 967 entities. 969 4.4.1 Certificate Application 971 This subcomponent is used to state requirements regarding 972 subject enrollment and request for certificate issuance. 974 4.4.2 Certificate Issuance 976 This subcomponent is used to state requirements regarding 977 issuance of a certificate and notification to the applicant of 978 such issuance. 980 4.4.3 Certificate Acceptance 982 This subcomponent is used to state requirements regarding 983 acceptance of an issued certificate and for consequent 984 publication of certificates. 986 4.4.4 Certificate Suspension and Revocation 988 This subcomponent addresses the following: 990 * Circumstances under which a certificate may be revoked; 992 * Who can request the revocation of the entity certificate; 994 * Procedures used for certificate revocation request; 996 * Revocation request grace period available to the subject; 998 * Circumstances under which a certificate may be suspended; 1000 * Who can request the suspension of a certificate; 1002 * Procedures to request certificate suspension; 1004 * How long the suspension may last; 1006 * If a CRL mechanism is used, the issuance frequency; 1008 * Requirements on relying parties to check CRLs; 1010 * On-line revocation/status checking availability; 1012 * Requirements on relying parties to perform on-line 1013 revocation/status checks; 1015 * Other forms of revocation advertisements available; and 1017 * Requirements on relying parties to check other forms of 1018 revocation advertisements. 1020 * Any variations on the above stipulations when the 1021 suspension or revocation is the result of private key 1022 compromise (as opposed to other reasons for suspension or 1023 revocation). 1025 4.4.5 Security Audit Procedures 1027 This subcomponent is used to describe event logging and audit 1028 systems, implemented for the purpose of maintaining a secure 1029 environment. Elements include the following: 1031 * Types of events recorded; (28) 1033 * Frequency with which audit logs are processed or audited; 1035 * Period for which audit logs are kept; 1037 * Protection of audit logs: 1039 - Who can view audit logs; 1040 - Protection against modification of audit log; and 1041 - Protection against deletion of audit log. 1043 * Audit log back up procedures; 1045 * Whether the audit log accumulation system is internal or 1046 external to the entity; 1048 * Whether the subject who caused an audit event to occur is 1049 notified of the audit action; and 1051 * Vulnerability assessments. 1052 4.4.6 Records Archival 1054 This subcomponent is used to describe general records archival 1055 (or records retention) policies, including the following: 1057 * Types of events recorded; (29) 1059 * Retention period for archive; 1061 * Protection of archive: 1063 - Who can view the archive; 1064 - Protection against modification of archive; and 1065 - Protection against deletion of archive. 1067 * Archive backup procedures; 1069 * Requirements for time-stamping of records; 1071 * Whether the archive collection system is internal or 1072 external; and 1073 * Procedures to obtain and verify archive information. 1075 4.4.7 Key Changeover 1077 This subcomponent describes the procedures to provide a new 1078 public key to a CA's users. 1080 4.4.8 Compromise and Disaster Recovery 1082 This subcomponent describes requirements relating to 1083 notification and recovery procedures in the event of compromise 1084 or disaster. Each of the following circumstances may need to 1085 be addressed separately: 1087 * The recovery procedures used if computing resources, 1088 software, and/or data are corrupted or suspected to be 1089 corrupted. These procedures describe how a secure 1090 environment is reestablished, which certificates are 1091 revoked, whether the entity key is revoked, how the new 1092 entity public key is provided to the users, and how the 1093 subjects are recertified. 1095 * The recovery procedures used if the entity public key is 1096 revoked. These procedures describe how a secure environment 1097 is reestablished, how the new entity public key is provided 1098 to the users, and how the subjects are recertified. 1100 * The recovery procedures used if the entity key is 1101 compromised. These procedures describe how a secure 1102 environment is reestablished, how the new entity public key 1103 is provided to the users, and how the subjects are 1104 recertified. 1106 4.4.9 CA Termination 1108 This subcomponent describes requirements relating to procedures 1109 for termination and for termination notification of a CA or RA, 1110 including the identity of the custodian of CA and RA archival 1111 records. 1113 4.5 PHYSICAL, PROCEDURAL, AND PERSONNEL SECURITY CONTROLS 1115 This component describes non-technical security controls (that is, 1116 physical, procedural, and personnel controls) used by the issuing 1117 CA to perform securely the functions of key generation, subject 1118 authentication, certificate issuance, certificate revocation, 1119 audit, and archival. 1121 This component can also be used to define non-technical security 1122 controls on repository, subject CAs, RAs, and end entities. The 1123 non technical security controls for the subject CAs, RAs, and end 1124 entities could be the same, similar, or very different. 1126 These non-technical security controls are critical to trusting the 1127 certificates since lack of security may compromise CA operations 1128 resulting, for example, in the creation of certificates or CRLs 1129 with erroneous information or the compromise of the CA private 1130 key. 1132 This component consists of three subcomponents: 1134 * Physical Security Controls; 1136 * Procedural Controls; and 1138 * Personnel Security Controls. 1140 Within each subcomponent, separate consideration will, in general, 1141 need to be given to each entity type, that is, issuing CA, 1142 repository, subject CAs, RAs, and end entities. 1144 4.5.1 Physical Security Controls 1146 In this subcomponent, the physical controls on the facility 1147 housing the entity systems are described.(21) Topics addressed 1148 may include: 1150 * Site location and construction; 1152 * Physical access; 1154 * Power and air conditioning; 1156 * Water exposures; 1158 * Fire prevention and protection; 1160 * Media storage; 1162 * Waste disposal; and 1164 * Off-site backup. 1166 4.5.2 Procedural Controls 1168 In this subcomponent, requirements for recognizing trusted 1169 roles are described, together with the responsibilities for 1170 each role.(22) 1172 For each task identified for each role, it should also be 1173 stated how many individuals are required to perform the task (n 1174 out m rule). Identification and authentication requirements 1175 for each role may also be defined. 1177 4.5.3 Personnel Security Controls 1179 This subcomponent addresses the following: 1181 * Background checks and clearance procedures required for 1182 the personnel filling the trusted roles; (23) 1184 * Background checks and clearance procedures requirements 1185 for other personnel, including janitorial staff; (24) 1187 * Training requirements and training procedures for each 1188 role; 1190 * Any retraining period and retraining procedures for each 1191 role; 1193 * Frequency and sequence for job rotation among various 1194 roles; 1196 * Sanctions against personnel for unauthorized actions, 1197 unauthorized use of authority, and unauthorized use of 1198 entity systems; (25) 1200 * Controls on contracting personnel, including: 1202 - Bonding requirements on contract personnel; 1203 - Contractual requirements including indemnification for 1204 damages due to the actions of the contractor personnel; 1205 - Audit and monitoring of contractor personnel; and 1206 - Other controls on contracting personnel. 1208 * Documentation to be supplied to personnel. 1210 4.6 TECHNICAL SECURITY CONTROLS 1212 This component is used to define the security measures taken by 1213 the issuing CA to protect its cryptographic keys and activation 1214 data (e.g., PINs, passwords, or manually-held key shares). This 1215 component may also be used to impose constraints on repositories, 1216 subject CAs and end entities to protect their cryptographic keys 1217 and critical security parameters. Secure key management is 1218 critical to ensure that all secret and private keys and activation 1219 data are protected and used only by authorized personnel. 1221 This component also describes other technical security controls 1222 used by the issuing CA to perform securely the functions of key 1223 generation, user authentication, certificate registration, 1224 certificate revocation, audit, and archival. Technical controls 1225 include life-cycle security controls (including software 1226 development environment security, trusted software development 1227 methodology) and operational security controls. 1229 This component can also be used to define other technical security 1230 controls on repositories, subject CAs, RAs, and end entities. 1232 This component has the following subcomponents: 1234 * Key Pair Generation and Installation; 1236 * Private Key Protection; 1238 * Other Aspects of Key Pair Management; 1240 * Activation Data; 1242 * Computer Security Controls; 1244 * Life-Cycle Security Controls; 1246 * Network Security Controls; and 1248 * Cryptographic Module Engineering Controls. 1250 4.6.1 Key Pair Generation and Installation 1252 Key pair generation and installation need to be considered for 1253 the issuing CA, repositories, subject CAs, RAs, and subject end 1254 entities. For each of these types of entities, the following 1255 questions potentially need to be answered: 1257 1. Who generates the entity public, private key pair? 1259 2. How is the private key provided securely to the entity? 1261 3. How is the entity's public key provided securely to the 1262 certificate issuer? 1264 4. If the entity is a CA (issuing or subject) how is the 1265 entity's public key provided securely to the users? 1267 5. What are the key sizes? 1269 6. Who generates the public key parameters? 1271 7. Is the quality of the parameters checked during key 1272 generation? 1274 8. Is the key generation performed in hardware or software? 1276 9. For what purposes may the key be used, or for what 1277 purposes should usage of the key be restricted (for X.509 1278 certificates, these purposes should map to the key usage 1279 flags in the Version 3, X.509 certificates)? 1281 4.6.2 Private Key Protection 1283 Requirements for private key protection need to be considered 1284 for the issuing CA, repositories, subject CAs, RAs, and subject 1285 end entities. For each of these types of entity, the following 1286 questions potentially need to be answered: 1288 1. What standards, if any, are required for the module used 1289 to generate the keys? For example, are the keys certified 1290 by the infrastructure required to be generated using modules 1291 complaint with the US FIPS 140-1? If so, what is the 1292 required FIPS 140-1 level of the module? 1294 2. Is the private key under n out of m multi-person 1295 control?(18) If yes, provide n and m (two person control is 1296 a special case of n out of m, where n = m = 2)? 1298 3. Is the private key escrowed? (19) If so, who is the 1299 escrow agent, what form is the key escrowed in (examples 1300 include plaintext, encrypted, split key), and what are the 1301 security controls on the escrow system? 1303 4. Is the private key backed up? If so, who is the backup 1304 agent, what form is the key backed up in (examples include 1305 plaintext, encrypted, split key), and what are the security 1306 controls on the backup system? 1308 5. Is the private key archived? If so, who is the archival 1309 agent, what form is the key archived in (examples include 1310 plaintext, encrypted, split key), and what are the security 1311 controls on the archival system? 1313 6. Who enters the private key in the cryptographic module? 1314 In what form (i.e., plaintext, encrypted, or split key)? 1315 How is the private key stored in the module (i.e., 1316 plaintext, encrypted, or split key)? 1318 7. Who can activate (use) the private key? What actions 1319 must be performed to activate the private key (e.g., login, 1320 power on, supply PIN, insert token/key, automatic, etc.)? 1321 Once the key is activated, is the key active for an 1322 indefinite period, active for one time, or active for a 1323 defined time period? 1325 8. Who can deactivate the private key and how? Example of 1326 how might include, logout, power off, remove token/key, 1327 automatic, or time expiration. 1329 9. Who can destroy the private key and how? Examples of how 1330 might include token surrender, token destruction, or key 1331 overwrite. 1333 4.6.3 Other Aspects of Key Pair Management 1335 Other aspects of key management need to be considered for the 1336 issuing CA, repositories, subject CAs, RAs, and subject end 1337 entities. For each of these types of entity, the following 1338 questions potentially need to be answered: 1340 1. Is the public key archived? If so, who is the archival 1341 agent and what are the security controls on the archival 1342 system? The archival system should provide integrity 1343 controls other than digital signatures since: the archival 1344 period may be greater than the cryptanalysis period for the 1345 key and the archive requires tamper protection, which is not 1346 provided by digital signatures. 1348 2. What are the usage periods, or active lifetimes, for the 1349 public and the private key respectively? 1351 4.6.4 Activation Data 1353 Activation data refers to data values other than keys that are 1354 required to operate cryptographic modules and that need to be 1355 protected. (20) Protection of activation data potentially 1356 needs to be considered for the issuing CA, subject CAs, RAs, 1357 and end entities. Such consideration potentially needs to 1358 address the entire life-cycle of the activation data from 1359 generation through archival and destruction. For each of the 1360 entity types (issuing CA, repository, subject CA, RA, and end 1361 entity) all of the questions listed in 4.6.1 through 4.6.3 1362 potentially need to be answered with respect to activation data 1363 rather than with respect to keys. 1365 4.6.5 Computer Security Controls 1367 This subcomponent is used to describe computer security 1368 controls such as: use of the trusted computing base concept, 1369 discretionary access control, labels, mandatory access 1370 controls, object reuse, audit, identification and 1371 authentication, trusted path, security testing, and penetration 1372 testing. Product assurance may also be addressed. 1374 A computer security rating for computer systems may be 1375 required. The rating could be based, for example, on the 1376 Trusted System Evaluation Criteria (TCSEC), Canadian Trusted 1377 Products Evaluation Criteria, European Information Technology 1378 Security Evaluation Criteria (ITSEC), or the Common Criteria. 1379 This subcomponent can also address requirements for product 1380 evaluation analysis, testing, profiling, product certification, 1381 and/or product accreditation related activity undertaken. 1383 4.6.6 Life Cycle Security Controls 1385 This subcomponent addresses system development controls and 1386 security management controls. 1388 System development controls include development environment 1389 security, development personnel security, configuration 1390 management security during product maintenance, software 1391 engineering practices, software development methodology, 1392 modularity, layering, use of failsafe design and implementation 1393 techniques (e.g., defensive programming) and development 1394 facility security. 1396 Security management controls include execution of tools and 1397 procedures to ensure that the operational systems and networks 1398 adhere to configured security. These tools and procedures 1399 include checking the integrity of the security software, 1400 firmware, and hardware to ensure their correct operation. 1402 This subcomponent can also address life-cycle security ratings 1403 based, for example, on the Trusted Software Development 1404 Methodology (TSDM) level IV and V, independent life- cycle 1405 security controls audit, and the Software Engineering 1406 Institute's Capability Maturity Model (SEI-CMM). 1408 4.6.7 Network Security Controls 1410 This subcomponent addresses network security related controls, 1411 including firewalls. 1413 4.6.8 Cryptographic Module Engineering Controls (26) 1415 This subcomponent addresses the following aspects of a 1416 cryptographic module: identification of the cryptographic 1417 module boundary, input/output, roles and services, finite state 1418 machine, physical security, software security, operating system 1419 security, algorithm compliance, electromagnetic compatibility, 1420 and self tests. Requirements may be expressed through 1421 reference to a standard such as U.S. FIPS 140-1. (27) 1423 4.7 CERTIFICATE AND CRL PROFILES 1425 This component is used to specify the certificate format and, if 1426 CRLs are used, the CRL format. Assuming use of the X.509 1427 certificate and CRL formats, this includes information on 1428 profiles, versions, and extensions used. 1430 This component has two subcomponents: 1432 * Certificate Profile; and 1434 * CRL Profile. 1436 4.7.1 Certificate Profile 1438 This subcomponent addresses such topics as the following 1439 (potentially by reference to a separate profile definition, 1440 such as the PKIX Part I profile): 1442 * Version number(s) supported; 1444 * Certificate extensions populated and their criticality; 1445 * Cryptographic algorithm object identifiers; 1447 * Name forms used for the CA, RA, and end entity names; 1449 * Name constraints used and the name forms used in the name 1450 constraints; 1452 * Applicable certificate policy Object Identifier(s); 1454 * Usage of the policy constraints extension; 1456 * Policy qualifiers syntax and semantics; and 1458 * Processing semantics for the critical certificate policy 1459 extension. 1461 4.7.2 CRL Profile 1463 This subcomponent addresses such topics as the following 1464 (potentially by reference to a separate profile definition, 1465 such as the PKIX Part I profile): 1467 * Version numbers supported for CRLs; and 1469 * CRL and CRL entry extensions populated and their 1470 criticality. 1472 4.8 SPECIFICATION ADMINISTRATION 1474 This component is used to specify how this particular practices 1475 and policy specification will be maintained. 1477 It contains the following subcomponents: 1479 * Specification Change Procedures; 1481 * Publication and Notification Procedures; and 1483 * CPS Approval Procedures. 1485 4.8.1 Specification Change Procedures 1487 It will occasionally be necessary to change certificate 1488 policies and Certification Practice Statements. Some of these 1489 changes will not materially reduce the assurance that a 1490 certificate policy or its implementation provides, and will be 1491 judged by the policy administrator as not changing the 1492 acceptability of certificates asserting the policy for the 1493 purposes for which they have been used. Such changes to 1494 certificate policies and Certification Practice Statements need 1495 not require a change in the certificate policy Object 1496 Identifier or the CPS pointer (URL). Other changes to a 1497 specification will change the acceptability of certificates for 1498 specific purposes, and these changes will require changes to 1499 the certificate policy Object Identifier or CPS pointer (URL). 1501 This subcomponent contains the following information: 1503 * A list of specification components, subcomponents, and/or 1504 elements thereof that can be changed without notification 1505 and without changes to the certificate policy Object 1506 Identifier or CPS pointer (URL). 1508 * A list of specification components, subcomponents, and/or 1509 elements thereof that may change following a notification 1510 period without changing the certificate policy Object 1511 Identifier or CPS pointer (URL). The procedures to be used 1512 to notify interested parties (relying parties, certification 1513 authorities, etc.) of the certificate policy or CPS changes 1514 are described. The description of notification procedures 1515 includes the notification mechanism, notification period for 1516 comments, mechanism to receive, review and incorporate the 1517 comments, mechanism for final changes to the policy, and the 1518 period before final changes become effective. 1520 * A list of specification components, subcomponents, and/or 1521 elements, changes to which require a change in certificate 1522 policy Object Identifier or CPS pointer (URL).. 1524 4.8.2 Publication and Notification Procedures 1526 This subcomponent contains the following elements: 1528 * A list of components, subcomponents, and elements thereof 1529 that exist but that are not made publicly available; (33) 1531 * Descriptions of mechanisms used to distribute the 1532 certificate policy definition or CPS, including access 1533 controls on such distribution. 1535 4.8.3 CPS Approval Procedures 1537 In a certificate policy definition, this subcomponent describes 1538 how the compliance of a specific CPS with the certificate 1539 policy can be determined. 1541 5. PRACTICES AND POLICY SPECIFICATION OUTLINE 1543 This section contains a possible outline for a practices and policy 1544 specification, intended to serve as a checklist or (with some further 1545 development) a standard template for use by certificate policy or CPS 1546 writers. Such a common outline will facilitate: 1548 (a) Comparison of two certificate policies during cross- 1549 certification (for the purpose of equivalency mapping). 1551 (b) Comparison of a CPS with a certificate policy definition to 1552 ensure that the CPS faithfully implements the policy. 1554 (c) Comparison of two CPSs. 1556 1. INTRODUCTION 1558 1.1 Overview 1560 1.2 Identification 1562 1.3 Community and Applicability 1563 1.3.1 Certification authorities 1564 1.3.2 Registration authorities 1565 1.3.3 End entities 1566 1.3.4 Applicability 1568 1.4 Contact Details 1569 1.4.1 Specification administration organization 1570 1.4.2 Contact person 1571 1.4.3 Person determining CPS suitability for the policy 1573 2. GENERAL PROVISIONS 1575 2.1 Liability 1577 2.1.1 CA liability 1578 2.1.2 RA liability 1580 2.2 Obligations 1582 2.2.1 CA obligations 1583 2.2.2 RA obligations 1584 2.2.3 Subscriber obligations 1585 2.2.4 Relying party obligations 2.2.5 Repository obligations 1587 2.3 Financial responsibility 1589 2.3.1 Indemnification by relying parties 1590 2.3.2 Fiduciary relationships 1591 2.3.3 Administrative processes 1593 2.4 Interpretation and Enforcement 1595 2.4.1 Governing law 1596 2.4.2 Severability, survival, merger, notice 1597 2.4.3 Dispute resolution procedures 1599 2.5 Fees 1601 2.5.1 Certificate issuance or renewal fees 1602 2.5.2 Certificate access fees 1603 2.5.3 Revocation or status information access fees 1604 2.5.4 Fees for other services such as policy information 1605 2.5.5 Refund policy 1607 2.6 Publication and Repository 1609 2.6.1 Publication of CA information 1610 2.6.2 Frequency of publication 1611 2.6.3 Access controls 1612 2.6.4 Repositories 1614 2.7 Compliance audit 1616 2.7.1 Frequency of entity compliance audit 1617 2.7.2 Identity/qualifications of auditor 1618 2.7.3 Auditor's relationship to audited party 1619 2.7.4 Topics covered by audit 1620 2.7.5 Actions taken as a result of deficiency 1621 2.7.6 Communication of results 1623 2.8 Confidentiality 1625 2.8.1 Types of information to be kept confidential 1626 2.8.2 Types of information not considered confidential 1627 2.8.3 Disclosure of certificate revocation/suspension information 1628 2.8.4 Release to law enforcement officials 1629 2.8.5 Release as part of civil discovery 1630 2.8.6 Disclosure upon owner's request 1631 2.8.7 Other information release circumstances 1633 2.9 Intellectual Property Rights 1635 3. IDENTIFICATION AND AUTHENTICATION (34) 1637 3.1 Initial Registration 1638 3.1.1 Types of names 1639 3.1.2 Need for names to be meaningful 1640 3.1.3 Rules for interpreting various name forms 1641 3.1.4 Uniqueness of names 1642 3.1.5 Name claim dispute resolution procedure 1643 3.1.6 Recognition, authentication and role of trademarks 1644 3.1.7 Method to prove possession of private key 1645 3.1.8 Authentication of organization identity 1646 3.1.9 Authentication of individual identity 1648 3.2 Routine Rekey 1650 3.3 Rekey after Revocation 1652 3.4 Revocation Request 1654 4. OPERATIONAL REQUIREMENTS (34) 1656 4.1 Certificate Application 1658 4.2 Certificate Issuance 1660 4.3 Certificate Acceptance 1662 4.4 Certificate Suspension and Revocation 1663 4.4.1 Circumstances for revocation 1664 4.4.2 Who can request revocation 1665 4.4.3 Procedure for revocation request 1666 4.4.4 Revocation request grace period 1667 4.4.5 Circumstances for suspension 1668 4.4.6 Who can request suspension 1669 4.4.7 Procedure for suspension request 1670 4.4.8 Limits on suspension period 1671 4.4.9 CRL issuance frequency (if applicable) 1672 4.4.10 CRL checking requirements 1673 4.4.11 On-line revocation/status checking availability 1674 4.4.12 On-line revocation checking requirements 1675 4.4.13 Other forms of revocation advertisements available 1676 4.4.14 Checking requirements for other forms of revocation 1677 advertisements 1678 4.4.15 Special requirements re key compromise 1680 4.5 Security Audit Procedures 1681 4.5.1 Types of event recorded 1682 4.5.2 Frequency of processing log 1683 4.5.3 Retention period for audit log 1684 4.5.4 Protection of audit log 1685 4.5.5 Audit log backup procedures 1686 4.5.6 Audit collection system (internal vs external) 1687 4.5.7 Notification to event-causing subject 1688 4.5.8 Vulnerability assessments 1690 4.6 Records Archival 1692 4.6.1 Types of event recorded 1693 4.6.2 Retention period for archive 1694 4.6.3 Protection of archive 1695 4.6.4 Archive backup procedures 1696 4.6.5 Archive collection system (internal or external) 1697 4.6.6 Procedures to obtain and verify archive information 1699 4.7 Key changeover 1701 4.8 Compromise and Disaster Recovery 1703 4.9 CA Termination 1705 5. PHYSICAL, PROCEDURAL, AND PERSONNEL SECURITY CONTROLS (34) 1707 5.1 Physical Controls 1708 5.1.1 Site location and construction 1709 5.1.2 Physical access 1710 5.1.3 Power and air conditioning 1711 5.1.4 Water exposures 1712 5.1.5 Fire prevention and protection 1713 5.1.6 Media storage 1714 5.1.7 Waste disposal 1715 5.1.8 Off-site backup 1717 5.2 Procedural Controls 1718 5.2.1 Trusted roles 1719 5.2.2 Number of persons required per task 1720 5.2.3 Identification and authentication for each role 1722 5.3 Personnel Controls 1723 5.3.1 Background, qualifications, experience, and clearance 1724 requirements 1725 5.3.2 Background check procedures 1726 5.3.3 Training requirements 1727 5.3.4 Retraining frequency and requirements 1728 5.3.5 Job rotation frequency and sequence 1729 5.3.6 Sanctions for unauthorized actions 1730 5.3.7 Contracting personnel requirements 1731 5.3.8 Documentation supplied to personnel 1733 6. TECHNICAL SECURITY CONTROLS (34) 1735 6.1 Key Pair Generation and Installation 1736 6.1.1 Key pair generation 1737 6.1.2 Private key delivery to entity 1738 6.1.3 Public key delivery to certificate issuer 1739 6.1.4 CA public key delivery to users 1740 6.1.5 Key sizes 1741 6.1.6 Public key parameters generation 1742 6.1.7 Parameter quality checking 1743 6.1.8 Hardware/software key generation 1744 6.1.9 Key usage purposes (as per X.509 v3 key usage field) 1746 6.2 Private Key Protection 1747 6.2.1 Standards for cryptographic module 1748 6.2.2 Private key (n out of m) multi-person control 1749 6.2.3 Private key escrow 1750 6.2.4 Private key backup 1751 6.2.5 Private key archival 1752 6.2.6 Private key entry into cryptographic module 1753 6.2.7 Method of activating private key 1754 6.2.8 Method of deactivating private key 1755 6.2.9 Method of destroying private key 1757 6.3 Other Aspects of Key Pair Management 1758 6.3.1 Public key archival 1759 6.3.2 Usage periods for the public and private keys 1761 6.4 Activation Data 1762 6.4.1 Activation data generation and installation 1763 6.4.2 Activation data protection 1764 6.4.3 Other aspects of activation data 1766 6.5 Computer Security Controls 1767 6.5.1 Specific computer security technical requirements 1768 6.5.2 Computer security rating 1770 6.6 Life Cycle Technical Controls 1771 6.6.1 System development controls 1772 6.6.2 Security management controls 1773 6.6.3 Life cycle security ratings 1775 6.7 Network Security Controls 1777 6.8 Cryptographic Module Engineering Controls 1779 7. CERTIFICATE AND CRL PROFILES 1781 7.1 Certificate Profile 1783 7.1.1 Version number(s) 1784 7.1.2 Certificate extensions 1785 7.1.3 Algorithm object identifiers 1786 7.1.4 Name forms 1787 7.1.5 Name constraints 1788 7.1.6 Certificate policy Object Identifier 1789 7.1.7 Usage of Policy Constraints extension 1790 7.1.8 Policy qualifiers syntax and semantics 1791 7.1.9 Processing semantics for the critical certificate policy 1792 extension 1794 7.2 CRL Profile 1796 7.2.1 Version number(s) 1797 7.2.2 CRL and CRL entry extensions 1799 8. SPECIFICATION ADMINISTRATION 1801 8.1 Specification change procedures 1803 8.2 Publication and notification policies 1805 8.3 CPS approval procedures 1807 6. SECURITY CONSIDERATIONS 1809 This entire memo deals with security, related to public-key 1810 certificates. 1812 7. ACKNOWLEDGMENTS 1814 We wish to thank Dave Fillingham, Jim Brandt, and Edmond Van Hees for 1815 their inspiration, support, and valuable inputs. The development of 1816 this document was supported by the Government of Canada's Policy 1817 Management Authority (PMA) Committee, the National Security Agency, 1818 the National Institute of Standards and Technology (NIST), and the 1819 American Bar Association Information Security Committee Accreditation 1820 Technical Working Group. 1822 We also wish to thank the following individuals for their review and 1823 input: 1825 Teresa Acevedo, A&N Associates; 1826 Michael Baum; VeriSign; 1827 Sharon Boeyen, Entrust; 1828 Bob Burger, McCarter & English; 1829 Bill Burr, NIST; 1830 Patrick Cain, BBN; 1831 Michael Harrop, Government of Canada Treasury Board; 1832 Rick Hornbeck, Digital Commerce Services; 1833 Francois Marinier, Domus Software; 1834 John Morris, CygnaCom Solutions; 1835 Tim Moses, Entrust; 1836 Noel Nazario, NIST; 1837 John Nicolletos, A&N Associates; 1838 Jean Petty, CygnaCom Solutions; 1839 Denis Pinkas, Bull; 1840 J.-F. Sauriol, Domus Software; 1841 Robert Shirey, BBN; 1842 Mark Silvern, VeriSign; 1843 David Simonetti, Booz, Allen and Hamilton; and 1844 Darryl Stal, Entrust. 1846 Johnny Hsiung, and Chris Miller assisted in the preparation of the 1847 manuscript. 1849 8. REFERENCES 1851 [ABA1] American Bar Association, Digital Signature Guidelines: Legal 1852 Infrastructure for Certification Authorities and Electronic Commerce, 1853 Draft 1995. 1855 [BAU1] Michael. S. Baum, Federal Certification Authority Liability 1856 and Policy, NIST-GCR- 94-654, June 1994. 1858 [ISO1] ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information 1859 Technology - Open Systems Interconnection: The Directory: 1860 Authentication Framework," 1997 edition. (Pending publication of 1997 1861 edition, use 1993 edition with the following amendment applied: 1862 Final Text of Draft Amendment DAM 1 to ISO/IEC 9594-8 on Certificate 1863 Extensions, June 1996.) 1865 [PEM1] S. Kent, "Privacy Enhancement for Internet Electronic Mail, 1866 Part II: Certificate- Based Key Management," Internet RFC 1422, 1993. 1868 [PKI1] R. Housley, W. Ford, W. Polk, D. Solo, "Internet Public Key 1869 Infrastructure, Part I: X.509 Certificate and CRL Profile," draft- 1870 ietf-pkix-ipki-part1-03.txt, 1996. 1872 9. AUTHORS' ADDRESSES 1874 Santosh Chokhani 1875 CygnaCom Solutions, Inc. 1876 Suite 100 West 1877 7927 Jones Branch Drive 1878 McLean, VA 22102 1880 Phone: (703) 848-0883 1881 Fax: (703) 848-0960 1882 EMail: chokhani@cygnacom.com 1884 Warwick Ford 1885 VeriSign, Inc. 1886 One Alewife Center 1887 Cambridge, MA 02140 1889 Phone: (617) 492-2816 x225 1890 Fax: (617) 661-0716 1891 EMail: wford@verisign.com 1893 NOTES 1895 1 The ABA Digital Signature Guidelines can be purchased from the ABA. 1896 See http://www.abanet.com for ordering details. 1898 2 Examples of types of entity for subject CAs are a subordinate 1899 organization (e.g., branch or division), a federal government agency, 1900 or a state or provincial government department. 1902 3 This statement can have significant implications. For example, 1903 suppose a bank claims that it issues CA certificates to its branches 1904 only. Now, the user of a CA certificate issued by the bank can 1905 assume that the subject CA in the certificate is a branch of the bank 1907 4 Examples of the types of subject RA entities are branch and 1908 division of an organization. 1910 5 Examples of types of subject end entities are bank customers, 1911 telephone company subscribers, and employees of a government 1912 department 1914 6 This statement can have significant implications. For example, 1915 suppose Government CA claims that it issues certificates to 1916 Government employees only. Now, the user of a certificate issued by 1917 the Government CA can assume that the subject of the certificate is a 1918 Government employee. 1920 7 Examples include X.500 distinguished name, Internet e-mail address, 1921 and URL. 1923 8 The term "meaningful" means that the name form has commonly 1924 understood semantics to determine identity of the person and/or 1925 organization. Directory names and RFC 822 names may be more or less 1926 meaningful. 1928 9 Examples of proof include the issuing CA generating the key, or 1929 requiring the subject to send an electronically signed request or to 1930 sign a challenge. 1932 10 Examples of organization identity authentication are: articles of 1933 incorporation, duly signed corporate resolutions, company seal, and 1934 notarized documents. 1936 11 Examples of individual identity authentication are: biometrics 1937 (thumb print, ten finger print, face, palm, and retina scan), 1938 driver's license, passport, credit card, company badge, and 1939 government badge. 1941 12 Examples include duly signed authorization papers or corporate ID 1942 badge. 1944 13 The identification policy for routine rekey should be the same as 1945 the one for initial registration since the same subject needs 1946 rekeying. The rekey authentication may be accomplished using the 1947 techniques for initial I&A or using digitally signed requests. 1949 14 This identification and authentication policy could be the same as 1950 that for initial registration. 1952 15 This policy could be the same as the one for initial registration. 1954 16 The identification policy for Revocation request could be the same 1955 as that for initial registration since the same subject certificate 1956 needs to be revoked. The authentication policy could accept a 1957 Revocation request digitally signed by subject. The authentication 1958 information used during initial registration could be acceptable for 1959 Revocation request. Other less stringent authentication policy could 1960 be defined. 1962 17 The identification policy for key compromise notification could be 1963 the same as the one for initial registration since the same subject 1964 certificate needs to be revoked. The authentication policy could 1965 accept a Revocation request digitally signed by subject. The 1966 authentication information used during initial registration could be 1967 acceptable for key compromise notification. Other less stringent 1968 authentication policy could be defined. 1970 18 The n out of m rule allows a key to be split in m parts. The m 1971 parts may be given to m different individuals. Any n parts out of 1972 the m parts may be used to fully reconstitute the key, but having any 1973 n-1 parts provides one with no information about the key. 1975 19 A key may be escrowed, backed up or archived. Each of these 1976 functions have different purpose. Thus, a key may go through any 1977 subset of these functions depending on the requirements. The purpose 1978 of escrow is to allow a third party (such as an organization or 1979 government) to legally obtain the key without the cooperation of the 1980 subject. The purpose of back up is to allow the subject to 1981 reconstitute the key in case of the destruction of the key. The 1982 purpose of archive is to provide for reuse of the key in future, 1983 e.g., use the private key to decrypt a document. 1985 20 An example of activation data is a PIN or passphrase. 1987 21 Examples of physical access controls are: monitored facility , 1988 guarded facility, locked facility, access controlled using tokens, 1989 access controlled using biometrics, and access controlled through an 1990 access list. 1992 22 Examples of the roles include system administrator, system 1993 security officer, and system auditor. The duties of the system 1994 administrator are to configure, generate, boot, and operate the 1995 system. The duties of the system security officer are to assign 1996 accounts and privileges. The duties of the system auditor are to set 1997 up system audit profile, perform audit file management, and audit 1998 review. 2000 23 The background checks may include clearance level (e.g., none, 2001 sensitive, confidential, secret, top secret, etc.) and the clearance 2002 granting authority name. In lieu of or in addition to a defined 2003 clearance, the background checks may include types of background 2004 information (e.g., name, place of birth, date of birth, home address, 2005 previous residences, previous employment, and any other information 2006 that may help determine trustworthiness). The description should 2007 also include which information was verified and how. 2009 24 For example, the certificate policy may impose personnel security 2010 requirements on the network system administrator responsible for a 2011 CA's network access. 2013 25 Each authorized person should be accountable for his/her actions. 2015 26 A cryptographic module is hardware, software, or firmware or any 2016 combination of them. 2018 27 The compliance description should be specific and detailed. For 2019 example, for each FIPS 140-1 requirement, describe the level and 2020 whether the level has been certified by an accredited laboratory. 2022 28 Example of audit events are: request to create a certificate, 2023 request to revoke a certificate, key compromise notification, 2024 creation of a certificate, revocation of a certificate, issuance of a 2025 certificate, issuance of a CRL, issuance of key compromise CRL, 2026 establishment of trusted roles on the CA, actions of truste 2027 personnel, changes to CA keys, etc. 2029 29 Example of archive events are: request to create a certificate, 2030 request to revoke a certificate, key compromise notification, 2031 creation of a certificate, revocation of a certificate, issuance of a 2032 certificate, issuance of a CRL, issuance of key compromise CRL, and 2033 changes to CA keys. 2035 30 A parent CA is an example of audit relationship. 2037 31 Example of compliance audit topics: sample check on the various 2038 I&A policies, comprehensive checks on key management policies, 2039 comprehensive checks on system security controls, comprehensive 2040 checks on operations policy, and comprehensive checks on certificate 2041 profiles. 2043 32 The examples include, temporary suspension of operations until 2044 deficiencies are corrected, revocation of entity certificate, change 2045 in personnel, invocation of liability policy, more frequent 2046 compliance audit, etc. 2048 33 An organization may choose not to make public some of its security 2049 controls, clearance procedures, or some others elements due to their 2050 sensitivity. 2052 34 All or some of the following items may be different for the 2053 various types of entities, i.e., CA, RA, and end entities. 2055 LIST OF ACRONYMS 2057 ABA - American Bar Association 2058 CA - Certification Authority 2059 CPS - Certification Practice Statement 2060 CRL - Certificate Revocation List 2061 DAM - Draft Amendment 2062 FIPS - Federal Information Processing Standard 2063 I&A - Identification and Authentication 2064 IEC - International Electrotechnical Commission 2065 IETF - Internet Engineering Task Force 2066 IP - Internet Protocol 2067 ISO - International Organization for Standardization 2068 ITU - International Telecommunications Union 2069 NIST - National Institute of Standards and Technology 2070 OID - Object Identifier 2071 PIN - Personal Identification Number 2072 PKI - Public Key Infrastructure 2073 PKIX - Public Key Infrastructure (X.509) (IETF Working Group) 2074 RA - Registration Authority 2075 RFC - Request For Comment 2076 URL - Uniform Resource Locator 2077 US - United States