Network Working Group S. Chokhani
Request for Comments: 3647 Orion Security Solutions, Inc.
Obsoletes: 2527 W. Ford
Category: Informational VeriSign, Inc.
R. Sabett
Cooley Godward LLP
C. Merrill
McCarter & English, LLP
S. Wu
Infoliance, Inc.
November 2003
Network Working Group S. Chokhani
Request for Comments: 3647 Orion Security Solutions, Inc.
Obsoletes: 2527 W. Ford
Category: Informational VeriSign, Inc.
R. Sabett
Cooley Godward LLP
C. Merrill
McCarter & English, LLP
S. Wu
Infoliance, Inc.
November 2003
Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework
Internet X.509公钥基础设施证书政策和认证实践框架
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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document presents a framework to assist the writers of certificate policies or certification practice statements for participants within public key infrastructures, such as certification authorities, policy authorities, and communities of interest that wish to rely on certificates. 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 or a certification practice statement. This document supersedes RFC 2527.
本文件提供了一个框架，以帮助公钥基础设施（如认证机构、政策机构和希望依赖证书的利益团体）中的参与者编写证书政策或认证实践声明。特别是，该框架提供了一个全面的主题列表，这些主题可能（由作者自行决定）需要包含在证书政策或认证实践声明中。本文件取代RFC 2527。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Purpose. . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Scope. . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Certificate Policy . . . . . . . . . . . . . . . . . . . 9
3.2. Certificate Policy Examples. . . . . . . . . . . . . . . 11
3.3. X.509 Certificate Fields . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Purpose. . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Scope. . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Certificate Policy . . . . . . . . . . . . . . . . . . . 9
3.2. Certificate Policy Examples. . . . . . . . . . . . . . . 11
3.3. X.509 Certificate Fields . . . . . . . . . . . . . . . . 12
3.3.1. Certificate Policies Extension . . . . . . . . . 12
3.3.2. Policy Mappings Extension. . . . . . . . . . . . 13
3.3.3. Policy Constraints Extension . . . . . . . . . . 13
3.3.4. Policy Qualifiers. . . . . . . . . . . . . . . . 14
3.4. Certification Practice Statement . . . . . . . . . . . . 15
3.5. Relationship Between CP and CPS. . . . . . . . . . . . . 16
3.6. Relationship Among CPs, CPSs, Agreements, and
Other Documents. . . . . . . . . . . . . . . . . . . . . 17
3.7. Set of Provisions. . . . . . . . . . . . . . . . . . . . 20
4. Contents of a Set of Provisions. . . . . . . . . . . . . . . . 21
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 22
4.1.1. Overview . . . . . . . . . . . . . . . . . . . . 22
4.1.2. Document Name and Identification . . . . . . . . 22
4.1.3. PKI Participants . . . . . . . . . . . . . . . . 23
4.1.4. Certificate Usage. . . . . . . . . . . . . . . . 24
4.1.5. Policy Administration. . . . . . . . . . . . . . 24
4.1.6. Definitions and Acronyms . . . . . . . . . . . . 24
4.2. Publication and Repository Responsibilities. . . . . . . 25
4.3. Identification and Authentication (I&A). . . . . . . . . 25
4.3.1. Naming . . . . . . . . . . . . . . . . . . . . . 25
4.3.2. Initial Identity Validation. . . . . . . . . . . 26
4.3.3. I&A for Re-key Requests. . . . . . . . . . . . . 27
4.3.4. I&A for Revocation Requests. . . . . . . . . . . 27
4.4. Certificate Life-Cycle Operational Requirements. . . . . 27
4.4.1. Certificate Application. . . . . . . . . . . . . 28
4.4.2. Certificate Application Processing . . . . . . . 28
4.4.3. Certificate Issuance . . . . . . . . . . . . . . 28
4.4.4. Certificate Acceptance . . . . . . . . . . . . . 29
4.4.5. Key Pair and Certificate Usage . . . . . . . . . 29
4.4.6. Certificate Renewal. . . . . . . . . . . . . . . 30
4.4.7. Certificate Re-key . . . . . . . . . . . . . . . 30
4.4.8. Certificate Modification . . . . . . . . . . . . 31
4.4.9. Certificate Revocation and Suspension. . . . . . 31
4.4.10. Certificate Status Services. . . . . . . . . . . 33
4.4.11. End of Subscription. . . . . . . . . . . . . . . 33
4.4.12. Key Escrow and Recovery. . . . . . . . . . . . . 33
4.5. Facility, Management, and Operational Controls . . . . . 33
4.5.1. Physical Security Controls . . . . . . . . . . . 34
4.5.2. Procedural Controls. . . . . . . . . . . . . . . 35
4.5.3. Personnel Controls . . . . . . . . . . . . . . . 35
4.5.4. Audit Logging Procedures . . . . . . . . . . . . 36
4.5.5. Records Archival . . . . . . . . . . . . . . . . 37
4.5.6. Key Changeover . . . . . . . . . . . . . . . . . 38
4.5.7. Compromise and Disaster Recovery . . . . . . . . 38
4.5.8. CA or RA Termination . . . . . . . . . . . . . . 38
4.6. Technical Security Controls. . . . . . . . . . . . . . . 39
4.6.1. Key Pair Generation and Installation . . . . . . 39
4.6.2. Private Key Protection and Cryptographic
3.3.1. Certificate Policies Extension . . . . . . . . . 12
3.3.2. Policy Mappings Extension. . . . . . . . . . . . 13
3.3.3. Policy Constraints Extension . . . . . . . . . . 13
3.3.4. Policy Qualifiers. . . . . . . . . . . . . . . . 14
3.4. Certification Practice Statement . . . . . . . . . . . . 15
3.5. Relationship Between CP and CPS. . . . . . . . . . . . . 16
3.6. Relationship Among CPs, CPSs, Agreements, and
Other Documents. . . . . . . . . . . . . . . . . . . . . 17
3.7. Set of Provisions. . . . . . . . . . . . . . . . . . . . 20
4. Contents of a Set of Provisions. . . . . . . . . . . . . . . . 21
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 22
4.1.1. Overview . . . . . . . . . . . . . . . . . . . . 22
4.1.2. Document Name and Identification . . . . . . . . 22
4.1.3. PKI Participants . . . . . . . . . . . . . . . . 23
4.1.4. Certificate Usage. . . . . . . . . . . . . . . . 24
4.1.5. Policy Administration. . . . . . . . . . . . . . 24
4.1.6. Definitions and Acronyms . . . . . . . . . . . . 24
4.2. Publication and Repository Responsibilities. . . . . . . 25
4.3. Identification and Authentication (I&A). . . . . . . . . 25
4.3.1. Naming . . . . . . . . . . . . . . . . . . . . . 25
4.3.2. Initial Identity Validation. . . . . . . . . . . 26
4.3.3. I&A for Re-key Requests. . . . . . . . . . . . . 27
4.3.4. I&A for Revocation Requests. . . . . . . . . . . 27
4.4. Certificate Life-Cycle Operational Requirements. . . . . 27
4.4.1. Certificate Application. . . . . . . . . . . . . 28
4.4.2. Certificate Application Processing . . . . . . . 28
4.4.3. Certificate Issuance . . . . . . . . . . . . . . 28
4.4.4. Certificate Acceptance . . . . . . . . . . . . . 29
4.4.5. Key Pair and Certificate Usage . . . . . . . . . 29
4.4.6. Certificate Renewal. . . . . . . . . . . . . . . 30
4.4.7. Certificate Re-key . . . . . . . . . . . . . . . 30
4.4.8. Certificate Modification . . . . . . . . . . . . 31
4.4.9. Certificate Revocation and Suspension. . . . . . 31
4.4.10. Certificate Status Services. . . . . . . . . . . 33
4.4.11. End of Subscription. . . . . . . . . . . . . . . 33
4.4.12. Key Escrow and Recovery. . . . . . . . . . . . . 33
4.5. Facility, Management, and Operational Controls . . . . . 33
4.5.1. Physical Security Controls . . . . . . . . . . . 34
4.5.2. Procedural Controls. . . . . . . . . . . . . . . 35
4.5.3. Personnel Controls . . . . . . . . . . . . . . . 35
4.5.4. Audit Logging Procedures . . . . . . . . . . . . 36
4.5.5. Records Archival . . . . . . . . . . . . . . . . 37
4.5.6. Key Changeover . . . . . . . . . . . . . . . . . 38
4.5.7. Compromise and Disaster Recovery . . . . . . . . 38
4.5.8. CA or RA Termination . . . . . . . . . . . . . . 38
4.6. Technical Security Controls. . . . . . . . . . . . . . . 39
4.6.1. Key Pair Generation and Installation . . . . . . 39
4.6.2. Private Key Protection and Cryptographic
Module Engineering Controls. . . . . . . . . . . 40
4.6.3. Other Aspects of Key Pair Management . . . . . . 42
4.6.4. Activation Data. . . . . . . . . . . . . . . . . 42
4.6.5. Computer Security Controls . . . . . . . . . . . 42
4.6.6. Life Cycle Security Controls . . . . . . . . . . 43
4.6.7. Network Security Controls. . . . . . . . . . . . 43
4.6.8. Timestamping . . . . . . . . . . . . . . . . . . 43
4.7. Certificate, CRL, and OCSP Profiles. . . . . . . . . . . 44
4.7.1. Certificate Profile. . . . . . . . . . . . . . . 44
4.7.2. CRL Profile. . . . . . . . . . . . . . . . . . . 44
4.7.3. OCSP Profile . . . . . . . . . . . . . . . . . . 44
4.8. Compliance Audit and Other Assessment. . . . . . . . . . 45
4.9. Other Business and Legal Matters . . . . . . . . . . . . 45
4.9.1. Fees . . . . . . . . . . . . . . . . . . . . . . 46
4.9.2. Financial Responsibility . . . . . . . . . . . . 47
4.9.3. Confidentiality of Business Information. . . . . 47
4.9.4. Privacy of Personal Information. . . . . . . . . 48
4.9.5. Intellectual Property Rights . . . . . . . . . . 48
4.9.6. Representations and Warranties . . . . . . . . . 48
4.9.7. Disclaimers of Warranties. . . . . . . . . . . . 49
4.9.8. Limitations of Liability . . . . . . . . . . . . 49
4.9.9. Indemnities. . . . . . . . . . . . . . . . . . . 49
4.9.10. Term and Termination . . . . . . . . . . . . . . 50
4.9.11. Individual notices and communications
with participants. . . . . . . . . . . . . . . . 50
4.9.12. Amendments . . . . . . . . . . . . . . . . . . . 50
4.9.13. Dispute Resolution Procedures. . . . . . . . . . 51
4.9.14. Governing Law. . . . . . . . . . . . . . . . . . 51
4.9.15. Compliance with Applicable Law . . . . . . . . . 51
4.9.16. Miscellaneous Provisions . . . . . . . . . . . . 51
4.9.17. Other Provisions . . . . . . . . . . . . . . . . 53
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 53
6. Outline of a Set of Provisions . . . . . . . . . . . . . . . . 53
7. Comparison to RFC 2527 . . . . . . . . . . . . . . . . . . . . 60
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 88
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 88
10. Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
12. List of Acronyms . . . . . . . . . . . . . . . . . . . . . . . 91
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 92
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 94
Module Engineering Controls. . . . . . . . . . . 40
4.6.3. Other Aspects of Key Pair Management . . . . . . 42
4.6.4. Activation Data. . . . . . . . . . . . . . . . . 42
4.6.5. Computer Security Controls . . . . . . . . . . . 42
4.6.6. Life Cycle Security Controls . . . . . . . . . . 43
4.6.7. Network Security Controls. . . . . . . . . . . . 43
4.6.8. Timestamping . . . . . . . . . . . . . . . . . . 43
4.7. Certificate, CRL, and OCSP Profiles. . . . . . . . . . . 44
4.7.1. Certificate Profile. . . . . . . . . . . . . . . 44
4.7.2. CRL Profile. . . . . . . . . . . . . . . . . . . 44
4.7.3. OCSP Profile . . . . . . . . . . . . . . . . . . 44
4.8. Compliance Audit and Other Assessment. . . . . . . . . . 45
4.9. Other Business and Legal Matters . . . . . . . . . . . . 45
4.9.1. Fees . . . . . . . . . . . . . . . . . . . . . . 46
4.9.2. Financial Responsibility . . . . . . . . . . . . 47
4.9.3. Confidentiality of Business Information. . . . . 47
4.9.4. Privacy of Personal Information. . . . . . . . . 48
4.9.5. Intellectual Property Rights . . . . . . . . . . 48
4.9.6. Representations and Warranties . . . . . . . . . 48
4.9.7. Disclaimers of Warranties. . . . . . . . . . . . 49
4.9.8. Limitations of Liability . . . . . . . . . . . . 49
4.9.9. Indemnities. . . . . . . . . . . . . . . . . . . 49
4.9.10. Term and Termination . . . . . . . . . . . . . . 50
4.9.11. Individual notices and communications
with participants. . . . . . . . . . . . . . . . 50
4.9.12. Amendments . . . . . . . . . . . . . . . . . . . 50
4.9.13. Dispute Resolution Procedures. . . . . . . . . . 51
4.9.14. Governing Law. . . . . . . . . . . . . . . . . . 51
4.9.15. Compliance with Applicable Law . . . . . . . . . 51
4.9.16. Miscellaneous Provisions . . . . . . . . . . . . 51
4.9.17. Other Provisions . . . . . . . . . . . . . . . . 53
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 53
6. Outline of a Set of Provisions . . . . . . . . . . . . . . . . 53
7. Comparison to RFC 2527 . . . . . . . . . . . . . . . . . . . . 60
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 88
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 88
10. Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
12. List of Acronyms . . . . . . . . . . . . . . . . . . . . . . . 91
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 92
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 94
In general, a public-key certificate (hereinafter "certificate") binds a public key held by an entity (such as person, organization, account, device, or site) to a set of information that identifies the entity associated with use of the corresponding private key. In most cases involving identity certificates, this entity is known as the "subject" or "subscriber" of the certificate. Two exceptions, however, include devices (in which the subscriber is usually the individual or organization controlling the device) and anonymous certificates (in which the identity of the individual or organization is not available from the certificate itself). Other types of certificates bind public keys to attributes of an entity other than the entity's identity, such as a role, a title, or creditworthiness information.
通常，公钥证书（以下简称“证书”）将实体（例如个人、组织、帐户、设备或站点）持有的公钥绑定到一组信息，这些信息标识与使用相应私钥相关的实体。在大多数涉及身份证书的情况下，该实体称为证书的“主体”或“订阅者”。但是，有两种例外情况包括设备（其中订户通常是控制设备的个人或组织）和匿名证书（其中个人或组织的身份无法从证书本身获得）。其他类型的证书将公钥绑定到实体身份以外的实体属性，例如角色、头衔或信誉信息。
A certificate is used by a "certificate user" or "relying party" that needs to use, and rely upon the accuracy of, the binding between the subject public key distributed via that certificate and the identity and/or other attributes of the subject contained in that certificate. A relying party is frequently an entity that verifies a digital signature from the certificate's subject where the digital signature is associated with an email, web form, electronic document, or other data. Other examples of relying parties can include a sender of encrypted email to the subscriber, a user of a web browser relying on a server certificate during a secure sockets layer (SSL) session, and an entity operating a server that controls access to online information using client certificates as an access control mechanism. In summary, a relying party is an entity that uses a public key in a certificate (for signature verification and/or encryption). The degree to which a relying party can trust the binding embodied in a certificate depends on several factors. These factors can include the practices followed by the certification authority (CA) in authenticating the subject; the CA's operating policy, procedures, and security controls; the scope of the subscriber's responsibilities (for example, in protecting the private key); and the stated responsibilities and liability terms and conditions of the CA (for example, warranties, disclaimers of warranties, and limitations of liability).
证书由“证书用户”或“依赖方”使用，需要使用并依赖于通过该证书分发的主体公钥与该证书中包含的主体身份和/或其他属性之间的绑定的准确性。依赖方通常是验证证书主体的数字签名的实体，其中数字签名与电子邮件、web表单、电子文档或其他数据关联。依赖方的其他示例可以包括向订阅者发送加密电子邮件的发送者、在安全套接字层（SSL）会话期间依赖服务器证书的web浏览器的用户以及操作服务器的实体，该服务器使用客户端证书作为访问控制机制来控制对在线信息的访问。总之，依赖方是在证书中使用公钥（用于签名验证和/或加密）的实体。依赖方对证书中包含的约束的信任程度取决于几个因素。这些因素包括认证机构（CA）在认证主体时遵循的实践；CA的操作政策、程序和安全控制；订户的责任范围（例如，保护私钥）；以及CA规定的责任和责任条款和条件（例如，保证、保证免责声明和责任限制）。
A Version 3 X.509 certificate may contain a field declaring that one or more specific certificate policies apply to that certificate [ISO1]. According to X.509, a certificate policy (CP) is "a named set of rules that indicates the applicability of a certificate to a particular community and/or class of applications with common security requirements." A CP may be used by a relying party to help
版本3 X.509证书可能包含一个字段，声明一个或多个特定的证书策略应用于该证书[ISO1]。根据X.509，证书策略（CP）是“一组指定的规则，表明证书适用于具有共同安全要求的特定社区和/或应用程序类别。”依赖方可以使用CP来提供帮助
in deciding whether a certificate, and the binding therein, are sufficiently trustworthy and otherwise appropriate for a particular application. The CP concept is an outgrowth of the policy statement concept developed for Internet Privacy Enhanced Mail [PEM1] and expanded upon in [BAU1]. The legal and liability aspects presented in Section 4.9 are outcomes of a collaborative effort between IETF PKIX working group and the American Bar Association (ABA) members who have worked on legal acceptance of digital signature and role of PKI in that acceptance.
在决定证书及其绑定是否足够可信以及是否适合于特定应用时。CP概念是针对互联网隐私增强邮件[PEM1]开发的政策声明概念的产物，并在[BAU1]中进行了扩展。第4.9节中介绍的法律和责任方面是IETF PKIX工作组和美国律师协会（ABA）成员之间合作的结果，这些成员致力于数字签名的法律接受以及PKI在接受中的作用。
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 Information Security Committee's Digital Signature Guidelines (hereinafter "DSG")(1) and the Information Security Committee's PKI Assessment Guidelines (hereinafter "PAG")(2), "a CPS is a statement of the practices which a certification authority employs in issuing certificates." [ABA1, ABA2] In general, CPSs also describe practices relating to all certificate lifecycle services (e.g., issuance, management, revocation, and renewal or re-keying), and CPSs provide details concerning other business, legal, and technical matters. The terms contained in a CP or CPS may or may not be binding upon a PKI's participants as a contract. A CP or CPS may itself purport to be a contract. More commonly, however, an agreement may incorporate a CP or CPS by reference and therefore attempt to bind the parties of the agreement to some or all of its terms. For example, some PKIs may utilize a CP or (more commonly) a CPS that is incorporated by reference in the agreement between a subscriber and a CA or RA (called a "subscriber agreement") or the agreement between a relying party and a CA (called a "relying party agreement" or "RPA"). In other cases, however, a CP or CPS has no contractual significance at all. A PKI may intend these CPs and CPSs to be strictly informational or disclosure documents.
根据美国律师协会信息安全委员会的数字签名指南（以下简称“DSG”），CA发布或引用的认证实践声明（CPS）中可能包含CA在颁发和管理证书时遵循的实践的更详细说明。（1）以及信息安全委员会的PKI评估指南（以下简称“PAG”）（2），“CPS是对证书颁发机构在颁发证书时采用的做法的声明。”[ABA1，ABA2]一般而言，CPS还描述了与所有证书生命周期服务相关的做法（例如，发行、管理、撤销和更新或重新键入），和CPS提供有关其他业务、法律和技术事项的详细信息。CP或CPS中包含的条款可能对PKI的参与者具有约束力，也可能不具有约束力。CP或CPS本身可能声称是合同。但更常见的是，协议可能通过引用包含CP或CPS，从而试图约束pa协议的部分或全部条款。例如，一些PKI可以使用CP或（更常见的）CP，该CP通过引用并入订户与CA或RA之间的协议（称为“订户协议”）或依赖方与CA之间的协议（称为“依赖方协议”或“RPA”）。但是，在其他情况下，CP或CP完全没有合同意义。PKI可能希望这些CP或CP严格作为信息或披露文件。
The purpose of this document is twofold. First, the document aims to explain the concepts of a CP and a CPS, describe the differences between these two concepts, and describe their relationship to subscriber and relying party agreements. Second, this document aims to present a framework to assist the writers and users of certificate policies or CPSs in drafting and understanding these documents. In particular, the framework identifies the elements that may need to be considered in formulating a CP or a CPS. The purpose is not to define particular certificate policies or CPSs, per se. Moreover, this document does not aim to provide legal advice or recommendations
本文件的目的有两个。首先，本文件旨在解释CP和CP的概念，描述这两个概念之间的区别，并描述它们与订户和依赖方协议的关系。其次，本文件旨在提供一个框架，帮助证书政策或CPS的作者和用户起草和理解这些文件。特别是，该框架确定了在制定CP或CP时可能需要考虑的要素。其目的不是定义特定的证书策略或CP本身。此外，本文件不旨在提供法律意见或建议
as to particular requirements or practices that should be contained within CPs or CPSs. (Such recommendations, however, appear in [ABA2].)
关于应包含在CPs或CPs中的特殊要求或实践。（然而，此类建议出现在[ABA2]中。）
The scope of this document is limited to discussion of the topics that can be covered in a CP (as defined in X.509) or CPS (as defined in the DSG and PAG). In particular, this document describes the types of information that should be considered for inclusion in a CP or a CPS. While the framework as presented generally assumes use of the X.509 version 3 certificate format for the purpose of providing assurances of identity, it is not intended that the material be restricted to use of that certificate format or identity certificates. Rather, it is intended that this framework be adaptable to other certificate formats and to certificates providing assurances other than identity that may come into use.
本文件的范围仅限于讨论CP（定义见X.509）或CP（定义见DSG和PAG）中可涵盖的主题。特别是，本文件描述了应考虑包含在CP或CP中的信息类型。虽然所述框架通常假定使用X.509版本3证书格式以提供身份保证，但并不打算将材料限于使用该证书格式或身份证书。相反，其目的是使该框架适用于其他证书格式以及提供除身份以外的其他保证的证书。
The scope does not extend to defining security policies generally (such as organization security policy, system security policy, or data labeling policy). Further, this document does not define a specific CP or CPS. Moreover, in presenting a framework, this document should be viewed and used as a flexible tool presenting topics that should be considered of particular relevance to CPs or CPSs, and not as a rigid formula for producing CPs or CPSs.
该范围不扩展到一般定义安全策略（如组织安全策略、系统安全策略或数据标签策略）。此外，本文件未定义特定CP或CP。此外，在提出框架时，应将本文件视为一种灵活的工具，用于提出应被视为与CPs或CPs特别相关的主题，而不是作为生成CPs或CPs的僵化公式。
This document assumes that the reader is familiar with the general concepts of digital signatures, certificates, and public-key infrastructure (PKI), as used in X.509, the DSG, and the PAG.
本文档假设读者熟悉X.509、DSG和PAG中使用的数字签名、证书和公钥基础设施（PKI）的一般概念。
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).
激活数据-操作加密模块所需且需要保护的数据值（密钥除外）（例如PIN、密码或手动持有的密钥共享）。
Authentication - The process of establishing that individuals, organizations, or things are who or what they claim to be. In the context of a PKI, authentication can be the process of establishing that an individual or organization applying for or seeking access to something under a certain name is, in fact, the proper individual or organization. This corresponds to the second process involved with identification, as shown in the definition of "identification" below. Authentication can also refer to a security service that provides assurances that individuals, organizations, or things are who or what
认证-确定个人、组织或事物是他们声称的人或物的过程。在公钥基础设施的背景下，身份验证可以是一个过程，即确定申请或寻求访问某个名称下的内容的个人或组织实际上是适当的个人或组织。这对应于涉及识别的第二个过程，如下文“识别”的定义所示。身份验证还可以指提供个人、组织或事物是谁或什么的保证的安全服务
they claim to be or that a message or other data originated from a specific individual, organization, or device. Thus, it is said that a digital signature of a message authenticates the message's sender.
他们声称消息或其他数据来自或来自特定的个人、组织或设备。因此，据说消息的数字签名认证消息的发送者。
CA-certificate - A certificate for one CA's public key issued by another CA.
CA证书-一个CA的公钥由另一个CA颁发的证书。
Certificate policy (CP) - 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 CP might indicate applicability of a type of certificate to the authentication of parties engaging in business-to-business transactions for the trading of goods or services within a given price range.
证书策略（CP）-一组命名规则，指示证书对具有通用安全要求的特定社区和/或应用程序类别的适用性。例如，一个特定的CP可能表明一种证书类型适用于在给定价格范围内进行商品或服务交易的企业对企业交易的各方的认证。
Certification path - An ordered sequence of certificates that, 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 that a certification authority employs in issuing, managing, revoking, and renewing or re-keying certificates.
认证实践声明（CPS）-认证机构在颁发、管理、撤销、更新或重新设置证书时采用的实践声明。
CPS Summary (or CPS Abstract) - A subset of the provisions of a complete CPS that is made public by a CA.
CPS摘要（或CPS摘要）-CA公布的完整CPS条款的子集。
Identification - The process of establishing the identity of an individual or organization, i.e., to show that an individual or organization is a specific individual or organization. In the context of a PKI, identification refers to two processes:
识别-确定个人或组织身份的过程，即表明个人或组织是特定的个人或组织。在PKI的上下文中，标识涉及两个过程：
(1) establishing that a given name of an individual or organization corresponds to a real-world identity of an individual or organization, and
(1) 确定个人或组织的给定名称对应于个人或组织的真实身份，以及
(2) establishing that an individual or organization applying for or seeking access to something under that name is, in fact, the named individual or organization. A person seeking identification may be a certificate applicant, an applicant for employment in a trusted position within a PKI participant, or a person seeking access to a network or software application, such as a CA administrator seeking access to CA systems.
(2) 确定以该名称申请或寻求访问某物的个人或组织实际上是被命名的个人或组织。寻求身份的人可以是证书申请人、在PKI参与者中担任受信任职位的申请人，或者寻求访问网络或软件应用程序的人，例如寻求访问CA系统的CA管理员。
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).
颁发证书颁发机构（颁发CA）-在特定证书的上下文中，颁发CA是颁发证书的CA（另请参见主体证书颁发机构）。
Participant - An individual or organization that plays a role within a given PKI as a subscriber, relying party, CA, RA, certificate manufacturing authority, repository service provider, or similar entity.
参与者-在给定PKI中扮演订户、依赖方、CA、RA、证书制造机构、存储库服务提供商或类似实体角色的个人或组织。
PKI Disclosure Statement (PDS) - An instrument that supplements a CP or CPS by disclosing critical information about the policies and practices of a CA/PKI. A PDS is a vehicle for disclosing and emphasizing information normally covered in detail by associated CP and/or CPS documents. Consequently, a PDS is not intended to replace a CP or CPS.
PKI披露声明（PDS）-通过披露CA/PKI政策和实践的关键信息来补充CP或CP的工具。PDS是一种披露和强调相关CP和/或CPS文件通常详细涵盖的信息的工具。因此，PDS并不打算取代CP或CP。
Policy qualifier - Policy-dependent information that may accompany a CP identifier in an X.509 certificate. Such information can include a pointer to the URL of the applicable CPS or relying party agreement. It may also include text (or number causing the appearance of text) that contains terms of the use of the certificate or other legal information.
策略限定符—X.509证书中可能伴随CP标识符的策略相关信息。此类信息可包括指向适用CPS或依赖方协议URL的指针。它还可能包括包含证书使用条款或其他法律信息的文本（或导致文本出现的数字）。
Registration authority (RA) - An entity that is responsible for one or more of the following functions: the identification and authentication of certificate applicants, the approval or rejection of certificate applications, initiating certificate revocations or suspensions under certain circumstances, processing subscriber requests to revoke or suspend their certificates, and approving or rejecting requests by subscribers to renew or re-key their certificates. RAs, however, do 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 sometimes used in other documents for the same concept.]
注册机构（RA）-负责以下一项或多项职能的实体：识别和认证证书申请人，批准或拒绝证书申请，在某些情况下启动证书撤销或暂停，处理订阅服务器撤销或挂起其证书的请求，以及批准或拒绝订阅服务器续订或重新设置其证书密钥的请求。但是，RA不签署或颁发证书（即，RA被授权代表CA执行某些任务）。[注：本地注册机构（LRA）一词有时在其他文件中用于同一概念。]
Relying party - A recipient of a certificate who acts in reliance on that certificate and/or any digital signatures verified using that certificate. In this document, the terms "certificate user" and "relying party" are used interchangeably.
依赖方-依赖该证书和/或使用该证书验证的任何数字签名的证书接收方。在本文件中，术语“证书用户”和“依赖方”可互换使用。
Relying party agreement (RPA) - An agreement between a certification authority and relying party that typically establishes the rights and responsibilities between those parties regarding the verification of digital signatures or other uses of certificates.
依赖方协议（RPA）-认证机构和依赖方之间的协议，通常确定这些方之间关于验证数字签名或证书的其他用途的权利和责任。
Set of provisions - A collection of practice and/or policy statements, spanning a range of standard topics, for use in expressing a CP or CPS employing the approach described in this framework.
一套条款-涵盖一系列标准主题的实践和/或政策声明的集合，用于采用本框架中描述的方法表达CP或CP。
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).
主体证书颁发机构（主体CA）-在特定CA证书的上下文中，主体CA是其公钥在证书中得到认证的CA（另请参见颁发证书颁发机构）。
Subscriber - A subject of a certificate who is issued a certificate.
订阅者-被颁发证书的证书的主体。
Subscriber Agreement - An agreement between a CA and a subscriber that establishes the right and responsibilities of the parties regarding the issuance and management of certificates.
订户协议-CA和订户之间的协议，确定双方在证书颁发和管理方面的权利和责任。
Validation - The process of identification of certificate applicants. "Validation" is a subset of "identification" and refers to identification in the context of establishing the identity of certificate applicants.
验证-认证申请人的身份识别过程。“验证”是“身份”的一个子集，是指在确定证书申请人身份时的身份。
This section explains the concepts of CP and CPS, and describes their relationship with other PKI documents, such as subscriber agreements and relying party agreements. 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.
本节解释了CP和CP的概念，并描述了它们与其他PKI文档的关系，如订户协议和依赖方协议。还描述了其他相关概念。本节和其他一些章节中介绍的某些内容特定于X.509版本3中定义的证书策略扩展。除这些部分外，此框架旨在适用于可能会使用的其他证书格式。
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 the identity and/or other attributes of a particular entity (the certificate subject, which is usually also the subscriber). The extent to which the relying party should rely on that statement by the CA, however, needs to be assessed by the relying party or entity controlling or coordinating the way relying parties or relying party applications use certificates. Different certificates are issued following different practices and procedures, and may be suitable for different applications and/or purposes.
当证书颁发机构颁发证书时，它向证书用户（即依赖方）提供声明，说明特定公钥绑定到特定实体（证书主体，通常也是订阅者）的身份和/或其他属性。然而，依赖方对CA声明的依赖程度需要由控制或协调依赖方或依赖方应用程序使用证书方式的依赖方或实体进行评估。根据不同的实践和程序颁发不同的证书，可能适用于不同的应用和/或目的。
The X.509 standard defines a CP 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 identify a specific applicable CP, which may be used by a relying party to
X.509标准将CP定义为“一组命名规则，表明证书适用于具有通用安全要求的特定社区和/或应用程序类别”[ISO1]。X.509版本3证书可识别特定的适用CP，依赖方可使用该CP
decide whether or not to trust a certificate, associated public key, or any digital signatures verified using the public key for a particular purpose.
决定是否信任证书、关联公钥或为特定目的使用公钥验证的任何数字签名。
CPs typically fall into two major categories. First, some CPs "indicate the applicability of a certificate to a particular community" [ISO1]. These CPs set forth requirements for certificate usage and requirements on members of a community. For instance, a CP may focus on the needs of a geographical community, such as the ETSI policy requirements for CAs issuing qualified certificates [ETS]. Also, a CP of this kind may focus on the needs of a specific vertical-market community, such as financial services [IDT].
CP通常分为两大类。首先，一些CP“表明证书对特定社区的适用性”[ISO1]。这些CPs规定了证书使用要求和对社区成员的要求。例如，CP可能关注地理社区的需求，例如对CA颁发合格证书[ETS]的ETSI政策要求。此外，此类CP可能关注特定垂直市场社区的需求，如金融服务[IDT]。
The second category of typical CPs "indicate the applicability of a certificate to a . . . class of application with common security requirements." These CPs identify a set of applications or uses for certificates and say that these applications or uses require a certain level of security. They then set forth PKI requirements that are appropriate for these applications or uses. A CP within this category often makes sets requirements appropriate for a certain "level of assurance" provided by certificates, relative to certificates issued pursuant to related CPs. These levels of assurance may correspond to "classes" or "types" of certificates.
第二类典型CP“表明证书对具有共同安全要求的……类应用程序的适用性”。这些CP识别一组应用程序或证书的使用，并表示这些应用程序或使用需要一定程度的安全性。然后，他们提出了适用于这些应用或用途的PKI要求。该类别的CP通常针对证书提供的特定“保证水平”制定适当的集合要求，相对于根据相关CP颁发的证书。这些保证级别可能对应于证书的“类别”或“类型”。
For instance, the Government of Canada PKI Policy Management Authority (GOC PMA) has established eight certificate policies in a single document [GOC], four policies for certificates used for digital signatures and four policies for certificates used for confidentiality encryption. For each of these applications, the document establishes four levels of assurances: rudimentary, basic, medium, and high. The GOC PMA described certain types of digital signature and confidentiality uses in the document, each with a certain set of security requirements, and grouped them into eight categories. The GOC PMA then established PKI requirements for each of these categories, thereby creating eight types of certificates, each providing rudimentary, basic, medium, or high levels of assurance. The progression from rudimentary to high levels corresponds to increasing security requirements and corresponding increasing levels of assurance.
例如，加拿大政府PKI政策管理局（GOC PMA）在一份文件[GOC]中制定了八项证书政策，四项用于数字签名的证书政策和四项用于保密加密的证书政策。对于这些应用程序中的每一个，该文件都建立了四个级别的保证：基本、基本、中等和高。GOC PMA在文件中描述了某些类型的数字签名和保密用途，每种用途都有一定的安全要求，并将其分为八类。然后，GOC PMA为这些类别中的每一类建立了PKI要求，从而创建了八种类型的证书，每种证书都提供基本、基本、中等或高级别的保证。从初级到高级的发展对应于不断增加的安全需求和相应不断增加的保证级别。
A CP is represented in a certificate by a unique number called an "Object Identifier" (OID). That OID, or at least an "arc", can be registered. An "arc" is the beginning of the numerical sequence of an OID and is assigned to a particular organization. The registration process follows the procedures specified in ISO/IEC and ITU standards. The party that registers the OID or arc also can publish the text of the CP, for examination by relying parties. Any one certificate will typically declare a single CP or, possibly, be
CP在证书中由称为“对象标识符”（OID）的唯一数字表示。可以注册该OID或至少一个“弧”。“弧”是OID数字序列的开始，并指定给特定组织。注册过程遵循ISO/IEC和ITU标准中规定的程序。注册OID或arc的一方也可以发布CP文本，供依赖方检查。任何一个证书通常会声明一个CP，或者可能是
issued consistent with a small number of different policies. Such declaration appears in the Certificate Policies extension of a X.509 Version 3 certificate. When a CA places multiple CPs within a certificate's Certificate Policies extension, the CA is asserting that the certificate is appropriate for use in accordance with any of the listed CPs.
与少量不同政策一致发布。此类声明出现在X.509版本3证书的证书策略扩展中。当CA在证书的证书策略扩展中放置多个CP时，CA会断言该证书适合根据列出的任何CP使用。
CPs also constitute a basis for an audit, accreditation, or another assessment of a CA. Each CA can be assessed against one or more certificate policies or CPSs that 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 an assessment 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 CP indications in its well-defined trust model.
CP还构成对CA进行审核、认证或其他评估的基础。每个CA可以根据一个或多个认证政策或其被认可为实施的CP进行评估。当一个CA为另一个CA颁发CA证书时，颁发CA必须评估其信任主体CA的证书策略集（此类评估可能基于对涉及的证书策略的评估）。然后由CA证书中的颁发CA指示经过评估的证书策略集。X.509认证路径处理逻辑在其定义良好的信任模型中使用这些CP指示。
For example purposes, suppose that the International Air Transport Association (IATA) undertakes to define some certificate policies for use throughout the airline industry, in a PKI operated by IATA in combination with PKIs operated by individual airlines. Two CPs might be defined - the IATA General-Purpose CP, and the IATA Commercial-Grade CP.
例如，假设国际航空运输协会（IATA）承诺在IATA运营的PKI中结合各航空公司运营的PKI，定义一些在整个航空业中使用的证书政策。可以定义两种CP——国际航空运输协会通用CP和国际航空运输协会商用CP。
The IATA General-Purpose CP could be used 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.
IATA通用CP可供行业人员用于保护日常信息（例如，临时电子邮件），并用于验证从万维网浏览器到服务器的连接，以便进行一般信息检索。可以使用低成本、基于软件的系统（例如商业浏览器）生成、存储和管理密钥对。根据该政策，证书可自动颁发给IATA公司目录中列出的任何员工或向其所在组织的网络管理员提交签名证书申请表的任何成员航空公司。
The IATA Commercial-Grade CP could be used to protect financial transactions or binding contractual exchanges between airlines. Under this policy, IATA could require that certified key pairs be generated and stored in approved cryptographic hardware tokens. Certificates and tokens could be provided to airline employees with disbursement authority. These authorized individuals might then be required to present themselves to the corporate security office, show a valid identification badge, and sign a subscriber agreement requiring them to protect the token and use it only for authorized purposes, as a condition of being issued a token and a certificate.
IATA商业级CP可用于保护航空公司之间的金融交易或具有约束力的合同交换。根据该政策，IATA可能要求生成经认证的密钥对，并将其存储在经批准的加密硬件令牌中。可以向具有支付权限的航空公司员工提供证书和代币。然后，这些授权个人可能需要向公司安全办公室出示自己的身份证，出示有效的身份证，并签署订户协议，要求他们保护代币，并仅将其用于授权目的，作为获得代币和证书的条件。
The following extension fields in an X.509 certificate are used to support CPs:
X.509证书中的以下扩展字段用于支持CPs：
* Certificate Policies extension; * Policy Mappings extension; and * Policy Constraints extension.
* 证书策略扩展；*政策映射扩展；和*政策限制扩展。
A Certificate Policies field lists CPs that the certification authority declares are applicable. Using the example of the IATA General-Purpose and Commercial-Grade policies defined in Section 3.2, the certificates issued to regular airline employees would contain the object identifier for General-Purpose policy. The certificates issued to the employees with disbursement authority would contain the object identifiers for both the General-Purpose policy and the Commercial-Grade policy. The inclusion of both object identifiers in the certificates means that they would be appropriate for either the General-Purpose or Commercial-Grade policies. The Certificate Policies field may also optionally convey qualifier values for each identified policy; the use of qualifiers is discussed in Section 3.4.
证书策略字段列出证书颁发机构声明适用的CP。以第3.2节中定义的IATA通用和商业级政策为例，向普通航空公司员工颁发的证书将包含通用政策的对象标识符。颁发给具有支付权限的员工的证书将包含通用保单和商业级保单的对象标识符。证书中包含两个对象标识符意味着它们适用于通用或商业级策略。证书策略字段还可以选择性地传递每个已识别策略的限定符值；第3.4节讨论了限定符的使用。
When processing a certification path, a CP that is acceptable to the relying party application must be present in every certificate in the path, i.e., in CA-certificates as well as end entity certificates.
在处理证书路径时，依赖方应用程序可接受的CP必须存在于路径中的每个证书中，即CA证书以及终端实体证书中。
If the Certificate Policies field is flagged critical, it serves the same purpose as described above but also has an additional role. Specifically, 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 at least one of the listed CPs. This field is intended to protect the certification authority against claims for damages asserted by a relying party who has used the certificate for an inappropriate purpose or in an inappropriate manner, as stipulated in the applicable CP.
如果证书策略字段被标记为关键字段，则其用途与上述相同，但还具有其他角色。具体而言，它表明证书的使用仅限于确定的政策之一，即，证书颁发机构声明证书只能按照至少一个列出的CP的规定使用。该字段旨在保护认证机构免受依赖方提出的损害索赔，该依赖方将证书用于适用CP中规定的不适当目的或以不适当方式使用。
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 erroneously issuing a bad certificate, e.g., to an imposter. Suppose, however, that someone used an Internal Revenue Service tax-filing certificate as the basis for encrypting multi-million-dollar-value proprietary trade secrets, which subsequently fell into the wrong hands because of a cryptanalytic attack by an attacker who is able to decrypt the message. The Internal Revenue Service may want
例如，为了保护纳税申报，美国国税局可能会向纳税人颁发证书。美国国税局理解并能够承受错误签发坏证书的风险，例如，向冒名顶替者签发坏证书的风险。然而，假设有人使用美国国税局的报税证书作为加密价值数百万美元的专有商业秘密的基础，这些商业秘密随后由于能够解密消息的攻击者的密码分析攻击而落入坏人之手。美国国税局可能希望
to defend itself against claims for damages in such circumstances by pointing to the criticality of the Certificate Policies extension to show that the subscriber and relying party misused the certificate. The critical-flagged Certificate Policies extension is intended to mitigate the risk to the CA in such situations.
在这种情况下，通过指出证书策略扩展的关键性，证明订阅者和依赖方滥用了证书，为自己辩护，以应对损害索赔。“关键标记证书策略”扩展旨在减轻这种情况下CA面临的风险。
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.
策略映射扩展只能在CA证书中使用。此字段允许证书颁发机构指示其自己域中的某些策略可以被视为等同于主题证书颁发机构域中的某些其他策略。
For example, suppose that for purposes of facilitating interoperability, the ACE Corporation establishes an agreement with the ABC Corporation to cross-certify the public keys of each others' certification authorities for the purposes of mutually securing their respective business-to-business exchanges. 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 appearing in their Certificate Policies extensions. 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). With such a statement included in the cross-certificate issued to ABC, relying party applications in the ACE domain requiring the presence of the object identifier for the ace-e-commerce CP can also accept, process, and rely upon certificates issued within the ABC domain containing the object identifier for the abc-e-commerce CP.
例如，假设为了促进互操作性，ACE公司与ABC公司签订协议，交叉认证彼此的认证机构的公钥，以便相互保护各自的业务对业务交换。此外，假设两家公司都有预先存在的金融交易保护政策，分别称为ace-e-commerce和abc-e-commerce。可以看出，简单地在两个域之间生成交叉证书并不能提供必要的互操作性，因为这两家公司的应用程序配置了各自的证书策略，员工证书也填充了各自的证书策略。一种可能的解决方案是重新配置所有金融应用程序以要求其中一个策略，并重新颁发所有证书，其中两个策略都出现在证书策略扩展中。另一个可能更易于管理的解决方案使用策略映射字段。如果此字段包含在ACE公司认证机构颁发的ABC公司认证机构交叉证书中，则它可以提供一份声明，说明ABC的金融交易保护政策（即ABC电子商务）可以被视为等同于ACE公司的金融交易保护政策（即ACE电子商务）。在向ABC颁发的交叉证书中包含此类声明后，ACE域中需要ACE-e-commerce CP对象标识符的依赖方应用程序也可以接受、处理和依赖在ABC域中颁发的包含ABC-e-commerce CP对象标识符的证书。
The Policy Constraints extension supports two optional features. The first is the ability for a certification authority to require that explicit CP indications be present in all subsequent certificates in a certification path. Certificates at the start of a certification path may be considered by a relying party to be part of a trusted domain, i.e., certification authorities are trusted for all purposes
策略约束扩展支持两个可选功能。第一种是认证机构能够要求在认证路径中的所有后续证书中显示显式CP指示。依赖方可能会将证书路径起始处的证书视为受信任域的一部分，即，证书颁发机构在所有方面都是受信任的
so no particular CP is needed in the Certificate Policies extension. Such certificates need not contain explicit indications of CP. When a certification authority in the trusted domain, however, certifies outside the domain, it can activate the requirement that a specific CP's object identifier appear in subsequent certificates in the certification path.
因此，证书策略扩展中不需要特定的CP。此类证书不需要包含CP的明确指示。但是，当受信任域中的证书颁发机构在域外进行认证时，它可以激活特定CP的对象标识符出现在认证路径中后续证书中的要求。
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.
“策略约束”字段中的另一个可选功能是证书颁发机构能够禁用证书路径中后续证书颁发机构的策略映射。在域外进行认证时禁用策略映射可能是明智的。这有助于控制由于可传递信任而产生的风险，例如，域a信任域B，域B信任域C，但域a不希望被迫信任域C。
The Certificate Policies extension field has a provision for conveying, along with each CP 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.
Certificate Policys extension字段有一个规定，用于在限定符字段中与每个CP标识符一起传递附加的策略相关信息。X.509标准没有规定使用此字段的目的，也没有规定此字段的语法。任何组织都可以注册策略限定符类型。
The following policy qualifier types are defined in PKIX RFC 3280 [PKI1]:
PKIX RFC 3280[PKI1]中定义了以下策略限定符类型：
(a) The CPS Pointer qualifier contains a pointer to a CPS, CPS Summary, RPA, or PDS published by the CA. The pointer is in the form of a uniform resource identifier (URI).
(a) CPS指针限定符包含指向CA发布的CPS、CPS摘要、RPA或PDS的指针。该指针采用统一资源标识符（URI）的形式。
(b) The User Notice qualifier contains a text string that is to be displayed to 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 relying party acknowledge that the applicable terms and conditions have been disclosed and/or accepted.
(b) 用户通知限定符包含一个文本字符串，该字符串将在使用证书之前显示给订阅者和依赖方。文本字符串可以是IA5String或BMPString—ISO 100646-1多个八位编码字符集的子集。CA可以援引一种程序，要求依赖方承认已披露和/或接受适用的条款和条件。
Policy qualifiers can be used to support the definition of generic, or parameterized, CPs. Provided the base CP 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.
策略限定符可用于支持泛型或参数化CP的定义。如果基本CP提供了这样的功能，则可以定义策略限定符类型，以便在每个证书的基础上传递填充通用定义的其他特定策略详细信息。
The term certification practice statement (CPS) is defined by the DSG and PAG as: "A statement of the practices which a certification authority employs in issuing certificates." [ABA1, ABA2] As stated above, a CPS establishes practices concerning lifecycle services in addition to issuance, such as certificate management (including publication and archiving), revocation, and renewal or re-keying. In the DSG, the ABA expands this definition with the following comments:
DSG和PAG将术语认证实践声明（CPS）定义为：“认证机构在颁发证书时采用的实践声明。”[ABA1，ABA2]如上所述，CPS除了颁发证书外，还建立了与生命周期服务相关的实践，如证书管理（包括发布和归档）、撤销、更新或重新键入。在DSG中，ABA用以下注释扩展了该定义：
"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 . . . ." This form of CPS is the most common type, and can vary in length and level of detail.
“认证实践声明可采用认证机构声明的形式，说明其值得信赖的系统的详细信息，以及其在运营和支持颁发证书时采用的实践……”这种形式的认证实践声明是最常见的类型，其长度和详细程度可能有所不同。
Some PKIs may not have the need to create a thorough and detailed statement of practices. For example, the CA may itself be the relying party and would already be aware of the nature and trustworthiness of its services. In other cases, a PKI may provide certificates providing only a very low level of assurances where the applications being secured may pose only marginal risks if compromised. In these cases, an organization establishing a PKI may only want to write or have CAs use a subscriber agreement, relying party agreement, or agreement combining subscriber and relying party terms, depending on the role of the different PKI participants. In such a PKI, that agreement may serve as the only "statement of practices" used by one or more CAs within that PKI. Consequently, that agreement may also be considered a CPS and can be entitled or subtitled as such.
有些公钥基础设施可能不需要创建一份全面和详细的实践说明。例如，CA本身可能是依赖方，并且已经知道其服务的性质和可靠性。在其他情况下，PKI可能提供仅提供极低级别保证的证书，其中被保护的应用程序在受到损害时可能只带来边际风险。在这些情况下，建立PKI的组织可能只希望编写或让CA使用订户协议、依赖方协议或结合订户和依赖方条款的协议，具体取决于不同PKI参与者的角色。在这样的PKI中，该协议可以作为该PKI中一个或多个CA使用的唯一“实践声明”。因此，该协议也可被视为CPS，并可作为CPS的标题或副标题。
Likewise, since a detailed CPS may contain sensitive details of its system, a CA may elect not to publish its entire CPS. It may instead opt to publish a CPS Summary (or CPS Abstract). The CPS Summary would contain only those provisions from the CPS that the CA considers to be relevant to the participants in the PKI (such as the responsibilities of the parties or the stages of the certificate lifecycle). A CPS Summary, however, would not contain those sensitive provisions of the full CPS that might provide an attacker with useful information about the CA's operations. Throughout this document, the use of "CPS" includes both a detailed CPS and a CPS Summary (unless otherwise specified).
同样，由于详细的CP可能包含其系统的敏感细节，CA可能选择不发布其整个CP。它可以选择发布CPS摘要（或CPS摘要）。CPS摘要将仅包含CA认为与PKI参与者相关的CPS条款（如各方的责任或证书生命周期的各个阶段）。但是，CPS摘要不会包含完整CPS中可能向攻击者提供有关CA操作的有用信息的敏感条款。在本文件中，“CPS”的使用包括详细的CPS和CPS摘要（除非另有规定）。
CPSs do not automatically constitute contracts and do not automatically bind PKI participants as a contract would. Where a document serves the dual purpose of being a subscriber or relying party agreement and CPS, the document is intended to be a contract and constitutes a binding contract to the extent that a subscriber or
CP不会自动构成合同，也不会像合同那样自动约束PKI参与者。如果文件具有作为认购人或依赖方协议和CPS的双重目的，则该文件旨在成为合同，并在认购人或依赖方同意的范围内构成具有约束力的合同
relying party agreement would ordinarily be considered as such. Most CPSs, however, do not serve such a dual purpose. Therefore, in most cases, a CPS's terms have a binding effect as contract terms only if a separate document creates a contractual relationship between the parties and that document incorporates part or all of the CPS by reference. Further, if a particular PKI employs a CPS Summary (as opposed to the entire CPS), the CPS Summary could be incorporated into any applicable subscriber or relying party agreement.
依赖方协议通常被视为依赖方协议。然而，大多数CPS并没有达到这样的双重目的。因此，在大多数情况下，只有当单独的文件在双方之间建立了合同关系，并且该文件通过引用包含部分或全部CPS时，CPS的条款才具有合同条款的约束力。此外，如果特定PKI采用CPS摘要（与整个CPS相反），则该CPS摘要可纳入任何适用的订户或依赖方协议中。
In the future, a court or applicable statutory or regulatory law may declare that a certificate itself is a document that is capable of creating a contractual relationship, to the extent its mechanisms designed for incorporation by reference (such as the Certificate Policies extension and its qualifiers) indicate that terms of its use appear in certain documents. In the meantime, however, some subscriber agreements and relying party agreements may incorporate a CPS by reference and therefore make its terms binding on the parties to such agreements.
将来，法院或适用的法定或监管法律可能会宣布，证书本身是一种能够建立合同关系的文件，只要其机制设计为通过引用纳入（如证书政策扩展及其限定符）表明其使用条款出现在某些文件中。然而，同时，一些认购协议和依赖方协议可能通过引用纳入CPS，从而使其条款对此类协议的各方具有约束力。
3.5. Relationship Between Certificate Policy and Certification Practice Statement
3.5. 证书政策和认证实践声明之间的关系
The CP and CPS address the same set of topics that are of interest to the relying party in terms of the degree to and purpose for which a public key certificate should be trusted. Their primary difference is in the focus of their provisions. A CP sets forth the requirements and standards imposed by the PKI with respect to the various topics. In other words, the purpose of the CP is to establish what participants must do. A CPS, by contrast, states how a CA and other participants in a given domain implement procedures and controls to meet the requirements stated in the CP. In other words, the purpose of the CPS is to disclose how the participants perform their functions and implement controls.
CP和CPS涉及依赖方在公钥证书的可信程度和用途方面感兴趣的同一组主题。它们的主要区别在于其规定的重点。CP规定了PKI对不同主题的要求和标准。换句话说，CP的目的是确定参与者必须做什么。相反，CP说明CA和给定域中的其他参与者如何实施程序和控制以满足CP中规定的要求。换句话说，CP的目的是披露参与者如何履行其职能和实施控制。
An additional difference between a CP and CPS relates the scope of coverage of the two kinds of documents. Since a CP is a statement of requirements, it best serves as the vehicle for communicating minimum operating guidelines that must be met by interoperating PKIs. Thus, a CP generally applies to multiple CAs, multiple organizations, or multiple domains. By contrast, a CPS applies only to a single CA or single organization and is not generally a vehicle to facilitate interoperation.
CP和CPS之间的另一个区别涉及两种文件的覆盖范围。由于CP是一种需求声明，因此它最适合作为传达互操作PKI必须满足的最低操作准则的工具。因此，CP通常适用于多个CA、多个组织或多个域。相比之下，CPS仅适用于单个CA或单个组织，通常不是促进互操作的工具。
A CA with a single CPS may support multiple CPs (used for different application purposes and/or by different relying party communities). Also, multiple CAs, with non-identical CPSs, may support the same CP.
具有单个CP的CA可以支持多个CP（用于不同的应用目的和/或由不同的依赖方社区使用）。此外，具有不同CP的多个CA可能支持同一CP。
For example, the Federal Government might define a government-wide CP for handling confidential human resources information. The CP will be a broad statement of the general requirements for participants within the Government's PKI, and an indication of the types of applications for which it is suitable for use. Each department or agency wishing to operate a certification authority in this PKI may be required to write its own certification practice statement to support this CP by explaining how it meets the requirements of the CP. At the same time, a department's or agency's CPS may support other certificate policies.
例如，联邦政府可能会为处理机密人力资源信息定义一个政府范围的CP。CP将广泛说明政府PKI中参与者的一般要求，并说明适合使用的应用类型。每个希望在本PKI中运营认证机构的部门或机构可能需要编写自己的认证实践声明，通过解释其如何满足CP的要求来支持本CP。同时，部门或机构的CP可能支持其他证书政策。
An additional difference between a CP and CPS concerns the level of detail of the provisions in each. Although the level of detail may vary among CPSs, a CPS will generally be more detailed than a CP. A CPS provides a detailed description of procedures and controls in place to meet the CP requirements, while a CP is more general.
CP和CPS之间的另一个区别涉及到各自条款的详细程度。尽管各CPS的详细程度可能有所不同，但CPS通常比CP更详细。CPS提供了满足CP要求的程序和控制措施的详细说明，而CP更一般。
The main differences between CPs and CPSs can therefore be summarized as follows:
因此，CPs和CPs之间的主要差异可总结如下：
(a) A PKI uses a CP to establish requirements that state what participants within it must do. A single CA or organization can use a CPS to disclose how it meets the requirements of a CP or how it implements its practices and controls.
(a) PKI使用CP建立要求，说明其参与者必须做什么。单个CA或组织可以使用CP披露其如何满足CP的要求或如何实施其实践和控制。
(b) A CP facilitates interoperation through cross-certification, unilateral certification, or other means. Therefore, it is intended to cover multiple CAs. By contrast, a CPS is a statement of a single CA or organization. Its purpose is not to facilitate interoperation (since doing so is the function of a CP).
(b) CP通过交叉认证、单边认证或其他方式促进互操作。因此，它旨在覆盖多个CA。相反，CPS是单个CA或组织的声明。其目的不是为了促进互操作（因为这样做是CP的功能）。
(c) A CPS is generally more detailed than a CP and specifies how the CA meets the requirements specified in the one or more CPs under which it issues certificates.
(c) CPS通常比CP更详细，并规定CA如何满足其颁发证书的一个或多个CPS中规定的要求。
In addition to populating the certificate policies extension with the applicable CP object 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 CP qualifier, is described in Section 3.4.
除了使用适用的CP对象标识符填充证书策略扩展之外，证书颁发机构还可以在其颁发的证书中包含对其证书实施规程声明的引用。第3.4节介绍了使用CP限定符进行此操作的标准方法。
CPs and CPSs play a central role in documenting the requirements and practices of a PKI. Nonetheless, they are not the only documents relevant to a PKI. For instance, subscriber agreements and relying party agreements play a critical role in allocating responsibilities
CPs和CPs在记录PKI的要求和实践方面起着核心作用。尽管如此，它们并不是与PKI相关的唯一文件。例如，订户协议和依赖方协议在分配责任方面起着关键作用
to subscribers and relying parties relating to the use of certificates and key pairs. They establish the terms and conditions under which certificates are issued, managed, and used. The term subscriber agreement is defined by the PAG as: "An agreement between a CA and a subscriber that establishes the right and obligations of the parties regarding the issuance and management of certificates." [ABA2] The PAG defines a relying party agreement as: "An agreement between a certification authority and relying party that typically establishes the rights and obligations between those parties regarding the verification of digital signatures or other uses of certificates." [ABA2]
与证书和密钥对的使用有关的订阅者和依赖方。它们规定了证书颁发、管理和使用的条款和条件。PAG将“认购人协议”一词定义为：“CA和认购人之间的协议，确定双方在证书颁发和管理方面的权利和义务。”[ABA2]PAG将依赖方协议定义为：“认证机构和依赖方之间的协议，通常确定这些方之间关于验证数字签名或证书的其他用途的权利和义务。”[ABA2]
As mentioned in Section 3.5, a subscriber agreement, relying party agreement, or an agreement that combines subscriber and relying party terms may also serve as a CPS. In other PKIs, however, a subscriber or relying party agreement may incorporate some or all of the terms of a CP or CPS by reference. Yet other PKIs may distill from a CP and/or CPS the terms that are applicable to a subscriber and place such terms in a self-contained subscriber agreement, without incorporating a CP or CPS by reference. They may use the same method to distill relying party terms from a CP and/or CPS and place such terms in a self-contained relying party agreement. Creating such self-contained agreements has the advantage of creating documents that are easier for consumers to review. In some cases, subscribers or relying parties may be deemed to be "consumers" under applicable law, who are subject to certain statutory or regulatory protections. Under the legal systems of civil law countries, incorporating a CP or CPS by reference may not be effective to bind consumers to the terms of an incorporated CP or CPS.
如第3.5节所述，认购方协议、依赖方协议或结合认购方和依赖方条款的协议也可作为CPS。然而，在其他公钥基础设施中，订户或依赖方协议可通过引用纳入CP或CP的部分或全部条款。然而，其他PKI可以从CP和/或CP中提取适用于订阅者的条款，并将这些条款放入独立的订阅者协议中，而无需通过引用合并CP或CP。他们可以使用相同的方法从CP和/或CP中提取依赖方条款，并将这些条款放入独立的依赖方协议中。创建这样的自包含协议的优点是创建更易于消费者查看的文档。在某些情况下，根据适用法律，订户或依赖方可能被视为“消费者”，受某些法律或监管保护。根据大陆法系国家的法律制度，通过引用合并CP或CP可能无法有效约束消费者遵守合并CP或CP的条款。
CPs and CPSs may be incorporated by reference in other documents, including:
CPs和CPs可通过引用纳入其他文件，包括：
* Interoperability agreements (including agreements between CAs for cross-certification, unilateral certification, or other forms of interoperation),
* 互操作性协议（包括CAs之间关于交叉认证、单边认证或其他形式互操作的协议），
* Vendor agreements (under which a PKI vendor agrees to meet standards set forth in a CP or CPS), or
* 供应商协议（其中PKI供应商同意满足CP或CP中规定的标准），或
* A PDS. See [ABA2]
* PDS。见[ABA2]
A PDS serves a similar function to a CPS Summary. It is a relatively short document containing only a subset of critical details about a PKI or CA. It may differ from a CPS Summary, however, in that its purpose is to act as a summary of information about the overall nature of the PKI, as opposed to simply a condensed form of the CPS.
PDS的功能与CPS摘要类似。它是一个相对较短的文档，仅包含PKI或CA关键细节的子集。但是，它可能不同于CPS摘要，因为它的目的是作为PKI总体性质信息的摘要，而不是简单的CPS的浓缩形式。
Moreover, its purpose is to distill information about the PKI, as opposed to protecting security sensitive information contained in an unpublished CPS, although a PDS could also serve that function.
此外，其目的是提取有关PKI的信息，而不是保护未发布CPS中包含的安全敏感信息，尽管PDS也可以起到这一作用。
Just as writers may wish to refer to a CP or CPS or incorporate it by reference in an agreement or PDS, a CP or CPS may refer to other documents when establishing requirements or making disclosures. For instance, a CP may set requirements for certificate content by referring to an external document setting forth a standard certificate profile. Referencing external documents permits a CP or CPS to impose detailed requirements or make detailed disclosures without having to reprint lengthy provisions from other documents within the CP or CPS. Moreover, referencing a document in a CP or CPS is another useful way of dividing disclosures between public information and security sensitive confidential information (in addition to or as an alternative to publishing a CPS Summary). For example, a PKI may want to publish a CP or CPS, but maintain site construction parameters for CA high security zones as confidential information. In that case, the CP or CPS could reference an external manual or document containing the detailed site construction parameters.
正如作者可能希望引用CP或CP，或通过引用将其纳入协议或PDS中一样，CP或CP在制定要求或进行披露时也可能引用其他文件。例如，CP可以通过参考设定标准证书概要文件的外部文档来设定证书内容的要求。引用外部文件允许CP或CPS施加详细要求或进行详细披露，而无需重新打印CP或CPS内其他文件的冗长规定。此外，在CP或CPS中引用文件是将公开信息和安全敏感机密信息区分开来的另一种有用方法（除了发布CPS摘要之外，或作为发布CPS摘要的替代方法）。例如，PKI可能希望发布CP或CP，但将CA高安全区域的站点构造参数作为机密信息进行维护。在这种情况下，CP或CPS可参考包含详细现场施工参数的外部手册或文件。
Documents that a PKI may wish to refer to in a CP or CPS include:
PKI可能希望在CP或CP中引用的文件包括：
* A security policy,
* 安全政策，
* Training, operational, installation, and user manuals (which may contain operational requirements),
* 培训、操作、安装和用户手册（可能包含操作要求），
* Standards documents that apply to particular aspects of the PKI (such as standards specifying the level of protection offered by any hardware tokens used in the PKI or standards applicable to the site construction),
* 适用于PKI特定方面的标准文件（如规定PKI中使用的任何硬件令牌提供的保护级别的标准或适用于站点建设的标准），
* Key management plans,
* 关键管理计划，
* Human resource guides and employment manuals (which may describe some aspects of personnel security practices), and
* 人力资源指南和雇佣手册（可能描述人员安全实践的某些方面），以及
* E-mail policies (which may discuss subscriber and relying party responsibilities, as well as the implications of key management, if applicable). See [ABA2]
* 电子邮件策略（可能讨论订阅者和依赖方的责任，以及密钥管理的含义，如果适用）。见[ABA2]
A set of provisions is a collection of practice and/or policy statements, spanning a range of standard topics for use in expressing a CP or CPS employing the approach described in this framework by covering the topic appearing in Section 5 below. They are also described in detail in Section 4 below.
一套条款是实践和/或政策声明的集合，涵盖一系列标准主题，用于采用本框架中描述的方法表达CP或CP，涵盖下文第5节中出现的主题。下文第4节也对其进行了详细描述。
A CP can be expressed as a single set of provisions.
CP可以表示为一组规定。
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:
CPS可以表示为一组单独的条款，其中每个组件满足一个或多个证书策略的要求，或者，也可以表示为一组有组织的条款集合。例如，CPS可以表示为以下各项的组合：
(a) a list of certificate policies supported by the CPS;
(a) CPS支持的证书策略列表；
(b) for each CP in (a), a set of provisions that contains statements responding to that CP by filling in details not stipulated in that policy or expressly left to the discretion of the CA (in its CPS) ; such statements serve to state how this particular CPS implements the requirements of the particular CP; or
(b) 对于（a）中的每个CP，一套条款，其中包含通过填写该政策中未规定或由CA（在其CP中）明确决定的细节来响应该CP的声明；此类声明用于说明该特定CP如何实施特定CP的要求；或
(c) a set of provisions that contains statements regarding the certification practices on the CA, regardless of CP.
(c) 一组条款，包含关于CA认证实践的声明，无论CP如何。
The statements provided in (b) and (c) may augment or refine the stipulations of the applicable CP, but generally must not conflict with any of the stipulations of such CP. In certain cases, however, a policy authority may permit exceptions to the requirements in a CP, because certain compensating controls of the CA are disclosed in its CPS that allow the CA to provide assurances that are equivalent to the assurances provided by CAs that are in full compliance with the CP.
（b）和（c）中提供的声明可增加或完善适用CP的规定，但通常不得与此类CP的任何规定冲突。但是，在某些情况下，政策主管部门可允许CP中的要求例外，因为CA的CPS中披露了CA的某些补偿控制，允许CA提供与CA提供的完全符合CP的保证相同的保证。
This framework outlines the contents of a set of provisions, in terms of nine primary components, as follows:
该框架从九个主要部分概述了一套条款的内容，如下所示：
1. Introduction 2. Publication and Repository 3. Identification and Authentication 4. Certificate Life-Cycle Operational Requirements 5. Facilities, Management, and Operational Controls 6. Technical Security Controls 7. Certificate, CRL, and OCSP Profile 8. Compliance audit 9. Other Business and Legal Matters
1. 导言2。出版物和储存库3。识别和认证4。证书生命周期操作要求5。设施、管理和运营控制6。技术安全控制7。证书、CRL和OCSP配置文件8。合规审计9。其他商业及法律事宜
PKIs can use this simple framework of nine primary components to write a simple CP or CPS. Moreover, a CA can use this same framework to write a subscriber agreement, relying party agreement, or agreement containing subscriber and relying party terms. If a CA uses this simple framework to construct an agreement, it can use paragraph 1 as an introduction or recitals, it can set forth the responsibilities of the parties in paragraphs 2-8, and it can use paragraph 9 to cover the business and legal issues described in more detail, using the ordering of Section 4.9 below (such as representations and warranties, disclaimers, and liability limitations). The ordering of topics in this simple framework and the business and legal matters Section 4.9 is the same as (or similar to) the ordering of topics in a typical software or other technology agreement. Therefore, a PKI can establish a set of core documents (with a CP, CPS, subscriber agreement, and relying party agreement) all having the same structure and ordering of topics, thereby facilitating comparisons and mappings among these documents and among the corresponding documents of other PKIs.
PKI可以使用这个由九个主要组件组成的简单框架来编写一个简单的CP或CP。此外，CA可以使用此相同的框架编写订户协议、依赖方协议或包含订户和依赖方条款的协议。如果CA使用这个简单的框架来构建协议，它可以使用第1段作为引言或陈述，它可以在第2-8段中规定双方的责任，它可以使用第9段来涵盖更详细描述的业务和法律问题，使用下面第4.9节的顺序（如陈述和保证、免责声明和责任限制）。此简单框架中主题的排序以及第4.9节中的业务和法律事项与典型软件或其他技术协议中主题的排序相同（或类似）。因此，PKI可以建立一组核心文档（使用CP、CPS、订户协议和依赖方协议）都具有相同的主题结构和顺序，从而便于在这些文档和其他PKI的相应文档之间进行比较和映射。
This simple framework may also be useful for agreements other than subscriber agreements and relying party agreements. For instance, a CA wishing to outsource certain services to an RA or certificate manufacturing authority (CMA) may find it useful to use this framework as a checklist to write a registration authority agreement or outsourcing agreement. Similarly, two CAs may wish to use this simple framework for the purpose of drafting a cross-certification, unilateral certification, or other interoperability agreement.
这个简单的框架对于订户协议和依赖方协议以外的协议也可能有用。例如，希望将某些服务外包给RA或证书制造机构（CMA）的CA可能会发现，将此框架用作编写注册机构协议或外包协议的检查表非常有用。同样，两个CA可能希望使用此简单框架来起草交叉认证、单边认证或其他互操作性协议。
In short, the primary components of the simple framework (specified above) may meet the needs of drafters of short CPs, CPSs, subscriber agreements, and relying party agreements. Nonetheless, this framework is extensible, and its coverage of the nine components is flexible enough to meet the needs of drafters of comprehensive CPs and CPSs. Specifically, components appearing above 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. Drafters of CPs and CPSs are permitted to add additional levels of subcomponents below the subcomponents described in Section 4 for the purpose of meeting the needs of the drafter's particular PKI.
简言之，简单框架的主要组成部分（如上所述）可以满足短期CP、CP、订户协议和依赖方协议起草者的需要。尽管如此，该框架是可扩展的，其九个组成部分的覆盖范围足够灵活，能够满足全面CPs和CPs起草者的需要。具体地说，上面出现的组件可以进一步划分为子组件，并且子组件可以包括多个元素。第4节更详细地描述了上述组件及其子组件的内容。CPs和CPs的起草者可以在第4节所述子组件的下方添加额外级别的子组件，以满足起草者特定PKI的需要。
This section expands upon the contents of the simple framework of provisions, as introduced in Section 3.7. The topics identified in this section are, consequently, candidate topics for inclusion in a detailed CP or CPS.
本节扩展了第3.7节中介绍的简单条款框架的内容。因此，本节中确定的主题是包含在详细CP或CP中的候选主题。
While many topics are identified, it is not necessary for a CP or a CPS to include a concrete statement for every such topic. Rather, a particular CP or CPS may state "no stipulation" for a component, subcomponent, or element on which the particular CP or CPS imposes no requirements or makes no disclosure. In this sense, the list of topics can be considered a checklist of topics for consideration by the CP or CPS writer.
虽然确定了许多主题，但CP或CP没有必要为每个此类主题都包含具体的声明。相反，特定CP或CP可以对特定CP或CP未提出要求或未披露的组件、子组件或元件声明“无规定”。从这个意义上讲，主题列表可以被视为CP或CPS作者考虑的主题清单。
It is recommended that each and every component and subcomponent be included in a CP or CPS, even if there is "no stipulation"; this will indicate to the reader that a conscious decision was made to include or exclude a provision concerning that topic. This drafting style protects against inadvertent omission of a topic, while facilitating comparison of different certificate policies or CPSs, e.g., when making policy mapping decisions.
建议将每个组件和子组件包括在CP或CP中，即使“没有规定”；这将向读者表明，有意识地决定包括或排除与该主题有关的规定。这种起草风格可以防止无意中遗漏主题，同时便于比较不同的证书策略或CP，例如，在做出策略映射决策时。
In a CP, 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, or the document to which a policy qualifier points. Such CPs 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.
在CP中，可以不指定某些组件、子组件和/或元素，并规定所需信息将在策略限定符或策略限定符指向的文档中指明。此类CP可被视为参数化定义。规定集应引用或定义所需的策略限定符类型，并应指定任何适用的默认值。
This component identifies and introduces the set of provisions, and indicates the types of entities and applications for which the document (either the CP or the CPS being written) is targeted.
本部分确定并介绍了一套规定，并指出了文件（CP或正在编写的CP）所针对的实体和应用的类型。
This subcomponent provides a general introduction to the document being written. This subcomponent can also be used to provide a synopsis of the PKI to which the CP or CPS applies. For example, it may set out different levels of assurance provided by certificates within the PKI. Depending on the complexity and scope of the particular PKI, a diagrammatic representation of the PKI might be useful here.
此子组件提供所编写文档的一般介绍。此子组件还可用于提供CP或CP适用的PKI概要。例如，它可以规定PKI中证书提供的不同级别的保证。根据特定PKI的复杂性和范围，此处可能需要PKI的图解表示。
This subcomponent provides any applicable names or other identifiers, including ASN.1 object identifiers, for the document. An example of such a document name would be the US Federal Government Policy for Secure E-mail.
此子组件为文档提供任何适用的名称或其他标识符，包括ASN.1对象标识符。这种文件名的一个例子是美国联邦政府的安全电子邮件政策。
This subcomponent describes the identity or types of entities that fill the roles of participants within a PKI, namely:
此子组件描述了在PKI中担任参与者角色的实体的身份或类型，即：
* Certification authorities, i.e., the entities that issue certificates. A CA is the issuing CA with respect to the certificates it issues and is the subject CA with respect to the CA certificate issued to it. CAs may be organized in a hierarchy in which an organization's CA issues certificates to CAs operated by subordinate organizations, such as a branch, division, or department within a larger organization.
* 认证机构，即颁发证书的实体。CA是与其颁发的证书相关的颁发CA，也是与其颁发的CA证书相关的主体CA。CA可以按层次结构组织，其中组织的CA向下级组织（如较大组织内的分支机构、部门或部门）运营的CA颁发证书。
* Registration authorities, i.e., the entities that establish enrollment procedures for end-user certificate applicants, perform identification and authentication of certificate applicants, initiate or pass along revocation requests for certificates, and approve applications for renewal or re-keying certificates on behalf of a CA. Subordinate organizations within a larger organization can act as RAs for the CA serving the entire organization, but RAs may also be external to the CA.
* 注册机构，即为最终用户证书申请人建立注册程序、对证书申请人进行身份识别和认证、发起或传递证书撤销请求的实体，并代表CA批准证书续期或重新设置密钥的申请。较大组织内的下级组织可以充当为整个组织服务的CA的RAs，但RAs也可以是CA的外部组织。
* Subscribers. Examples of subscribers who receive certificates from a CA include employees of an organization with its own CA, banking or brokerage customers, organizations hosting e-commerce sites, organizations participating in a business-to-business exchange, and members of the public receiving certificates from a CA issuing certificates to the public at large.
* 订户。从CA接收证书的订户示例包括拥有自己CA的组织的员工、银行或经纪客户、托管电子商务网站的组织、参与企业对企业交换的组织、，以及从向公众发放证书的CA处接收证书的公众成员。
* Relying parties. Examples of relying parties include employees of an organization having its own CA who receive digitally signed e-mails from other employees, persons buying goods and services from e-commerce sites, organizations participating in a business-to-business exchange who receive bids or orders from other participating organizations, and individuals and organizations doing business with subscribers who have received their certificates from a CA issuing certificates to the public. Relying parties may or may not also be subscribers within a given PKI.
* 依赖方。依赖方的例子包括拥有自己的CA的组织的员工，他们接收来自其他员工的数字签名电子邮件，从电子商务网站购买商品和服务的人，参与企业对企业交换的组织，他们接收来自其他参与组织的投标或订单，以及与已从向公众颁发证书的CA处收到证书的用户开展业务的个人和组织。依赖方可能是也可能不是给定PKI中的订户。
* Other participants, such as certificate manufacturing authorities, providers of repository services, and other entities providing PKI-related services.
* 其他参与者，如证书制造机构、存储库服务提供商以及提供PKI相关服务的其他实体。
This subcomponent contains:
此子组件包含：
* A list or the types of applications for which the issued certificates are suitable, such as electronic mail, retail transactions, contracts, and a travel order, and/or
* 适用于已签发证书的申请的列表或类型，如电子邮件、零售交易、合同和旅行订单，和/或
* A list or the types of applications for which use of the issued certificates is prohibited.
* 禁止使用已颁发证书的申请的列表或类型。
In the case of a CP or CPS describing different levels of assurance, this subcomponent can describe applications or types of applications that are appropriate or inappropriate for the different levels of assurance.
对于描述不同保证级别的CP或CP，本子组件可描述适用于或不适用于不同保证级别的应用或应用类型。
This subcomponent includes the name and mailing address of the organization that is responsible for the drafting, registering, maintaining, and updating of this CP or CPS. It also includes the name, electronic mail address, telephone number, and fax number of a contact person. As an alternative to naming an actual person, the document may name a title or role, an e-mail alias, and other generalized contact information. In some cases, the organization may state that its contact person, alone or in combination with others, is available to answer questions about the document.
本子部分包括负责起草、注册、维护和更新本CP或CP的组织的名称和邮寄地址。它还包括联系人的姓名、电子邮件地址、电话号码和传真号码。作为命名实际人员的替代方法，文档可以命名标题或角色、电子邮件别名和其他通用联系信息。在某些情况下，组织可能会声明其联系人可以单独或与其他人一起回答有关该文件的问题。
Moreover, when a formal or informal policy authority is responsible for determining whether a CA should be allowed to operate within or interoperate with a PKI, it may wish to approve the CPS of the CA as being suitable for the policy authority's CP. If so, this subcomponent can include the name or title, electronic mail address (or alias), telephone number, fax number, and other generalized information of the entity in charge of making such a determination. Finally, in this case, this subcomponent also includes the procedures by which this determination is made.
此外，当正式或非正式的政策机构负责确定是否应允许CA在PKI内运行或与PKI互操作时，可能希望批准CA的CP适合政策机构的CP。如果是，此子组件可以包括名称或标题、电子邮件地址（或别名），负责做出此类决定的实体的电话号码、传真号码和其他一般信息。最后，在这种情况下，该子组件还包括进行该确定的程序。
This subcomponent contains a list of definitions for defined terms used within the document, as well as a list of acronyms in the document and their meanings.
此子组件包含文档中使用的已定义术语的定义列表，以及文档中首字母缩略词及其含义的列表。
This component contains any applicable provisions regarding:
本部分包含关于以下方面的任何适用规定：
* An identification of the entity or entities that operate repositories within the PKI, such as a CA, certificate manufacturing authority, or independent repository service provider;
* 在PKI中运行存储库的一个或多个实体的标识，如CA、证书制造机构或独立存储库服务提供商；
* The responsibility of a PKI participant to publish information regarding its practices, certificates, and the current status of such certificates, which may include the responsibilities of making the CP or CPS publicly available using various mechanisms and of identifying components, subcomponents, and elements of such documents that exist but are not made publicly available, for instance, security controls, clearance procedures, or trade secret information due to their sensitivity;
* PKI参与者发布有关其实践、证书和此类证书当前状态的信息的责任，可能包括使用各种机制公开CP或CP以及识别组件、子组件的责任，以及存在但未公开的此类文件的要素，例如，安全控制、清关程序或商业秘密信息，因为其敏感性；
* When information must be published and the frequency of publication; and
* 必须发布信息的时间和发布频率；和
* Access control on published information objects including CPs, CPS, certificates, certificate status, and CRLs.
* 对已发布信息对象的访问控制，包括CPs、CPs、证书、证书状态和CRL。
This component describes the procedures used to authenticate the identity and/or other attributes of an end-user certificate applicant to a CA or RA prior to certificate issuance. In addition, the component sets forth the procedures for authenticating the identity and the criteria for accepting applicants of entities seeking to become CAs, RAs, or other entities operating in or interoperating with a PKI. It also describes how parties requesting re-key or revocation are authenticated. This component also addresses naming practices, including the recognition of trademark rights in certain names.
此组件描述了用于在证书颁发之前向CA或RA验证最终用户证书申请人的身份和/或其他属性的过程。此外，该组件还规定了身份验证程序以及接受寻求成为CA、RAs或在PKI中运行或与PKI互操作的其他实体的申请人的标准。它还描述了请求重设密钥或撤销的各方如何进行身份验证。本部分还涉及命名实践，包括承认某些名称的商标权。
This subcomponent includes the following elements regarding naming and identification of the subscribers:
此子组件包括以下关于订阅者命名和标识的元素：
* Types of names assigned to the subject, such as X.500 distinguished names; RFC-822 names; and X.400 names;
* 指定给主题的名称类型，如X.500可分辨名称；RFC-822名称；和X.400个姓名；
* Whether names have to be meaningful or not;(3)
* 名称是否必须有意义；(3)
* Whether or not subscribers can be anonymous or pseudonymous, and if they can, what names are assigned to or can be used by anonymous subscribers;
* 订阅者是否可以匿名或假名，如果可以，匿名订阅者可以指定或使用什么名称；
* Rules for interpreting various name forms, such as the X.500 standard and RFC-822;
* 解释各种名称形式的规则，如X.500标准和RFC-822；
* Whether names have to be unique; and
* 名称是否必须是唯一的；和
* Recognition, authentication, and the role of trademarks.
* 识别、认证和商标的作用。
This subcomponent contains the following elements for the identification and authentication procedures for the initial registration for each subject type (CA, RA, subscriber, or other participant):
此子组件包含每个主题类型（CA、RA、订户或其他参与者）初始注册的识别和认证程序的以下要素：
* If and how the subject must prove possession of the companion private key for the public key being registered, for example, a digital signature in the certificate request message;(4)
* 如果以及如何证明主体拥有注册公钥的伴随私钥，例如，证书请求消息中的数字签名；(4)
* Identification and authentication requirements for organizational identity of subscriber or participant (CA; RA; subscriber (in the case of certificates issued to organizations or devices controlled by an organization), or other participant), for example, consulting the database of a service that identifies organizations or inspecting an organization's articles of incorporation;
* 订阅者或参与者（CA；RA；订阅者（在向组织或组织控制的设备颁发证书的情况下）或其他参与者的组织身份的识别和认证要求，例如，查阅识别组织的服务数据库或检查组织的公司章程；
* Identification and authentication requirements for an individual subscriber or a person acting on behalf of an organizational subscriber or participant (CA, RA, in the case of certificates issued to organizations or devices controlled by an organization, the subscriber, or other participant),(5) including:
* 个人订阅者或代表组织订阅者或参与者（CA、RA，如果证书颁发给组织、订阅者或其他参与者控制的组织或设备）的个人订阅者或代表组织订阅者或参与者的人的身份验证要求，（5）包括：
* Type of documentation and/or number of identification credentials required;
* 所需文件类型和/或身份证件数量；
* How a CA or RA authenticates the identity of the organization or individual based on the documentation or credentials provided;
* CA或RA如何根据提供的文件或凭证认证组织或个人的身份；
* If the individual must personally present to the authenticating CA or RA;
* 如果个人必须亲自向认证CA或RA出示；
* How an individual as an organizational person is authenticated, such as by reference to duly signed authorization documents or a corporate identification badge.
* 个人作为组织人员的身份认证方式，例如通过参考正式签署的授权文件或公司识别徽章。
* List of subscriber information that is not verified (called "non-verified subscriber information") during the initial registration;
* 初始注册期间未经验证的用户信息列表（称为“未经验证的用户信息”）；
* Validation of authority involves a determination of whether a person has specific rights, entitlements, or permissions, including the permission to act on behalf of an organization to obtain a certificate; and
* 授权验证涉及确定一个人是否拥有特定的权利、权利或许可，包括代表一个组织获得证书的许可；和
* In the case of applications by a CA wishing to operate within, or interoperate with, a PKI, this subcomponent contains the criteria by which a PKI, CA, or policy authority determines whether or not the CA is suitable for such operations or interoperation. Such interoperation may include cross-certification, unilateral certification, or other forms of interoperation.
* 如果CA的应用程序希望在PKI内运行或与PKI互操作，则此子组件包含PKI、CA或策略机构确定CA是否适合此类操作或互操作的标准。这种互操作可能包括交叉认证、单边认证或其他形式的互操作。
This subcomponent addresses the following elements for the identification and authentication procedures for re-key for each subject type (CA, RA, subscriber, and other participants):
本子组件针对每种主体类型（CA、RA、订户和其他参与者）的重新密钥识别和身份验证程序，阐述了以下要素：
* Identification and authentication requirements for routine re-key, such as a re-key request that contains the new key and is signed using the current valid key; and
* 常规重密钥的标识和身份验证要求，例如包含新密钥并使用当前有效密钥签名的重密钥请求；和
* Identification and authentication requirements for re-key after certificate revocation. One example is the use of the same process as the initial identity validation.
* 证书撤销后重新密钥的标识和身份验证要求。一个例子是使用与初始身份验证相同的过程。
This subcomponent describes the identification and authentication procedures for a revocation request by each subject type (CA, RA, subscriber, and other participant). Examples include a revocation request digitally signed with the private key whose companion public key needs to be revoked, and a digitally signed request by the RA.
本子组件描述了每种主体类型（CA、RA、订户和其他参与者）撤销请求的识别和认证过程。示例包括使用私钥进行数字签名的撤销请求，其附带的公钥需要撤销，以及RA的数字签名请求。
This component is used to specify requirements imposed upon issuing CA, subject CAs, RAs, subscribers, or other participants with respect to the life-cycle of a certificate.
此组件用于指定颁发CA、主体CA、RAs、订阅者或其他参与者对证书生命周期的要求。
Within each subcomponent, separate consideration may need to be given to subject CAs, RAs, subscribers, and other participants.
在每个子组件中，可能需要单独考虑主体CA、RAs、订阅者和其他参与者。
This subcomponent is used to address the following requirements regarding subject certificate application:
本子部分用于满足以下有关主体证书申请的要求：
* Who can submit a certificate application, such as a certificate subject or the RA; and
* 谁可以提交证书申请，如证书主体或RA；和
* Enrollment process used by subjects to submit certificate applications and responsibilities in connection with this process. An example of this process is where the subject generates the key pair and sends a certificate request to the RA. The RA validates and signs the request and sends it to the CA. A CA or RA may have the responsibility of establishing an enrollment process in order to receive certificate applications. Likewise, certificate applicants may have the responsibility of providing accurate information on their certificate applications.
* 受试者用于提交证书申请的注册流程以及与此流程相关的责任。该过程的一个示例是，主体生成密钥对并向RA发送证书请求。RA验证并签署请求并将其发送给CA。CA或RA可能负责建立注册流程以接收证书申请。同样，证书申请人可能有责任提供其证书申请的准确信息。
This subcomponent is used to describe the procedure for processing certificate applications. For example, the issuing CA and RA may perform identification and authentication procedures to validate the certificate application. Following such steps, the CA or RA will either approve or reject the certificate application, perhaps upon the application of certain criteria. Finally, this subcomponent sets a time limit during which a CA and/or RA must act on and process a certificate application.
此子组件用于描述处理证书申请的过程。例如，颁发CA和RA可以执行识别和认证过程以验证证书应用。按照这些步骤，CA或RA将批准或拒绝证书申请，可能是基于某些标准的应用。最后，此子组件设置CA和/或RA必须对证书应用程序采取行动并进行处理的时间限制。
This subcomponent is used to describe the following certificate issuance related elements:
此子组件用于描述以下证书颁发相关元素：
* Actions performed by the CA during the issuance of the certificate, for example a procedure whereby the CA validates the RA signature and RA authority and generates a certificate; and
* CA在颁发证书期间执行的操作，例如CA验证RA签名和RA授权并生成证书的程序；和
* Notification mechanisms, if any, used by the CA to notify the subscriber of the issuance of the certificate; an example is a procedure under which the CA e-mails the certificate to the subscriber or the RA or e-mails information permitting the subscriber to download the certificate from a web site.
* CA用于通知订阅者证书颁发的通知机制（如有）；例如，CA通过电子邮件将证书发送给订阅者或RA，或通过电子邮件发送允许订阅者从网站下载证书的信息。
This subcomponent addresses the following:
此子组件涉及以下内容：
* The conduct of an applicant that will be deemed to constitute acceptance of the certificate. Such conduct may include affirmative steps to indicate acceptance, actions implying acceptance, or a failure to object to the certificate or its content. For instance, acceptance may be deemed to occur if the CA does not receive any notice from the subscriber within a certain time period; a subscriber may send a signed message accepting the certificate; or a subscriber may send a signed message rejecting the certificate where the message includes the reason for rejection and identifies the fields in the certificate that are incorrect or incomplete.
* 申请人的行为将被视为构成对证书的接受。此类行为可包括表明接受的肯定步骤、暗示接受的行动或未能对证书或其内容提出异议。例如，如果CA在某个时间段内未收到订户的任何通知，则可能会被视为接受；用户可以发送接受证书的签名消息；或者，订阅者可以发送拒绝证书的签名消息，其中该消息包含拒绝的原因，并标识证书中不正确或不完整的字段。
* Publication of the certificate by the CA. For example, the CA may post the certificate to an X.500 or LDAP repository.
* CA发布证书。例如，CA可以将证书发布到X.500或LDAP存储库。
* Notification of certificate issuance by the CA to other entities. As an example, the CA may send the certificate to the RA.
* CA向其他实体发出证书颁发通知。例如，CA可以向RA发送证书。
This subcomponent is used to describe the responsibilities relating to the use of keys and certificates, including:
本子部分用于描述与密钥和证书使用相关的责任，包括：
* Subscriber responsibilities relating to use of the subscriber's private key and certificate. For example, the subscriber may be required to use a private key and certificate only for appropriate applications as set forth in the CP and in consistency with applicable certificate content (e.g., key usage field). Use of a private key and certificate are subject to the terms of the subscriber agreement, the use of a private key is permitted only after the subscriber has accepted the corresponding certificate, or the subscriber must discontinue use of the private key following the expiration or revocation of the certificate.
* 订阅者使用订阅者私钥和证书的责任。例如，订户可能被要求仅对CP中规定的适当应用使用私钥和证书，并且与适用的证书内容（例如，密钥使用字段）一致。私钥和证书的使用受订户协议条款的约束，仅在订户接受相应证书后才允许使用私钥，或者订户必须在证书到期或撤销后停止使用私钥。
* Relying party responsibilities relating to the use of a subscriber's public key and certificate. For instance, a relying party may be obligated to rely on certificates only for appropriate applications as set forth in the CP and in consistency with applicable certificate content (e.g., key usage field), successfully perform public key operations as a condition of relying on a certificate, assume responsibility to check the status of a certificate using one of the required or permitted
* 与使用订户公钥和证书有关的依赖方责任。例如，依赖方可能有义务仅为CP中规定的适当应用依赖证书，并与适用的证书内容（例如，密钥使用字段）一致，成功执行公钥操作作为依赖证书的条件，负责使用所需或允许的证书之一检查证书的状态
mechanisms set forth in the CP/CPS (see Section 4.4.9 below), and assent to the terms of the applicable relying party agreement as a condition of relying on the certificate.
CP/CPS中规定的机制（见下文第4.4.9节），并同意适用依赖方协议的条款作为依赖证书的条件。
This subcomponent is used to describe the following elements related to certificate renewal. Certificate renewal means the issuance of a new certificate to the subscriber without changing the subscriber or other participant's public key or any other information in the certificate:
此子组件用于描述与证书续订相关的以下元素。证书更新是指在不更改订阅方或其他参与者的公钥或证书中的任何其他信息的情况下向订阅方颁发新证书：
* Circumstances under which certificate renewal takes place, such as where the certificate life has expired, but the policy permits the same key pair to be reused;
* 发生证书续订的情况，例如证书有效期已过期，但策略允许重复使用同一密钥对；
* Who may request certificate renewal, for instance, the subscriber, RA, or the CA may automatically renew an end-user subscriber certificate;
* 谁可以请求证书续期，例如，订户、RA或CA可以自动续期最终用户订户证书；
* A CA or RA's procedures to process renewal requests to issue the new certificate, for example, the use of a token, such as a password, to re-authenticate the subscriber, or procedures that are the same as the initial certificate issuance;
* CA或RA处理续订请求以颁发新证书的程序，例如，使用令牌（如密码）重新认证订户，或与初始证书颁发相同的程序；
* Notification of the new certificate to the subscriber;
* 向认购人通知新证书；
* Conduct constituting acceptance of the certificate;
* 构成接受证书的行为；
* Publication of the certificate by the CA; and
* CA发布证书；和
* Notification of certificate issuance by the CA to other entities.
* CA向其他实体发出证书颁发通知。
This subcomponent is used to describe the following elements related to a subscriber or other participant generating a new key pair and applying for the issuance of a new certificate that certifies the new public key:
此子组件用于描述与生成新密钥对的订阅者或其他参与者以及申请颁发新证书以证明新公钥相关的以下要素：
* Circumstances under which certificate re-key can or must take place, such as after a certificate is revoked for reasons of key compromise or after a certificate has expired and the usage period of the key pair has also expired;
* 可以或必须进行证书重设密钥的情况，例如在证书因密钥泄露而被吊销后，或在证书过期且密钥对的使用期限也已过期后；
* Who may request certificate re-key, for example, the subscriber;
* 谁可以请求证书重设密钥，例如，订户；
* A CA or RA's procedures to process re-keying requests to issue the new certificate, such as procedures that are the same as the initial certificate issuance;
* CA或RA处理密钥更新请求以颁发新证书的程序，例如与初始证书颁发相同的程序；
* Notification of the new certificate to the subscriber;
* 向认购人通知新证书；
* Conduct constituting acceptance of the certificate;
* 构成接受证书的行为；
* Publication of the certificate by the CA; and
* CA发布证书；和
* Notification of certificate issuance by the CA to other entities.
* CA向其他实体发出证书颁发通知。
This subcomponent is used to describe the following elements related to the issuance of a new certificate (6) due to changes in the information in the certificate other than the subscriber public key:
此子组件用于描述由于证书中除订户公钥以外的信息发生变化而发行新证书（6）的以下相关要素：
* Circumstances under which certificate modification can take place, such as name change, role change, reorganization resulting in a change in the DN;
* 可能发生证书修改的情况，例如名称更改、角色更改、导致DN更改的重组；
* Who may request certificate modification, for instance, subscribers, human resources personnel, or the RA;
* 可能要求修改证书的人员，例如，订阅者、人力资源人员或RA；
* A CA or RA's procedures to process modification requests to issue the new certificate, such as procedures that are the same as the initial certificate issuance;
* CA或RA处理修改请求以颁发新证书的程序，例如与初始证书颁发相同的程序；
* Notification of the new certificate to the subscriber;
* 向认购人通知新证书；
* Conduct constituting acceptance of the certificate;
* 构成接受证书的行为；
* Publication of the certificate by the CA; and
* CA发布证书；和
* Notification of certificate issuance by the CA to other entities.
* CA向其他实体发出证书颁发通知。
This subcomponent addresses the following:
此子组件涉及以下内容：
* Circumstances under which a certificate may be suspended and circumstances under which it must be revoked, for instance, in cases of subscriber employment termination, loss of cryptographic token, or suspected compromise of the private key;
* 可能暂停证书的情况以及必须撤销证书的情况，例如，在订户终止雇佣关系、丢失加密令牌或怀疑私钥泄露的情况下；
* Who can request the revocation of the participant's certificate, for example, the subscriber, RA, or CA in the case of an end-user subscriber certificate.
* 谁可以请求撤销参与者的证书，例如，在最终用户用户证书的情况下，用户、RA或CA。
* Procedures used for certificate revocation request, such as a digitally signed message from the RA, a digitally signed message from the subscriber, or a phone call from the RA;
* 用于证书撤销请求的过程，例如来自RA的数字签名消息、来自订户的数字签名消息或来自RA的电话呼叫；
* The grace period available to the subscriber, within which the subscriber must make a revocation request;
* 认购人可用的宽限期，认购人必须在该宽限期内提出撤销请求；
* The time within which CA must process the revocation request;
* CA必须处理撤销请求的时间；
* The mechanisms, if any, that a relying party may use or must use in order to check the status of certificates on which they wish to rely;
* 依赖方为检查其希望依赖的证书的状态而可能使用或必须使用的机制（如有）；
* If a CRL mechanism is used, the issuance frequency;
* 如果使用CRL机制，发行频率；
* If a CRL mechanism is used, maximum latency between the generation of CRLs and posting of the CRLs to the repository (in other words, the maximum amount of processing- and communication-related delays in posting CRLs to the repository after the CRLs are generated);
* 如果使用CRL机制，则在生成CRL和将CRL发布到存储库之间的最大延迟（换句话说，在生成CRL后将CRL发布到存储库中的与处理和通信相关的最大延迟量）；
* On-line revocation/status checking availability, for instance, OCSP and a web site to which status inquiries can be submitted;
* 在线撤销/状态检查可用性，例如，OCSP和可提交状态查询的网站；
* Requirements on relying parties to perform on-line revocation/status checks;
* 对依赖方进行在线撤销/状态检查的要求；
* Other forms of revocation advertisements available;
* 其他形式的撤销广告；
* Any variations of the above stipulations for which suspension or revocation is the result of private key compromise (as opposed to other reasons for suspension or revocation).
* 因私钥泄露导致暂停或撤销的上述规定的任何变更（与暂停或撤销的其他原因相反）。
* Circumstances under which a certificate may be suspended;
* 在何种情况下证书可能被暂停；
* Who can request the suspension of a certificate, for example, the subscriber, human resources personnel, a supervisor of the subscriber, or the RA in the case of an end-user subscriber certificate;
* 可申请暂停证书的人员，例如，认购人、人力资源人员、认购人的主管，或最终用户认购人证书的RA；
* Procedures to request certificate suspension, such as a digitally signed message from the subscriber or RA, or a phone call from the RA; and
* 申请证书暂停的程序，例如来自订户或RA的数字签名消息，或来自RA的电话；和
* How long the suspension may last.
* 暂停可能持续多长时间。
This subcomponent addresses the certificate status checking services available to the relying parties, including:
本子组件介绍了可供依赖方使用的证书状态检查服务，包括：
* The operational characteristics of certificate status checking services;
* 证书状态检查服务的操作特性；
* The availability of such services, and any applicable policies on unavailability; and
* 此类服务的可用性，以及关于不可用性的任何适用政策；和
* Any optional features of such services.
* 此类服务的任何可选功能。
This subcomponent addresses procedures used by the subscriber to end subscription to the CA services, including:
此子组件说明了订阅者用于终止CA服务订阅的过程，包括：
* The revocation of certificates at the end of subscription (which may differ, depending on whether the end of subscription was due to the expiration of the certificate or termination of the service).
* 在订阅结束时撤销证书（这可能有所不同，取决于订阅结束是由于证书到期还是服务终止）。
This subcomponent contains the following elements to identify the policies and practices relating to the escrowing, and/or recovery of private keys where private key escrow services are available (through the CA or other trusted third parties):
此子组件包含以下元素，以确定与托管和/或私钥恢复相关的政策和实践，其中私钥托管服务可用（通过CA或其他受信任的第三方）：
* Identification of the document containing private key escrow and recovery policies and practices or a listing of such policies and practices; and
* 识别包含私钥托管和恢复政策和实践的文件或此类政策和实践的列表；和
* Identification of the document containing session key encapsulation and recovery policies and practices or a listing of such policies and practices.
* 标识包含会话密钥封装和恢复策略和实践的文档，或此类策略和实践的列表。
This component describes non-technical security controls (that is, physical, procedural, and personnel controls) used by the issuing CA to securely perform the functions of key generation, subject authentication, certificate issuance, certificate revocation, auditing, and archiving.
此组件描述了非技术性安全控制（即物理、程序和人员控制），由颁发CA用于安全地执行密钥生成、主体身份验证、证书颁发、证书撤销、审核和归档等功能。
This component can also be used to define non-technical security controls on repositories, subject CAs, RAs, subscribers, and other participants. The non-technical security controls for the subject CAs, RAs, subscribers, and other participants could be the same, similar, or very different.
此组件还可用于定义存储库、主题CA、RAs、订阅者和其他参与者的非技术安全控制。主题CA、RAs、订阅者和其他参与者的非技术安全控制可能相同、相似或非常不同。
These non-technical security controls are critical to trusting the certificates since lack of security may compromise CA operations resulting for example, in the creation of certificates or CRLs with erroneous information or compromising the CA private key.
这些非技术性的安全控制对于信任证书至关重要，因为缺乏安全性可能会危及CA操作，例如，导致使用错误信息创建证书或CRL或危及CA私钥。
Within each subcomponent, separate consideration will, in general, need to be given to each entity type, that is, the issuing CA, repository, subject CAs, RAs, subscribers, and other participants.
在每个子组件中，通常需要单独考虑每个实体类型，即发行CA、存储库、主题CA、RAs、订阅者和其他参与者。
In this subcomponent, the physical controls on the facility housing the entity systems are described. Topics addressed may include:
在本子部分中，描述了实体系统所在设施的物理控制。讨论的主题可能包括：
* Site location and construction, such as the construction requirements for high-security zones and the use of locked rooms, cages, safes, and cabinets;
* 现场位置和施工，如高安全区的施工要求以及上锁房间、笼子、保险箱和橱柜的使用；
* Physical access, i.e., mechanisms to control access from one area of the facility to another or access into high-security zones, such as locating CA operations in a secure computer room monitored by guards or security alarms and requiring movement from zone to zone to be accomplished using a token, biometric readers, and/or access control lists;
* 物理访问，即控制从设施的一个区域到另一个区域的访问或进入高安全区域的机制，例如在由警卫或安全警报监控的安全计算机室内定位CA操作，并要求使用令牌、生物识别读卡器和/或访问控制列表实现从一个区域到另一个区域的移动；
* Power and air conditioning;
* 电力和空调；
* Water exposures;
* 水暴露；
* Fire prevention and protection;
* 防火和保护；
* Media storage, for example, requiring the storage of backup media in a separate location that is physically secure and protected from fire and water damage;
* 介质存储，例如，要求将备份介质存储在物理安全且不受火灾和水损害的单独位置；
* Waste disposal; and
* 废物处理；和
* Off-site backup.
* 异地备份。
In this subcomponent, requirements for recognizing trusted roles are described, together with the responsibilities for each role. Examples of trusted roles include system administrators, security officers, and system auditors.
在此子组件中，描述了识别受信任角色的要求，以及每个角色的职责。受信任角色的示例包括系统管理员、安全官员和系统审计员。
For each task identified, the number of individuals required to perform the task (n out m rule) should be stated for each role. Identification and authentication requirements for each role may also be defined.
对于确定的每个任务，应说明每个角色执行任务所需的人员数量（n/m规则）。还可以定义每个角色的标识和身份验证要求。
This component also includes the separation of duties in terms of the roles that cannot be performed by the same individuals.
该部分还包括职责分离，即不能由同一个人执行的角色。
This subcomponent addresses the following:
此子组件涉及以下内容：
* Qualifications, experience, and clearances that personnel must have as a condition of filling trusted roles or other important roles. Examples include credentials, job experiences, and official government clearances that candidates for these positions must have before being hired;
* 作为填补受信任角色或其他重要角色的条件，人员必须具备的资格、经验和许可。例如，这些职位的候选人在被聘用前必须具备的资历、工作经验和官方政府许可证；
* Background checks and clearance procedures that are required in connection with the hiring of personnel filling trusted roles or perhaps other important roles; such roles may require a check of their criminal records, references, and additional clearances that a participant undertakes after a decision has been made to hire a particular person;
* 雇佣担任受信任角色或其他重要角色的人员所需的背景调查和批准程序；此类角色可能需要检查其犯罪记录、推荐人以及参与者在决定雇用特定人员后所进行的额外许可；
* Training requirements and training procedures for each role following the hiring of personnel;
* 雇佣人员后每个角色的培训要求和培训程序；
* Any retraining period and retraining procedures for each role after completion of initial training;
* 完成初始培训后，每个角色的任何再培训期和再培训程序；
* 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 for the purpose of imposing accountability on a participant's personnel;
* 对未经授权的行为、未经授权的使用权限和未经授权的使用实体系统的人员进行制裁，以便对参与者的人员实施问责；
* Controls on personnel that are independent contractors rather than employees of the entity; examples include:
* 对作为独立承包商而非实体员工的人员的控制；例子包括：
- Bonding requirements on contract personnel;
- 对合同人员的担保要求；
- Contractual requirements including indemnification for damages due to the actions of the contractor personnel;
- 合同要求，包括因承包商人员的行为造成的损害赔偿；
- Auditing and monitoring of contractor personnel; and
- 承包商人员的审计和监督；和
- Other controls on contracting personnel.
- 对订约人员的其他控制。
* Documentation to be supplied to personnel during initial training, retraining, or otherwise.
* 在初始培训、再培训或其他过程中向人员提供的文件。
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, such as certificate lifecycle operations, attempts to access the system, and requests made to the system;
* 记录的事件类型，例如证书生命周期操作、尝试访问系统以及向系统发出的请求；
* Frequency with which audit logs are processed or archived, for example, weekly, following an alarm or anomalous event, or when ever the audit log is n% full;
* 处理或归档审计日志的频率，例如，每周、警报或异常事件之后，或审计日志已满n%时；
* Period for which audit logs are kept;
* 保存审核日志的期限；
* Protection of audit logs:
* 审计日志的保护：
- Who can view audit logs, for example only the audit administrator;
- 谁可以查看审核日志，例如，只有审核管理员；
- Protection against modification of audit logs, for instance a requirement that no one may modify or delete the audit records or that only an audit administrator may delete an audit file as part of rotating the audit file; and
- 防止修改审计日志，例如要求任何人不得修改或删除审计记录，或者只有审计管理员可以删除审计文件，作为审计文件轮换的一部分；和
- Protection against deletion of audit logs.
- 防止删除审核日志。
* 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, for example, where audit data is run through a tool that identifies potential attempts to breach the security of the system.
* 例如，漏洞评估，其中审计数据通过一个工具运行，该工具可识别破坏系统安全性的潜在企图。
This subcomponent is used to describe general records archival (or records retention) policies, including the following:
此子组件用于描述一般记录存档（或记录保留）策略，包括以下内容：
* Types of records that are archived, for example, all audit data, certificate application information, and documentation supporting certificate applications;
* 存档的记录类型，例如，所有审核数据、证书申请信息和支持证书申请的文档；
* Retention period for an archive;
* 档案的保存期限；
* Protection of an archive:
* 保护档案：
- Who can view the archive, for example, a requirement that only the audit administrator may view the archive;
- 谁可以查看档案，例如，要求只有审核管理员可以查看档案；
- Protection against modification of the archive, such as securely storing the data on a write once medium;
- 保护档案免受修改，例如将数据安全地存储在一次写入介质上；
- Protection against deletion of the archive;
- 防止档案被删除；
- Protection against the deterioration of the media on which the archive is stored, such as a requirement for data to be migrated periodically to fresh media; and
- 防止存储归档文件的介质变质，例如要求定期将数据迁移到新介质；和
- Protection against obsolescence of hardware, operating systems, and other software, by, for example, retaining as part of the archive the hardware, operating systems, and/or other software in order to permit access to and use of archived records over time.
- 防止硬件、操作系统和其他软件过时，例如，将硬件、操作系统和/或其他软件保留为存档的一部分，以便允许访问和使用存档记录。
* Archive backup procedures;
* 档案备份程序；
* Requirements for time-stamping of records;
* 记录加盖时间戳的要求；
* Whether the archive collection system is internal or external; and
* 档案收集系统是内部的还是外部的；和
* Procedures to obtain and verify archive information, such as a requirement that two separate copies of the archive data be kept under the control of two persons, and that the two copies be compared in order to ensure that the archive information is accurate.
* 获取和验证存档信息的程序，例如要求存档数据的两份单独副本由两人控制，并对两份副本进行比较，以确保存档信息的准确性。
This subcomponent describes the procedures to provide a new public key to a CA's users following a re-key by the CA. These procedures may be the same as the procedure for providing the current key. Also, the new key may be certified in a certificate signed using the old key.
本子组件描述了在CA重新设置密钥后向CA用户提供新公钥的过程。这些过程可能与提供当前密钥的过程相同。此外，可以在使用旧密钥签名的证书中认证新密钥。
This subcomponent describes requirements relating to notification and recovery procedures in the event of compromise or disaster. Each of the following may need to be addressed separately:
本子部分描述了发生危害或灾难时与通知和恢复程序相关的要求。以下各项可能需要单独解决：
* Identification or listing of the applicable incident and compromise reporting and handling procedures.
* 确定或列出适用的事故和危害报告及处理程序。
* 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 re-established, 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 re-certified.
* 在计算资源、软件和/或数据损坏或怀疑损坏时使用的恢复过程。这些过程描述了如何重新建立安全环境、吊销哪些证书、是否吊销实体密钥、如何向用户提供新的实体公钥以及如何重新认证主体。
* The recovery procedures used if the entity key is compromised. These procedures describe how a secure environment is re-established, how the new entity public key is provided to the users, and how the subjects are re-certified.
* 实体密钥泄露时使用的恢复过程。这些过程描述了如何重新建立安全环境，如何向用户提供新的实体公钥，以及如何重新认证主体。
* The entity's capabilities to ensure business continuity following a natural or other disaster. Such capabilities may include the availability of a remote hot-site at which operations may be recovered. They may also include procedures for securing its facility during the period of time following a natural or other disaster and before a secure environment is re-established, either at the original site or at a remote site. For example, procedures to protect against theft of sensitive materials from an earthquake-damaged site.
* 实体在自然灾害或其他灾害后确保业务连续性的能力。这些功能可能包括远程热站点的可用性，在该站点上可以恢复操作。它们还可能包括在自然灾害或其他灾害发生后以及重新建立安全环境之前（无论是在原始现场还是在远程现场），保护其设施的程序。例如，防止地震破坏现场敏感材料被盗的程序。
This subcomponent describes requirements relating to procedures for termination and termination notification of a CA or RA, including the identity of the custodian of CA and RA archival records.
本子部分描述了与CA或RA终止和终止通知程序相关的要求，包括CA和RA档案记录保管人的身份。
This component is used to define the security measures taken by the issuing CA to protect its cryptographic keys and activation data (e.g., PINs, passwords, or manually-held key shares). This component may also be used to impose constraints on repositories, subject CAs, subscribers, and other participants to protect their private keys, activation data for their private 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.
此组件用于定义颁发CA为保护其加密密钥和激活数据（例如PIN、密码或手动持有的密钥共享）而采取的安全措施。此组件还可用于对存储库、主题CA、订阅者和其他参与者施加约束，以保护其私钥、私钥的激活数据和关键安全参数。安全密钥管理对于确保所有密钥和私钥以及激活数据都受到保护，并且仅由授权人员使用至关重要。
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, auditing, and archiving. Technical controls include life-cycle security controls (including software development environment security, trusted software development methodology) and operational security controls.
此组件还描述了颁发CA用于安全执行密钥生成、用户身份验证、证书注册、证书吊销、审核和归档功能的其他技术安全控制。技术控制包括生命周期安全控制（包括软件开发环境安全、可信软件开发方法）和操作安全控制。
This component can also be used to define other technical security controls on repositories, subject CAs, RAs, subscribers, and other participants.
此组件还可用于定义存储库、主题CA、RAs、订阅者和其他参与者的其他技术安全控制。
Key pair generation and installation need to be considered for the issuing CA, repositories, subject CAs, RAs, and subscribers. For each of these types of entities, the following questions potentially need to be answered:
对于颁发CA、存储库、主题CA、RAs和订阅者，需要考虑密钥对的生成和安装。对于每种类型的实体，可能需要回答以下问题：
1. Who generates the entity public, private key pair? Possibilities include the subscriber, RA, or CA. Also, how is the key generation performed? Is the key generation performed by hardware or software?
1. 谁生成实体公钥、私钥对？可能包括订户、RA或CA。此外，密钥生成是如何执行的？密钥生成是由硬件还是软件执行的？
2. How is the private key provided securely to the entity? Possibilities include a situation where the entity has generated it and therefore already has it, handing the entity the private key physically, mailing a token containing the private key securely, or delivering it in an SSL session.
2. 如何将私钥安全地提供给实体？可能的情况包括实体已经生成并因此已经拥有私钥、物理地将私钥交给实体、安全地邮寄包含私钥的令牌或在SSL会话中交付私钥。
3. How is the entity's public key provided securely to the certification authority? Some possibilities are in an online SSL session or in a message signed by the RA.
3. 实体的公钥如何安全地提供给认证机构？一些可能性存在于在线SSL会话或RA签署的消息中。
4. In the case of issuing CAs, how is the CA's public key provided securely to potential relying parties? Possibilities include handing the public key to the relying party securely in person, physically mailing a copy securely to the relying party, or delivering it in a SSL session.
4. 在颁发CA的情况下，如何将CA的公钥安全地提供给潜在的依赖方？可能包括亲自安全地将公钥交给依赖方，将副本安全地邮寄给依赖方，或在SSL会话中交付。
5. What are the key sizes? Examples include a 1,024 bit RSA modulus and a 1,024 bit DSA large prime.
5. 关键尺寸是多少？示例包括1024位RSA模和1024位DSA大素数。
6. Who generates the public key parameters, and is the quality of the parameters checked during key generation?
6. 谁生成公钥参数，在密钥生成过程中是否检查参数的质量？
7. 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 X.509 Version 3 certificates.
7. 钥匙可以用于什么目的，或者应该限制钥匙的使用用于什么目的？对于X.509证书，这些用途应映射到X.509版本3证书中的密钥使用标志。
4.6.2. Private Key Protection and Cryptographic Module Engineering Controls
4.6.2. 私钥保护和加密模块工程控制
Requirements for private key protection and cryptographic modules need to be considered for the issuing CA, repositories, subject CAs, RAs, and subscribers. For each of these types of entities, the following questions potentially need to be answered:
对于颁发CA、存储库、主体CA、RAs和订阅者，需要考虑私钥保护和加密模块的要求。对于每种类型的实体，可能需要回答以下问题：
1. What standards, if any, are required for the cryptographic module used to generate the keys? A cryptographic module can be composed of hardware, software, firmware, or any combination of them. For example, are the keys certified by the infrastructure required to be generated using modules compliant with the US FIPS 140-1? If so, what is the required FIPS 140-1 level of the module? Are there any other engineering or other controls relating to a cryptographic module, such as the 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, and self tests.
1. 用于生成密钥的加密模块需要什么标准（如果有）？加密模块可以由硬件、软件、固件或它们的任意组合组成。例如，是否需要使用符合美国FIPS 140-1的模块生成基础设施认证的密钥？如果是，模块所需的FIPS 140-1级别是什么？是否存在与加密模块相关的任何其他工程或其他控制，例如加密模块边界的标识、输入/输出、角色和服务、有限状态机、物理安全、软件安全、操作系统安全、算法符合性、电磁兼容性和自检。
2. Is the private key under n out of m multi-person control?(7) If yes, provide n and m (two person control is a special case of n out of m, where n = m = 2)?
2. 私钥是否在n out of m多人控制下？（7）如果是，请提供n和m（两人控制是n out of m的特例，其中n=m=2）？
3. Is the private key escrowed?(8) 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. 是否托管私钥？（8）如果是，谁是托管代理，托管密钥的形式是什么（示例包括明文、加密、拆分密钥），托管系统的安全控制是什么？
4. 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?
4. 私钥是否已备份？如果是，谁是备份代理，备份密钥的形式是什么（示例包括明文、加密、拆分密钥），以及备份系统上的安全控制是什么？
5. 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. 私钥是否已存档？如果是，谁是存档代理，密钥以何种形式存档（示例包括明文、加密、拆分密钥），以及存档系统上的安全控制是什么？
6. Under what circumstances, if any, can a private key be transferred into or from a cryptographic module? Who is permitted to perform such a transfer operation? In what form is the private key during the transfer (i.e., plaintext, encrypted, or split key)?
6. 在什么情况下（如果有的话），可以将私钥传输到加密模块或从加密模块传输私钥？允许谁执行此类转移操作？在传输过程中，私钥的形式是什么（即，明文、加密或分割密钥）？
7. How is the private key stored in the module (i.e., plaintext, encrypted, or split key)?
7. 私钥如何存储在模块中（即，明文、加密或拆分密钥）？
8. 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. 谁可以激活（使用）私钥？激活私钥必须执行哪些操作（例如登录、通电、电源PIN、插入令牌/密钥、自动等）？一旦钥匙被激活，钥匙是无限期激活、一次激活还是在规定的时间段内激活？
9. Who can deactivate the private key and how? Examples of methods of deactivating private keys include logging out, turning the power off, removing the token/key, automatic deactivation, and time expiration.
9. 谁可以停用私钥？如何停用？停用私钥的方法的示例包括注销、关闭电源、移除令牌/密钥、自动停用和过期。
10. Who can destroy the private key and how? Examples of methods of destroying private keys include token surrender, token destruction, and overwriting the key.
10. 谁可以销毁私钥？如何销毁？销毁私钥的方法的示例包括令牌放弃、令牌销毁和覆盖密钥。
11. Provide the capabilities of the cryptographic module in the following areas: 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, and self tests. Capability may be expressed through reference to compliance with a standard such as U.S. FIPS 140-1, associated level, and rating.
11. 在以下方面提供加密模块的功能：识别加密模块边界、输入/输出、角色和服务、有限状态机、物理安全、软件安全、操作系统安全、算法遵从性、电磁兼容性和自检。可通过参考符合标准（如美国FIPS 140-1、相关等级和评级）来表示能力。
Other aspects of key management need to be considered for the issuing CA, repositories, subject CAs, RAs, subscribers, and other participants. For each of these types of entities, the following questions potentially need to be answered:
颁发CA、存储库、主题CA、RAs、订阅者和其他参与者需要考虑密钥管理的其他方面。对于每种类型的实体，可能需要回答以下问题：
1. Is the public key archived? If so, who is the archival agent and what are the security controls on the archival system? Also, what software and hardware need to be preserved as part of the archive to permit use of the public key over time? Note: this subcomponent is not limited to requiring or describing the use of digital signatures with archival data, but rather can address integrity controls other than digital signatures when an archive requires tamper protection. Digital signatures do not provide tamper protection or protect the integrity of data; they merely verify data integrity. Moreover, the archival period may be greater than the cryptanalysis period for the public key needed to verify any digital signature applied to archival data.
1. 公钥是否已存档？如果是，谁是档案代理人，档案系统的安全控制是什么？此外，需要将哪些软件和硬件作为存档的一部分进行保存，以允许随着时间的推移使用公钥？注：此子组件不限于要求或描述对存档数据使用数字签名，而是可以在存档需要篡改保护时解决除数字签名以外的完整性控制。数字签名不提供篡改保护或保护数据的完整性；它们只是验证数据的完整性。此外，存档周期可能大于验证应用于存档数据的任何数字签名所需的公钥的密码分析周期。
2. What is the operational period of the certificates issued to the subscriber. What are the usage periods, or active lifetimes, for the subscriber's key pair?
2. 向认购人颁发的证书的有效期是多久。订户密钥对的使用周期或有效寿命是多少？
Activation data refers to data values other than whole private keys that are required to operate private keys or cryptographic modules containing private keys, such as a PIN, passphrase, or portions of a private key used in a key-splitting scheme. Protection of activation data prevents unauthorized use of the private key, and potentially needs to be considered for the issuing CA, subject CAs, RAs, and subscribers. Such consideration potentially needs to address the entire life-cycle of the activation data from generation through archival and destruction. For each of the entity types (issuing CA, repository, subject CA, RA, subscriber, and other participants), all of the questions listed in 4.6.1 through 4.6.3 potentially need to be answered with respect to activation data rather than with respect to keys.
激活数据是指操作私钥或包含私钥的加密模块（如PIN、密码短语或密钥分割方案中使用的私钥部分）所需的除整个私钥以外的数据值。保护激活数据可防止私钥的未经授权使用，并且可能需要考虑颁发CA、主体CA、RAs和订户。这种考虑可能需要解决激活数据从生成到存档和销毁的整个生命周期。对于每种实体类型（颁发CA、存储库、主体CA、RA、订户和其他参与者），4.6.1至4.6.3中列出的所有问题都可能需要回答激活数据方面的问题，而不是密钥方面的问题。
This subcomponent is used to describe computer security controls such as: use of the trusted computing base concept, discretionary access control, labels, mandatory access controls, object re-use, audit, identification and authentication, trusted path, security testing, and penetration testing. Product assurance may also be addressed.
此子组件用于描述计算机安全控制，例如：可信计算基础概念的使用、自主访问控制、标签、强制访问控制、对象重用、审核、标识和身份验证、可信路径、安全测试和渗透测试。还可以解决产品保证问题。
A computer security rating for computer systems may be required. The rating could be based, for example, on the Trusted System Evaluation Criteria (TCSEC), Canadian Trusted Products Evaluation Criteria, European Information Technology Security Evaluation Criteria (ITSEC), or the Common Criteria for Information Technology Security Evaluation, ISO/IEC 15408:1999. This subcomponent can also address requirements for product evaluation analysis, testing, profiling, product certification, and/or product accreditation related activity undertaken.
可能需要计算机系统的计算机安全等级。例如，评级可以基于可信系统评估标准（TCSEC）、加拿大可信产品评估标准、欧洲信息技术安全评估标准（ITSEC）或信息技术安全评估通用标准ISO/IEC 15408:1999。该子组件还可以满足产品评估分析、测试、分析、产品认证和/或产品认证相关活动的要求。
This subcomponent addresses 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 failsafe design and 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.
安全管理控制包括执行工具和程序，以确保操作系统和网络遵守配置的安全。这些工具和程序包括检查安全软件、固件和硬件的完整性，以确保其正确运行。
This subcomponent can also address life-cycle security ratings based, for example, on the Trusted Software Development Methodology (TSDM) level IV and V, independent life-cycle security controls audit, and the Software Engineering Institute's Capability Maturity Model (SEI-CMM).
该子组件还可以基于可信软件开发方法（TSDM）第四和第五级、独立生命周期安全控制审计和软件工程研究所的能力成熟度模型（SEI-CMM）来处理生命周期安全评级。
This subcomponent addresses network security related controls, including firewalls.
此子组件处理与网络安全相关的控制，包括防火墙。
This subcomponent addresses requirements or practices relating to the use of timestamps on various data. It may also discuss whether or not the time-stamping application must use a trusted time source.
本子组件阐述了与在各种数据上使用时间戳相关的要求或实践。它还可能讨论时间戳应用程序是否必须使用受信任的时间源。
This component is used to specify the certificate format and, if CRLs and/or OCSP are used, the CRL and/or OCSP format. This includes information on profiles, versions, and extensions used.
此组件用于指定证书格式，如果使用CRL和/或OCSP，则指定CRL和/或OCSP格式。这包括有关使用的配置文件、版本和扩展的信息。
This subcomponent addresses such topics as the following (potentially by reference to a separate profile definition, such as the one defined in IETF PKIX RFC 3280):
本子组件涉及以下主题（可能通过参考单独的配置文件定义，如IETF PKIX RFC 3280中定义的配置文件定义）：
* Version number(s) supported;
* 支持的版本号；
* Certificate extensions populated and their criticality;
* 证书扩展及其重要性；
* Cryptographic algorithm object identifiers;
* 加密算法；对象标识符；
* Name forms used for the CA, RA, and subscriber names;
* 用于CA、RA和订户名称的名称表格；
* Name constraints used and the name forms used in the name constraints;
* 使用的名称约束和名称约束中使用的名称形式；
* Applicable CP OID(s);
* 适用的CP OID；
* Usage of the policy constraints extension;
* 政策约束扩展的使用；
* Policy qualifiers syntax and semantics; and
* 策略限定符语法和语义；和
* Processing semantics for the critical CP extension.
* 关键CP扩展的处理语义。
This subcomponent addresses such topics as the following (potentially by reference to a separate profile definition, such as the one defined in IETF PKIX RFC 3280):
本子组件涉及以下主题（可能通过参考单独的配置文件定义，如IETF PKIX RFC 3280中定义的配置文件定义）：
* Version numbers supported for CRLs; and
* CRL支持的版本号；和
* CRL and CRL entry extensions populated and their criticality.
* 已填充CRL和CRL入口扩展及其关键性。
This subcomponent addresses such topics as the following (potentially by reference to a separate profile definition, such as the IETF RFC 2560 profile):
本子组件涉及以下主题（可能通过参考单独的概要定义，如IETF RFC 2560概要）：
* Version of OCSP that is being used as the basis for establishing an OCSP system; and
* 作为建立OCSP系统基础的OCSP版本；和
* OCSP extensions populated and their criticality.
* OCSP扩展及其关键性。
This component addresses the following:
该组件解决以下问题：
* The list of topics covered by the assessment and/or the assessment methodology used to perform the assessment; examples include WebTrust for CAs (9) and SAS 70 (10).
* 评估涵盖的主题列表和/或用于执行评估的评估方法；示例包括针对CAs的WebTrust（9）和SAS 70（10）。
* Frequency of compliance audit or other assessment for each entity that must be assessed pursuant to a CP or CPS, or the circumstances that will trigger an assessment; possibilities include an annual audit, pre-operational assessment as a condition of allowing an entity to be operational, or investigation following a possible or actual compromise of security.
* 必须根据CP或CP进行评估的每个实体的合规审计或其他评估频率，或将触发评估的情况；可能性包括年度审计、作为允许实体运营的条件的运营前评估，或在可能或实际的安全危害后进行调查。
* The identity and/or qualifications of the personnel performing the audit or other assessment.
* 执行审计或其他评估的人员的身份和/或资格。
* The relationship between the assessor and the entity being assessed, including the degree of independence of the assessor.
* 评估员与被评估实体之间的关系，包括评估员的独立程度。
* Actions taken as a result of deficiencies found during the assessment; examples include a temporary suspension of operations until deficiencies are corrected, revocation of certificates issued to the assessed entity, changes in personnel, triggering special investigations or more frequent subsequent compliance assessments, and claims for damages against the assessed entity.
* 因评估期间发现的缺陷而采取的措施；例如，在缺陷得到纠正之前暂时暂停运营，撤销向被评估实体颁发的证书，更换人员，触发特别调查或更频繁的后续合规性评估，以及向被评估实体索赔损失。
* Who is entitled to see results of an assessment (e.g., assessed entity, other participants, the general public), who provides them (e.g., the assessor or the assessed entity), and how they are communicated.
* 谁有权查看评估结果（例如，评估实体、其他参与者、公众），谁提供评估结果（例如，评估员或评估实体），以及如何传达评估结果。
This component covers general business and legal matters. Sections 9.1 and 9.2 of the framework discuss the business issues of fees to be charged for various services and the financial responsibility of participants to maintain resources for ongoing operations and for paying judgments or settlements in response to claims asserted against them. The remaining sections are generally concerned with legal topics.
本部分涵盖一般业务和法律事项。框架第9.1节和第9.2节讨论了各种服务收费的业务问题，以及参与者维护持续运营资源和支付判决或结算以回应对其提出的索赔的财务责任。其余各节一般涉及法律主题。
Starting with Section 9.3 of the framework, the ordering of topics is the same as or similar to the ordering of topics in a typical software licensing agreement or other technology agreement. Consequently, this framework may not only be used for CPs and CPSs, but also associated PKI-related agreements, especially subscriber agreements, and relying party agreements. This ordering is intended help lawyers review CPs, CPSs, and other documents adhering to this framework.
从框架第9.3节开始，主题的顺序与典型软件许可协议或其他技术协议中主题的顺序相同或类似。因此，该框架不仅可用于CP和CP，还可用于相关的PKI相关协议，特别是订户协议和依赖方协议。此命令旨在帮助律师审查CPs、CPs和遵守此框架的其他文件。
With respect to many of the legal subcomponents within this component, a CP or CPS drafter may choose to include in the document terms and conditions that apply directly to subscribers or relying parties. For instance, a CP or CPS may set forth limitations of liability that apply to subscribers and relying parties. The inclusion of terms and conditions is likely to be appropriate where the CP or CPS is itself a contract or part of a contract.
对于本部分中的许多法律子部分，CP或CPS起草人可选择在文件中包含直接适用于认购方或依赖方的条款和条件。例如，CP或CP可规定适用于认购方和依赖方的责任限制。如果CP或CP本身是合同或合同的一部分，则包含条款和条件可能是适当的。
In other cases, however, the CP or CPS is not a contract or part of a contract; instead, it is configured so that its terms and conditions are applied to the parties by separate documents, which may include associated agreements, such as subscriber or relying party agreements. In that event, a CP drafter may write a CP so as to require that certain legal terms and conditions appear (or not appear) in such associated agreements. For example, a CP might include a subcomponent stating that a certain limitation of liability term must appear in a CA's subscriber and relying party agreements. Another example is a CP that contains a subcomponent prohibiting the use of a subscriber or relying party agreement containing a limitation upon CA liability inconsistent with the provisions of the CP. A CPS drafter may use legal subcomponents to disclose that certain terms and conditions appear in associated subscriber, relying party, or other agreements in use by the CA. A CPS might explain, for instance, that the CA writing it uses an associated subscriber or relying party agreement that applies a particular provision for limiting liability.
但是，在其他情况下，CP或CPS不是合同或合同的一部分；相反，它的配置使其条款和条件通过单独的文件适用于各方，其中可能包括相关协议，如认购方或依赖方协议。在这种情况下，CP起草人可以编写CP，以要求在此类相关协议中出现（或不出现）某些法律条款和条件。例如，CP可能包含一个子组件，声明CA的订户和依赖方协议中必须出现特定的责任限制条款。另一个例子是CP，该CP包含禁止使用订户或依赖方协议的子组件，该协议包含与CP规定不一致的CA责任限制。CPS起草人可使用法律子组件披露相关订户、依赖方、，或CA正在使用的其他协议。例如，CPS可能会解释，CA使用关联订户或依赖方协议，该协议适用特定的责任限制条款。
This subcomponent contains any applicable provisions regarding fees charged by CAs, repositories, or RAs, such as:
本子部分包含有关CAs、存储库或RAs收费的任何适用规定，例如：
* Certificate issuance or renewal fees;
* 证书颁发或续期费用；
* Certificate access fees;
* 证书使用费；
* Revocation or status information access fees;
* 撤销或状态信息访问费；
* Fees for other services such as providing access to the relevant CP or CPS; and
* 其他服务的费用，如提供相关CP或CP的访问权；和
* Refund policy.
* 退款政策。
This subcomponent contains requirements or disclosures relating to the resources available to CAs, RAs, and other participants providing certification services to support performance of their operational PKI responsibilities, and to remain solvent and pay damages in the event they are liable to pay a judgment or settlement in connection with a claim arising out of such operations. Such provisions include:
本子部分包含与CAs、RAs和其他提供认证服务以支持履行其运营PKI职责的参与者可用资源相关的要求或披露，如果他们有责任支付与此类操作引起的索赔相关的判决或和解，则保持偿付能力并支付损害赔偿金。这些规定包括：
* A statement that the participant maintains a certain amount of insurance coverage for its liabilities to other participants;
* 一份声明，表明该参与人为其对其他参与人的负债维持一定金额的保险范围；
* A statement that a participant has access to other resources to support operations and pay damages for potential liability, which may be couched in terms of a minimum level of assets necessary to operate and cover contingencies that might occur within a PKI, where examples include assets on the balance sheet of an organization, a surety bond, a letter of credit, and a right under an agreement to an indemnity under certain circumstances; and
* 一份声明，表明参与者有权获得其他资源以支持运营并支付潜在负债的损害赔偿金，该声明可以按照运营所需的最低资产水平来表述，并涵盖PKI内可能发生的意外事件，其中示例包括组织资产负债表上的资产、担保债券，信用证，以及在特定情况下根据协议获得赔偿的权利；和
* A statement that a participant has a program that offers first-party insurance or warranty protection to other participants in connection with their use of the PKI.
* 一份声明，表明参与者拥有一项计划，该计划向其他参与者提供与PKI使用相关的第一方保险或保修保护。
This subcomponent contains provisions relating to the treatment of confidential business information that participants may communicate to each other, such as business plans, sales information, trade secrets, and information received from a third party under a nondisclosure agreement. Specifically, this subcomponent addresses:
本子部分包含与参与者可能相互交流的机密商业信息处理相关的规定，如商业计划、销售信息、商业秘密以及根据保密协议从第三方收到的信息。具体而言，本子组件涉及：
* The scope of what is considered confidential information,
* 被视为机密信息的范围，
* The types of information that are considered to be outside the scope of confidential information, and
* 被认为不属于保密信息范围的信息类型，以及
* The responsibilities of participants that receive confidential information to secure it from compromise, and refrain from using it or disclosing it to third parties.
* 接受保密信息的参与者有责任确保保密信息不被泄露，并避免使用保密信息或向第三方披露保密信息。
This subcomponent relates to the protection that participants, particularly CAs, RAs, and repositories, may be required to afford to personally identifiable private information of certificate applicants, subscribers, and other participants. Specifically, this subcomponent addresses the following, to the extent pertinent under applicable law:
此子组件涉及参与者（尤其是CA、RAs和存储库）可能需要提供的保护，以提供证书申请人、订阅者和其他参与者的个人可识别私人信息。具体而言，本子部分在适用法律规定的范围内涉及以下内容：
* The designation and disclosure of the applicable privacy plan that applies to a participant's activities, if required by applicable law or policy;
* 如果适用法律或政策要求，指定和披露适用于参与者活动的适用隐私计划；
* Information that is or is not considered private within the PKI;
* 在PKI中被认为是或不是私有的信息；
* Any responsibility of participants that receive private information to secure it, and refrain from using it and from disclosing it to third parties;
* 接收私人信息的参与者有责任确保其安全，并避免使用该信息和向第三方披露该信息；
* Any requirements as to notices to, or consent from individuals regarding use or disclosure of private information; and
* 关于个人使用或披露私人信息的通知或同意的任何要求；和
* Any circumstances under which a participant is entitled or required to disclose private information pursuant to judicial, administrative process in a private or governmental proceeding, or in any legal proceeding.
* 在任何情况下，参与者有权或被要求在私人或政府诉讼或任何法律诉讼中根据司法、行政程序披露私人信息。
This subcomponent addresses the intellectual property rights, such as copyright, patent, trademarks, or trade secrets, that certain participants may have or claim in a CP, CPS, certificates, names, and keys, or are the subject of a license to or from participants.
本子部分涉及某些参与者可能拥有或在CP、CPS、证书、名称和密钥中主张的知识产权，如版权、专利、商标或商业秘密，或者是参与者许可证的主体。
This subcomponent can include representations and warranties of various entities that are being made pursuant to the CP or CPS. For example, a CPS that serves as a contract might contain a CA's warranty that information contained in the certificate is accurate. Alternatively, a CPS might contain a less extensive warranty to the effect that the information in the certificate is true to the best of the CA's knowledge after performing certain identity authentication procedures with due diligence. This subcomponent can also include requirements that representations and warranties appear in certain agreements, such as subscriber or relying party agreements. For instance, a CP may contain a requirement that all CAs utilize a subscriber agreement, and that a subscriber agreement must contain a
本子部分可包括根据CP或CPS作出的各实体的陈述和保证。例如，用作合同的CPS可能包含CA的保证，即证书中包含的信息是准确的。或者，CPS可能包含一个不太广泛的保证，即证书中的信息在经过尽职调查执行某些身份验证程序后，据CA所知是真实的。此子组件还可以包括某些协议中出现的陈述和保证的要求，如订户或依赖方协议。例如，CP可能包含所有CA使用订户协议的要求，并且订户协议必须包含
warranty by the CA that information in the certificate is accurate. Participants that may make representations and warranties include CAs, RAs, subscribers, relying parties, and other participants.
CA保证证书中的信息准确无误。可能作出陈述和保证的参与者包括CAs、RAs、订户、依赖方和其他参与者。
This subcomponent can include disclaimers of express warranties that may otherwise be deemed to exist in an agreement, and disclaimers of implied warranties that may otherwise be imposed by applicable law, such as warranties of merchantability or fitness for a particular purpose. The CP or CPS may directly impose such disclaimers, or the CP or CPS may contain a requirement that disclaimers appear in associated agreements, such as subscriber or relying party agreements.
本子部分可包括对协议中可能存在的明示保证的免责声明，以及对适用法律可能施加的默示保证的免责声明，如适销性或特定用途适用性的保证。CP或CPS可直接施加此类免责声明，或CP或CPS可包含相关协议中出现免责声明的要求，如认购方或依赖方协议。
This subcomponent can include limitations of liability in a CP or CPS or limitations that appear or must appear in an agreement associated with the CP or CPS, such as a subscriber or relying party agreement. These limitations may fall into one of two categories: limitations on the elements of damages recoverable and limitations on the amount of damages recoverable, also known as liability caps. Often, contracts contain clauses preventing the recovery of elements of damages such as incidental and consequential damages, and sometimes punitive damages. Frequently, contracts contain clauses that limit the possible recovery of one party or the other to an amount certain or to an amount corresponding to a benchmark, such as the amount a vendor was paid under the contract.
该子部分可包括CP或CP中的责任限制，或与CP或CP相关的协议中出现或必须出现的限制，如订户或依赖方协议。这些限制可分为两类：对可收回损害赔偿要素的限制和对可收回损害赔偿金额的限制，也称为责任上限。通常，合同包含防止追偿附带和后果性损害赔偿等损害要素的条款，有时还包括惩罚性损害赔偿。通常，合同包含的条款将一方或另一方可能收回的金额限制在一定的金额或与基准相对应的金额，例如供应商根据合同支付的金额。
This subcomponent includes provisions by which one party makes a second party whole for losses or damage incurred by the second party, typically arising out of the first party's conduct. They may appear in a CP, CPS, or agreement. For example, a CP may require that subscriber agreements contain a term under which a subscriber is responsible for indemnifying a CA for losses the CA sustains arising out of a subscriber's fraudulent misrepresentations on the certificate application under which the CA issued the subscriber an inaccurate certificate. Similarly, a CPS may say that a CA uses a relying party agreement, under which relying parties are responsible for indemnifying a CA for losses the CA sustains arising out of use of a certificate without properly checking revocation information or use of a certificate for purposes beyond what the CA permits.
本子部分包括一方就第二方遭受的损失或损害（通常由第一方的行为引起）向第二方作出赔偿的规定。它们可能出现在CP、CPS或协议中。例如，CP可能要求认购人协议包含一项条款，根据该条款，认购人负责赔偿CA因认购人在证书申请中的欺诈性失实陈述而遭受的损失，根据该欺诈性失实陈述，CA向认购人颁发了不准确的证书。类似地，CPS可能会说CA使用依赖方协议，根据该协议，依赖方负责赔偿CA因使用证书而遭受的损失，而无需正确检查撤销信息或出于CA许可以外的目的使用证书。
This subcomponent can include the time period in which a CP or a CPS remains in force and the circumstances under which the document, portions of the document, or its applicability to a particular participant can be terminated. In addition or alternatively, the CP or CPS may include requirements that certain term and termination clauses appear in agreements, such as subscriber or relying party agreements. In particular, such terms can include:
本子部分可包括CP或CP保持有效的时间段，以及文件、文件部分或其对特定参与者的适用性可终止的情况。此外，CP或CP可包括协议中出现某些条款和终止条款的要求，如认购方或依赖方协议。具体而言，此类术语可包括：
* The term of a document or agreement, that is, when the document becomes effective and when it expires if it is not terminated earlier.
* 文件或协议的期限，即文件生效时，如果文件未提前终止，则文件到期时。
* Termination provisions stating circumstances under which the document, certain portions of it, or its application to a particular participant ceases to remain in effect.
* 终止条款，说明文件、文件的某些部分或其对特定参与者的应用在何种情况下不再有效。
* Any consequences of termination of the document. For example, certain provisions of an agreement may survive its termination and remain in force. Examples include acknowledgements of intellectual property rights and confidentiality provisions. Also, termination may trigger a responsibility of parties to return confidential information to the party that disclosed it.
* 本文件终止的任何后果。例如，协议的某些条款可能在协议终止后继续有效。例如承认知识产权和保密条款。此外，终止可能会导致双方有责任将保密信息返还给披露方。
This subcomponent discusses the way in which one participant can or must communicate with another participant on a one-to-one basis in order for such communications to be legally effective. For example, an RA may wish to inform the CA that it wishes to terminate its agreement with the CA. This subcomponent is different from publication and repository functions, because unlike individual communications described in this subcomponent, publication and posting to a repository are for the purpose of communicating to a wide audience of recipients, such as all relying parties. This subcomponent may establish mechanisms for communication and indicate the contact information to be used to route such communications, such as digitally signed e-mail notices to a specified address, followed by a signed e-mail acknowledgement of receipt.
本子部分讨论了一个参与者可以或必须与另一个参与者进行一对一沟通的方式，以使此类沟通具有法律效力。例如，RA可能希望通知CA其希望终止与CA的协议。此子组件不同于发布和存储库功能，因为与此子组件中描述的个人通信不同，发布和发布到存储库是为了与广泛的接收者（如所有依赖方）进行沟通。该子组件可建立通信机制，并指示用于路由此类通信的联系信息，例如数字签名电子邮件通知到指定地址，然后是签名电子邮件接收确认。
It will occasionally be necessary to amend a CP or CPS. Some of these changes will not materially reduce the assurance that a CP or its implementation provides, and will be judged by the policy administrator to have an insignificant effect on the acceptability of certificates. Such changes to a CP or CPS need not require a change
有时需要修改CP或CPS。其中一些变更不会实质性降低CP或其实施提供的保证，并且保单管理人会判断这些变更对证书的可接受性影响不大。CP或CP的此类变更无需变更
in the CP OID or the CPS pointer (URL). On the other hand, some changes to a specification will materially change the acceptability of certificates for specific purposes, and these changes may require corresponding changes to the CP OID or CPS pointer qualifier (URL).
在CP OID或CPS指针（URL）中。另一方面，对规范的某些更改将实质性地改变特定用途证书的可接受性，这些更改可能需要对CP OID或CPS指针限定符（URL）进行相应的更改。
This subcomponent may also contain the following information:
此子组件还可能包含以下信息：
* The procedures by which the CP or CPS and/or other documents must, may be, or are amended. In the case of CP or CPS amendments, change procedures may include a notification mechanism to provide notice of proposed amendments to affected parties, such as subscribers and relying parties, a comment period, a mechanism by which comments are received, reviewed and incorporated into the document, and a mechanism by which amendments become final and effective.
* CP或CPS和/或其他文件必须、可能或修订的程序。在CP或CPS修订的情况下，变更程序可能包括向受影响方（如认购方和依赖方）提供拟议修订通知的通知机制、评论期、接收、审查评论并将其纳入文件的机制，以及修正案最终生效的机制。
* The circumstances under which amendments to the CP or CPS would require a change in CP OID or CPS pointer (URL).
* 对CP或CPS的修改需要更改CP OID或CPS指针（URL）的情况。
This subcomponent discusses procedures utilized to resolve disputes arising out of the CP, CPS, and/or agreements. Examples of such procedures include requirements that disputes be resolved in a certain forum or by alternative dispute resolution mechanisms.
本子部分讨论了用于解决CP、CPS和/或协议引起的争议的程序。这类程序的例子包括要求在某一论坛或通过其他争端解决机制解决争端。
This subcomponent sets forth a statement that the law of a certain jurisdiction governs the interpretation and enforcement of the subject CP or CPS or agreements.
本子部分陈述了某一司法管辖区的法律管辖主体CP或CP或协议的解释和执行。
This subcomponent relates to stated requirements that participants comply with applicable law, for example, laws relating to cryptographic hardware and software that may be subject to the export control laws of a given jurisdiction. The CP or CPS could purport to impose such requirements or may require that such provisions appear in other agreements.
本子部分涉及参与者遵守适用法律的规定要求，例如，与密码硬件和软件相关的法律，这些法律可能受特定管辖区出口管制法律的约束。CP或CPS可能声称实施此类要求，或可能要求此类规定出现在其他协议中。
This subcomponent contains miscellaneous provisions, sometimes called "boilerplate provisions," in contracts. The clauses covered in this subcomponent may appear in a CP, CPS, or agreements and include:
该子部分包含合同中的杂项条款，有时称为“样板条款”。本子部分涵盖的条款可能出现在CP、CPS或协议中，包括：
* An entire agreement clause, which typically identifies the document or documents comprising the entire agreement between the parties and states that such agreements supersede all prior and contemporaneous written or oral understandings relating to the same subject matter;
* 完整协议条款，该条款通常确定了构成双方之间完整协议的一份或多份文件，并声明此类协议取代与同一标的物有关的所有先前和同期书面或口头谅解；
* An assignment clause, which may act to limit the ability of a party in an agreement, assigning its rights under the agreement to another party (such as the right to receive a stream of payments in the future) or limiting the ability of a party to delegate its obligations under the agreement;
* 转让条款，可限制协议一方的能力，将其在本协议下的权利转让给另一方（如未来收到一系列付款的权利），或限制一方根据本协议委托其义务的能力；
* A severability clause, which sets forth the intentions of the parties in the event that a court or other tribunal determines that a clause within an agreement is, for some reason, invalid or unenforceable, and whose purpose is frequently to prevent the unenforceability of one clause from causing the whole agreement to be unenforceable; and
* 可分割条款，当法院或其他法庭确定协议中的某一条款因某种原因无效或不可执行时，该条款规定了双方的意图，其目的通常是防止某一条款的不可执行性导致整个协议不可执行；和
* An enforcement clause, which may state that a party prevailing in any dispute arising out of an agreement is entitled to attorneys' fees as part of its recovery, or may state that a party's waiver of one breach of contract does not constitute a continuing waiver or a future waiver of other breaches of contract.
* 强制执行条款，该条款可以规定，在协议引起的任何争议中胜诉的一方有权获得律师费作为其追偿的一部分，或者可以规定，一方放弃一项违约行为并不构成对其他违约行为的持续放弃或未来放弃。
* A force majeure clause, commonly used to excuse the performance of one or more parties to an agreement due to an event outside the reasonable control of the affected party or parties. Typically, the duration of the excused performance is commensurate with the duration of the delay caused by the event. The clause may also provide for the termination of the agreement under specified circumstances and conditions. Events considered to constitute a "force majeure" may include so-called "Acts of God," wars, terrorism, strikes, natural disasters, failures of suppliers or vendors to perform, or failures of the Internet or other infrastructure. Force majeure clauses should be drafted so as to be consistent with other portions of the framework and applicable service level agreements. For instance, responsibilities and capabilities for business continuity and disaster recovery may place some events within the reasonable control of the parties, such as an obligation to maintain backup electrical power in the face of power outages.
* 不可抗力条款，通常用于免除一方或多方因受影响方合理控制范围之外的事件而履行协议的责任。通常，免责履行的持续时间与事件造成的延迟的持续时间相当。本条款还可规定在特定情况和条件下终止本协议。被视为“不可抗力”的事件可能包括所谓的“天灾”、战争、恐怖主义、罢工、自然灾害、供应商或供应商未能履行义务，或互联网或其他基础设施故障。不可抗力条款的起草应与框架的其他部分和适用的服务水平协议保持一致。例如，业务连续性和灾难恢复的责任和能力可能会将某些事件置于双方的合理控制范围内，例如在停电情况下维护备用电源的义务。
This subcomponent is a "catchall" location where additional responsibilities and terms can be imposed on PKI participants that do not neatly fit within one of the other components or subcomponents of the framework. CP and CPS writers can place any provision within this subcomponent that is not covered by another subcomponent.
该子组件是一个“总括”位置，在该位置，如果PKI参与者不适合框架的其他组件或子组件之一，则可以对其施加额外的责任和条款。CP和CPS编写者可以在此子组件中放置其他子组件未涵盖的任何条款。
According to X.509, a certificate policy (CP) is "a named set of rules that indicates the applicability of a certificate to a particular community and/or class of applications with common security requirements." A CP may be used by a relying party to help in deciding whether a certificate, and the binding therein, are sufficiently trustworthy and otherwise appropriate for a particular application.
根据X.509，证书策略（CP）是“一组指定的规则，表明证书适用于具有共同安全要求的特定社区和/或应用程序类别。”依赖方可使用CP帮助决定证书是否有效，以及其中的约束，足够值得信赖，并且适用于特定应用。
The degree to which a relying party can trust the binding embodied in a certificate depends on several factors. These factors can include the practices followed by the certification authority (CA) in authenticating the subject; the CA's operating policy, procedures, and technical security controls, including the scope of the subscriber's responsibilities (for example, in protecting the private key), and the stated responsibilities and liability terms and conditions of the CA (for example, warranties, disclaimers of warranties, and limitations of liability).
依赖方对证书中包含的约束的信任程度取决于几个因素。这些因素包括认证机构（CA）在认证主体时遵循的实践；CA的操作政策、程序和技术安全控制，包括订阅者的责任范围（例如，保护私钥），以及CA规定的责任和责任条款和条件（例如，保证、保证免责声明和责任限制）。
This document provides a framework to address technical, procedural, personnel, and physical security aspects of Certification Authorities, Registration Authorities, repositories, subscribers, and relying party cryptographic modules, in order to ensure that the certificate generation, publication, renewal, re-key, usage, and revocation is done in a secure manner. Specifically, Section 4.3 Identification and Authentication (I&A); Section 4.4 Certificate Life-Cycle Operational Requirements; Section 4.5 Facility Management, and Operational Controls; Section 4.6 Technical Security Controls; Section 4.7 Certificate CRL, and OCSP Profiles; and Section 4.8 Compliance Audit and Other Assessment, are oriented towards ensuring secure operation of the PKI entities such as CA, RA, repository, subscriber systems, and relying party systems.
本文档提供了一个框架，用于解决证书颁发机构、注册机构、存储库、订阅者和依赖方加密模块的技术、程序、人员和物理安全方面的问题，以确保证书的生成、发布、续订、重设密钥、使用、，撤销是以安全的方式进行的。具体而言，第4.3节识别和认证（I&A）；第4.4节证书生命周期运行要求；第4.5节设施管理和运营控制；第4.6节技术安全控制；第4.7节证书CRL和OCSP概要；第4.8节合规性审计和其他评估旨在确保PKI实体（如CA、RA、存储库、订户系统和依赖方系统）的安全运行。
This section contains a recommended outline for a set of provisions, intended to serve as a checklist or (with some further development) a standard template for use by CP or CPS writers. Such a common outline will facilitate:
本节包含一套条款的建议大纲，旨在作为CP或CPS编写者使用的检查表或标准模板（进一步发展）。这种共同大纲将有助于：
(a) Comparison of two certificate policies during cross-certification or other forms of interoperation (for the purpose of equivalency mapping).
(a) 在交叉认证或其他形式的互操作过程中比较两种证书策略（用于等价映射）。
(b) Comparison of a CPS with a CP to ensure that the CPS faithfully implements the policy.
(b) 将CP与CP进行比较，以确保CP忠实地执行策略。
(c) Comparison of two CPSs.
(c) 两种CP的比较。
In order to comply with the RFC, the drafters of a compliant CP or CPS are strongly advised to adhere to this outline. While use of an alternate outline is discouraged, it may be accepted if a proper justification is provided for the deviation and a mapping table is provided to readily discern where each of the items described in this outline is provided.
为了遵守RFC，强烈建议合规CP或CP的起草人遵守本大纲。虽然不鼓励使用备用大纲，但如果为偏差提供了适当的理由，并且提供了映射表，以便于识别在何处提供了本大纲中描述的每个项目，则可以接受备用大纲。
1. INTRODUCTION 1.1 Overview 1.2 Document name and identification 1.3 PKI participants 1.3.1 Certification authorities 1.3.2 Registration authorities 1.3.3 Subscribers 1.3.4 Relying parties 1.3.5 Other participants 1.4 Certificate usage 1.4.1. Appropriate certificate uses 1.4.2 Prohibited certificate uses 1.5 Policy administration 1.5.1 Organization administering the document 1.5.2 Contact person 1.5.3 Person determining CPS suitability for the policy 1.5.4 CPS approval procedures 1.6 Definitions and acronyms 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES 2.1 Repositories 2.2 Publication of certification information 2.3 Time or frequency of publication 2.4 Access controls on repositories 3. IDENTIFICATION AND AUTHENTICATION (11) 3.1 Naming 3.1.1 Types of names 3.1.2 Need for names to be meaningful 3.1.3 Anonymity or pseudonymity of subscribers 3.1.4 Rules for interpreting various name forms 3.1.5 Uniqueness of names 3.1.6 Recognition, authentication, and role of trademarks 3.2 Initial identity validation
1. 导言1.1概述1.2文件名称和标识1.3 PKI参与者1.3.1认证机构1.3.2注册机构1.3.3订户1.3.4依赖方1.3.5其他参与者1.4证书使用1.4.1。适当的证书使用1.4.2禁止的证书使用1.5政策管理1.5.1管理文件的组织1.5.2联系人1.5.3确定CPS是否适合政策的人员1.5.4 CPS批准程序1.6定义和首字母缩略词2。发布和存储库责任2.1存储库2.2认证信息的发布2.3发布的时间或频率2.4存储库的访问控制3。识别和认证（11）3.1命名3.1.1名称类型3.1.2名称必须有意义3.1.3订阅者的匿名性或假名3.1.4各种名称格式的解释规则3.1.5名称的唯一性3.1.6识别、认证和商标的作用3.2初始身份验证
3.2.1 Method to prove possession of private key 3.2.2 Authentication of organization identity 3.2.3 Authentication of individual identity 3.2.4 Non-verified subscriber information 3.2.5 Validation of authority 3.2.6 Criteria for interoperation 3.3 Identification and authentication for re-key requests 3.3.1 Identification and authentication for routine re-key 3.3.2 Identification and authentication for re-key after revocation 3.4 Identification and authentication for revocation request 4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS (11) 4.1 Certificate Application 4.1.1 Who can submit a certificate application 4.1.2 Enrollment process and responsibilities 4.2 Certificate application processing 4.2.1 Performing identification and authentication functions 4.2.2 Approval or rejection of certificate applications 4.2.3 Time to process certificate applications 4.3 Certificate issuance 4.3.1 CA actions during certificate issuance 4.3.2 Notification to subscriber by the CA of issuance of certificate 4.4 Certificate acceptance 4.4.1 Conduct constituting certificate acceptance 4.4.2 Publication of the certificate by the CA 4.4.3 Notification of certificate issuance by the CA to other entities 4.5 Key pair and certificate usage 4.5.1 Subscriber private key and certificate usage 4.5.2 Relying party public key and certificate usage 4.6 Certificate renewal 4.6.1 Circumstance for certificate renewal 4.6.2 Who may request renewal 4.6.3 Processing certificate renewal requests 4.6.4 Notification of new certificate issuance to subscriber 4.6.5 Conduct constituting acceptance of a renewal certificate 4.6.6 Publication of the renewal certificate by the CA 4.6.7 Notification of certificate issuance by the CA to other entities 4.7 Certificate re-key 4.7.1 Circumstance for certificate re-key 4.7.2 Who may request certification of a new public key 4.7.3 Processing certificate re-keying requests 4.7.4 Notification of new certificate issuance to subscriber 4.7.5 Conduct constituting acceptance of a re-keyed certificate 4.7.6 Publication of the re-keyed certificate by the CA 4.7.7 Notification of certificate issuance by the CA to other entities
3.2.1 证明拥有私钥的方法3.2.2组织身份验证3.2.3个人身份验证3.2.4未经验证的用户信息3.2.5权限验证3.2.6互操作标准3.3重新密钥请求的标识和验证3.3.1例行程序的标识和验证重新密钥3.3.2撤销后重新密钥的标识和认证3.4撤销请求的标识和认证4。证书生命周期运行要求（11）4.1证书申请4.1.1谁可以提交证书申请4.1.2注册流程和职责4.2证书申请处理4.2.1执行身份验证功能4.2.2证书申请的批准或拒绝4.2.3处理证书申请的时间4.3证书颁发4.3.1证书颁发期间的CA行动4.3.2 CA向用户发出证书颁发通知4.4证书接受4.4.1构成证书接受的行为4.4.2 CA发布证书4.4.3 CA向其他实体发出证书颁发通知4.5密钥对和证书使用4.5.1用户私钥和证书使用4.5.2依赖方公钥和证书使用4.6证书更新4.6.1证书更新的情况4.6.2谁可以请求更新4.6.3处理证书更新请求4.6.4向用户发出新证书的通知4.6.5构成接受更新证书4.6.6 CA发布更新证书4.6.7 CA向其他实体发布证书的通知4.7证书密钥更新4.7.1证书密钥更新的情况4.7.2谁可以请求新公钥的认证4.7.3处理证书密钥更新请求4.7.4新密钥的通知向订户颁发证书4.7.5构成接受重新加密证书的行为4.7.6 CA发布重新加密证书4.7.7 CA向其他实体颁发证书的通知
4.8 Certificate modification 4.8.1 Circumstance for certificate modification 4.8.2 Who may request certificate modification 4.8.3 Processing certificate modification requests 4.8.4 Notification of new certificate issuance to subscriber 4.8.5 Conduct constituting acceptance of modified certificate 4.8.6 Publication of the modified certificate by the CA 4.8.7 Notification of certificate issuance by the CA to other entities 4.9 Certificate revocation and suspension 4.9.1 Circumstances for revocation 4.9.2 Who can request revocation 4.9.3 Procedure for revocation request 4.9.4 Revocation request grace period 4.9.5 Time within which CA must process the revocation request 4.9.6 Revocation checking requirement for relying parties 4.9.7 CRL issuance frequency (if applicable) 4.9.8 Maximum latency for CRLs (if applicable) 4.9.9 On-line revocation/status checking availability 4.9.10 On-line revocation checking requirements 4.9.11 Other forms of revocation advertisements available 4.9.12 Special requirements re key compromise 4.9.13 Circumstances for suspension 4.9.14 Who can request suspension 4.9.15 Procedure for suspension request 4.9.16 Limits on suspension period 4.10 Certificate status services 4.10.1 Operational characteristics 4.10.2 Service availability 4.10.3 Optional features 4.11 End of subscription 4.12 Key escrow and recovery 4.12.1 Key escrow and recovery policy and practices 4.12.2 Session key encapsulation and recovery policy and practices 5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS (11) 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
4.8 证书修改4.8.1证书修改情况4.8.2谁可以请求证书修改4.8.3处理证书修改请求4.8.4向订户发出新证书的通知4.8.5构成接受修改后证书的行为4.8.6 CA发布修改后的证书4.8.7 CA向其他实体发布证书的通知4.9证书撤销和暂停4.9.1撤销的情况4.9.2谁可以请求撤销4.9.3撤销请求的程序4.9.4撤销请求宽限期4.9.5 CA必须处理撤销请求的时间4.9.6撤销检查对依赖方的要求4.9.7 CRL发布频率（如适用）4.9.8 CRL的最大延迟（如适用）4.9.9在线撤销/状态检查可用性4.9.10在线撤销检查要求4.9.11其他形式的撤销广告可用性4.9.12特殊要求重新关键妥协4.9.13暂停情况4.9.14谁可以请求暂停4.9.15暂停程序请求4.9.16暂停限制期间4.10证书状态服务4.10.1操作特征4.10.2服务可用性4.10.3可选功能4.11订阅结束4.12密钥托管和恢复4.12.1密钥托管和恢复策略与实践4.12.2会话密钥封装和恢复策略与实践5。设施、管理和运营控制（11）5.1物理控制5.1.1现场位置和施工5.1.2物理通道5.1.3电源和空调5.1.4水暴露5.1.5防火和保护5.1.6介质存储5.1.7废物处理5.1.8场外备份5.2程序控制5.2.1信任角色5.2.2任务所需人数5.2.3识别和管理每个角色的身份验证
5.2.4 Roles requiring separation of duties 5.3 Personnel controls 5.3.1 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 Independent contractor requirements 5.3.8 Documentation supplied to personnel 5.4 Audit logging procedures 5.4.1 Types of events recorded 5.4.2 Frequency of processing log 5.4.3 Retention period for audit log 5.4.4 Protection of audit log 5.4.5 Audit log backup procedures 5.4.6 Audit collection system (internal vs. external) 5.4.7 Notification to event-causing subject 5.4.8 Vulnerability assessments 5.5 Records archival 5.5.1 Types of records archived 5.5.2 Retention period for archive 5.5.3 Protection of archive 5.5.4 Archive backup procedures 5.5.5 Requirements for time-stamping of records 5.5.6 Archive collection system (internal or external) 5.5.7 Procedures to obtain and verify archive information 5.6 Key changeover 5.7 Compromise and disaster recovery 5.7.1 Incident and compromise handling procedures 5.7.2 Computing resources, software, and/or data are corrupted 5.7.3 Entity private key compromise procedures 5.7.4 Business continuity capabilities after a disaster 5.8 CA or RA termination 6. TECHNICAL SECURITY CONTROLS (11) 6.1 Key pair generation and installation 6.1.1 Key pair generation 6.1.2 Private key delivery to subscriber 6.1.3 Public key delivery to certificate issuer 6.1.4 CA public key delivery to relying parties 6.1.5 Key sizes 6.1.6 Public key parameters generation and quality checking 6.1.7 Key usage purposes (as per X.509 v3 key usage field) 6.2 Private Key Protection and Cryptographic Module Engineering Controls 6.2.1 Cryptographic module standards and controls 6.2.2 Private key (n out of m) multi-person control 6.2.3 Private key escrow
5.2.4 需要职责分离的角色5.3人员控制5.3.1资格、经验、，和许可要求5.3.2背景检查程序5.3.3培训要求5.3.4再培训频率和要求5.3.5工作轮换频率和顺序5.3.6未经授权行为的制裁5.3.7独立承包商要求5.3.8提供给人员的文件5.4审计记录程序5.4.1类型记录的事件5.4.2处理日志的频率5.4.3审核日志的保留期5.4.4审核日志的保护5.4.5审核日志备份程序5.4.6审核收集系统（内部与外部）5.4.7事件引发主体通知5.4.8漏洞评估5.5档案记录5.5.1档案记录类型5.5.2档案保留期5.5.3档案保护5.5.4档案备份程序5.5.5记录时间戳要求5.5.6档案收集系统（内部或外部）5.5.7获取和验证归档信息的程序5.6关键转换5.7危害和灾难恢复5.7.1事件和危害处理程序5.7.2计算资源、软件、，和/或数据损坏5.7.3实体私钥泄露程序5.7.4灾难后的业务连续性能力5.8 CA或RA终止6。技术安全控制（11）6.1密钥对生成和安装6.1.1密钥对生成6.1.2向订户交付私钥6.1.3向证书颁发者交付公钥6.1.4向依赖方交付CA公钥6.1.5密钥大小6.1.6公钥参数生成和质量检查6.1.7密钥使用目的（根据X.509 v3密钥使用字段）6.2私钥保护和加密模块工程控制6.2.1加密模块标准和控制6.2.2私钥（n/m）多人控制6.2.3私钥托管
6.2.4 Private key backup 6.2.5 Private key archival 6.2.6 Private key transfer into or from a cryptographic module 6.2.7 Private key storage on cryptographic module 6.2.8 Method of activating private key 6.2.9 Method of deactivating private key 6.2.10 Method of destroying private key 6.2.11 Cryptographic Module Rating 6.3 Other aspects of key pair management 6.3.1 Public key archival 6.3.2 Certificate operational periods and key pair usage periods 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 controls 6.7 Network security controls 6.8 Time-stamping 7. CERTIFICATE, CRL, AND OCSP 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 Policies extension 7.2 CRL profile 7.2.1 Version number(s) 7.2.2 CRL and CRL entry extensions 7.3 OCSP profile 7.3.1 Version number(s) 7.3.2 OCSP extensions 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS 8.1 Frequency or circumstances of assessment 8.2 Identity/qualifications of assessor 8.3 Assessor's relationship to assessed entity 8.4 Topics covered by assessment 8.5 Actions taken as a result of deficiency
6.2.4 私钥备份6.2.5私钥存档6.2.6私钥传入或传出加密模块6.2.7加密模块上的私钥存储6.2.8激活私钥的方法6.2.9禁用私钥的方法6.2.10销毁私钥的方法6.2.11加密模块评级6.3密钥对的其他方面管理6.3.1公钥存档6.3.2证书操作周期和密钥对使用周期6.4激活数据6.4.1激活数据生成和安装6.4.2激活数据保护6.4.3激活数据的其他方面6.5计算机安全控制6.5.1特定计算机安全技术要求6.5.2计算机安全等级6.6生命周期技术控制6.6.1系统开发控制6.6.2安全管理控制6.6.3生命周期安全控制6.7网络安全控制6.8时间戳7。证书、CRL和OCSP配置文件7.1证书配置文件7.1.1版本号7.1.2证书扩展7.1.3算法对象标识符7.1.4名称表单7.1.5名称约束7.1.6证书策略对象标识符7.1.7策略约束扩展的使用7.1.8策略限定符语法和语义7.1.9关键证书策略扩展的处理语义7.2 CRL配置文件7.2.1版本号（s） 7.2.2 CRL和CRL条目扩展7.3 OCSP配置文件7.3.1版本号7.3.2 OCSP扩展8.合规审计和其他评估8.1评估的频率或情况8.2评估员的身份/资格8.3评估员与被评估实体的关系8.4评估所涵盖的主题8.5因缺陷而采取的行动
8.6 Communication of results 9. OTHER BUSINESS AND LEGAL MATTERS 9.1 Fees 9.1.1 Certificate issuance or renewal fees 9.1.2 Certificate access fees 9.1.3 Revocation or status information access fees 9.1.4 Fees for other services 9.1.5 Refund policy 9.2 Financial responsibility 9.2.1 Insurance coverage 9.2.2 Other assets 9.2.3 Insurance or warranty coverage for end-entities 9.3 Confidentiality of business information 9.3.1 Scope of confidential information 9.3.2 Information not within the scope of confidential information 9.3.3 Responsibility to protect confidential information 9.4 Privacy of personal information 9.4.1 Privacy plan 9.4.2 Information treated as private 9.4.3 Information not deemed private 9.4.4 Responsibility to protect private information 9.4.5 Notice and consent to use private information 9.4.6 Disclosure pursuant to judicial or administrative process 9.4.7 Other information disclosure circumstances 9.5 Intellectual property rights 9.6 Representations and warranties 9.6.1 CA representations and warranties 9.6.2 RA representations and warranties 9.6.3 Subscriber representations and warranties 9.6.4 Relying party representations and warranties 9.6.5 Representations and warranties of other participants 9.7 Disclaimers of warranties 9.8 Limitations of liability 9.9 Indemnities 9.10 Term and termination 9.10.1 Term 9.10.2 Termination 9.10.3 Effect of termination and survival 9.11 Individual notices and communications with participants 9.12 Amendments 9.12.1 Procedure for amendment 9.12.2 Notification mechanism and period 9.12.3 Circumstances under which OID must be changed 9.13 Dispute resolution provisions 9.14 Governing law 9.15 Compliance with applicable law 9.16 Miscellaneous provisions 9.16.1 Entire agreement
8.6 交流结果9。其他业务和法律事项9.1费用9.1.1证书颁发或更新费用9.1.2证书访问费9.1.3撤销或状态信息访问费9.1.4其他服务费用9.1.5退款政策9.2财务责任9.2.1保险范围9.2.2其他资产9.2.3最终实体的保险或保修范围9.3商业信息的保密性9.3.1保密信息的范围9.3.2不在保密信息范围内的信息9.3.3保护保密信息的责任9.4个人信息的隐私9.4.1隐私计划9.4.2被视为隐私的信息9.4.3不被视为隐私的信息9.4.4保护私人信息的责任9.4.5通知和同意使用私人信息9.4.6根据司法或行政程序披露9.4.7其他信息披露情况9.5知识产权9.6陈述和保证9.6.1 CA陈述和保证9.6.2 RA陈述和保证保证9.6.3订户声明和保证9.6.4依赖方声明和保证9.6.5其他参与者的声明和保证9.7保证免责声明9.8责任限制9.9赔偿9.10期限和终止9.10.1期限9.10.2终止9.10.3终止和存续的影响9.11个人通知和与参与者的通信9.12修订9.12.1修订程序9.12.2通知机制和期限9.12.3 OID必须更改的情况9.13争议解决条款9.14适用法律9.15符合适用法律9.16杂项条款9.16.1整个协议
9.16.2 Assignment 9.16.3 Severability 9.16.4 Enforcement (attorneys' fees and waiver of rights) 9.16.5 Force Majeure 9.17 Other provisions
9.16.2 转让9.16.3可分割性9.16.4执行（律师费和放弃权利）9.16.5不可抗力9.17其他规定
This framework represents an incremental improvement over RFC 2527. The new framework benefits from the experience gained in the course of deploying CP and CPS documents under RFC 2527. Further, this new framework is based on coordination with the American Bar Association Information Security Committee within the Section of Science and Technology Law. The ISC wrote the PKI Assessment Guidelines [ABA2], which embodies a great deal of technical, business, and legal experience in PKI operations. In particular, representatives of the ISC made changes to the framework to better suite it to the legal environment and make it more accessible to lawyers.
该框架代表了对RFC2527的增量改进。新框架得益于根据RFC 2527部署CP和CPS文件过程中获得的经验。此外，这一新框架是基于与美国律师协会信息安全委员会在科学和技术法部分的协调。ISC编写了PKI评估指南[ABA2]，其中包含了大量PKI运营的技术、业务和法律经验。特别是，ISC的代表对框架进行了修改，以使其更好地适应法律环境，并使其更易于律师使用。
>From a technical perspective, the changes to the RFC 2527 framework were minimal and incremental, rather than revolutionary. Sections 3-7 have largely been preserved, with modest reorganization and new topics. For example, the new framework includes a revision of Section 4 of the framework to include a full treatment of the certificate life-cycle, the addition of key escrow, key encapsulation, and key recovery policies and practices, and OCSP. Section 2 audit functions now appear alone in Section 8, and Section 2 focuses exclusively on repository functions. The business and legal matters in RFC 2527's Section 2 now appear in a new Section 9.
>从技术角度看，对RFC 2527框架的更改是最小的、渐进的，而不是革命性的。第3-7节基本上保留了下来，并进行了适当的重组和新的主题。例如，新框架包括对框架第4节的修订，以包括对证书生命周期的全面处理、添加密钥托管、密钥封装和密钥恢复策略和实践以及OCSP。第2节审计功能现在单独出现在第8节中，第2节专门关注存储库功能。RFC 2527第2节中的业务和法律事项现在出现在新的第9节中。
From a legal perspective, the new Section 9 is useful because it places topics in the framework in an ordering that is similar to software licensing and other technology agreements and thus is familiar to technology lawyers. Moreover, the framework as a whole can double as a framework for a subscriber, relying party, or other PKI-related agreement. The changes are intended to make legal review of, and input into, CP and CPS documents more efficient. Section 9 also adds new legal topics, such as the privacy of personal information, liability terms, and duration of the effectiveness of the document.
从法律角度看，新的第9节很有用，因为它将主题放在框架中的顺序类似于软件许可和其他技术协议，因此技术律师很熟悉。此外，该框架作为一个整体可以兼作订户、依赖方或其他PKI相关协议的框架。这些变更旨在提高CP和CPS文件的法律审查和输入效率。第9节还增加了新的法律主题，如个人信息隐私、责任条款和文件有效期。
Section 1 of the new framework is largely the same as RFC 2527, although it increases coverage of PKI participants by breaking out subscribers from relying parties and adding a section for other participants. It changes the "applicability" section to one covering appropriate and prohibited uses of certificates. Also, it moves CPS
新框架的第1节基本上与RFC 2527相同，但它通过从依赖方中分离订户并为其他参与者添加一节来增加PKI参与者的覆盖范围。它将“适用性”部分改为涵盖证书的适当和禁止使用。此外，它还移动CPS
approval procedures from RFC 2527's Section 8.3 into a collected policy administration section. Finally, Section 1.6 adds a place to list definitions and acronyms.
将RFC 2527第8.3节中的批准程序纳入收集的保单管理部分。最后，第1.6节添加了一个位置来列出定义和首字母缩略词。
Section 2 of the new framework is a reorganization of Section 2.6 of the old framework. Section 3 of the new framework is based on a division of the old Section 3.1 into two parts for naming and identification and authentication issues. It adds new issues, such as the permissibility of pseudonyms and anonymity. Old Section 4 topics on audit logging, record archives, key changeover, compromise and disaster recovery, and CA termination have moved to Section 5. The remaining Section 4 topics have been expanded and reorganized to cover a complete certificate lifecycle. New topics include items implicit in the RFC 2527 Section 4, but now explicit, such as certificate application processing, certificate modification, and the end of subscription.
新框架第2节是对旧框架第2.6节的重组。新框架的第3节基于将旧的第3.1节划分为两个部分来处理命名、标识和身份验证问题。它增加了新的问题，例如笔名的允许性和匿名性。关于审计日志记录、记录归档、密钥转换、泄露和灾难恢复以及CA终止的第4节主题已移至第5节。其余的第4节主题已经展开并重新组织，以涵盖完整的证书生命周期。新的主题包括RFC2527第4节中隐含但现在明确的项目，例如证书应用程序处理、证书修改和订阅结束。
New Sections 5.1 through 5.3 are almost identical to their counterparts in RFC 2527. The remainder of the new Section 5 is the topics moved from RFC 2527's Section 4, in the order that they appeared in Section 4. Section 6 of the new framework is almost the same as the old Section 6, with some exceptions, such as the consolidation of old Section 6.8 (cryptographic module engineering controls) into Section 6.2.1 (now called "cryptographic module standards and controls") and the addition of time-stamping in a new Section 6.8. Section 7 is almost identical to the old Section 7, the major change being the addition of a section covering OCSP profile. Section 8 is almost identical to RFC 2527's Section 2.7.
新的第5.1至5.3节与RFC 2527中的对应部分几乎相同。新的第5节的其余部分是从RFC 2527的第4节转移的主题，按照它们在第4节中出现的顺序。新框架的第6节与旧的第6节几乎相同，但有一些例外，例如将旧的第6.8节（加密模块工程控制）合并到第6.2.1节（现在称为“加密模块标准和控制”）中，并在新的第6.8节中添加时间戳。第7节与旧的第7节几乎相同，主要变化是增加了一节，涵盖OCSP剖面。第8节与RFC 2527第2.7节几乎相同。
New Section 9 contains business and legal topics that were covered in RFC 2527's Section 2, including fees, financial responsibility, confidentiality, and intellectual property. It adds a section on the privacy of personal information, which has become a significant policy issue. The "liability" Section 2.2 in RFC 2527 now appears in Sections 9.6 through 9.9, covering representations and warranties, disclaimers, limitations of liability, and indemnities. Section 9.10 adds a section concerning the duration of the effectiveness of documentation. Section 9.12 collects terms concerning the way in which a document (CP, CPS, agreement, or other document) may be amended, formerly appearing in Section 8.1. Section 9 includes "legal boilerplate" topics, some of which were in the old Section 2. Finally, Section 9.17 is a catch-all "other provisions" section where drafters can place information that does not fit well into any other section of the framework.
新的第9节包含RFC 2527第2节涵盖的商业和法律主题，包括费用、财务责任、保密性和知识产权。它增加了关于个人信息隐私的一节，这已成为一个重大的政策问题。RFC 2527中的“责任”第2.2节现在出现在第9.6至9.9节中，涵盖陈述和保证、免责声明、责任限制和赔偿。第9.10节增加了关于文件有效期的一节。第9.12节收集了有关文件（CP、CPS、协议或其他文件）修改方式的条款，以前出现在第8.1节中。第9节包括“法律样板”主题，其中一些在旧的第2节中。最后，第9.17节是一个包罗万象的“其他条款”部分，起草者可以在其中放置不适合框架任何其他部分的信息。
The following matrix shows the sections in the old RFC 2527 framework and their successor sections in the new framework.
以下矩阵显示了旧RFC 2527框架中的部分以及新框架中的后续部分。
ORIGINAL RFC 2527 NEW RFC SECTION
SECTION
------------------------------------------------------
1. Introduction 1.
------------------------------------------------------
1.1 Overview 1.1
------------------------------------------------------
1.2 Identification 1.2
------------------------------------------------------
1.3 Community and
Applicability 1.3
------------------------------------------------------
1.3.1 Certification
Authorities 1.3.1
------------------------------------------------------
1.3.2 Registration Authorities 1.3.2
------------------------------------------------------
1.3.3 End entities 1.3.3,
1.3.4
------------------------------------------------------
1.3.4 Applicability 1.4, 4.5
------------------------------------------------------
1.4 Contact Details 1.5
------------------------------------------------------
1.4.1 Specification Administration
Organization 1.5.1
------------------------------------------------------
1.4.2 Contact Person 1.5.2
------------------------------------------------------
1.4.3 Person Determining CPS
Suitability for the Policy 1.5.3
------------------------------------------------------
2. General Provisions 2, 8, 9
------------------------------------------------------
2.1 Obligations 2.6.4
------------------------------------------------------
2.1.1 1A Obligations Integrated
throughout
portions of the
framework that
apply to CAs
------------------------------------------------------
2.1.2 RA Obligations Integrated
throughout
portions of the
framework that
apply to RAs
ORIGINAL RFC 2527 NEW RFC SECTION
SECTION
------------------------------------------------------
1. Introduction 1.
------------------------------------------------------
1.1 Overview 1.1
------------------------------------------------------
1.2 Identification 1.2
------------------------------------------------------
1.3 Community and
Applicability 1.3
------------------------------------------------------
1.3.1 Certification
Authorities 1.3.1
------------------------------------------------------
1.3.2 Registration Authorities 1.3.2
------------------------------------------------------
1.3.3 End entities 1.3.3,
1.3.4
------------------------------------------------------
1.3.4 Applicability 1.4, 4.5
------------------------------------------------------
1.4 Contact Details 1.5
------------------------------------------------------
1.4.1 Specification Administration
Organization 1.5.1
------------------------------------------------------
1.4.2 Contact Person 1.5.2
------------------------------------------------------
1.4.3 Person Determining CPS
Suitability for the Policy 1.5.3
------------------------------------------------------
2. General Provisions 2, 8, 9
------------------------------------------------------
2.1 Obligations 2.6.4
------------------------------------------------------
2.1.1 1A Obligations Integrated
throughout
portions of the
framework that
apply to CAs
------------------------------------------------------
2.1.2 RA Obligations Integrated
throughout
portions of the
framework that
apply to RAs
------------------------------------------------------
2.1.3 Subscriber Obligations 4.1.2, 4.4, 4.5,
4.5.1, 4.6.5,
4.7.5, 4.8.1,
4.8.5, 4.9.1,
4.9.2, 4.9.13,
4.9.15, 5., 6.,
9.6.3, 9.9
------------------------------------------------------
2.1.4 Relying Party Obligations 4.5, 4.5.2, 4.9.6,
5., 6., 9.6.4, 9.9
------------------------------------------------------
2.1.5 Repository Obligations 2., 4.4.2, 4.4.3,
4.6.6, 4.6.7,
4.7.6, 4.7.7,
4.8.6, 4.8.7
------------------------------------------------------
2.2 Liability 9.6, 9.7, 9.8, 9.9
------------------------------------------------------
2.2.1 CA Liability 9.6.1, 9.7., 9.8,
9.9
------------------------------------------------------
2.2.2 RA Liability 9.6.2, 9.7, 9.8, 9.9
------------------------------------------------------
2.3 Financial Responsibility 9.2
------------------------------------------------------
2.3.1 Indemnification by Relying
Parties 9.9
------------------------------------------------------
2.3.2 Fiduciary Relationships 9.7
------------------------------------------------------
2.4 Interpretation and Enforcement 9.16
------------------------------------------------------
2.4.1 Governing Law 9.14, 9.15
------------------------------------------------------
2.4.2 Severability, Survival,
Merger, Notice 9.10.3, 9.11,
9.16.1,9.16.3
------------------------------------------------------
2.4.3 Dispute Resolution
Procedures 9.13, 9.16.4
------------------------------------------------------
2.5 Fees 9.1
------------------------------------------------------
2.5.1 Certificate Issuance
or Renewal Fees 9.1.1
------------------------------------------------------
2.5.2 Certificate Access Fees 9.1.2
------------------------------------------------------
2.1.3 Subscriber Obligations 4.1.2, 4.4, 4.5,
4.5.1, 4.6.5,
4.7.5, 4.8.1,
4.8.5, 4.9.1,
4.9.2, 4.9.13,
4.9.15, 5., 6.,
9.6.3, 9.9
------------------------------------------------------
2.1.4 Relying Party Obligations 4.5, 4.5.2, 4.9.6,
5., 6., 9.6.4, 9.9
------------------------------------------------------
2.1.5 Repository Obligations 2., 4.4.2, 4.4.3,
4.6.6, 4.6.7,
4.7.6, 4.7.7,
4.8.6, 4.8.7
------------------------------------------------------
2.2 Liability 9.6, 9.7, 9.8, 9.9
------------------------------------------------------
2.2.1 CA Liability 9.6.1, 9.7., 9.8,
9.9
------------------------------------------------------
2.2.2 RA Liability 9.6.2, 9.7, 9.8, 9.9
------------------------------------------------------
2.3 Financial Responsibility 9.2
------------------------------------------------------
2.3.1 Indemnification by Relying
Parties 9.9
------------------------------------------------------
2.3.2 Fiduciary Relationships 9.7
------------------------------------------------------
2.4 Interpretation and Enforcement 9.16
------------------------------------------------------
2.4.1 Governing Law 9.14, 9.15
------------------------------------------------------
2.4.2 Severability, Survival,
Merger, Notice 9.10.3, 9.11,
9.16.1,9.16.3
------------------------------------------------------
2.4.3 Dispute Resolution
Procedures 9.13, 9.16.4
------------------------------------------------------
2.5 Fees 9.1
------------------------------------------------------
2.5.1 Certificate Issuance
or Renewal Fees 9.1.1
------------------------------------------------------
2.5.2 Certificate Access Fees 9.1.2
------------------------------------------------------
2.5.3 Revocation or Status
Information Access Fees 9.1.3
------------------------------------------------------
2.5.4 Fees for Other Services Such
as Policy Information 9.1.4
------------------------------------------------------
2.5.5 Refund Policy 9.1.5
------------------------------------------------------
2.6 Publication and Repository 2.
------------------------------------------------------
2.6.1 Publication of CA
Information 2.2, 4.4.2,
4.4.3, 4.6.6,
4.6.7, 4.7.6,
4.7.7, 4.8.6,
4.8.7
------------------------------------------------------
2.6.2 Frequency of Publication 2.3
------------------------------------------------------
2.6.3 Access Controls 2.4
------------------------------------------------------
2.6.4 Repositories 2.1
------------------------------------------------------
2.7 Compliance Audit 8.
------------------------------------------------------
2.7.1 Frequency of Entity Compliance
Audit 8.1
------------------------------------------------------
2.7.2 Identity/Qualifications of
Auditor 8.2
------------------------------------------------------
2.7.3 Auditor's Relationship to Audited
Party 8.3
------------------------------------------------------
2.7.4 Topics Covered by Audit 8.4
------------------------------------------------------
2.7.5 Actions Taken as a Result of
Deficiency 8.5
------------------------------------------------------
2.7.6 Communications of Results 8.6
------------------------------------------------------
2.8 Confidentiality 9.3, 9.4
------------------------------------------------------
2.8.1 Types of Information to be
Kept Confidential 9.3.1, 9.4.2
------------------------------------------------------
2.5.3 Revocation or Status
Information Access Fees 9.1.3
------------------------------------------------------
2.5.4 Fees for Other Services Such
as Policy Information 9.1.4
------------------------------------------------------
2.5.5 Refund Policy 9.1.5
------------------------------------------------------
2.6 Publication and Repository 2.
------------------------------------------------------
2.6.1 Publication of CA
Information 2.2, 4.4.2,
4.4.3, 4.6.6,
4.6.7, 4.7.6,
4.7.7, 4.8.6,
4.8.7
------------------------------------------------------
2.6.2 Frequency of Publication 2.3
------------------------------------------------------
2.6.3 Access Controls 2.4
------------------------------------------------------
2.6.4 Repositories 2.1
------------------------------------------------------
2.7 Compliance Audit 8.
------------------------------------------------------
2.7.1 Frequency of Entity Compliance
Audit 8.1
------------------------------------------------------
2.7.2 Identity/Qualifications of
Auditor 8.2
------------------------------------------------------
2.7.3 Auditor's Relationship to Audited
Party 8.3
------------------------------------------------------
2.7.4 Topics Covered by Audit 8.4
------------------------------------------------------
2.7.5 Actions Taken as a Result of
Deficiency 8.5
------------------------------------------------------
2.7.6 Communications of Results 8.6
------------------------------------------------------
2.8 Confidentiality 9.3, 9.4
------------------------------------------------------
2.8.1 Types of Information to be
Kept Confidential 9.3.1, 9.4.2
------------------------------------------------------
2.8.2 Types of Information Not
Considered Confidential 9.3.2, 9.4.3
------------------------------------------------------
2.8.3 Disclosure of Certificate
Revocation/Suspension
Information 9.3.1, 9.3.2,
9.3.3, 9.4.2,
9.4.3, 9.4.4
------------------------------------------------------
2.8.4 Release to Law Enforcement
Officials 9.3.3, 9.4.6
------------------------------------------------------
2.8.5 Release as Part of Civil
Discovery 9.3.3, 9.4.6
------------------------------------------------------
2.8.6 Disclosure Upon Owner's
Request 9.3.3, 9.4.7
------------------------------------------------------
2.8.7 Other Information Release
Circumstances 9.3.3, 9.4.7
------------------------------------------------------
2.9 Intellectual Property Rights 9.5
------------------------------------------------------
3. Identification and Authentication 3.
------------------------------------------------------
3.1 Initial Registration 3.1, 3.2
------------------------------------------------------
3.1.1 Type of Names 3.1.1
------------------------------------------------------
3.1.2 Need for Names to be
Meaningful 3.1.2, 3.1.3
------------------------------------------------------
3.1.3 Rules for Interpreting
Various Name Forms 3.1.4
------------------------------------------------------
3.1.4 Uniqueness of Names 3.1.5
------------------------------------------------------
3.1.5 Name Claim Dispute
Resolution Procedure 3.1.6
------------------------------------------------------
3.1.6 Recognition, Authentication,
and Role of Trademarks 3.1.6
------------------------------------------------------
3.1.7 Method to Prove Possession
of Private Key 3.2.1
------------------------------------------------------
2.8.2 Types of Information Not
Considered Confidential 9.3.2, 9.4.3
------------------------------------------------------
2.8.3 Disclosure of Certificate
Revocation/Suspension
Information 9.3.1, 9.3.2,
9.3.3, 9.4.2,
9.4.3, 9.4.4
------------------------------------------------------
2.8.4 Release to Law Enforcement
Officials 9.3.3, 9.4.6
------------------------------------------------------
2.8.5 Release as Part of Civil
Discovery 9.3.3, 9.4.6
------------------------------------------------------
2.8.6 Disclosure Upon Owner's
Request 9.3.3, 9.4.7
------------------------------------------------------
2.8.7 Other Information Release
Circumstances 9.3.3, 9.4.7
------------------------------------------------------
2.9 Intellectual Property Rights 9.5
------------------------------------------------------
3. Identification and Authentication 3.
------------------------------------------------------
3.1 Initial Registration 3.1, 3.2
------------------------------------------------------
3.1.1 Type of Names 3.1.1
------------------------------------------------------
3.1.2 Need for Names to be
Meaningful 3.1.2, 3.1.3
------------------------------------------------------
3.1.3 Rules for Interpreting
Various Name Forms 3.1.4
------------------------------------------------------
3.1.4 Uniqueness of Names 3.1.5
------------------------------------------------------
3.1.5 Name Claim Dispute
Resolution Procedure 3.1.6
------------------------------------------------------
3.1.6 Recognition, Authentication,
and Role of Trademarks 3.1.6
------------------------------------------------------
3.1.7 Method to Prove Possession
of Private Key 3.2.1
------------------------------------------------------
3.1.8 Authentication of
Organization Identity 3.2.2
------------------------------------------------------
3.1.9 Authentication of
Individual Identity 3.2.3
------------------------------------------------------
3.2 Routine Rekey 3.3.1, 4.6, 4.7
------------------------------------------------------
3.3 Rekey After Revocation 3.3.2
------------------------------------------------------
3.4 Revocation Request 3.4
------------------------------------------------------
4. Operational Requirements 4., 5.
------------------------------------------------------
4.1 Certificate Application 4.1, 4.2, 4.6,
4.7
------------------------------------------------------
4.2 Certificate Issuance 4.2, 4.3, 4.4.3,
4.6, 4.7, 4.8.4,
4.8.6, 4.8.7
------------------------------------------------------
4.3 Certificate Acceptance 4.3.2, 4.4, 4.6,
4.7, 4.8.4-4.8.7
------------------------------------------------------
4.4 Certificate Suspension
and Revocation 4.8, 4.9
------------------------------------------------------
4.4.1 Circumstances for Revocation 4.8.1, 4.9.1
------------------------------------------------------
4.4.2 Who Can Request Revocation 4.8.2, 4.9.2
------------------------------------------------------
4.4.3 Procedure for Revocation
Request 4.8.3-4.8.7,
4.9.3
------------------------------------------------------
4.4.4 Revocation Request
Grace Period 4.9.4
------------------------------------------------------
4.4.5 Circumstances for Suspension 4.9.13
------------------------------------------------------
4.4.6 Who Can Request Suspension 4.9.14
------------------------------------------------------
4.4.7 Procedure for Suspension
Request 4.9.15
------------------------------------------------------
4.4.8 Limits on Suspension Period 4.9.16
------------------------------------------------------
3.1.8 Authentication of
Organization Identity 3.2.2
------------------------------------------------------
3.1.9 Authentication of
Individual Identity 3.2.3
------------------------------------------------------
3.2 Routine Rekey 3.3.1, 4.6, 4.7
------------------------------------------------------
3.3 Rekey After Revocation 3.3.2
------------------------------------------------------
3.4 Revocation Request 3.4
------------------------------------------------------
4. Operational Requirements 4., 5.
------------------------------------------------------
4.1 Certificate Application 4.1, 4.2, 4.6,
4.7
------------------------------------------------------
4.2 Certificate Issuance 4.2, 4.3, 4.4.3,
4.6, 4.7, 4.8.4,
4.8.6, 4.8.7
------------------------------------------------------
4.3 Certificate Acceptance 4.3.2, 4.4, 4.6,
4.7, 4.8.4-4.8.7
------------------------------------------------------
4.4 Certificate Suspension
and Revocation 4.8, 4.9
------------------------------------------------------
4.4.1 Circumstances for Revocation 4.8.1, 4.9.1
------------------------------------------------------
4.4.2 Who Can Request Revocation 4.8.2, 4.9.2
------------------------------------------------------
4.4.3 Procedure for Revocation
Request 4.8.3-4.8.7,
4.9.3
------------------------------------------------------
4.4.4 Revocation Request
Grace Period 4.9.4
------------------------------------------------------
4.4.5 Circumstances for Suspension 4.9.13
------------------------------------------------------
4.4.6 Who Can Request Suspension 4.9.14
------------------------------------------------------
4.4.7 Procedure for Suspension
Request 4.9.15
------------------------------------------------------
4.4.8 Limits on Suspension Period 4.9.16
------------------------------------------------------
4.4.9 CRL Issuance Frequency
(If Applicable) 4.9.7, 4.9.8,
4.10
------------------------------------------------------
4.4.10 CRL Checking Requirements 4.9.6, 4.10
------------------------------------------------------
4.4.11 On-Line Revocation/
Status Checking
Availability 4.9.9, 4.10
------------------------------------------------------
4.4.12 On-Line Revocation
Checking Requirements 4.9.6, 4.9.10,
4.10
------------------------------------------------------
4.4.13 Other Forms
of Revocation
Advertisements 4.9.11, 4.10
------------------------------------------------------
4.4.14 Checking Requirements
for Other Forms of
Revocation
Advertisements 4.9.6, 4.9.11,
4.10
------------------------------------------------------
4.4.15 Special Requirements re
Key Compromise 4.9.12
------------------------------------------------------
4.5 Security Audit Procedures 5.4
------------------------------------------------------
4.5.1 Types of Events Recorded 5.4.1
------------------------------------------------------
4.5.2 Frequency of Processing Log 5.4.2
------------------------------------------------------
4.5.3 Retention Period for Audit
Log 5.4.3
------------------------------------------------------
4.5.4 Protection of Audit Log 5.4.4
------------------------------------------------------
4.5.5 Audit Log Backup Procedures 5.4.5
------------------------------------------------------
4.5.6 Audit Collection System
(Internal vs. External) 5.4.6
------------------------------------------------------
4.5.7 Notification to Event-Causing
Subject 5.4.7
------------------------------------------------------
4.5.8 Vulnerability Assessments 5.4.8
------------------------------------------------------
4.4.9 CRL Issuance Frequency
(If Applicable) 4.9.7, 4.9.8,
4.10
------------------------------------------------------
4.4.10 CRL Checking Requirements 4.9.6, 4.10
------------------------------------------------------
4.4.11 On-Line Revocation/
Status Checking
Availability 4.9.9, 4.10
------------------------------------------------------
4.4.12 On-Line Revocation
Checking Requirements 4.9.6, 4.9.10,
4.10
------------------------------------------------------
4.4.13 Other Forms
of Revocation
Advertisements 4.9.11, 4.10
------------------------------------------------------
4.4.14 Checking Requirements
for Other Forms of
Revocation
Advertisements 4.9.6, 4.9.11,
4.10
------------------------------------------------------
4.4.15 Special Requirements re
Key Compromise 4.9.12
------------------------------------------------------
4.5 Security Audit Procedures 5.4
------------------------------------------------------
4.5.1 Types of Events Recorded 5.4.1
------------------------------------------------------
4.5.2 Frequency of Processing Log 5.4.2
------------------------------------------------------
4.5.3 Retention Period for Audit
Log 5.4.3
------------------------------------------------------
4.5.4 Protection of Audit Log 5.4.4
------------------------------------------------------
4.5.5 Audit Log Backup Procedures 5.4.5
------------------------------------------------------
4.5.6 Audit Collection System
(Internal vs. External) 5.4.6
------------------------------------------------------
4.5.7 Notification to Event-Causing
Subject 5.4.7
------------------------------------------------------
4.5.8 Vulnerability Assessments 5.4.8
------------------------------------------------------
4.6 Records Archival 5.5
------------------------------------------------------
4.6.1 Types of Records Archived 5.5.1
------------------------------------------------------
4.6.2 Retention Period for Archive 5.5.2
------------------------------------------------------
4.6.3 Protection of Archive 5.5.3
------------------------------------------------------
4.6.4 Archive Backup Procedures 5.5.4
------------------------------------------------------
4.6.5 Requirements for
Time-Stamping of Records 5.5.5
------------------------------------------------------
4.6.6 Archive Collection System
(Internal or External) 5.5.6
------------------------------------------------------
4.6.6 Procedures to Obtain and
Verify Archive Information 5.5.7
------------------------------------------------------
4.7 Key Changeover 5.6
------------------------------------------------------
4.8 Compromise and Disaster
Recovery 5.7, 5.7.1
------------------------------------------------------
4.8.1 Computing Resources, Software,
and/or Data Are Corrupted 5.7.2
------------------------------------------------------
4.8.2 Entity Public
Key is Revoked 4.9.7, 4.9.9,
4.9.11
------------------------------------------------------
4.8.3 Entity Key is Compromised 5.7.3
------------------------------------------------------
4.8.4 Secure Facility After a Natural
or Other Type of Disaster 5.7.4
------------------------------------------------------
4.9 CA Termination 5.8
------------------------------------------------------
5. Physical, Procedural, and
Personnel Security Controls 5.
------------------------------------------------------
5.1 Physical Controls 5.1
------------------------------------------------------
5.1.1 Site Location and Construction 5.1.1
------------------------------------------------------
5.1.2 Physical Access 5.1.2
------------------------------------------------------
4.6 Records Archival 5.5
------------------------------------------------------
4.6.1 Types of Records Archived 5.5.1
------------------------------------------------------
4.6.2 Retention Period for Archive 5.5.2
------------------------------------------------------
4.6.3 Protection of Archive 5.5.3
------------------------------------------------------
4.6.4 Archive Backup Procedures 5.5.4
------------------------------------------------------
4.6.5 Requirements for
Time-Stamping of Records 5.5.5
------------------------------------------------------
4.6.6 Archive Collection System
(Internal or External) 5.5.6
------------------------------------------------------
4.6.6 Procedures to Obtain and
Verify Archive Information 5.5.7
------------------------------------------------------
4.7 Key Changeover 5.6
------------------------------------------------------
4.8 Compromise and Disaster
Recovery 5.7, 5.7.1
------------------------------------------------------
4.8.1 Computing Resources, Software,
and/or Data Are Corrupted 5.7.2
------------------------------------------------------
4.8.2 Entity Public
Key is Revoked 4.9.7, 4.9.9,
4.9.11
------------------------------------------------------
4.8.3 Entity Key is Compromised 5.7.3
------------------------------------------------------
4.8.4 Secure Facility After a Natural
or Other Type of Disaster 5.7.4
------------------------------------------------------
4.9 CA Termination 5.8
------------------------------------------------------
5. Physical, Procedural, and
Personnel Security Controls 5.
------------------------------------------------------
5.1 Physical Controls 5.1
------------------------------------------------------
5.1.1 Site Location and Construction 5.1.1
------------------------------------------------------
5.1.2 Physical Access 5.1.2
------------------------------------------------------
5.1.3 Power and Air Conditioning 5.1.3
------------------------------------------------------
------------------------------------------------------
5.1.3 Power and Air Conditioning 5.1.3
------------------------------------------------------
5.1.4 Water Exposures 5.1.4
------------------------------------------------------
5.1.5 Fire Prevention and Protection 5.1.5
------------------------------------------------------
5.1.6 Media Storage 5.1.6
------------------------------------------------------
5.1.7 Waste Disposal 5.1.7
------------------------------------------------------
5.1.8 Off-Site Backup 5.1.8
------------------------------------------------------
5.2 Procedural Controls 5.2
------------------------------------------------------
5.2.1 Trusted Roles 5.2.1, 5.2.4
------------------------------------------------------
5.2.2 Number of Persons
Required per Task 5.2.2, 5.2.4
------------------------------------------------------
5.2.3 Identification and
Authentication for Each Role 5.2.3
------------------------------------------------------
5.3 Personnel Controls 5.3
------------------------------------------------------
5.3.1 Background, Qualifications,
Experience, and Clearance
Requirements 5.3.1
------------------------------------------------------
5.3.2 Background Check Procedures 5.3.2
------------------------------------------------------
5.3.3 Training Requirements 5.3.3
------------------------------------------------------
5.3.4 Retraining Frequency
and Requirements 5.3.4
------------------------------------------------------
5.3.5 Job Rotation Frequency
and Sequence 5.3.5
------------------------------------------------------
5.3.6 Sanctions for
Unauthorized Actions 5.3.6
------------------------------------------------------
5.3.7 Contracting Personnel
Requirements 5.3.7
------------------------------------------------------
5.3.8 Documentation Supplied to
Personnel 5.3.8
5.1.4 Water Exposures 5.1.4
------------------------------------------------------
5.1.5 Fire Prevention and Protection 5.1.5
------------------------------------------------------
5.1.6 Media Storage 5.1.6
------------------------------------------------------
5.1.7 Waste Disposal 5.1.7
------------------------------------------------------
5.1.8 Off-Site Backup 5.1.8
------------------------------------------------------
5.2 Procedural Controls 5.2
------------------------------------------------------
5.2.1 Trusted Roles 5.2.1, 5.2.4
------------------------------------------------------
5.2.2 Number of Persons
Required per Task 5.2.2, 5.2.4
------------------------------------------------------
5.2.3 Identification and
Authentication for Each Role 5.2.3
------------------------------------------------------
5.3 Personnel Controls 5.3
------------------------------------------------------
5.3.1 Background, Qualifications,
Experience, and Clearance
Requirements 5.3.1
------------------------------------------------------
5.3.2 Background Check Procedures 5.3.2
------------------------------------------------------
5.3.3 Training Requirements 5.3.3
------------------------------------------------------
5.3.4 Retraining Frequency
and Requirements 5.3.4
------------------------------------------------------
5.3.5 Job Rotation Frequency
and Sequence 5.3.5
------------------------------------------------------
5.3.6 Sanctions for
Unauthorized Actions 5.3.6
------------------------------------------------------
5.3.7 Contracting Personnel
Requirements 5.3.7
------------------------------------------------------
5.3.8 Documentation Supplied to
Personnel 5.3.8
------------------------------------------------------
6. Technical Security Controls 6.
------------------------------------------------------
6.1 Key Pair Generation and
Installation 6.1
------------------------------------------------------
6.1.1 Key Pair Generation 6.1.1
------------------------------------------------------
6.1.2 Private Key Delivery to Entity 6.1.2
------------------------------------------------------
6.1.3 Public Key Delivery to
Certificate Issuer 6.1.3
------------------------------------------------------
6.1.4 CA Public Key Delivery to Users 6.1.4
------------------------------------------------------
6.1.5 Key Sizes 6.1.5
------------------------------------------------------
6.1.6 Public Key Parameters Generation 6.1.6
------------------------------------------------------
6.1.7 Parameter Quality Checking 6.1.6
------------------------------------------------------
6.1.8 Hardware/Software Key Generation 6.1.1
------------------------------------------------------
6.1.9 Key Usage Purposes
(as per X.509 v3 Key Usage Field) 6.1.9
------------------------------------------------------
6.2 Private Key Protection 6.2
------------------------------------------------------
6.2.1 Standards for Cryptographic
Module 6.2.1
------------------------------------------------------
------------------------------------------------------
6. Technical Security Controls 6.
------------------------------------------------------
6.1 Key Pair Generation and
Installation 6.1
------------------------------------------------------
6.1.1 Key Pair Generation 6.1.1
------------------------------------------------------
6.1.2 Private Key Delivery to Entity 6.1.2
------------------------------------------------------
6.1.3 Public Key Delivery to
Certificate Issuer 6.1.3
------------------------------------------------------
6.1.4 CA Public Key Delivery to Users 6.1.4
------------------------------------------------------
6.1.5 Key Sizes 6.1.5
------------------------------------------------------
6.1.6 Public Key Parameters Generation 6.1.6
------------------------------------------------------
6.1.7 Parameter Quality Checking 6.1.6
------------------------------------------------------
6.1.8 Hardware/Software Key Generation 6.1.1
------------------------------------------------------
6.1.9 Key Usage Purposes
(as per X.509 v3 Key Usage Field) 6.1.9
------------------------------------------------------
6.2 Private Key Protection 6.2
------------------------------------------------------
6.2.1 Standards for Cryptographic
Module 6.2.1
------------------------------------------------------
6.2.2 Private Key (n out of m)
Multi-Person Control 6.2.2
------------------------------------------------------
6.2.3 Private Key Escrow 6.2.3
------------------------------------------------------
6.2.4 Private Key Backup 6.2.4
------------------------------------------------------
6.2.5 Private Key Archival 6.2.5
------------------------------------------------------
6.2.6 Private Key Entry Into
Cryptographic Module 6.2.6, 6.2.7
------------------------------------------------------
6.2.7 Method of Activating
Private Key 6.2.8
6.2.2 Private Key (n out of m)
Multi-Person Control 6.2.2
------------------------------------------------------
6.2.3 Private Key Escrow 6.2.3
------------------------------------------------------
6.2.4 Private Key Backup 6.2.4
------------------------------------------------------
6.2.5 Private Key Archival 6.2.5
------------------------------------------------------
6.2.6 Private Key Entry Into
Cryptographic Module 6.2.6, 6.2.7
------------------------------------------------------
6.2.7 Method of Activating
Private Key 6.2.8
------------------------------------------------------
6.2.8 Method of Deactivating
Private Key 6.2.9
------------------------------------------------------
6.2.9 Method of Destroying Private
Key 6.2.10
------------------------------------------------------
6.3 Other Aspects of Key Pair
Management 6.3
------------------------------------------------------
6.3.1 Public Key Archival 6.3.1
------------------------------------------------------
6.3.2 Usage Periods for the Public
and Private Keys 6.3.2
------------------------------------------------------
6.4 Activation Data 6.4
------------------------------------------------------
6.4.1 Activation Data Generation
and Installation 6.4.1
------------------------------------------------------
6.4.2 Activation Data Protection 6.4.2
------------------------------------------------------
6.4.3 Other Aspects of Activation
Data 6.4.3
------------------------------------------------------
6.5 Computer Security Controls 6.5
------------------------------------------------------
6.5.1 Specific Computer Security
Technical Requirements 6.5.1
------------------------------------------------------
6.5.2 Computer Security Rating 6.5.2
------------------------------------------------------
6.6 Life Cycle Technical Controls 6.6
------------------------------------------------------
6.6.1 System Development Controls 6.6.1
------------------------------------------------------
6.6.2 Security Management Controls 6.6.2
------------------------------------------------------
6.6.3 Life Cycle Security Controls 6.6.3
------------------------------------------------------
6.7 Network Security Controls 6.7
------------------------------------------------------
6.8 Cryptographic Module
Engineering Controls 6.2.1, 6.2,
6.2.1, 6.2.11
------------------------------------------------------
7.Certificate and CRL Profiles 7.
------------------------------------------------------
6.2.8 Method of Deactivating
Private Key 6.2.9
------------------------------------------------------
6.2.9 Method of Destroying Private
Key 6.2.10
------------------------------------------------------
6.3 Other Aspects of Key Pair
Management 6.3
------------------------------------------------------
6.3.1 Public Key Archival 6.3.1
------------------------------------------------------
6.3.2 Usage Periods for the Public
and Private Keys 6.3.2
------------------------------------------------------
6.4 Activation Data 6.4
------------------------------------------------------
6.4.1 Activation Data Generation
and Installation 6.4.1
------------------------------------------------------
6.4.2 Activation Data Protection 6.4.2
------------------------------------------------------
6.4.3 Other Aspects of Activation
Data 6.4.3
------------------------------------------------------
6.5 Computer Security Controls 6.5
------------------------------------------------------
6.5.1 Specific Computer Security
Technical Requirements 6.5.1
------------------------------------------------------
6.5.2 Computer Security Rating 6.5.2
------------------------------------------------------
6.6 Life Cycle Technical Controls 6.6
------------------------------------------------------
6.6.1 System Development Controls 6.6.1
------------------------------------------------------
6.6.2 Security Management Controls 6.6.2
------------------------------------------------------
6.6.3 Life Cycle Security Controls 6.6.3
------------------------------------------------------
6.7 Network Security Controls 6.7
------------------------------------------------------
6.8 Cryptographic Module
Engineering Controls 6.2.1, 6.2,
6.2.1, 6.2.11
------------------------------------------------------
7.Certificate and CRL Profiles 7.
------------------------------------------------------
7.1 Certificate Profile 7.1
------------------------------------------------------
7.1.1 Version Number(s) 7.1.1
------------------------------------------------------
7.1.2 Certificate Extensions 7.1.2
------------------------------------------------------
7.1.3 Algorithm Object Identifiers 7.1.3
------------------------------------------------------
7.1.4 Name Forms 7.1.4
------------------------------------------------------
7.1.5 Name Constraints 7.1.5
------------------------------------------------------
7.1.6 Certificate Policy Object
Identifier 7.1.6
------------------------------------------------------
7.1.7 Usage of Policy Constraints
Extension 7.1.7
------------------------------------------------------
7.1.8 Policy Qualifiers Syntax
and Semantics 7.1.8
------------------------------------------------------
7.1.9 Processing Semantics for
the Critical Certificate
Policies Extension 7.1.9
------------------------------------------------------
7.2 CRL Profile 7.2
------------------------------------------------------
7.2.1 Version Number(s) 7.2.1
------------------------------------------------------
7.2.2 CRL and CRL Entry Extensions 7.2.1
------------------------------------------------------
8. Specification Administration N/A
------------------------------------------------------
8.1 Specification Change
Procedures 9.12
------------------------------------------------------
8.2 Publication and Notification
Policies 2.2, 2.3
------------------------------------------------------
8.3 CPS Approval Procedures 1.5.4
------------------------------------------------------
------------------------------------------------------
7.1 Certificate Profile 7.1
------------------------------------------------------
7.1.1 Version Number(s) 7.1.1
------------------------------------------------------
7.1.2 Certificate Extensions 7.1.2
------------------------------------------------------
7.1.3 Algorithm Object Identifiers 7.1.3
------------------------------------------------------
7.1.4 Name Forms 7.1.4
------------------------------------------------------
7.1.5 Name Constraints 7.1.5
------------------------------------------------------
7.1.6 Certificate Policy Object
Identifier 7.1.6
------------------------------------------------------
7.1.7 Usage of Policy Constraints
Extension 7.1.7
------------------------------------------------------
7.1.8 Policy Qualifiers Syntax
and Semantics 7.1.8
------------------------------------------------------
7.1.9 Processing Semantics for
the Critical Certificate
Policies Extension 7.1.9
------------------------------------------------------
7.2 CRL Profile 7.2
------------------------------------------------------
7.2.1 Version Number(s) 7.2.1
------------------------------------------------------
7.2.2 CRL and CRL Entry Extensions 7.2.1
------------------------------------------------------
8. Specification Administration N/A
------------------------------------------------------
8.1 Specification Change
Procedures 9.12
------------------------------------------------------
8.2 Publication and Notification
Policies 2.2, 2.3
------------------------------------------------------
8.3 CPS Approval Procedures 1.5.4
------------------------------------------------------
The following matrix shows the sections in the new framework and the sections in RFC 2527 to which the headings in the new framework correspond.
以下矩阵显示了新框架中的章节以及RFC 2527中新框架中标题对应的章节。
NEW RFC SECTION ORIGINAL RFC 2527
SECTION
------------------------------------------------------
1. Introduction 1.
------------------------------------------------------
1.1 Overview 1.1
------------------------------------------------------
1.2 Document Name and Identification 1.2
------------------------------------------------------
1.3 PKI Participants 1.3
------------------------------------------------------
1.3.1 Certification Authorities 1.3.1
------------------------------------------------------
1.3.2 Registration Authorities 1.3.2
------------------------------------------------------
1.3.3 Subscribers 1.3.3
------------------------------------------------------
1.3.4 Relying Parties 1.3.3
------------------------------------------------------
1.3.5 Other Participants N/A
------------------------------------------------------
1.4 Certificate Usage 1.3.4
------------------------------------------------------
1.4.1 Appropriate Certificate Uses 1.3.4
------------------------------------------------------
1.4.2 Prohibited Certificate Uses 1.3.4
------------------------------------------------------
1.5 Policy Administration 1.4
------------------------------------------------------
1.5.1 Organization Administering
the Document 1.4.1
------------------------------------------------------
1.5.2 Contact Person 1.4.2
------------------------------------------------------
1.5.3 Person Determining CPS
Suitability for the Policy 1.4.3
------------------------------------------------------
1.5.4 CPS Approval Procedures 8.3
------------------------------------------------------
1.6 Definitions and Acronyms N/A
------------------------------------------------------
2. Publication and Repository
Responsibilities 2.1.5, 2.6
NEW RFC SECTION ORIGINAL RFC 2527
SECTION
------------------------------------------------------
1. Introduction 1.
------------------------------------------------------
1.1 Overview 1.1
------------------------------------------------------
1.2 Document Name and Identification 1.2
------------------------------------------------------
1.3 PKI Participants 1.3
------------------------------------------------------
1.3.1 Certification Authorities 1.3.1
------------------------------------------------------
1.3.2 Registration Authorities 1.3.2
------------------------------------------------------
1.3.3 Subscribers 1.3.3
------------------------------------------------------
1.3.4 Relying Parties 1.3.3
------------------------------------------------------
1.3.5 Other Participants N/A
------------------------------------------------------
1.4 Certificate Usage 1.3.4
------------------------------------------------------
1.4.1 Appropriate Certificate Uses 1.3.4
------------------------------------------------------
1.4.2 Prohibited Certificate Uses 1.3.4
------------------------------------------------------
1.5 Policy Administration 1.4
------------------------------------------------------
1.5.1 Organization Administering
the Document 1.4.1
------------------------------------------------------
1.5.2 Contact Person 1.4.2
------------------------------------------------------
1.5.3 Person Determining CPS
Suitability for the Policy 1.4.3
------------------------------------------------------
1.5.4 CPS Approval Procedures 8.3
------------------------------------------------------
1.6 Definitions and Acronyms N/A
------------------------------------------------------
2. Publication and Repository
Responsibilities 2.1.5, 2.6
------------------------------------------------------
2.1 Repositories 2.6.4
------------------------------------------------------
2.2 Publication of Certification
Information 2.6.1, 8.2
------------------------------------------------------
2.3 Time or Frequency of
Publication 2.6.2, 8.2
------------------------------------------------------
2.4 Access Controls on Repositories 2.6.3
------------------------------------------------------
3. Identification and Authentication 3.
------------------------------------------------------
3.1 Naming 3.1
------------------------------------------------------
3.1.1 Type of Names 3.1.1
------------------------------------------------------
3.1.2 Need for Names to be Meaningful 3.1.2
------------------------------------------------------
3.1.3. Anonymity or Pseudonymity of
Subscribers 3.1.2
------------------------------------------------------
3.1.4 Rules for Interpreting Various
Name Forms 3.1.3
------------------------------------------------------
3.1.5 Uniqueness of Names 3.1.4
------------------------------------------------------
3.1.6 Recognition, Authentication,
and Role of Trademarks 3.1.5, 3.1.6
------------------------------------------------------
3.2 Initial Identity Validation 3.1
------------------------------------------------------
3.2.1 Method to Prove Possession
of Private Key 3.1.7
------------------------------------------------------
3.2.2 Authentication of
Organization Identity 3.1.8
------------------------------------------------------
3.2.3 Authentication of Individual
Identity 3.1.9
------------------------------------------------------
3.2.4 Non-Verified Subscriber
Information N/A
------------------------------------------------------
3.2.5 Validation of Authority 3.1.9
------------------------------------------------------
2.1 Repositories 2.6.4
------------------------------------------------------
2.2 Publication of Certification
Information 2.6.1, 8.2
------------------------------------------------------
2.3 Time or Frequency of
Publication 2.6.2, 8.2
------------------------------------------------------
2.4 Access Controls on Repositories 2.6.3
------------------------------------------------------
3. Identification and Authentication 3.
------------------------------------------------------
3.1 Naming 3.1
------------------------------------------------------
3.1.1 Type of Names 3.1.1
------------------------------------------------------
3.1.2 Need for Names to be Meaningful 3.1.2
------------------------------------------------------
3.1.3. Anonymity or Pseudonymity of
Subscribers 3.1.2
------------------------------------------------------
3.1.4 Rules for Interpreting Various
Name Forms 3.1.3
------------------------------------------------------
3.1.5 Uniqueness of Names 3.1.4
------------------------------------------------------
3.1.6 Recognition, Authentication,
and Role of Trademarks 3.1.5, 3.1.6
------------------------------------------------------
3.2 Initial Identity Validation 3.1
------------------------------------------------------
3.2.1 Method to Prove Possession
of Private Key 3.1.7
------------------------------------------------------
3.2.2 Authentication of
Organization Identity 3.1.8
------------------------------------------------------
3.2.3 Authentication of Individual
Identity 3.1.9
------------------------------------------------------
3.2.4 Non-Verified Subscriber
Information N/A
------------------------------------------------------
3.2.5 Validation of Authority 3.1.9
------------------------------------------------------
3.2.6 Criteria for Interoperation 4.1
------------------------------------------------------
3.3 Identification and Authentication
for Re-Key Requests 3.2, 3.3
------------------------------------------------------
3.3.1 Identification and
Authentication for Routine
Re-Key 3.2
------------------------------------------------------
3.3.2 Identification and
Authentication for Re-Key
After Revocation 3.3
------------------------------------------------------
3.4 Identification and Authentication
for Revocation Request 3.4
------------------------------------------------------
4. Certificate Life-Cycle
Operational Requirements 4.
------------------------------------------------------
4.1 Certificate Application 4.1
------------------------------------------------------
4.1.1 Who Can Submit a Certificate
Application 4.1
------------------------------------------------------
4.1.2 Enrollment Process and
Responsibilities 2.1.3, 4.1
------------------------------------------------------
4.2 Certificate Application
Processing 4.1, 4.2
------------------------------------------------------
4.2.1 Performing Identification
and Authentication Functions 4.1, 4.2
------------------------------------------------------
4.2.2 Approval or Rejection of
Certificate Applications 4.1, 4.2
------------------------------------------------------
4.2.3 Time to Process
Certificate Applications 4.1, 4.2
------------------------------------------------------
4.3 Certificate Issuance 4.2
------------------------------------------------------
4.3.1 CA Actions During
Certificate Issuance 4.2
------------------------------------------------------
4.3.2 Notifications to Subscriber by
the CA of Issuance of Certificate 4.2, 4.3
------------------------------------------------------
3.2.6 Criteria for Interoperation 4.1
------------------------------------------------------
3.3 Identification and Authentication
for Re-Key Requests 3.2, 3.3
------------------------------------------------------
3.3.1 Identification and
Authentication for Routine
Re-Key 3.2
------------------------------------------------------
3.3.2 Identification and
Authentication for Re-Key
After Revocation 3.3
------------------------------------------------------
3.4 Identification and Authentication
for Revocation Request 3.4
------------------------------------------------------
4. Certificate Life-Cycle
Operational Requirements 4.
------------------------------------------------------
4.1 Certificate Application 4.1
------------------------------------------------------
4.1.1 Who Can Submit a Certificate
Application 4.1
------------------------------------------------------
4.1.2 Enrollment Process and
Responsibilities 2.1.3, 4.1
------------------------------------------------------
4.2 Certificate Application
Processing 4.1, 4.2
------------------------------------------------------
4.2.1 Performing Identification
and Authentication Functions 4.1, 4.2
------------------------------------------------------
4.2.2 Approval or Rejection of
Certificate Applications 4.1, 4.2
------------------------------------------------------
4.2.3 Time to Process
Certificate Applications 4.1, 4.2
------------------------------------------------------
4.3 Certificate Issuance 4.2
------------------------------------------------------
4.3.1 CA Actions During
Certificate Issuance 4.2
------------------------------------------------------
4.3.2 Notifications to Subscriber by
the CA of Issuance of Certificate 4.2, 4.3
------------------------------------------------------
4.4 Certificate Acceptance 2.1.3, 4.3
------------------------------------------------------
4.4.1 Conduct Constituting
Certificate Acceptance 4.3
------------------------------------------------------
4.4.2 Publication of the
Certificate by the CA 2.1.5, 2.6.1, 4.3
------------------------------------------------------
4.4.3 Notification of
Certificate Issuance by
the CA to Other Entities 2.1.5, 2.6.1,
4.2, 4.3
------------------------------------------------------
4.5 Key Pair and
Certificate Usage 1.3.4, 2.1.3,
2.1.4
------------------------------------------------------
4.5.1 Subscriber Private Key
and Certificate Usage 1.3.4, 2.1.3
------------------------------------------------------
4.5.2 Relying Party Public
Key and Certificate
Usage 1.3.4, 2.1.4
------------------------------------------------------
4.6 Certificate Renewal 3.2, 4.1, 4.2,
4.3
------------------------------------------------------
4.6.1 Circumstances for
Certificate Renewal 3.2, 4.1
------------------------------------------------------
4.6.2 Who May Request Renewal 3.2, 4.1
------------------------------------------------------
4.6.3 Processing Certificate
Renewal Requests 3.2, 4.1, 4.2
------------------------------------------------------
4.6.4 Notification of New
Certificate Issuance to
Subscriber 3.2, 4.2, 4.3
------------------------------------------------------
4.6.5 Conduct Constituting
Acceptance of a Renewal
Certificate 2.1.3, 3.2, 4.3
------------------------------------------------------
4.6.6 Publication of the
Renewal Certificate
by the CA 2.1.5, 2.6.1,
3.2, 4.3
------------------------------------------------------
4.4 Certificate Acceptance 2.1.3, 4.3
------------------------------------------------------
4.4.1 Conduct Constituting
Certificate Acceptance 4.3
------------------------------------------------------
4.4.2 Publication of the
Certificate by the CA 2.1.5, 2.6.1, 4.3
------------------------------------------------------
4.4.3 Notification of
Certificate Issuance by
the CA to Other Entities 2.1.5, 2.6.1,
4.2, 4.3
------------------------------------------------------
4.5 Key Pair and
Certificate Usage 1.3.4, 2.1.3,
2.1.4
------------------------------------------------------
4.5.1 Subscriber Private Key
and Certificate Usage 1.3.4, 2.1.3
------------------------------------------------------
4.5.2 Relying Party Public
Key and Certificate
Usage 1.3.4, 2.1.4
------------------------------------------------------
4.6 Certificate Renewal 3.2, 4.1, 4.2,
4.3
------------------------------------------------------
4.6.1 Circumstances for
Certificate Renewal 3.2, 4.1
------------------------------------------------------
4.6.2 Who May Request Renewal 3.2, 4.1
------------------------------------------------------
4.6.3 Processing Certificate
Renewal Requests 3.2, 4.1, 4.2
------------------------------------------------------
4.6.4 Notification of New
Certificate Issuance to
Subscriber 3.2, 4.2, 4.3
------------------------------------------------------
4.6.5 Conduct Constituting
Acceptance of a Renewal
Certificate 2.1.3, 3.2, 4.3
------------------------------------------------------
4.6.6 Publication of the
Renewal Certificate
by the CA 2.1.5, 2.6.1,
3.2, 4.3
------------------------------------------------------
4.6.7 Notification of
Certificate Issuance by
the CA to Other Entities 2.1.5, 2.6.1, 3.2,
4.2, 4.3
------------------------------------------------------
4.7 Certificate Re-Key 3.2, 4.1, 4.2, 4.3
------------------------------------------------------
4.7.1 Circumstances for
Certificate Re-Key 3.2, 4.1
------------------------------------------------------
4.7.2 Who May Request Certification
of a New Public Key 3.2, 4.1
------------------------------------------------------
4.7.3 Processing Certificate
Re-Keying Requests 3.2, 4.1, 4.2
------------------------------------------------------
4.7.4 Notification of New
Certificate Issuance to
Subscriber 3.2, 4.2, 4.3
------------------------------------------------------
4.7.5 Conduct Constituting
Acceptance of a
Re-Keyed Certificate 2.1.3, 3.2, 4.3
------------------------------------------------------
4.7.6 Publication of the
Re-Keyed Certificate
by the CA 2.1.5, 2.6.1,
3.2, 4.3
------------------------------------------------------
4.7.7 Notification of Certificate
Issuance by the CA
to Other Entities 2.1.5, 2.6.1,
3.2, 4.2, 4.3
------------------------------------------------------
4.8 Certificate Modification 4.4
------------------------------------------------------
4.8.1 Circumstances for
Certificate Modification 2.1.3, 4.4.1
------------------------------------------------------
4.8.2 Who May Request Certificate
Modification 4.4.2
------------------------------------------------------
4.8.3 Processing Certificate
Modification Requests 4.4.3
------------------------------------------------------
4.6.7 Notification of
Certificate Issuance by
the CA to Other Entities 2.1.5, 2.6.1, 3.2,
4.2, 4.3
------------------------------------------------------
4.7 Certificate Re-Key 3.2, 4.1, 4.2, 4.3
------------------------------------------------------
4.7.1 Circumstances for
Certificate Re-Key 3.2, 4.1
------------------------------------------------------
4.7.2 Who May Request Certification
of a New Public Key 3.2, 4.1
------------------------------------------------------
4.7.3 Processing Certificate
Re-Keying Requests 3.2, 4.1, 4.2
------------------------------------------------------
4.7.4 Notification of New
Certificate Issuance to
Subscriber 3.2, 4.2, 4.3
------------------------------------------------------
4.7.5 Conduct Constituting
Acceptance of a
Re-Keyed Certificate 2.1.3, 3.2, 4.3
------------------------------------------------------
4.7.6 Publication of the
Re-Keyed Certificate
by the CA 2.1.5, 2.6.1,
3.2, 4.3
------------------------------------------------------
4.7.7 Notification of Certificate
Issuance by the CA
to Other Entities 2.1.5, 2.6.1,
3.2, 4.2, 4.3
------------------------------------------------------
4.8 Certificate Modification 4.4
------------------------------------------------------
4.8.1 Circumstances for
Certificate Modification 2.1.3, 4.4.1
------------------------------------------------------
4.8.2 Who May Request Certificate
Modification 4.4.2
------------------------------------------------------
4.8.3 Processing Certificate
Modification Requests 4.4.3
------------------------------------------------------
4.8.4 Notification of New
Certificate Issuance to
Subscriber 4.2, 4.3, 4.4.3
------------------------------------------------------
4.8.5 Conduct Constituting
Acceptance of Modified
Certificate 2.1.3, 4.3, 4.4.3
------------------------------------------------------
4.8.6 Publication of the Modified
Certificate by
the CA 2.1.5, 2.6.1,
4.2, 4.3, 4.4.3
------------------------------------------------------
4.8.7 Notification of
Certificate Issuance by
the CA to Other
Entities 2.1.5, 2.6.1,
4.2, 4.3, 4.4.3
------------------------------------------------------
4.9 Certificate Revocation
and Suspension 4.4
------------------------------------------------------
4.9.1 Circumstances for Revocation 2.1.3, 4.4.1
------------------------------------------------------
4.9.2 Who Can Request Revocation 4.4.2
------------------------------------------------------
4.9.3 Procedure for Revocation
Request 2.1.3, 4.4.3
------------------------------------------------------
4.9.4 Revocation Request Grace
Period 4.4.4
------------------------------------------------------
4.9.5 Time Within Which CA Must
Process the Revocation Request N/A
------------------------------------------------------
4.9.6 Revocation Checking
Requirements for Relying
Parties 2.1.4, 4.4.10,
4.4.12, 4.4.14
------------------------------------------------------
4.9.7 CRL Issuance Frequency 4.4.9, 4.8.3
------------------------------------------------------
4.9.8 Maximum Latency for CRLs 4.4.9
------------------------------------------------------
4.9.9 On-Line Revocation/Status
Checking Availability 4.4.11, 4.8.3
------------------------------------------------------
4.8.4 Notification of New
Certificate Issuance to
Subscriber 4.2, 4.3, 4.4.3
------------------------------------------------------
4.8.5 Conduct Constituting
Acceptance of Modified
Certificate 2.1.3, 4.3, 4.4.3
------------------------------------------------------
4.8.6 Publication of the Modified
Certificate by
the CA 2.1.5, 2.6.1,
4.2, 4.3, 4.4.3
------------------------------------------------------
4.8.7 Notification of
Certificate Issuance by
the CA to Other
Entities 2.1.5, 2.6.1,
4.2, 4.3, 4.4.3
------------------------------------------------------
4.9 Certificate Revocation
and Suspension 4.4
------------------------------------------------------
4.9.1 Circumstances for Revocation 2.1.3, 4.4.1
------------------------------------------------------
4.9.2 Who Can Request Revocation 4.4.2
------------------------------------------------------
4.9.3 Procedure for Revocation
Request 2.1.3, 4.4.3
------------------------------------------------------
4.9.4 Revocation Request Grace
Period 4.4.4
------------------------------------------------------
4.9.5 Time Within Which CA Must
Process the Revocation Request N/A
------------------------------------------------------
4.9.6 Revocation Checking
Requirements for Relying
Parties 2.1.4, 4.4.10,
4.4.12, 4.4.14
------------------------------------------------------
4.9.7 CRL Issuance Frequency 4.4.9, 4.8.3
------------------------------------------------------
4.9.8 Maximum Latency for CRLs 4.4.9
------------------------------------------------------
4.9.9 On-Line Revocation/Status
Checking Availability 4.4.11, 4.8.3
------------------------------------------------------
4.9.10 On-Line Revocation
Checking Requirements 4.4.12
------------------------------------------------------
4.9.11 Other Forms of Revocation
Advertisements Available 4.4.13, 4.4.14,
4.8.3
------------------------------------------------------
4.9.12 Special Requirements re
Key Compromise 4.4.15
------------------------------------------------------
4.9.13 Circumstances for Suspension 2.1.3, 4.4.5
------------------------------------------------------
4.9.14 Who Can Request Suspension 4.4.6
------------------------------------------------------
4.9.15 Procedure for
Suspension Request 2.1.3, 4.4.7
------------------------------------------------------
4.9.16 Limits on Suspension Period 4.4.8
------------------------------------------------------
4.10 Certificate Status Services 4.4.9-4.4.14
------------------------------------------------------
4.10.1 Operational
Characteristics 4.4.9, 4.4.11,
4.4.13
------------------------------------------------------
4.10.2 Service Availability 4.4.9, 4.4.11,
4.4.13
------------------------------------------------------
4.10.3 Operational Features 4.4.9, 4.4.11,
4.4.13
------------------------------------------------------
4.11 End of Subscription N/A
------------------------------------------------------
4.12 Key Escrow and Recovery 6.2.3
------------------------------------------------------
4.12.1 Key Escrow and Recovery Policy
and Practices 6.2.3
------------------------------------------------------
4.12.2 Session Key Encapsulation
and Recovery Policy and
Practices 6.2.3
------------------------------------------------------
5. Facility, Management, and
Operational Controls 2.1.3, 2.1.4,
4., 5.
------------------------------------------------------
5.1 Physical Controls 5.1
------------------------------------------------------
4.9.10 On-Line Revocation
Checking Requirements 4.4.12
------------------------------------------------------
4.9.11 Other Forms of Revocation
Advertisements Available 4.4.13, 4.4.14,
4.8.3
------------------------------------------------------
4.9.12 Special Requirements re
Key Compromise 4.4.15
------------------------------------------------------
4.9.13 Circumstances for Suspension 2.1.3, 4.4.5
------------------------------------------------------
4.9.14 Who Can Request Suspension 4.4.6
------------------------------------------------------
4.9.15 Procedure for
Suspension Request 2.1.3, 4.4.7
------------------------------------------------------
4.9.16 Limits on Suspension Period 4.4.8
------------------------------------------------------
4.10 Certificate Status Services 4.4.9-4.4.14
------------------------------------------------------
4.10.1 Operational
Characteristics 4.4.9, 4.4.11,
4.4.13
------------------------------------------------------
4.10.2 Service Availability 4.4.9, 4.4.11,
4.4.13
------------------------------------------------------
4.10.3 Operational Features 4.4.9, 4.4.11,
4.4.13
------------------------------------------------------
4.11 End of Subscription N/A
------------------------------------------------------
4.12 Key Escrow and Recovery 6.2.3
------------------------------------------------------
4.12.1 Key Escrow and Recovery Policy
and Practices 6.2.3
------------------------------------------------------
4.12.2 Session Key Encapsulation
and Recovery Policy and
Practices 6.2.3
------------------------------------------------------
5. Facility, Management, and
Operational Controls 2.1.3, 2.1.4,
4., 5.
------------------------------------------------------
5.1 Physical Controls 5.1
------------------------------------------------------
5.1.1 Site Location and Construction 5.1.1
------------------------------------------------------
5.1.2 Physical Access 5.1.2
------------------------------------------------------
5.1.3 Power and Air Conditioning 5.1.3
------------------------------------------------------
5.1.4 Water Exposures 5.1.4
------------------------------------------------------
5.1.5 Fire Prevention and Protection 5.1.5
------------------------------------------------------
5.1.6 Media Storage 5.1.6
------------------------------------------------------
5.1.7 Waste Disposal 5.1.7
------------------------------------------------------
5.1.8 Off-Site Backup 5.1.8
------------------------------------------------------
5.2 Procedural Controls 5.2
------------------------------------------------------
5.2.1 Trusted Roles 5.2.1
------------------------------------------------------
5.2.2 Number of Persons Required
per Task 5.2.2
------------------------------------------------------
5.2.3 Identification and
Authentication for Each Role 5.2.3
------------------------------------------------------
5.2.4 Roles Requiring Separation
of Duties 5.2.1, 5.2.2
------------------------------------------------------
5.3 Personnel Controls 5.3
------------------------------------------------------
5.3.1 Qualifications, Experience,
and Clearance Requirements 5.3.1
------------------------------------------------------
5.3.2 Background Check Procedures 5.3.2
------------------------------------------------------
5.3.3 Training Requirements 5.3.3
------------------------------------------------------
5.3.4 Retraining Frequency
and Requirements 5.3.4
------------------------------------------------------
5.3.5 Job Rotation Frequency
and Sequence 5.3.5
------------------------------------------------------
5.3.6 Sanctions for Unauthorized
Actions 5.3.6
------------------------------------------------------
5.1.1 Site Location and Construction 5.1.1
------------------------------------------------------
5.1.2 Physical Access 5.1.2
------------------------------------------------------
5.1.3 Power and Air Conditioning 5.1.3
------------------------------------------------------
5.1.4 Water Exposures 5.1.4
------------------------------------------------------
5.1.5 Fire Prevention and Protection 5.1.5
------------------------------------------------------
5.1.6 Media Storage 5.1.6
------------------------------------------------------
5.1.7 Waste Disposal 5.1.7
------------------------------------------------------
5.1.8 Off-Site Backup 5.1.8
------------------------------------------------------
5.2 Procedural Controls 5.2
------------------------------------------------------
5.2.1 Trusted Roles 5.2.1
------------------------------------------------------
5.2.2 Number of Persons Required
per Task 5.2.2
------------------------------------------------------
5.2.3 Identification and
Authentication for Each Role 5.2.3
------------------------------------------------------
5.2.4 Roles Requiring Separation
of Duties 5.2.1, 5.2.2
------------------------------------------------------
5.3 Personnel Controls 5.3
------------------------------------------------------
5.3.1 Qualifications, Experience,
and Clearance Requirements 5.3.1
------------------------------------------------------
5.3.2 Background Check Procedures 5.3.2
------------------------------------------------------
5.3.3 Training Requirements 5.3.3
------------------------------------------------------
5.3.4 Retraining Frequency
and Requirements 5.3.4
------------------------------------------------------
5.3.5 Job Rotation Frequency
and Sequence 5.3.5
------------------------------------------------------
5.3.6 Sanctions for Unauthorized
Actions 5.3.6
------------------------------------------------------
5.3.7 Independent Contractor
Requirements 5.3.7
------------------------------------------------------
5.3.8 Documentation Supplied to
Personnel 5.3.8
------------------------------------------------------
5.4 Audit Logging Procedures 4.5
------------------------------------------------------
5.4.1 Types of Events Recorded 4.5.1
------------------------------------------------------
5.4.2 Frequency of Processing Log 4.5.2
------------------------------------------------------
5.4.3 Retention Period for Audit
Log 4.5.3
------------------------------------------------------
5.4.4 Protection of Audit Log 4.5.4
------------------------------------------------------
5.4.5 Audit Log Backup Procedures 4.5.5
------------------------------------------------------
5.4.6 Audit Collection System
(Internal vs. External) 4.5.6
------------------------------------------------------
5.4.7 Notification to Event-Causing
Subject 4.5.7
------------------------------------------------------
5.4.8 Vulnerability Assessments 4.5.8
------------------------------------------------------
5.5 Records Archival 4.6
------------------------------------------------------
5.5.1 Types of Records Archived 4.6.1
------------------------------------------------------
5.5.2 Retention Period for Archive 4.6.2
------------------------------------------------------
5.5.3 Protection of Archive 4.6.3
------------------------------------------------------
5.5.4 Archive Backup Procedures 4.6.4
------------------------------------------------------
5.5.5 Requirements for Time-Stamping
of Records 4.6.5
------------------------------------------------------
5.5.6 Archive Collection System
(Internal or External) 4.6.6
------------------------------------------------------
5.5.7 Procedures to Obtain and
Verify Archive
Information 4.6.7
------------------------------------------------------
5.3.7 Independent Contractor
Requirements 5.3.7
------------------------------------------------------
5.3.8 Documentation Supplied to
Personnel 5.3.8
------------------------------------------------------
5.4 Audit Logging Procedures 4.5
------------------------------------------------------
5.4.1 Types of Events Recorded 4.5.1
------------------------------------------------------
5.4.2 Frequency of Processing Log 4.5.2
------------------------------------------------------
5.4.3 Retention Period for Audit
Log 4.5.3
------------------------------------------------------
5.4.4 Protection of Audit Log 4.5.4
------------------------------------------------------
5.4.5 Audit Log Backup Procedures 4.5.5
------------------------------------------------------
5.4.6 Audit Collection System
(Internal vs. External) 4.5.6
------------------------------------------------------
5.4.7 Notification to Event-Causing
Subject 4.5.7
------------------------------------------------------
5.4.8 Vulnerability Assessments 4.5.8
------------------------------------------------------
5.5 Records Archival 4.6
------------------------------------------------------
5.5.1 Types of Records Archived 4.6.1
------------------------------------------------------
5.5.2 Retention Period for Archive 4.6.2
------------------------------------------------------
5.5.3 Protection of Archive 4.6.3
------------------------------------------------------
5.5.4 Archive Backup Procedures 4.6.4
------------------------------------------------------
5.5.5 Requirements for Time-Stamping
of Records 4.6.5
------------------------------------------------------
5.5.6 Archive Collection System
(Internal or External) 4.6.6
------------------------------------------------------
5.5.7 Procedures to Obtain and
Verify Archive
Information 4.6.7
------------------------------------------------------
5.6 Key Changeover 4.7
------------------------------------------------------
5.7 Compromise and Disaster Recovery 4.8
------------------------------------------------------
5.7.1 Incident and Compromise
Handling Procedures 4.8
------------------------------------------------------
5.7.2 Computing Resources, Software,
and/or Data Are Corrupted 4.8.1
------------------------------------------------------
5.7.3 Entity Private Key
Compromise Procedures 4.8.3
------------------------------------------------------
5.7.4 Business Continuity
Capabilities After a
Disaster 4.8.4
------------------------------------------------------
5.8 CA or RA Termination 4.9
------------------------------------------------------
6. Technical Security Controls 2.1.3, 2.1.4,
6.
------------------------------------------------------
6.1 Key Pair Generation and
Installation 6.1
------------------------------------------------------
6.1.1 Key Pair Generation 6.1.1, 6.1.8
------------------------------------------------------
6.1.2 Private Key Delivery to
Subscriber 6.1.2
------------------------------------------------------
6.1.3 Public Key Delivery to
Certificate Issuer 6.1.3
------------------------------------------------------
6.1.4 CA Public Key Delivery to
Relying Parties 6.1.4
------------------------------------------------------
6.1.5 Key Sizes 6.1.5
------------------------------------------------------
6.1.6 Public Key Parameters Generation
and Quality Checking 6.1.6, 6.1.7
------------------------------------------------------
6.1.7 Key Usage Purposes
(as per X.509 v3
Key Usage Field) 6.1.9
------------------------------------------------------
5.6 Key Changeover 4.7
------------------------------------------------------
5.7 Compromise and Disaster Recovery 4.8
------------------------------------------------------
5.7.1 Incident and Compromise
Handling Procedures 4.8
------------------------------------------------------
5.7.2 Computing Resources, Software,
and/or Data Are Corrupted 4.8.1
------------------------------------------------------
5.7.3 Entity Private Key
Compromise Procedures 4.8.3
------------------------------------------------------
5.7.4 Business Continuity
Capabilities After a
Disaster 4.8.4
------------------------------------------------------
5.8 CA or RA Termination 4.9
------------------------------------------------------
6. Technical Security Controls 2.1.3, 2.1.4,
6.
------------------------------------------------------
6.1 Key Pair Generation and
Installation 6.1
------------------------------------------------------
6.1.1 Key Pair Generation 6.1.1, 6.1.8
------------------------------------------------------
6.1.2 Private Key Delivery to
Subscriber 6.1.2
------------------------------------------------------
6.1.3 Public Key Delivery to
Certificate Issuer 6.1.3
------------------------------------------------------
6.1.4 CA Public Key Delivery to
Relying Parties 6.1.4
------------------------------------------------------
6.1.5 Key Sizes 6.1.5
------------------------------------------------------
6.1.6 Public Key Parameters Generation
and Quality Checking 6.1.6, 6.1.7
------------------------------------------------------
6.1.7 Key Usage Purposes
(as per X.509 v3
Key Usage Field) 6.1.9
------------------------------------------------------
6.2 Private Key Protection and
Cryptographic Module
Engineering Controls 6.2, 6.8
------------------------------------------------------
6.2.1 Cryptographic Module Standards
and Controls 6.2.1, 6.8
------------------------------------------------------
6.2.2 Private Key (n out of m)
Multi-Person Control 6.2.2
------------------------------------------------------
6.2.3 Private Key Escrow 6.2.3
------------------------------------------------------
6.2.4 Private Key Backup 6.2.4
------------------------------------------------------
6.2.5 Private Key Archival 6.2.5
------------------------------------------------------
6.2.6 Private Key Transfer Into
or From a Cryptographic
Module 6.2.6
------------------------------------------------------
6.2.7 Private Key Storage on
Cryptographic Module 6.2.6
------------------------------------------------------
6.2.8 Method of Activating Private
Key 6.2.7
------------------------------------------------------
6.2.9 Method of Deactivating
Private Key 6.2.8
------------------------------------------------------
6.2.10 Method of Destroying
Private Key 6.2.9
------------------------------------------------------
6.2.11 Cryptographic Module Rating 6.2.1, 6.8
------------------------------------------------------
6.3 Other Aspects of Key Pair
Management 6.3
------------------------------------------------------
6.3.1 Public Key Archival 6.3.1
------------------------------------------------------
6.3.2 Certificate Operational
Periods and Key Pair Usage
Periods 6.3.2
------------------------------------------------------
6.4 Activation Data 6.4
------------------------------------------------------
6.2 Private Key Protection and
Cryptographic Module
Engineering Controls 6.2, 6.8
------------------------------------------------------
6.2.1 Cryptographic Module Standards
and Controls 6.2.1, 6.8
------------------------------------------------------
6.2.2 Private Key (n out of m)
Multi-Person Control 6.2.2
------------------------------------------------------
6.2.3 Private Key Escrow 6.2.3
------------------------------------------------------
6.2.4 Private Key Backup 6.2.4
------------------------------------------------------
6.2.5 Private Key Archival 6.2.5
------------------------------------------------------
6.2.6 Private Key Transfer Into
or From a Cryptographic
Module 6.2.6
------------------------------------------------------
6.2.7 Private Key Storage on
Cryptographic Module 6.2.6
------------------------------------------------------
6.2.8 Method of Activating Private
Key 6.2.7
------------------------------------------------------
6.2.9 Method of Deactivating
Private Key 6.2.8
------------------------------------------------------
6.2.10 Method of Destroying
Private Key 6.2.9
------------------------------------------------------
6.2.11 Cryptographic Module Rating 6.2.1, 6.8
------------------------------------------------------
6.3 Other Aspects of Key Pair
Management 6.3
------------------------------------------------------
6.3.1 Public Key Archival 6.3.1
------------------------------------------------------
6.3.2 Certificate Operational
Periods and Key Pair Usage
Periods 6.3.2
------------------------------------------------------
6.4 Activation Data 6.4
------------------------------------------------------
6.4.1 Activation Data Generation
and Installation 6.4.1
------------------------------------------------------
6.4.2 Activation Data Protection 6.4.2
------------------------------------------------------
6.4.3 Other Aspects of Activation
Data 6.4.3
------------------------------------------------------
6.5 Computer Security Controls 6.5
------------------------------------------------------
6.5.1 Specific Computer Security
Technical Requirements 6.5.1
------------------------------------------------------
6.5.2 Computer Security Rating 6.5.2
------------------------------------------------------
6.6 Life Cycle Technical Controls 6.6
------------------------------------------------------
6.6.1 System Development Controls 6.6.1
------------------------------------------------------
6.6.2 Security Management Controls 6.6.2
------------------------------------------------------
6.6.3 Life Cycle Security Controls 6.6.3
------------------------------------------------------
6.7 Network Security Controls 6.7
------------------------------------------------------
6.8 Time-Stamping N/A
------------------------------------------------------
7. Certificate, CRL, and
OCSP Profiles 7.
------------------------------------------------------
7.1 Certificate Profile 7.1
------------------------------------------------------
7.1.1 Version Number(s) 7.1.1
------------------------------------------------------
7.1.2 Certificate Extensions 7.1.2
------------------------------------------------------
7.1.3 Algorithm Object Identifiers 7.1.3
------------------------------------------------------
7.1.4 Name Forms 7.1.4
------------------------------------------------------
7.1.5 Name Constraints 7.1.5
------------------------------------------------------
7.1.6 Certificate Policy
Object Identifier 7.1.6
------------------------------------------------------
7.1.7 Usage of Policy Constraints
Extension 7.1.7
------------------------------------------------------
6.4.1 Activation Data Generation
and Installation 6.4.1
------------------------------------------------------
6.4.2 Activation Data Protection 6.4.2
------------------------------------------------------
6.4.3 Other Aspects of Activation
Data 6.4.3
------------------------------------------------------
6.5 Computer Security Controls 6.5
------------------------------------------------------
6.5.1 Specific Computer Security
Technical Requirements 6.5.1
------------------------------------------------------
6.5.2 Computer Security Rating 6.5.2
------------------------------------------------------
6.6 Life Cycle Technical Controls 6.6
------------------------------------------------------
6.6.1 System Development Controls 6.6.1
------------------------------------------------------
6.6.2 Security Management Controls 6.6.2
------------------------------------------------------
6.6.3 Life Cycle Security Controls 6.6.3
------------------------------------------------------
6.7 Network Security Controls 6.7
------------------------------------------------------
6.8 Time-Stamping N/A
------------------------------------------------------
7. Certificate, CRL, and
OCSP Profiles 7.
------------------------------------------------------
7.1 Certificate Profile 7.1
------------------------------------------------------
7.1.1 Version Number(s) 7.1.1
------------------------------------------------------
7.1.2 Certificate Extensions 7.1.2
------------------------------------------------------
7.1.3 Algorithm Object Identifiers 7.1.3
------------------------------------------------------
7.1.4 Name Forms 7.1.4
------------------------------------------------------
7.1.5 Name Constraints 7.1.5
------------------------------------------------------
7.1.6 Certificate Policy
Object Identifier 7.1.6
------------------------------------------------------
7.1.7 Usage of Policy Constraints
Extension 7.1.7
------------------------------------------------------
7.1.8 Policy Qualifiers Syntax
and Semantics 7.1.8
------------------------------------------------------
7.1.9 Processing Semantics for the
Critical Certificate Policies
Extension 7.1.9
------------------------------------------------------
7.2 CRL Profile 7.2
------------------------------------------------------
7.2.1 Version Number(s) 7.2.1
------------------------------------------------------
7.2.2 CRL and CRL Entry Extensions 7.2.1
------------------------------------------------------
7.3 OCSP Profile N/A
------------------------------------------------------
7.3.1 Version Number(s) N/A
------------------------------------------------------
7.3.2 OCSP Extensions N/A
------------------------------------------------------
8. Compliance Audit and Other
Assessments 2.7
------------------------------------------------------
8.1 Frequency and Circumstances
of Assessment 2.7.1
------------------------------------------------------
8.2 Identity/Qualifications of
Assessor 2.7.2
------------------------------------------------------
8.3 Assessor's Relationship to
Assessed Entity 2.7.3
------------------------------------------------------
8.4 Topics Covered by Assessment 2.7.4
------------------------------------------------------
8.5 Actions Taken as a Result
of Deficiency 2.7.5
------------------------------------------------------
8.6 Communications of Results 2.7.6
------------------------------------------------------
9. Other Business and Legal
Matters 2.
------------------------------------------------------
7.1.8 Policy Qualifiers Syntax
and Semantics 7.1.8
------------------------------------------------------
7.1.9 Processing Semantics for the
Critical Certificate Policies
Extension 7.1.9
------------------------------------------------------
7.2 CRL Profile 7.2
------------------------------------------------------
7.2.1 Version Number(s) 7.2.1
------------------------------------------------------
7.2.2 CRL and CRL Entry Extensions 7.2.1
------------------------------------------------------
7.3 OCSP Profile N/A
------------------------------------------------------
7.3.1 Version Number(s) N/A
------------------------------------------------------
7.3.2 OCSP Extensions N/A
------------------------------------------------------
8. Compliance Audit and Other
Assessments 2.7
------------------------------------------------------
8.1 Frequency and Circumstances
of Assessment 2.7.1
------------------------------------------------------
8.2 Identity/Qualifications of
Assessor 2.7.2
------------------------------------------------------
8.3 Assessor's Relationship to
Assessed Entity 2.7.3
------------------------------------------------------
8.4 Topics Covered by Assessment 2.7.4
------------------------------------------------------
8.5 Actions Taken as a Result
of Deficiency 2.7.5
------------------------------------------------------
8.6 Communications of Results 2.7.6
------------------------------------------------------
9. Other Business and Legal
Matters 2.
------------------------------------------------------
9.1 Fees 2.5
------------------------------------------------------
9.1.1 Certificate Issuance or
Renewal Fees 2.5.1
------------------------------------------------------
9.1 Fees 2.5
------------------------------------------------------
9.1.1 Certificate Issuance or
Renewal Fees 2.5.1
------------------------------------------------------
9.1.2 Certificate Access Fees 2.5.2
------------------------------------------------------
9.1.3 Revocation or Status
Information Access Fees 2.5.3
------------------------------------------------------
9.1.4 Fees for Other Services 2.5.4
------------------------------------------------------
9.1.5 Refund Policy 2.5.5
------------------------------------------------------
9.2 Financial Responsibility 2.3
------------------------------------------------------
9.2.1 Insurance Coverage 2.3
------------------------------------------------------
9.2.2 Other Assets 2.3
------------------------------------------------------
9.2.3 Insurance or Warranty Coverage
for End-Entities 2.3
------------------------------------------------------
9.3 Confidentiality of Business
Information 2.8
------------------------------------------------------
9.3.1 Scope of Confidential
Information 2.8.1, 2.8.3
------------------------------------------------------
9.3.2 Information Not Within the
Scope of Confidential
Information 2.8.2, 2.8.3
------------------------------------------------------
9.3.3 Responsibility to Protect
Confidential Information 2.8,
------------------------------------------------------
9.1.2 Certificate Access Fees 2.5.2
------------------------------------------------------
9.1.3 Revocation or Status
Information Access Fees 2.5.3
------------------------------------------------------
9.1.4 Fees for Other Services 2.5.4
------------------------------------------------------
9.1.5 Refund Policy 2.5.5
------------------------------------------------------
9.2 Financial Responsibility 2.3
------------------------------------------------------
9.2.1 Insurance Coverage 2.3
------------------------------------------------------
9.2.2 Other Assets 2.3
------------------------------------------------------
9.2.3 Insurance or Warranty Coverage
for End-Entities 2.3
------------------------------------------------------
9.3 Confidentiality of Business
Information 2.8
------------------------------------------------------
9.3.1 Scope of Confidential
Information 2.8.1, 2.8.3
------------------------------------------------------
9.3.2 Information Not Within the
Scope of Confidential
Information 2.8.2, 2.8.3
------------------------------------------------------
9.3.3 Responsibility to Protect
Confidential Information 2.8,
2.8.3-2.8.7
------------------------------------------------------
9.4 Privacy of Personal Information 2.8
------------------------------------------------------
9.4.1 Privacy Plan N/A
------------------------------------------------------
9.4.2 Information Treated as Private 2.8.1, 2.8.3
------------------------------------------------------
9.4.3 Information Not Deemed Private 2.8.2, 2.8.3
------------------------------------------------------
9.4.4 Responsibility to Protect
Private Information 2.8, 2.8.1,
2.8.3
------------------------------------------------------
9.4.5 Notice and Consent to Use
Private Information N/A
2.8.3-2.8.7
------------------------------------------------------
9.4 Privacy of Personal Information 2.8
------------------------------------------------------
9.4.1 Privacy Plan N/A
------------------------------------------------------
9.4.2 Information Treated as Private 2.8.1, 2.8.3
------------------------------------------------------
9.4.3 Information Not Deemed Private 2.8.2, 2.8.3
------------------------------------------------------
9.4.4 Responsibility to Protect
Private Information 2.8, 2.8.1,
2.8.3
------------------------------------------------------
9.4.5 Notice and Consent to Use
Private Information N/A
------------------------------------------------------
9.4.6 Disclosure Pursuant to
Judicial or Administrative
Process 2.8.4-2.8.5
------------------------------------------------------
9.4.7 Other Information Disclosure
Circumstances 2.8.6-2.8.7
------------------------------------------------------
9.5 Intellectual Property rights 2.9
------------------------------------------------------
9.6 Representations and Warranties 2.2
------------------------------------------------------
9.6.1 CA Representations and
Warranties 2.2.1
------------------------------------------------------
9.6.2 RA Representations and
Warranties 2.2.2
------------------------------------------------------
9.6.3 Subscriber Representations
and Warranties 2.1.3
------------------------------------------------------
------------------------------------------------------
9.4.6 Disclosure Pursuant to
Judicial or Administrative
Process 2.8.4-2.8.5
------------------------------------------------------
9.4.7 Other Information Disclosure
Circumstances 2.8.6-2.8.7
------------------------------------------------------
9.5 Intellectual Property rights 2.9
------------------------------------------------------
9.6 Representations and Warranties 2.2
------------------------------------------------------
9.6.1 CA Representations and
Warranties 2.2.1
------------------------------------------------------
9.6.2 RA Representations and
Warranties 2.2.2
------------------------------------------------------
9.6.3 Subscriber Representations
and Warranties 2.1.3
------------------------------------------------------
9.6.4 Relying Party Representations
and Warranties 2.1.4
------------------------------------------------------
9.6.5 Representations and Warranties
of Other Participants N/A
------------------------------------------------------
9.7 Disclaimers of Warranties 2.2, 2.3.2
------------------------------------------------------
9.8 Limitations of Liability 2.2
------------------------------------------------------
9.9 Indemnities 2.1.3, 2.1.4,
2.2, 2.3.1
------------------------------------------------------
9.10 Term and Termination N/A
------------------------------------------------------
9.10.1 Term N/A
------------------------------------------------------
9.10.2 Termination N/A
------------------------------------------------------
9.10.3 Effect of Termination and
Survival N/A
------------------------------------------------------
9.11 Individual Notices and
Communications with Participants 2.4.2
------------------------------------------------------
9.12 Amendments 8.1
9.6.4 Relying Party Representations
and Warranties 2.1.4
------------------------------------------------------
9.6.5 Representations and Warranties
of Other Participants N/A
------------------------------------------------------
9.7 Disclaimers of Warranties 2.2, 2.3.2
------------------------------------------------------
9.8 Limitations of Liability 2.2
------------------------------------------------------
9.9 Indemnities 2.1.3, 2.1.4,
2.2, 2.3.1
------------------------------------------------------
9.10 Term and Termination N/A
------------------------------------------------------
9.10.1 Term N/A
------------------------------------------------------
9.10.2 Termination N/A
------------------------------------------------------
9.10.3 Effect of Termination and
Survival N/A
------------------------------------------------------
9.11 Individual Notices and
Communications with Participants 2.4.2
------------------------------------------------------
9.12 Amendments 8.1
------------------------------------------------------
9.12.1 Procedure for Amendment 8.1
------------------------------------------------------
9.12.2 Notification Mechanism
and Period 8.1
------------------------------------------------------
9.12.3 Circumstances Under Which OID
Must be Changed 8.1
------------------------------------------------------
9.13 Dispute Resolution Provisions 2.4.3
------------------------------------------------------
9.14 Governing Law 2.4.1
------------------------------------------------------
9.15 Compliance with Applicable Law 2.4.1
------------------------------------------------------
9.16 Miscellaneous Provisions 2.4
------------------------------------------------------
9.16.1 Entire Agreement 2.4.2
------------------------------------------------------
9.16.2 Assignment N/A
------------------------------------------------------
9.16.3 Severability 2.4.2
------------------------------------------------------
9.16.4 Enforcement (Attorney's Fees
and Waiver of Rights) 2.4.3
------------------------------------------------------
9.17 Other Provisions N/A
------------------------------------------------------
------------------------------------------------------
9.12.1 Procedure for Amendment 8.1
------------------------------------------------------
9.12.2 Notification Mechanism
and Period 8.1
------------------------------------------------------
9.12.3 Circumstances Under Which OID
Must be Changed 8.1
------------------------------------------------------
9.13 Dispute Resolution Provisions 2.4.3
------------------------------------------------------
9.14 Governing Law 2.4.1
------------------------------------------------------
9.15 Compliance with Applicable Law 2.4.1
------------------------------------------------------
9.16 Miscellaneous Provisions 2.4
------------------------------------------------------
9.16.1 Entire Agreement 2.4.2
------------------------------------------------------
9.16.2 Assignment N/A
------------------------------------------------------
9.16.3 Severability 2.4.2
------------------------------------------------------
9.16.4 Enforcement (Attorney's Fees
and Waiver of Rights) 2.4.3
------------------------------------------------------
9.17 Other Provisions N/A
------------------------------------------------------
The development of the predecessor document (RFC 2527) was supported by the Government of Canada's Policy Management Authority (PMA) Committee, the National Security Agency, the National Institute of Standards and Technology (NIST), and the American Bar Association Information Security Committee Accreditation Working Group.
先前文件（RFC 2527）的编制得到了加拿大政府政策管理局（PMA）委员会、国家安全局、国家标准与技术研究所（NIST）和美国律师协会信息安全委员会认证工作组的支持。
This revision effort is largely a result of constant inspiration from Michael Baum. Michael Power, Mike Jenkins, and Alice Sturgeon have also made several contributions.
这一修订工作主要是迈克尔·鲍姆不断启发的结果。迈克尔·鲍尔、迈克·詹金斯和爱丽丝·斯特金也做出了一些贡献。
[ABA1] American Bar Association, Digital Signature Guidelines: Legal Infrastructure for Certification Authorities and Secure Electronic Commerce, 1996.
[ABA1]美国律师协会，《数字签名指南：认证机构和安全电子商务的法律基础设施》，1996年。
[ABA2] American Bar Association, PKI Assessment Guidelines, v0.30, Public Draft For Comment, June 2001.
[ABA2]美国律师协会，PKI评估指南，v0.30，公开征求意见稿，2001年6月。
[BAU1] Michael. S. Baum, Federal Certification Authority Liability and Policy, NIST-GCR-94-654, June 1994, available at http://www.verisign.com/repository/pubs/index.html.
迈克尔。S.Baum，联邦认证机构责任和政策，NIST-GCR-94-6541994年6月，可在http://www.verisign.com/repository/pubs/index.html.
[ETS] European Telecommunications Standards Institute, "Policy Requirements for Certification Authorities Issuing Qualified Certificates," ETSI TS 101 456, Version 1.1.1, December 2000.
[ETS]欧洲电信标准协会，“颁发合格证书的认证机构的政策要求”，ETSI TS 101 456，版本1.1.1，2000年12月。
[GOC] Government of Canada PKI Policy Management Authority, "Digital Signature and Confidentiality Certificate Policies for the Government of Canada Public Key Infrastructure," v.3.02, April 1999.
[GOC]加拿大政府PKI政策管理局，“加拿大政府公钥基础设施的数字签名和保密证书政策”，v.3.021999年4月。
[IDT] Identrus, LLC, "Identrus Identity Certificate Policy" IP-IPC Version 1.7, March 2001.
[IDT]Identitrus，LLC，“Identitrus身份证书政策”IP-IPC版本1.7，2001年3月。
[ISO1] ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information Technology - Open Systems Interconnection: The Directory: Authentication Framework," 1997 edition. (Pending publication of 2000 edition, use 1997 edition.)
[ISO1]ISO/IEC 9594-8/ITU-T建议X.509，“信息技术-开放系统互连：目录：认证框架”，1997年版。（2000版待出版，使用1997版。）
[PEM1] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management", RFC 1422, February 1993.
[PEM1]Kent，S.，“因特网电子邮件的隐私增强：第二部分：基于证书的密钥管理”，RFC 1422，1993年2月。
[PKI1] Housley, R., Polk, W. Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[PKI1]Housley，R.，Polk，W.Ford，W.和D.Solo，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）概要”，RFC 32802002年4月。
[CPF] Chokhani, S. and W. Ford, "Internet X.509 Public Key Infrastructure, Certificate Policy and Certification Practices Statement Framework", RFC 2527, March 1999.
[CPF]Chokhani，S.和W.Ford，“互联网X.509公钥基础设施、证书政策和认证实践声明框架”，RFC 2527，1999年3月。
1. A paper copy of the ABA Digital Signature Guidelines can be purchased from the ABA. See http://www.abanet.com for ordering details. The DSG may also be downloaded without charge from the ABA website at http://www.abanet.org/scitech/ec/isc/digital_signature.html.
1. ABA数字签名指南的纸质副本可从ABA购买。看见http://www.abanet.com 有关订购详情。DSG也可以从ABA网站免费下载，网址为http://www.abanet.org/scitech/ec/isc/digital_signature.html.
2. A draft of the PKI Assessment Guidelines may be downloaded without charge from the ABA website at http://www.abanet.org/scitech/ec/isc/pag/pag.html.
2. PKI评估指南草案可从ABA网站免费下载，网址为http://www.abanet.org/scitech/ec/isc/pag/pag.html.
3. The term "meaningful" means that the name form has commonly understood semantics to determine the identity of a person and/or organization. Directory names and RFC 822 names may be more or less meaningful.
3. 术语“有意义”意味着名称形式具有普遍理解的语义，以确定个人和/或组织的身份。目录名和RFC 822名称可能或多或少有意义。
4. The subject may not need to prove to the CA that the subject has possession of the private key corresponding to the public key being registered if the CA generates the subject's key pair on the subject's behalf.
4. 如果CA代表受试者生成受试者的密钥对，则受试者可能不需要向CA证明受试者拥有与注册的公钥相对应的私钥。
5. Examples of means to identify and authenticate individuals include biometric means (such as thumb print, ten finger print, and scan of the face, palm, or retina), a driver's license, a credit card, a company badge, and a government badge.
5. 识别和认证个人的方法示例包括生物测定方法（例如拇指指纹、十个指纹和面部、手掌或视网膜扫描）、驾驶执照、信用卡、公司徽章和政府徽章。
6. Certificate "modification" does not refer to making a change to an existing certificate, since this would prevent the verification of any digital signatures on the certificate and cause the certificate to be invalid. Rather, the concept of "modification" refers to a situation where the information referred to in the certificate has changed or should be changed, and the CA issues a new certificate containing the modified information. One example is a subscriber that changes his or her name, which would necessitate the issuance of a new certificate containing the new name.
6. 证书“修改”不是指对现有证书进行更改，因为这将阻止对证书上的任何数字签名进行验证，并导致证书无效。相反，“修改”的概念是指证书中提及的信息已经更改或应该更改，并且CA发布包含修改信息的新证书的情况。一个例子是订户更改了自己的姓名，这将需要颁发包含新姓名的新证书。
7. The n out of m rule allows a private 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 private key, but having any n-1 parts provides one with no information about the private key.
7. n of m规则允许私钥拆分为m个部分。m个部分可能被给予m个不同的个体。m个部分中的任意n个部分可用于完全重构私钥，但是具有任意n-1个部分提供了没有关于私钥的信息的私钥。
8. A private key may be escrowed, backed up, or archived. Each of these functions has a different purpose. Thus, a private 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 obtain the private key without the cooperation of the subscriber. The purpose of back up is to allow the subscriber to reconstitute the key in case of the destruction or corruption of the key for business continuity purposes. The purpose of archives is to provide for reuse of the private key in the future, e.g., use to decrypt a document.
8. 私钥可以托管、备份或存档。每个功能都有不同的用途。因此，根据需求，私钥可以通过这些功能的任何子集。托管的目的是允许第三方（如组织或政府）在没有订户合作的情况下获得私钥。备份的目的是允许订户在密钥被破坏或损坏时重新配置密钥，以实现业务连续性。存档的目的是为将来重新使用私钥提供便利，例如用于解密文档。
9. WebTrust refers to the "WebTrust Program for Certification Authorities," from the American Institute of Certified Public Accountants, Inc., and the Canadian Institute of Chartered Accountants.
9. WebTrust指的是美国注册会计师协会和加拿大特许会计师协会的“认证机构WebTrust计划”。
10. See <http://www.aicpa.org>.
10. 看<http://www.aicpa.org>.
11. All or some of the following items may be different for the various types of entities, i.e., CA, RA, and end entities.
11. 对于不同类型的实体，即CA、RA和终端实体，以下所有或部分项目可能不同。
ABA - American Bar Association CA - Certification Authority CP - Certificate Policy 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
ABA-美国律师协会CA-认证机构CP-证书政策CPS-认证实践声明CRL-证书撤销列表DAM-修订草案FIPS-联邦信息处理标准I&A-识别和认证IEC-国际电工委员会IETF-互联网工程任务部队IP-互联网协议ISO-国际标准化组织ITU-国际电信联盟NIST-国家标准和技术研究所OID-对象标识符PIN-个人识别号PKI-公钥基础设施PKIX-公钥基础设施（X.509）（IETF工作组）RA-注册机构RFC-征求意见URL-统一资源定位器美国-美国
Santosh Chokhani Orion Security Solutions, Inc. 3410 N. Buchanan Street Arlington, VA 22207
Santosh Chokhani Orion Security Solutions，Inc.弗吉尼亚州阿灵顿布坎南大街北3410号22207
Phone: (703) 237-4621 Fax: (703) 237-4920 EMail: chokhani@orionsec.com
电话：（703）237-4621传真：（703）237-4920电子邮件：chokhani@orionsec.com
Warwick Ford VeriSign, Inc. 6 Ellery Square Cambridge, MA 02138
华威福特威瑞信公司，马萨诸塞州剑桥市埃勒里广场6号，邮编02138
Phone: (617) 642-0139 EMail: wford@verisign.com
电话：（617）642-0139电子邮件：wford@verisign.com
Randy V. Sabett, J.D., CISSP Cooley Godward LLP One Freedom Square, Reston Town Center 11951 Freedom Drive Reston, VA 20190-5656
Randy V.Sabett，J.D.，西斯普Cooley Godward有限责任合伙公司自由广场一号，莱斯顿市中心，自由大道11951号，弗吉尼亚州莱斯顿，20190-5656
Phone: (703) 456-8137 Fax: (703) 456-8100 EMail: rsabett@cooley.com
电话：（703）456-8137传真：（703）456-8100电子邮件：rsabett@cooley.com
Charles (Chas) R. Merrill McCarter & English, LLP Four Gateway Center 100 Mulberry Street Newark, New Jersey 07101-0652
Charles（Chas）R.Merrill McCarter&English律师事务所，新泽西州纽瓦克市桑树街100号四网关中心律师事务所，邮编：07101-0652
Phone: (973) 622-4444 Fax: (973) 624-7070 EMail: cmerrill@mccarter.com
电话：（973）622-4444传真：（973）624-7070电子邮件：cmerrill@mccarter.com
Stephen S. Wu Infoliance, Inc. 800 West El Camino Real Suite 180 Mountain View, CA 94040
Stephen S.Wu Infoliance，Inc.800西埃尔卡米诺皇家套房180山景城，加利福尼亚州94040
Phone: (650) 917-8045 Fax: (650) 618-1454 EMail: swu@infoliance.com
电话：（650）917-8045传真：（650）618-1454电子邮件：swu@infoliance.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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 assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。