Network Working Group S. Chokhani Request for Comments: 2527 CygnaCom Solutions, Inc. Category: Informational W. Ford VeriSign, Inc. March 1999 Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This document presents a framework to assist the writers of certificate policies or certification practice statements for certification authorities and public key infrastructures. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy definition or a certification practice statement. 1. INTRODUCTION 1.1 BACKGROUND A public-key certificate (hereinafter "certificate") binds a public- key value to a set of information that identifies the entity (such as person, organization, account, or site) associated with use of the corresponding private key (this entity is known as the "subject" of the certificate). A certificate is used by a "certificate user" or "relying party" that needs to use, and rely upon the accuracy of, the public key distributed via that certificate (a certificate user is typically an entity that is verifying a digital signature from the certificate's subject or an entity sending encrypted data to the subject). The degree to which a certificate user can trust the binding embodied in a certificate depends on several factors. These factors include the practices followed by the certification authority (CA) in authenticating the subject; the CA's operating policy, procedures, and security controls; the subject's obligations (for example, in protecting the private key); and the stated undertakings Chokhani & Ford Informational [Page 1] RFC 2527 PKIX March 1999 and legal obligations of the CA (for example, warranties and limitations on liability). A Version 3 X.509 certificate may contain a field declaring that one or more specific certificate policies applies to that certificate [ISO1]. According to X.509, 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 certificate policy may be used by a certificate user to help in deciding whether a certificate, and the binding therein, is sufficiently trustworthy for a particular application. The certificate policy concept is an outgrowth of the policy statement concept developed for Internet Privacy Enhanced Mail [PEM1] and expanded upon in [BAU1]. A more detailed description of the practices followed by a CA in issuing and otherwise managing certificates may be contained in a certification practice statement (CPS) published by or referenced by the CA. According to the American Bar Association Digital Signature Guidelines (hereinafter "ABA Guidelines"), "a CPS is a statement of the practices which a certification authority employs in issuing certificates." [ABA1] 1.2 PURPOSE The purpose of this document is to establish a clear relationship between certificate policies and CPSs, and to present a framework to assist the writers of certificate policies or CPSs with their tasks. In particular, the framework identifies the elements that may need to be considered in formulating a certificate policy or a CPS. The purpose is not to define particular certificate policies or CPSs, per se. 1.3 SCOPE The scope of this document is limited to discussion of the contents of a certificate policy (as defined in X.509) or CPS (as defined in the ABA Guidelines). In particular, this document describes the types of information that should be considered for inclusion in a certificate policy definition or a CPS. While the framework as presented generally assumes use of the X.509 version 3 certificate format, it is not intended that the material be restricted to use of that certificate format. Rather, it is intended that this framework be adaptable to other certificate formats that may come into use. The scope does not extend to defining security policies generally (such as organization security policy, system security policy, or data labeling policy) beyond the policy elements that are considered Chokhani & Ford Informational [Page 2] RFC 2527 PKIX March 1999 of particular relevance to certificate policies or CPSs. This document does not define a specific certificate policy or CPS. It is assumed that the reader is familiar with the general concepts of digital signatures, certificates, and public-key infrastructure, as used in X.509 and the ABA Guidelines. 2. DEFINITIONS This document makes use of the following defined terms: Activation data - Data values, other than keys, that are required to operate cryptographic modules and that need to be protected (e.g., a PIN, a passphrase, or a manually-held key share). CA-certificate - A certificate for one CA's public key issued by another CA. 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. Certification path - An ordered sequence of certificates which, together with the public key of the initial object in the path, can be processed to obtain that of the final object in the path. Certification Practice Statement (CPS) - A statement of the practices which a certification authority employs in issuing certificates. Issuing certification authority (issuing CA) - In the context of a particular certificate, the issuing CA is the CA that issued the certificate (see also Subject certification authority). Policy qualifier - Policy-dependent information that accompanies a certificate policy identifier in an X.509 certificate. Registration authority (RA) - An entity that is responsible for identification and authentication of certificate subjects, but that does not sign or issue certificates (i.e., an RA is delegated certain tasks on behalf of a CA). [Note: The term Local Registration Authority (LRA) is used elsewhere for the same concept.] Chokhani & Ford Informational [Page 3] RFC 2527 PKIX March 1999 Relying party - A recipient of a certificate who acts in reliance on that certificate and/or digital signatures verified using that certificate. In this document, the terms "certificate user" and "relying party" are used interchangeably. Set of provisions - A collection of practice and/or policy statements, spanning a range of standard topics, for use in expressing a certificate policy definition or CPS employing the approach described in this framework. Subject certification authority (subject CA) - In the context of a particular CA-certificate, the subject CA is the CA whose public key is certified in the certificate (see also Issuing certification authority). 3. CONCEPTS This section explains the concepts of certificate policy and CPS, and describes their relationship. Other related concepts are also described. Some of the material covered in this section and in some other sections is specific to certificate policies extensions as defined X.509 version 3. Except for those sections, this framework is intended to be adaptable to other certificate formats that may come into use. 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). However, the extent to which the certificate user should rely on that statement by the CA needs to be assessed by the certificate user. Different certificates are issued following different practices and procedures, and may be suitable for different applications and/or purposes. 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"[ISO1]. An X.509 Version 3 certificate may contain an indication of certificate policy, which may be used by a certificate user to decide whether or not to trust a certificate for a particular purpose. A certificate policy, which needs to be recognized by both the issuer and user of a certificate, is represented in a certificate by a unique, registered Object Identifier. The registration process follows the procedures specified in ISO/IEC and ITU standards. The Chokhani & Ford Informational [Page 4] RFC 2527 PKIX March 1999 party that registers the Object Identifier also publishes a textual specification of the certificate policy, for examination by certificate users. Any one certificate will typically declare a single certificate policy or, possibly, be issued consistent with a small number of different policies. Certificate policies also constitute a basis for accreditation of CAs. Each CA is accredited against one or more certificate policies which it is recognized as implementing. When one CA issues a CA- certificate for another CA, the issuing CA must assess the set of certificate policies for which it trusts the subject CA (such assessment may be based upon accreditation with respect to the certificate policies involved). The assessed set of certificate policies is then indicated by the issuing CA in the CA-certificate. The X.509 certification path processing logic employs these certificate policy indications in its well-defined trust model. 3.2 CERTIFICATE POLICY EXAMPLES For example purposes, suppose that IATA undertakes to define some certificate policies for use throughout the airline industry, in a public-key infrastructure operated by IATA in combination with public-key infrastructures operated by individual airlines. Two certificate policies are defined - the IATA General-Purpose policy, and the IATA Commercial-Grade policy. The IATA General-Purpose policy is intended for use by industry personnel for protecting routine information (e.g., casual electronic mail) and for authenticating connections from World Wide Web browsers to servers for general information retrieval purposes. The key pairs may be generated, stored, and managed using low-cost, software-based systems, such as commercial browsers. Under this policy, a certificate may be automatically issued to anybody listed as an employee in the corporate directory of IATA or any member airline who submits a signed certificate request form to a network administrator in his or her organization. The IATA Commercial-Grade policy is used to protect financial transactions or binding contractual exchanges between airlines. Under this policy, IATA requires that certified key pairs be generated and stored in approved cryptographic hardware tokens. Certificates and tokens are provided to airline employees with disbursement authority. These authorized individuals are required to present themselves to the corporate security office, show a valid identification badge, and sign an undertaking to protect the token and use it only for authorized purposes, before a token and a certificate are issued. Chokhani & Ford Informational [Page 5] RFC 2527 PKIX March 1999 3.3 X.509 CERTIFICATE FIELDS The following extension fields in an X.509 certificate are used to support certificate policies: * Certificate Policies extension; * Policy Mappings extension; and * 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 different in the two cases. 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 IATA General- Purpose and Commercial-Grade policies defined in Section 3.2, the certificates issued to regular airline employees will contain the object identifier for certificate policy for the General-Purpose policy. The certificates issued to the employees with disbursement authority will contain the object identifiers for both the General- Purpose policy and the Commercial-Grade policy. The Certificate Policies field may also optionally convey qualifier values for each identified policy; use of qualifiers is discussed in Section 3.4. 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 General-Purpose policy. However, an airline's financial applications will be configured to require the Commercial-Grade policy for validating financial transactions over a certain dollar value. 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 CA-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 only be used in accordance with the provisions of one of the listed certificate policies. This field is Chokhani & Ford Informational [Page 6] RFC 2527 PKIX March 1999 intended to protect the certification authority against damage claims by a relying party who has used the certificate for an inappropriate purpose or in an inappropriate manner, as stipulated in the applicable certificate policy definition. For example, the Internal Revenue Service might issue certificates to taxpayers for the purpose of protecting tax filings. The Internal Revenue Service understands and can accommodate the risks of accidentally issuing a bad certificate, e.g., to a wrongly- authenticated person. However, suppose someone used an Internal Revenue Service 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 Internal Revenue Service certificate. The Internal Revenue Service may want to protect itself against claims for damages in such circumstances. The critical-flagged Certificate Policies extension is intended to mitigate the risk to the certificate issuer in such situations. 3.3.2 Policy Mappings Extension The Policy Mappings extension may only be used in CA-certificates. 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 (EDI). 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 with 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 may be 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). Chokhani & Ford Informational [Page 7] RFC 2527 PKIX March 1999 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 that explicit certificate policy indications 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. Such certificates need not contain explicit indications of certificate policy. However, when a certification authority in the trusted domain certifies outside the domain, it can activate the requirement for explicit certificate policy in subsequent certificates in the certification path. The other optional feature in the Policy Constraints field is the ability for a certification authority to disable policy mapping by subsequent certification authorities in a certification path. It may be prudent to disable policy mapping when certifying outside the domain. This can assist in controlling risks due to transitive trust, e.g., a domain A trusts domain B, domain B trusts domain C, but domain A does not want to be forced to trust domain C. 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. The following policy qualifier types are defined in PKIX Part I [PKI1]: (a) The CPS Pointer qualifier contains a pointer to a Certification Practice Statement (CPS) published by the CA. The pointer is in the form of a uniform resource identifier (URI). (b) The User Notice qualifier contains a text string that is to be displayed to a certificate user (including subscribers and relying parties) prior to the use of the certificate. The text string may be an IA5String or a BMPString - a subset of the ISO 100646-1 multiple octet coded character set. A CA may invoke a procedure that requires that the certficate user acknowledge that the applicable terms and conditions have been disclosed or accepted. Chokhani & Ford Informational [Page 8] RFC 2527 PKIX March 1999 Policy qualifiers can be used to support the definition of generic, or parameterized, certificate policy definitions. Provided the base certificate policy definition so provides, policy qualifier types can be defined to convey, on a per-certificate basis, additional specific policy details that fill in the generic definition. 3.5 CERTIFICATION PRACTICE STATEMENT The term certification practice statement (CPS) is defined by the ABA Guidelines as: "A statement of the practices which a certification authority employs in issuing certificates." [ABA1] 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. 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 Chokhani & Ford Informational [Page 9] RFC 2527 PKIX March 1999 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. 3.6 RELATIONSHIP BETWEEN CERTIFICATE POLICY AND CERTIFICATION PRACTICE STATEMENT The concepts of certificate policy and CPS come from different sources and were developed for different reasons. However, their interrelationship is important. 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). Although the level of detail may vary among CPSs, they will generally be more detailed than certificate policy definitions. Indeed, CPSs may be quite comprehensive, robust documents providing a description of the precise service offerings, detailed procedures of the life-cycle management of certificates, and more - a level of detail which weds the CPS to a particular (proprietary) implementation of a service offering. Although such detail may be indispensable to adequately disclose, and to make a full assessment of trustworthiness in the absence of accreditation or other recognized quality metrics, a detailed CPS does not form a suitable basis for interoperability between CAs operated by different organizations. Rather, certificate policies best serve as the vehicle on which to base common interoperability standards and common assurance criteria on an industry-wide (or possibly more global) basis. A CA with a single CPS may support multiple certificate policies (used for different application purposes and/or by different certificate user communities). Also, multiple different CAs, with non-identical certification practice statements, may support the same certificate policy. For example, the Federal Government 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. Chokhani & Ford Informational [Page 10] RFC 2527 PKIX March 1999 The main difference between certificate policy and CPS can therefore be summarized as follows: (a) Most organizations that operate public or inter- organizational certification authorities will document their own practices in CPSs or similar statements. The CPS is one of the organization's means of protecting itself and positioning its business relationships with subscribers and other entities. (b) There is strong incentive, on the other hand, for a certificate policy to apply more broadly than to just a single organization. If a particular certificate policy is widely recognized and imitated, it has great potential as the basis of automated certificate acceptance in many systems, including unmanned systems and systems that are manned by people not independently empowered to determine the acceptability of different presented certificates. 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 SET OF PROVISIONS A set of provisions is a collection of practice and/or policy statements, spanning a range of standard topics, for use in expressing a certificate policy definition or CPS employing the approach described in this framework. A certificate policy can be expressed as a single set of provisions. A CPS can be expressed as a single set of provisions with each component addressing the requirements of one or more certificate policies, or, alternatively, as an organized collection of sets of provisions. For example, a CPS could be expressed as a combination of the following: (a) a list of certificate policies supported by the CPS; (b) for each certificate policy in (a), a set of provisions which contains statements that refine that certificate policy by filling in details not stipulated in that policy or expressly left to the discretion of the CPS by that certificate policy; such statements serve to state how this particular CPS implements the requirements of the particular certificate Chokhani & Ford Informational [Page 11] RFC 2527 PKIX March 1999 policy; (c) a set of provisions that contains statements regarding the certification practices on the CA, regardless of certificate policy. The statements provided in (b) and (c) may augment or refine the stipulations of the applicable certificate policy definition, but must not conflict with any of the stipulations of such certificate policy definition. This framework outlines the contents of a set of provisions, in terms of eight primary components, as follows: * Introduction; * General Provisions; * Identification and Authentication; * Operational Requirements; * Physical, Procedural, and Personnel Security Controls; * Technical Security Controls; * Certificate and CRL Profile; and * Specification Administration. Components can be further divided into subcomponents, and a subcomponent may comprise multiple elements. Section 4 provides a more detailed description of the contents of the above components, and their subcomponents. 4. CONTENTS OF A SET OF PROVISIONS This section expands upon the contents of a set of provisions, as introduced in Section 3.7. The topics identified in this section are, consequently, candidate topics for inclusion in a certificate policy definition or CPS. While many topics are identified, it is not necessary for a certificate policy or a CPS to include a concrete statement for every such topic. Rather, a particular certificate policy or CPS may state "no stipulation" for a component, subcomponent, or element on which the particular certificate policy or CPS imposes no requirements. In this sense, the list of topics can be considered a checklist of Chokhani & Ford Informational [Page 12] RFC 2527 PKIX March 1999 topics for consideration by the certificate policy or CPS writer. It is recommended that each and every component and subcomponent be included in a certificate policy or CPS, even if there is "no stipulation"; this will indicate to the reader that a conscious decision was made to include or exclude that topic. This protects against inadvertent omission of a topic, while facilitating comparison of different certificate policies or CPSs, e.g., when making policy mapping decisions. In a certificate policy definition, it is possible to leave certain components, subcomponents, and/or elements unspecified, and to stipulate that the required information will be indicated in a policy qualifier. Such certificate policy definitions can be considered parameterized definitions. The set of provisions should reference or define the required policy qualifier types and should specify any applicable default values. 4.1 INTRODUCTION This component identifies and introduces the set of provisions, and indicates the types of entities and applications for which the specification is targeted. This component has the following subcomponents: * Overview; * Identification; * Community and Applicability; and * Contact Details. 4.1.1 Overview This subcomponent provides a general introduction to the specification. 4.1.2 Identification This subcomponent provides any applicable names or other identifiers, including ASN.1 object identifiers, for the set of provisions. 4.1.3 Community and Applicability This subcomponent describes the types of entities that issue certificates or that are certified as subject CAs (2, 3), the types of entities that perform RA functions (4), and the types of entities Chokhani & Ford Informational [Page 13] RFC 2527 PKIX March 1999 that are certified as subject end entities or subscribers. (5, 6) This subcomponent also contains: * A list of applications for which the issued certificates are suitable. (Examples of application in this case are: electronic mail, retail transactions, contracts, travel order, etc.) * A list of applications for which use of the issued certificates is restricted. (This list implicitly prohibits all other uses for the certificates.) * A list of applications for which use of the issued certificates is prohibited. 4.1.4 Contact Details This subcomponent includes the name and mailing address of the authority that is responsible for the registration, maintenance, and interpretation of this certificate policy or CPS. It also includes the name, electronic mail address, telephone number, and fax number of a contact person. 4.2 GENERAL PROVISIONS This component specifies any applicable presumptions on a range of legal and general practices topics. This component contains the following subcomponents: * Obligations; * Liability; * Financial Responsibility; * Interpretation and Enforcement; * Fees; * Publication and Repositories; * Compliance Audit; * Confidentiality; and * Intellectual Property Rights. Chokhani & Ford Informational [Page 14] RFC 2527 PKIX March 1999 Each subcomponent may need to separately state provisions applying to the entity types: CA, repository, RA, subscriber, and relying party. (Specific provisions regarding subscribers and relying parties are only applicable in the Liability and Obligations subcomponents.) 4.2.1 Obligations This subcomponent contains, for each entity type, any applicable provisions regarding the entity's obligations to other entities. Such provisions may include: * CA and/or RA obligations: * Notification of issuance of a certificate to the subscriber who is the subject of the certificate being issued; * Notification of issuance of a certificate to others than the subject of the certificate; * Notification of revocation or suspension of a certificate to the subscriber whose certificate is being revoked or suspended; and * Notification of revocation or suspension of a certificate to others than the subject whose certificate is being revoked or suspended. * Subscriber obligations: * Accuracy of representations in certificate application; * Protection of the entity's private key; * Restrictions on private key and certificate use; and * Notification upon private key compromise. * Relying party obligations: * Purposes for which certificate is used; * Digital signature verification responsibilities; * Revocation and suspension checking responsibilities; and * Acknowledgment of applicable liability caps and warranties. * Repository obligations * Timely publication of certificates and revocation information Chokhani & Ford Informational [Page 15] RFC 2527 PKIX March 1999 4.2.2 Liability This subcomponent contains, for each entity type, any applicable provisions regarding apportionment of liability, such as: * Warranties and limitations on warranties; * Kinds of damages covered (e.g., indirect, special, consequential, incidental, punitive, liquidated damages, negligence and fraud) and disclaimers; * Loss limitations (caps) per certificate or per transaction; and * Other exclusions (e.g., Acts of God, other party responsibilities). 4.2.3 Financial Responsibility This subcomponent contains, for CAs, repository, and RAs, any applicable provisions regarding financial responsibilities, such as: * Indemnification of CA and/or RA by relying parties; * Fiduciary relationships (or lack thereof) between the various entities; and * Administrative processes (e.g., accounting, audit). 4.2.4 Interpretation and Enforcement This subcomponent contains any applicable provisions regarding interpretation and enforcement of the certificate policy or CPS, addressing such topics as: * Governing law; * Severability of provisions, survival, merger, and notice; and * Dispute resolution procedures. 4.2.5 Fees This subcomponent contains any applicable provisions regarding fees charged by CAs, repositories, or RAs, such as: * Certificate issuance or renewal fees; * Certificate access fee; Chokhani & Ford Informational [Page 16] RFC 2527 PKIX March 1999 * Revocation or status information access fee; * Fees for other services such as policy information; and * Refund policy. 4.2.6 Publication and Repositories This subcomponent contains any applicable provisions regarding: * A CA's obligations to publish information regarding its practices, its certificates, and the current status of such certificates; * Frequency of publication; * Access control on published information objects including certificate policy definitions, CPS, certificates, certificate status, and CRLs; and * Requirements pertaining to the use of repositories operated by CAs or by other independent parties. 4.2.7 Compliance Audit This subcomponent addresses the following: * Frequency of compliance audit for each entity; * Identity/qualifictions of the auditor; * Auditor'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 they are shared with (e.g., subject CA, RA, and/or end entities), who provides them (e.g., entity being audited or auditor), how they are communicated. Chokhani & Ford Informational [Page 17] RFC 2527 PKIX March 1999 4.2.8 Confidentiality Policy This subcomponent addresses the following: * Types of information that must be kept confidential by CA or RA; * Types of information that are not considered confidential; * Who is entitled to be informed of reasons for revocation and suspension of certificates; * Policy on release of information to law enforcement officials; * Information that can be revealed as part of civil discovery; * Conditions upon which CA or RA may disclose upon owner's request; and * Any other circumstances under which confidential information may be disclosed. 4.2.9 Intellectual Property Rights This subcomponent addresses ownership rights of certificates, practice/policy specifications, names, and keys. 4.3 IDENTIFICATION AND AUTHENTICATION This component describes the procedures used to authenticate a certificate applicant to a CA or RA prior to certificate issuance. It also describes how parties requesting rekey or revocation are authenticated. This component also addresses naming practices, including name ownership recognition and name dispute resolution. This component has the following subcomponents: * Initial Registration; * Routine Rekey; * Rekey After Revocation; and * Revocation Request. Chokhani & Ford Informational [Page 18] RFC 2527 PKIX March 1999 4.3.1 Initial Registration This subcomponent includes the following elements regarding identification and authentication procedures during entity registration or certificate issuance: * 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; * Recognition, authentication, and role of trademarks; * If and how the subject must prove possession of 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 a subject (CA, RA, or end entity) (11), including: * Number of pieces of identification required; * How a CA or RA validates the pieces of identification provided; * If the individual must present personally to the authenticating CA or RA; * How an individual as an organizational person is authenticated (12). 4.3.2 Routine Rekey This subcomponent describes the identification and authentication procedures for routine rekey for each subject type (CA, RA, and end entity). (13) 4.3.3 Rekey After Revocation -- No Key Compromise This subcomponent describes the identification and authentication procedures for rekey for each subject type (CA, RA, and end entity) after the subject certificate has been revoked. (14) Chokhani & Ford Informational [Page 19] RFC 2527 PKIX March 1999 4.3.4 Revocation Request This subcomponent describes the identification and authentication procedures for a revocation request by each subject type (CA, RA, and end entity). (16) 4.4 OPERATIONAL REQUIREMENTS This component is used to specify requirements imposed upon issuing CA, subject CAs, RAs, or end entities with respect to various operational activities. This component consists of the following subcomponents: * Certificate Application; * Certificate Issuance; * Certificate Acceptance; * Certificate Suspension and Revocation; * Security Audit Procedures; * Records Archival; * Key Changeover; * Compromise and Disaster Recovery; and * CA Termination. Within each subcomponent, separate consideration may need to be given to issuing CA, repository, subject CAs, RAs, and end entities. 4.4.1 Certificate Application This subcomponent is used to state requirements regarding subject enrollment and request for certificate issuance. 4.4.2 Certificate Issuance This subcomponent is used to state requirements regarding issuance of a certificate and notification to the applicant of such issuance. Chokhani & Ford Informational [Page 20] RFC 2527 PKIX March 1999 4.4.3 Certificate Acceptance This subcomponent is used to state requirements regarding acceptance of an issued certificate and for consequent publication of certificates. 4.4.4 Certificate Suspension and Revocation This subcomponent addresses the following: * Circumstances under which a 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 subject; * Circumstances under which a certificate may be suspended; * Who can request the suspension of a certificate; * Procedures to request certificate suspension; * How long the suspension may last; * If a CRL mechanism is used, the issuance frequency; * Requirements on relying parties to check CRLs; * On-line revocation/status checking availability; * Requirements on relying parties to perform on-line revocation/status checks; * Other forms of revocation advertisements available; and * Requirements on relying parties to check other forms of revocation advertisements. * Any variations on the above stipulations when the suspension or revocation is the result of private key compromise (as opposed to other reasons for suspension or revocation). Chokhani & Ford Informational [Page 21] RFC 2527 PKIX March 1999 4.4.5 Security Audit Procedures This subcomponent is used to describe event logging and audit systems, implemented for the purpose of maintaining a secure environment. Elements include the following: * Types of events recorded; (28) * Frequency with which audit logs are processed or audited; * Period for which audit logs are kept; * Protection of audit logs: - Who can view audit logs; - Protection against modification of audit log; and - Protection against deletion of audit log. * Audit log back up procedures; * Whether the audit log accumulation system is internal or external to the entity; * Whether the subject who caused an audit event to occur is notified of the audit action; and * Vulnerability assessments. 4.4.6 Records Archival This subcomponent is used to describe general records archival (or records retention) policies, including the following: * Types of events recorded; (29) * Retention period for archive; * Protection of archive: - Who can view the archive; - Protection against modification of archive; and - Protection against deletion of archive. * Archive backup procedures; * Requirements for time-stamping of records; * Whether the archive collection system is internal or external; Chokhani & Ford Informational [Page 22] RFC 2527 PKIX March 1999 and * Procedures to obtain and verify archive information. 4.4.7 Key Changeover This subcomponent describes the procedures to provide a new public key to a CA's users. 4.4.8 Compromise and Disaster Recovery This subcomponent describes requirements relating to notification and recovery procedures in the event of compromise or disaster. Each of the following circumstances may need to be addressed separately: * The recovery procedures used if computing resources, software, and/or data are corrupted or suspected to be corrupted. These procedures describe how a secure environment is reestablished, which certificates are revoked, whether the entity key is revoked, how the new entity public key is provided to the users, and how the 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. * The CA's procedures for securing i