Network Working Group S. Chokhani
Request for Comments: 2527 CygnaCom Solutions, Inc.
Category: Informational W. Ford
VeriSign, Inc.
March 1999
Network Working Group S. Chokhani
Request for Comments: 2527 CygnaCom Solutions, Inc.
Category: Informational W. Ford
VeriSign, Inc.
March 1999
Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework
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 (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
This document presents a framework to assist the writers of certificate policies or certification practice statements for certification authorities and public key infrastructures. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy definition or a certification practice statement.
本文件提供了一个框架，以协助认证机构和公钥基础设施的证书政策或认证实践声明的编写者。特别是，该框架提供了一个全面的主题列表，这些主题可能（由作者自行决定）需要包含在证书策略定义或认证实践声明中。
A public-key certificate (hereinafter "certificate") binds a public-key value to a set of information that identifies the entity (such as person, organization, account, or site) associated with use of the corresponding private key (this entity is known as the "subject" of the certificate). A certificate is used by a "certificate user" or "relying party" that needs to use, and rely upon the accuracy of, the public key distributed via that certificate (a certificate user is typically an entity that is verifying a digital signature from the certificate's subject or an entity sending encrypted data to the subject). The degree to which a certificate user can trust the binding embodied in a certificate depends on several factors. These factors include the practices followed by the certification authority (CA) in authenticating the subject; the CA's operating policy, procedures, and security controls; the subject's obligations (for example, in protecting the private key); and the stated undertakings
公钥证书（以下简称“证书”）将公钥值绑定到一组信息，这些信息标识与使用相应私钥相关的实体（如个人、组织、帐户或站点）（该实体称为证书的“主体”）。证书由需要使用并依赖通过该证书分发的公钥的准确性的“证书用户”或“依赖方”使用（证书用户通常是验证来自证书主体的数字签名的实体或向该主体发送加密数据的实体）。证书用户可以信任证书中包含的绑定的程度取决于几个因素。这些因素包括认证机构（CA）在认证主体时遵循的实践；CA的操作政策、程序和安全控制；主体的义务（例如，保护私钥）；以及声明的承诺
and legal obligations of the CA (for example, warranties and limitations on liability).
以及CA的法律义务（例如，责任的保证和限制）。
A Version 3 X.509 certificate may contain a field declaring that one or more specific certificate policies applies to that certificate [ISO1]. According to X.509, a certificate policy is "a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements." A certificate policy may be used by a certificate user to help in deciding whether a certificate, and the binding therein, is sufficiently trustworthy for a particular application. The certificate policy concept is an outgrowth of the policy statement concept developed for Internet Privacy Enhanced Mail [PEM1] and expanded upon in [BAU1].
版本3 X.509证书可能包含一个字段，声明一个或多个特定的证书策略应用于该证书[ISO1]。根据X.509，证书策略是“一组指定的规则，表明证书对具有共同安全要求的特定社区和/或应用程序类别的适用性。”证书用户可以使用证书策略来帮助决定证书是否可用，以及其中的绑定，对于特定的应用程序来说是足够值得信赖的。证书政策概念是为互联网隐私增强邮件[PEM1]开发的政策声明概念的产物，并在[BAU1]中扩展。
A more detailed description of the practices followed by a CA in issuing and otherwise managing certificates may be contained in a certification practice statement (CPS) published by or referenced by the CA. According to the American Bar Association Digital Signature Guidelines (hereinafter "ABA Guidelines"), "a CPS is a statement of the practices which a certification authority employs in issuing certificates." [ABA1]
根据美国律师协会数字签名指南（以下简称“ABA指南”），CA发布或引用的认证实践声明（CPS）中可能包含CA在颁发和管理证书时遵循的实践的更详细描述，“CPS是认证机构在颁发证书时采用的实践声明。”[ABA1]
The purpose of this document is to establish a clear relationship between certificate policies and CPSs, and to present a framework to assist the writers of certificate policies or CPSs with their tasks. In particular, the framework identifies the elements that may need to be considered in formulating a certificate policy or a CPS. The purpose is not to define particular certificate policies or CPSs, per se.
本文档的目的是在证书策略和CPS之间建立明确的关系，并提供一个框架，以帮助证书策略或CPS的编写者完成其任务。特别是，该框架确定了在制定证书策略或CPS时可能需要考虑的要素。其目的不是定义特定的证书策略或CP本身。
The scope of this document is limited to discussion of the contents of a certificate policy (as defined in X.509) or CPS (as defined in the ABA Guidelines). In particular, this document describes the types of information that should be considered for inclusion in a certificate policy definition or a CPS. While the framework as presented generally assumes use of the X.509 version 3 certificate format, it is not intended that the material be restricted to use of that certificate format. Rather, it is intended that this framework be adaptable to other certificate formats that may come into use.
本文件的范围仅限于讨论证书政策（定义见X.509）或CPS（定义见ABA指南）的内容。特别是，本文档描述了应考虑包含在证书策略定义或CPS中的信息类型。虽然所提供的框架通常假定使用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) beyond the policy elements that are considered
该范围不扩展到一般定义安全策略（如组织安全策略、系统安全策略或数据标签策略），超出了所考虑的策略元素
of particular relevance to certificate policies or CPSs.
与证书策略或CP特别相关。
This document does not define a specific certificate policy or CPS.
本文档未定义特定的证书策略或CP。
It is assumed that the reader is familiar with the general concepts of digital signatures, certificates, and public-key infrastructure, as used in X.509 and the ABA Guidelines.
假定读者熟悉X.509和ABA指南中使用的数字签名、证书和公钥基础设施的一般概念。
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、密码或手动持有的密钥共享）。
CA-certificate - A certificate for one CA's public key issued by another CA.
CA证书-一个CA的公钥由另一个CA颁发的证书。
Certificate policy - A named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements. For example, a particular certificate policy might indicate applicability of a type of certificate to the authentication of electronic data interchange transactions for the trading of goods within a given price range.
证书策略—一组命名规则，指示证书对具有通用安全要求的特定社区和/或应用程序类别的适用性。例如，特定的证书政策可能表明某种类型的证书适用于在给定价格范围内进行货物交易的电子数据交换交易的认证。
Certification path - An ordered sequence of certificates which, together with the public key of the initial object in the path, can be processed to obtain that of the final object in the path.
证书路径-一个有序的证书序列，与路径中初始对象的公钥一起，可以进行处理以获得路径中最终对象的公钥。
Certification Practice Statement (CPS) - A statement of the practices which a certification authority employs in issuing certificates.
认证实践声明（CPS）-认证机构在颁发证书时采用的实践声明。
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（另请参见主体证书颁发机构）。
Policy qualifier - Policy-dependent information that accompanies a certificate policy identifier in an X.509 certificate.
策略限定符—与X.509证书中的证书策略标识符相关的策略相关信息。
Registration authority (RA) - An entity that is responsible for identification and authentication of certificate subjects, but that does not sign or issue certificates (i.e., an RA is delegated certain tasks on behalf of a CA). [Note: The term Local Registration Authority (LRA) is used elsewhere for the same concept.]
注册机构（RA）-负责识别和认证证书主体，但不签署或颁发证书的实体（即，RA被授权代表CA执行某些任务）。[注：同一概念在其他地方使用了“地方登记机关”（LRA）一词。]
Relying party - A recipient of a certificate who acts in reliance on that certificate and/or digital signatures verified using that certificate. In this document, the terms "certificate user" and "relying party" are used interchangeably.
依赖方-依赖该证书和/或使用该证书验证的数字签名的证书接收方。在本文件中，术语“证书用户”和“依赖方”可互换使用。
Set of provisions - A collection of practice and/or policy statements, spanning a range of standard topics, for use in expressing a certificate policy definition or CPS employing the approach described in this framework.
一套规定-涵盖一系列标准主题的实践和/或政策声明的集合，用于表达采用本框架中所述方法的证书政策定义或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（另请参见颁发证书颁发机构）。
This section explains the concepts of certificate policy and CPS, and describes their relationship. Other related concepts are also described. Some of the material covered in this section and in some other sections is specific to certificate policies extensions as defined X.509 version 3. Except for those sections, this framework is intended to be adaptable to other certificate formats that may come into use.
本节解释了证书策略和CPS的概念，并描述了它们之间的关系。还描述了其他相关概念。本节和其他一些章节中介绍的某些内容特定于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 a particular entity (the certificate subject). However, the extent to which the certificate user should rely on that statement by the CA needs to be assessed by the certificate user. Different certificates are issued following different practices and procedures, and may be suitable for different applications and/or purposes.
当证书颁发机构颁发证书时，它向证书用户（即依赖方）提供声明，说明特定公钥绑定到特定实体（证书主体）。但是，证书用户应该在多大程度上依赖CA的声明，需要由证书用户进行评估。根据不同的实践和程序颁发不同的证书，可能适用于不同的应用和/或目的。
The X.509 standard defines a certificate policy as "a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements"[ISO1]. An X.509 Version 3 certificate may contain an indication of certificate policy, which may be used by a certificate user to decide whether or not to trust a certificate for a particular purpose.
X.509标准将证书策略定义为“一组命名规则，表明证书适用于具有通用安全要求的特定社区和/或应用程序类别”[ISO1]。X.509版本3证书可能包含证书策略的指示，证书用户可以使用该指示来决定是否为特定目的信任证书。
A certificate policy, which needs to be recognized by both the issuer and user of a certificate, is represented in a certificate by a unique, registered Object Identifier. The registration process follows the procedures specified in ISO/IEC and ITU standards. The
证书策略需要由证书的颁发者和用户共同识别，它在证书中由唯一的注册对象标识符表示。注册过程遵循ISO/IEC和ITU标准中规定的程序。这个
party that registers the Object Identifier also publishes a textual specification of the certificate policy, for examination by certificate users. Any one certificate will typically declare a single certificate policy or, possibly, be issued consistent with a small number of different policies.
注册对象标识符的一方还发布证书策略的文本规范，供证书用户检查。任何一个证书通常都会声明一个证书策略，或者可能会与少量不同的策略一致。
Certificate policies also constitute a basis for accreditation of CAs. Each CA is accredited against one or more certificate policies which it is recognized as implementing. When one CA issues a CA-certificate for another CA, the issuing CA must assess the set of certificate policies for which it trusts the subject CA (such assessment may be based upon accreditation with respect to the certificate policies involved). The assessed set of certificate policies is then indicated by the issuing CA in the CA-certificate. The X.509 certification path processing logic employs these certificate policy indications in its well-defined trust model.
证书政策也是认证中国科学院的基础。每个CA都是根据一个或多个证书政策进行认证的，该证书政策被认为是实施的。当一个CA为另一个CA颁发CA证书时，颁发CA必须评估其信任主体CA的一组证书策略（此类评估可能基于所涉及证书策略的认证）。然后由CA证书中的颁发CA指示经过评估的证书策略集。X.509证书路径处理逻辑在其定义良好的信任模型中使用这些证书策略指示。
For example purposes, suppose that IATA undertakes to define some certificate policies for use throughout the airline industry, in a public-key infrastructure operated by IATA in combination with public-key infrastructures operated by individual airlines. Two certificate policies are defined - the IATA General-Purpose policy, and the IATA Commercial-Grade policy.
例如，假设国际航空运输协会承诺在国际航空运输协会运营的公钥基础设施中，结合各航空公司运营的公钥基础设施，定义一些在整个航空业中使用的证书政策。定义了两种证书政策——IATA通用政策和IATA商用级政策。
The IATA General-Purpose policy is intended for use by industry personnel for protecting routine information (e.g., casual electronic mail) and for authenticating connections from World Wide Web browsers to servers for general information retrieval purposes. The key pairs may be generated, stored, and managed using low-cost, software-based systems, such as commercial browsers. Under this policy, a certificate may be automatically issued to anybody listed as an employee in the corporate directory of IATA or any member airline who submits a signed certificate request form to a network administrator in his or her organization.
IATA通用政策旨在供行业人员用于保护日常信息（如临时电子邮件）和验证从万维网浏览器到服务器的连接，以便进行一般信息检索。可以使用低成本、基于软件的系统（例如商业浏览器）生成、存储和管理密钥对。根据该政策，证书可自动颁发给IATA公司目录中列出的任何员工或向其所在组织的网络管理员提交签名证书申请表的任何成员航空公司。
The IATA Commercial-Grade policy is used to protect financial transactions or binding contractual exchanges between airlines. Under this policy, IATA requires that certified key pairs be generated and stored in approved cryptographic hardware tokens. Certificates and tokens are provided to airline employees with disbursement authority. These authorized individuals are required to present themselves to the corporate security office, show a valid identification badge, and sign an undertaking to protect the token and use it only for authorized purposes, before a token and a certificate are issued.
IATA商业级政策用于保护航空公司之间的金融交易或具有约束力的合同交换。根据该政策，IATA要求生成经认证的密钥对，并将其存储在经批准的加密硬件令牌中。向具有支付权限的航空公司员工提供证书和代币。在颁发代币和证书之前，这些授权人员必须向公司安全办公室出示自己的身份证，并签署承诺书，以保护代币，并仅将其用于授权目的。
The following extension fields in an X.509 certificate are used to support certificate policies:
X.509证书中的以下扩展字段用于支持证书策略：
* Certificate Policies extension; * Policy Mappings extension; and * Policy Constraints extension.
* 证书策略扩展；*政策映射扩展；和*政策限制扩展。
The Certificate Policies extension has two variants - one with the field flagged non-critical and one with the field flagged critical. The purpose of the field is different in the two cases.
证书策略扩展有两个变体—一个字段标记为非关键，另一个字段标记为关键。在这两种情况下，字段的用途不同。
A non-critical Certificate Policies field lists certificate policies that the certification authority declares are applicable. However, use of the certificate is not restricted to the purposes indicated by the applicable policies. Using the example of the IATA General-Purpose and Commercial-Grade policies defined in Section 3.2, the certificates issued to regular airline employees will contain the object identifier for certificate policy for the General-Purpose policy. The certificates issued to the employees with disbursement authority will contain the object identifiers for both the General-Purpose policy and the Commercial-Grade policy. The Certificate Policies field may also optionally convey qualifier values for each identified policy; use of qualifiers is discussed in Section 3.4.
非关键证书策略字段列出证书颁发机构声明的适用证书策略。但是，证书的使用不限于适用政策规定的目的。以第3.2节中定义的IATA通用和商业级政策为例，颁发给普通航空公司员工的证书将包含通用政策证书政策的对象标识符。发放给具有支付权限的员工的证书将包含通用保单和商业级保单的对象标识符。证书策略字段还可以选择性地传递每个已识别策略的限定符值；第3.4节讨论了限定符的使用。
The non-critical Certificate Policies field is designed to be used by applications as follows. Each application is pre-configured to know what policy it requires. Using the example in Section 3.2, electronic mail applications and Web servers will be configured to require the General-Purpose policy. However, an airline's financial applications will be configured to require the Commercial-Grade policy for validating financial transactions over a certain dollar value.
“非关键证书策略”字段旨在供应用程序使用，如下所示。每个应用程序都预先配置为知道它需要什么策略。使用第3.2节中的示例，电子邮件应用程序和Web服务器将配置为需要通用策略。但是，航空公司的金融应用程序将被配置为需要商业级策略来验证超过特定美元价值的金融交易。
When processing a certification path, a certificate policy that is acceptable to the certificate-using application must be present in every certificate in the path, i.e., in CA-certificates as well as end entity certificates.
处理证书路径时，路径中的每个证书（即CA证书以及终端实体证书）中都必须存在使用证书的应用程序可接受的证书策略。
If the Certificate Policies field is flagged critical, it serves the same purpose as described above but also has an additional role. It indicates that the use of the certificate is restricted to one of the identified policies, i.e., the certification authority is declaring that the certificate must only be used in accordance with the provisions of one of the listed certificate policies. This field is
如果证书策略字段被标记为关键字段，则其用途与上述相同，但还具有其他角色。它表示证书的使用仅限于确定的策略之一，即，证书颁发机构声明证书只能按照列出的证书策略之一的规定使用。这个领域是
intended to protect the certification authority against damage claims by a relying party who has used the certificate for an inappropriate purpose or in an inappropriate manner, as stipulated in the applicable certificate policy definition.
旨在保护认证机构免受依赖方的损害索赔，该依赖方将证书用于不适当的目的或以不适当的方式使用，如适用的证书政策定义所规定。
For example, the Internal Revenue Service might issue certificates to taxpayers for the purpose of protecting tax filings. The Internal Revenue Service understands and can accommodate the risks of accidentally issuing a bad certificate, e.g., to a wrongly-authenticated person. However, suppose someone used an Internal Revenue Service tax-filing certificate as the basis for encrypting multi-million-dollar-value proprietary secrets which subsequently fell into the wrong hands because of an error in issuing the Internal Revenue Service certificate. The Internal Revenue Service may want to protect itself against claims for damages in such circumstances. The critical-flagged Certificate Policies extension is intended to mitigate the risk to the certificate issuer in such situations.
例如，为了保护纳税申报，美国国税局可能会向纳税人颁发证书。美国国税局理解并能够承受意外颁发坏证书的风险，例如，向错误认证的人员颁发坏证书的风险。然而，假设有人使用美国国税局的报税证书作为加密价值数百万美元的专有机密的基础，这些机密随后由于颁发美国国税局证书的错误而落入坏人之手。在这种情况下，美国国税局可能希望保护自己免受损害索赔。“关键标记证书策略”扩展旨在减轻此类情况下证书颁发者面临的风险。
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 the ACE Corporation establishes an agreement with the ABC Corporation to cross-certify each others' public-key infrastructures for the purposes of mutually protecting electronic data interchange (EDI). Further, suppose that both companies have pre-existing financial transaction protection policies called ace-e-commerce and abc-e-commerce, respectively. One can see that simply generating cross certificates between the two domains will not provide the necessary interoperability, as the two companies' applications are configured with and employee certificates are populated with their respective certificate policies. One possible solution is to reconfigure all of the financial applications to require either policy and to reissue all the certificates with both policies. Another solution, which may be easier to administer, uses the Policy Mapping field. If this field is included in a cross-certificate for the ABC Corporation certification authority issued by the ACE Corporation certification authority, it can provide a statement that the ABC's financial transaction protection policy (i.e., abc-e-commerce) can be considered equivalent to that of the ACE Corporation (i.e., ace-e-commerce).
例如，假设ACE公司与ABC公司签订协议，相互认证对方的公钥基础设施，以相互保护电子数据交换（EDI）。此外，假设两家公司都有预先存在的金融交易保护政策，分别称为ace-e-commerce和abc-e-commerce。可以看出，简单地在两个域之间生成交叉证书并不能提供必要的互操作性，因为这两家公司的应用程序都配置了证书，员工证书也填充了各自的证书策略。一种可能的解决方案是重新配置所有金融应用程序，使其需要任何一种策略，并使用这两种策略重新颁发所有证书。另一个可能更易于管理的解决方案使用策略映射字段。如果此字段包含在ACE公司认证机构颁发的ABC公司认证机构交叉证书中，则它可以提供一份声明，说明ABC的金融交易保护政策（即ABC电子商务）可以被视为等同于ACE公司的金融交易保护政策（即ACE电子商务）。
The Policy Constraints extension supports two optional features. The first is the ability for a certification authority to require that explicit certificate policy indications be present in all subsequent certificates in a certification path. Certificates at the start of a certification path may be considered by a certificate user to be part of a trusted domain, i.e., certification authorities are trusted for all purposes so no particular certificate policy is needed in the Certificate Policies extension. Such certificates need not contain explicit indications of certificate policy. However, when a certification authority in the trusted domain certifies outside the domain, it can activate the requirement for explicit certificate policy in subsequent certificates in the certification path.
策略约束扩展支持两个可选功能。第一种是证书颁发机构能够要求在证书路径中的所有后续证书中显示明确的证书策略指示。证书用户可以将证书路径开始处的证书视为受信任域的一部分，即证书颁发机构在所有方面都是受信任的，因此证书策略扩展中不需要特定的证书策略。此类证书不需要包含证书策略的明确指示。但是，当受信任域中的证书颁发机构在域外进行证书颁发时，它可以在证书路径中的后续证书中激活对显式证书策略的要求。
The other optional feature in the Policy Constraints field is the ability for a certification authority to disable policy mapping by subsequent certification authorities in a certification path. It may be prudent to disable policy mapping when certifying outside the domain. This can assist in controlling risks due to transitive trust, e.g., a domain A trusts domain B, domain B trusts domain C, but domain A does not want to be forced to trust domain C.
“策略约束”字段中的另一个可选功能是证书颁发机构能够禁用证书路径中后续证书颁发机构的策略映射。在域外进行认证时禁用策略映射可能是明智的。这有助于控制由于可传递信任而产生的风险，例如，域a信任域B，域B信任域C，但域a不希望被迫信任域C。
The Certificate Policies extension field has a provision for conveying, along with each certificate policy identifier, additional policy-dependent information in a qualifier field. The X.509 standard does not mandate the purpose for which this field is to be used, nor does it prescribe the syntax for this field. Policy qualifier types can be registered by any organization.
Certificate Policys extension字段有一个规定，用于在限定符字段中与每个证书策略标识符一起传递附加的策略相关信息。X.509标准没有规定使用此字段的目的，也没有规定此字段的语法。任何组织都可以注册策略限定符类型。
The following policy qualifier types are defined in PKIX Part I [PKI1]:
PKIX第一部分[PKI1]中定义了以下策略限定符类型：
(a) The CPS Pointer qualifier contains a pointer to a Certification Practice Statement (CPS) published by the CA. The pointer is in the form of a uniform resource identifier (URI).
(a) CPS指针限定符包含指向CA发布的认证实践声明（CPS）的指针。该指针采用统一资源标识符（URI）的形式。
(b) The User Notice qualifier contains a text string that is to be displayed to a certificate user (including subscribers and relying parties) prior to the use of the certificate. The text string may be an IA5String or a BMPString - a subset of the ISO 100646-1 multiple octet coded character set. A CA may invoke a procedure that requires that the certficate user acknowledge that the applicable terms and conditions have been disclosed or accepted.
(b) 用户通知限定符包含一个文本字符串，该字符串将在使用证书之前显示给证书用户（包括订阅者和依赖方）。文本字符串可以是IA5String或BMPString—ISO 100646-1多个八位编码字符集的子集。CA可以调用一个程序，要求证书用户承认已披露或接受适用的条款和条件。
Policy qualifiers can be used to support the definition of generic, or parameterized, certificate policy definitions. Provided the base certificate policy definition so provides, policy qualifier types can be defined to convey, on a per-certificate basis, additional specific policy details that fill in the generic definition.
策略限定符可用于支持通用或参数化证书策略定义的定义。如果基本证书策略定义如此提供，则可以定义策略限定符类型，以便在每个证书的基础上传递填充通用定义的其他特定策略详细信息。
The term certification practice statement (CPS) is defined by the ABA Guidelines as: "A statement of the practices which a certification authority employs in issuing certificates." [ABA1] In the 1995 draft of the ABA guidelines, the ABA expands this definition with the following comments:
ABA指南将认证实践声明（CPS）一词定义为：“认证机构在颁发证书时采用的实践声明。”[ABA1]在1995年的ABA指南草案中，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, or it may be a statute or regulation applicable to the certification authority and covering similar subject matter. It may also be part of the contract between the certification authority and the subscriber. A certification practice statement may also be comprised of multiple documents, a combination of public law, private contract, and/or declaration.
认证实践声明的形式可以是认证机构声明其可信赖系统的详细信息，以及其在运营和支持颁发证书时采用的实践，或者，它可能是适用于认证机构并涵盖类似主题的法规或条例。它也可能是认证机构和用户之间合同的一部分。认证实践声明也可以由多个文件、公法、私人合同和/或声明的组合组成。
Certain forms for legally implementing certification practice statements lend themselves to particular relationships. For example, when the legal relationship between a certification authority and subscriber is consensual, a contract would ordinarily be the means of giving effect to a certification practice statement. The certification authority's duties to a relying person are generally based on the certification authority's representations, which may include a certification practice statement.
合法实施认证实践声明的某些形式适用于特定关系。例如，如果认证机构和订户之间的法律关系是协商一致的，则合同通常是使认证惯例声明生效的手段。认证机构对依赖人的职责通常基于认证机构的陈述，其中可能包括认证实践声明。
Whether a certification practice statement is binding on a relying person depends on whether the relying person has knowledge or notice of the certification practice statement. A relying person has knowledge or at least notice of the contents of the certificate used by the relying person to verify a digital signature, including documents incorporated into the certificate by reference. It is therefore advisable to incorporate a certification practice statement into a certificate by reference.
认证惯例声明是否对依赖人具有约束力取决于依赖人是否知道或注意到认证惯例声明。依赖人知道或至少知道依赖人用于验证数字签名的证书内容，包括通过引用并入证书的文件。因此，建议通过引用将认证实践声明纳入证书中。
As much as possible, a certification practice statement should indicate any of the widely recognized standards to which the certification authority's practices conform. Reference to widely recognized standards may indicate concisely the suitability of the
认证惯例声明应尽可能表明认证机构的惯例所遵循的任何广泛认可的标准。参考广泛认可的标准可简明扼要地表明本标准的适用性
certification authority's practices for another person's purposes, as well as the potential technological compatibility of the certificates issued by the certification authority with repositories and other systems.
认证机构针对他人目的的做法，以及认证机构颁发的证书与存储库和其他系统的潜在技术兼容性。
3.6 RELATIONSHIP BETWEEN CERTIFICATE POLICY AND CERTIFICATION PRACTICE STATEMENT
3.6 证书政策和认证实践声明之间的关系
The concepts of certificate policy and CPS come from different sources and were developed for different reasons. However, their interrelationship is important.
证书策略和CPS的概念来自不同的来源，发展的原因也不同。然而，它们之间的相互关系很重要。
A certification practice statement is a detailed statement by a certification authority as to its practices, that potentially needs to be understood and consulted by subscribers and certificate users (relying parties). Although the level of detail may vary among CPSs, they will generally be more detailed than certificate policy definitions. Indeed, CPSs may be quite comprehensive, robust documents providing a description of the precise service offerings, detailed procedures of the life-cycle management of certificates, and more - a level of detail which weds the CPS to a particular (proprietary) implementation of a service offering.
认证惯例声明是认证机构就其惯例所作的详细声明，可能需要用户和证书用户（依赖方）理解和咨询。尽管各CP的详细程度可能有所不同，但它们通常比证书策略定义更详细。事实上，CPS可能是相当全面、健壮的文档，提供了对精确服务产品的描述、证书生命周期管理的详细程序，以及更详细的内容——将CPS与服务产品的特定（专有）实现相结合的详细程度。
Although such detail may be indispensable to adequately disclose, and to make a full assessment of trustworthiness in the absence of accreditation or other recognized quality metrics, a detailed CPS does not form a suitable basis for interoperability between CAs operated by different organizations. Rather, certificate policies best serve as the vehicle on which to base common interoperability standards and common assurance criteria on an industry-wide (or possibly more global) basis. A CA with a single CPS may support multiple certificate policies (used for different application purposes and/or by different certificate user communities). Also, multiple different CAs, with non-identical certification practice statements, may support the same certificate policy.
尽管在缺乏认证或其他公认质量指标的情况下，这些细节对于充分披露和全面评估可信度可能是必不可少的，但详细的CPS并不构成不同组织运营的CA之间互操作性的适当基础。相反，证书策略最适合作为在整个行业（或可能更全球化）基础上建立通用互操作性标准和通用保证标准的工具。具有单个CP的CA可能支持多个证书策略（用于不同的应用程序目的和/或由不同的证书用户社区使用）。此外，多个不同的CA（具有不相同的认证实践声明）可能支持相同的证书策略。
For example, the Federal Government might define a government-wide certificate policy for handling confidential human resources information. The certificate policy definition will be a broad statement of the general characteristics of that certificate policy, and an indication of the types of applications for which it is suitable for use. Different departments or agencies that operate certification authorities with different certification practice statements might support this certificate policy. At the same time, such certification authorities may support other certificate policies.
例如，联邦政府可能会为处理机密人力资源信息定义一个政府范围的证书政策。证书策略定义将概括说明该证书策略的一般特征，并指出其适合使用的应用程序类型。使用不同认证实践声明运营认证机构的不同部门或机构可能支持此认证政策。同时，此类证书颁发机构可能支持其他证书策略。
The main difference between certificate policy and CPS can therefore be summarized as follows:
因此，证书策略和CPS之间的主要区别可以总结如下：
(a) Most organizations that operate public or inter-organizational certification authorities will document their own practices in CPSs or similar statements. The CPS is one of the organization's means of protecting itself and positioning its business relationships with subscribers and other entities.
(a) 大多数运营公共或跨组织认证机构的组织将在CPS或类似声明中记录其自身的实践。CPS是组织保护自身和定位其与订阅者和其他实体的业务关系的手段之一。
(b) There is strong incentive, on the other hand, for a certificate policy to apply more broadly than to just a single organization. If a particular certificate policy is widely recognized and imitated, it has great potential as the basis of automated certificate acceptance in many systems, including unmanned systems and systems that are manned by people not independently empowered to determine the acceptability of different presented certificates.
(b) 另一方面，有很强的动机促使证书政策比单一组织更广泛地适用。如果一个特定的证书策略被广泛认可和模仿，那么它就有很大的潜力作为许多系统中自动证书接受的基础，包括无人系统和由没有独立授权来确定不同证书可接受性的人员操作的系统。
In addition to populating the certificate policies field with the certificate policy identifier, a certification authority may include, in certificates it issues, a reference to its certification practice statement. A standard way to do this, using a certificate policy qualifier, is described in Section 3.4.
除了用证书策略标识符填充证书策略字段外，证书颁发机构还可以在其颁发的证书中包含对其认证实践声明的引用。第3.4节介绍了使用证书策略限定符执行此操作的标准方法。
A set of provisions is a collection of practice and/or policy statements, spanning a range of standard topics, for use in expressing a certificate policy definition or CPS employing the approach described in this framework.
一组规定是一系列实践和/或政策声明的集合，涵盖一系列标准主题，用于表达采用本框架中所述方法的证书政策定义或CP。
A certificate policy can be expressed as a single set of provisions.
证书策略可以表示为一组规定。
A CPS can be expressed as a single set of provisions with each component addressing the requirements of one or more certificate policies, or, alternatively, as an organized collection of sets of provisions. For example, a CPS could be expressed as a combination of the following:
CPS可以表示为一组单独的条款，其中每个组件满足一个或多个证书策略的要求，或者，也可以表示为一组有组织的条款集合。例如，CPS可以表示为以下各项的组合：
(a) a list of certificate policies supported by the CPS;
(a) CPS支持的证书策略列表；
(b) for each certificate policy in (a), a set of provisions which contains statements that refine that certificate policy by filling in details not stipulated in that policy or expressly left to the discretion of the CPS by that certificate policy; such statements serve to state how this particular CPS implements the requirements of the particular certificate
(b) 对于（a）中的每个证书政策，一套规定，其中包含通过填写该政策中未规定或该证书政策明确留给CPS自行决定的细节来完善该证书政策的声明；此类声明用于说明特定CPS如何实现特定证书的要求
policy;
政策
(c) a set of provisions that contains statements regarding the certification practices on the CA, regardless of certificate policy.
(c) 一组规定，其中包含有关CA上的认证实践的声明，与证书策略无关。
The statements provided in (b) and (c) may augment or refine the stipulations of the applicable certificate policy definition, but must not conflict with any of the stipulations of such certificate policy definition.
（b）和（c）中提供的声明可以补充或完善适用证书政策定义的规定，但不得与此类证书政策定义的任何规定相冲突。
This framework outlines the contents of a set of provisions, in terms of eight primary components, as follows:
该框架从以下八个主要部分概述了一套条款的内容：
* Introduction;
* 介绍
* General Provisions;
* 一般规定；
* Identification and Authentication;
* 识别和认证；
* Operational Requirements;
* 操作要求；
* Physical, Procedural, and Personnel Security Controls;
* 物理、程序和人员安全控制；
* Technical Security Controls;
* 技术安全控制；
* Certificate and CRL Profile; and
* 证书和CRL档案；和
* Specification Administration.
* 规范管理。
Components can be further divided into subcomponents, and a subcomponent may comprise multiple elements. Section 4 provides a more detailed description of the contents of the above components, and their subcomponents.
组件可以进一步划分为子组件，并且子组件可以包括多个元素。第4节更详细地描述了上述组件及其子组件的内容。
This section expands upon the contents of a set of provisions, as introduced in Section 3.7. The topics identified in this section are, consequently, candidate topics for inclusion in a certificate policy definition or CPS.
本节扩展了第3.7节中介绍的一套规定的内容。因此，本节中确定的主题是要包含在证书策略定义或CPS中的候选主题。
While many topics are identified, it is not necessary for a certificate policy or a CPS to include a concrete statement for every such topic. Rather, a particular certificate policy or CPS may state "no stipulation" for a component, subcomponent, or element on which the particular certificate policy or CPS imposes no requirements. In this sense, the list of topics can be considered a checklist of
虽然确定了许多主题，但证书策略或CPS没有必要为每个此类主题包含具体的声明。相反，特定证书政策或CPS可能会对特定证书政策或CPS没有要求的组件、子组件或元素声明“无规定”。从这个意义上讲，主题列表可以被视为
topics for consideration by the certificate policy or CPS writer. It is recommended that each and every component and subcomponent be included in a certificate policy or CPS, even if there is "no stipulation"; this will indicate to the reader that a conscious decision was made to include or exclude that topic. This protects against inadvertent omission of a topic, while facilitating comparison of different certificate policies or CPSs, e.g., when making policy mapping decisions.
供证书策略或CPS编写者考虑的主题。建议将每个组件和子组件包括在证书政策或CPS中，即使“没有规定”；这将向读者表明，有意识地决定包括或排除该主题。这可以防止无意中遗漏主题，同时便于比较不同的证书策略或CP，例如，在做出策略映射决策时。
In a certificate policy definition, it is possible to leave certain components, subcomponents, and/or elements unspecified, and to stipulate that the required information will be indicated in a policy qualifier. Such certificate policy definitions can be considered parameterized definitions. The set of provisions should reference or define the required policy qualifier types and should specify any applicable default values.
在证书策略定义中，可以保留未指定的某些组件、子组件和/或元素，并规定将在策略限定符中指示所需的信息。此类证书策略定义可以视为参数化定义。规定集应引用或定义所需的策略限定符类型，并应指定任何适用的默认值。
This component identifies and introduces the set of provisions, and indicates the types of entities and applications for which the specification is targeted.
本部分确定并介绍了一组规定，并指出了规范所针对的实体和应用程序的类型。
This component has the following subcomponents:
此组件具有以下子组件：
* Overview;
* 概述
* Identification;
* 识别
* Community and Applicability; and
* 社区和适用性；和
* Contact Details.
* 联系方式。
This subcomponent provides a general introduction to the specification.
本子组件提供了本规范的一般介绍。
This subcomponent provides any applicable names or other identifiers, including ASN.1 object identifiers, for the set of provisions.
本子组件为该套规定提供任何适用名称或其他标识符，包括ASN.1对象标识符。
This subcomponent describes the types of entities that issue certificates or that are certified as subject CAs (2, 3), the types of entities that perform RA functions (4), and the types of entities
本子组件描述了颁发证书或认证为主体CA的实体类型（2、3）、执行RA功能的实体类型（4）以及实体类型
that are certified as subject end entities or subscribers. (5, 6)
被认证为主体终端实体或订户的。(5, 6)
This subcomponent also contains:
此子组件还包含：
* A list of applications for which the issued certificates are suitable. (Examples of application in this case are: electronic mail, retail transactions, contracts, travel order, etc.)
* 适用于已颁发证书的申请清单。（这种情况下的应用示例包括：电子邮件、零售交易、合同、旅行订单等）
* A list of applications for which use of the issued certificates is restricted. (This list implicitly prohibits all other uses for the certificates.)
* 限制使用已颁发证书的申请列表。（此列表隐式禁止证书的所有其他用途。）
* A list of applications for which use of the issued certificates is prohibited.
* 禁止使用已颁发证书的申请清单。
This subcomponent includes the name and mailing address of the authority that is responsible for the registration, maintenance, and interpretation of this certificate policy or CPS. It also includes the name, electronic mail address, telephone number, and fax number of a contact person.
本子部分包括负责注册、维护和解释本证书政策或CPS的机构的名称和邮寄地址。它还包括联系人的姓名、电子邮件地址、电话号码和传真号码。
This component specifies any applicable presumptions on a range of legal and general practices topics.
本部分规定了关于一系列法律和一般惯例主题的任何适用假设。
This component contains the following subcomponents:
此组件包含以下子组件：
* Obligations;
* 义务；
* Liability;
* 责任
* Financial Responsibility;
* 财务责任；
* Interpretation and Enforcement;
* 解释和执行；
* Fees;
* 费用；
* Publication and Repositories;
* 出版物和储存库；
* Compliance Audit;
* 合规审计；
* Confidentiality; and
* 保密性；和
* Intellectual Property Rights.
* 知识产权。
Each subcomponent may need to separately state provisions applying to the entity types: CA, repository, RA, subscriber, and relying party. (Specific provisions regarding subscribers and relying parties are only applicable in the Liability and Obligations subcomponents.)
每个子组件可能需要单独说明适用于实体类型的规定：CA、存储库、RA、订户和依赖方。（关于认购人和依赖方的具体规定仅适用于责任和义务子部分。）
This subcomponent contains, for each entity type, any applicable provisions regarding the entity's obligations to other entities. Such provisions may include:
对于每种实体类型，本子部分包含有关该实体对其他实体的义务的任何适用规定。这些规定可包括：
* CA and/or RA obligations: * Notification of issuance of a certificate to the subscriber who is the subject of the certificate being issued; * Notification of issuance of a certificate to others than the subject of the certificate; * Notification of revocation or suspension of a certificate to the subscriber whose certificate is being revoked or suspended; and * Notification of revocation or suspension of a certificate to others than the subject whose certificate is being revoked or suspended.
* CA和/或RA义务：*向作为所签发证书主体的认购人发出证书签发通知；*向证书主体以外的其他人发出证书签发通知；*向其证书被撤销或暂停的认购人发出撤销或暂停证书的通知；以及*向证书被撤销或暂停的主体以外的其他人发出证书被撤销或暂停的通知。
* Subscriber obligations:
* 认购人义务：
* Accuracy of representations in certificate application; * Protection of the entity's private key; * Restrictions on private key and certificate use; and * Notification upon private key compromise.
* 证书申请中陈述的准确性；*保护实体的私钥；*对私钥和证书使用的限制；和*私钥泄露时的通知。
* Relying party obligations:
* 依赖方义务：
* Purposes for which certificate is used; * Digital signature verification responsibilities; * Revocation and suspension checking responsibilities; and * Acknowledgment of applicable liability caps and warranties.
* 证书的使用目的；*数字签名验证责任；*撤销和暂停检查责任；和*确认适用的责任上限和保证。
* Repository obligations
* 存储库义务
* Timely publication of certificates and revocation information
* 及时发布证书和吊销信息
This subcomponent contains, for each entity type, any applicable provisions regarding apportionment of liability, such as:
对于每种实体类型，本子部分包含关于责任分配的任何适用规定，例如：
* Warranties and limitations on warranties;
* 保证和保证限制；
* Kinds of damages covered (e.g., indirect, special, consequential, incidental, punitive, liquidated damages, negligence and fraud) and disclaimers;
* 赔偿金种类（例如，间接、特殊、后果性、附带、惩罚性、违约赔偿金、疏忽和欺诈）和免责声明；
* Loss limitations (caps) per certificate or per transaction; and
* 每份证书或每笔交易的损失限额（上限）；和
* Other exclusions (e.g., Acts of God, other party responsibilities).
* 其他除外责任（如天灾、其他方责任）。
This subcomponent contains, for CAs, repository, and RAs, any applicable provisions regarding financial responsibilities, such as:
对于CAs、存储库和RAs，本子组件包含有关财务责任的任何适用规定，例如：
* Indemnification of CA and/or RA by relying parties;
* 依赖方对CA和/或RA的赔偿；
* Fiduciary relationships (or lack thereof) between the various entities; and
* 各实体之间的信托关系（或缺乏信托关系）；和
* Administrative processes (e.g., accounting, audit).
* 管理流程（例如，会计、审计）。
This subcomponent contains any applicable provisions regarding interpretation and enforcement of the certificate policy or CPS, addressing such topics as:
本子部分包含有关证书政策或CPS的解释和实施的任何适用规定，涉及以下主题：
* Governing law;
* 适用法律；
* Severability of provisions, survival, merger, and notice; and
* 条款、存续、合并和通知的可分割性；和
* Dispute resolution procedures.
* 争端解决程序。
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 fee;
* 证书使用费；
* Revocation or status information access fee;
* 撤销或状态信息访问费；
* Fees for other services such as policy information; and
* 政策信息等其他服务的费用；和
* Refund policy.
* 退款政策。
This subcomponent contains any applicable provisions regarding:
本子部分包含关于以下方面的任何适用规定：
* A CA's obligations to publish information regarding its practices, its certificates, and the current status of such certificates;
* CA有义务发布有关其实践、证书以及此类证书当前状态的信息；
* Frequency of publication;
* 出版频率；
* Access control on published information objects including certificate policy definitions, CPS, certificates, certificate status, and CRLs; and
* 对已发布信息对象的访问控制，包括证书策略定义、CP、证书、证书状态和CRL；和
* Requirements pertaining to the use of repositories operated by CAs or by other independent parties.
* 与使用由CAs或其他独立方运营的存储库有关的要求。
This subcomponent addresses the following:
此子组件涉及以下内容：
* Frequency of compliance audit for each entity;
* 每个实体的合规审计频率；
* Identity/qualifictions of the auditor;
* 审计师的身份/资质；
* Auditor's relationship to the entity being audited; (30)
* 审计师与被审计实体的关系；(30)
* List of topics covered under the compliance audit; (31)
* 合规审计涵盖的主题清单；(31)
* Actions taken as a result of a deficiency found during compliance audit; (32)
* 因合规性审计期间发现的缺陷而采取的措施；(32)
* Compliance audit results: who they are shared with (e.g., subject CA, RA, and/or end entities), who provides them (e.g., entity being audited or auditor), how they are communicated.
* 合规性审计结果：与谁共享（如主体CA、RA和/或最终实体），谁提供（如被审计实体或审计员），如何沟通。
This subcomponent addresses the following:
此子组件涉及以下内容：
* Types of information that must be kept confidential by CA or RA;
* CA或RA必须保密的信息类型；
* Types of information that are not considered confidential;
* 不被视为机密的信息类型；
* Who is entitled to be informed of reasons for revocation and suspension of certificates;
* 有权被告知撤销和暂停证书的原因的人员；
* Policy on release of information to law enforcement officials;
* 向执法官员发布信息的政策；
* Information that can be revealed as part of civil discovery;
* 作为民事证据开示的一部分可以披露的信息；
* Conditions upon which CA or RA may disclose upon owner's request; and
* CA或RA可根据业主要求披露的条件；和
* Any other circumstances under which confidential information may be disclosed.
* 可能披露机密信息的任何其他情况。
This subcomponent addresses ownership rights of certificates, practice/policy specifications, names, and keys.
此子组件涉及证书的所有权、实践/策略规范、名称和密钥。
This component describes the procedures used to authenticate a certificate applicant to a CA or RA prior to certificate issuance. It also describes how parties requesting rekey or revocation are authenticated. This component also addresses naming practices, including name ownership recognition and name dispute resolution.
此组件描述在颁发证书之前，用于向CA或RA验证证书申请人的过程。它还描述了请求重新密钥或撤销的各方如何进行身份验证。该组件还涉及命名实践，包括名称所有权识别和名称争议解决。
This component has the following subcomponents:
此组件具有以下子组件：
* Initial Registration;
* 初次登记；
* Routine Rekey;
* 常规密钥更新；
* Rekey After Revocation; and
* 撤销后重新密钥；和
* Revocation Request.
* 撤销请求。
This subcomponent includes the following elements regarding identification and authentication procedures during entity registration or certificate issuance:
本子部分包括以下有关实体注册或证书颁发期间识别和认证程序的要素：
* Types of names assigned to the subject (7);
* 指定给受试者的姓名类型（7）；
* Whether names have to be meaningful or not (8);
* 名称是否必须有意义（8）；
* Rules for interpreting various name forms;
* 解释各种姓名形式的规则；
* Whether names have to be unique;
* 名称是否必须是唯一的；
* How name claim disputes are resolved;
* 名称索赔纠纷如何解决；
* Recognition, authentication, and role of trademarks;
* 商标的识别、认证和作用；
* If and how the subject must prove possession of the companion private key for the public key being registered (9);
* 如果以及如何证明主体拥有注册公钥的伴随私钥（9）；
* Authentication requirements for organizational identity of subject (CA, RA, or end entity) (10);
* 主体（CA、RA或最终实体）的组织身份认证要求（10）；
* Authentication requirements for a person acting on behalf of a subject (CA, RA, or end entity) (11), including:
* 代表主体（CA、RA或最终实体）行事的人员的认证要求（11），包括：
* Number of pieces of identification required; * How a CA or RA validates the pieces of identification provided; * If the individual must present personally to the authenticating CA or RA; * How an individual as an organizational person is authenticated (12).
* 所需标识的件数；*CA或RA如何验证所提供的标识；*如果个人必须亲自向认证CA或RA出示；*个人作为组织人员的身份认证方式（12）。
This subcomponent describes the identification and authentication procedures for routine rekey for each subject type (CA, RA, and end entity). (13)
本子部分描述了每种受试者类型（CA、RA和最终实体）例行密钥更新的识别和认证程序。(13)
This subcomponent describes the identification and authentication procedures for rekey for each subject type (CA, RA, and end entity) after the subject certificate has been revoked. (14)
本子组件描述了在主体证书被吊销后，每个主体类型（CA、RA和最终实体）的重新密钥识别和认证过程。(14)
This subcomponent describes the identification and authentication procedures for a revocation request by each subject type (CA, RA, and end entity). (16)
本子组件描述了每种主体类型（CA、RA和最终实体）撤销请求的识别和认证过程。(16)
This component is used to specify requirements imposed upon issuing CA, subject CAs, RAs, or end entities with respect to various operational activities.
此组件用于指定对签发CA、主体CA、RAs或终端实体施加的与各种运营活动有关的要求。
This component consists of the following subcomponents:
该组件由以下子组件组成：
* Certificate Application;
* 证书申请；
* Certificate Issuance;
* 证书颁发；
* Certificate Acceptance;
* 验收证书；
* Certificate Suspension and Revocation;
* 证书的暂停和撤销；
* Security Audit Procedures;
* 安全审计程序；
* Records Archival;
* 档案；
* Key Changeover;
* 钥匙转换；
* Compromise and Disaster Recovery; and
* 妥协和灾后恢复；和
* CA Termination.
* CA终止。
Within each subcomponent, separate consideration may need to be given to issuing CA, repository, subject CAs, RAs, and end entities.
在每个子组件中，可能需要单独考虑颁发CA、存储库、主体CA、RAs和最终实体。
This subcomponent is used to state requirements regarding subject enrollment and request for certificate issuance.
此子组件用于说明有关科目注册和证书颁发申请的要求。
This subcomponent is used to state requirements regarding issuance of a certificate and notification to the applicant of such issuance.
本子部分用于说明有关证书颁发和向申请人发出此类颁发通知的要求。
This subcomponent is used to state requirements regarding acceptance of an issued certificate and for consequent publication of certificates.
本子部分用于说明有关接受已颁发证书以及随后发布证书的要求。
This subcomponent addresses the following:
此子组件涉及以下内容：
* Circumstances under which a certificate may be revoked;
* 可撤销证书的情况；
* Who can request the revocation of the entity certificate;
* 谁可以要求撤销实体证书；
* Procedures used for certificate revocation request;
* 申请证书撤销的程序；
* Revocation request grace period available to the subject;
* 主体可用的撤销请求宽限期；
* Circumstances under which a certificate may be suspended;
* 在何种情况下证书可能被暂停；
* Who can request the suspension of a certificate;
* 谁可以要求暂停证书；
* Procedures to request certificate suspension;
* 申请暂停证书的程序；
* How long the suspension may last;
* 暂停可能持续多久；
* If a CRL mechanism is used, the issuance frequency;
* 如果使用CRL机制，发行频率；
* Requirements on relying parties to check CRLs;
* 对依赖方检查CRL的要求；
* On-line revocation/status checking availability;
* 在线撤销/状态检查可用性；
* Requirements on relying parties to perform on-line revocation/status checks;
* 对依赖方进行在线撤销/状态检查的要求；
* Other forms of revocation advertisements available; and
* 其他形式的撤销广告；和
* Requirements on relying parties to check other forms of revocation advertisements.
* 要求依赖方检查其他形式的撤销广告。
* Any variations on the above stipulations when the suspension or revocation is the result of private key compromise (as opposed to other reasons for suspension or revocation).
* 当暂停或撤销是私钥泄露的结果（与暂停或撤销的其他原因相反）时，对上述规定的任何变更。
This subcomponent is used to describe event logging and audit systems, implemented for the purpose of maintaining a secure environment. Elements include the following:
此子组件用于描述事件日志记录和审核系统，这些系统是为了维护安全环境而实现的。内容包括：
* Types of events recorded; (28)
* 记录的事件类型；(28)
* Frequency with which audit logs are processed or audited;
* 处理或审核审核日志的频率；
* Period for which audit logs are kept;
* 保存审核日志的期限；
* Protection of audit logs:
* 审计日志的保护：
- Who can view audit logs; - Protection against modification of audit log; and - Protection against deletion of audit log.
- 谁可以查看审核日志；-防止修改审核日志；和-防止删除审核日志。
* Audit log back up procedures;
* 审核日志备份程序；
* Whether the audit log accumulation system is internal or external to the entity;
* 审计日志累积系统是实体内部的还是外部的；
* Whether the subject who caused an audit event to occur is notified of the audit action; and
* 是否将审计行动通知导致审计事件发生的主体；和
* Vulnerability assessments.
* 脆弱性评估。
This subcomponent is used to describe general records archival (or records retention) policies, including the following:
此子组件用于描述一般记录存档（或记录保留）策略，包括以下内容：
* Types of events recorded; (29)
* 记录的事件类型；(29)
* Retention period for archive;
* 档案保存期限；
* Protection of archive:
* 保护档案：
- Who can view the archive; - Protection against modification of archive; and - Protection against deletion of archive.
- 谁可以查看存档文件；-防止档案被修改；和-防止删除存档。
* Archive backup procedures;
* 档案备份程序；
* Requirements for time-stamping of records;
* 记录加盖时间戳的要求；
* Whether the archive collection system is internal or external;
* 档案收集系统是内部的还是外部的；
and
和
* Procedures to obtain and verify archive information.
* 获取和验证归档信息的程序。
This subcomponent describes the procedures to provide a new public key to a CA's users.
此子组件描述了向CA的用户提供新公钥的过程。
This subcomponent describes requirements relating to notification and recovery procedures in the event of compromise or disaster. Each of the following circumstances may need to be addressed separately:
本子部分描述了发生危害或灾难时与通知和恢复程序相关的要求。可能需要单独解决以下每种情况：
* The recovery procedures used if computing resources, software, and/or data are corrupted or suspected to be corrupted. These procedures describe how a secure environment is reestablished,
* 在计算资源、软件和/或数据损坏或怀疑损坏时使用的恢复过程。这些程序描述了如何重建安全环境，
which certificates are revoked, whether the entity key is revoked, how the new entity public key is provided to the users, and how the subjects are recertified.
吊销了哪些证书、是否吊销了实体密钥、如何向用户提供新的实体公钥以及如何重新认证主体。
* The recovery procedures used if the entity public key is revoked. These procedures describe how a secure environment is reestablished, how the new entity public key is provided to the users, and how the subjects are recertified.
* 实体公钥被吊销时使用的恢复过程。这些过程描述了如何重建安全环境，如何向用户提供新的实体公钥，以及如何重新认证主题。
* The recovery procedures used if the entity key is compromised. These procedures describe how a secure environment is reestablished, how the new entity public key is provided to the users, and how the subjects are recertified.
* 实体密钥泄露时使用的恢复过程。这些过程描述了如何重建安全环境，如何向用户提供新的实体公钥，以及如何重新认证主题。
* The CA's procedures for securing its facility during the period of time following a natural or other disaster and before a secure environment is reestablished either at the original site or a remote hot-site. For example, procedures to protect against theft of sensitive materials from an earthquake-damaged site.
* CA在自然灾害或其他灾害之后以及在原始现场或远程热现场重建安全环境之前保护其设施的程序。例如，防止地震破坏现场敏感材料被盗的程序。
This subcomponent describes requirements relating to procedures for termination and for 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 describes non-technical security controls (that is, physical, procedural, and personnel controls) used by the issuing CA to perform securely the functions of key generation, subject authentication, certificate issuance, certificate revocation, audit, and archival.
此组件描述了非技术性安全控制（即物理、程序和人员控制），由颁发CA使用，以安全地执行密钥生成、主体身份验证、证书颁发、证书撤销、审核和存档等功能。
This component can also be used to define non-technical security controls on repository, subject CAs, RAs, and end entities. The non technical security controls for the subject CAs, RAs, and end entities could be the same, similar, or 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 the compromise of the CA private key.
这些非技术性安全控制对于信任证书至关重要，因为缺乏安全性可能会危及CA操作，从而导致（例如）使用错误信息创建证书或CRL或CA私钥受损。
This component consists of three subcomponents:
该组件由三个子组件组成：
* Physical Security Controls;
* 实物安全控制；
* Procedural Controls; and
* 程序控制；和
* Personnel Security Controls.
* 人员安全控制。
Within each subcomponent, separate consideration will, in general, need to be given to each entity type, that is, issuing CA, repository, subject CAs, RAs, and end entities.
在每个子组件中，通常需要单独考虑每个实体类型，即颁发CA、存储库、主题CA、RAs和最终实体。
In this subcomponent, the physical controls on the facility housing the entity systems are described.(21) Topics addressed may include:
在本子部分中，描述了实体系统所在设施的物理控制。（21）涉及的主题可能包括：
* Site location and construction;
* 现场位置和施工；
* Physical access;
* 物理访问；
* Power and air conditioning;
* 电力和空调；
* Water exposures;
* 水暴露；
* Fire prevention and protection;
* 防火和保护；
* Media storage;
* 媒体存储；
* Waste disposal; and
* 废物处理；和
* Off-site backup.
* 异地备份。
In this subcomponent, requirements for recognizing trusted roles are described, together with the responsibilities for each role.(22)
在此子组件中，描述了识别受信任角色的要求，以及每个角色的职责。（22）
For each task identified for each role, it should also be stated how many individuals are required to perform the task (n out m rule). Identification and authentication requirements for each role may also be defined.
对于为每个角色确定的每个任务，还应说明执行该任务需要多少个人（n out m规则）。还可以定义每个角色的标识和身份验证要求。
This subcomponent addresses the following:
此子组件涉及以下内容：
* Background checks and clearance procedures required for the personnel filling the trusted roles; (23)
* 担任受信任角色的人员所需的背景调查和许可程序；(23)
* Background checks and clearance procedures requirements for other personnel, including janitorial staff; (24)
* 其他人员（包括看门人）的背景调查和许可程序要求；(24)
* Training requirements and training procedures for each role;
* 每个角色的培训要求和培训程序；
* Any retraining period and retraining procedures for each role;
* 每个角色的任何再培训期和再培训程序；
* Frequency and sequence for job rotation among various roles;
* 不同角色之间工作轮换的频率和顺序；
* Sanctions against personnel for unauthorized actions, unauthorized use of authority, and unauthorized use of entity systems; (25)
* 对未经授权行为、未经授权使用权限和未经授权使用实体系统的人员的制裁；(25)
* Controls on contracting personnel, including:
* 对订约人员的控制，包括：
- Bonding requirements on contract personnel; - Contractual requirements including indemnification for damages due to the actions of the contractor personnel; - Audit and monitoring of contractor personnel; and - Other controls on contracting personnel.
- 对合同人员的担保要求；-合同要求，包括因承包商人员的行为造成的损害赔偿；-承包商人员的审计和监督；和-对合同人员的其他控制。
* Documentation to be supplied to personnel.
* 提供给相关人员的文件。
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
此组件用于定义颁发CA为保护其加密密钥和激活数据（例如PIN、密码或手动持有的密钥共享）而采取的安全措施。此组件还可用于对存储库、主题CA施加约束
and end entities to protect their cryptographic keys and critical security parameters. Secure key management is critical to ensure that all secret and private keys and activation data are protected and used only by authorized personnel.
和终端实体，以保护其加密密钥和关键安全参数。安全密钥管理对于确保所有密钥和私钥以及激活数据都受到保护，并且仅由授权人员使用至关重要。
This component also describes other technical security controls used by the issuing CA to perform securely the functions of key generation, user authentication, certificate registration, certificate revocation, audit, and archival. Technical controls include life-cycle security controls (including software development environment security, trusted software development methodology) and operational security controls.
此组件还描述了颁发CA用于安全执行密钥生成、用户身份验证、证书注册、证书吊销、审核和存档功能的其他技术安全控制。技术控制包括生命周期安全控制（包括软件开发环境安全、可信软件开发方法）和操作安全控制。
This component can also be used to define other technical security controls on repositories, subject CAs, RAs, and end entities.
此组件还可用于定义存储库、主题CA、RAs和终端实体上的其他技术安全控制。
This component has the following subcomponents:
此组件具有以下子组件：
* Key Pair Generation and Installation;
* 密钥对生成和安装；
* Private Key Protection;
* 私钥保护；
* Other Aspects of Key Pair Management;
* 密钥对管理的其他方面；
* Activation Data;
* 激活数据；
* Computer Security Controls;
* 计算机安全控制；
* Life-Cycle Security Controls;
* 生命周期安全控制；
* Network Security Controls; and
* 网络安全控制；和
* Cryptographic Module Engineering Controls.
* 密码模块工程控制。
Key pair generation and installation need to be considered for the issuing CA, repositories, subject CAs, RAs, and subject end entities. 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?
1. 谁生成实体公钥、私钥对？
2. How is the private key provided securely to the entity?
2. 如何将私钥安全地提供给实体？
3. How is the entity's public key provided securely to the certificate issuer?
3. 实体的公钥如何安全地提供给证书颁发者？
4. If the entity is a CA (issuing or subject) how is the entity's public key provided securely to the users?
4. 如果该实体是CA（颁发或主体），该实体的公钥如何安全地提供给用户？
5. What are the key sizes?
5. 关键尺寸是多少？
6. Who generates the public key parameters?
6. 谁生成公钥参数？
7. Is the quality of the parameters checked during key generation?
7. 在密钥生成过程中是否检查了参数的质量？
8. Is the key generation performed in hardware or software?
8. 密钥生成是在硬件还是软件中执行的？
9. For what purposes may the key be used, or for what purposes should usage of the key be restricted (for X.509 certificates, these purposes should map to the key usage flags in the Version 3, X.509 certificates)?
9. 密钥可用于什么目的，或者密钥的使用应限制用于什么目的（对于X.509证书，这些目的应映射到版本3、X.509证书中的密钥使用标志）？
Requirements for private key protection need to be considered for the issuing CA, repositories, subject CAs, RAs, and subject end entities. For each of these types of entity, the following questions potentially need to be answered:
需要考虑颁发CA、存储库、主体CA、RAs和主体终端实体的私钥保护要求。对于每种类型的实体，可能需要回答以下问题：
1. What standards, if any, are required for the module used to generate the keys? For example, are the keys certified by the infrastructure required to be generated using modules complaint with the US FIPS 140-1? If so, what is the required FIPS 140-1 level of the module?
1. 用于生成密钥的模块需要什么标准（如果有）？例如，是否需要使用美国FIPS 140-1的模块生成基础设施认证的密钥？如果是，模块所需的FIPS 140-1级别是什么？
2. Is the private key under n out of m multi-person control?(18) If yes, provide n and m (two person control is a special case of n out of m, where n = m = 2)?
2. 私钥是否在n out of m多人控制下？（18）如果是，请提供n和m（两人控制是n out of m的特例，其中n=m=2）？
3. Is the private key escrowed? (19) If so, who is the escrow agent, what form is the key escrowed in (examples include plaintext, encrypted, split key), and what are the security controls on the escrow system?
3. 私钥是否托管？（19） 如果是，谁是托管代理，托管密钥采用何种形式（示例包括明文、加密、拆分密钥），托管系统的安全控制是什么？
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. Who enters the private key in the cryptographic module? In what form (i.e., plaintext, encrypted, or split key)? How is the private key stored in the module (i.e., plaintext, encrypted, or split key)?
6. 谁在加密模块中输入私钥？以何种形式（即明文、加密或分割密钥）？私钥如何存储在模块中（即，明文、加密或拆分密钥）？
7. Who can activate (use) the private key? What actions must be performed to activate the private key (e.g., login, power on, supply PIN, insert token/key, automatic, etc.)? Once the key is activated, is the key active for an indefinite period, active for one time, or active for a defined time period?
7. 谁可以激活（使用）私钥？激活私钥必须执行哪些操作（例如登录、通电、电源PIN、插入令牌/密钥、自动等）？一旦钥匙被激活，钥匙是无限期激活、一次激活还是在规定的时间段内激活？
8. Who can deactivate the private key and how? Example of how might include, logout, power off, remove token/key, automatic, or time expiration.
8. 谁可以停用私钥？如何停用？示例说明如何包括注销、关机、删除令牌/密钥、自动或时间过期。
9. Who can destroy the private key and how? Examples of how might include token surrender, token destruction, or key overwrite.
9. 谁可以销毁私钥？如何销毁？示例可能包括令牌放弃、令牌销毁或密钥覆盖。
Other aspects of key management need to be considered for the issuing CA, repositories, subject CAs, RAs, and subject end entities. For each of these types of entity, 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? The archival system should provide integrity controls other than digital signatures since: the archival period may be greater than the cryptanalysis period for the key and the archive requires tamper protection, which is not provided by digital signatures.
1. 公钥是否已存档？如果是，谁是档案代理人，档案系统的安全控制是什么？存档系统应提供除数字签名以外的完整性控制，因为：存档周期可能大于密钥的密码分析周期，存档需要篡改保护，而这不是由数字签名提供的。
2. What are the usage periods, or active lifetimes, for the public and the private key respectively?
2. 公钥和私钥的使用周期或有效寿命分别是多少？
Activation data refers to data values other than keys that are required to operate cryptographic modules and that need to be protected. (20) Protection of activation data potentially needs to be considered for the issuing CA, subject CAs, RAs, and end entities. 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, and end entity) 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.
激活数据是指除密钥以外的数据值，这些密钥是操作密码模块所必需的，并且需要保护。（20） 对于发布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 reuse, 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. This subcomponent can also address requirements for product evaluation analysis, testing, profiling, product certification, and/or product accreditation related activity undertaken.
可能需要计算机系统的计算机安全等级。例如，评级可以基于可信系统评估标准（TCSEC）、加拿大可信产品评估标准、欧洲信息技术安全评估标准（ITSEC）或通用标准。该子组件还可以满足产品评估分析、测试、分析、产品认证和/或产品认证相关活动的要求。
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 the following aspects of a cryptographic module: identification of the cryptographic module boundary, input/output, roles and services, finite state machine, physical security, software security, operating system security, algorithm compliance, electromagnetic compatibility, and self tests. Requirements may be expressed through reference to a standard such as U.S. FIPS 140-1. (27)
此子组件涉及加密模块的以下方面：加密模块边界标识、输入/输出、角色和服务、有限状态机、物理安全、软件安全、操作系统安全、算法遵从性、电磁兼容性和自检。可通过参考美国FIPS 140-1等标准来表达要求。(27)
This component is used to specify the certificate format and, if CRLs are used, the CRL format. Assuming use of the X.509 certificate and CRL formats, this includes information on profiles, versions, and extensions used.
此组件用于指定证书格式，如果使用CRL，则指定CRL格式。假设使用X.509证书和CRL格式，这包括有关使用的配置文件、版本和扩展的信息。
This component has two subcomponents:
此组件有两个子组件：
* Certificate Profile; and
* 证书简介；和
* CRL Profile.
* CRL配置文件。
This subcomponent addresses such topics as the following (potentially by reference to a separate profile definition, such as the PKIX Part I profile):
此子组件涉及以下主题（可能通过参考单独的配置文件定义，如PKIX第一部分配置文件）：
* Version number(s) supported;
* 支持的版本号；
* Certificate extensions populated and their criticality;
* 证书扩展及其重要性；
* Cryptographic algorithm object identifiers;
* 加密算法；对象标识符；
* Name forms used for the CA, RA, and end entity names;
* 用于CA、RA和最终实体名称的名称表格；
* Name constraints used and the name forms used in the name constraints;
* 使用的名称约束和名称约束中使用的名称形式；
* Applicable certificate policy Object Identifier(s);
* 适用的证书策略对象标识符；
* Usage of the policy constraints extension;
* 政策约束扩展的使用；
* Policy qualifiers syntax and semantics; and
* 策略限定符语法和语义；和
* Processing semantics for the critical certificate policy extension.
* 关键证书策略扩展的处理语义。
This subcomponent addresses such topics as the following (potentially by reference to a separate profile definition, such as the PKIX Part I profile):
此子组件涉及以下主题（可能通过参考单独的配置文件定义，如PKIX第一部分配置文件）：
* Version numbers supported for CRLs; and
* CRL支持的版本号；和
* CRL and CRL entry extensions populated and their criticality.
* 已填充CRL和CRL入口扩展及其关键性。
This component is used to specify how this particular certificate policy definition or CPS will be maintained.
此组件用于指定如何维护此特定证书策略定义或CP。
It contains the following subcomponents:
它包含以下子组件：
* Specification Change Procedures;
* 规范变更程序；
* Publication and Notification Procedures; and
* 公布和通知程序；和
* CPS Approval Procedures.
* CPS批准程序。
It will occasionally be necessary to change certificate policies and Certification Practice Statements. Some of these changes will not materially reduce the assurance that a certificate policy or its implementation provides, and will be judged by the policy administrator as not changing the acceptability of certificates asserting the policy for the purposes for which they have been used. Such changes to certificate policies and Certification Practice Statements need not require a change in the certificate policy Object Identifier or the CPS pointer (URL). Other changes to a specification will change the acceptability of certificates for specific purposes, and these changes will require changes to the certificate policy Object Identifier or CPS pointer (URL).
有时需要更改证书政策和认证实践声明。其中一些更改不会实质上减少证书策略或其实现提供的保证，并且策略管理员会判断这些更改不会改变声明该策略的证书的可接受性，以实现其使用目的。对证书策略和证书实践语句的此类更改不需要更改证书策略对象标识符或CPS指针（URL）。规范的其他更改将更改特定用途证书的可接受性，这些更改将要求更改证书策略对象标识符或CPS指针（URL）。
This subcomponent contains the following information:
此子组件包含以下信息：
* A list of specification components, subcomponents, and/or elements thereof that can be changed without notification and without changes to the certificate policy Object Identifier or CPS pointer (URL).
* 规范组件、子组件和/或其元素的列表，这些组件、子组件和/或元素可以在不发出通知的情况下进行更改，也不需要更改证书策略对象标识符或CPS指针（URL）。
* A list of specification components, subcomponents, and/or elements thereof that may change following a notification period without changing the certificate policy Object Identifier or CPS
* 规范组件、子组件和/或其元素的列表，这些组件、子组件和/或元素在通知期后可能会更改，而不会更改证书策略对象标识符或CP
pointer (URL). The procedures to be used to notify interested parties (relying parties, certification authorities, etc.) of the certificate policy or CPS changes are described. The description of notification procedures includes the notification mechanism, notification period for comments, mechanism to receive, review and incorporate the comments, mechanism for final changes to the policy, and the period before final changes become effective.
指针（URL）。描述了用于通知相关方（依赖方、认证机构等）证书政策或CPS变更的程序。通知程序的说明包括通知机制、意见通知期限、接收、审查和纳入意见的机制、政策最终变更的机制以及最终变更生效前的期限。
* A list of specification components, subcomponents, and/or elements, changes to which require a change in certificate policy Object Identifier or CPS pointer (URL)..
* 规范组件、子组件和/或元素的列表，对其进行更改需要更改证书策略对象标识符或CPS指针（URL）。。
This subcomponent contains the following elements:
此子组件包含以下元素：
* A list of components, subcomponents, and elements thereof that exist but that are not made publicly available; (33)
* 存在但未公开的组件、子组件及其元件列表；(33)
* Descriptions of mechanisms used to distribute the certificate policy definition or CPS, including access controls on such distribution.
* 描述用于分发证书策略定义或CP的机制，包括对此类分发的访问控制。
In a certificate policy definition, this subcomponent describes how the compliance of a specific CPS with the certificate policy can be determined.
在证书策略定义中，此子组件描述如何确定特定CP与证书策略的符合性。
This section contains a possible outline for a set of provisions, intended to serve as a checklist or (with some further development) a standard template for use by certificate policy or CPS writers. Such a common outline will facilitate:
本节包含一组规定的可能概要，旨在作为检查表或（经过进一步发展）标准模板，供证书政策或CPS编写者使用。这种共同大纲将有助于：
(a) Comparison of two certificate policies during cross-certification (for the purpose of equivalency mapping).
(a) 交叉认证期间两种证书策略的比较（用于等效映射）。
(b) Comparison of a CPS with a certificate policy definition to ensure that the CPS faithfully implements the policy.
(b) 将CPS与证书策略定义进行比较，以确保CPS忠实地实施策略。
(c) Comparison of two CPSs.
(c) 两种CP的比较。
1. INTRODUCTION
1. 介绍
1.1 Overview
1.1 概述
1.2 Identification
1.2 识别
1.3 Community and Applicability 1.3.1 Certification authorities 1.3.2 Registration authorities 1.3.3 End entities 1.3.4 Applicability
1.3 社区和适用性1.3.1认证机构1.3.2注册机构1.3.3最终实体1.3.4适用性
1.4 Contact Details 1.4.1 Specification administration organization 1.4.2 Contact person 1.4.3 Person determining CPS suitability for the policy
1.4 联系方式1.4.1规范管理组织1.4.2联系人1.4.3确定CPS是否适用于本政策的人员
2. GENERAL PROVISIONS
2. 一般规定
2.1 Obligations
2.1 义务
2.1.1 CA obligations 2.1.2 RA obligations 2.1.3 Subscriber obligations 2.1.4 Relying party obligations 2.1.5 Repository obligations
2.1.1 CA义务2.1.2 RA义务2.1.3订户义务2.1.4依赖方义务2.1.5存储库义务
2.2 Liability
2.2 责任
2.2.1 CA liability 2.2.2 RA liability
2.2.1 CA责任2.2.2 RA责任
2.3 Financial responsibility
2.3 财务责任
2.3.1 Indemnification by relying parties 2.3.2 Fiduciary relationships 2.3.3 Administrative processes
2.3.1 依赖方的赔偿2.3.2信托关系2.3.3行政程序
2.4 Interpretation and Enforcement
2.4 解释和执行
2.4.1 Governing law 2.4.2 Severability, survival, merger, notice 2.4.3 Dispute resolution procedures
2.4.1 适用法律2.4.2可分割性、存续、合并、通知2.4.3争议解决程序
2.5 Fees
2.5 费用
2.5.1 Certificate issuance or renewal fees 2.5.2 Certificate access fees
2.5.1 证书颁发或更新费用2.5.2证书访问费
2.5.3 Revocation or status information access fees 2.5.4 Fees for other services such as policy information 2.5.5 Refund policy
2.5.3 撤销或状态信息访问费2.5.4政策信息等其他服务的费用2.5.5退款政策
2.6 Publication and Repository
2.6 出版物和储存库
2.6.1 Publication of CA information 2.6.2 Frequency of publication 2.6.3 Access controls 2.6.4 Repositories
2.6.1 CA信息发布2.6.2发布频率2.6.3访问控制2.6.4存储库
2.7 Compliance audit
2.7 合规审计
2.7.1 Frequency of entity compliance audit 2.7.2 Identity/qualifications of auditor 2.7.3 Auditor's relationship to audited party 2.7.4 Topics covered by audit 2.7.5 Actions taken as a result of deficiency 2.7.6 Communication of results
2.7.1 实体合规审计频率2.7.2审计师的身份/资格2.7.3审计师与被审计方的关系2.7.4审计所涵盖的主题2.7.5因缺陷而采取的行动2.7.6结果沟通
2.8 Confidentiality
2.8 保密性
2.8.1 Types of information to be kept confidential 2.8.2 Types of information not considered confidential 2.8.3 Disclosure of certificate revocation/suspension information 2.8.4 Release to law enforcement officials 2.8.5 Release as part of civil discovery 2.8.6 Disclosure upon owner's request 2.8.7 Other information release circumstances
2.8.1 保密信息类型2.8.2非保密信息类型2.8.3证书撤销/暂停信息披露2.8.4向执法人员发布2.8.5作为民事发现的一部分发布2.8.6应业主要求披露2.8.7其他信息发布情况
2.9 Intellectual Property Rights
2.9 知识产权
3. IDENTIFICATION AND AUTHENTICATION (34)
3. 识别和认证（34）
3.1 Initial Registration 3.1.1 Types of names 3.1.2 Need for names to be meaningful 3.1.3 Rules for interpreting various name forms 3.1.4 Uniqueness of names 3.1.5 Name claim dispute resolution procedure 3.1.6 Recognition, authentication and role of trademarks 3.1.7 Method to prove possession of private key 3.1.8 Authentication of organization identity 3.1.9 Authentication of individual identity
3.1 初始注册3.1.1姓名类型3.1.2姓名必须有意义3.1.3各种姓名表的解释规则3.1.4姓名的唯一性3.1.5姓名索赔争议解决程序3.1.6识别，商标的认证和作用3.1.7证明拥有私钥的方法3.1.8组织身份认证3.1.9个人身份认证
3.2 Routine Rekey
3.2 例行重发
3.3 Rekey after Revocation
3.3 撤销后重新注册
3.4 Revocation Request
3.4 撤销请求
4. OPERATIONAL REQUIREMENTS (34)
4. 业务要求（34）
4.1 Certificate Application
4.1 证书申请
4.2 Certificate Issuance
4.2 证书发行
4.3 Certificate Acceptance
4.3 验收证书
4.4 Certificate Suspension and Revocation 4.4.1 Circumstances for revocation 4.4.2 Who can request revocation 4.4.3 Procedure for revocation request 4.4.4 Revocation request grace period 4.4.5 Circumstances for suspension 4.4.6 Who can request suspension 4.4.7 Procedure for suspension request 4.4.8 Limits on suspension period 4.4.9 CRL issuance frequency (if applicable) 4.4.10 CRL checking requirements 4.4.11 On-line revocation/status checking availability 4.4.12 On-line revocation checking requirements 4.4.13 Other forms of revocation advertisements available 4.4.14 Checking requirements for other forms of revocation advertisements 4.4.15 Special requirements re key compromise
4.4 证书暂停和撤销4.4.1撤销的情况4.4.2谁可以请求撤销4.4.3撤销请求程序4.4.4撤销请求宽限期4.4.5暂停的情况4.4.6谁可以请求暂停4.4.7暂停请求程序4.4.8暂停期限值4.4.9 CRL发放频率（如适用）4.4.10 CRL检查要求4.4.11在线撤销/状态检查可用性4.4.12在线撤销检查要求4.4.13其他形式的撤销广告可用性4.4.14其他形式撤销广告的检查要求4.4.15特殊要求
4.5 Security Audit Procedures 4.5.1 Types of event recorded 4.5.2 Frequency of processing log 4.5.3 Retention period for audit log 4.5.4 Protection of audit log 4.5.5 Audit log backup procedures 4.5.6 Audit collection system (internal vs external) 4.5.7 Notification to event-causing subject 4.5.8 Vulnerability assessments
4.5 安全审计程序4.5.1记录的事件类型4.5.2处理日志的频率4.5.3审计日志的保留期4.5.4审计日志的保护4.5.5审计日志备份程序4.5.6审计收集系统（内部与外部）4.5.7事件引发主体的通知4.5.8漏洞评估
4.6 Records Archival
4.6 档案
4.6.1 Types of event recorded 4.6.2 Retention period for archive 4.6.3 Protection of archive 4.6.4 Archive backup procedures 4.6.5 Requirements for time-stamping of records 4.6.6 Archive collection system (internal or external) 4.6.7 Procedures to obtain and verify archive information
4.6.1 记录的事件类型4.6.2存档保留期4.6.3存档保护4.6.4存档备份程序4.6.5记录时间戳要求4.6.6存档收集系统（内部或外部）4.6.7获取和验证存档信息的程序
4.7 Key changeover
4.7 钥匙转换
4.8 Compromise and Disaster Recovery 4.8.1 Computing resources, software, and/or data are corrupted 4.8.2 Entity public key is revoked 4.8.3 Entity key is compromised 4.8.4 Secure facility after a natural or other type of disaster
4.8 泄露和灾难恢复4.8.1计算资源、软件和/或数据损坏4.8.2实体公钥被吊销4.8.3实体密钥泄露4.8.4自然或其他类型灾难后的安全设施
4.9 CA Termination
4.9 CA终止
5. PHYSICAL, PROCEDURAL, AND PERSONNEL SECURITY CONTROLS (34)
5. 物理、程序和人员安全控制（34）
5.1 Physical Controls 5.1.1 Site location and construction 5.1.2 Physical access 5.1.3 Power and air conditioning 5.1.4 Water exposures 5.1.5 Fire prevention and protection 5.1.6 Media storage 5.1.7 Waste disposal 5.1.8 Off-site backup
5.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 Procedural Controls 5.2.1 Trusted roles 5.2.2 Number of persons required per task 5.2.3 Identification and authentication for each role
5.2 程序控制5.2.1受信任的角色5.2.2每个任务所需的人数5.2.3每个角色的标识和身份验证
5.3 Personnel Controls 5.3.1 Background, qualifications, experience, and clearance requirements 5.3.2 Background check procedures 5.3.3 Training requirements 5.3.4 Retraining frequency and requirements 5.3.5 Job rotation frequency and sequence 5.3.6 Sanctions for unauthorized actions 5.3.7 Contracting personnel requirements 5.3.8 Documentation supplied to personnel
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提供给人员的文件
6. TECHNICAL SECURITY CONTROLS (34)
6. 技术安全控制（34）
6.1 Key Pair Generation and Installation 6.1.1 Key pair generation 6.1.2 Private key delivery to entity 6.1.3 Public key delivery to certificate issuer 6.1.4 CA public key delivery to users 6.1.5 Key sizes 6.1.6 Public key parameters generation 6.1.7 Parameter quality checking
6.1 密钥对生成和安装6.1.1密钥对生成6.1.2私钥传递给实体6.1.3公钥传递给证书颁发者6.1.4 CA公钥传递给用户6.1.5密钥大小6.1.6公钥参数生成6.1.7参数质量检查
6.1.8 Hardware/software key generation 6.1.9 Key usage purposes (as per X.509 v3 key usage field)
6.1.8 硬件/软件密钥生成6.1.9密钥使用目的（根据X.509 v3密钥使用字段）
6.2 Private Key Protection 6.2.1 Standards for cryptographic module 6.2.2 Private key (n out of m) multi-person control 6.2.3 Private key escrow 6.2.4 Private key backup 6.2.5 Private key archival 6.2.6 Private key entry into cryptographic module 6.2.7 Method of activating private key 6.2.8 Method of deactivating private key 6.2.9 Method of destroying private key
6.2 私钥保护6.2.1加密模块标准6.2.2私钥（n/m）多人控制6.2.3私钥托管6.2.4私钥备份6.2.5私钥存档6.2.6私钥进入加密模块6.2.7激活私钥的方法6.2.8禁用私钥的方法6.2.9销毁私钥的方法
6.3 Other Aspects of Key Pair Management 6.3.1 Public key archival 6.3.2 Usage periods for the public and private keys
6.3 密钥对管理的其他方面6.3.1公钥存档6.3.2公钥和私钥的使用期限
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.4 激活数据6.4.1激活数据生成和安装6.4.2激活数据保护6.4.3激活数据的其他方面
6.5 Computer Security Controls 6.5.1 Specific computer security technical requirements 6.5.2 Computer security rating
6.5 计算机安全控制6.5.1特定计算机安全技术要求6.5.2计算机安全等级
6.6 Life Cycle Technical Controls 6.6.1 System development controls 6.6.2 Security management controls 6.6.3 Life cycle security ratings
6.6 生命周期技术控制6.6.1系统开发控制6.6.2安全管理控制6.6.3生命周期安全评级
6.7 Network Security Controls
6.7 网络安全控制
6.8 Cryptographic Module Engineering Controls
6.8 密码模块工程控制
7. CERTIFICATE AND CRL PROFILES
7. 证书和CRL配置文件
7.1 Certificate Profile
7.1 证书配置文件
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.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 Processing semantics for the critical certificate policy extension
7.1.9 关键证书策略扩展的处理语义
7.2 CRL Profile
7.2 CRL剖面
7.2.1 Version number(s) 7.2.2 CRL and CRL entry extensions
7.2.1 版本号7.2.2 CRL和CRL条目扩展
8. SPECIFICATION ADMINISTRATION
8. 规范管理
8.1 Specification change procedures
8.1 规格更改程序
8.2 Publication and notification policies
8.2 发布和通知政策
8.3 CPS approval procedures
8.3 CPS批准程序
The development of this document 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 Technical Working Group. Special thanks are due to Dave Fillingham, Jim Brandt, and Edmond Van Hees for their inspiration, support, and valuable inputs.
本文件的编制得到了加拿大政府政策管理局（PMA）委员会、国家安全局、国家标准与技术研究所（NIST）和美国律师协会信息安全委员会认证技术工作组的支持。特别感谢Dave Fillingham、Jim Brandt和Edmond Van Hees的灵感、支持和宝贵投入。
The following individuals also deserve credit for their review and input:
以下个人的审查和投入也值得表扬：
Teresa Acevedo, A&N Associates;
Michael Baum; VeriSign;
Sharon Boeyen, Entrust;
Bob Burger, McCarter & English;
Bill Burr, NIST;
Patrick Cain, BBN;
Michael Harrop, Government of Canada Treasury Board;
Rick Hornbeck, Digital Commerce Services;
Francois Marinier, Domus Software;
John Morris, CygnaCom Solutions;
Tim Moses, Entrust;
Noel Nazario, NIST;
John Nicolletos, A&N Associates;
Jean Petty, CygnaCom Solutions;
Denis Pinkas, Bull;
J.-F. Sauriol, Domus Software;
Robert Shirey, BBN;
Mark Silvern, VeriSign;
David Simonetti, Booz, Allen and Hamilton; and
Darryl Stal, Entrust.
Teresa Acevedo, A&N Associates;
Michael Baum; VeriSign;
Sharon Boeyen, Entrust;
Bob Burger, McCarter & English;
Bill Burr, NIST;
Patrick Cain, BBN;
Michael Harrop, Government of Canada Treasury Board;
Rick Hornbeck, Digital Commerce Services;
Francois Marinier, Domus Software;
John Morris, CygnaCom Solutions;
Tim Moses, Entrust;
Noel Nazario, NIST;
John Nicolletos, A&N Associates;
Jean Petty, CygnaCom Solutions;
Denis Pinkas, Bull;
J.-F. Sauriol, Domus Software;
Robert Shirey, BBN;
Mark Silvern, VeriSign;
David Simonetti, Booz, Allen and Hamilton; and
Darryl Stal, Entrust.
Johnny Hsiung, and Chris Miller assisted in the preparation of the manuscript.
约翰尼·雄和克里斯·米勒协助编写了手稿。
[ABA1] American Bar Association, Digital Signature Guidelines: Legal Infrastructure for Certification Authorities and Electronic Commerce, 1995.
[ABA1]美国律师协会，《数字签名指南：认证机构和电子商务的法律基础设施》，1995年。
[BAU1] Michael. S. Baum, Federal Certification Authority Liability and Policy, NIST-GCR- 94-654, June 1994.
迈克尔。S.Baum，联邦认证机构责任和政策，NIST-GCR-94-654，1994年6月。
[ISO1] ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information Technology - Open Systems Interconnection: The Directory: Authentication Framework," 1997 edition. (Pending publication of 1997 edition, use 1993 edition with the following amendment applied: Final Text of Draft Amendment DAM 1 to ISO/IEC 9594-8 on Certificate Extensions, June 1996.)
[ISO1]ISO/IEC 9594-8/ITU-T建议X.509，“信息技术-开放系统互连：目录：认证框架”，1997年版。（在1997年版出版之前，使用1993年版，并应用以下修订：ISO/IEC 9594-8证书延期修订草案DAM 1的最终文本，1996年6月。）
[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., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure, Certificate and CRL Profile", RFC 2459, January 1999.
[PKI1]Housley，R.，Ford，W.，Polk，W.和D.Solo，“Internet X.509公钥基础设施，证书和CRL配置文件”，RFC 2459，1999年1月。
Santosh Chokhani CygnaCom Solutions, Inc. Suite 100 West 7927 Jones Branch Drive McLean, VA 22102
Santosh Chokhani CygnaCom Solutions，Inc.弗吉尼亚州麦克莱恩琼斯大道西7927号100室22102
Phone: (703) 848-0883 Fax: (703) 848-0960 EMail: chokhani@cygnacom.com
电话：（703）848-0883传真：（703）848-0960电子邮件：chokhani@cygnacom.com
Warwick Ford VeriSign, Inc. 301 Edgewater Place, Suite 210 Wakefield, MA 01880
华威福特威瑞信有限公司，地址：马萨诸塞州威克菲尔德市Edgewater Place 301号210室，邮编：01880
Phone: (781) 245-6996 x225 Fax: (781) 245-6006 EMail: wford@verisign.com
电话：（781）245-6996 x225传真：（781）245-6006电子邮件：wford@verisign.com
NOTES
笔记
1 The ABA Digital Signature Guidelines can be purchased from the ABA. See http://www.abanet.com for ordering details.
1 ABA数字签名指南可从ABA购买。看见http://www.abanet.com 有关订购详情。
2 Examples of types of entity for subject CAs are a subordinate organization (e.g., branch or division), a federal government agency, or a state or provincial government department.
2主体CA的实体类型示例为下级组织（如分支机构或部门）、联邦政府机构或州或省政府部门。
3 This statement can have significant implications. For example, suppose a bank claims that it issues CA certificates to its branches only. Now, the user of a CA certificate issued by the bank can assume that the subject CA in the certificate is a branch of the bank
3本声明可能具有重大意义。例如，假设一家银行声称它只向其分支机构颁发CA证书。现在，银行颁发的CA证书的用户可以假定证书中的主体CA是银行的分支机构
4 Examples of the types of subject RA entities are branch and division of an organization.
4主体RA实体类型的示例为组织的分支和部门。
5 Examples of types of subject end entities are bank customers, telephone company subscribers, and employees of a government department
5主题终端实体类型的示例包括银行客户、电话公司用户和政府部门的员工
6 This statement can have significant implications. For example, suppose Government CA claims that it issues certificates to Government employees only. Now, the user of a certificate issued by the Government CA can assume that the subject of the certificate is a Government employee.
6该声明可能具有重大意义。例如，假设政府CA声称它只向政府雇员颁发证书。现在，政府CA颁发的证书的用户可以假定证书的主体是政府雇员。
7 Examples include X.500 distinguished name, Internet e-mail address, and URL.
7个示例包括X.500可分辨名称、Internet电子邮件地址和URL。
8 The term "meaningful" means that the name form has commonly understood semantics to determine identity of the person and/or organization. Directory names and RFC 822 names may be more or less meaningful.
8术语“有意义”是指名称形式具有普遍理解的语义，以确定个人和/或组织的身份。目录名和RFC 822名称可能或多或少有意义。
9 Examples of proof include the issuing CA generating the key, or requiring the subject to send an electronically signed request or to sign a challenge.
9证明的例子包括签发CA生成密钥，或要求受试者发送电子签名请求或签署质疑。
10 Examples of organization identity authentication are: articles of incorporation, duly signed corporate resolutions, company seal, and notarized documents.
组织身份认证的10个示例包括：公司章程、正式签署的公司决议、公司印章和公证文件。
11 Examples of individual identity authentication are: biometrics (thumb print, ten finger print, face, palm, and retina scan), driver's license, passport, credit card, company badge, and government badge.
11个人身份认证的示例包括：生物特征（拇指指纹、十个指纹、面部、手掌和视网膜扫描）、驾驶执照、护照、信用卡、公司徽章和政府徽章。
12 Examples include duly signed authorization papers or corporate ID badge.
12个例子包括正式签署的授权文件或公司ID徽章。
13 The identification policy for routine rekey should be the same as the one for initial registration since the same subject needs rekeying. The rekey authentication may be accomplished using the techniques for initial I&A or using digitally signed requests.
13由于同一受试者需要重新输入密钥，因此常规重新输入密钥的识别策略应与初始注册的识别策略相同。可使用初始I&A技术或使用数字签名请求来完成密钥重新认证。
14 This identification and authentication policy could be the same as that for initial registration.
14此标识和身份验证策略可以与初始注册相同。
15 This policy could be the same as the one for initial registration.
15此政策可能与初始注册的政策相同。
16 The identification policy for Revocation request could be the same as that for initial registration since the same subject certificate needs to be revoked. The authentication policy could accept a Revocation request digitally signed by subject. The authentication information used during initial registration could be acceptable for Revocation request. Other less stringent authentication policy could be defined.
16撤销请求的标识策略可以与初始注册的标识策略相同，因为需要撤销相同的主体证书。身份验证策略可以接受由主体数字签名的吊销请求。初始注册期间使用的身份验证信息可用于撤销请求。可以定义其他不太严格的身份验证策略。
17 The identification policy for key compromise notification could be the same as the one for initial registration since the same subject certificate needs to be revoked. The authentication policy could accept a Revocation request digitally signed by subject. The authentication information used during initial registration could be acceptable for key compromise notification. Other less stringent authentication policy could be defined.
17密钥泄露通知的标识策略可能与初始注册的标识策略相同，因为同一主体证书需要撤销。身份验证策略可以接受由主体数字签名的吊销请求。初始注册期间使用的身份验证信息可用于密钥泄露通知。可以定义其他不太严格的身份验证策略。
18 The n out of m rule allows a key to be split in m parts. The m parts may be given to m different individuals. Any n parts out of the m parts may be used to fully reconstitute the key, but having any n- 1 parts provides one with no information about the key.
18“m取n”规则允许将密钥拆分为m个部分。m个部分可能被给予m个不同的个体。m个部分中的任何n个部分都可以用来完全重新组合密钥，但是如果有任何n-1个部分，则不会提供关于密钥的任何信息。
19 A key may be escrowed, backed up or archived. Each of these functions have different purpose. Thus, a key may go through any subset of these functions depending on the requirements. The purpose of escrow is to allow a third party (such as an organization or government) to legally obtain the key without the cooperation of the subject. The purpose of back up is to allow the subject to reconstitute the key in case of the destruction of the key. The purpose of archive is to provide for reuse of the key in future, e.g., use the private key to decrypt a document.
19密钥可以托管、备份或存档。每个功能都有不同的用途。因此，根据需求，键可以通过这些功能的任何子集。托管的目的是允许第三方（如组织或政府）在没有主体合作的情况下合法获取密钥。备份的目的是允许主体在密钥被破坏的情况下重新配置密钥。存档的目的是为将来重新使用密钥提供便利，例如，使用私钥解密文档。
20 An example of activation data is a PIN or passphrase.
20激活数据的一个示例是PIN或密码短语。
21 Examples of physical access controls are: monitored facility , guarded facility, locked facility, access controlled using tokens,
21物理访问控制的示例包括：受监控设施、受保护设施、锁定设施、使用令牌控制的访问，
access controlled using biometrics, and access controlled through an access list.
使用生物特征进行访问控制，并通过访问列表进行访问控制。
22 Examples of the roles include system administrator, system security officer, and system auditor. The duties of the system administrator are to configure, generate, boot, and operate the system. The duties of the system security officer are to assign accounts and privileges. The duties of the system auditor are to set up system audit profile, perform audit file management, and audit review.
22个角色示例包括系统管理员、系统安全官员和系统审计员。系统管理员的职责是配置、生成、引导和操作系统。系统安全官员的职责是分配帐户和权限。系统审核员的职责是建立系统审核档案、执行审核文件管理和审核审核。
23 The background checks may include clearance level (e.g., none, sensitive, confidential, secret, top secret, etc.) and the clearance granting authority name. In lieu of or in addition to a defined clearance, the background checks may include types of background information (e.g., name, place of birth, date of birth, home address, previous residences, previous employment, and any other information that may help determine trustworthiness). The description should also include which information was verified and how.
23背景检查可能包括许可级别（例如，无、敏感、机密、机密、绝密等）和许可授予机构名称。除了规定的许可之外，背景检查还可以包括各种背景信息（例如姓名、出生地、出生日期、家庭住址、以前的居住地、以前的工作以及可能有助于确定可信度的任何其他信息）。说明还应包括哪些信息得到验证以及如何验证。
24 For example, the certificate policy may impose personnel security requirements on the network system administrator responsible for a CA's network access.
24例如，证书策略可能对负责CA网络访问的网络系统管理员施加人员安全要求。
25 Regardless of whether authorized persons are employees, practices should be implemented to ensure that each authorized person is held accountable for his/her actions.
25无论被授权人是否为员工，都应采取措施确保每个被授权人对其行为负责。
26 A cryptographic module is hardware, software, or firmware or any combination of them.
26加密模块是硬件、软件或固件或它们的任意组合。
27 The compliance description should be specific and detailed. For example, for each FIPS 140-1 requirement, describe the level and whether the level has been certified by an accredited laboratory.
27合规性说明应具体详细。例如，对于每项FIPS 140-1要求，描述其等级以及该等级是否已由认证实验室认证。
28 Example of audit events are: request to create a certificate, request to revoke a certificate, key compromise notification, creation of a certificate, revocation of a certificate, issuance of a certificate, issuance of a CRL, issuance of key compromise CRL, establishment of trusted roles on the CA, actions of truste personnel, changes to CA keys, etc.
28审核事件的示例包括：请求创建证书、请求撤销证书、密钥泄露通知、创建证书、撤销证书、颁发证书、颁发CRL、颁发密钥泄露CRL、在CA上建立受信任角色、受信任人员的操作，更改CA密钥等。
29 Example of archive events are: request to create a certificate, request to revoke a certificate, key compromise notification, creation of a certificate, revocation of a certificate, issuance of a certificate, issuance of a CRL, issuance of key compromise CRL, and changes to CA keys.
29存档事件的示例包括：请求创建证书、请求撤销证书、密钥泄露通知、创建证书、撤销证书、颁发证书、颁发CRL、颁发密钥泄露CRL以及更改CA密钥。
30 A parent CA is an example of audit relationship.
30父CA是审计关系的一个示例。
31 Example of compliance audit topics: sample check on the various I&A policies, comprehensive checks on key management policies, comprehensive checks on system security controls, comprehensive checks on operations policy, and comprehensive checks on certificate profiles.
31合规性审计主题示例：各种I&A策略的样本检查、密钥管理策略的全面检查、系统安全控制的全面检查、操作策略的全面检查以及证书配置文件的全面检查。
32 The examples include, temporary suspension of operations until deficiencies are corrected, revocation of entity certificate, change in personnel, invocation of liability policy, more frequent compliance audit, etc.
32例如，在缺陷得到纠正之前暂时暂停运营、撤销实体证书、更换人员、援引责任政策、更频繁的合规审计等。
33 An organization may choose not to make public some of its security controls, clearance procedures, or some others elements due to their sensitivity.
33由于其敏感性，组织可能选择不公开其某些安全控制、许可程序或其他要素。
34 All or some of the following items may be different for the various types of entities, i.e., CA, RA, and end entities.
34对于不同类型的实体，即CA、RA和终端实体，以下所有或部分项目可能不同。
LIST OF ACRONYMS
缩略词清单
ABA - American Bar Association CA - Certification Authority CPS - Certification Practice Statement CRL - Certificate Revocation List DAM - Draft Amendment FIPS - Federal Information Processing Standard I&A - Identification and Authentication IEC - International Electrotechnical Commission IETF - Internet Engineering Task Force IP - Internet Protocol ISO - International Organization for Standardization ITU - International Telecommunications Union NIST - National Institute of Standards and Technology OID - Object Identifier PIN - Personal Identification Number PKI - Public Key Infrastructure PKIX - Public Key Infrastructure (X.509) (IETF Working Group) RA - Registration Authority RFC - Request For Comment URL - Uniform Resource Locator US - United States
ABA-美国律师协会CA-认证机构CPS-认证实践声明CRL-证书撤销清单DAM-修订草案FIPS-联邦信息处理标准I&A-识别和认证IEC-国际电工委员会IETF-互联网工程任务组IP-互联网协议ISO-国际标准化组织ITU-国际电信联盟NIST-国家标准与技术研究所OID-对象标识符PIN-个人识别号PKI-公钥基础设施PKIX-公钥基础设施（X.509）（IETF工作组）RA-注册机构RFC-征求意见URL-统一资源定位器美国-美国
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。