PKIX Working Group S. Chokhani (CygnaCom Solutions, Inc.) Internet Draft W. Ford (VeriSign, Inc.) expires in six months June 1997 Certificate Policy and Certification Practice Statement Framework Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of 6 months and may be updated, replaced, or may become obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as work in progress. To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za(Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document presents an initial draft of a framework to assist the writers of X.509 certificate policies or certification practice statements for certification authorities and public key infrastructures. In particular, the framework identifies a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in an X.509 certificate policy or a certification practice statement. 1. INTRODUCTION 1.1 BACKGROUND An X.509 public key certificate (henceforth termed a certificate) binds an entity to the entity's public key. The degree to which a certificate user (a certificate user is typically a signature verifier or a key token generator) can trust this binding depends on several factors. These factors include the Certification Authority (CA) policy and procedures for authentication of end entities, CA operating policy, procedures and security controls, Chokhani [Page 1] Internet-Draft CPF and CPSF January 1997 end entity policy and procedures for handling private keys, etc. The liability assumed by certificate issuers and end entities also plays a role in the degree of trust. Version 3 X.509 certificates may contain certificate policies [8]. A certificate policy allows the users of a certificate to decide how much trust to place in the certificate, i.e., in the binding of the entity's identity and the entity's public key. According to X.509, version 3, a certificate policy is "a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements." A detailed description of how certificate policies are implemented by a particular CA is called a Certification Practice Statement (CPS). According to the American Bar Association (ABA), "a CPS is a statement of the practices which a certification authority employs in issuing certificates." When negotiating a cross certification, CAs examine and compare each other's CPS. 1.2 PURPOSE The purpose of this document is to present a framework that identifies the elements that may need to be considered in formulating a certificate policy or a CPS, to assist the writers of certificate policies or CPSs with their task. The purpose is not to define particular certificate policies or CPSs per se. 1.3 SCOPE There are many classes of policies, such as organization security policy, system security policy, data labeling policy, etc. The scope of this document is limited to defining the aspects and elements of a certificate policy (as described and intended in the X.509, version 3 certificate standard and ABA digital signature guidelines). While the certificate policy and certification practices statement framework presented here was motivated by the X.509 version 3 certificate standard, the framework can be used by other public key certificate standards. This document does not define a specific certificate policy or CPS. Instead, it describes what types of information should be included in a certificate policy (and documented in a CPS). This document does not provide specific values or specific mechanisms to choose those values. Specific security policy and the mechanisms that implement them are the scope of a detailed document, a CPS. Chokhani [Page 2] Internet-Draft CPF and CPSF January 1997 This document's scope is limited to provide a comprehensive framework. It does not contain any guidance on how to write sound certificate policies or CPS. This certificate policy and CPS framework contains many topics. It is not necessary for a policy or a CPS to define something concrete for each topic. A tangible statement, "none", and "not applicable" are all acceptable values. Addressing each and every topic ensures that the policy and CPS writers have not omitted anything. Addressing each and every topic in the defined sequence also facilitates comparison of policies and certification practice statements for the purpose of equivalency mapping (as described in Section 3). 1.4 AUDIENCE The audience for this document are the designers and policy- makers of certificate infrastructures using version 3 X.509 certificates. 1.5 DOCUMENT ORGANIZATION This document contains seven main sections. This section has provided an introduction. Section 2 contains definitions of key terms used in this document. Section 3 further explains certificate policy and CPS related terms and Section 4 provides a list of references and related work. Section 5 provides an overview of the certificate policy and certification practices framework. Section 6 contains the details of the certificate policy and CPS framework. Section 7 provides an outline format for a certificate policy and certification practice statement. 2. DEFINITIONS In this section, we define terms used in the development of certificate policy and CPS. These terms are closely related, but have subtle differences. The definitions are intended to clarify those subtle differences. Certificate Policy - A named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements. For example, a particular certificate policy might indicate applicability of a type of certificate to the authentication of electronic data interchange transactions for the trading of goods within a given price range. The certificate policy should be used by the user of the certificate to decide whether or not to accept the binding between the subject (of the certificate) and the Chokhani [Page 3] Internet-Draft CPF and CPSF January 1997 public key. A subset of the components in the certificate policy and certification practices statement framework are given concrete values to define a certificate policy. The certificate policy is represented by a registered object identifier in the X.509, version 3 certificate. The object owner also registers a textual description of the policy and makes it available to the certificate users. The certificate policy object identifier can be included in the following extensions in the X.509, version 3 certificates: certificate policies, policy mappings, and policy constraints. The object identifier(s) may appear in none, some, or all of these fields. These object identifiers may be the same (referring to the same certificate policy) or may be different (referring to different certificate policies). Element of Policy - A topic that may need to be covered in a certificate policy or in a certification practice statement. Certification Path - A set of certificates that provides a chain of trust from the relying party's trusted CA to the entity whose public key is required by the relying party. Certificate Policy and Certificate Practice Statement (CPS) Framework - A comprehensive set of security and liability related components that can be used to define a certificate policy or a CPS. A subset of the components in the certificate policy and CPS framework are given concrete values to define a certificate policy or a CPS. Certification Practice Statement (CPS) - A statement of the practices which a certification authority employs in issuing certificates. Issuing Certification Authority (CA) - A CA who has elected to apply a policy to itself and its subjects (CA and end entities). Policy Qualifier - Policy-dependent information that accompanies a certificate policy identifier in an X.509 certificate. Registration Authority (RA) - An entity who is responsible for identification and authentication of subjects of certificate, but is not a CA, and hence does not sign or issue certificates. Subject CA - A CA that is certified by the issuing CA and hence complies with the certificate policy of the issuing CA. Subject RA - See Registration Authority (RA). Chokhani [Page 4] Internet-Draft CPF and CPSF January 1997 3. CERTIFICATE POLICY AND CPS RELATED CONCEPTS This section contains a detailed explanation of a certificate policy and a certification practice statement. 3.1 CERTIFICATE POLICY When a certification authority issues a certificate, it is providing a statement to a certificate user (i.e., a relying party) that a particular public key is bound to a particular entity (the certificate subject). But to what extent can the certificate user rely on that statement by the certification authority? Different certificates are issued following different practices and procedures, and may be suitable for different applications and/or purposes. The term certificate policy derives from the X.509 standard [8]. Certificate policy refers to the way an X.509 certificate indicates to a certificate user whether or not the certificate is suitable for use for a particular application. A certificate policy needs to be recognized by both the issuer and user of the certificate. Any individual certificate will typically be associated with a single certificate policy or, possibly, be issued consistent with a small number of different policies. The X.509 standard defines a certificate policy as "a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements." A certificate policy is registered and assigned a globally unique ISO/IEC/ITU object identifier (OID). This registration process follows the procedures specified in ISO/IEC/ITU standards. 3.2 CERTIFICATE POLICY EXAMPLES An organization can be expected to support a number of different certificate policies. For example, a certain organization might support two different certificate policies. One might govern how certificates are issued for confidentiality (encryption) applications, while the second might deal with how certificates are issued for non-repudiation (digital signature) applications. For the purposes of this example, call this organization ACME research, and call the two policies the ACME Electronic Mail policy, and the ACME Purchase policy. The ACME Electronic Mail policy is used by the ACME employees for protecting routine information (e.g., causal electronic mail) and for authenticating Chokhani [Page 5] Internet-Draft CPF and CPSF January 1997 connections from the World Wide Web browsers to the corporate Web servers. The Certified key pairs may be generated, stored, and managed using low-cost software-based systems. Under this policy, a certificate is automatically issued to anybody identified in the corporate directory who submits a signed certificate request form to a network administrator. The ACME Purchase policy is used to protect financial transactions. Under this policy, ACME requires that certified key pairs be generated and stored in approved cryptographic hardware tokens. A certificate and token is provided to employees with disbursement authority. These authorized individual are required to present themselves to a special security office, and show a valid identification badge before a token is issued. 3.3 X.509 CERTIFICATE FIELDS RELATING TO CERTIFICATE POLICIES The following extension fields in an X.509 certificate are used to support certificate policies: * Certificate Policies extension * Policy Mappings extension * Policy Constraints extension 3.3.1 Certificate Policies Extension The Certificate Policies extension has two variants - one with the field flagged non-critical and one with the field flagged critical. The purpose of the field is slightly different in the two cases. Each Certificate Policy may define one or more purposes for which certificates issued on the policy may be used. A non- critical Certificate Policies field lists certificate policies that the certification authority declares are applicable, however, use of the certificate is not restricted to the purposes indicated by the applicable policies. Using the example of the "Electronic Mail" and the "Purchase" policies defined in Section 3.2 above, the certificates issued to the organization's regular employees will contain the object identifier for certificate policy for the Electronic Mail policy. The certificates issued to the employees with disbursement authority will contain the object identifiers for both the Electronic Mail policy and the Purchase policy. The Certificate Policies field may also optionally convey qualifier values for each identified policy; use of qualifiers is discussed below in Section 3.4. Chokhani [Page 6] Internet-Draft CPF and CPSF January 1997 The non-critical Certificate Policies field is designed to be used by applications as follows. Each application is pre- configured to know what policy it requires. Using the example in Section 3.2, electronic mail applications and Web servers will be configured to require the Electronic Mail policy. The corporate financial applications will be configured to require the Purchase policy for validating financial transactions. When processing a certification path, a certificate policy that is acceptable to the certificate-using application must be present in every certificate in the path, i.e., in certification authority certificates as well as end entity certificates. If the certificate policies field is flagged critical, it serves the same purpose as described above but also has an additional role. It indicates that the use of the certificate is restricted to one of the identified policies, i.e., the certification authority is declaring that the certificate must not be used for any purpose other than those identified by the certificate policies. This field is intended, first and foremost, to protect the certification authority against damage claims by some party who has used the certificate for a purpose not defined in the applicable policies. For example, the government might issue certificates to taxpayers for the purpose of protecting tax filings. The government understands and can accommodate the risks of accidentally issuing a bad certificate, e.g., to a wrongly- authenticated person. However, suppose someone used a government tax-filing certificate as the basis for encrypting multi-million-dollar-value proprietary secrets which subsequently fell into the wrong hands because of an error in issuing the government certificate. Would it not be possible for the damaged party to sue the government for issuing a bad certificate? It is this type of situation that the critical- flagged Certificate Policies extension is intended to avert. To provide protection against this type of situation, the extension field should always be set critical in a certificate, i.e., any application using the certificate must use the certificate only for the purpose(s) defined by the policies in the field. Chokhani [Page 7] Internet-Draft CPF and CPSF January 1997 3.3.2 Policy Mapping Extension The next policy related extension field is the Policy Mappings extension. This extension may only be used in CA- certificates, i.e., certificates for certification authorities issued by other certification authorities. This field allows a certification authority to indicate that certain policies in its own domain can be considered equivalent to certain other policies in the subject certification authority's domain. For example, suppose the ACE Corporation establishes an agreement with the ABC Corporation to cross-certify each others' public-key infrastructures for the purposes of mutually protecting electronic data interchange. Further, suppose that both companies have pre-existing financial transaction protection policies called ace-e-commerce and abc-e-commerce, respectively. One can see that simply generating cross certificates between the two domains will not provide the necessary interoperability, as the two companies' applications are configured and employee certificates are populated with their respective certificate policies. One possible solution is to reconfigure all of the financial applications to require either policy and to reissue all the certificates with both policies. Another solution, which is much easier to administer, uses the Policy Mapping field. If this field is included in a cross- certificate for the ABC Corporation certification authority issued by the ACE Corporation certification authority, it can provide a statement that the ABC's financial transaction protection policy (i.e., abc-e- commerce) can be considered equivalent to that of the ACE Corporation (i.e., ace-e- commerce). 3.3.3 Policy Constraints Extension The Policy Constraints extension supports two optional features. The first is the ability for a certification authority to require explicit certificate policy to be present in all subsequent certificates in a certification path. Certificates at the start of a certification path may be considered by a certificate user to be part of a trusted domain, i.e., certification authorities are trusted for all purposes so no particular certificate policy is needed in the Certificate Policies extension. Whenever a certification authority in the trusted domain certifies outside the domain, it should activate the requirement for explicit policy in subsequent certificates. The other optional feature in the Policy Constraints field is Chokhani [Page 8] Internet-Draft CPF and CPSF January 1997 the ability for a certification authority to disable policy mapping by subsequent certification authorities in a certification path. Unless special requirements arise, it would be prudent to always disable policy mapping when certifying outside the domain. This will eliminate the increase in security risk due to transitive trust. i.e., a domain A trusts domain B, domain B trusts domain C, and hence domain A trusts domain C even though domain A does not wish to trust any other domain except domain B. 3.4 POLICY QUALIFIERS The Certificate Policies extension field has a provision for conveying, along with each certificate policy identifier, additional policy-dependent information in a qualifier field. The X.509 standard does not mandate the purpose for which this field is to be used, nor does it prescribe the syntax for this field. Policy qualifier types can be registered by any organization. In practice, policy qualifiers will not be particularly useful unless agreement is reached, outside the standard, on the purposes for which they will be used and on the syntax for representing them. A collection of common qualifier types will likely emerge. Some important purposes currently envisaged for qualifiers are: a. for providing a solid link back to a location from which a copy of the full certification practice statement (see next section) can be retrieved; the qualifier will convey a World Wide Web URL and a digest field to enable a user to check that the document has been retrieved uncorrupted; and b. for conveying textual information comprising appropriate legal text, e.g., disclaimer of limitation of liability, for display to certificate users whenever certificates are used. It is anticipated that the IETF PKIX Working Group will standardize these qualifier types. 3.5 CERTIFICATION PRACTICE STATEMENT The term certification practice statement derives from the American Bar Association (ABA) Digital Signature Guidelines [10]. (E1) A certification practice statement is defined to be: A statement of the practices which a certification authority employs in issuing certificates. Chokhani [Page 9] Internet-Draft CPF and CPSF January 1997 In the 1995 draft of the ABA guidelines, the ABA expands this definition with the following comments: A certification practice statement may take the form of a declaration by the certification authority of the details of its trustworthy system and the practices it employs in its operations and in support of issuance of a certificate, or it may be a statute or regulation applicable to the certification authority and covering similar subject matter. It may also be part of the contract between the certification authority and the subscriber. A certification practice statement may also be comprised of multiple documents, a combination of public law, private contract, and/or declaration. Certain forms for legally implementing certification practice statements lend themselves to particular relationships. For example, when the legal relationship between a certification authority and subscriber is consensual, a contract would ordinarily be the means of giving effect to a certification practice statement. The certification authority's duties to a relying person are generally based on the certification authority's representations, which may include a certification practice statement. Whether a certification practice statement is binding on a relying person depends on whether the relying person has knowledge or notice of the certification practice statement. A relying person has knowledge or at least notice of the contents of the certificate used by the relying person to verify a digital signature, including documents incorporated into the certificate by reference. It is therefore advisable to incorporate a certification practice statement into a certificate by reference. NOTE: When the legal relationship is regulatory, for example, between a government and its citizens, a statute may be the means of giving effect to a certification practice statement. As much as possible, a certification practice statement should indicate any of the widely recognized standards to which the certification authority's practices conform. Reference to widely recognized standards may indicate concisely the suitability of the certification authority's practices for another person's purposes, as well as the potential technological compatibility of the certificates issued by the certification authority with repositories and other systems. Chokhani [Page 10] Internet-Draft CPF and CPSF January 1997 3.6 RELATIONSHIP BETWEEN CERTIFICATE POLICY AND CERTIFICATION PRACTICE STATEMENT The concepts of certificate policy and certification practice statement come from different sources and were developed for different reasons. However, they are interrelated. This section describes the relationship between the two. A certification practice statement is a detailed statement by a certification authority as to its practices, that potentially needs to be understood and consulted by subscribers and certificate users (relying parties). A certificate policy is a mutually understood indicator from certification authority to certificate user as to suitable applications and purposes for a particular certificate. A certification authority with a single certification practice statement may support multiple certificate policies (used by different certificate user communities). Also, multiple different certification authorities, with non-identical certification practice statements, may support the same certificate policy. For example, the Government of Canada might define a government- wide certificate policy for handling confidential human resources information. The certificate policy definition will be a broad statement of the general characteristics of that certificate policy, and an indication of the types of applications for which it is suitable for use. Different departments or agencies that operate certification authorities with different certification practice statements might support this certificate policy. At the same time, such certification authorities may support other certificate policies. In addition to populating the certificate policies field with the certificate policy identifier, a certification authority may include, in certificates it issues, a reference to its certification practice statement. A standard way to do this, using a certificate policy qualifier, is described in Section 3.4. 3.7 CA DISCLOSURE RECORD A CA Disclosure Record [9] is a body of textual information, intended to convey information about a particular certification authority that may be of some help to a certificate user in evaluating the suitability of a certificate issued by that certification authority. The following excerpt from the Utah Administrative Code has the following recommendations for the contents of a certification Chokhani [Page 11] Internet-Draft CPF and CPSF January 1997 authority disclosure record: 1. an indication that the certification authority disclosure record is provided and maintained by this state; 2. the name, street address, and voice telephone number of the certification authority; 3. the telephone number of the certification authority's facsimile transmission machine, if the certification authority has such a machine; 4. the electronic mail or other address by which the certification authority may be contacted electronically; 5. the distinguished name of the certification authority; 6. the current public key or keys of the certification authority by which its digital signatures on published certificates may be verified; 7. the restrictions, if any, placed on the certification authorities license pursuant to section 201(3); 8. if the certification authority's license has been revoked or is currently suspended, the data of revocation or suspension and the grounds for revocation or suspension; 9. the amount of the certification authority's suitable guaranty; 10. the total amount of all claims filed with the division for payment from the suitable guaranty filed by the certification authority; 11. a brief description of any limit known to the division and applicable to the certification authority's liability or legal capacity to pay damages in tort or for breach of a duty prescribed in this document; unless the limitation is specified in this document; 12. the categorization pursuant to section 202(2) of the certification authority's compliance with this document and resulting from the most recent performance audit of the certification authority's activities, and the data of the most recent performance audit; 13. any event which substantially affects the certification Chokhani [Page 12] Internet-Draft CPF and CPSF January 1997 authority's ability to conduct its business or the validity of a certificate published in the repository provided by the Division or in a recognized repository; 14. if a certificate containing the public key required to verify one or more certificates issued by the certification authority has been revoked or is currently suspended, the date of its revocation or suspension; and 15. if the certification authority has a material, primary certification practice statement, indications of its location, the method or procedure by which it may be retrieved, its form and structure, its authorship, and its date, as prescribed in rule 302. 4. REFERENCES This document is based on the certificate taxonomy developed by CygnaCom and documented in [1]. References 2 through 7 have been used to refine the framework. 1. Technical Specifications for Federal Public Key Infrastructure-Annex D: Interoperability Profiles, (Appendix E), CygnaCom Solutions, Inc., December, 1995. 2. Technical Specifications for Federal Public Key Infrastructure-Annex B: Technical Security Policy, National Institutes of Standards and Technology, December, 1995. 3. Statement of Work Federal Public Key Infrastructure Pilot, (Appendix A-Technical Specifications), Solicitation No. 52SBN5C8535, National Institutes of Standards and Technology, October, 1994. 4. Information System Security Policy and Certification Practice Statement, National Security Agency, March 12, 1996. 5. Government of Canada PKI - Certificate Policy and Certification Practices Statement Framework, November 12, 1996. 6. MISSI Policy Analysis, Booz, Allen and Hamilton, March 1996. 7. Recommendation X.509 and ISO 9594-8, Information Processing System - Open Systems Interconnection - The Directory - Authentication Framework, 1988. 8. Final Text of Draft Amendment DAM 4 to ISO/IEC 9594-2, DAM 2 to ISO/IEC 9594-6, DAM 1 to ISO/IEC 9594-7, and DAM 1 to ISO/IEC Chokhani [Page 13] Internet-Draft CPF and CPSF January 1997 9594-8 on Certificate Extensions, June 1996. 9. Utah Administrative Code. 10. American Bar Association, Digital Signature Guidelines: Legal Infrastructure for Certification Authorities and Electronic Commerce, Draft 1995. 11. Baum, Michael S., Federal Certification Authority Liability and Policy, NIST-GCR-94-654, June 1994. 12. Certification Practices Statement, Verisign, 1996. 13. Privacy Enhanced Mail, Internet RFC 1421-23, 1994 5. CERTIFICATE POLICY AND CERTIFICATION PRACTICES FRAMEWORK: OVERVIEW This section provides a brief overview of the certificate policy components. Section 6 provides a complete refinement of the components. Both the certificate policy and the CPS are composed of components described in this section and further refined in Section 6. Components can be further divided into subcomponents. Subcomponents can be divided into elements. Elements can be divided into subelements. A certificate policy or CPS consists of the following components: * Community and Applicability * Identification and Authentication Policy * Key Management Policy * Local Security Policy * Technical Security Policy * Operations Policy * Legal Provisions * Certificate and CRL Profile * Policy Administration Each of these components is described below. Chokhani [Page 14] Internet-Draft CPF and CPSF January 1997 5.1 COMMUNITY AND APPLICABILITY Under this component, the following are described: * types of subject CA certified (e.g., subordinate banks, peer banks, regional offices, etc.) (2) * types of subject Registration Authority (RA) certified (e.g., regional offices) * types of end entities certified (e.g., employees, contractors, subscribers, customers, etc.) (3) * applications for which the policy is suitable for, is restricted to, or must not be used in conjunction with. 5.2 IDENTIFICATION AND AUTHENTICATION (I&A) POLICY This component is used to describe the various I&A policies. The I&A policies are fundamental to ensuring that the bindings between the public keys and the individuals are correct. The I&A policies may be the same or different for the subject CA, subject Registration Authority (RA), and subject end entities. For each class of subject (CA, RA, or end entity), the I&A policy may be different for the various interactions with the parent CA. The interactions include, initial registration, rekey, rekey after revocation, and revocation request. The component also describes if and how the trademarks are recognized (authenticated). The component also describes if and how name disputes are resolved. 5.3 KEY MANAGEMENT POLICY This component is used to define the security measures taken by the CA to protect its cryptographic keys and critical security parameters (e.g., Personal Identification Number or PIN). This component may also be used to impose constraints on subject CAs and end entities to protect their cryptographic keys and critical security parameters. For the sake of completeness, for each type of entity (issuer CA, subject CA, RA, and end entity), and for each type of keying material (private key, parameters, public key, and critical security parameters) this element addresses the entire key life-cycle from generation, through storage and usage, to archival and destruction. Secure key management is critical to ensure that all secret and private keys and critical security parameters are protected and used only by authorized personnel. Chokhani [Page 15] Internet-Draft CPF and CPSF January 1997 5.4 LOCAL SECURITY POLICY This component is used to define the non-technical security controls used by the CA to perform CA functions securely. The CA functions include key generation, user authentication, certificate registration, certificate revocation, audit, and archival. The non-technical security controls include physical, personnel, and procedural controls. This component is also used to define non-technical security controls on subject CAs, RAs, and end entities. The non technical security controls for the subject CAs, RAs, and end entities could be the same, similar, or quite different. In most cases they are envisioned to be quite different with tighter controls on the subject CAs and RAs due to the sensitivity of the functions they perform. The security controls are critical to trusting the public key certificates since lack of security may compromise CA operations, resulting in creation of certificates or CRLs with erroneous information or even the compromise of the CA private key. 5.5 TECHNICAL SECURITY POLICY This component is used to define the technical security controls used by the CA to perform CA functions securely. The CA functions include key generation, user authentication, certificate registration, certificate revocation, audit, and archival. The technical controls include life-cycle security controls (including software development environment security, trusted software development methodology) and operational security controls. This component is also used to define technical security controls on subject CAs, RAs, and end entities. The technical security controls for the subject CAs, RAs, and end entities could be the same, similar, or quite different. In most cases they are envisioned to be quite different with tighter controls on the subject CAs and RAs due to the sensitivity of the roles they perform. The security controls are critical to trusting the public key certificates since lack of security may compromise CA operations, resulting in the creation of certificates or CRLs with erroneous information or even the compromise of the CA private key. Chokhani [Page 16] Internet-Draft CPF and CPSF January 1997 5.6 OPERATIONS POLICY This component is used to describe the frequency of routine Certificate Revocation List (CRL) issuance, frequency of special CRL issuance (e.g., key compromise CRL), and frequency for CA key changeover. It also describes how the CA operations are periodically audited by another entity and the CA's relationship with that entity. This component is also used to define who can revoke certificates under what circumstances. This component is used to describe periodic compliance audits the CA performs on the subject CAs, RAs, and end entities. Periodic compliance audit on subject CAs and RAs is recommended to ensure compliance and to maintain trustworthiness of the whole infrastructure. Periodic compliance audit of subject end entities is also desirable, but not as critical as the subject CAs. This component is also used to define the frequency of routine CRL issuance, frequency of special CRL issuance (e.g., key compromise CRL), and frequency for key changeover for the subject CAs. This component is also used to define the typical validity period for subject end entity certificates. These validity periods could be different based on key usage (e.g., signature, key establishment, etc.) This component is also used to describe the CA, subject CAs, subject RAs, and subject end entities archival policies. This component is also used to describe the procedures for recovering from CA and RA failure and compromise. This component is also used to define the confidentiality policy for the information that the CA and RA hold. This component is relevant for certificate policy, since a compliance audit policy increases the overall trustworthiness of the infrastructure entities. The CRL issuance frequency allows the users of the certificate to develop appropriate caching strategies. The key changeover period in conjunction with key size directly relate to the security offered by the cryptosystem. 5.7 LEGAL PROVISIONS This component describes the liability policy including disclaimers of warranty and limitations on liability. This component also defines the obligations of the subscribers (subject CA, RA, and end entities) and those of the certificate Chokhani [Page 17] Internet-Draft CPF and CPSF January 1997 users (relying parties). It also describes applicable laws and regulations and dispute resolution procedures. 5.8 CERTIFICATE AND CRL PROFILE This component is used to define the certificate and CRL versions and extensions supported (populated) by the CA and the criticality of the extensions. This component describes typical values of the following fields within the policy constraints extension: require explicit policy, and inhibit policy mapping. This component is also used to define the certificate and CRL versions and extensions supported (populated) by the subject CAs and the criticality of the extensions. This component describes typical values of the following fields within the policy constraints extension: require explicit policy, and inhibit policy mapping. The certificate profile could be different for different key usage such as signature, key management, certificate signing, CRL signing, etc. 5.9 POLICY ADMINISTRATION This component is used to define the authority that is responsible for the registration, maintenance and interpretation of the policy. The information includes the name and address of the organization, and the name and the telephone number of a contact person. This component also describes how the policy change is administered and how various notices are published and distributed. This component also describes how the compliance of a specific CPS with the policy is determined. 6. CERTIFICATE POLICY AND CERTIFICATION PRACTICES FRAMEWORK: DESCRIPTION In this section, we provide a complete refinement of the certificate policy and certification practices statement framework. Chokhani [Page 18] Internet-Draft CPF and CPSF January 1997 6.1 COMMUNITY AND APPLICABILITY This component consists of the following subcomponents: * Subject CAs * Subject RAs * Subject End Entities * Applicability This component describes the various types of certificate subscribers, and applications and standards. The following sections describe these subcomponents. 6.1.1 Subject CAs This subcomponent contains a brief description of the types of entities that are certified as subject CAs. (4) 6.1.2 Subject RAs This subcomponent contains a brief description of the types of entities that are certified as subject RAs. (5) 6.1.3 Subject End Entities This subcomponent contains a brief description of the types of entities that are certified as end entities. (6) 6.1.4 Applicability This subcomponent contains: * A list of applications for which the issued certificates are suitable * A list of applications that the issued certificates are restricted to. (This list implicitly prohibits all other uses for the certificates.) * A list of applications that the issued certificates are prohibited from being used for Chokhani [Page 19] Internet-Draft CPF and CPSF January 1997 6.2 IDENTIFICATION AND AUTHENTICATION (I&A) POLICY This component contains the I&A policies for subject CAs, subject RAs, and subject end entities. These policies could be the same or different for each of these entities. * Initial Registration * Routine Rekey * Rekey After Revocation * Revocation Request 6.2.1 Initial Registration This subcomponent contains the following: * Identification and authentication policy for each subject type (CA, RA, and end entity) for initial registration * Types of names assigned to the subject (7) * Whether names have to be meaningful or not (8) * Rules for interpreting various name forms * Whether names have to be unique * How name claim disputes are resolved * Whether trademarks are recognized or not * How trademarks are authenticated * What role trademarks play in naming and identification and authentication * If and how the subject must prove that (s)he possesses the companion private key for the public key being registered (9) * Authentication requirements for organizational identity of subject (CA, RA, or end entity) (10) * Authentication requirements for a person acting on behalf of subject (CA, RA, or end entity) (11) Chokhani [Page 20] Internet-Draft CPF and CPSF January 1997 * Number of identifications required * How a CA or RA validates the identification cards provided * If the person must present himself to the authenticating CA or RA * How an individual as an organizational person is authenticated (12) 6.2.2 Routine Rekey This subcomponent contains the I&A policy for routine rekey for each subject type (CA, RA, and end entity). (13) 6.2.3 Rekey After Revocation -- No Key Compromise This subcomponent is used to describe the I&A policy for rekey for each subject type (CA, RA, and end entity) after the subject certificate has been revoked. (14) 6.2.4 Revocation Request This subcomponent is used to describe the I&A policy for revocation request by each subject type (CA, RA, and end entity). (16) 6.3 KEY MANAGEMENT POLICY This component consists of the key management policies for the following entities: issuing CA, subject CAs, subject RAs, and subject end entities. These four sets of policies could be the same or different. 6.3.1 Public and Private Key Pair The key management policies for the issuing CA, subject CAs, Subject RAs, and subject end entities address the entire life- cycle of the public and private key pair from generation through archival and destruction. For each of these types of entities (issuing CA, subject CA, subject RA, subject end entity) the following questions should be answered: 6.3.1.1 Key Pair Generation and Installation 1. Who generates the entity public, private key pair? 2. How is the private key provided securely to the Chokhani [Page 21] Internet-Draft CPF and CPSF January 1997 entity? 3. How is the entity's public key provided securely to the certificate issuer? 4. If the entity is a CA (issuing or subject) how is the entity's public key provided securely to the users? 5. What are the key sizes? 6. Who generates the public key parameters? 7. Is the quality of the parameters checked during key generation? 8. Is the key generation performed in hardware or software? 9. For what purposes may the key be used (these purposes should be same as the key usage flags in the Version 3, X.509 certificates)? 10. For what purposes may the key must be restricted to(these purposes should be same as the key usage flags in the Version 3, X.509 certificates and the key usage field must be marked criical)? 11. What standards, if any, are required for the module used to generate the keys? For example, are the keys certified by the infrastructure required to be generated using modules complaint with the US FIPS 140-1? If yes, what is the security level of the module? 6.3.1.2 Private Key Protection 1. Is the private key under n out of m multi-person control?(18) If yes, provide n and m (two person control is a special case of n out of m, where n = m = 2)? 2. Is the private key escrowed? (19) If so, who is the escrow agent, what form is the key escrowed in (examples include plaintext, encrypted, split key), and what are the security controls on the escrow system? 3. Is the private key backed up? If so, who is the backup agent, what form is the key backed up in (examples include plaintext, encrypted, split key), and what are the security controls on the backup system? Chokhani [Page 22] Internet-Draft CPF and CPSF January 1997 4. Is the private key archived? If so, who is the archival agent, what form is the key archived in (examples include plaintext, encrypted, split key), and what are the security controls on the archival system? 5. Who enters the private key in the cryptographic module? In what form (i.e., plaintext, encrypted, or split key)? 6. How is the private key stored in the module (i.e., plaintext, encrypted, or split key)? 7. Who can activate (use) the private key? What actions must be performed to activate the private key (e.g., login, power on, supply PIN, insert token/key, automatic, etc.)? Once the key is activated, is the key active for an indefinite period, active for one time, or active for a defined time period? 8. Who can deactivate the private key and how? Example of how include, logout, power off, remove token/key, automatic, time expiration, etc. 9. Who can destroy the private key and how? Examples of how include token surrender, token destruction, key overwrite, etc. 6.3.1.3 Other Aspects of Key Pair Management 1. Is the public key archived? If so, who is the archival agent and what are the security controls on the archival system? The archival system should provide integrity controls other than digital signatures since: the archival period may be greater than the cryptanalysis period for the key and the archive requires tamper protection, which is not provided by digital signatures. 2. What are the validity periods for the public and the private key respectively? Chokhani [Page 23] Internet-Draft CPF and CPSF January 1997 6.3.2 Critical Security Parameters (20) The key management policies for the issuing CA, subject CAs, Subject RAs, and subject end entities address the entire life- cycle of the critical security parameters from generation through archival and destruction. For each of these types of entities (issuing CA, subject CA, subject RA, subject end entity) the following questions should be answered: 6.3.2.1 Critical Security Parameter Generation and Installation 1. Who generates the initial critical security parameters? 2. How are the critical security parameters provided securely to the entity? 3. What are the size requirements on the parameters (e.g., PIN size, password size, etc.)? 6.3.2.2 Critical Security Parameter Protection 1. Are the parameters stored in a token (e.g., crypto ignition key)? 2. Are the parameters under n out of m multi-person control? If yes, provide n and m (two person control is a special case of n out of m, where n = m = 2). 3. Are the parameters escrowed? If so, who is the escrow agent, what form are the parameters escrowed in (examples include plaintext, encrypted, split key), and what are the security controls on the escrow system? 4. Are the parameters backed up? If so, who is the backup agent, what form are the parameters backed up in (examples include plaintext, encrypted, split key), and what are the security controls on the backup system? 5. Are the parameters archived? If so, who is the archival agent, what form are the parameters archived in (examples include plaintext, encrypted, split key), and what are the security controls on the archival system? 6.3.2.3 Other Aspects of Critical Security Parameters 1. Who enters the parameters in the cryptographic module? Chokhani [Page 24] Internet-Draft CPF and CPSF January 1997 In what form (i.e., plaintext, encrypted, or split key)? 2. How are the parameters used in the module (e.g., for authentication and private key activation, private key decryption and activation, etc.)? 3. What is the recommended life for the parameters? 4. Who can change the parameters? 6.4 LOCAL SECURITY POLICY This component consists of four security policies for the four types of entities: one for the issuer CA, one for subject CAs, one for the subject RAs, and one for subject end-entities. The following sections describe the items required for these four security policies: * Physical Controls * Procedural Controls * Personnel Controls 6.4.1 Physical Controls The physical controls on the facility housing the entity systems are described.(21) 6.4.2 Procedural Controls The procedural controls for the entity are described. These controls include the description of various trusted roles and responsibilities for each of the roles.(22) For each of these roles, n out m rules should be defined, i.e. define how many people are required to perform the task. Identification and authentication requirements for each role must also be defined. Chokhani [Page 25] Internet-Draft CPF and CPSF January 1997 6.4.3 Personnel Controls This subcomponent contains the following: * Background checks and clearance procedures required for the personnel filling the trusted roles (23) * Background checks and clearance procedures requirements for other personnel (24) * Training requirements and training procedures for each role * Any retraining period and retraining procedures for each role * Frequency and sequence for job rotation among various roles * Sanctions against personnel for unauthorized actions, unauthorized use of authority, and unauthorized use of entity systems (25) * Controls on the contracting personnel for operating the entity system and facility - Bonding requirements on contract personnel - Contractual requirements including indemnification for damages due to the actions of the contractor personnel - Audit and monitoring of contractor personnel - Other controls on contracting personnel 6.5 TECHNICAL SECURITY POLICY This component consists of four technical security policies for the four types of entities: one for the issuer CA, one for subject CAs, one for the subject RAs, and one for subject end- entities. The following sections describe the items required for these four technical security policies: * Computer Security Controls * Life-Cycle Security Controls * Network Security Controls Chokhani [Page 26] Internet-Draft CPF and CPSF January 1997 * Cryptographic Module Engineering Controls * Computer Security Assurance * Life-Cycle Assurance * Cryptographic Assurance 6.5.1 Computer Security Controls This subcomponent is used to describe computer security controls. Examples of computer security controls are: trusted computing base concept, discretionary access control, labels, mandatory access controls, object reuse, audit, identification and authentication, trusted path, security testing, penetration testing, etc. 6.5.2 Life Cycle Security Controls This subcomponent is used to describe system development controls and security management controls. System development controls include development environment security, development personnel security, configuration management security during product maintenance, software engineering practices, software development methodology, modularity, layering, use of Fail-Safe design techniques, use of Fail-Safe implementation techniques (e.g., defensive programming) and development facility security. Security management controls include execution of tools and procedures to ensure that the operational systems and networks adhere to configured security. These tools and procedures include checking the integrity of the security software, firmware, and hardware to ensure their correct operation. 6.5.3 Network Security Controls This subcomponent is used to describe network security related controls for the system. Examples of network security controls are: firewalls, guards, etc. Chokhani [Page 27] Internet-Draft CPF and CPSF January 1997 6.5.4 Cryptographic Module Engineering Controls (26) This subcomponent contains the following aspects of the cryptographic module: identification of the cryptographic module boundary, input/output, roles and services, finite state machine, physical security, software security, operating system security, algorithm compliance, electromagnetic compatibility, key management, and self tests. 6.5.5 Computer Security Assurance This subcomponent is used to describe the computer security rating for the computer system. The rating could be based on the Trusted System Evaluation Criteria (TCSEC), Canadian Trusted Products Evaluation Criteria, European Information Technology Security Evaluation Criteria, or the Common Criteria. This subcomponent is also used to describe the evaluation analysis, testing, profiling, certification, and/or accreditation related activity undertaken. 6.5.6 Life-Cycle Assurance This subcomponent is used to describe the life-cycle security controls rating such as the Trusted Software Development Methodology (TSDM) level, IV&V, independent life-cycle security controls audit, and Software Engineering Institute's Capability Maturity Model (SEI-CMM). 6.5.7 Cryptographic Assurance This subcomponent is used to describe the cryptographic module's compliance with applicable standards (e.g., US FIPS 140-1). (27) 6.6 OPERATIONS POLICY The operations policy is used to describe the operating procedures for the issuing CA, subject CAs, subject RAs, and subject end entities. Each operations policy consists of the following subcomponents: * revocation policy * key compromise policy * audit policy Chokhani [Page 28] Internet-Draft CPF and CPSF January 1997 * archive policy * key changeover policy * recovery procedures * compliance audit * non-disclosure policy. The subject end entity policy does not contains the non-disclosure policy subcomponent. 6.6.1 Revocation Policy This subcomponent contains the following: * Circumstances under which the entity certificate may be revoked * Who can request the revocation of the entity certificate * Procedures used for certificate revocation request * Revocation request grace period available to the entity * Circumstances under which the entity certificate may be suspended (held) * Who can request the suspension (hold) of the entity certificate * Procedures used for certificate suspension (hold) request * How long the suspension may last * CRL issuance frequency by the entity * Requirements on the entity to check CRLs * On-line revocation checks available * Requirements on the entity to perform on-line revocation checks * Other forms of revocation advertisements available * Requirements on the entity to checks other forms of revocation advertisements Chokhani [Page 29] Internet-Draft CPF and CPSF January 1997 6.6.2 Key Compromise Policy This subcomponent is used to describe the following: * Procedures used by the entity to report key compromise * Key compromise notification grace period available to the entity * Key compromise CRL issuance frequency by the entity * Requirements on the entity to check key compromise CRL 6.6.3 Audit Policy This subcomponent is used to describe the following: * Types of events the entity audits (28) * Frequency with which each event is audited * Period for which audit logs are kept * Protection of audit logs - Who can view the audit log - Protection against modification of audit log - Protection against deletion of audit log * Audit log back up procedures * Whether the audit collection system is internal or external to the entity * Whether the subject who caused an audit event to occur is notified of the audit action Chokhani [Page 30] Internet-Draft CPF and CPSF January 1997 6.6.4 Archive Policy This subcomponent is used to describe the following: * Types of event to be archived (29) * Retention period for archive * Protection of archive - Who can view the archive - Protection against modification of archive - Protection against deletion of archive * Archive back up procedures * Whether the archive collection system is internal or external to the entity * Archive custodian in case of entity termination * Procedures to obtain and verify archive information 6.6.5 Key Changeover This subcomponent contains the following: * Entity public key validity period * Procedures to provide the new entity public key to the users 6.6.6 Recovery Procedures This subcomponent is used to describe the disaster recovery procedures for the entity. This subcomponent also contains the recovery procedures used by the entity under each of the following circumstances: * The recovery procedures used if the entity computing resources, software, and/or data are corrupted or suspected to be corrupted. These procedures describe how a secure environment is reestablished, which certificates and CRL are revoked, whether the entity key is revoked, how the new entity public key is provided to the users, and how the Chokhani [Page 31] Internet-Draft CPF and CPSF January 1997 subjects are recertified. * The recovery procedures used if the entity public key is revoked. These procedures describe how a secure environment is reestablished, how the new entity public key is provided to the users, and how the subjects are recertified. * The recovery procedures used if the entity key is compromised. These procedures describe how a secure environment is reestablished, how the new entity public key is provided to the users, and how the subjects are recertified. 6.6.7 Compliance Audit This subcomponent contains the following: * Frequency of compliance audit for the entity * Identity of the audit entity * Auditing entity's relationship to the entity being audited (30) * List of topics covered under the compliance audit(31) * Actions taken as a result of a deficiency found during compliance audit (32) * Compliance audit results: who are they shared with (e.g., subject CA, RA, and/or end entities), who provides them (e.g., entity being audited, or auditor), how are they provided, i.e., communication mechanism 6.6.8 Non-disclosure Policy This subcomponent contains the following: * Information that must be kept confidential by the entity * Who is entitled to know what in terms of the reasons for revocation and suspension of the certificates issued by the entity * Who is entitled to know what in terms of the reasons for revocation and suspension requested by the entity * Information that can be revealed to the law enforcement Chokhani [Page 32] Internet-Draft CPF and CPSF January 1997 personnel * Information that can be revealed as part of civil discovery * List of other mitigating circumstances under which confidential information may be disclosed 6.7 LEGAL PROVISIONS The legal provisions include the following subcomponents for each of the four types of the entities (issuing CA, subject CAs, subject RAs, and subject end entities): * Entity Liability Policy * Entity Obligations * Certificate User (Relying Party) Obligations * Financial Responsibility * Laws and Procedures * Fees The subject end entities only contain the following subcomponents: entity liability policy, entity obligations. 6.7.1 Entity Liability Policy This subcomponent contains the following: * Warranties and disclaimers of warranties * Liabilities and limitations on liabilities 6.7.2 Entity Obligations This subcomponent contains the following: * Entity's obligations in terms of accuracy of representation * Obligations of the entity to protect the private key * Purpose for which the entity's private key is constrained to be used for Chokhani [Page 33] Internet-Draft CPF and CPSF January 1997 * Entity's obligations for notification of issuance of a certificate to the subscriber who is the subject of the certificate being issued * Entity's general obligations for notification of issuance of a certificate to others than the subject of the certificate * Entity's obligations for notification of revocation of a certificate to the subscriber whose certificate is being revoked * Entity's general obligations for notification of revocation of a certificate to others than the subject whose certificate is being revoked * Entity's obligations for notification of suspension of a certificate to the subscriber whose certificate is being suspended * Entity's general obligations for notification of suspension of a certificate to others than the subject whose certificate is being suspended 6.7.3 Certificate User (Relying Party) Obligations This subcomponent contains the following elements: * Purposes for which a relying party may use the certificates issued by the entity * Certificate verification responsibilities of the relying parties * Revocation and suspension checking responsibilities of the relying parties 6.7.4 Financial Responsibility This subcomponent contains the following elements: * Indemnification clause for the entity by the certificate users * Fiduciary relationship of the entity with subscribers and entities in the infrastructure Chokhani [Page 34] Internet-Draft CPF and CPSF January 1997 6.7.5 Laws and Procedures This subcomponent contains the following elements: * Statement about applicable laws and regulations * Dispute resolution procedures 6.7.6 Fees This subcomponent contains the following elements: * Certificate issuance fee * Certificate access fee * Revocation information access fee * Fee for other services such as the certificate status, policy information, etc. * Refund policy for the various services 6.8 CERTIFICATE AND CRL PROFILES This component is used to define the certificate and CRL versions and extensions supported (populated) by the issuing CA and the subject CAs. This component contains the following information: * Certificate Profile * CRL Profile 6.8.1 Certificate Profile This subcomponent has the following information: certificate version, naming, policy related information. 6.8.1.1 Certificate Version This subcomponent has the following elements: * A list of version numbers supported for the certificate * A list of certificate profiles (e.g., PKIX, Federal PKI, or ANSI X9.57, etc.) * Certificate extensions populated and their criticality. Chokhani [Page 35] Internet-Draft CPF and CPSF January 1997 * Signature, key management, and other cryptographic algorithms object identifiers 6.8.1.2 Naming This subcomponent has the following elements: * Name forms used for the CA, RA, and end entity names * Name constraints used and the name forms used in the name constraints 6.8.1.3 Policy This subcomponent has the following elements: * Applicable policy OID for this policy * Typical values for the following fields within the policy constraints extension: require explicit policy and inhibit policy mapping * Policy qualifiers syntax, semantics, and their processing semantics * Processing semantics for the critical certificate policy extension 6.8.2 CRL Profile This subcomponent has the following elements: * A list of the version numbers supported for CRLs * CRL and CRL entry extensions populated and their criticality 6.9 POLICY ADMINISTRATION This component is used to define the authority that is responsible for the registration, maintenance, and interpretation of the policy. Chokhani [Page 36] Internet-Draft CPF and CPSF January 1997 6.9.1 Contact Information This subcomponent includes the name, mailing address of the organization, and the name, electronic mail address, telephone number, and fax number of a contact person. It also describes who performs the analysis of a CPS to determine its suitability as an implementation vehicle for the policy. 6.9.2 Policy Definition and Practice Statement Change Procedures It will occasionally be necessary to change certificate policies and Certification Practice Statements. Some of these changes will not change the assurance that a certificate policy or its implementation provide, and will be judged by the policy administrator as not changing the acceptability of certificates asserting the policy for the purposes for which they have been used. Such changes to security policies and Certification Practice Statements need not require a change in the policy Object Identifier (OID). Changes to other policy components (or their implementations) will change the acceptability of certificates for specific purposes, and these changes will require changes to the OID representing the changed policy. This subcomponent contains the following information: * a list of policy or CPS components, subcomponents, and elements that can be changed without notification and without changes to the policy OID. * a list of the policy or CPS components, subcomponents, and elements that may change following a notification period without changing the policy OID. The procedures to be used to notify interested parties (relying parties, certification authorities, etc.) of the policy or CPS changes is described. The description of notification procedures includes the notification mechanism, notification period for comments, mechanism to receive, review and incorporate the comments, mechanism for final changes to the policy, and the period before final changes become effective. * a list of components, subcomponents, and elements changes to which require a change in the policy object identifier. Chokhani [Page 37] Internet-Draft CPF and CPSF January 1997 6.9.3 Publication and Notification Policies This subcomponent contains the following elements: * list of components, subcomponents, and elements that are not published in the CPS(33) * descriptions of mechanisms used to distribute the policy, CPS, certificates, certificate status, and CRLs * access control on information objects including the policy, CPS, certificates, certificate status, and CRLs * notification procedures for the security breaches of CA and RA * procedures for termination and for termination notification of the CA and RA, including the identity of the custodian of CA and RA archival records 7. CERTIFICATE POLICY AND CPS OUTLINE This appendix contains a possible outline for a certificate policy or a CPS. With further development, it is intended to evolve to a standard template suitable for use by certificate policy or CPS writers. Such a common format will facilitate: 1. ease in comparing two policies during cross-certification (for the purpose of equivalency mapping). 2. ease in comparing a CPS with a policy to ensure that the CPS faithfully implements the policy. 3. ease in comparing two CPS for equivalency. Following is the proposed outline for a certificate policy or CPS. Since a certificate policy and a CPS both address the same issues (a CPS is a detailed description of how a policy is implemented), we expect that they both should be able to use the same outline. It is proposed that the upper two levels of this outline form the basis of a certificate policy or CPS template. Lower level items constitute a useful checklist for the certificate or CPS writer, but would not form part of the template. COMMUNITY AND APPLICABILITY Types of CAs certified Chokhani [Page 38] Internet-Draft CPF and CPSF January 1997 Types of RAs certified Types of end entities certified Applicability List of suitable applications List of approved applications List of prohibited applications IDENTIFICATION AND AUTHENTICATION (34) Initial registration Types of names Need for names to be meaningful Rules for interpreting various name forms Uniqueness of names Name claim dispute resolution procedure Recognition, authentication and role of trademarks in I&A Method to prove possession of private key Authentication of organization identity Authentication of individual identity Number of identifications required Authentication confirmation procedure Need to present in person Routine Rekey Authentication method Method to prove possession of private key Rekey after revocation Chokhani [Page 39] Internet-Draft CPF and CPSF January 1997 Authentication method Method to prove possession of private key Revocation Request Authentication method KEY MANAGEMENT (34) Key Pair Generation and Installation Key pair generating entity Method for private key delivery to entity Method for public key delivery to certificate issuer Method for CA public key delivery to users Key sizes Public key parameters generating entity Parameter quality checking Hardware/software key generation Key usage purposes (as per X.509 v3 key usage field) Key usage restrictions (as per X.509 v3 critical key usage field) Standards for cryptographic module Private Key Protection Private key under (n out of m) multi-person control Private key escrow Private key backup Private key archival Private key entry into cryptographic module Storage form of the private key in the module Chokhani [Page 40] Internet-Draft CPF and CPSF January 1997 Method of activating private key Method of deactivating private key Method of destroying private key Other Aspects of Key Pair Management Public key archival Usage periods for the public and private keys Critical Security Parameters Generation and Installation Critical security parameter generating entity Method for delivery of critical security parameters Critical security parameter sizes Critical Security Parameter Protection Storage medium for critical security parameters Critical security parameters under (n out of m) multi-person control Critical security parameters escrow Critical security parameters backup Critical security parameters archival Other Aspects of Critical Security Parameters Critical security parameters entry into cryptographic module Critical security parameters purpose Usage periods for critical security parameters Changes to critical security parameters LOCAL SECURITY POLICY (34) Physical controls Procedural controls Chokhani [Page 41] Internet-Draft CPF and CPSF January 1997 Separation of duties n out of m rule for each role I&A requirement for each role Personnel Controls Clearance procedures Training requirements Retraining period and requirements Job rotation frequency and sequence Sanctions for unauthorized use Contracting personnel Bonding requirements Indemnification for damages due to contractor Audit and monitoring of contractor personnel Other controls TECHNICAL SECURITY POLICY (34) Computer security controls Trusted Computing Base Identification and Authentication Discretionary Access Controls Labels Mandatory Access Controls Object Reuse Audit Trusted Path Chokhani [Page 42] Internet-Draft CPF and CPSF January 1997 Security Testing Penetration Testing Life cycle technical controls System development controls Development environment security Development personnel security Configuration management Development facility physical controls Software engineering practices Software development methodology Modularity Layering Fail-Safe Design Fail-Safe Implementation Security management controls Procedures Tools Software Integrity Firmware Integrity Hardware Integrity Network security controls firewalls and guard firewall and guard policy firewall and guard security rating Chokhani [Page 43] Internet-Draft CPF and CPSF January 1997 Crypto Engineering Controls input/output roles and services finite state machine physical security software security operating system security algorithm compliance electromagnetic compatibility key management self tests Computer Security Assurance standard rating organization accreditation of rating organization rating Evaluation analysis Security testing System security profiling System certification and/or accreditation Life-cycle Security Assurance TSDM level, rating organization, and accreditation of rating organization IV&V Independent life-cycle security controls audit Chokhani [Page 44] Internet-Draft CPF and CPSF January 1997 SEI CMM level, rating organization, and accreditation of rating organization Cryptographic Module Assurance standard rating organization accreditation of rating organization rating OPERATIONS POLICY (34) Revocation When can entity (CA, RA, or end entity) certificate be revoked Who can request revocation of entity certificate Procedure for entity certificate revocation Revocation request grace period When can the entity certificate be suspended (put on hold) Who can request the entity certificate suspension Procedures for entity certificate suspension request Length of suspension CRL issuance frequency by the entity (if applicable) CRL check requirement on the entity On-line revocation checks available Requirements on the entity to perform on-line revocation checks Other forms of revocation advertisements available Requirements on the entity to check other forms of revocation advertisements Key compromise Procedure used by the entity to report key compromise Chokhani [Page 45] Internet-Draft CPF and CPSF January 1997 Key compromise notification grace period Key compromise CRL issuance by the entity (if applicable) Requirement on the entity to check key compromise CRL Audit policy Types of event to be audited Frequency with which each event is audited Retention period for audit log Protection of audit log Who can view the audit log Protection against modification of audit log Protection against deletion of audit log Audit log back up procedures Audit collection system (internal or external to the entity) Notification to audit causing subject Archive policy Types of event to be archived Retention period for archive Protection of archive Who can view the archive Protection against modification of archive Protection against deletion of archive Archive back up procedures Archive collection system (internal or external to the entity) Archive custodian in case of entity termination Chokhani [Page 46] Internet-Draft CPF and CPSF January 1997 Procedures to obtain and verify archive information Key changeover Public key validity period Procedures to provide new key to users Recovery procedures Disaster recovery procedures Recovery from entity resources corruption Recovery from entity public key revocation (no key compromise) Recovery from entity private key compromise Compliance audit Frequency of entity compliance audit Entity's relationship to the auditor Topic covered by the audit Actions taken as a result of deficiency Entities who are provided the results of compliance audit Entity who provides the results of compliance audit Mechanism used to provide results of compliance audit Non-disclosure policy Information to be kept confidential by the entity Disclosure rules (who can be told what) for reasons of revocation/suspension of certificates Information that can be revealed to the law enforcement personnel Information that can be revealed as part of civil discovery Mitigating circumstances when confidential information may be disclosed Chokhani [Page 47] Internet-Draft CPF and CPSF January 1997 LEGAL PROVISIONS Certification Authority Liability Warranties and disclaimers of warranties Liabilities and limitations on liabilities CA obligations Accuracy of representations Protection of issuing CA private key Restrictions on issuing CA private key use Notification of issuance of a certificate to the subject of the certificate Notification of issuance of a certificate to others Notification of revocation of a certificate to the subject of the certificate Notification of revocation of a certificate to others Notification of suspension of a certificate to the subject of the certificate Notification of suspension of a certificate to others Certificate user obligations Use of certificates for appropriate purpose Certificate verification responsibilities Revocation/suspension check responsibility Financial responsibility Indemnification of issuing CA by certificate users Fiduciary relationships of the issuing CA Laws and procedures Chokhani [Page 48] Internet-Draft CPF and CPSF January 1997 Applicable laws and regulations Dispute resolution procedures Fees Certificate issuance fee Certificate access fee Revocation information access fee Fee for other services such as the certificate status, policy information, etc. Refund policy for the various services. Registration Authority Liability Warranties and disclaimers of warranties Liabilities and limitations on liabilities Subject RA obligations Accuracy of representations Protection of RA private key Restrictions on RA private key use Certificate user obligations Use of certificates for appropriate purpose Certificate verification responsibilities Revocation/suspension check responsibility Financial responsibility Indemnification of RA by certificate users Fiduciary relationships of RA Laws and procedures Chokhani [Page 49] Internet-Draft CPF and CPSF January 1997 Applicable laws and regulations Dispute resolution procedures Fees Certificate registration fee Certificate revocation fee Fee for other services Refund policy for the various services. End entity Liability Warranties and disclaimers of warranties Liabilities and limitations on liabilities End entity obligations Accuracy of representations Protection of end entity private key Restrictions on end entity private key use CERTIFICATE AND CRL PROFILES (34) Certificate Profile Certificate Version A list of version numbers supported for the certificate A list of certificate profiles (e.g., PKIX, Federal PKI, or ANSI X9.57, etc.) Certificate extensions populated and their criticality. Signature, key management, and other cryptographic algorithms object identifiers Naming Chokhani [Page 50] Internet-Draft CPF and CPSF January 1997 Name forms used for the CA, RA, and end entity names Name constraints used and the name forms used in the name constraints Policy Applicable policy OID for this policy Typical values for the following fields within the policy constraints extension: require explicit policy and inhibit policy mapping Policy qualifiers syntax, semantics, and their processing semantics Processing semantics for the critical certificate policy extension CRL Profile A list of the version numbers supported for CRLs CRL and CRL entry extensions populated and their criticality POLICY ADMINISTRATION Contact information Name and mailing address of the policy administration organization Name, electronic mail address, telephone number, and fax number of a contact person Name and telephone number of person determining CPS suitability for the policy Policy definition change procedures List the items that can change without notification Items that can change with notification List of items Notification mechanism Comment period Chokhani [Page 51] Internet-Draft CPF and CPSF January 1997 Mechanism to handle comments Period for final change notice List of items whose change requires a new policy Publication and notification policies List of items not published in the CPS Mechanisms used to distribute policy, CPS, certificates, certificate status, and CRLs. Access control on information objects including the policy, CPS, certificates, certificate status, and CRLs Notification procedures for security breaches of issuing CA Notification procedures for security breaches of subject CA Notification procedures for security breaches of subject RA Termination procedure and notification for issuing CA Termination procedure and notification for subject CA Termination procedure and notification for subject RA 8. LIST OF ACRONYMS ABA - American Bar Association CA - Certification Authority CC - Common Criteria CMM - Capability Maturity Model CPS - Certification Practice Statement CRL - Certificate Revocation List DAM - Draft Amendment DAP - Directory Access Protocol FIPS - Federal Information Processing Standard FSDA - Fail Safe Design Analysis I&A - Identification and Authentication IEC - International Electrotechnical Commission IETF - Internet Engineering Task Force IP - Internet Protocol Chokhani [Page 52] Internet-Draft CPF and CPSF January 1997 ISO - International Organization for Standardization ITU - International Telecommunications Union IV&V - Independent Validation and Verification MSP - Message Security Protocol NIST - National Institute of Standards and Technology OID - Object Identifier PIN - Personal Identification Number PKCS - Public Key Cryptography Standard PKI - Public Key Infrastructure PKIX - Public Key Infrastructure (X.509) (IETF Working Group) RA - Registration Authority RFC - Request For Comment SEI - Software Engineering Institute S-HTTP - Secure HyperText Transfer Protocol S/MIME - Secure/Multipurpose Internet Mail Extension TCP - Transmission Control Protocol TCSEC - Trusted Computer System Evaluation Criteria TSDM - Trusted Software Development Methodology URL - Uniform Resource Locator US - United States 9. GLOSSARY OF TERMS Accreditation: A decision by the responsible official of the organization to operate a system and accept the residual risks identified by the certification activities, or to accept the risks even though no certification activities have been done or completed. (System) Certification: A series of security engineering activities to ensure that the security requirements for a system are implemented correctly, and to identify residual risks. The certification activities typically consist of security analysis of the system architecture, design, and implementation and security testing of the system. End Entity: A person or a computer system who is not a CA or RA. Entity: A CA, RA, or end entity. Relying Party: Someone who uses a public key in a certificate to Chokhani [Page 53] Internet-Draft CPF and CPSF January 1997 either verify a digital signature or to encrypt keys or data. Critical Security Parameters: security-related information (e.g., cryptographic keys, authentication data such as passwords and personal identification number (PIN)) Subject: An entity whose public key is certified in a public key certificate. Subject End Entity: An end entity who is the subject of a certificate. Subscriber: See subject User: See relying party 10. ENDNOTES 1 Extracts of the ABA Digital Signature Guidelines presented in this report are taken from the 1995 draft version which was publicly released for review and comment. Later work revising the document has not been publicly released, but does not materially impact the correctness of this report. 2 Example: A bank claims that it issues CA certificates to its branches only. Now, the user of a CA certificate issued by the bank can assume that the subject CA in the certificate is a branch of the bank. 3 Example: A Government CA claims that it issues certificates to Government employees only. Now, the user of a certificate issued by the Government CA can assume that the subject of the certificate is a Government employee. 4 Examples of the types of subject CA entities are a subordinate organizations (e.g., branch, division, etc.), a US Federal Government agency, a Government of Canada agency, a state agency, a provincial department, etc. 5 Examples of the types of subject RA entities are branch and division of an organization. 6 Examples of types of subject end entities are uniformed and civilian DoD personnel, DoD contractors, Ministry of Defense employees, bank customers, telephone company subscribers, etc. 7 Examples include X.500 distinguished names, RFC 822 Internet names, URL, etc. Chokhani [Page 54] Internet-Draft CPF and CPSF January 1997 8 The term meaningful means that the name form has commonly understood semantics to determine identity of the person and/or organization. The directory names and RFC 822 names are examples of meaningful names. 9 Examples of proof include the issuing CA generating the key, or requiring the subject to send an electronically signed request or to sign a challenge. 10 Examples of organization identity authentication are: articles of incorporation, duly signed corporate resolutions, company seal, and notarized documents. 11 Examples of individual identity authentication are: biometrics (thumb print, ten finger print, face, palm, and retina scan), driver's license, passport, credit card, company badge, and government badge. 12 Examples include duly signed authorization papers, corporate badge, etc. 13 The identification policy for routine rekey should be the same as the one for initial registration since the same subject needs rekeying. The rekey authentication may be accomplished using the techniques for initial I&A or using digitally signed requests. 14 This I&A policy could be the same as the one for initial registration. 15 This policy could be the same as the one for initial registration. 16 The identification policy for Revocation request could be the same as the one for initial registration since the same subject certificate needs to be revoked. The authentication policy could accept a Revocation request digitally signed by subject. The authentication information used during initial registration could be acceptable for Revocation request. Other less stringent authentication policy could be defined. 17 The identification policy for key compromise notification could be the same as the one for initial registration since the same subject certificate needs to be revoked. The authentication policy could accept a Revocation request digitally signed by subject. The authentication information used during initial registration could be acceptable for key compromise notification. Other less stringent authentication policy could be defined. 18 The n out of m rule allows a key to be split in m parts. The m Chokhani [Page 55] Internet-Draft CPF and CPSF January 1997 parts may be given to m different individuals. Any n parts out of the m parts may be used to fully reconstitute the key, but having any n-1 parts provides one with no information about the key. 19 A key may be escrowed, backed up or archived. Each of these functions have different purpose. Thus, a key may go through any subset of these functions depending on the requirements. The purpose of escrow is to allow a third party (such as an organization or government) to legally obtain the key without the cooperation of the subject. The purpose of back up is to allow the subject to reconstitute the key in case of the destruction of the key. The purpose of archive is to provide for reuse of the key in future, e.g., use the private key to decrypt a document. 20 The critical security parameters are the information other than the public and private key pair and public key parameters required to operate the module. An example of a critical security parameters is a PIN or passphrase. The public key parameters are NOT an example of critical security parameters. 21 Examples of physical controls are: monitored facility, guarded facility, locked facility, access controlled using tokens, access controlled using biometrics, access controlled through an access list, etc. 22 Examples of the roles include, system administrator, system security officer, system auditor, and crypto officer. The duties of the system administrator are to configure, generate, boot, and operate the system. The duties of the system security officer are to assign accounts and privileges. The duties of the system auditor are to set up system audit profile, perform audit file management, and audit review. The duties of the crypto officer are to hold, manage, and protect the CA keys and PINs, and to use them to operate the cryptographic devices used by the CA to sign the certificates and the CRLs. 23 The background checks may include clearance level (e.g., none, sensitive, confidential, secret, top secret, etc.) and the clearance granting authority name. In lieu of or in addition to a defined clearance, the background checks may include types of background information (e.g., name, place of birth, date of birth, home address, previous residences, previous employment, and any other information that may help determine trustworthiness). The description should also include which information was verified and how. 24 For example, the certificate policy may impose personnel security requirements on the network system administrator responsible for a CA's network access. Chokhani [Page 56] Internet-Draft CPF and CPSF January 1997 25 Each authorized person should be accountable for his/her actions. 26 A cryptographic module is hardware, software, or firmware or any combination of them. 27 The compliance description should be specific and detailed. For example, for each FIPS 140-1 requirement, describe the level and whether the level has been certified by an accredited laboratory. 28 Example of audit events are: request to create a certificate, request to revoke a certificate, key compromise notification, creation of a certificate, revocation of a certificate, issuance of a certificate, issuance of a CRL, issuance of key compromise CRL, establishment of trusted roles on the CA, actions of truste personnel, changes to CA keys, etc. 29 Example of archive events are: request to create a certificate, request to revoke a certificate, key compromise notification, creation of a certificate, revocation of a certificate, issuance of a certificate, issuance of a CRL, issuance of key compromise CRL, and changes to CA keys. 30 a parent CA is an example of audit relationship. 31 Example of compliance audit topics: sample check on the various I&A policies, comprehensive checks on key management policies, comprehensive checks on system security controls, comprehensive checks on operations policy, and comprehensive checks on certificate profiles, 32 The examples include, temporary suspension of operations until deficiencies are corrected, revocation of entity certificate, change in personnel, invocation of liability policy, more frequent compliance audit, etc. 33 An organization may choose not to make public some of its security controls, clearance procedures, or some others elements due to their sensitivity. 34 All or some of the following items may be different for the various types of entities, i.e., CA, RA, and end entities. 11. Security Considerations This entire memo deals with security related to public key certificates. Chokhani [Page 57] Internet-Draft CPF and CPSF January 1997 12. Acknowledgments We would like to thank Dave Fillingham and Jim Brandt for their inspiration, numerous valuable suggestions and inputs. We would also like to thank Edmond Van Hees for his support and inputs. We would also like to thank the Government of Canada's Policy Management Authority (PMA) Committee for their contribution and support of this work. This document has been developed under the guidance of the International Policy Framework Working Group. The members of this working group are: Richard Bloom, US Federal Security Infrastructure Program Management Office; Santosh Chokhani (Co-Author), CygnaCom Solutions, Inc.; David W. Fillingham, National Security Agency; Warwick Ford (Co-Author); Richard Kemp, US Federal Security Infrastructure Program Management Office; Noel Nazario, National Institute of Standards and Technology; David Simonetti, Booz, Allen and Hamilton; and Edmond Van Hees, Communication Security Establishment, Government of Canada. We would also like the following industry members for their review and input: Teresa Acevedo, A&N Associates; Michael Baum, Verisign; Patrick Cain, BBN; Michael Harrop, Government of Canada Treasury Board; John Morris, CygnaCom Solutions, Inc.; Tim Moses, Nortel; John Nicolletos, A&N Associates; Jean Petty, CygnaCom Solutions, Inc.; and Darryl Stal, Nortel. Johnny Hsiung and Chris Miller assisted in the preparation of the manuscript. 13. Author's Address Questions about this document can be directed to the authors: Santosh Chokhani CygnaCom Solutions, Inc. Suite 100 West 7927 Jones Branch Drive McLean, VA 22102 Phone: (703) 848-0883 Fax: (703) 848-0960 EMail: chokhani@cygnacom.com Warwick Ford VeriSign, Inc. Chokhani [Page 58] Internet-Draft CPF and CPSF January 1997 Phone: (613) 225-3487 Fax: (613) 225-6361 Email: wford@verisign.com expires in six months June 1997 Chokhani [Page 59]