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.
AbstractThis 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.
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]
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.
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). 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
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.
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
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.
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.
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. 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
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.
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.
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. 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
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.
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.
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.)
* Revocation or status information access fee; * Fees for other services such as policy information; and * Refund policy.
and * Procedures to obtain and verify archive information.
* Off-site backup.
and end entities to protect their cryptographic keys and critical security parameters. Secure key management is critical to ensure that all secret and private keys and activation data are protected and used only by authorized personnel. This component also describes other technical security controls used by the issuing CA to perform securely the functions of key generation, user authentication, certificate registration, certificate revocation, audit, and archival. Technical controls include life-cycle security controls (including software development environment security, trusted software development methodology) and operational security controls. This component can also be used to define other technical security controls on repositories, subject CAs, RAs, and end entities. This component has the following subcomponents: * Key Pair Generation and Installation; * Private Key Protection; * Other Aspects of Key Pair Management; * Activation Data; * Computer Security Controls; * Life-Cycle Security Controls; * Network Security Controls; and * Cryptographic Module Engineering Controls.
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, or for what purposes should usage of the key be restricted (for X.509 certificates, these purposes should map to the key usage flags in the Version 3, X.509 certificates)?
6. Who enters the private key in the cryptographic module? In what form (i.e., plaintext, encrypted, or split key)? 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 might include, logout, power off, remove token/key, automatic, or time expiration. 9. Who can destroy the private key and how? Examples of how might include token surrender, token destruction, or key overwrite.
pointer (URL). The procedures to be used to notify interested parties (relying parties, certification authorities, etc.) of the certificate policy or CPS changes are 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 specification components, subcomponents, and/or elements, changes to which require a change in certificate policy Object Identifier or CPS pointer (URL)..
1. INTRODUCTION 1.1 Overview 1.2 Identification 1.3 Community and Applicability 1.3.1 Certification authorities 1.3.2 Registration authorities 1.3.3 End entities 1.3.4 Applicability 1.4 Contact Details 1.4.1 Specification administration organization 1.4.2 Contact person 1.4.3 Person determining CPS suitability for the policy 2. GENERAL PROVISIONS 2.1 Obligations 2.1.1 CA obligations 2.1.2 RA obligations 2.1.3 Subscriber obligations 2.1.4 Relying party obligations 2.1.5 Repository obligations 2.2 Liability 2.2.1 CA liability 2.2.2 RA liability 2.3 Financial responsibility 2.3.1 Indemnification by relying parties 2.3.2 Fiduciary relationships 2.3.3 Administrative processes 2.4 Interpretation and Enforcement 2.4.1 Governing law 2.4.2 Severability, survival, merger, notice 2.4.3 Dispute resolution procedures 2.5 Fees 2.5.1 Certificate issuance or renewal fees 2.5.2 Certificate access fees
2.5.3 Revocation or status information access fees 2.5.4 Fees for other services such as policy information 2.5.5 Refund policy 2.6 Publication and Repository 2.6.1 Publication of CA information 2.6.2 Frequency of publication 2.6.3 Access controls 2.6.4 Repositories 2.7 Compliance audit 2.7.1 Frequency of entity compliance audit 2.7.2 Identity/qualifications of auditor 2.7.3 Auditor's relationship to audited party 2.7.4 Topics covered by audit 2.7.5 Actions taken as a result of deficiency 2.7.6 Communication of results 2.8 Confidentiality 2.8.1 Types of information to be kept confidential 2.8.2 Types of information not considered confidential 2.8.3 Disclosure of certificate revocation/suspension information 2.8.4 Release to law enforcement officials 2.8.5 Release as part of civil discovery 2.8.6 Disclosure upon owner's request 2.8.7 Other information release circumstances 2.9 Intellectual Property Rights 3. IDENTIFICATION AND AUTHENTICATION (34) 3.1 Initial Registration 3.1.1 Types of names 3.1.2 Need for names to be meaningful 3.1.3 Rules for interpreting various name forms 3.1.4 Uniqueness of names 3.1.5 Name claim dispute resolution procedure 3.1.6 Recognition, authentication and role of trademarks 3.1.7 Method to prove possession of private key 3.1.8 Authentication of organization identity 3.1.9 Authentication of individual identity 3.2 Routine Rekey 3.3 Rekey after Revocation
3.4 Revocation Request 4. OPERATIONAL REQUIREMENTS (34) 4.1 Certificate Application 4.2 Certificate Issuance 4.3 Certificate Acceptance 4.4 Certificate Suspension and Revocation 4.4.1 Circumstances for revocation 4.4.2 Who can request revocation 4.4.3 Procedure for revocation request 4.4.4 Revocation request grace period 4.4.5 Circumstances for suspension 4.4.6 Who can request suspension 4.4.7 Procedure for suspension request 4.4.8 Limits on suspension period 4.4.9 CRL issuance frequency (if applicable) 4.4.10 CRL checking requirements 4.4.11 On-line revocation/status checking availability 4.4.12 On-line revocation checking requirements 4.4.13 Other forms of revocation advertisements available 4.4.14 Checking requirements for other forms of revocation advertisements 4.4.15 Special requirements re key compromise 4.5 Security Audit Procedures 4.5.1 Types of event recorded 4.5.2 Frequency of processing log 4.5.3 Retention period for audit log 4.5.4 Protection of audit log 4.5.5 Audit log backup procedures 4.5.6 Audit collection system (internal vs external) 4.5.7 Notification to event-causing subject 4.5.8 Vulnerability assessments 4.6 Records Archival 4.6.1 Types of event recorded 4.6.2 Retention period for archive 4.6.3 Protection of archive 4.6.4 Archive backup procedures 4.6.5 Requirements for time-stamping of records 4.6.6 Archive collection system (internal or external) 4.6.7 Procedures to obtain and verify archive information
4.7 Key changeover 4.8 Compromise and Disaster Recovery 4.8.1 Computing resources, software, and/or data are corrupted 4.8.2 Entity public key is revoked 4.8.3 Entity key is compromised 4.8.4 Secure facility after a natural or other type of disaster 4.9 CA Termination 5. PHYSICAL, PROCEDURAL, AND PERSONNEL SECURITY CONTROLS (34) 5.1 Physical Controls 5.1.1 Site location and construction 5.1.2 Physical access 5.1.3 Power and air conditioning 5.1.4 Water exposures 5.1.5 Fire prevention and protection 5.1.6 Media storage 5.1.7 Waste disposal 5.1.8 Off-site backup 5.2 Procedural Controls 5.2.1 Trusted roles 5.2.2 Number of persons required per task 5.2.3 Identification and authentication for each role 5.3 Personnel Controls 5.3.1 Background, qualifications, experience, and clearance requirements 5.3.2 Background check procedures 5.3.3 Training requirements 5.3.4 Retraining frequency and requirements 5.3.5 Job rotation frequency and sequence 5.3.6 Sanctions for unauthorized actions 5.3.7 Contracting personnel requirements 5.3.8 Documentation supplied to personnel 6. TECHNICAL SECURITY CONTROLS (34) 6.1 Key Pair Generation and Installation 6.1.1 Key pair generation 6.1.2 Private key delivery to entity 6.1.3 Public key delivery to certificate issuer 6.1.4 CA public key delivery to users 6.1.5 Key sizes 6.1.6 Public key parameters generation 6.1.7 Parameter quality checking
6.1.8 Hardware/software key generation 6.1.9 Key usage purposes (as per X.509 v3 key usage field) 6.2 Private Key Protection 6.2.1 Standards for cryptographic module 6.2.2 Private key (n out of m) multi-person control 6.2.3 Private key escrow 6.2.4 Private key backup 6.2.5 Private key archival 6.2.6 Private key entry into cryptographic module 6.2.7 Method of activating private key 6.2.8 Method of deactivating private key 6.2.9 Method of destroying private key 6.3 Other Aspects of Key Pair Management 6.3.1 Public key archival 6.3.2 Usage periods for the public and private keys 6.4 Activation Data 6.4.1 Activation data generation and installation 6.4.2 Activation data protection 6.4.3 Other aspects of activation data 6.5 Computer Security Controls 6.5.1 Specific computer security technical requirements 6.5.2 Computer security rating 6.6 Life Cycle Technical Controls 6.6.1 System development controls 6.6.2 Security management controls 6.6.3 Life cycle security ratings 6.7 Network Security Controls 6.8 Cryptographic Module Engineering Controls 7. CERTIFICATE AND CRL PROFILES 7.1 Certificate Profile 7.1.1 Version number(s) 7.1.2 Certificate extensions 7.1.3 Algorithm object identifiers 7.1.4 Name forms 7.1.5 Name constraints 7.1.6 Certificate policy Object Identifier 7.1.7 Usage of Policy Constraints extension 7.1.8 Policy qualifiers syntax and semantics
7.1.9 Processing semantics for the critical certificate policy extension 7.2 CRL Profile 7.2.1 Version number(s) 7.2.2 CRL and CRL entry extensions 8. SPECIFICATION ADMINISTRATION 8.1 Specification change procedures 8.2 Publication and notification policies 8.3 CPS approval procedures
[ABA1] American Bar Association, Digital Signature Guidelines: Legal Infrastructure for Certification Authorities and Electronic Commerce, 1995. [BAU1] Michael. S. Baum, Federal Certification Authority Liability and Policy, NIST-GCR- 94-654, June 1994. [ISO1] ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information Technology - Open Systems Interconnection: The Directory: Authentication Framework," 1997 edition. (Pending publication of 1997 edition, use 1993 edition with the following amendment applied: Final Text of Draft Amendment DAM 1 to ISO/IEC 9594-8 on Certificate Extensions, June 1996.) [PEM1] Kent, S., "Privacy Enhancement for Internet Electronic Mail, Part II: Certificate-Based Key Management", RFC 1422, February 1993. [PKI1] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure, Certificate and CRL Profile", RFC 2459, January 1999.
NOTES 1 The ABA Digital Signature Guidelines can be purchased from the ABA. See http://www.abanet.com for ordering details. 2 Examples of types of entity for subject CAs are a subordinate organization (e.g., branch or division), a federal government agency, or a state or provincial government department. 3 This statement can have significant implications. For example, suppose 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 4 Examples of the types of subject RA entities are branch and division of an organization. 5 Examples of types of subject end entities are bank customers, telephone company subscribers, and employees of a government department 6 This statement can have significant implications. For example, suppose 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. 7 Examples include X.500 distinguished name, Internet e-mail address, and URL. 8 The term "meaningful" means that the name form has commonly understood semantics to determine identity of the person and/or organization. Directory names and RFC 822 names may be more or less meaningful. 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 or corporate ID badge. 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 identification and authentication policy could be the same as that 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 that 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 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 An example of activation data is a PIN or passphrase. 21 Examples of physical access controls are: monitored facility , guarded facility, locked facility, access controlled using tokens,
access controlled using biometrics, and access controlled through an access list. 22 Examples of the roles include system administrator, system security officer, and system auditor. 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. 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. 25 Regardless of whether authorized persons are employees, practices should be implemented to ensure that each authorized person is held 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. LIST OF ACRONYMS ABA - American Bar Association CA - Certification Authority CPS - Certification Practice Statement CRL - Certificate Revocation List DAM - Draft Amendment FIPS - Federal Information Processing Standard I&A - Identification and Authentication IEC - International Electrotechnical Commission IETF - Internet Engineering Task Force IP - Internet Protocol ISO - International Organization for Standardization ITU - International Telecommunications Union NIST - National Institute of Standards and Technology OID - Object Identifier PIN - Personal Identification Number PKI - Public Key Infrastructure PKIX - Public Key Infrastructure (X.509) (IETF Working Group) RA - Registration Authority RFC - Request For Comment URL - Uniform Resource Locator US - United States
Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.