idnits 2.17.1 draft-chokhani-cps-00.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-18) 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 58 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 59 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 731 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? == There are 9 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 13 has weird spacing: '... This docum...' == Line 14 has weird spacing: '...), its areas...' == Line 15 has weird spacing: '... and its w...' == Line 19 has weird spacing: '... and may b...' == Line 23 has weird spacing: '... To learn ...' == (726 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 (June 1997) is 9804 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '8' on line 211 looks like a reference -- Missing reference section? '10' on line 424 looks like a reference -- Missing reference section? '9' on line 518 looks like a reference -- Missing reference section? '1' on line 592 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 10 warnings (==), 6 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 June 1997 7 Certificate Policy and Certification Practice Statement Framework 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of 6 months 19 and may be updated, replaced, or may become obsolete by other 20 documents at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as work in progress. 23 To learn the current status of any Internet-Draft, please check the 24 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za(Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Abstract 31 This document presents an initial draft of a framework to assist the 32 writers of X.509 certificate policies or certification practice 33 statements for certification authorities and public key 34 infrastructures. In particular, the framework identifies a 35 comprehensive list of topics that potentially (at the writer's 36 discretion) need to be covered in an X.509 certificate policy or a 37 certification practice statement. 39 1. INTRODUCTION 41 1.1 BACKGROUND 43 An X.509 public key certificate (henceforth termed a certificate) 44 binds an entity to the entity's public key. The degree to which a 45 certificate user (a certificate user is typically a signature 46 verifier or a key token generator) can trust this binding depends 47 on several factors. These factors include the Certification 48 Authority (CA) policy and procedures for authentication of end 49 entities, CA operating policy, procedures and security controls, 50 end entity policy and procedures for handling private keys, etc. 51 The liability assumed by certificate issuers and end entities also 52 plays a role in the degree of trust. 54 Version 3 X.509 certificates may contain certificate policies [8]. 55 A certificate policy allows the users of a certificate to decide 56 how much trust to place in the certificate, i.e., in the binding 57 of the entity's identity and the entity's public key. According 58 to X.509, version 3, a certificate policy is "a named set of rules 59 that indicates the applicability of a certificate to a particular 60 community and/or class of application with common security 61 requirements." 63 A detailed description of how certificate policies are implemented 64 by a particular CA is called a Certification Practice Statement 65 (CPS). According to the American Bar Association (ABA), "a CPS is 66 a statement of the practices which a certification authority 67 employs in issuing certificates." When negotiating a cross 68 certification, CAs examine and compare each other's CPS. 70 1.2 PURPOSE 72 The purpose of this document is to present a framework that 73 identifies the elements that may need to be considered in 74 formulating a certificate policy or a CPS, to assist the writers 75 of certificate policies or CPSs with their task. The purpose is 76 not to define particular certificate policies or CPSs per se. 78 1.3 SCOPE 80 There are many classes of policies, such as organization security 81 policy, system security policy, data labeling policy, etc. The 82 scope of this document is limited to defining the aspects and 83 elements of a certificate policy (as described and intended in the 84 X.509, version 3 certificate standard and ABA digital signature 85 guidelines). While the certificate policy and certification 86 practices statement framework presented here was motivated by the 87 X.509 version 3 certificate standard, the framework can be used by 88 other public key certificate standards. 90 This document does not define a specific certificate policy or 91 CPS. Instead, it describes what types of information should be 92 included in a certificate policy (and documented in a CPS). This 93 document does not provide specific values or specific mechanisms 94 to choose those values. Specific security policy and the 95 mechanisms that implement them are the scope of a detailed 96 document, a CPS. 98 This document's scope is limited to provide a comprehensive 99 framework. It does not contain any guidance on how to write sound 100 certificate policies or CPS. 102 This certificate policy and CPS framework contains many topics. 103 It is not necessary for a policy or a CPS to define something 104 concrete for each topic. A tangible statement, "none", and "not 105 applicable" are all acceptable values. Addressing each and every 106 topic ensures that the policy and CPS writers have not omitted 107 anything. Addressing each and every topic in the defined sequence 108 also facilitates comparison of policies and certification practice 109 statements for the purpose of equivalency mapping (as described in 110 Section 3). 112 1.4 AUDIENCE 114 The audience for this document are the designers and policy- 115 makers of certificate infrastructures using version 3 X.509 116 certificates. 118 1.5 DOCUMENT ORGANIZATION 120 This document contains seven main sections. This section has 121 provided an introduction. Section 2 contains definitions of key 122 terms used in this document. Section 3 further explains 123 certificate policy and CPS related terms and Section 4 provides a 124 list of references and related work. Section 5 provides an 125 overview of the certificate policy and certification practices 126 framework. Section 6 contains the details of the certificate 127 policy and CPS framework. Section 7 provides an outline format 128 for a certificate policy and certification practice statement. 130 2. DEFINITIONS 132 In this section, we define terms used in the development of 133 certificate policy and CPS. These terms are closely related, but 134 have subtle differences. The definitions are intended to clarify 135 those subtle differences. 137 Certificate Policy - A named set of rules that indicates the 138 applicability of a certificate to a particular community and/or 139 class of application with common security requirements. For 140 example, a particular certificate policy might indicate 141 applicability of a type of certificate to the authentication of 142 electronic data interchange transactions for the trading of goods 143 within a given price range. The certificate policy should be used 144 by the user of the certificate to decide whether or not to accept 145 the binding between the subject (of the certificate) and the 146 public key. A subset of the components in the certificate policy 147 and certification practices statement framework are given concrete 148 values to define a certificate policy. The certificate policy is 149 represented by a registered object identifier in the X.509, 150 version 3 certificate. The object owner also registers a textual 151 description of the policy and makes it available to the 152 certificate users. 154 The certificate policy object identifier can be included in the 155 following extensions in the X.509, version 3 certificates: 156 certificate policies, policy mappings, and policy constraints. 157 The object identifier(s) may appear in none, some, or all of these 158 fields. These object identifiers may be the same (referring to 159 the same certificate policy) or may be different (referring to 160 different certificate policies). 162 Element of Policy - A topic that may need to be covered in a 163 certificate policy or in a certification practice statement. 165 Certification Path - A set of certificates that provides a chain 166 of trust from the relying party's trusted CA to the entity whose 167 public key is required by the relying party. 169 Certificate Policy and Certificate Practice Statement (CPS) 170 Framework - A comprehensive set of security and liability related 171 components that can be used to define a certificate policy or a 172 CPS. A subset of the components in the certificate policy and CPS 173 framework are given concrete values to define a certificate policy 174 or a CPS. 176 Certification Practice Statement (CPS) - A statement of the 177 practices which a certification authority employs in issuing 178 certificates. 180 Issuing Certification Authority (CA) - A CA who has elected to 181 apply a policy to itself and its subjects (CA and end entities). 183 Policy Qualifier - Policy-dependent information that accompanies a 184 certificate policy identifier in an X.509 certificate. 186 Registration Authority (RA) - An entity who is responsible for 187 identification and authentication of subjects of certificate, but 188 is not a CA, and hence does not sign or issue certificates. 190 Subject CA - A CA that is certified by the issuing CA and hence 191 complies with the certificate policy of the issuing CA. 193 Subject RA - See Registration Authority (RA). 195 3. CERTIFICATE POLICY AND CPS RELATED CONCEPTS 197 This section contains a detailed explanation of a certificate policy 198 and a certification practice statement. 200 3.1 CERTIFICATE POLICY 202 When a certification authority issues a certificate, it is 203 providing a statement to a certificate user (i.e., a relying 204 party) that a particular public key is bound to a particular 205 entity (the certificate subject). But to what extent can the 206 certificate user rely on that statement by the certification 207 authority? Different certificates are issued following different 208 practices and procedures, and may be suitable for different 209 applications and/or purposes. 211 The term certificate policy derives from the X.509 standard [8]. 212 Certificate policy refers to the way an X.509 certificate 213 indicates to a certificate user whether or not the certificate is 214 suitable for use for a particular application. A certificate 215 policy needs to be recognized by both the issuer and user of the 216 certificate. Any individual certificate will typically be 217 associated with a single certificate policy or, possibly, be 218 issued consistent with a small number of different policies. 220 The X.509 standard defines a certificate policy as "a named set of 221 rules that indicates the applicability of a certificate to a 222 particular community and/or class of application with common 223 security requirements." 225 A certificate policy is registered and assigned a globally unique 226 ISO/IEC/ITU object identifier (OID). This registration process 227 follows the procedures specified in ISO/IEC/ITU standards. 229 3.2 CERTIFICATE POLICY EXAMPLES 231 An organization can be expected to support a number of different 232 certificate policies. For example, a certain organization might 233 support two different certificate policies. One might govern how 234 certificates are issued for confidentiality (encryption) 235 applications, while the second might deal with how certificates 236 are issued for non-repudiation (digital signature) applications. 238 For the purposes of this example, call this organization ACME 239 research, and call the two policies the ACME Electronic Mail 240 policy, and the ACME Purchase policy. The ACME Electronic Mail 241 policy is used by the ACME employees for protecting routine 242 information (e.g., causal electronic mail) and for authenticating 243 connections from the World Wide Web browsers to the corporate Web 244 servers. The Certified key pairs may be generated, stored, and 245 managed using low-cost software-based systems. Under this policy, 246 a certificate is automatically issued to anybody identified in the 247 corporate directory who submits a signed certificate request form 248 to a network administrator. 250 The ACME Purchase policy is used to protect financial 251 transactions. Under this policy, ACME requires that certified key 252 pairs be generated and stored in approved cryptographic hardware 253 tokens. A certificate and token is provided to employees with 254 disbursement authority. These authorized individual are required 255 to present themselves to a special security office, and show a 256 valid identification badge before a token is issued. 258 3.3 X.509 CERTIFICATE FIELDS RELATING TO CERTIFICATE POLICIES 260 The following extension fields in an X.509 certificate are used to 261 support certificate policies: 263 * Certificate Policies extension 264 * Policy Mappings extension 265 * Policy Constraints extension 267 3.3.1 Certificate Policies Extension 269 The Certificate Policies extension has two variants - one with 270 the field flagged non-critical and one with the field flagged 271 critical. The purpose of the field is slightly different in 272 the two cases. 274 Each Certificate Policy may define one or more purposes for 275 which certificates issued on the policy may be used. A non- 276 critical Certificate Policies field lists certificate policies 277 that the certification authority declares are applicable, 278 however, use of the certificate is not restricted to the 279 purposes indicated by the applicable policies. Using the 280 example of the "Electronic Mail" and the "Purchase" policies 281 defined in Section 3.2 above, the certificates issued to the 282 organization's regular employees will contain the object 283 identifier for certificate policy for the Electronic Mail 284 policy. The certificates issued to the employees with 285 disbursement authority will contain the object identifiers for 286 both the Electronic Mail policy and the Purchase policy. The 287 Certificate Policies field may also optionally convey qualifier 288 values for each identified policy; use of qualifiers is 289 discussed below in Section 3.4. 291 The non-critical Certificate Policies field is designed to be 292 used by applications as follows. Each application is pre- 293 configured to know what policy it requires. Using the example 294 in Section 3.2, electronic mail applications and Web servers 295 will be configured to require the Electronic Mail policy. The 296 corporate financial applications will be configured to require 297 the Purchase policy for validating financial transactions. 299 When processing a certification path, a certificate policy that 300 is acceptable to the certificate-using application must be 301 present in every certificate in the path, i.e., in 302 certification authority certificates as well as end entity 303 certificates. 305 If the certificate policies field is flagged critical, it 306 serves the same purpose as described above but also has an 307 additional role. It indicates that the use of the certificate 308 is restricted to one of the identified policies, i.e., the 309 certification authority is declaring that the certificate must 310 not be used for any purpose other than those identified by the 311 certificate policies. This field is intended, first and 312 foremost, to protect the certification authority against damage 313 claims by some party who has used the certificate for a purpose 314 not defined in the applicable policies. 316 For example, the government might issue certificates to 317 taxpayers for the purpose of protecting tax filings. The 318 government understands and can accommodate the risks of 319 accidentally issuing a bad certificate, e.g., to a wrongly- 320 authenticated person. However, suppose someone used a 321 government tax-filing certificate as the basis for encrypting 322 multi-million-dollar-value proprietary secrets which 323 subsequently fell into the wrong hands because of an error in 324 issuing the government certificate. Would it not be possible 325 for the damaged party to sue the government for issuing a bad 326 certificate? It is this type of situation that the critical- 327 flagged Certificate Policies extension is intended to avert. 328 To provide protection against this type of situation, the 329 extension field should always be set critical in a certificate, 330 i.e., any application using the certificate must use the 331 certificate only for the purpose(s) defined by the policies in 332 the field. 334 3.3.2 Policy Mapping Extension 336 The next policy related extension field is the Policy Mappings 337 extension. This extension may only be used in CA- 338 certificates, i.e., certificates for certification authorities 339 issued by other certification authorities. This field allows a 340 certification authority to indicate that certain policies in 341 its own domain can be considered equivalent to certain other 342 policies in the subject certification authority's domain. 344 For example, suppose the ACE Corporation establishes an 345 agreement with the ABC Corporation to cross-certify each 346 others' public-key infrastructures for the purposes of mutually 347 protecting electronic data interchange. Further, suppose that 348 both companies have pre-existing financial transaction 349 protection policies called ace-e-commerce and abc-e-commerce, 350 respectively. One can see that simply generating cross 351 certificates between the two domains will not provide the 352 necessary interoperability, as the two companies' applications 353 are configured and employee certificates are populated with 354 their respective certificate policies. One possible solution 355 is to reconfigure all of the financial applications to require 356 either policy and to reissue all the certificates with both 357 policies. Another solution, which is much easier to 358 administer, uses the Policy Mapping field. If this field is 359 included in a cross- certificate for the ABC Corporation 360 certification authority issued by the ACE Corporation 361 certification authority, it can provide a statement that the 362 ABC's financial transaction protection policy (i.e., abc-e- 363 commerce) can be considered equivalent to that of the ACE 364 Corporation (i.e., ace-e- commerce). 366 3.3.3 Policy Constraints Extension 368 The Policy Constraints extension supports two optional 369 features. The first is the ability for a certification 370 authority to require explicit certificate policy to be present 371 in all subsequent certificates in a certification path. 372 Certificates at the start of a certification path may be 373 considered by a certificate user to be part of a trusted 374 domain, i.e., certification authorities are trusted for all 375 purposes so no particular certificate policy is needed in the 376 Certificate Policies extension. Whenever a certification 377 authority in the trusted domain certifies outside the domain, 378 it should activate the requirement for explicit policy in 379 subsequent certificates. 381 The other optional feature in the Policy Constraints field is 382 the ability for a certification authority to disable policy 383 mapping by subsequent certification authorities in a 384 certification path. Unless special requirements arise, it 385 would be prudent to always disable policy mapping when 386 certifying outside the domain. This will eliminate the 387 increase in security risk due to transitive trust. i.e., a 388 domain A trusts domain B, domain B trusts domain C, and hence 389 domain A trusts domain C even though domain A does not wish to 390 trust any other domain except domain B. 392 3.4 POLICY QUALIFIERS 394 The Certificate Policies extension field has a provision for 395 conveying, along with each certificate policy identifier, 396 additional policy-dependent information in a qualifier field. The 397 X.509 standard does not mandate the purpose for which this field 398 is to be used, nor does it prescribe the syntax for this field. 399 Policy qualifier types can be registered by any organization. 401 In practice, policy qualifiers will not be particularly useful 402 unless agreement is reached, outside the standard, on the purposes 403 for which they will be used and on the syntax for representing 404 them. A collection of common qualifier types will likely emerge. 406 Some important purposes currently envisaged for qualifiers are: 408 a. for providing a solid link back to a location from which a 409 copy of the full certification practice statement (see next 410 section) can be retrieved; the qualifier will convey a World 411 Wide Web URL and a digest field to enable a user to check that 412 the document has been retrieved uncorrupted; and 414 b. for conveying textual information comprising appropriate 415 legal text, e.g., disclaimer of limitation of liability, for 416 display to certificate users whenever certificates are used. 418 It is anticipated that the IETF PKIX Working Group will 419 standardize these qualifier types. 421 3.5 CERTIFICATION PRACTICE STATEMENT 423 The term certification practice statement derives from the 424 American Bar Association (ABA) Digital Signature Guidelines [10]. 425 (E1) A certification practice statement is defined to be: 427 A statement of the practices which a certification authority 428 employs in issuing certificates. 430 In the 1995 draft of the ABA guidelines, the ABA expands this 431 definition with the following comments: 433 A certification practice statement may take the form of a 434 declaration by the certification authority of the details of 435 its trustworthy system and the practices it employs in its 436 operations and in support of issuance of a certificate, or it 437 may be a statute or regulation applicable to the certification 438 authority and covering similar subject matter. It may also be 439 part of the contract between the certification authority and 440 the subscriber. A certification practice statement may also be 441 comprised of multiple documents, a combination of public law, 442 private contract, and/or declaration. 444 Certain forms for legally implementing certification practice 445 statements lend themselves to particular relationships. For 446 example, when the legal relationship between a certification 447 authority and subscriber is consensual, a contract would 448 ordinarily be the means of giving effect to a certification 449 practice statement. The certification authority's duties to a 450 relying person are generally based on the certification 451 authority's representations, which may include a certification 452 practice statement. 454 Whether a certification practice statement is binding on a 455 relying person depends on whether the relying person has 456 knowledge or notice of the certification practice statement. A 457 relying person has knowledge or at least notice of the contents 458 of the certificate used by the relying person to verify a 459 digital signature, including documents incorporated into the 460 certificate by reference. It is therefore advisable to 461 incorporate a certification practice statement into a 462 certificate by reference. 464 NOTE: When the legal relationship is regulatory, for 465 example, between a government and its citizens, a statute 466 may be the means of giving effect to a certification 467 practice statement. 469 As much as possible, a certification practice statement should 470 indicate any of the widely recognized standards to which the 471 certification authority's practices conform. Reference to 472 widely recognized standards may indicate concisely the 473 suitability of the certification authority's practices for 474 another person's purposes, as well as the potential 475 technological compatibility of the certificates issued by the 476 certification authority with repositories and other systems. 478 3.6 RELATIONSHIP BETWEEN CERTIFICATE POLICY AND CERTIFICATION 479 PRACTICE STATEMENT 481 The concepts of certificate policy and certification practice 482 statement come from different sources and were developed for 483 different reasons. However, they are interrelated. This section 484 describes the relationship between the two. 486 A certification practice statement is a detailed statement by a 487 certification authority as to its practices, that potentially 488 needs to be understood and consulted by subscribers and 489 certificate users (relying parties). A certificate policy is a 490 mutually understood indicator from certification authority to 491 certificate user as to suitable applications and purposes for a 492 particular certificate. A certification authority with a single 493 certification practice statement may support multiple certificate 494 policies (used by different certificate user communities). Also, 495 multiple different certification authorities, with non-identical 496 certification practice statements, may support the same 497 certificate policy. 499 For example, the Government of Canada might define a government- 500 wide certificate policy for handling confidential human resources 501 information. The certificate policy definition will be a broad 502 statement of the general characteristics of that certificate 503 policy, and an indication of the types of applications for which 504 it is suitable for use. Different departments or agencies that 505 operate certification authorities with different certification 506 practice statements might support this certificate policy. At the 507 same time, such certification authorities may support other 508 certificate policies. 510 In addition to populating the certificate policies field with the 511 certificate policy identifier, a certification authority may 512 include, in certificates it issues, a reference to its 513 certification practice statement. A standard way to do this, 514 using a certificate policy qualifier, is described in Section 3.4. 516 3.7 CA DISCLOSURE RECORD 518 A CA Disclosure Record [9] is a body of textual information, 519 intended to convey information about a particular certification 520 authority that may be of some help to a certificate user in 521 evaluating the suitability of a certificate issued by that 522 certification authority. 524 The following excerpt from the Utah Administrative Code has the 525 following recommendations for the contents of a certification 526 authority disclosure record: 528 1. an indication that the certification authority disclosure 529 record is provided and maintained by this state; 531 2. the name, street address, and voice telephone number of the 532 certification authority; 534 3. the telephone number of the certification authority's 535 facsimile transmission machine, if the certification authority 536 has such a machine; 538 4. the electronic mail or other address by which the 539 certification authority may be contacted electronically; 541 5. the distinguished name of the certification authority; 543 6. the current public key or keys of the certification 544 authority by which its digital signatures on published 545 certificates may be verified; 547 7. the restrictions, if any, placed on the certification 548 authorities license pursuant to section 201(3); 550 8. if the certification authority's license has been revoked 551 or is currently suspended, the data of revocation or suspension 552 and the grounds for revocation or suspension; 554 9. the amount of the certification authority's suitable 555 guaranty; 557 10. the total amount of all claims filed with the division for 558 payment from the suitable guaranty filed by the certification 559 authority; 561 11. a brief description of any limit known to the division and 562 applicable to the certification authority's liability or legal 563 capacity to pay damages in tort or for breach of a duty 564 prescribed in this document; unless the limitation is specified 565 in this document; 567 12. the categorization pursuant to section 202(2) of the 568 certification authority's compliance with this document and 569 resulting from the most recent performance audit of the 570 certification authority's activities, and the data of the most 571 recent performance audit; 573 13. any event which substantially affects the certification 574 authority's ability to conduct its business or the validity of 575 a certificate published in the repository provided by the 576 Division or in a recognized repository; 578 14. if a certificate containing the public key required to 579 verify one or more certificates issued by the certification 580 authority has been revoked or is currently suspended, the date 581 of its revocation or suspension; and 583 15. if the certification authority has a material, primary 584 certification practice statement, indications of its location, 585 the method or procedure by which it may be retrieved, its form 586 and structure, its authorship, and its date, as prescribed in 587 rule 302. 589 4. REFERENCES 591 This document is based on the certificate taxonomy developed by 592 CygnaCom and documented in [1]. References 2 through 7 have been 593 used to refine the framework. 595 1. Technical Specifications for Federal Public Key 596 Infrastructure-Annex D: Interoperability Profiles, (Appendix E), 597 CygnaCom Solutions, Inc., December, 1995. 599 2. Technical Specifications for Federal Public Key 600 Infrastructure-Annex B: Technical Security Policy, National 601 Institutes of Standards and Technology, December, 1995. 603 3. Statement of Work Federal Public Key Infrastructure Pilot, 604 (Appendix A-Technical Specifications), Solicitation No. 605 52SBN5C8535, National Institutes of Standards and Technology, 606 October, 1994. 608 4. Information System Security Policy and Certification Practice 609 Statement, National Security Agency, March 12, 1996. 611 5. Government of Canada PKI - Certificate Policy and 612 Certification Practices Statement Framework, November 12, 1996. 614 6. MISSI Policy Analysis, Booz, Allen and Hamilton, March 1996. 616 7. Recommendation X.509 and ISO 9594-8, Information Processing 617 System - Open Systems Interconnection - The Directory - 618 Authentication Framework, 1988. 620 8. Final Text of Draft Amendment DAM 4 to ISO/IEC 9594-2, DAM 2 621 to ISO/IEC 9594-6, DAM 1 to ISO/IEC 9594-7, and DAM 1 to ISO/IEC 622 9594-8 on Certificate Extensions, June 1996. 624 9. Utah Administrative Code. 626 10. American Bar Association, Digital Signature Guidelines: Legal 627 Infrastructure for Certification Authorities and Electronic 628 Commerce, Draft 1995. 630 11. Baum, Michael S., Federal Certification Authority Liability 631 and Policy, NIST-GCR-94-654, June 1994. 633 12. Certification Practices Statement, Verisign, 1996. 635 13. Privacy Enhanced Mail, Internet RFC 1421-23, 1994 637 5. CERTIFICATE POLICY AND CERTIFICATION PRACTICES FRAMEWORK: OVERVIEW 639 This section provides a brief overview of the certificate policy 640 components. Section 6 provides a complete refinement of the 641 components. Both the certificate policy and the CPS are composed of 642 components described in this section and further refined in Section 643 6. Components can be further divided into subcomponents. 644 Subcomponents can be divided into elements. Elements can be divided 645 into subelements. 647 A certificate policy or CPS consists of the following components: 649 * Community and Applicability 651 * Identification and Authentication Policy 653 * Key Management Policy 655 * Local Security Policy 657 * Technical Security Policy 659 * Operations Policy 661 * Legal Provisions 663 * Certificate and CRL Profile 665 * Policy Administration 667 Each of these components is described below. 669 5.1 COMMUNITY AND APPLICABILITY 671 Under this component, the following are described: 673 * types of subject CA certified (e.g., subordinate banks, peer 674 banks, regional offices, etc.) (2) 676 * types of subject Registration Authority (RA) certified (e.g., 677 regional offices) 679 * types of end entities certified (e.g., employees, 680 contractors, subscribers, customers, etc.) (3) 682 * applications for which the policy is suitable for, is 683 restricted to, or must not be used in conjunction with. 685 5.2 IDENTIFICATION AND AUTHENTICATION (I&A) POLICY 687 This component is used to describe the various I&A policies. The 688 I&A policies are fundamental to ensuring that the bindings between 689 the public keys and the individuals are correct. The I&A policies 690 may be the same or different for the subject CA, subject 691 Registration Authority (RA), and subject end entities. For each 692 class of subject (CA, RA, or end entity), the I&A policy may be 693 different for the various interactions with the parent CA. The 694 interactions include, initial registration, rekey, rekey after 695 revocation, and revocation request. The component also describes 696 if and how the trademarks are recognized (authenticated). The 697 component also describes if and how name disputes are resolved. 699 5.3 KEY MANAGEMENT POLICY 701 This component is used to define the security measures taken by 702 the CA to protect its cryptographic keys and critical security 703 parameters (e.g., Personal Identification Number or PIN). This 704 component may also be used to impose constraints on subject CAs 705 and end entities to protect their cryptographic keys and critical 706 security parameters. For the sake of completeness, for each type 707 of entity (issuer CA, subject CA, RA, and end entity), and for 708 each type of keying material (private key, parameters, public key, 709 and critical security parameters) this element addresses the 710 entire key life-cycle from generation, through storage and usage, 711 to archival and destruction. 713 Secure key management is critical to ensure that all secret and 714 private keys and critical security parameters are protected and 715 used only by authorized personnel. 717 5.4 LOCAL SECURITY POLICY 719 This component is used to define the non-technical security 720 controls used by the CA to perform CA functions securely. The CA 721 functions include key generation, user authentication, certificate 722 registration, certificate revocation, audit, and archival. The 723 non-technical security controls include physical, personnel, and 724 procedural controls. 726 This component is also used to define non-technical security 727 controls on subject CAs, RAs, and end entities. The non technical 728 security controls for the subject CAs, RAs, and end entities could 729 be the same, similar, or quite different. In most cases they are 730 envisioned to be quite different with tighter controls on the 731 subject CAs and RAs due to the sensitivity of the functions they 732 perform. 734 The security controls are critical to trusting the public key 735 certificates since lack of security may compromise CA operations, 736 resulting in creation of certificates or CRLs with erroneous 737 information or even the compromise of the CA private key. 739 5.5 TECHNICAL SECURITY POLICY 741 This component is used to define the technical security controls 742 used by the CA to perform CA functions securely. The CA functions 743 include key generation, user authentication, certificate 744 registration, certificate revocation, audit, and archival. The 745 technical controls include life-cycle security controls (including 746 software development environment security, trusted software 747 development methodology) and operational security controls. 749 This component is also used to define technical security controls 750 on subject CAs, RAs, and end entities. The technical security 751 controls for the subject CAs, RAs, and end entities could be the 752 same, similar, or quite different. In most cases they are 753 envisioned to be quite different with tighter controls on the 754 subject CAs and RAs due to the sensitivity of the roles they 755 perform. 757 The security controls are critical to trusting the public key 758 certificates since lack of security may compromise CA operations, 759 resulting in the creation of certificates or CRLs with erroneous 760 information or even the compromise of the CA private key. 762 5.6 OPERATIONS POLICY 764 This component is used to describe the frequency of routine 765 Certificate Revocation List (CRL) issuance, frequency of special 766 CRL issuance (e.g., key compromise CRL), and frequency for CA key 767 changeover. It also describes how the CA operations are 768 periodically audited by another entity and the CA's relationship 769 with that entity. This component is also used to define who can 770 revoke certificates under what circumstances. 772 This component is used to describe periodic compliance audits the 773 CA performs on the subject CAs, RAs, and end entities. Periodic 774 compliance audit on subject CAs and RAs is recommended to ensure 775 compliance and to maintain trustworthiness of the whole 776 infrastructure. Periodic compliance audit of subject end entities 777 is also desirable, but not as critical as the subject CAs. 779 This component is also used to define the frequency of routine CRL 780 issuance, frequency of special CRL issuance (e.g., key compromise 781 CRL), and frequency for key changeover for the subject CAs. This 782 component is also used to define the typical validity period for 783 subject end entity certificates. These validity periods could be 784 different based on key usage (e.g., signature, key establishment, 785 etc.) 787 This component is also used to describe the CA, subject CAs, 788 subject RAs, and subject end entities archival policies. 790 This component is also used to describe the procedures for 791 recovering from CA and RA failure and compromise. 793 This component is also used to define the confidentiality policy 794 for the information that the CA and RA hold. 796 This component is relevant for certificate policy, since a 797 compliance audit policy increases the overall trustworthiness of 798 the infrastructure entities. The CRL issuance frequency allows 799 the users of the certificate to develop appropriate caching 800 strategies. The key changeover period in conjunction with key 801 size directly relate to the security offered by the cryptosystem. 803 5.7 LEGAL PROVISIONS 805 This component describes the liability policy including 806 disclaimers of warranty and limitations on liability. 808 This component also defines the obligations of the subscribers 809 (subject CA, RA, and end entities) and those of the certificate 810 users (relying parties). 812 It also describes applicable laws and regulations and dispute 813 resolution procedures. 815 5.8 CERTIFICATE AND CRL PROFILE 817 This component is used to define the certificate and CRL versions 818 and extensions supported (populated) by the CA and the criticality 819 of the extensions. This component describes typical values of the 820 following fields within the policy constraints extension: require 821 explicit policy, and inhibit policy mapping. 823 This component is also used to define the certificate and CRL 824 versions and extensions supported (populated) by the subject CAs 825 and the criticality of the extensions. This component describes 826 typical values of the following fields within the policy 827 constraints extension: require explicit policy, and inhibit 828 policy mapping. 830 The certificate profile could be different for different key usage 831 such as signature, key management, certificate signing, CRL 832 signing, etc. 834 5.9 POLICY ADMINISTRATION 836 This component is used to define the authority that is responsible 837 for the registration, maintenance and interpretation of the 838 policy. The information includes the name and address of the 839 organization, and the name and the telephone number of a contact 840 person. 842 This component also describes how the policy change is 843 administered and how various notices are published and 844 distributed. 846 This component also describes how the compliance of a specific CPS 847 with the policy is determined. 849 6. CERTIFICATE POLICY AND CERTIFICATION PRACTICES FRAMEWORK: 850 DESCRIPTION 852 In this section, we provide a complete refinement of the certificate 853 policy and certification practices statement framework. 855 6.1 COMMUNITY AND APPLICABILITY 857 This component consists of the following subcomponents: 859 * Subject CAs 861 * Subject RAs 863 * Subject End Entities 865 * Applicability 866 This component describes the various types of certificate 867 subscribers, and applications and standards. 869 The following sections describe these subcomponents. 871 6.1.1 Subject CAs 873 This subcomponent contains a brief description of the types of 874 entities that are certified as subject CAs. (4) 876 6.1.2 Subject RAs 878 This subcomponent contains a brief description of the types of 879 entities that are certified as subject RAs. (5) 881 6.1.3 Subject End Entities 883 This subcomponent contains a brief description of the types of 884 entities that are certified as end entities. (6) 886 6.1.4 Applicability 888 This subcomponent contains: 890 * A list of applications for which the issued certificates 891 are suitable 893 * A list of applications that the issued certificates are 894 restricted to. (This list implicitly prohibits all other 895 uses for the certificates.) 897 * A list of applications that the issued certificates are 898 prohibited from being used for 900 6.2 IDENTIFICATION AND AUTHENTICATION (I&A) POLICY 902 This component contains the I&A policies for subject CAs, subject 903 RAs, and subject end entities. These policies could be the same 904 or different for each of these entities. 906 * Initial Registration 908 * Routine Rekey 910 * Rekey After Revocation 912 * Revocation Request 914 6.2.1 Initial Registration 916 This subcomponent contains the following: 918 * Identification and authentication policy for each subject 919 type (CA, RA, and end entity) for initial registration 921 * Types of names assigned to the subject (7) 923 * Whether names have to be meaningful or not (8) 925 * Rules for interpreting various name forms 927 * Whether names have to be unique 929 * How name claim disputes are resolved 931 * Whether trademarks are recognized or not 933 * How trademarks are authenticated 935 * What role trademarks play in naming and identification and 936 authentication 938 * If and how the subject must prove that (s)he possesses the 939 companion private key for the public key being registered 940 (9) 942 * Authentication requirements for organizational identity of 943 subject (CA, RA, or end entity) (10) 945 * Authentication requirements for a person acting on behalf 946 of subject (CA, RA, or end entity) (11) 947 * Number of identifications required 949 * How a CA or RA validates the identification cards provided 951 * If the person must present himself to the authenticating 952 CA or RA 954 * How an individual as an organizational person is 955 authenticated (12) 957 6.2.2 Routine Rekey 959 This subcomponent contains the I&A policy for routine rekey for 960 each subject type (CA, RA, and end entity). (13) 962 6.2.3 Rekey After Revocation -- No Key Compromise 964 This subcomponent is used to describe the I&A policy for rekey 965 for each subject type (CA, RA, and end entity) after the 966 subject certificate has been revoked. (14) 968 6.2.4 Revocation Request 970 This subcomponent is used to describe the I&A policy for 971 revocation request by each subject type (CA, RA, and end 972 entity). (16) 974 6.3 KEY MANAGEMENT POLICY 976 This component consists of the key management policies for the 977 following entities: issuing CA, subject CAs, subject RAs, and 978 subject end entities. These four sets of policies could be the 979 same or different. 981 6.3.1 Public and Private Key Pair 983 The key management policies for the issuing CA, subject CAs, 984 Subject RAs, and subject end entities address the entire life- 985 cycle of the public and private key pair from generation 986 through archival and destruction. For each of these types of 987 entities (issuing CA, subject CA, subject RA, subject end 988 entity) the following questions should be answered: 990 6.3.1.1 Key Pair Generation and Installation 992 1. Who generates the entity public, private key pair? 994 2. How is the private key provided securely to the 995 entity? 997 3. How is the entity's public key provided securely to 998 the certificate issuer? 1000 4. If the entity is a CA (issuing or subject) how is the 1001 entity's public key provided securely to the users? 1003 5. What are the key sizes? 1005 6. Who generates the public key parameters? 1007 7. Is the quality of the parameters checked during key 1008 generation? 1010 8. Is the key generation performed in hardware or 1011 software? 1013 9. For what purposes may the key be used (these purposes 1014 should be same as the key usage flags in the Version 3, 1015 X.509 certificates)? 1017 10. For what purposes may the key must be restricted 1018 to(these purposes should be same as the key usage flags 1019 in the Version 3, X.509 certificates and the key usage 1020 field must be marked criical)? 1022 11. What standards, if any, are required for the module 1023 used to generate the keys? For example, are the keys 1024 certified by the infrastructure required to be generated 1025 using modules complaint with the US FIPS 140-1? If yes, 1026 what is the security level of the module? 1028 6.3.1.2 Private Key Protection 1030 1. Is the private key under n out of m multi-person 1031 control?(18) If yes, provide n and m (two person control 1032 is a special case of n out of m, where n = m = 2)? 1034 2. Is the private key escrowed? (19) If so, who is the 1035 escrow agent, what form is the key escrowed in (examples 1036 include plaintext, encrypted, split key), and what are 1037 the security controls on the escrow system? 1039 3. Is the private key backed up? If so, who is the 1040 backup agent, what form is the key backed up in (examples 1041 include plaintext, encrypted, split key), and what are 1042 the security controls on the backup system? 1043 4. Is the private key archived? If so, who is the 1044 archival agent, what form is the key archived in 1045 (examples include plaintext, encrypted, split key), and 1046 what are the security controls on the archival system? 1048 5. Who enters the private key in the cryptographic 1049 module? In what form (i.e., plaintext, encrypted, or 1050 split key)? 1052 6. How is the private key stored in the module (i.e., 1053 plaintext, encrypted, or split key)? 1055 7. Who can activate (use) the private key? What actions 1056 must be performed to activate the private key (e.g., 1057 login, power on, supply PIN, insert token/key, automatic, 1058 etc.)? Once the key is activated, is the key active for 1059 an indefinite period, active for one time, or active for 1060 a defined time period? 1062 8. Who can deactivate the private key and how? Example 1063 of how include, logout, power off, remove token/key, 1064 automatic, time expiration, etc. 1066 9. Who can destroy the private key and how? Examples of 1067 how include token surrender, token destruction, key 1068 overwrite, etc. 1070 6.3.1.3 Other Aspects of Key Pair Management 1072 1. Is the public key archived? If so, who is the 1073 archival agent and what are the security controls on the 1074 archival system? The archival system should provide 1075 integrity controls other than digital signatures since: 1076 the archival period may be greater than the cryptanalysis 1077 period for the key and the archive requires tamper 1078 protection, which is not provided by digital signatures. 1080 2. What are the validity periods for the public and the 1081 private key respectively? 1083 6.3.2 Critical Security Parameters (20) 1085 The key management policies for the issuing CA, subject CAs, 1086 Subject RAs, and subject end entities address the entire life- 1087 cycle of the critical security parameters from generation 1088 through archival and destruction. For each of these types of 1089 entities (issuing CA, subject CA, subject RA, subject end 1090 entity) the following questions should be answered: 1092 6.3.2.1 Critical Security Parameter Generation and 1093 Installation 1095 1. Who generates the initial critical security 1096 parameters? 1098 2. How are the critical security parameters provided 1099 securely to the entity? 1101 3. What are the size requirements on the parameters 1102 (e.g., PIN size, password size, etc.)? 1104 6.3.2.2 Critical Security Parameter Protection 1106 1. Are the parameters stored in a token (e.g., crypto 1107 ignition key)? 1109 2. Are the parameters under n out of m multi-person 1110 control? If yes, provide n and m (two person control is 1111 a special case of n out of m, where n = m = 2). 1113 3. Are the parameters escrowed? If so, who is the escrow 1114 agent, what form are the parameters escrowed in (examples 1115 include plaintext, encrypted, split key), and what are 1116 the security controls on the escrow system? 1118 4. Are the parameters backed up? If so, who is the 1119 backup agent, what form are the parameters backed up in 1120 (examples include plaintext, encrypted, split key), and 1121 what are the security controls on the backup system? 1123 5. Are the parameters archived? If so, who is the 1124 archival agent, what form are the parameters archived in 1125 (examples include plaintext, encrypted, split key), and 1126 what are the security controls on the archival system? 1128 6.3.2.3 Other Aspects of Critical Security Parameters 1130 1. Who enters the parameters in the cryptographic module? 1131 In what form (i.e., plaintext, encrypted, or split key)? 1133 2. How are the parameters used in the module (e.g., for 1134 authentication and private key activation, private key 1135 decryption and activation, etc.)? 1137 3. What is the recommended life for the parameters? 1139 4. Who can change the parameters? 1141 6.4 LOCAL SECURITY POLICY 1143 This component consists of four security policies for the four 1144 types of entities: one for the issuer CA, one for subject CAs, 1145 one for the subject RAs, and one for subject end-entities. The 1146 following sections describe the items required for these four 1147 security policies: 1149 * Physical Controls 1151 * Procedural Controls 1153 * Personnel Controls 1155 6.4.1 Physical Controls 1157 The physical controls on the facility housing the entity 1158 systems are described.(21) 1160 6.4.2 Procedural Controls 1162 The procedural controls for the entity are described. These 1163 controls include the description of various trusted roles and 1164 responsibilities for each of the roles.(22) 1166 For each of these roles, n out m rules should be defined, i.e. 1167 define how many people are required to perform the task. 1168 Identification and authentication requirements for each role 1169 must also be defined. 1171 6.4.3 Personnel Controls 1173 This subcomponent contains the following: 1175 * Background checks and clearance procedures required for 1176 the personnel filling the trusted roles (23) 1178 * Background checks and clearance procedures requirements 1179 for other personnel (24) 1181 * Training requirements and training procedures for each 1182 role 1184 * Any retraining period and retraining procedures for each 1185 role 1187 * Frequency and sequence for job rotation among various 1188 roles 1190 * Sanctions against personnel for unauthorized actions, 1191 unauthorized use of authority, and unauthorized use of 1192 entity systems (25) 1194 * Controls on the contracting personnel for operating the 1195 entity system and facility 1197 - Bonding requirements on contract personnel 1199 - Contractual requirements including indemnification for 1200 damages due to the actions of the contractor personnel 1202 - Audit and monitoring of contractor personnel 1204 - Other controls on contracting personnel 1206 6.5 TECHNICAL SECURITY POLICY 1208 This component consists of four technical security policies for 1209 the four types of entities: one for the issuer CA, one for subject 1210 CAs, one for the subject RAs, and one for subject end- entities. 1211 The following sections describe the items required for these four 1212 technical security policies: 1214 * Computer Security Controls 1216 * Life-Cycle Security Controls 1218 * Network Security Controls 1219 * Cryptographic Module Engineering Controls 1221 * Computer Security Assurance 1223 * Life-Cycle Assurance 1225 * Cryptographic Assurance 1227 6.5.1 Computer Security Controls 1229 This subcomponent is used to describe computer security 1230 controls. Examples of computer security controls are: trusted 1231 computing base concept, discretionary access control, labels, 1232 mandatory access controls, object reuse, audit, identification 1233 and authentication, trusted path, security testing, penetration 1234 testing, etc. 1236 6.5.2 Life Cycle Security Controls 1238 This subcomponent is used to describe system development 1239 controls and security management controls. 1241 System development controls include development environment 1242 security, development personnel security, configuration 1243 management security during product maintenance, software 1244 engineering practices, software development methodology, 1245 modularity, layering, use of Fail-Safe design techniques, use 1246 of Fail-Safe implementation techniques (e.g., defensive 1247 programming) and development facility security. 1249 Security management controls include execution of tools and 1250 procedures to ensure that the operational systems and networks 1251 adhere to configured security. These tools and procedures 1252 include checking the integrity of the security software, 1253 firmware, and hardware to ensure their correct operation. 1255 6.5.3 Network Security Controls 1257 This subcomponent is used to describe network security related 1258 controls for the system. Examples of network security controls 1259 are: firewalls, guards, etc. 1261 6.5.4 Cryptographic Module Engineering Controls (26) 1263 This subcomponent contains the following aspects of the 1264 cryptographic module: identification of the cryptographic 1265 module boundary, input/output, roles and services, finite state 1266 machine, physical security, software security, operating system 1267 security, algorithm compliance, electromagnetic compatibility, 1268 key management, and self tests. 1270 6.5.5 Computer Security Assurance 1272 This subcomponent is used to describe the computer security 1273 rating for the computer system. The rating could be based on 1274 the Trusted System Evaluation Criteria (TCSEC), Canadian 1275 Trusted Products Evaluation Criteria, European Information 1276 Technology Security Evaluation Criteria, or the Common 1277 Criteria. 1279 This subcomponent is also used to describe the evaluation 1280 analysis, testing, profiling, certification, and/or 1281 accreditation related activity undertaken. 1283 6.5.6 Life-Cycle Assurance 1285 This subcomponent is used to describe the life-cycle security 1286 controls rating such as the Trusted Software Development 1287 Methodology (TSDM) level, IV&V, independent life-cycle security 1288 controls audit, and Software Engineering Institute's Capability 1289 Maturity Model (SEI-CMM). 1291 6.5.7 Cryptographic Assurance 1293 This subcomponent is used to describe the cryptographic 1294 module's compliance with applicable standards (e.g., US FIPS 1295 140-1). (27) 1297 6.6 OPERATIONS POLICY 1299 The operations policy is used to describe the operating procedures 1300 for the issuing CA, subject CAs, subject RAs, and subject end 1301 entities. Each operations policy consists of the following 1302 subcomponents: 1304 * revocation policy 1306 * key compromise policy 1308 * audit policy 1309 * archive policy 1311 * key changeover policy 1313 * recovery procedures 1315 * compliance audit 1317 * non-disclosure policy. The subject end entity policy does 1318 not contains the non-disclosure policy subcomponent. 1320 6.6.1 Revocation Policy 1322 This subcomponent contains the following: 1324 * Circumstances under which the entity certificate may be 1325 revoked 1327 * Who can request the revocation of the entity certificate 1329 * Procedures used for certificate revocation request 1331 * Revocation request grace period available to the entity 1333 * Circumstances under which the entity certificate may be 1334 suspended (held) 1336 * Who can request the suspension (hold) of the entity 1337 certificate 1339 * Procedures used for certificate suspension (hold) request 1341 * How long the suspension may last 1343 * CRL issuance frequency by the entity 1345 * Requirements on the entity to check CRLs 1347 * On-line revocation checks available 1349 * Requirements on the entity to perform on-line revocation 1350 checks 1352 * Other forms of revocation advertisements available 1354 * Requirements on the entity to checks other forms of 1355 revocation advertisements 1357 6.6.2 Key Compromise Policy 1359 This subcomponent is used to describe the following: 1361 * Procedures used by the entity to report key compromise 1363 * Key compromise notification grace period available to the 1364 entity 1366 * Key compromise CRL issuance frequency by the entity 1368 * Requirements on the entity to check key compromise CRL 1370 6.6.3 Audit Policy 1372 This subcomponent is used to describe the following: 1374 * Types of events the entity audits (28) 1376 * Frequency with which each event is audited 1378 * Period for which audit logs are kept 1380 * Protection of audit logs 1382 - Who can view the audit log 1384 - Protection against modification of audit log 1386 - Protection against deletion of audit log 1388 * Audit log back up procedures 1390 * Whether the audit collection system is internal or 1391 external to the entity 1393 * Whether the subject who caused an audit event to occur is 1394 notified of the audit action 1396 6.6.4 Archive Policy 1398 This subcomponent is used to describe the following: 1400 * Types of event to be archived (29) 1402 * Retention period for archive 1404 * Protection of archive 1406 - Who can view the archive 1408 - Protection against modification of archive 1410 - Protection against deletion of archive 1412 * Archive back up procedures 1414 * Whether the archive collection system is internal or 1415 external to the entity 1417 * Archive custodian in case of entity termination 1419 * Procedures to obtain and verify archive information 1421 6.6.5 Key Changeover 1423 This subcomponent contains the following: 1425 * Entity public key validity period 1427 * Procedures to provide the new entity public key to the 1428 users 1430 6.6.6 Recovery Procedures 1432 This subcomponent is used to describe the disaster recovery 1433 procedures for the entity. 1435 This subcomponent also contains the recovery procedures used by 1436 the entity under each of the following circumstances: 1438 * The recovery procedures used if the entity computing 1439 resources, software, and/or data are corrupted or suspected 1440 to be corrupted. These procedures describe how a secure 1441 environment is reestablished, which certificates and CRL are 1442 revoked, whether the entity key is revoked, how the new 1443 entity public key is provided to the users, and how the 1444 subjects are recertified. 1446 * The recovery procedures used if the entity public key is 1447 revoked. These procedures describe how a secure environment 1448 is reestablished, how the new entity public key is provided 1449 to the users, and how the subjects are recertified. 1451 * The recovery procedures used if the entity key is 1452 compromised. These procedures describe how a secure 1453 environment is reestablished, how the new entity public key 1454 is provided to the users, and how the subjects are 1455 recertified. 1457 6.6.7 Compliance Audit 1459 This subcomponent contains the following: 1461 * Frequency of compliance audit for the entity 1463 * Identity of the audit entity 1465 * Auditing entity's relationship to the entity being audited 1466 (30) 1468 * List of topics covered under the compliance audit(31) 1470 * Actions taken as a result of a deficiency found during 1471 compliance audit (32) 1473 * Compliance audit results: who are they shared with (e.g., 1474 subject CA, RA, and/or end entities), who provides them 1475 (e.g., entity being audited, or auditor), how are they 1476 provided, i.e., communication mechanism 1478 6.6.8 Non-disclosure Policy 1480 This subcomponent contains the following: 1482 * Information that must be kept confidential by the entity 1484 * Who is entitled to know what in terms of the reasons for 1485 revocation and suspension of the certificates issued by the 1486 entity 1488 * Who is entitled to know what in terms of the reasons for 1489 revocation and suspension requested by the entity 1491 * Information that can be revealed to the law enforcement 1492 personnel 1494 * Information that can be revealed as part of civil 1495 discovery 1497 * List of other mitigating circumstances under which 1498 confidential information may be disclosed 1500 6.7 LEGAL PROVISIONS 1502 The legal provisions include the following subcomponents for each 1503 of the four types of the entities (issuing CA, subject CAs, 1504 subject RAs, and subject end entities): 1506 * Entity Liability Policy 1508 * Entity Obligations 1510 * Certificate User (Relying Party) Obligations 1512 * Financial Responsibility 1514 * Laws and Procedures 1516 * Fees 1518 The subject end entities only contain the following subcomponents: 1519 entity liability policy, entity obligations. 1521 6.7.1 Entity Liability Policy 1523 This subcomponent contains the following: 1525 * Warranties and disclaimers of warranties 1527 * Liabilities and limitations on liabilities 1529 6.7.2 Entity Obligations 1531 This subcomponent contains the following: 1533 * Entity's obligations in terms of accuracy of 1534 representation 1536 * Obligations of the entity to protect the private key 1538 * Purpose for which the entity's private key is constrained 1539 to be used for 1540 * Entity's obligations for notification of issuance of a 1541 certificate to the subscriber who is the subject of the 1542 certificate being issued 1544 * Entity's general obligations for notification of issuance 1545 of a certificate to others than the subject of the 1546 certificate 1548 * Entity's obligations for notification of revocation of a 1549 certificate to the subscriber whose certificate is being 1550 revoked 1552 * Entity's general obligations for notification of 1553 revocation of a certificate to others than the subject whose 1554 certificate is being revoked 1556 * Entity's obligations for notification of suspension of a 1557 certificate to the subscriber whose certificate is being 1558 suspended 1560 * Entity's general obligations for notification of 1561 suspension of a certificate to others than the subject whose 1562 certificate is being suspended 1564 6.7.3 Certificate User (Relying Party) Obligations 1566 This subcomponent contains the following elements: 1568 * Purposes for which a relying party may use the 1569 certificates issued by the entity 1571 * Certificate verification responsibilities of the relying 1572 parties 1574 * Revocation and suspension checking responsibilities of the 1575 relying parties 1577 6.7.4 Financial Responsibility 1579 This subcomponent contains the following elements: 1581 * Indemnification clause for the entity by the certificate 1582 users 1584 * Fiduciary relationship of the entity with subscribers and 1585 entities in the infrastructure 1587 6.7.5 Laws and Procedures 1589 This subcomponent contains the following elements: 1591 * Statement about applicable laws and regulations 1593 * Dispute resolution procedures 1595 6.7.6 Fees 1597 This subcomponent contains the following elements: 1599 * Certificate issuance fee 1601 * Certificate access fee 1603 * Revocation information access fee 1605 * Fee for other services such as the certificate status, 1606 policy information, etc. 1608 * Refund policy for the various services 1610 6.8 CERTIFICATE AND CRL PROFILES 1612 This component is used to define the certificate and CRL versions 1613 and extensions supported (populated) by the issuing CA and the 1614 subject CAs. This component contains the following information: 1616 * Certificate Profile 1618 * CRL Profile 1620 6.8.1 Certificate Profile 1622 This subcomponent has the following information: certificate 1623 version, naming, policy related information. 1625 6.8.1.1 Certificate Version 1627 This subcomponent has the following elements: 1629 * A list of version numbers supported for the certificate 1631 * A list of certificate profiles (e.g., PKIX, Federal 1632 PKI, or ANSI X9.57, etc.) 1634 * Certificate extensions populated and their criticality. 1636 * Signature, key management, and other cryptographic 1637 algorithms object identifiers 1639 6.8.1.2 Naming 1641 This subcomponent has the following elements: 1643 * Name forms used for the CA, RA, and end entity names 1645 * Name constraints used and the name forms used in the 1646 name constraints 1648 6.8.1.3 Policy 1650 This subcomponent has the following elements: 1652 * Applicable policy OID for this policy 1654 * Typical values for the following fields within the 1655 policy constraints extension: require explicit policy and 1656 inhibit policy mapping 1658 * Policy qualifiers syntax, semantics, and their 1659 processing semantics 1661 * Processing semantics for the critical certificate 1662 policy extension 1664 6.8.2 CRL Profile 1666 This subcomponent has the following elements: 1668 * A list of the version numbers supported for CRLs 1670 * CRL and CRL entry extensions populated and their 1671 criticality 1673 6.9 POLICY ADMINISTRATION 1675 This component is used to define the authority that is responsible 1676 for the registration, maintenance, and interpretation of the 1677 policy. 1679 6.9.1 Contact Information 1681 This subcomponent includes the name, mailing address of the 1682 organization, and the name, electronic mail address, telephone 1683 number, and fax number of a contact person. It also describes 1684 who performs the analysis of a CPS to determine its suitability 1685 as an implementation vehicle for the policy. 1687 6.9.2 Policy Definition and Practice Statement Change Procedures 1689 It will occasionally be necessary to change certificate 1690 policies and Certification Practice Statements. Some of these 1691 changes will not change the assurance that a certificate policy 1692 or its implementation provide, and will be judged by the policy 1693 administrator as not changing the acceptability of certificates 1694 asserting the policy for the purposes for which they have been 1695 used. Such changes to security policies and Certification 1696 Practice Statements need not require a change in the policy 1697 Object Identifier (OID). Changes to other policy components 1698 (or their implementations) will change the acceptability of 1699 certificates for specific purposes, and these changes will 1700 require changes to the OID representing the changed policy. 1702 This subcomponent contains the following information: 1704 * a list of policy or CPS components, subcomponents, and 1705 elements that can be changed without notification and 1706 without changes to the policy OID. 1708 * a list of the policy or CPS components, subcomponents, and 1709 elements that may change following a notification period 1710 without changing the policy OID. The procedures to be used 1711 to notify interested parties (relying parties, certification 1712 authorities, etc.) of the policy or CPS changes is 1713 described. The description of notification procedures 1714 includes the notification mechanism, notification period for 1715 comments, mechanism to receive, review and incorporate the 1716 comments, mechanism for final changes to the policy, and the 1717 period before final changes become effective. 1719 * a list of components, subcomponents, and elements changes 1720 to which require a change in the policy object identifier. 1722 6.9.3 Publication and Notification Policies 1724 This subcomponent contains the following elements: 1726 * list of components, subcomponents, and elements that are 1727 not published in the CPS(33) 1729 * descriptions of mechanisms used to distribute the policy, 1730 CPS, certificates, certificate status, and CRLs 1732 * access control on information objects including the 1733 policy, CPS, certificates, certificate status, and CRLs 1735 * notification procedures for the security breaches of CA 1736 and RA 1738 * procedures for termination and for termination 1739 notification of the CA and RA, including the identity of the 1740 custodian of CA and RA archival records 1742 7. CERTIFICATE POLICY AND CPS OUTLINE 1744 This appendix contains a possible outline for a certificate policy or a 1745 CPS. With further development, it is intended to evolve to a standard 1746 template suitable for use by certificate policy or CPS writers. Such a 1747 common format will facilitate: 1749 1. ease in comparing two policies during cross-certification (for the 1750 purpose of equivalency mapping). 1752 2. ease in comparing a CPS with a policy to ensure that the CPS 1753 faithfully implements the policy. 1755 3. ease in comparing two CPS for equivalency. 1757 Following is the proposed outline for a certificate policy or CPS. 1758 Since a certificate policy and a CPS both address the same issues (a CPS 1759 is a detailed description of how a policy is implemented), we expect 1760 that they both should be able to use the same outline. 1762 It is proposed that the upper two levels of this outline form the basis 1763 of a certificate policy or CPS template. Lower level items constitute a 1764 useful checklist for the certificate or CPS writer, but would not form 1765 part of the template. 1767 COMMUNITY AND APPLICABILITY 1769 Types of CAs certified 1770 Types of RAs certified 1772 Types of end entities certified 1774 Applicability 1776 List of suitable applications 1778 List of approved applications 1780 List of prohibited applications 1782 IDENTIFICATION AND AUTHENTICATION (34) 1784 Initial registration 1786 Types of names 1788 Need for names to be meaningful 1790 Rules for interpreting various name forms 1792 Uniqueness of names 1794 Name claim dispute resolution procedure 1796 Recognition, authentication and role of trademarks in I&A 1798 Method to prove possession of private key 1800 Authentication of organization identity 1802 Authentication of individual identity 1804 Number of identifications required 1806 Authentication confirmation procedure 1808 Need to present in person 1810 Routine Rekey 1812 Authentication method 1814 Method to prove possession of private key 1816 Rekey after revocation 1817 Authentication method 1819 Method to prove possession of private key 1821 Revocation Request 1823 Authentication method 1825 KEY MANAGEMENT (34) 1827 Key Pair Generation and Installation 1829 Key pair generating entity 1831 Method for private key delivery to entity 1833 Method for public key delivery to certificate issuer 1835 Method for CA public key delivery to users 1837 Key sizes 1839 Public key parameters generating entity 1841 Parameter quality checking 1843 Hardware/software key generation 1845 Key usage purposes (as per X.509 v3 key usage field) 1847 Key usage restrictions (as per X.509 v3 critical key usage field) 1849 Standards for cryptographic module 1851 Private Key Protection 1853 Private key under (n out of m) multi-person control 1855 Private key escrow 1857 Private key backup 1859 Private key archival 1861 Private key entry into cryptographic module 1863 Storage form of the private key in the module 1864 Method of activating private key 1866 Method of deactivating private key 1868 Method of destroying private key 1870 Other Aspects of Key Pair Management 1872 Public key archival 1874 Usage periods for the public and private keys 1876 Critical Security Parameters Generation and Installation 1878 Critical security parameter generating entity 1880 Method for delivery of critical security parameters 1882 Critical security parameter sizes 1884 Critical Security Parameter Protection 1886 Storage medium for critical security parameters 1888 Critical security parameters under (n out of m) multi-person 1889 control 1891 Critical security parameters escrow 1893 Critical security parameters backup 1895 Critical security parameters archival 1897 Other Aspects of Critical Security Parameters 1899 Critical security parameters entry into cryptographic module 1901 Critical security parameters purpose 1903 Usage periods for critical security parameters 1905 Changes to critical security parameters 1907 LOCAL SECURITY POLICY (34) 1909 Physical controls 1911 Procedural controls 1912 Separation of duties 1914 n out of m rule for each role 1916 I&A requirement for each role 1918 Personnel Controls 1920 Clearance procedures 1922 Training requirements 1924 Retraining period and requirements 1926 Job rotation frequency and sequence 1928 Sanctions for unauthorized use 1930 Contracting personnel 1932 Bonding requirements 1934 Indemnification for damages due to contractor 1936 Audit and monitoring of contractor personnel 1938 Other controls 1940 TECHNICAL SECURITY POLICY (34) 1942 Computer security controls 1944 Trusted Computing Base 1946 Identification and Authentication 1948 Discretionary Access Controls 1950 Labels 1952 Mandatory Access Controls 1954 Object Reuse 1956 Audit 1958 Trusted Path 1959 Security Testing 1961 Penetration Testing 1963 Life cycle technical controls 1965 System development controls 1967 Development environment security 1969 Development personnel security 1971 Configuration management 1973 Development facility physical controls 1975 Software engineering practices 1977 Software development methodology 1979 Modularity 1981 Layering 1983 Fail-Safe Design 1985 Fail-Safe Implementation 1987 Security management controls 1989 Procedures 1991 Tools 1993 Software Integrity 1995 Firmware Integrity 1997 Hardware Integrity 1999 Network security controls 2001 firewalls and guard 2003 firewall and guard policy 2005 firewall and guard security rating 2007 Crypto Engineering Controls 2009 input/output 2011 roles and services 2013 finite state machine 2015 physical security 2017 software security 2019 operating system security 2021 algorithm compliance 2023 electromagnetic compatibility 2025 key management 2027 self tests 2029 Computer Security Assurance 2031 standard 2033 rating organization 2035 accreditation of rating organization 2037 rating 2039 Evaluation analysis 2041 Security testing 2043 System security profiling 2045 System certification and/or accreditation 2047 Life-cycle Security Assurance 2049 TSDM level, rating organization, and accreditation of rating 2050 organization 2052 IV&V 2054 Independent life-cycle security controls audit 2055 SEI CMM level, rating organization, and accreditation of rating 2056 organization 2058 Cryptographic Module Assurance 2060 standard 2062 rating organization 2064 accreditation of rating organization 2066 rating 2068 OPERATIONS POLICY (34) 2069 Revocation 2071 When can entity (CA, RA, or end entity) certificate be revoked 2073 Who can request revocation of entity certificate 2075 Procedure for entity certificate revocation 2077 Revocation request grace period 2079 When can the entity certificate be suspended (put on hold) 2081 Who can request the entity certificate suspension 2083 Procedures for entity certificate suspension request 2085 Length of suspension 2087 CRL issuance frequency by the entity (if applicable) 2089 CRL check requirement on the entity 2091 On-line revocation checks available 2093 Requirements on the entity to perform on-line revocation checks 2095 Other forms of revocation advertisements available 2097 Requirements on the entity to check other forms of revocation 2098 advertisements 2100 Key compromise 2102 Procedure used by the entity to report key compromise 2103 Key compromise notification grace period 2105 Key compromise CRL issuance by the entity (if applicable) 2107 Requirement on the entity to check key compromise CRL 2109 Audit policy 2111 Types of event to be audited 2113 Frequency with which each event is audited 2115 Retention period for audit log 2117 Protection of audit log 2119 Who can view the audit log 2121 Protection against modification of audit log 2123 Protection against deletion of audit log 2125 Audit log back up procedures 2127 Audit collection system (internal or external to the entity) 2129 Notification to audit causing subject 2131 Archive policy 2133 Types of event to be archived 2135 Retention period for archive 2137 Protection of archive 2139 Who can view the archive 2141 Protection against modification of archive 2143 Protection against deletion of archive 2145 Archive back up procedures 2147 Archive collection system (internal or external to the entity) 2149 Archive custodian in case of entity termination 2150 Procedures to obtain and verify archive information 2152 Key changeover 2154 Public key validity period 2156 Procedures to provide new key to users 2158 Recovery procedures 2160 Disaster recovery procedures 2162 Recovery from entity resources corruption 2164 Recovery from entity public key revocation (no key compromise) 2166 Recovery from entity private key compromise 2168 Compliance audit 2170 Frequency of entity compliance audit 2172 Entity's relationship to the auditor 2174 Topic covered by the audit 2176 Actions taken as a result of deficiency 2178 Entities who are provided the results of compliance audit 2180 Entity who provides the results of compliance audit 2182 Mechanism used to provide results of compliance audit 2184 Non-disclosure policy 2186 Information to be kept confidential by the entity 2188 Disclosure rules (who can be told what) for reasons of 2189 revocation/suspension of certificates 2191 Information that can be revealed to the law enforcement personnel 2193 Information that can be revealed as part of civil discovery 2195 Mitigating circumstances when confidential information may be 2196 disclosed 2198 LEGAL PROVISIONS 2200 Certification Authority 2202 Liability 2204 Warranties and disclaimers of warranties 2206 Liabilities and limitations on liabilities 2208 CA obligations 2210 Accuracy of representations 2212 Protection of issuing CA private key 2214 Restrictions on issuing CA private key use 2216 Notification of issuance of a certificate to the subject of the 2217 certificate 2219 Notification of issuance of a certificate to others 2221 Notification of revocation of a certificate to the subject of 2222 the certificate 2224 Notification of revocation of a certificate to others 2226 Notification of suspension of a certificate to the subject of 2227 the certificate 2229 Notification of suspension of a certificate to others 2231 Certificate user obligations 2233 Use of certificates for appropriate purpose 2235 Certificate verification responsibilities 2237 Revocation/suspension check responsibility 2239 Financial responsibility 2241 Indemnification of issuing CA by certificate users 2243 Fiduciary relationships of the issuing CA 2245 Laws and procedures 2246 Applicable laws and regulations 2248 Dispute resolution procedures 2250 Fees 2252 Certificate issuance fee 2254 Certificate access fee 2256 Revocation information access fee 2258 Fee for other services such as the certificate status, policy 2259 information, etc. 2261 Refund policy for the various services. 2263 Registration Authority 2265 Liability 2267 Warranties and disclaimers of warranties 2269 Liabilities and limitations on liabilities 2271 Subject RA obligations 2273 Accuracy of representations 2275 Protection of RA private key 2277 Restrictions on RA private key use 2279 Certificate user obligations 2281 Use of certificates for appropriate purpose 2283 Certificate verification responsibilities 2285 Revocation/suspension check responsibility 2287 Financial responsibility 2289 Indemnification of RA by certificate users 2291 Fiduciary relationships of RA 2293 Laws and procedures 2294 Applicable laws and regulations 2296 Dispute resolution procedures 2298 Fees 2300 Certificate registration fee 2302 Certificate revocation fee 2304 Fee for other services 2306 Refund policy for the various services. 2308 End entity 2310 Liability 2312 Warranties and disclaimers of warranties 2314 Liabilities and limitations on liabilities 2316 End entity obligations 2318 Accuracy of representations 2320 Protection of end entity private key 2322 Restrictions on end entity private key use 2324 CERTIFICATE AND CRL PROFILES (34) 2326 Certificate Profile 2328 Certificate Version 2330 A list of version numbers supported for the certificate 2332 A list of certificate profiles (e.g., PKIX, Federal PKI, or 2333 ANSI X9.57, etc.) 2335 Certificate extensions populated and their criticality. 2337 Signature, key management, and other cryptographic algorithms 2338 object identifiers 2340 Naming 2341 Name forms used for the CA, RA, and end entity names 2343 Name constraints used and the name forms used in the name 2344 constraints 2346 Policy 2348 Applicable policy OID for this policy 2350 Typical values for the following fields within the policy 2351 constraints extension: require explicit policy and inhibit 2352 policy mapping 2354 Policy qualifiers syntax, semantics, and their processing 2355 semantics 2357 Processing semantics for the critical certificate policy 2358 extension 2360 CRL Profile 2362 A list of the version numbers supported for CRLs 2364 CRL and CRL entry extensions populated and their criticality 2366 POLICY ADMINISTRATION 2368 Contact information 2370 Name and mailing address of the policy administration organization 2372 Name, electronic mail address, telephone number, and fax number of 2373 a contact person 2375 Name and telephone number of person determining CPS suitability 2376 for the policy 2378 Policy definition change procedures 2380 List the items that can change without notification 2382 Items that can change with notification 2384 List of items 2386 Notification mechanism 2388 Comment period 2389 Mechanism to handle comments 2391 Period for final change notice 2393 List of items whose change requires a new policy 2395 Publication and notification policies 2397 List of items not published in the CPS 2399 Mechanisms used to distribute policy, CPS, certificates, 2400 certificate status, and CRLs. 2402 Access control on information objects including the policy, CPS, 2403 certificates, certificate status, and CRLs 2405 Notification procedures for security breaches of issuing CA 2407 Notification procedures for security breaches of subject CA 2409 Notification procedures for security breaches of subject RA 2411 Termination procedure and notification for issuing CA 2413 Termination procedure and notification for subject CA 2415 Termination procedure and notification for subject RA 2417 8. LIST OF ACRONYMS 2419 ABA - American Bar Association 2421 CA - Certification Authority 2422 CC - Common Criteria 2423 CMM - Capability Maturity Model 2424 CPS - Certification Practice Statement 2425 CRL - Certificate Revocation List 2427 DAM - Draft Amendment 2428 DAP - Directory Access Protocol 2430 FIPS - Federal Information Processing Standard 2431 FSDA - Fail Safe Design Analysis 2433 I&A - Identification and Authentication 2434 IEC - International Electrotechnical Commission 2435 IETF - Internet Engineering Task Force 2436 IP - Internet Protocol 2437 ISO - International Organization for Standardization 2438 ITU - International Telecommunications Union 2439 IV&V - Independent Validation and Verification 2441 MSP - Message Security Protocol 2443 NIST - National Institute of Standards and Technology 2445 OID - Object Identifier 2447 PIN - Personal Identification Number 2448 PKCS - Public Key Cryptography Standard 2449 PKI - Public Key Infrastructure 2450 PKIX - Public Key Infrastructure (X.509) (IETF Working Group) 2452 RA - Registration Authority 2453 RFC - Request For Comment 2455 SEI - Software Engineering Institute 2456 S-HTTP - Secure HyperText Transfer Protocol 2457 S/MIME - Secure/Multipurpose Internet Mail Extension 2459 TCP - Transmission Control Protocol 2460 TCSEC - Trusted Computer System Evaluation Criteria 2461 TSDM - Trusted Software Development Methodology 2463 URL - Uniform Resource Locator 2464 US - United States 2466 9. GLOSSARY OF TERMS 2468 Accreditation: A decision by the responsible official of the 2469 organization to operate a system and accept the residual risks 2470 identified by the certification activities, or to accept the risks 2471 even though no certification activities have been done or completed. 2473 (System) Certification: A series of security engineering activities 2474 to ensure that the security requirements for a system are implemented 2475 correctly, and to identify residual risks. The certification 2476 activities typically consist of security analysis of the system 2477 architecture, design, and implementation and security testing of the 2478 system. 2480 End Entity: A person or a computer system who is not a CA or RA. 2482 Entity: A CA, RA, or end entity. 2484 Relying Party: Someone who uses a public key in a certificate to 2485 either verify a digital signature or to encrypt keys or data. 2487 Critical Security Parameters: security-related information (e.g., 2488 cryptographic keys, authentication data such as passwords and 2489 personal identification number (PIN)) 2491 Subject: An entity whose public key is certified in a public key 2492 certificate. 2494 Subject End Entity: An end entity who is the subject of a 2495 certificate. 2497 Subscriber: See subject 2499 User: See relying party 2501 10. ENDNOTES 2503 1 Extracts of the ABA Digital Signature Guidelines presented in this 2504 report are taken from the 1995 draft version which was publicly 2505 released for review and comment. Later work revising the document 2506 has not been publicly released, but does not materially impact the 2507 correctness of this report. 2509 2 Example: A bank claims that it issues CA certificates to its 2510 branches only. Now, the user of a CA certificate issued by the bank 2511 can assume that the subject CA in the certificate is a branch of the 2512 bank. 2514 3 Example: A Government CA claims that it issues certificates to 2515 Government employees only. Now, the user of a certificate issued by 2516 the Government CA can assume that the subject of the certificate is a 2517 Government employee. 2519 4 Examples of the types of subject CA entities are a subordinate 2520 organizations (e.g., branch, division, etc.), a US Federal Government 2521 agency, a Government of Canada agency, a state agency, a provincial 2522 department, etc. 2524 5 Examples of the types of subject RA entities are branch and 2525 division of an organization. 2527 6 Examples of types of subject end entities are uniformed and 2528 civilian DoD personnel, DoD contractors, Ministry of Defense 2529 employees, bank customers, telephone company subscribers, etc. 2531 7 Examples include X.500 distinguished names, RFC 822 Internet names, 2532 URL, etc. 2534 8 The term meaningful means that the name form has commonly 2535 understood semantics to determine identity of the person and/or 2536 organization. The directory names and RFC 822 names are examples of 2537 meaningful names. 2539 9 Examples of proof include the issuing CA generating the key, or 2540 requiring the subject to send an electronically signed request or to 2541 sign a challenge. 2543 10 Examples of organization identity authentication are: articles of 2544 incorporation, duly signed corporate resolutions, company seal, and 2545 notarized documents. 2547 11 Examples of individual identity authentication are: biometrics 2548 (thumb print, ten finger print, face, palm, and retina scan), 2549 driver's license, passport, credit card, company badge, and 2550 government badge. 2552 12 Examples include duly signed authorization papers, corporate 2553 badge, etc. 2555 13 The identification policy for routine rekey should be the same as 2556 the one for initial registration since the same subject needs 2557 rekeying. The rekey authentication may be accomplished using the 2558 techniques for initial I&A or using digitally signed requests. 2560 14 This I&A policy could be the same as the one for initial 2561 registration. 2563 15 This policy could be the same as the one for initial registration. 2565 16 The identification policy for Revocation request could be the same 2566 as the one for initial registration since the same subject 2567 certificate needs to be revoked. The authentication policy could 2568 accept a Revocation request digitally signed by subject. The 2569 authentication information used during initial registration could be 2570 acceptable for Revocation request. Other less stringent 2571 authentication policy could be defined. 2573 17 The identification policy for key compromise notification could be 2574 the same as the one for initial registration since the same subject 2575 certificate needs to be revoked. The authentication policy could 2576 accept a Revocation request digitally signed by subject. The 2577 authentication information used during initial registration could be 2578 acceptable for key compromise notification. Other less stringent 2579 authentication policy could be defined. 2581 18 The n out of m rule allows a key to be split in m parts. The m 2582 parts may be given to m different individuals. Any n parts out of 2583 the m parts may be used to fully reconstitute the key, but having any 2584 n-1 parts provides one with no information about the key. 2586 19 A key may be escrowed, backed up or archived. Each of these 2587 functions have different purpose. Thus, a key may go through any 2588 subset of these functions depending on the requirements. The purpose 2589 of escrow is to allow a third party (such as an organization or 2590 government) to legally obtain the key without the cooperation of the 2591 subject. The purpose of back up is to allow the subject to 2592 reconstitute the key in case of the destruction of the key. The 2593 purpose of archive is to provide for reuse of the key in future, 2594 e.g., use the private key to decrypt a document. 2596 20 The critical security parameters are the information other than 2597 the public and private key pair and public key parameters required to 2598 operate the module. An example of a critical security parameters is 2599 a PIN or passphrase. The public key parameters are NOT an example of 2600 critical security parameters. 2602 21 Examples of physical controls are: monitored facility, guarded 2603 facility, locked facility, access controlled using tokens, access 2604 controlled using biometrics, access controlled through an access 2605 list, etc. 2607 22 Examples of the roles include, system administrator, system 2608 security officer, system auditor, and crypto officer. The duties of 2609 the system administrator are to configure, generate, boot, and 2610 operate the system. The duties of the system security officer are to 2611 assign accounts and privileges. The duties of the system auditor are 2612 to set up system audit profile, perform audit file management, and 2613 audit review. The duties of the crypto officer are to hold, manage, 2614 and protect the CA keys and PINs, and to use them to operate the 2615 cryptographic devices used by the CA to sign the certificates and the 2616 CRLs. 2618 23 The background checks may include clearance level (e.g., none, 2619 sensitive, confidential, secret, top secret, etc.) and the clearance 2620 granting authority name. In lieu of or in addition to a defined 2621 clearance, the background checks may include types of background 2622 information (e.g., name, place of birth, date of birth, home address, 2623 previous residences, previous employment, and any other information 2624 that may help determine trustworthiness). The description should 2625 also include which information was verified and how. 2627 24 For example, the certificate policy may impose personnel security 2628 requirements on the network system administrator responsible for a 2629 CA's network access. 2631 25 Each authorized person should be accountable for his/her actions. 2633 26 A cryptographic module is hardware, software, or firmware or any 2634 combination of them. 2636 27 The compliance description should be specific and detailed. For 2637 example, for each FIPS 140-1 requirement, describe the level and 2638 whether the level has been certified by an accredited laboratory. 2640 28 Example of audit events are: request to create a certificate, 2641 request to revoke a certificate, key compromise notification, 2642 creation of a certificate, revocation of a certificate, issuance of a 2643 certificate, issuance of a CRL, issuance of key compromise CRL, 2644 establishment of trusted roles on the CA, actions of truste 2645 personnel, changes to CA keys, etc. 2647 29 Example of archive events are: request to create a certificate, 2648 request to revoke a certificate, key compromise notification, 2649 creation of a certificate, revocation of a certificate, issuance of a 2650 certificate, issuance of a CRL, issuance of key compromise CRL, and 2651 changes to CA keys. 2653 30 a parent CA is an example of audit relationship. 2655 31 Example of compliance audit topics: sample check on the various 2656 I&A policies, comprehensive checks on key management policies, 2657 comprehensive checks on system security controls, comprehensive 2658 checks on operations policy, and comprehensive checks on certificate 2659 profiles, 2661 32 The examples include, temporary suspension of operations until 2662 deficiencies are corrected, revocation of entity certificate, change 2663 in personnel, invocation of liability policy, more frequent 2664 compliance audit, etc. 2666 33 An organization may choose not to make public some of its security 2667 controls, clearance procedures, or some others elements due to their 2668 sensitivity. 2670 34 All or some of the following items may be different for the 2671 various types of entities, i.e., CA, RA, and end entities. 2673 11. Security Considerations 2675 This entire memo deals with security related to public key certificates. 2677 12. Acknowledgments 2679 We would like to thank Dave Fillingham and Jim Brandt for their 2680 inspiration, numerous valuable suggestions and inputs. We would also 2681 like to thank Edmond Van Hees for his support and inputs. We would 2682 also like to thank the Government of Canada's Policy Management 2683 Authority (PMA) Committee for their contribution and support of this 2684 work. 2686 This document has been developed under the guidance of the 2687 International Policy Framework Working Group. The members of this 2688 working group are: Richard Bloom, US Federal Security Infrastructure 2689 Program Management Office; Santosh Chokhani (Co-Author), CygnaCom 2690 Solutions, Inc.; David W. Fillingham, National Security Agency; 2691 Warwick Ford (Co-Author); Richard Kemp, US Federal Security 2692 Infrastructure Program Management Office; Noel Nazario, National 2693 Institute of Standards and Technology; David Simonetti, Booz, Allen 2694 and Hamilton; and Edmond Van Hees, Communication Security 2695 Establishment, Government of Canada. 2697 We would also like the following industry members for their review 2698 and input: Teresa Acevedo, A&N Associates; Michael Baum, Verisign; 2699 Patrick Cain, BBN; Michael Harrop, Government of Canada Treasury 2700 Board; John Morris, CygnaCom Solutions, Inc.; Tim Moses, Nortel; John 2701 Nicolletos, A&N Associates; Jean Petty, CygnaCom Solutions, Inc.; and 2702 Darryl Stal, Nortel. 2704 Johnny Hsiung and Chris Miller assisted in the preparation of the 2705 manuscript. 2707 13. Author's Address 2709 Questions about this document can be directed to the authors: 2711 Santosh Chokhani 2712 CygnaCom Solutions, Inc. 2713 Suite 100 West 2714 7927 Jones Branch Drive 2715 McLean, VA 22102 2717 Phone: (703) 848-0883 2718 Fax: (703) 848-0960 2719 EMail: chokhani@cygnacom.com 2721 Warwick Ford 2722 VeriSign, Inc. 2724 Phone: (613) 225-3487 2725 Fax: (613) 225-6361 2726 Email: wford@verisign.com 2728 expires in six months June 1997