Internet Engineering Task Force (IETF) S. Kent
Request for Comments: 6484 D. Kong
BCP: 173 K. Seo
Category: Best Current Practice R. Watro
ISSN: 2070-1721 BBN Technologies
February 2012
Internet Engineering Task Force (IETF) S. Kent
Request for Comments: 6484 D. Kong
BCP: 173 K. Seo
Category: Best Current Practice R. Watro
ISSN: 2070-1721 BBN Technologies
February 2012
Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)
资源公钥基础结构（RPKI）的证书策略（CP）
Abstract
摘要
This document describes the certificate policy for a Public Key Infrastructure (PKI) used to support attestations about Internet Number Resource (INR) holdings. Each organization that distributes IP addresses or Autonomous System (AS) numbers to an organization will, in parallel, issue a (public key) certificate reflecting this distribution. These certificates will enable verification that the resources indicated in the certificate have been distributed to the holder of the associated private key and that this organization is the current, unique holder of these resources.
本文档描述了公钥基础设施（PKI）的证书策略，PKI用于支持有关Internet数字资源（INR）持有的认证。向组织分发IP地址或自治系统（AS）编号的每个组织将同时颁发反映此分发的（公钥）证书。这些证书将允许验证证书中指示的资源是否已分发给相关私钥的持有者，以及该组织是否是这些资源的当前唯一持有者。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6484.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6484.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从该文档中提取的代码组件必须
include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
包括信托法律条款第4.e节中所述的简化BSD许可证文本，且不提供简化BSD许可证中所述的担保。
Table of Contents
目录
1. Introduction ....................................................6
1.1. Overview ...................................................7
1.2. Document Name and Identification ...........................7
1.3. PKI Participants ...........................................7
1.3.1. Certification Authorities ...........................8
1.3.2. Registration Authorities ............................8
1.3.3. Subscribers .........................................8
1.3.4. Relying Parties .....................................8
1.3.5. Other Participants ..................................8
1.4. Certificate Usage ..........................................9
1.4.1. Appropriate Certificate Uses ........................9
1.4.2. Prohibited Certificate Uses .........................9
1.5. Policy Administration ......................................9
1.5.1. Organization Administering the Document .............9
1.5.2. Contact Person ......................................9
1.5.4. CP Approval Procedures ..............................9
1.6. Definitions and Acronyms ..................................10
2. Publication and Repository Responsibilities ....................11
2.1. Repositories ..............................................11
2.2. Publication of Certification Information ..................11
2.3. Time or Frequency of Publication ..........................12
2.4. Access Controls on Repositories ...........................12
3. Identification and Authentication ..............................12
3.1. Naming ....................................................12
3.1.1. Types of Names .....................................12
3.1.2. Need for Names to Be Meaningful ....................12
3.1.3. Anonymity or Pseudonymity of Subscribers ...........13
3.1.4. Rules for Interpreting Various Name Forms ..........13
3.1.5. Uniqueness of Names ................................13
3.2. Initial Identity Validation ...............................13
3.2.1. Method to Prove Possession of the Private Key ......13
3.2.2. Authentication of Organization Identity ............13
3.2.3. Authentication of Individual Identity ..............14
3.2.4. Non-Verified Subscriber Information ................14
3.2.5. Validation of Authority ............................14
3.2.6. Criteria for Interoperation ........................14
3.3. Identification and Authentication for Re-Key Requests .....14
3.3.1. Identification and Authentication for
Routine Re-Key .....................................14
3.3.2. Identification and Authentication for
Re-Key after Revocation ............................15
3.4. Identification and Authentication for Revocation Request ..15
1. Introduction ....................................................6
1.1. Overview ...................................................7
1.2. Document Name and Identification ...........................7
1.3. PKI Participants ...........................................7
1.3.1. Certification Authorities ...........................8
1.3.2. Registration Authorities ............................8
1.3.3. Subscribers .........................................8
1.3.4. Relying Parties .....................................8
1.3.5. Other Participants ..................................8
1.4. Certificate Usage ..........................................9
1.4.1. Appropriate Certificate Uses ........................9
1.4.2. Prohibited Certificate Uses .........................9
1.5. Policy Administration ......................................9
1.5.1. Organization Administering the Document .............9
1.5.2. Contact Person ......................................9
1.5.4. CP Approval Procedures ..............................9
1.6. Definitions and Acronyms ..................................10
2. Publication and Repository Responsibilities ....................11
2.1. Repositories ..............................................11
2.2. Publication of Certification Information ..................11
2.3. Time or Frequency of Publication ..........................12
2.4. Access Controls on Repositories ...........................12
3. Identification and Authentication ..............................12
3.1. Naming ....................................................12
3.1.1. Types of Names .....................................12
3.1.2. Need for Names to Be Meaningful ....................12
3.1.3. Anonymity or Pseudonymity of Subscribers ...........13
3.1.4. Rules for Interpreting Various Name Forms ..........13
3.1.5. Uniqueness of Names ................................13
3.2. Initial Identity Validation ...............................13
3.2.1. Method to Prove Possession of the Private Key ......13
3.2.2. Authentication of Organization Identity ............13
3.2.3. Authentication of Individual Identity ..............14
3.2.4. Non-Verified Subscriber Information ................14
3.2.5. Validation of Authority ............................14
3.2.6. Criteria for Interoperation ........................14
3.3. Identification and Authentication for Re-Key Requests .....14
3.3.1. Identification and Authentication for
Routine Re-Key .....................................14
3.3.2. Identification and Authentication for
Re-Key after Revocation ............................15
3.4. Identification and Authentication for Revocation Request ..15
4. Certificate Life-Cycle Operational Requirements ................16
4.1. Certificate Application ...................................16
4.1.1. Who Can Submit a Certificate Application ...........16
4.1.2. Enrollment Process and Responsibilities ............16
4.2. Certificate Application Processing ........................16
4.2.1. Performing Identification and
Authentication Functions ...........................16
4.2.2. Approval or Rejection of Certificate Applications ..16
4.2.3. Time to Process Certificate Applications ...........17
4.3. Certificate Issuance ......................................17
4.3.1. CA Actions during Certificate Issuance .............17
4.3.2. Notification to Subscriber by the CA of
Issuance of Certificate ............................17
4.4. Certificate Acceptance ....................................17
4.4.1. Conduct Constituting Certificate Acceptance ........17
4.4.2. Publication of the Certificate by the CA ...........17
4.4.3. Notification of Certificate Issuance by the
CA to Other Entities ...............................17
4.5. Key Pair and Certificate Usage ............................18
4.5.1. Subscriber Private Key and Certificate Usage .......18
4.5.2. Relying Party Public Key and Certificate Usage .....18
4.6. Certificate Renewal .......................................18
4.6.1. Circumstance for Certificate Renewal ...............19
4.6.2. Who May Request Renewal ............................19
4.6.3. Processing Certificate Renewal Requests ............19
4.6.4. Notification of New Certificate Issuance to
Subscriber .........................................19
4.6.5. Conduct Constituting Acceptance of a
Renewal Certificate ................................19
4.6.6. Publication of the Renewal Certificate by the CA ...20
4.6.7. Notification of Certificate Issuance by the
CA to Other Entities ...............................20
4.7. Certificate Re-Key ........................................20
4.7.1. Circumstance for Certificate Re-Key ................20
4.7.2. Who May Request Certification of a New Public Key ..20
4.7.3. Processing Certificate Re-Keying Requests ..........21
4.7.4. Notification of New Certificate Issuance to
Subscriber .........................................21
4.7.5. Conduct Constituting Acceptance of a
Re-Keyed Certificate ...............................21
4.7.6. Publication of the Re-Keyed Certificate by the CA ..21
4.7.7. Notification of Certificate Issuance by the
CA to Other Entities ...............................21
4.8. Certificate Modification ..................................21
4.8.1. Circumstance for Certificate Modification ..........21
4.8.2. Who May Request Certificate Modification ...........21
4.8.3. Processing Certificate Modification Requests .......22
4. Certificate Life-Cycle Operational Requirements ................16
4.1. Certificate Application ...................................16
4.1.1. Who Can Submit a Certificate Application ...........16
4.1.2. Enrollment Process and Responsibilities ............16
4.2. Certificate Application Processing ........................16
4.2.1. Performing Identification and
Authentication Functions ...........................16
4.2.2. Approval or Rejection of Certificate Applications ..16
4.2.3. Time to Process Certificate Applications ...........17
4.3. Certificate Issuance ......................................17
4.3.1. CA Actions during Certificate Issuance .............17
4.3.2. Notification to Subscriber by the CA of
Issuance of Certificate ............................17
4.4. Certificate Acceptance ....................................17
4.4.1. Conduct Constituting Certificate Acceptance ........17
4.4.2. Publication of the Certificate by the CA ...........17
4.4.3. Notification of Certificate Issuance by the
CA to Other Entities ...............................17
4.5. Key Pair and Certificate Usage ............................18
4.5.1. Subscriber Private Key and Certificate Usage .......18
4.5.2. Relying Party Public Key and Certificate Usage .....18
4.6. Certificate Renewal .......................................18
4.6.1. Circumstance for Certificate Renewal ...............19
4.6.2. Who May Request Renewal ............................19
4.6.3. Processing Certificate Renewal Requests ............19
4.6.4. Notification of New Certificate Issuance to
Subscriber .........................................19
4.6.5. Conduct Constituting Acceptance of a
Renewal Certificate ................................19
4.6.6. Publication of the Renewal Certificate by the CA ...20
4.6.7. Notification of Certificate Issuance by the
CA to Other Entities ...............................20
4.7. Certificate Re-Key ........................................20
4.7.1. Circumstance for Certificate Re-Key ................20
4.7.2. Who May Request Certification of a New Public Key ..20
4.7.3. Processing Certificate Re-Keying Requests ..........21
4.7.4. Notification of New Certificate Issuance to
Subscriber .........................................21
4.7.5. Conduct Constituting Acceptance of a
Re-Keyed Certificate ...............................21
4.7.6. Publication of the Re-Keyed Certificate by the CA ..21
4.7.7. Notification of Certificate Issuance by the
CA to Other Entities ...............................21
4.8. Certificate Modification ..................................21
4.8.1. Circumstance for Certificate Modification ..........21
4.8.2. Who May Request Certificate Modification ...........21
4.8.3. Processing Certificate Modification Requests .......22
4.8.4. Notification of New Certificate Issuance to
Subscriber .........................................22
4.8.5. Conduct Constituting Acceptance of Modified
Certificate ........................................22
4.8.6. Publication of the Modified Certificate by the CA ..22
4.8.7. Notification of Certificate Issuance by the
CA to Other Entities ...............................22
4.9. Certificate Revocation and Suspension .....................22
4.9.1. Circumstances for Revocation .......................22
4.9.2. Who Can Request Revocation .........................22
4.9.3. Procedure for Revocation Request ...................23
4.9.4. Revocation Request Grace Period ....................23
4.9.5. Time within which CA Must Process the
Revocation Request .................................23
4.9.6. Revocation Checking Requirement for Relying
Parties ............................................23
4.9.7. CRL Issuance Frequency .............................23
4.9.8. Maximum Latency for CRLs ...........................23
4.10. Certificate Status Services ..............................24
5. Facility, Management, and Operational Controls .................24
5.1. Physical Controls .........................................24
5.1.1. Site Location and Construction .....................24
5.1.2. Physical Access ....................................24
5.1.3. Power and Air Conditioning .........................24
5.1.4. Water Exposures ....................................24
5.1.5. Fire Prevention and Protection .....................24
5.1.6. Media Storage ......................................24
5.1.7. Waste Disposal .....................................24
5.1.8. Off-Site Backup ....................................24
5.2. Procedural Controls .......................................24
5.2.1. Trusted Roles ......................................25
5.2.2. Number of Persons Required per Task ................25
5.2.3. Identification and Authentication for Each Role ....25
5.2.4. Roles Requiring Separation of Duties ...............25
5.3. Personnel Controls ........................................25
5.4. Audit Logging Procedures ..................................25
5.4.1. Types of Events Recorded ...........................25
5.4.2. Frequency of Processing Log ........................25
5.4.3. Retention Period for Audit Log .....................26
5.4.4. Protection of Audit Log ............................26
5.4.5. Audit Log Backup Procedures ........................26
5.4.8. Vulnerability Assessments ..........................26
5.6. Key Changeover ............................................26
5.7. CA or RA Termination ......................................26
6. Technical Security Controls ....................................26
6.1. Key Pair Generation and Installation ......................27
6.1.1. Key Pair Generation ................................27
6.1.2. Private Key Delivery to Subscriber .................27
4.8.4. Notification of New Certificate Issuance to
Subscriber .........................................22
4.8.5. Conduct Constituting Acceptance of Modified
Certificate ........................................22
4.8.6. Publication of the Modified Certificate by the CA ..22
4.8.7. Notification of Certificate Issuance by the
CA to Other Entities ...............................22
4.9. Certificate Revocation and Suspension .....................22
4.9.1. Circumstances for Revocation .......................22
4.9.2. Who Can Request Revocation .........................22
4.9.3. Procedure for Revocation Request ...................23
4.9.4. Revocation Request Grace Period ....................23
4.9.5. Time within which CA Must Process the
Revocation Request .................................23
4.9.6. Revocation Checking Requirement for Relying
Parties ............................................23
4.9.7. CRL Issuance Frequency .............................23
4.9.8. Maximum Latency for CRLs ...........................23
4.10. Certificate Status Services ..............................24
5. Facility, Management, and Operational Controls .................24
5.1. Physical Controls .........................................24
5.1.1. Site Location and Construction .....................24
5.1.2. Physical Access ....................................24
5.1.3. Power and Air Conditioning .........................24
5.1.4. Water Exposures ....................................24
5.1.5. Fire Prevention and Protection .....................24
5.1.6. Media Storage ......................................24
5.1.7. Waste Disposal .....................................24
5.1.8. Off-Site Backup ....................................24
5.2. Procedural Controls .......................................24
5.2.1. Trusted Roles ......................................25
5.2.2. Number of Persons Required per Task ................25
5.2.3. Identification and Authentication for Each Role ....25
5.2.4. Roles Requiring Separation of Duties ...............25
5.3. Personnel Controls ........................................25
5.4. Audit Logging Procedures ..................................25
5.4.1. Types of Events Recorded ...........................25
5.4.2. Frequency of Processing Log ........................25
5.4.3. Retention Period for Audit Log .....................26
5.4.4. Protection of Audit Log ............................26
5.4.5. Audit Log Backup Procedures ........................26
5.4.8. Vulnerability Assessments ..........................26
5.6. Key Changeover ............................................26
5.7. CA or RA Termination ......................................26
6. Technical Security Controls ....................................26
6.1. Key Pair Generation and Installation ......................27
6.1.1. Key Pair Generation ................................27
6.1.2. Private Key Delivery to Subscriber .................27
6.1.3. Public Key Delivery to Certificate Issuer ..........27
6.1.4. CA Public Key Delivery to Relying Parties ..........27
6.1.5. Key Sizes ..........................................27
6.1.6. Public Key Parameters Generation and
Quality Checking ...................................28
6.1.7. Key Usage Purposes (as per X.509 v3 Key
Usage Field) .......................................28
6.2. Private Key Protection and Cryptographic Module
Engineering Controls ......................................28
6.2.1. Cryptographic Module Standards and Controls ........28
6.2.2. Private Key (N out of M) Multi-Person Control ......28
6.2.3. Private Key Escrow .................................28
6.2.4. Private Key Backup .................................28
6.2.5. Private Key Archival ...............................28
6.2.6. Private Key Transfer into or from a
Cryptographic Module ...............................29
6.2.7. Private Key Storage on Cryptographic Module ........29
6.2.8. Method of Activating a Private Key .................29
6.2.9. Method of Deactivating a Private Key ...............29
6.2.10. Method of Destroying a Private Key ................29
6.2.11. Cryptographic Module Rating .......................29
6.3. Other Aspects of Key Pair Management ......................29
6.3.1. Public Key Archival ................................29
6.3.2. Certificate Operational Periods and Key
Pair Usage Periods .................................29
6.4. Activation Data ...........................................30
6.5. Computer Security Controls ................................30
6.6. Life-Cycle Technical Controls .............................30
6.6.1. System Development Controls ........................30
6.6.2. Security Management Controls .......................30
6.6.3. Life-Cycle Security Controls .......................30
6.7. Network Security Controls .................................30
6.8. Timestamping ..............................................30
7. Certificate and CRL Profiles ...................................31
8. Compliance Audit and Other Assessments .........................31
9. Other Business and Legal Matters ...............................31
9.12. Amendments ..............................................31
9.12.1. Procedure for Amendment ...........................31
9.12.2. Notification Mechanism and Period .................31
9.12.3. Circumstances under Which OID Must Be Changed .....32
10. Security Considerations .......................................32
11. Acknowledgments ...............................................33
12. References ....................................................33
12.1. Normative References .....................................33
12.2. Informative References ...................................33
6.1.3. Public Key Delivery to Certificate Issuer ..........27
6.1.4. CA Public Key Delivery to Relying Parties ..........27
6.1.5. Key Sizes ..........................................27
6.1.6. Public Key Parameters Generation and
Quality Checking ...................................28
6.1.7. Key Usage Purposes (as per X.509 v3 Key
Usage Field) .......................................28
6.2. Private Key Protection and Cryptographic Module
Engineering Controls ......................................28
6.2.1. Cryptographic Module Standards and Controls ........28
6.2.2. Private Key (N out of M) Multi-Person Control ......28
6.2.3. Private Key Escrow .................................28
6.2.4. Private Key Backup .................................28
6.2.5. Private Key Archival ...............................28
6.2.6. Private Key Transfer into or from a
Cryptographic Module ...............................29
6.2.7. Private Key Storage on Cryptographic Module ........29
6.2.8. Method of Activating a Private Key .................29
6.2.9. Method of Deactivating a Private Key ...............29
6.2.10. Method of Destroying a Private Key ................29
6.2.11. Cryptographic Module Rating .......................29
6.3. Other Aspects of Key Pair Management ......................29
6.3.1. Public Key Archival ................................29
6.3.2. Certificate Operational Periods and Key
Pair Usage Periods .................................29
6.4. Activation Data ...........................................30
6.5. Computer Security Controls ................................30
6.6. Life-Cycle Technical Controls .............................30
6.6.1. System Development Controls ........................30
6.6.2. Security Management Controls .......................30
6.6.3. Life-Cycle Security Controls .......................30
6.7. Network Security Controls .................................30
6.8. Timestamping ..............................................30
7. Certificate and CRL Profiles ...................................31
8. Compliance Audit and Other Assessments .........................31
9. Other Business and Legal Matters ...............................31
9.12. Amendments ..............................................31
9.12.1. Procedure for Amendment ...........................31
9.12.2. Notification Mechanism and Period .................31
9.12.3. Circumstances under Which OID Must Be Changed .....32
10. Security Considerations .......................................32
11. Acknowledgments ...............................................33
12. References ....................................................33
12.1. Normative References .....................................33
12.2. Informative References ...................................33
This document describes the certificate policy for a Public Key Infrastructure (PKI) used to attest to Internet Number Resource (INR) holdings (IP addresses or Autonomous System (AS) numbers). An organization that distributes INRs to another organization MAY, in parallel, issue a (public key) certificate reflecting this distribution. These certificates will enable verification that the resources indicated in the certificate have been distributed to the holder of the associated private key and that this organization is the current holder of these resources.
本文档描述了用于证明互联网号码资源（INR）持有情况（IP地址或自主系统（AS）号码）的公钥基础设施（PKI）的证书策略。向另一个组织分发INR的组织可以同时颁发反映此分发的（公钥）证书。这些证书将允许验证证书中指示的资源是否已分发给相关私钥的持有者，以及该组织是否是这些资源的当前持有者。
The most important and distinguishing aspect of the PKI for which this policy was created is that it does not purport to identify an INR holder via the subject name contained in the certificate issued to that entity. Rather, each certificate issued under this policy is intended to enable an entity to assert, in a verifiable fashion, that it is the current holder of an INR based on the current records of the entity responsible for the resources in question. Verification of the assertion is based on two criteria: the ability of the entity to digitally sign data that is verifiable using the public key contained in the corresponding certificate, and validation of that certificate in the context of this PKI.
本政策所针对的PKI最重要和最有区别的方面是，该政策无意通过颁发给该实体的证书中包含的主体名称来识别INR持有人。相反，根据本政策颁发的每个证书旨在使实体能够以可验证的方式，根据负责相关资源的实体的当前记录，声明其是INR的当前持有人。断言的验证基于两个标准：实体对可使用相应证书中包含的公钥进行验证的数据进行数字签名的能力，以及在此PKI上下文中验证该证书的能力。
This PKI is designed exclusively for use in support of validation of claims related to current INR holdings. This includes any certificates issued in support of operation of this infrastructure, e.g., for integrity or access control of the repository system described in Section 2.4. Such transitive uses of certificates also are permitted under this policy. Use of the certificates and Certificate Revocation Lists (CRLs) managed under this PKI for any other purpose is a violation of this CP, and relying parties (RPs) SHOULD reject certificates presented for such uses.
此PKI专门用于支持与当前印度卢比持有量相关的索赔的验证。这包括为支持该基础设施的运行而颁发的任何证书，如第2.4节所述的存储库系统的完整性或访问控制证书。本政策还允许此类证书的传递性使用。将本PKI下管理的证书和证书撤销列表（CRL）用于任何其他用途违反本CP，依赖方（RP）应拒绝为此类用途提供的证书。
Note: This document is based on the template specified in RFC 3647 [RFC3647], a product of the Internet Engineering Task Force (IETF) stream. In the interest of keeping the document as short as reasonable, a number of sections contained in the template have been omitted from this policy because they do not apply to this PKI. However, we have retained the section numbering scheme employed in RFC 3647 to facilitate comparison with the outline in Section 6 of RFC 3647. Each of these omitted sections should be read as "No stipulation" in Certificate Policy (CP) / Certification Practice Statement (CPS) parlance.
注：本文件基于RFC 3647[RFC3647]中规定的模板，该模板是互联网工程任务组（IETF）流的产品。为了使文件尽可能简短合理，本政策中省略了模板中包含的一些章节，因为它们不适用于本PKI。然而，我们保留了RFC 3647中采用的章节编号方案，以便于与RFC 3647第6节中的大纲进行比较。在证书政策（CP）/认证实践声明（CPS）术语中，这些省略的章节应理解为“无规定”。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This PKI is designed to support validation of claims by current holders of INRs, in accordance with the records of the organizations that act as Certification Authorities (CAs) in this PKI. The ability to verify such claims is essential to ensuring the unambiguous distribution of these resources [RFC6480].
本PKI旨在根据本PKI中作为认证机构（CA）的组织的记录，支持INR当前持有人的索赔验证。核实此类索赔的能力对于确保这些资源的明确分配至关重要[RFC6480]。
The structure of the RPKI is congruent with the number resource allocation framework of the Internet. The IANA allocates number resources to Regional Internet Registries (RIRs), to others, and for special purposes [RFC5736]. The RIRs, in turn, manage the allocation of number resources to end users, Internet Service Providers, and others.
RPKI的结构与Internet的数字资源分配框架一致。IANA将数字资源分配给区域互联网注册中心（RIR）、其他注册中心和特殊用途[RFC5736]。RIR反过来管理向最终用户、互联网服务提供商和其他人分配的数字资源。
This PKI encompasses several types of certificates (see [RFC6487] for more details):
此PKI包含几种类型的证书（有关更多详细信息，请参阅[RFC6487]：
o CA certificates for each organization distributing INRs and for INR holders
o 分发INR的每个组织和INR持有人的CA证书
o End-entity (EE) certificates for organizations to validate digital signatures on RPKI signed objects
o 用于组织验证RPKI签名对象上数字签名的终端实体（EE）证书
The name of this document is "Certificate Policy (CP) for the Resource PKI (RPKI)".
本文档的名称为“资源PKI（RPKI）的证书策略（CP）”。
This policy has been assigned the following OID:
此策略已分配以下OID：
id-cp-ipAddr-asNumber OBJECT IDENTIFIER ::= { iso(1)
id-cp-ipAddr-asNumber OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1)
identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) cp(14) 2 }
security(5) mechanisms(5) pkix(7) cp(14) 2 }
Note that in a PKI, the term "subscriber" refers to an individual or organization that is a subject of a certificate issued by a CA. The term is used in this fashion throughout this document, without qualification, and should not be confused with the networking use of the term to refer to an individual or organization that receives service from an ISP. In such cases, the term "network subscriber" will be used. Also note that, for brevity, this document always refers to PKI participants as organizations or entities, even though some of them are individuals.
请注意，在PKI中，术语“订阅者”指的是CA颁发的证书的主体个人或组织。本文件中以这种方式使用该术语，没有任何限制，而且不应与“网络”一词的用法混淆，该词指的是从ISP接收服务的个人或组织。在这种情况下，将使用术语“网络订户”。还请注意，为简洁起见，本文件始终将PKI参与者称为组织或实体，即使其中一些人是个人。
The organizations that distribute IP addresses and AS numbers (IANA, RIRs, NIRs, ISPs) act as CAs in this PKI.
分发IP地址和AS号码的组织（IANA、RIRs、NIRs、ISP）充当此PKI中的CA。
Organizations that do not distribute INRs but hold such resources also act as CAs when they create EE certificates.
不分发INR但拥有此类资源的组织在创建EE证书时也充当CA。
This PKI does not require establishment or use of a registration authority (RA) function separate from the one provided inherently in conjunction with the CA function. The RA function MUST be provided by the same entity operating as a CA, e.g., entities listed in Section 1.3.1. An entity acting as a CA in this PKI already has a formal relationship with each organization to which it distributes INRs. These entities (the CAs) already perform the RA function implicitly since they already assume responsibility for distributing INRs.
此PKI不要求建立或使用注册机构（RA）功能，该功能与CA功能固有的功能分离。RA功能必须由与CA相同的实体提供，例如第1.3.1节中列出的实体。在该PKI中充当CA的实体已经与向其分发INR的每个组织建立了正式关系。这些实体（CA）已经隐式执行RA功能，因为它们已经承担了分发INR的责任。
These are the organizations receiving distributions of INRs: RIRs, NIRs, ISPs, and other organizations.
这些是接收INR分发的组织：RIR、NIR、ISP和其他组织。
Note that any of these organizations may have received distributions from more than one source over time. This is true even for RIRs, which participate in inter-registry exchanges of address space. This PKI accommodates such relationships.
请注意，随着时间的推移，这些组织中的任何一个都可能收到来自多个来源的分发。即使是参与地址空间的注册间交换的RIR也是如此。这种PKI适应了这种关系。
Entities or individuals that act in reliance on certificates or RPKI signed objects issued under this PKI are relying parties. Relying parties may or may not be subscribers within this PKI. (See Section 1.6 for the definition of an RPKI signed object.)
依赖根据本PKI颁发的证书或RPKI签名对象行事的实体或个人为依赖方。依赖方可能是也可能不是此PKI中的订户。（有关RPKI签名对象的定义，请参见第1.6节。）
Every organization that undertakes a role as a CA in this PKI is responsible for populating the RPKI distributed repository system with the certificates, CRLs, and RPKI signed objects that it issues. The organization MAY operate its own publication point, or it MAY outsource this function (see Sections 2.1 and 2.2).
在该PKI中担任CA角色的每个组织都负责向RPKI分布式存储库系统填充其颁发的证书、CRL和RPKI签名对象。组织可以运营自己的发布点，也可以外包该功能（见第2.1节和第2.2节）。
The certificates issued under this hierarchy are for authorization in support of validation of claims of current holdings of INRs.
根据该层次结构颁发的证书用于授权，以支持对印度卢比当前持有量的索赔进行验证。
Additional uses of the certificates, consistent with the basic goal cited above, also are permitted under this policy. For example, certificates may be issued in support of integrity and access control for the repository system described in Section 2.4. Such transitive uses are permitted under this policy.
根据本政策，符合上述基本目标的证书的其他用途也是允许的。例如，可以颁发证书以支持第2.4节中描述的存储库系统的完整性和访问控制。本政策允许此类过渡用途。
Any uses other than those described in Section 1.4.1 are prohibited under this policy.
本政策禁止第1.4.1节所述以外的任何用途。
This CP is administered by
本CP由以下人员管理：
Internet Engineering Steering Group c/o Internet Society 1775 Wiehle Avenue, Suite 201 Reston, VA 20190-5108 U.S.A.
互联网工程指导小组c/o互联网协会美国弗吉尼亚州雷斯顿市维勒大道1775号201室，邮编：20190-5108。
The contact information is
联系方式是
EMail: iesg@ietf.org
Phone: +1-703-439-2120 (Internet Society)
EMail: iesg@ietf.org
Phone: +1-703-439-2120 (Internet Society)
If a replacement BCP is needed that updates or obsoletes the current BCP, then the replacement BCP MUST be approved by the IESG following the procedures of the IETF Standards Process as defined in RFC 2026 [RFC2026].
如果需要更新或淘汰当前BCP的替换BCP，则替换BCP必须由IESG按照RFC 2026[RFC2026]中定义的IETF标准流程的程序批准。
CPS - Certification Practice Statement. A CPS is a document that specifies the practices that a Certification Authority (CA) employs in issuing certificates in this PKI.
CPS-认证实践声明。CPS是一份文件，规定了证书颁发机构（CA）在此PKI中颁发证书时采用的做法。
Distribution of INRs - A process of distribution of the INRs along the respective number hierarchy. IANA distributes blocks of IP addresses and AS numbers to the five Regional Internet Registries (RIRs). RIRs distribute smaller address blocks and AS numbers to organizations within their service regions, who in turn distribute IP addresses to their customers.
INR分布-INR沿相应数字层次分布的过程。IANA将IP地址块和AS编号分配给五个区域互联网注册中心（RIR）。RIR将较小的地址块和数字分发给其服务区域内的组织，这些组织反过来将IP地址分发给其客户。
IANA - Internet Assigned Numbers Authority. IANA is responsible for global coordination of the IP addressing system and AS numbers used for routing Internet traffic. IANA distributes INRs to Regional Internet Registries (RIRs).
IANA-互联网分配号码管理局。IANA负责IP寻址系统的全球协调，以及用于路由Internet流量的AS号码。IANA向区域互联网注册中心（RIR）分发INR。
INRs - Internet Number Resources. INRs are number values for three protocol parameter sets, namely:
INRs-互联网号码资源。INR是三个协议参数集的数值，即：
o IP version 4 addresses,
o IP版本4地址，
o IP version 6 addresses, and
o IP版本6地址，以及
o Identifiers used in Internet inter-domain routing, currently Border Gateway Protocol-4 AS numbers.
o 在Internet域间路由中使用的标识符，目前作为数字的边界网关协议-4。
ISP - Internet Service Provider. This is an organization managing and providing Internet services to other organizations.
互联网服务提供商。这是一个管理和向其他组织提供互联网服务的组织。
LIR - Local Internet Registry. In some regions, this term is used to refer to what is called an ISP in other regions.
LIR-本地互联网注册。在某些地区，该术语用于指代其他地区所称的ISP。
NIR - National Internet Registry. This is an organization that manages the distribution of INRs for a portion of the geopolitical area covered by a Regional Registry. NIRs form an optional second tier in the tree scheme used to manage INRs.
NIR-国家互联网注册处。这是一个管理区域登记所覆盖的部分地缘政治区域印度卢比分布的组织。NIR在用于管理INR的树形方案中形成可选的第二层。
RIR - Regional Internet Registry. This is an organization that manages the distribution of INRs for a geopolitical area.
RIR-区域互联网注册处。这是一个管理地缘政治区域印度卢比分布的组织。
RPKI signed object - An RPKI signed object is a digitally signed data object (other than a certificate or CRL) that is declared to be such by a Standards Track RFC, and that can be validated using certificates issued under this PKI. The content and format of these data constructs depend on the context in which validation of claims of current holdings of INRs takes place. Examples of these objects are repository manifests [RFC6486] and Route Origin Authorizations (ROAs) [RFC6482].
RPKI签名对象-RPKI签名对象是一个数字签名数据对象（证书或CRL除外），由标准跟踪RFC声明为数字签名数据对象，可以使用在此PKI下颁发的证书进行验证。这些数据结构的内容和格式取决于对目前持有的印度卢比的债权进行确认的背景。这些对象的示例包括存储库清单[RFC6486]和路由来源授权（ROA）[RFC6482]。
Certificates, CRLs, and RPKI signed objects (intended for public consumption) MUST be made available for downloading by all relying parties, to enable them to validate this data. This motivates use of a robust, distributed repository system. Each CA MUST maintain a publicly accessible online repository and publish all RPKI-signed objects (intended for public consumption) via this repository in a manner that conforms with "A Profile for Resource Certificate Repository Structure" [RFC6481]. (This function MAY be outsourced, as noted in Section 2.2 below.) The collection of repositories forms the RPKI distributed repository system.
证书、CRL和RPKI签名对象（供公众使用）必须可供所有依赖方下载，以使其能够验证此数据。这促使人们使用健壮的分布式存储库系统。每个CA必须维护一个可公开访问的在线存储库，并通过该存储库以符合“资源证书存储库结构配置文件”的方式发布所有RPKI签名对象（供公众使用）[RFC6481]。（如下面第2.2节所述，此功能可外包。）存储库集合构成RPKI分布式存储库系统。
Each CA MUST publish the certificates (intended for public consumption) that it issues via the repository system.
每个CA必须发布其通过存储库系统发布的证书（供公众使用）。
Each CA MUST publish the CRLs (intended for public consumption) that it issues via the repository system.
每个CA必须发布其通过存储库系统发布的CRL（供公众使用）。
Each CA MUST publish its RPKI signed objects (intended for public consumption) via the repository system.
每个CA必须通过存储库系统发布其RPKI签名的对象（供公众使用）。
Each CA that issues certificates to entities outside of its administrative domain SHOULD create and publish a CPS that meets the requirements set forth in this CP. Publication means that the entities to which the CA issues certificates MUST be able to acquire a copy of the CPS, and MUST be able to ascertain when the CPS changes. (An organization that does not allocate or assign INRs does not need to create or publish a CPS.)
向其管理域以外的实体颁发证书的每个CA应创建并发布符合本CP中规定要求的CP。发布意味着CA向其颁发证书的实体必须能够获得CP的副本，并且必须能够确定CP何时更改。（不分配或分配INR的组织不需要创建或发布CPS。）
An organization MAY choose to outsource publication of RPKI data -- certificates, CRLs, and other RPKI signed objects.
组织可以选择外包RPKI数据的发布——证书、CRL和其他RPKI签名对象。
The CP will be published as an IETF-stream RFC and will be available from the RFC repository.
CP将作为IETF流RFC发布，并可从RFC存储库获得。
The CPS for each CA MUST specify the following information:
每个CA的CP必须指定以下信息：
The period of time within which a certificate will be published after the CA issues the certificate.
CA颁发证书后发布证书的时间段。
The period of time within which a CA will publish a CRL with an entry for a revoked certificate after it revokes that certificate.
CA在撤销已撤销证书后，发布带有已撤销证书条目的CRL的时间段。
Expired and revoked certificates SHOULD be removed from the RPKI repository system, upon expiration or revocation, respectively. Also, please note that each CA MUST publish its CRL prior to the nextUpdate value in the scheduled CRL previously issued by the CA.
过期和吊销的证书应分别在到期或吊销时从RPKI存储库系统中删除。此外，请注意，每个CA必须在CA先前发布的计划CRL中的nextUpdate值之前发布其CRL。
Each CA or repository operator MUST implement access controls to prevent unauthorized persons from adding, modifying, or deleting repository entries. A CA or repository operator MUST NOT intentionally use technical means of limiting read access to its CPS, certificates, CRLs, or RPKI signed objects. This data is intended to be accessible to the public.
每个CA或存储库操作员必须实施访问控制，以防止未经授权的人员添加、修改或删除存储库条目。CA或存储库操作员不得故意使用技术手段限制对其CP、证书、CRL或RPKI签名对象的读取访问。这些数据旨在供公众查阅。
The distinguished name for every CA and end-entity consists of a single CommonName (CN) attribute with a value generated by the issuer of the certificate. Optionally, the serialNumber attribute MAY be included along with the common name (to form a terminal relative distinguished name set), to distinguish among successive instances of certificates associated with the same entity.
每个CA和最终实体的可分辨名称由单个CommonName（CN）属性组成，该属性的值由证书颁发者生成。可选地，serialNumber属性可以与公共名称一起包括（以形成终端相对可分辨名称集），以区分与同一实体关联的证书的连续实例。
The subject name in each certificate SHOULD NOT be "meaningful", i.e., the name is not intended to convey the identity of the subject to relying parties. The rationale here is that certificates issued under this PKI are used for authorization in support of applications that make use of attestations of INR holdings. They are not used to identify subjects.
每份证书中的主体名称不应具有“意义”，即该名称并非旨在向依赖方传达主体的身份。这里的理由是，根据本PKI颁发的证书用于授权，以支持使用INR持有证明的应用。它们不用于识别受试者。
Although subject (and issuer) names need not be meaningful, and may appear "random," anonymity is not a function of this PKI; thus, no explicit support for this feature is provided.
虽然主题（和发行人）名称不需要有意义，并且可能看起来是“随机的”，但匿名性不是此PKI的功能；因此，没有提供对此功能的明确支持。
None.
没有一个
There is no guarantee that subject names are globally unique in this PKI. Each CA certifies subject names that MUST be unique among the certificates it issues. Although it is desirable that these subject names be unique throughout the PKI, name uniqueness within the RPKI cannot be guaranteed.
无法保证主题名称在此PKI中是全局唯一的。每个CA都认证其颁发的证书中必须唯一的主题名称。虽然希望这些主题名称在整个PKI中是唯一的，但无法保证RPKI中的名称唯一性。
However, subject names in certificates SHOULD be constructed in a way that minimizes the chances that two entities in the RPKI will be assigned the same name. The RPKI Certificate Profile [RFC6487] provides an example of how to generate (meaningless) subject names in a way that minimizes the likelihood of collisions.
但是，证书中的主体名称的构造方式应尽量减少RPKI中两个实体被分配相同名称的可能性。RPKI证书配置文件[RFC6487]提供了一个示例，说明如何以最小化冲突可能性的方式生成（无意义的）主题名称。
Each CA operating within the context of this PKI MUST require each subject to demonstrate proof of possession (PoP) of the private key corresponding to the public key in the certificate, prior to issuing the certificate. The means by which PoP is achieved is determined by each CA and MUST be declared in the CPS of that CA.
在本PKI环境下运行的每个CA必须要求每个主体在颁发证书之前，证明拥有证书中公钥对应的私钥（PoP）。实现PoP的方法由每个CA确定，并且必须在该CA的CPS中声明。
Each CA operating within the context of this PKI MUST employ procedures to ensure that each certificate it issues accurately reflects its records with regard to the organization to which the CA has distributed the INRs identified in the certificate. The specific procedures employed for this purpose MUST be described by the CPS for each CA. Relying parties can expect each CA to employ procedures commensurate with those it already employs as a registry or ISP in the management of the INRs. This authentication is solely for use by each CA in dealing with the organizations to which it distributes INRs, and thus should not be relied upon outside of this CA-subscriber relationship.
在本PKI环境下运行的每个CA必须采用程序，以确保其颁发的每个证书准确反映其关于CA已向其分发证书中标识的INR的组织的记录。CPS必须为每个CA说明为此目的采用的具体程序。依赖方可以期望每个CA采用与其在INR管理中已经作为注册中心或ISP使用的程序相称的程序。此身份验证仅供各CA在处理其向其分发INR的组织时使用，因此不应依赖于此CA订户关系之外的身份验证。
Each CA operating within the context of this PKI MUST employ procedures to identify at least one individual as a representative of each organization that is an INR holder. The specific means by which each CA authenticates individuals as representatives for an organization MUST be described by the CPS for each CA. Relying parties can expect each CA to employ procedures commensurate with those it already employs as a registry or ISP in authenticating individuals as representatives for INR holders.
在本PKI背景下运营的每个CA必须采用程序，以确定至少一个人作为INR持有人的每个组织的代表。每个CA认证个人为组织代表的具体方式必须由每个CA的CPS描述。依赖方可以期望每个CA在认证个人为INR持有人代表时，采用与其已经作为注册中心或ISP使用的程序相称的程序。
A CA MUST NOT include any non-verified subscriber data in certificates issued under this certificate policy except for Subject Information Access (SIA) extensions.
CA不得在根据此证书策略颁发的证书中包含任何未经验证的订户数据，但主题信息访问（SIA）扩展除外。
Each CA operating within the context of this PKI MUST employ procedures to verify that an individual claiming to represent an organization to which a certificate is issued is authorized to represent that organization in this context. The procedures MUST be described by the CPS for the CA. Relying parties can expect each CA to employ procedures commensurate with those it already employs as a registry or ISP, in authenticating individuals as representatives for INR holders.
在本PKI上下文中运行的每个CA必须采用程序来验证声称代表向其颁发证书的组织的个人是否有权在此上下文中代表该组织。CPS必须对CA的程序进行说明。依赖方可以期望每个CA在认证个人作为INR持有人代表时，采用与其已作为注册中心或ISP使用的程序相称的程序。
This PKI is neither intended nor designed to interoperate with any other PKI.
此PKI既不是为了也不是为了与任何其他PKI互操作而设计的。
Each CA operating within the context of this PKI MUST employ procedures to ensure that an organization requesting a re-key is the legitimate holder of the certificate to be re-keyed and the associated INRs, and MUST require PoP of the private key corresponding to the new public key. The procedures employed for these purposes MUST be described in the CPS for the CA. With respect to authentication of the holder of the INRs, relying parties can expect each CA to employ procedures commensurate with those it already employs as a registry or ISP, in the management of INRs.
在该PKI环境下运行的每个CA必须采用程序，以确保请求重新加密的组织是要重新加密的证书和相关INR的合法持有人，并且必须要求与新公钥对应的私钥的PoP。CA的CPS中必须说明用于这些目的的程序。关于INR持有人的认证，依赖方可以期望每个CA在管理INR时采用与其已作为注册中心或ISP使用的程序相称的程序。
Note: An issuer MAY choose to require periodic re-keying consistent with contractual agreements with the recipient. If so, this MUST be described by the CPS for the CA.
注：发行人可选择要求与接收方的合同协议一致的定期密钥更新。如果是这样，则CA的CPS必须对此进行说明。
Each CA operating within the context of this PKI MUST employ procedures to ensure that an organization requesting a re-key after revocation is the same entity to which the revoked certificate was issued and is the legitimate holder of the associated INR. The CA MUST require PoP of the private key corresponding to the new public key. The specific procedures employed for these purposes MUST be described by the CPS for the CA. With respect to authentication of the holder of the INRs, relying parties can expect each CA to employ procedures commensurate with those it already employs as a registry or ISP, in the management of INRs. Note that there MAY be different procedures for the case where the legitimate subject still possesses the original private key as opposed to the case when it no longer has access to that key.
在本PKI环境下运行的每个CA必须采用程序，以确保在撤销后请求重新密钥的组织是向其颁发被撤销证书的同一实体，并且是相关INR的合法持有人。CA必须要求与新公钥对应的私钥的PoP。CPS必须为CA说明用于这些目的的具体程序。关于INR持有人的认证，依赖方可以期望每个CA在管理INR时采用与其已作为注册中心或ISP使用的程序相称的程序。请注意，对于合法主体仍然拥有原始私钥的情况，可能会有不同的程序，而不是当合法主体不再能够访问该私钥时。
Each CA operating within the context of this PKI MUST employ procedures to ensure that:
在本PKI环境下运行的每个CA必须采用程序确保：
o an organization requesting revocation is the legitimate holder of the certificate to be revoked.
o 请求撤销的组织是要撤销的证书的合法持有人。
o each certificate it revokes accurately reflects its records with regard to the organization to which the CA has distributed the INRs identified in the certificate.
o 其撤销的每一份证书都准确反映了其与CA向其分发证书中标识的INR的组织相关的记录。
o an individual claiming to represent an organization for which a certificate is to be revoked is authorized to represent that organization in this context.
o 声称代表将被吊销证书的组织的个人有权在此上下文中代表该组织。
The specific procedures employed for these purposes MUST be described by the CPS for the CA. Relying parties can expect each CA to employ procedures commensurate with those it already employs as a registry or ISP, in the management of INRs.
CPS必须为CA描述用于这些目的的具体程序。依赖方可以期望每个CA在INR的管理中采用与其已作为注册中心或ISP使用的程序相称的程序。
Any entity that distributes INRs SHOULD acquire a certificate. This includes Internet Registries and ISPs. Additionally, entities that hold INRs from an Internet Registry, or that are multi-homed, MAY acquire a certificate under this PKI. The (CA) certificates issued to these entities MUST include one or both of the extensions defined by RFC 3779 [RFC3779], "X.509 Extensions for IP Addresses and AS Identifiers", as appropriate.
分发INR的任何实体都应获得证书。这包括互联网注册处和ISP。此外，从互联网注册处持有INR的实体，或多址实体，可以获得此PKI下的证书。颁发给这些实体的（CA）证书必须包括RFC 3779[RFC3779]定义的一个或两个扩展，“IP地址和AS标识符的X.509扩展”，视情况而定。
The application procedure MUST be described in the CPS for each CA.
每个CA的CPS中必须说明申请程序。
The enrollment process and procedures MUST be described by the CPS for each CA. An entity that desires one or more certificates should contact the organization from which it receives its INRs.
CPS必须为每个CA描述注册流程和程序。需要一个或多个证书的实体应联系接收其INR的组织。
CAs SHOULD make use of existing standards for certificate application processing. Section 6 of the Resource Certificate Profile [RFC6487] defines the standard certificate request formats that MUST be supported.
核证机关应利用现有的证书申请处理标准。资源证书配置文件[RFC6487]的第6节定义了必须支持的标准证书请求格式。
Each CA MUST define via its CPS, the certificate request/response standards that it employs.
每个CA必须通过其CPS定义其采用的证书请求/响应标准。
Existing practices employed by registries and ISPs to identify and authenticate organizations that receive INRs form the basis for issuance of certificates to these subscribers. It is important to note that the Resource PKI SHOULD NOT be used to authenticate the identity of an organization, but rather to bind subscribers to the INRs they hold. Because identity is not being vouched for by this PKI, certificate application procedures need not verify legal organization names, etc.
登记处和ISP用于识别和认证接收INR的组织的现有做法构成了向这些用户颁发证书的基础。需要注意的是，资源PKI不应用于验证组织的身份，而应用于将订阅者绑定到他们持有的INR。由于此PKI不提供身份证明，因此证书申请程序无需验证合法组织名称等。
Certificate applications MUST be approved based on the normal business practices of the entity operating the CA, based on the CA's records of INR holders. Each CA MUST follow the procedures specified
证书申请必须根据CA运营实体的正常商业惯例，根据CA的INR持有人记录进行批准。每个CA必须遵循指定的程序
in Section 3.2.1 to verify that the requester holds the private key corresponding to the public key that will be bound to the certificate the CA issues to the requester. The details of how certificate applications are approved MUST be described in the CPS for the CA in question.
在第3.2.1节中，验证请求者是否持有与将绑定到CA颁发给请求者的证书的公钥相对应的私钥。证书申请如何批准的详细信息必须在相关CA的CPS中说明。
No stipulation. As part of its CPS, each CA MUST declare its expected time frame to process (approve, issue, and publish) a certificate application.
没有规定。作为其CPS的一部分，每个CA必须声明其处理（批准、颁发和发布）证书申请的预期时间范围。
If a CA determines that the request is acceptable, it MUST issue the corresponding certificate and publish it in the RPKI distributed repository system via publication of the certificate at the CA's repository publication point.
如果CA确定请求是可接受的，则必须颁发相应的证书，并通过在CA的存储库发布点发布证书，将其发布到RPKI分布式存储库系统中。
The CA MUST notify the subscriber when the certificate is published. The means by which a subscriber is notified MUST be defined by each CA in its CPS.
CA必须在证书发布时通知订阅服务器。通知订户的方式必须由每个CA在其CP中定义。
Within the timeframe specified in its CPS, the CA MUST place the certificate in the repository and notify the subscriber. This MAY be done without subscriber review and acceptance. Each CA MUST state in its CPS the procedures it follows for publishing of the certificate and notification to the subscriber.
在其CPS中指定的时间范围内，CA必须将证书放入存储库并通知订阅者。这可以在没有订户审查和验收的情况下完成。每个CA必须在其CPS中说明其发布证书和通知订户所遵循的程序。
Certificates MUST be published in the RPKI distributed repository system via publication of the certificate at the CA's repository publication point as per the conduct described in Section 4.4.1. The procedures for publication MUST be defined by each CA in its CPS.
必须按照第4.4.1节所述的行为，通过在CA的存储库发布点发布证书，在RPKI分布式存储库系统中发布证书。每个CA必须在其CPS中定义发布程序。
The CPS of each CA MUST indicate whether any other entities will be notified when a certificate is issued.
每个CA的CP必须指明在颁发证书时是否会通知任何其他实体。
A summary of the use model for the RPKI is provided below.
下面提供了RPKI使用模型的摘要。
Each holder of an INR is eligible to request an X.509 [X.509] CA certificate containing appropriate RFC 3779 extensions. Holders of CA resource certificates also MAY issue EE certificates to themselves to enable verification of RPKI signed objects that they generate.
INR的每位持有人都有资格申请包含适当RFC 3779扩展的X.509[X.509]CA证书。CA资源证书的持有者还可以向自己颁发EE证书，以便能够验证他们生成的RPKI签名对象。
Reliance on a certificate must be reasonable under the circumstances. If the circumstances indicate a need for additional assurances, the relying party must obtain such assurances in order for such reliance to be deemed reasonable.
在这种情况下，对证书的依赖必须是合理的。如果情况表明需要额外的保证，依赖方必须获得这种保证，才能认为这种依赖是合理的。
Before any act of reliance, relying parties MUST independently (1) verify that the certificate will be used for an appropriate purpose that is not prohibited or otherwise restricted by this CP (see Section 1.4), and (2) assess the status of the certificate and all the certificates in the chain (terminating at a trust anchor (TA) accepted by the RP) that issued the certificates relevant to the certificate in question. If any of the certificates in the certificate chain have been revoked or have expired, the relying party is solely responsible for determining whether reliance on a digital signature to be verified by the certificate in question is acceptable. Any such reliance is made solely at the risk of the relying party.
在任何依赖行为之前，依赖方必须独立（1）验证证书将用于本CP未禁止或限制的适当目的（见第1.4节），以及（2）评估证书和链中所有证书的状态（终止于RP接受的信托锚（TA））颁发了与所涉证书相关的证书。如果证书链中的任何证书已被吊销或已过期，依赖方应全权负责确定是否可接受依赖待由相关证书验证的数字签名。任何此类信赖仅由信赖方承担风险。
If a relying party determines that use of the certificate is appropriate, the relying party must utilize appropriate software and/or hardware to perform digital signature verification as a condition of relying on the certificate. Moreover, the relying party MUST validate the certificate in a manner consistent with the RPKI Certificate Profile [RFC6487], which specifies the extended validation algorithm for RPKI certificates.
如果依赖方确定证书的使用是适当的，则依赖方必须使用适当的软件和/或硬件来执行数字签名验证，作为依赖证书的一个条件。此外，依赖方必须以与RPKI证书配置文件[RFC6487]一致的方式验证证书，该文件指定了RPKI证书的扩展验证算法。
This section describes the procedures for certificate renewal. Certificate renewal is the issuance of a new certificate to replace an old one prior to its expiration. Only the validity dates and the serial number (the field in the certificate, not the DN attribute) are changed. The public key and all other information remain the same.
本节介绍证书续订的过程。证书更新是指在旧证书到期之前签发新证书以替换旧证书。仅更改有效日期和序列号（证书中的字段，而不是DN属性）。公钥和所有其他信息保持不变。
A certificate MUST be processed for renewal based on its expiration date or a renewal request from the subscriber. Prior to the expiration of an existing subscriber's certificate, it is the responsibility of the subscriber to renew the certificate to maintain continuity of certificate usage. If the issuing CA initiates the renewal process based on the certificate expiration date, then that CA MUST notify the holder in advance of the renewal process. The validity interval of the new (renewed) certificate SHOULD overlap that of the previous certificate to ensure continuity of certificate usage. It is RECOMMENDED that the renewed certificate be issued and published at least 1 week prior to the expiration of the certificate it replaces.
必须根据证书的到期日期或订阅者的续订请求处理证书以进行续订。在现有用户证书到期之前，用户有责任更新证书以保持证书使用的连续性。如果颁发证书的CA根据证书到期日启动续订流程，则该CA必须在续订流程之前通知持有人。新（续订）证书的有效期间隔应与以前证书的有效期间隔重叠，以确保证书使用的连续性。建议在更换的证书到期前至少1周颁发和发布更新的证书。
Certificate renewal SHOULD incorporate the same public key as the previous certificate, unless the private key has been reported as compromised. If a new key pair is being used, the stipulations of Section 4.7 apply.
证书续订应包含与上一个证书相同的公钥，除非私钥已被报告为泄露。如果正在使用新的密钥对，则第4.7节的规定适用。
Only the certificate holder or the issuing CA may initiate the renewal process. The certificate holder MAY request an early renewal, for example, if it expects to be unavailable to support the renewal process during the normal expiration period. An issuing CA MAY initiate the renewal process based on the certificate expiration date.
只有证书持有人或颁发证书的CA可以启动续订流程。例如，如果证书持有人预计在正常到期期间无法支持续期过程，则可以请求提前续期。颁发CA可以根据证书到期日期启动续订过程。
Renewal procedures MUST ensure that the person or organization seeking to renew a certificate is in fact the subscriber (or authorized by the subscriber) of the certificate and the legitimate holder of the INR associated with the renewed certificate. Renewal processing MUST verify that the certificate in question has not been revoked.
更新程序必须确保寻求更新证书的个人或组织实际上是证书的认购人（或认购人授权的人）以及与更新证书相关的INR的合法持有人。续订处理必须验证相关证书是否已被吊销。
No additional stipulations beyond those of Section 4.3.2.
除第4.3.2节规定外，无其他规定。
No additional stipulations beyond those of Section 4.4.1.
除第4.4.1节规定外，无其他规定。
No additional stipulations beyond those of Section 4.4.2.
除第4.4.2节规定外，无其他规定。
No additional stipulations beyond those of Section 4.4.3.
除第4.4.3节规定外，无其他规定。
This section describes the procedures for certificate re-key. Certificate re-key is the issuance of a new certificate to replace an old one because the key needs to be replaced. Unlike with certificate renewal, the public key is changed.
本节介绍证书重设密钥的过程。证书重设密钥是指颁发新证书以替换旧证书，因为需要替换密钥。与证书续订不同，公钥是更改的。
Re-key of a certificate SHOULD be performed only when required, based on:
仅当需要时，才应根据以下条件对证书重新设置密钥：
1. knowledge or suspicion of compromise or loss of the associated private key, or
1. 知道或怀疑相关私钥泄露或丢失，或
2. the expiration of the cryptographic lifetime of the associated key pair
2. 关联密钥对的加密生存期到期
A CA re-key operation has dramatic consequences, requiring the reissuance of all certificates issued by the re-keyed entity. So it should be performed only when necessary and in a way that preserves the ability of relying parties to validate certificates whose validation path includes the re-keyed entity. CA key rollover MUST follow the procedures defined in "CA Key Rollover in the RPKI" [RFC6489].
CA重新设置密钥操作会产生巨大的后果，需要重新颁发由重新设置密钥的实体颁发的所有证书。因此，只有在必要时才应执行此操作，并以保持依赖方验证其验证路径包括重新设置密钥的实体的证书的能力的方式执行。CA密钥翻转必须遵循“RPKI中的CA密钥翻转”[RFC6489]中定义的程序。
Note that if a certificate is revoked to replace the RFC 3779 extensions, the replacement certificate MUST incorporate the same public key rather than a new key. This applies when one is adding INRs (revocation not required) and when one is removing INRs (revocation required (see Section 4.8.1)).
请注意，如果吊销证书以替换RFC 3779扩展，则替换证书必须包含相同的公钥，而不是新密钥。这适用于添加INR（不需要撤销）和删除INR（需要撤销（见第4.8.1节））。
If the re-key is based on a suspected compromise, then the previous certificate MUST be revoked.
如果重新密钥基于可疑的泄露，则必须吊销以前的证书。
The holder of the certificate may request a re-key. In addition, the CA that issued the certificate MAY choose to initiate a re-key based on a verified compromise report.
证书持有人可以请求重新加密。此外，颁发证书的CA可以根据已验证的泄露报告选择启动重新密钥。
The re-key process follows the general procedures of certificate generation as defined in Section 4.3.
密钥更新过程遵循第4.3节中定义的证书生成的一般程序。
No additional stipulations beyond those of Section 4.3.2.
除第4.3.2节规定外，无其他规定。
No additional stipulations beyond those of Section 4.4.1.
除第4.4.1节规定外，无其他规定。
No additional stipulations beyond those of Section 4.4.2.
除第4.4.2节规定外，无其他规定。
No additional stipulations beyond those of Section 4.4.3.
除第4.4.3节规定外，无其他规定。
Modification of a certificate occurs to implement changes to selected attribute values in a certificate. In the context of the RPKI, the only changes that are accommodated by certificate modification are changes to the INR holdings described by the RFC 3779 extension(s) and changes to the SIA extension.
修改证书是为了实现对证书中选定属性值的更改。在RPKI的背景下，证书修改所适应的唯一变化是RFC 3779扩展描述的INR持有量变化和SIA扩展的变化。
When a certificate modification is approved, a new certificate is issued. If no INR holdings are removed from the certificate, the new certificate MUST contain the same public key and the same expiration date as the original certificate, but with the SIA extension and/or the INR set expanded. In this case, revocation of the previous certificate is not required.
批准证书修改后，将颁发新证书。如果没有从证书中删除INR持有，则新证书必须包含与原始证书相同的公钥和相同的到期日期，但SIA扩展和/或INR集已扩展。在这种情况下，不需要撤销以前的证书。
When previously distributed INRs are removed from a certificate, then the old certificate MUST be revoked and a new certificate MUST be issued, reflecting the changed INR holdings. (The SIA extension in the new certificate will be unchanged, unless the affected INR holder supplies a new SIA value.)
当从证书中删除以前分发的INR时，必须撤销旧证书并颁发新证书，以反映已更改的INR持有量。（新证书中的SIA扩展将保持不变，除非受影响的INR持有人提供新的SIA值。）
Either the certificate holder or the issuer may initiate the certificate modification process.
证书持有人或颁发者均可启动证书修改过程。
The CA MUST determine that the requested modification is appropriate and that the procedures for the issuance of a new certificate are followed (see Section 4.3).
CA必须确定所请求的修改是适当的，并遵循新证书的颁发程序（见第4.3节）。
No additional stipulations beyond those of Section 4.3.2.
除第4.3.2节规定外，无其他规定。
No additional stipulations beyond those of Section 4.4.1.
除第4.4.1节规定外，无其他规定。
No additional stipulations beyond those of Section 4.4.2.
除第4.4.2节规定外，无其他规定。
No additional stipulations beyond those of Section 4.4.3.
除第4.4.3节规定外，无其他规定。
A certificate MUST be revoked (and published on a CRL) if there is reason to believe that there has been a compromise of a subscriber's private key. A certificate also MAY be revoked to invalidate a data object signed by the private key associated with that certificate. Other circumstances that justify revocation of a certificate MAY be specified in a CA's CPS.
如果有理由相信订阅者的私钥已被泄露，则必须撤销证书（并在CRL上发布）。还可以吊销证书以使由与该证书相关联的私钥签名的数据对象无效。CA的CPS中可能规定了证明撤销证书合理的其他情况。
Note: If new INRs are being added to an organization's existing distribution, the old certificate need not be revoked. Instead, a new certificate MAY be issued with both the old and the new resources and the old key. If INRs are being removed or if there has been a key compromise, then the old certificate MUST be revoked (and a re-key MUST be performed in the event of key compromise).
注意：如果将新的INR添加到组织的现有分发中，则无需撤销旧证书。相反，可以使用旧资源和新资源以及旧密钥颁发新证书。如果正在删除INR或存在密钥泄露，则必须撤销旧证书（并且在密钥泄露的情况下必须执行重新密钥）。
This MUST be defined in the CPS of the organization that issued the certificate.
这必须在颁发证书的组织的CPS中定义。
A subscriber MAY submit a request to the certificate issuer for a revocation. This request MUST identify the certificate to be revoked and MUST be authenticated. The procedures for making the request MUST be described in the CPS for each CA. The RPKI provisioning document [RFC6492] describes a protocol that MAY be used to make revocation requests.
订阅者可以向证书颁发者提交撤销请求。此请求必须标识要吊销的证书，并且必须经过身份验证。每个CA的CPS中必须说明发出请求的程序。RPKI供应文档[RFC6492]描述了可用于发出撤销请求的协议。
A certificate issuer MUST notify the subscriber when revoking a certificate. The notification requirement is satisfied by CRL publication. The CPS for a CA MUST indicate the means by which the CA will inform a subscriber of certificate revocation.
证书颁发者在撤销证书时必须通知订阅方。CRL出版物满足通知要求。CA的CP必须指明CA通知订阅者证书撤销的方式。
A subscriber SHOULD request revocation as soon as possible after the need for revocation has been identified. There is no specified grace period for the subscriber in this process.
用户应在确定需要撤销后尽快请求撤销。在此过程中，没有为订阅服务器指定宽限期。
No stipulation. Each CA SHOULD specify its expected revocation processing time in its CPS.
没有规定。每个CA应在其CP中指定其预期撤销处理时间。
A relying party MUST acquire and check the most recent, scheduled CRL from the issuer of the certificate, whenever the relying party validates a certificate.
每当依赖方验证证书时，依赖方必须从证书颁发者处获取并检查最新的预定CRL。
The CRL issuance frequency MUST be determined by each CA and stated in its CPS. Each CRL carries a nextScheduledUpdate value, and a new CRL MUST be published at or before that time. A CA MUST set the nextUpdate value when it issues a CRL to signal when the next scheduled CRL will be issued.
CRL发行频率必须由各CA确定，并在其CPS中说明。每个CRL都带有nextScheduledUpdate值，并且必须在该时间或之前发布新的CRL。CA必须在发出CRL时设置nextUpdate值，以指示下一个计划CRL将在何时发出。
The CPS for each CA MUST specify the maximum latency associated with posting its CRL to the repository system.
每个CA的CP必须指定将其CRL发布到存储库系统的最大延迟。
This PKI does not make provision for use of the Online Certificate Status Protocol (OCSP) [RFC2560] or Server-Based Certificate Validation Protocol (SCVP) [RFC5055]. This is because it is anticipated that the primary RPs (ISPs) will acquire and validate certificates for all participating resource holders. These protocols are not designed for such large-scale, bulk certificate status checking. RPs MUST check for new CRLs at least daily. It is RECOMMENDED that RPs perform this check several times per day, but no more than 8-12 times per day (to avoid excessive repository accesses).
本PKI未规定使用在线证书状态协议（OCSP）[RFC2560]或基于服务器的证书验证协议（SCVP）[RFC5055]。这是因为预计主要RPs（ISP）将获取并验证所有参与资源持有者的证书。这些协议不是为大规模、批量证书状态检查而设计的。RPs必须至少每天检查新的CRL。建议RPs每天执行几次此检查，但每天不超过8-12次（以避免过度访问存储库）。
Each CA MUST maintain physical security controls for its operation that are commensurate with those employed by the organization in the management of INR distribution. The physical controls employed for CA operation MUST be specified in its CPS. Possible topics to be covered in the CPS are shown below. (These sections are taken from [RFC3647].)
每个CA必须为其运营维护物理安全控制，该控制与组织在INR分销管理中使用的控制相称。CA操作所采用的物理控制必须在其CPS中规定。CPS中可能涉及的主题如下所示。（这些章节摘自[RFC3647]。）
Each CA MUST maintain procedural security controls that are commensurate with those employed by the organization in the management of INR distribution. The procedural security controls employed for CA operation MUST be specified in its CPS. Possible topics to be covered in the CPS are shown below. (These sections are taken from [RFC3647].)
各CA必须维持与组织在INR分配管理中所采用的程序安全控制相称的程序安全控制。CA操作所采用的程序安全控制必须在其CPS中规定。CPS中可能涉及的主题如下所示。（这些章节摘自[RFC3647]。）
Each CA MUST maintain personnel security controls that are commensurate with those employed by the organization in the management of INR distribution. The details for each CA MUST be specified in its CPS.
各CA必须维持与组织在INR分配管理中雇用的人员相称的人员安全控制。每个CA的详细信息必须在其CPS中指定。
Details of how a CA implements the audit logging described in Sections 5.4.1 to 5.4.8 MUST be addressed in its CPS.
CA如何实施第5.4.1节至第5.4.8节中所述的审计日志记录的详细信息必须在其CPS中说明。
Audit records MUST be generated for the basic operations of the certification authority computing equipment. Audit records MUST include the date, time, responsible user or process, and summary content data relating to the event. Auditable events include:
必须为认证机构计算设备的基本操作生成审核记录。审核记录必须包括日期、时间、负责用户或流程，以及与事件相关的摘要内容数据。可审核事件包括：
o Access to CA computing equipment (e.g., logon, logout)
o 访问CA计算设备（例如登录、注销）
o Messages received requesting CA actions (e.g., certificate requests, certificate revocation requests, compromise notifications)
o 收到请求CA操作的消息（例如，证书请求、证书撤销请求、泄露通知）
o Certificate creation, modification, revocation, or renewal actions
o 证书创建、修改、吊销或续订操作
o Posting of any material to a repository
o 将任何材料过帐到存储库
o Any attempts to change or delete audit data
o 任何更改或删除审核数据的尝试
o Key generation
o 密钥生成
o Software and/or configuration updates to the CA
o CA的软件和/或配置更新
o Clock adjustments
o 时钟调整
Each CA MUST establish its own procedures for review of audit logs.
每个CA必须建立自己的审核日志审核程序。
Each CA MUST establish its own polices for retention of audit logs.
每个CA必须为保留审核日志制定自己的策略。
The audit log SHOULD be protected based on current industry standards.
应根据当前行业标准保护审核日志。
The audit log SHOULD be backed up based on current industry standards.
应根据当前行业标准备份审核日志。
The RPKI subsystems of a registry or ISP SHOULD participate in any vulnerability assessments that these organizations run as part of their normal business practice.
注册中心或ISP的RPKI子系统应参与这些组织作为其正常业务实践的一部分运行的任何漏洞评估。
When a CA wishes to change keys, it MUST acquire a new certificate containing its new public key. See [RFC6489] for a description of how key changeover is effected in the RPKI.
当CA希望更改密钥时，它必须获取包含其新公钥的新证书。请参阅[RFC6489]了解RPKI中密钥转换是如何实现的。
In the RPKI, each subscriber acts as a CA for the specified INRs that were distributed to that entity. Procedures associated with the termination of a CA MUST be described in the CPS for that CA. These procedures MUST include a provision to notify each entity that issued a certificate to the organization that is operating the CA that is terminating.
在RPKI中，每个订户充当分配给该实体的指定INR的CA。与CA终止相关的程序必须在该CA的CPS中说明。这些程序必须包括通知向运营终止CA的组织颁发证书的每个实体的规定。
Since the RA function MUST be provided by the same entity operating as the CA (see Section 1.3.2), there are no separate stipulations for RAs.
由于RA功能必须由与CA运营的同一实体提供（见第1.3.2节），因此RAs没有单独的规定。
The organizations that distribute INRs to network subscribers are authoritative for these distributions. This PKI is designed to enable ISPs and network subscribers to demonstrate that they are the holders of the INRs that have been distributed to them. Accordingly, the security controls used by CAs and subscribers for this PKI need only to be as secure as those that apply to the procedures for administering the distribution of INR data by the extant
向网络用户分发INR的组织对这些分发具有权威性。该PKI旨在使ISP和网络用户能够证明他们是已分发给他们的INR的持有人。因此，CA和订户为此PKI使用的安全控制只需与适用于管理现有用户分发INR数据的程序的安全控制一样安全
organizations. Details of each CA's security controls MUST be described in the CPS issued by the CA.
组织。每个CA的安全控制细节必须在CA发布的CPS中描述。
In most instances, public key pairs will be generated by the subject, i.e., the organization receiving the distribution of INRs. However, some CAs MAY offer to generate key pairs on behalf of their subjects at the request of the subjects, e.g., to accommodate subscribers who do not have the ability to perform key generation in a secure fashion. (The CA has to check the quality of the keys only if it generates them; see Section 6.1.6.) Since the keys used in this PKI are not for non-repudiation purposes, generation of key pairs by CAs does not inherently undermine the security of the PKI. Each CA MUST describe its key pair generation procedures in its CPS.
在大多数情况下，公钥对将由主体生成，即接收INR分发的组织。然而，一些ca可在主题的请求下提供代表其主题生成密钥对，例如，以容纳没有能力以安全方式执行密钥生成的订户。（CA只有在生成密钥时才必须检查密钥的质量；请参见第6.1.6节。）由于此PKI中使用的密钥并非用于不可否认性目的，因此CA生成密钥对不会从本质上破坏PKI的安全性。每个CA必须在其CP中描述其密钥对生成过程。
If a CA provides key pair generation services for subscribers, its CPS MUST describe the means by which private keys are delivered to subscribers in a secure fashion.
如果CA为订户提供密钥对生成服务，则其CP必须描述以安全方式向订户交付私钥的方式。
When a public key is transferred to the issuing CA to be certified, it MUST be delivered through a mechanism ensuring that the public key has not been altered during transit and that the subscriber possesses the private key corresponding to the transferred public key.
当公钥被传输到要认证的颁发CA时，必须通过一种机制来传递公钥，该机制确保公钥在传输过程中没有被更改，并且订户拥有与传输的公钥对应的私钥。
CA public keys for all entities (other than trust anchors) are contained in certificates issued by other CAs. These certificates MUST be published in the RPKI distributed repository system. Relying parties download these certificates from the repositories. Public key values and associated data for (putative) trust anchors are distributed out of band and accepted by relying parties on the basis of locally defined criteria.
所有实体（信任锚除外）的CA公钥包含在其他CA颁发的证书中。这些证书必须在RPKI分布式存储库系统中发布。依赖方从存储库下载这些证书。（假定）信任锚的公钥值和相关数据分布在带外，并由依赖方根据本地定义的标准接受。
The algorithms and key sizes used in the RPKI are specified in "A Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure" [RFC6485].
RPKI中使用的算法和密钥大小在“资源公钥基础设施中使用的算法和密钥大小配置文件”[RFC6485]中指定。
The public key parameters used in the RPKI are specified in [RFC6485]. Each subscriber is responsible for performing checks on the quality of its key pair. A CA is not responsible for performing such checks for subscribers except in the case where the CA generates the key pair on behalf of the subscriber.
[RFC6485]中规定了RPKI中使用的公钥参数。每个订户负责检查其密钥对的质量。CA不负责为订户执行此类检查，除非CA代表订户生成密钥对。
The Key usage extension bit values used in the RPKI are specified in RPKI Certificate Profile [RFC6487].
RPKI证书配置文件[RFC6487]中指定了RPKI中使用的密钥使用扩展位值。
6.2. Private Key Protection and Cryptographic Module Engineering Controls
6.2. 私钥保护和加密模块工程控制
The cryptographic module standards and controls employed by each CA MUST be described in the CPS issued by that CA.
每个CA采用的加密模块标准和控制必须在该CA发布的CPS中描述。
CAs MAY employ multi-person controls to constrain access to their private keys, but this is not a requirement for all CAs in the PKI. The CPS for each CA MUST describe which, if any, multi-person controls it employs.
CA可以使用多人控制来限制对其私钥的访问，但这不是PKI中所有CA的要求。每个CA的CP必须说明其使用的多人控制（如有）。
No private key escrow procedures are required for the RPKI.
RPKI不需要私钥托管程序。
Because of the adverse operational implications associated with the loss of use of a CA private key in the PKI, each CA MUST employ a secure means to back up its private keys. The details of the procedures for backing up a CA's private key MUST be described in the CPS issued by the CA.
由于在PKI中丢失CA私钥会带来不利的操作影响，因此每个CA必须采用安全的方法备份其私钥。CA发布的CPS中必须详细说明备份CA私钥的过程。
The details of the process and procedures used to archive the CA's private key MUST be described in the CPS issued by the CA.
CA发布的CPS中必须说明用于存档CA私钥的过程和程序的详细信息。
The details of the process and procedures used to transfer the CA's private key into or from a cryptographic module MUST be described in the CPS issued by the CA.
CA发布的CPS中必须描述用于将CA的私钥传输到加密模块或从加密模块传输私钥的过程和过程的详细信息。
The details of the process and procedures used to store the CA's private key on a cryptographic module and protect it from unauthorized use MUST be described in the CPS issued by the CA.
CA发布的CPS中必须详细说明用于将CA的私钥存储在加密模块上并防止其被未经授权使用的过程和过程。
The details of the process and procedures used to activate the CA's private key MUST be described in the CPS issued by the CA.
CA发布的CPS中必须说明用于激活CA私钥的过程和程序的详细信息。
The details of the process and procedures used to deactivate the CA's private key MUST be described in the CPS issued by the CA.
CA发布的CPS中必须描述用于停用CA私钥的过程和程序的详细信息。
The details of the process and procedures used to destroy the CA's private key MUST be described in the CPS issued by the CA.
CA发布的CPS中必须详细说明销毁CA私钥的过程和程序。
The security rating of the cryptographic module MUST be described in the CPS issued by the CA.
密码模块的安全等级必须在CA发布的CPS中描述。
Because this PKI does not support non-repudiation, there is no need to archive public keys.
由于此PKI不支持不可否认性，因此无需存档公钥。
The INRs held by a CA may periodically change when it receives new distributions. To minimize disruption, the CA key pair MUST NOT change when INRs are added to its certificate.
CA持有的INR在收到新的分配时可能会定期变化。为了最大限度地减少中断，在将INR添加到CA证书时，CA密钥对不得更改。
If ISP and network-subscriber certificates are tied to the duration of service agreements, these certificates should have validity periods commensurate with the duration of these agreements. In any
如果ISP和网络用户证书与服务协议期限相关联，则这些证书的有效期应与这些协议的期限相称。无论如何
case, the validity period for certificates MUST be chosen by the issuing CA and described in its CPS.
在这种情况下，证书的有效期必须由发证机构选择并在其CPS中说明。
Each CA MUST document in its CPS how it will generate, install, and protect its activation data.
每个CA必须在其CPS中记录其将如何生成、安装和保护其激活数据。
Each CA MUST document the technical security requirements it employs for CA computer operation in its CPS.
每个CA必须在其CPS中记录其用于CA计算机操作的技术安全要求。
The CPS for each CA MUST document any system development controls required by that CA, if applicable.
每个CA的CP必须记录该CA要求的任何系统开发控制（如适用）。
The CPS for each CA MUST document the security controls applied to the software and equipment used for this PKI. These controls MUST be commensurate with those used for the systems used by the CAs for managing the INRs.
每个CA的CP必须记录应用于此PKI所用软件和设备的安全控制。这些控制必须与CAs用于管理INR的系统的控制相称。
The CPS for each CA MUST document how the equipment (hardware and software) used for this PKI will be procured, installed, maintained, and updated. This MUST be done in a fashion commensurate with the way in which equipment for the management and distribution of INRs is handled.
每个CA的CP必须记录如何采购、安装、维护和更新用于此PKI的设备（硬件和软件）。这必须以与INR管理和分配设备的处理方式相称的方式进行。
The CPS for each CA MUST document the network security controls employed for CA operation. These MUST be commensurate with the protection it employs for the computers used for managing distribution of INRs.
每个CA的CP必须记录CA操作所采用的网络安全控制。这些必须与用于管理INR分配的计算机所采用的保护相称。
The RPKI does not make use of timestamping.
RPKI不使用时间戳。
Please refer to the RPKI Certificate and CRL Profile [RFC6487].
请参阅RPKI证书和CRL配置文件[RFC6487]。
The certificate policy for a typical PKI defines the criteria against which prospective CAs are evaluated and establishes requirements that they must meet. In this PKI, the CAs are already authoritative for the management of INRs, and the PKI simply supports verification of the distribution of these resources to network subscribers. Accordingly, whatever audit and other assessments are already used to ensure the security of the management of INRs is sufficient for this PKI. The CPS for each CA MUST describe what audits and other assessments are used.
典型PKI的证书策略定义了评估潜在CA的标准，并确定了它们必须满足的要求。在这种PKI中，CAs已经具有管理INR的权威性，并且PKI只支持验证这些资源分配给网络用户的情况。因此，无论已经使用何种审计和其他评估来确保INRs管理的安全性，都足以满足PKI的要求。每个CA的CPS必须说明使用了哪些审核和其他评估。
As noted throughout this certificate policy, the organizations managing the distribution of INRs are authoritative in their roles as managers of this data. They MUST operate this PKI to allow the holders of INRs to generate digitally signed data that attest to these distributions. Therefore, the manner in which the organizations in question manage their business and legal matters for this PKI MUST be commensurate with the way in which they already manage business and legal matters in their existing roles. Since there is no single set of responses to this section that would apply to all organizations, the topics listed in Sections 4.9.1 to 4.9.11 and 4.9.13 to 4.9.17 of RFC 3647 SHOULD be covered in the CPS issued by each CA, although not every CA may choose to address all of these topics. Please note that the topics in the above sections of RFC 3647 become sections 9.1 to 9.11 and 9.13 to 9.17 in the CPS.
如本证书政策所述，管理INR分发的组织作为该数据的管理者具有权威性。他们必须操作此PKI，以允许INR持有人生成数字签名数据，证明这些分发。因此，所涉组织为该PKI管理其业务和法律事务的方式必须与其现有角色中管理业务和法律事务的方式相称。由于本节没有适用于所有组织的单一回复集，RFC 3647第4.9.1节至第4.9.11节和第4.9.13节至第4.9.17节中列出的主题应包含在每个CA发布的CPS中，尽管不是每个CA都可以选择解决所有这些主题。请注意，RFC 3647上述章节中的主题将成为CPS中的第9.1至9.11节和第9.13至9.17节。
The procedure for amending this CP is via written notice from the IESG in the form of a new (BCP) RFC that updates or obsoletes this document.
修订本CP的程序由IESG以新（BCP）RFC的形式发出书面通知，更新或废弃本文件。
Successive versions of the CP will be published with the following statement:
CP的后续版本将发布以下声明：
This CP takes effect on MM/DD/YYYY.
This CP takes effect on MM/DD/YYYY.translate error, please retry
MM/DD/YYYY MUST be a minimum of 6 months from the date of publication.
MM/DD/YYYY必须自发布之日起至少6个月。
If the IESG judges that changes to the CP do not materially reduce the acceptability of certificates issued for RPKI purposes, there will be no change to the CP OID. If the IESG judges that changes to the CP do materially change the acceptability of certificates for RPKI purposes, then there MUST be a new CP OID.
如果IESG判断CP变更不会严重降低为RPKI目的颁发的证书的可接受性，则CP OID不会发生变更。如果IESG判断CP的变更确实实质性地改变了RPKI目的证书的可接受性，则必须有一个新的CP OID。
According to X.509, a certificate policy (CP) is "a named set of rules that indicates the applicability of a certificate to a particular community and/or class of applications with common security requirements." A CP may be used by a relying party to help in deciding whether a certificate and the binding therein are sufficiently trustworthy and otherwise appropriate for a particular application. This document describes the CP for the Resource Public Key Infrastructure (RPKI). There are separate documents (CPSs) that cover the factors that determine the degree to which a relying party can trust the binding embodied in a certificate. The degree to which such a binding can be trusted depends on several factors, e.g., the practices followed by the CA in authenticating the subject; the CA's operating policy, procedures, and technical security controls, including the scope of the subscriber's responsibilities (for example, in protecting the private key), and the stated responsibilities and liability terms and conditions of the CA (for example, warranties, disclaimers of warranties, and limitations of liability).
根据X.509，证书策略（CP）是“一组命名规则，表明证书适用于具有通用安全要求的特定社区和/或应用程序类别。”依赖方可以使用CP来帮助决定证书及其绑定是否足够可信，以及是否适合于特定应用。本文档描述了资源公钥基础结构（RPKI）的CP。有单独的文件（CP）涵盖了决定依赖方对证书中包含的约束的信任程度的因素。这种绑定的可信程度取决于几个因素，例如CA在认证主体时遵循的实践；CA的操作政策、程序和技术安全控制，包括订阅者的责任范围（例如，保护私钥），以及CA规定的责任和责任条款和条件（例如，保证、保证免责声明和责任限制）。
Since name uniqueness within the RPKI cannot be guaranteed, there is a risk that two or more CAs in the RPKI will issue certificates and CRLs under the same issuer name. Path validation implementations that conform to the resource certification path validation algorithm (see [RFC6487]) verify that the same key was used to sign both the target (the resource certificate) and the corresponding CRL. So, a name collision will not change the result. Use of the basic X.509 path validation algorithm, which assumes name uniqueness, could result in a revoked certificate being accepted as valid or a valid certificate being rejected as revoked. Relying parties must ensure that the software they use to validate certificates issued under this policy verifies that the same key was used to sign both the certificate and the corresponding CRL, as specified in [RFC6487].
由于无法保证RPKI中的名称唯一性，因此RPKI中的两个或多个CA有可能以相同的颁发者名称颁发证书和CRL。符合资源认证路径验证算法的路径验证实现（请参见[RFC6487]）验证是否使用相同的密钥对目标（资源证书）和相应的CRL进行签名。因此，名称冲突不会改变结果。使用基本的X.509路径验证算法（假定名称唯一性）可能会导致吊销的证书被视为有效证书而被接受，或有效证书被视为吊销而被拒绝。根据[RFC6487]中的规定，依赖方必须确保其用于验证根据本策略颁发的证书的软件验证是否使用相同的密钥对证书和相应的CRL进行了签名。
The authors would like to thank Geoff Huston, Randy Bush, Andrei Robachevsky, and other members of the RPKI community for reviewing this document and Matt Lepinski for his help with the formatting.
作者要感谢Geoff Huston、Randy Bush、Andrei Robachevsky和RPKI社区的其他成员对本文档的审阅，以及Matt Lepinski对格式的帮助。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC3779]Lynn，C.，Kent，S.，和K.Seo，“IP地址和AS标识符的X.509扩展”，RFC 3779，2004年6月。
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, February 2012.
[RFC6481]Huston，G.，Loomans，R.，和G.Michaelson，“资源证书存储库结构的配置文件”，RFC 64812012年2月。
[RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)", RFC 6485, February 2012.
[RFC6485]Huston，G.“用于资源公钥基础设施（RPKI）的算法和密钥大小的配置文件”，RFC 6485，2012年2月。
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, February 2012.
[RFC6487]Huston，G.，Michaelson，G.，和R.Loomans，“X.509 PKIX资源证书的配置文件”，RFC 6487，2012年2月。
[RFC6489] Huston, G., Michaelson, G., and S. Kent, "CA Key Rollover in the RPKI", BCP 174, RFC 6489, February 2012.
[RFC6489]Huston，G.，Michaelson，G.，和S.Kent，“RPKI中的CA键翻转”，BCP 174，RFC 6489，2012年2月。
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC2560]Myers，M.，Ankney，R.，Malpani，A.，Galperin，S.，和C.Adams，“X.509互联网公钥基础设施在线证书状态协议-OCSP”，RFC 25601999年6月。
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, November 2003.
[RFC3647]Chokhani，S.，Ford，W.，Sabett，R.，Merrill，C.，和S.Wu，“互联网X.509公钥基础设施证书政策和认证实践框架”，RFC 3647，2003年11月。
[RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. Polk, "Server-Based Certificate Validation Protocol (SCVP)", RFC 5055, December 2007.
[RFC5055]Freeman，T.，Housley，R.，Malpani，A.，Cooper，D.，和W.Polk，“基于服务器的证书验证协议（SCVP）”，RFC 50552007年12月。
[RFC5736] Huston, G., Cotton, M., and L. Vegoda, "IANA IPv4 Special Purpose Address Registry", RFC 5736, January 2010.
[RFC5736]Huston，G.，Cotton，M.和L.Vegoda，“IANA IPv4专用地址注册”，RFC 57362010年1月。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
[RFC6480]Lepinski，M.和S.Kent，“支持安全互联网路由的基础设施”，RFC 6480，2012年2月。
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012.
[RFC6482]Lepinski，M.，Kent，S.，和D.Kong，“路线原产地授权（ROA）的配置文件”，RFC 64822012年2月。
[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, February 2012.
[RFC6486]Austein，R.，Huston，G.，Kent，S.，和M.Lepinski，“资源公钥基础设施（RPKI）清单”，RFC 64862012年2月。
[RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A Protocol for Provisioning Resource Certificates", RFC 6492, February 2012.
[RFC6492]Huston，G.，Loomans，R.，Ellacott，B.，和R.Austein，“资源证书配置协议”，RFC 64922012年2月。
[X.509] ITU-T Recommendation X.509 | ISO/IEC 9594-8, "Information technology -- Open systems interconnection -- The Directory: Public-key and attribute certificate frameworks", November 2008.
[X.509]ITU-T建议X.509 | ISO/IEC 9594-8，“信息技术——开放系统互连——目录：公钥和属性证书框架”，2008年11月。
Authors' Addresses
作者地址
Stephen Kent BBN Technologies 10 Moulton Street Cambridge MA 02138 USA
美国马萨诸塞州剑桥莫尔顿街10号Stephen Kent BBN Technologies 02138
Phone: +1 617 873 3988
EMail: skent@bbn.com
Phone: +1 617 873 3988
EMail: skent@bbn.com
Derrick Kong BBN Technologies Moulton Street Cambridge MA 02138 USA
Derrick Kong BBN Technologies美国马萨诸塞州剑桥莫尔顿街02138
Phone: +1 617 873 1951
EMail: dkong@bbn.com
Phone: +1 617 873 1951
EMail: dkong@bbn.com
Karen Seo BBN Technologies 10 Moulton Street Cambridge MA 02138 USA
美国马萨诸塞州剑桥莫尔顿街10号Karen Seo BBN Technologies 02138
Phone: +1 617 873 3152
EMail: kseo@bbn.com
Phone: +1 617 873 3152
EMail: kseo@bbn.com
Ronald Watro BBN Technologies 10 Moulton Street Cambridge MA 02138 USA
Ronald Watro BBN Technologies美国马萨诸塞州剑桥莫尔顿街10号02138
Phone: +1 617 873 2551
EMail: rwatro@bbn.com
Phone: +1 617 873 2551
EMail: rwatro@bbn.com