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
        
1. Introduction
1. 介绍

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]中所述进行解释。

1.1. Overview
1.1. 概述

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)证书

1.2. Document Name and Identification
1.2. 文件名称和标识

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 }
        
1.3. PKI Participants
1.3. PKI参与者

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参与者称为组织或实体,即使其中一些人是个人。

1.3.1. Certification Authorities
1.3.1. 认证机构

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。

1.3.2. Registration Authorities
1.3.2. 登记机关

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的责任。

1.3.3. Subscribers
1.3.3. 订户

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适应了这种关系。

1.3.4. Relying Parties
1.3.4. 依赖方

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节。)

1.3.5. Other Participants
1.3.5. 其他与会者

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节)。

1.4. Certificate Usage
1.4. 证书使用
1.4.1. Appropriate Certificate Uses
1.4.1. 适当的证书使用

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节中描述的存储库系统的完整性和访问控制。本政策允许此类过渡用途。

1.4.2. Prohibited Certificate Uses
1.4.2. 禁止证书使用

Any uses other than those described in Section 1.4.1 are prohibited under this policy.

本政策禁止第1.4.1节所述以外的任何用途。

1.5. Policy Administration
1.5. 政策管理
1.5.1. Organization Administering the Document
1.5.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。

1.5.2. Contact Person
1.5.2. 联系人

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)
        
1.5.4. CP Approval Procedures
1.5.4. CP批准程序

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标准流程的程序批准。

1.6. Definitions and Acronyms
1.6. 定义和首字母缩略词

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]。

2. Publication and Repository Responsibilities
2. 发布和存储库职责
2.1. Repositories
2.1. 存储库

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分布式存储库系统。

2.2. Publication of Certification Information
2.2. 公布核证资料

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存储库获得。

2.3. Time or Frequency of Publication
2.3. 出版的时间或频率

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。

2.4. Access Controls on Repositories
2.4. 对存储库的访问控制

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签名对象的读取访问。这些数据旨在供公众查阅。

3. Identification and Authentication
3. 识别和认证
3.1. Naming
3.1. 命名
3.1.1. Types of Names
3.1.1. 名称类型

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属性可以与公共名称一起包括(以形成终端相对可分辨名称集),以区分与同一实体关联的证书的连续实例。

3.1.2. Need for Names to Be Meaningful
3.1.2. 需要有意义的名称

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持有证明的应用。它们不用于识别受试者。

3.1.3. Anonymity or Pseudonymity of Subscribers
3.1.3. 订阅者的匿名性或假名

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的功能;因此,没有提供对此功能的明确支持。

3.1.4. Rules for Interpreting Various Name Forms
3.1.4. 解释各种名称形式的规则

None.

没有一个

3.1.5. Uniqueness of Names
3.1.5. 名称的唯一性

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]提供了一个示例,说明如何以最小化冲突可能性的方式生成(无意义的)主题名称。

3.2. Initial Identity Validation
3.2. 初始身份验证
3.2.1. Method to Prove Possession of the Private Key
3.2.1. 证明拥有私钥的方法

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中声明。

3.2.2. Authentication of Organization Identity
3.2.2. 组织身份验证

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订户关系之外的身份验证。

3.2.3. Authentication of Individual Identity
3.2.3. 个人身份认证

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使用的程序相称的程序。

3.2.4. Non-Verified Subscriber Information
3.2.4. 未经验证的用户信息

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)扩展除外。

3.2.5. Validation of Authority
3.2.5. 授权的确认

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使用的程序相称的程序。

3.2.6. Criteria for Interoperation
3.2.6. 互操作标准

This PKI is neither intended nor designed to interoperate with any other PKI.

此PKI既不是为了也不是为了与任何其他PKI互操作而设计的。

3.3. Identification and Authentication for Re-Key Requests
3.3. 重新密钥请求的标识和身份验证
3.3.1. Identification and Authentication for Routine Re-Key
3.3.1. 用于例行重新密钥的标识和身份验证

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必须对此进行说明。

3.3.2. Identification and Authentication for Re-Key after Revocation
3.3.2. 撤销后重新密钥的标识和身份验证

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使用的程序相称的程序。请注意,对于合法主体仍然拥有原始私钥的情况,可能会有不同的程序,而不是当合法主体不再能够访问该私钥时。

3.4. Identification and Authentication for Revocation Request
3.4. 撤销请求的标识和身份验证

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使用的程序相称的程序。

4. Certificate Life-Cycle Operational Requirements
4. 证书生命周期操作要求
4.1. Certificate Application
4.1. 证书申请
4.1.1. Who Can Submit a Certificate Application
4.1.1. 谁可以提交证书申请

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中必须说明申请程序。

4.1.2. Enrollment Process and Responsibilities
4.1.2. 注册流程和责任

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的组织。

4.2. Certificate Application Processing
4.2. 证书申请处理

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定义其采用的证书请求/响应标准。

4.2.1. Performing Identification and Authentication Functions
4.2.1. 执行识别和身份验证功能

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不提供身份证明,因此证书申请程序无需验证合法组织名称等。

4.2.2. Approval or Rejection of Certificate Applications
4.2.2. 批准或拒绝证书申请

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中说明。

4.2.3. Time to Process Certificate Applications
4.2.3. 处理证书申请的时间

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必须声明其处理(批准、颁发和发布)证书申请的预期时间范围。

4.3. Certificate Issuance
4.3. 证书发行
4.3.1. CA Actions during Certificate Issuance
4.3.1. 证书颁发期间的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分布式存储库系统中。

4.3.2. Notification to Subscriber by the CA of Issuance of Certificate
4.3.2. CA向认购人发出证书颁发通知

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中定义。

4.4. Certificate Acceptance
4.4. 验收证书
4.4.1. Conduct Constituting Certificate Acceptance
4.4.1. 构成验收证书的行为

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中说明其发布证书和通知订户所遵循的程序。

4.4.2. Publication of the Certificate by the CA
4.4.2. CA发布证书

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中定义发布程序。

4.4.3. Notification of Certificate Issuance by the CA to Other Entities
4.4.3. CA向其他实体发布证书的通知

The CPS of each CA MUST indicate whether any other entities will be notified when a certificate is issued.

每个CA的CP必须指明在颁发证书时是否会通知任何其他实体。

4.5. Key Pair and Certificate Usage
4.5. 密钥对和证书使用

A summary of the use model for the RPKI is provided below.

下面提供了RPKI使用模型的摘要。

4.5.1. Subscriber Private Key and Certificate Usage
4.5.1. 订户私钥和证书使用

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签名对象。

4.5.2. Relying Party Public Key and Certificate Usage
4.5.2. 依赖方公钥和证书的使用

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证书的扩展验证算法。

4.6. Certificate Renewal
4.6. 证书续期

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属性)。公钥和所有其他信息保持不变。

4.6.1. Circumstance for Certificate Renewal
4.6.1. 证书续期的情况

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节的规定适用。

4.6.2. Who May Request Renewal
4.6.2. 谁可以要求续约

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可以根据证书到期日期启动续订过程。

4.6.3. Processing Certificate Renewal Requests
4.6.3. 处理证书续订请求

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的合法持有人。续订处理必须验证相关证书是否已被吊销。

4.6.4. Notification of New Certificate Issuance to Subscriber
4.6.4. 向订户发出新证书发行通知

No additional stipulations beyond those of Section 4.3.2.

除第4.3.2节规定外,无其他规定。

4.6.5. Conduct Constituting Acceptance of a Renewal Certificate
4.6.5. 构成接受续期证书的行为

No additional stipulations beyond those of Section 4.4.1.

除第4.4.1节规定外,无其他规定。

4.6.6. Publication of the Renewal Certificate by the CA
4.6.6. 核证机关公布续期证明书

No additional stipulations beyond those of Section 4.4.2.

除第4.4.2节规定外,无其他规定。

4.6.7. Notification of Certificate Issuance by the CA to Other Entities
4.6.7. CA向其他实体发布证书的通知

No additional stipulations beyond those of Section 4.4.3.

除第4.4.3节规定外,无其他规定。

4.7. Certificate Re-Key
4.7. 证书重设密钥

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.

本节介绍证书重设密钥的过程。证书重设密钥是指颁发新证书以替换旧证书,因为需要替换密钥。与证书续订不同,公钥是更改的。

4.7.1. Circumstance for Certificate Re-Key
4.7.1. 证书重设密钥的情况

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.

如果重新密钥基于可疑的泄露,则必须吊销以前的证书。

4.7.2. Who May Request Certification of a New Public Key
4.7.2. 谁可以申请新公钥的认证

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可以根据已验证的泄露报告选择启动重新密钥。

4.7.3. Processing Certificate Re-Keying Requests
4.7.3. 处理证书重设密钥请求

The re-key process follows the general procedures of certificate generation as defined in Section 4.3.

密钥更新过程遵循第4.3节中定义的证书生成的一般程序。

4.7.4. Notification of New Certificate Issuance to Subscriber
4.7.4. 向订户发出新证书发行通知

No additional stipulations beyond those of Section 4.3.2.

除第4.3.2节规定外,无其他规定。

4.7.5. Conduct Constituting Acceptance of a Re-Keyed Certificate
4.7.5. 构成接受重新加密证书的行为

No additional stipulations beyond those of Section 4.4.1.

除第4.4.1节规定外,无其他规定。

4.7.6. Publication of the Re-Keyed Certificate by the CA
4.7.6. CA发布重新设置密钥的证书

No additional stipulations beyond those of Section 4.4.2.

除第4.4.2节规定外,无其他规定。

4.7.7. Notification of Certificate Issuance by the CA to Other Entities
4.7.7. CA向其他实体发布证书的通知

No additional stipulations beyond those of Section 4.4.3.

除第4.4.3节规定外,无其他规定。

4.8. Certificate Modification
4.8. 证书修改
4.8.1. Circumstance for Certificate Modification
4.8.1. 更改证书的情况

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值。)

4.8.2. Who May Request Certificate Modification
4.8.2. 谁可以要求修改证书

Either the certificate holder or the issuer may initiate the certificate modification process.

证书持有人或颁发者均可启动证书修改过程。

4.8.3. Processing Certificate Modification Requests
4.8.3. 处理证书修改请求

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节)。

4.8.4. Notification of New Certificate Issuance to Subscriber
4.8.4. 向订户发出新证书发行通知

No additional stipulations beyond those of Section 4.3.2.

除第4.3.2节规定外,无其他规定。

4.8.5. Conduct Constituting Acceptance of Modified Certificate
4.8.5. 构成接受修改证书的行为

No additional stipulations beyond those of Section 4.4.1.

除第4.4.1节规定外,无其他规定。

4.8.6. Publication of the Modified Certificate by the CA
4.8.6. CA发布修改后的证书

No additional stipulations beyond those of Section 4.4.2.

除第4.4.2节规定外,无其他规定。

4.8.7. Notification of Certificate Issuance by the CA to Other Entities
4.8.7. CA向其他实体发布证书的通知

No additional stipulations beyond those of Section 4.4.3.

除第4.4.3节规定外,无其他规定。

4.9. Certificate Revocation and Suspension
4.9. 证书撤销及暂时吊销
4.9.1. Circumstances for Revocation
4.9.1. 撤销的情况

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或存在密钥泄露,则必须撤销旧证书(并且在密钥泄露的情况下必须执行重新密钥)。

4.9.2. Who Can Request Revocation
4.9.2. 谁可以请求撤销

This MUST be defined in the CPS of the organization that issued the certificate.

这必须在颁发证书的组织的CPS中定义。

4.9.3. Procedure for Revocation Request
4.9.3. 撤销申请的程序

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通知订阅者证书撤销的方式。

4.9.4. Revocation Request Grace Period
4.9.4. 撤销请求宽限期

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.

用户应在确定需要撤销后尽快请求撤销。在此过程中,没有为订阅服务器指定宽限期。

4.9.5. Time within which CA Must Process the Revocation Request
4.9.5. CA必须处理撤销请求的时间

No stipulation. Each CA SHOULD specify its expected revocation processing time in its CPS.

没有规定。每个CA应在其CP中指定其预期撤销处理时间。

4.9.6. Revocation Checking Requirement for Relying Parties
4.9.6. 依赖方撤销检查要求

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。

4.9.7. CRL Issuance Frequency
4.9.7. 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将在何时发出。

4.9.8. Maximum Latency for CRLs
4.9.8. CRL的最大延迟

The CPS for each CA MUST specify the maximum latency associated with posting its CRL to the repository system.

每个CA的CP必须指定将其CRL发布到存储库系统的最大延迟。

4.10. Certificate Status Services
4.10. 证书状态服务

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次(以避免过度访问存储库)。

5. Facility, Management, and Operational Controls
5. 设施、管理和运营控制
5.1. Physical Controls
5.1. 物理控制

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]。)

5.1.1. Site Location and Construction
5.1.1. 现场位置和施工
5.1.2. Physical Access
5.1.2. 物理访问
5.1.3. Power and Air Conditioning
5.1.3. 动力与空调
5.1.4. Water Exposures
5.1.4. 水暴露
5.1.5. Fire Prevention and Protection
5.1.5. 防火
5.1.6. Media Storage
5.1.6. 媒体存储
5.1.7. Waste Disposal
5.1.7. 废物处理
5.1.8. Off-Site Backup
5.1.8. 异地备份
5.2. Procedural Controls
5.2. 程序控制

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]。)

5.2.1. Trusted Roles
5.2.1. 信任角色
5.2.2. Number of Persons Required per Task
5.2.2. 每个任务所需的人数
5.2.3. Identification and Authentication for Each Role
5.2.3. 每个角色的标识和身份验证
5.2.4. Roles Requiring Separation of Duties
5.2.4. 需要职责分离的角色
5.3. Personnel Controls
5.3. 人事管理

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中指定。

5.4. Audit Logging Procedures
5.4. 审计日志记录程序

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中说明。

5.4.1. Types of Events Recorded
5.4.1. 记录的事件类型

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 时钟调整

5.4.2. Frequency of Processing Log
5.4.2. 处理日志的频率

Each CA MUST establish its own procedures for review of audit logs.

每个CA必须建立自己的审核日志审核程序。

5.4.3. Retention Period for Audit Log
5.4.3. 审核日志的保留期

Each CA MUST establish its own polices for retention of audit logs.

每个CA必须为保留审核日志制定自己的策略。

5.4.4. Protection of Audit Log
5.4.4. 审计日志的保护

The audit log SHOULD be protected based on current industry standards.

应根据当前行业标准保护审核日志。

5.4.5. Audit Log Backup Procedures
5.4.5. 审核日志备份过程

The audit log SHOULD be backed up based on current industry standards.

应根据当前行业标准备份审核日志。

5.4.8. Vulnerability Assessments
5.4.8. 薄弱评估

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子系统应参与这些组织作为其正常业务实践的一部分运行的任何漏洞评估。

5.6. Key Changeover
5.6. 钥匙转换

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中密钥转换是如何实现的。

5.7. CA or RA Termination
5.7. CA或RA终止

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没有单独的规定。

6. Technical Security Controls
6. 技术安全控制

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中描述。

6.1. Key Pair Generation and Installation
6.1. 密钥对生成和安装
6.1.1. Key Pair Generation
6.1.1. 密钥对生成

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中描述其密钥对生成过程。

6.1.2. Private Key Delivery to Subscriber
6.1.2. 私钥传递给订户

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必须描述以安全方式向订户交付私钥的方式。

6.1.3. Public Key Delivery to Certificate Issuer
6.1.3. 公钥传递给证书颁发者

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时,必须通过一种机制来传递公钥,该机制确保公钥在传输过程中没有被更改,并且订户拥有与传输的公钥对应的私钥。

6.1.4. CA Public Key Delivery to Relying Parties
6.1.4. 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分布式存储库系统中发布。依赖方从存储库下载这些证书。(假定)信任锚的公钥值和相关数据分布在带外,并由依赖方根据本地定义的标准接受。

6.1.5. Key Sizes
6.1.5. 关键尺寸

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]中指定。

6.1.6. Public Key Parameters Generation and Quality Checking
6.1.6. 公钥参数生成和质量检查

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代表订户生成密钥对。

6.1.7. Key Usage Purposes (as per X.509 v3 Key Usage Field)
6.1.7. 密钥使用目的(根据X.509 v3密钥使用字段)

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. 私钥保护和加密模块工程控制

6.2.1. Cryptographic Module Standards and Controls
6.2.1. 密码模块标准和控制

The cryptographic module standards and controls employed by each CA MUST be described in the CPS issued by that CA.

每个CA采用的加密模块标准和控制必须在该CA发布的CPS中描述。

6.2.2. Private Key (N out of M) Multi-Person Control
6.2.2. 私钥(N/M)多人控制

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必须说明其使用的多人控制(如有)。

6.2.3. Private Key Escrow
6.2.3. 私钥托管

No private key escrow procedures are required for the RPKI.

RPKI不需要私钥托管程序。

6.2.4. Private Key Backup
6.2.4. 私钥备份

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私钥的过程。

6.2.5. Private Key Archival
6.2.5. 私钥存档

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私钥的过程和程序的详细信息。

6.2.6. Private Key Transfer into or from a Cryptographic Module
6.2.6. 私钥传入或传出加密模块

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的私钥传输到加密模块或从加密模块传输私钥的过程和过程的详细信息。

6.2.7. Private Key Storage on Cryptographic Module
6.2.7. 密码模块上的私钥存储

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的私钥存储在加密模块上并防止其被未经授权使用的过程和过程。

6.2.8. Method of Activating a Private Key
6.2.8. 激活私钥的方法

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私钥的过程和程序的详细信息。

6.2.9. Method of Deactivating a Private Key
6.2.9. 停用私钥的方法

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私钥的过程和程序的详细信息。

6.2.10. Method of Destroying a Private Key
6.2.10. 销毁私钥的方法

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私钥的过程和程序。

6.2.11. Cryptographic Module Rating
6.2.11. 密码模块评级

The security rating of the cryptographic module MUST be described in the CPS issued by the CA.

密码模块的安全等级必须在CA发布的CPS中描述。

6.3. Other Aspects of Key Pair Management
6.3. 密钥对管理的其他方面
6.3.1. Public Key Archival
6.3.1. 公钥档案

Because this PKI does not support non-repudiation, there is no need to archive public keys.

由于此PKI不支持不可否认性,因此无需存档公钥。

6.3.2. Certificate Operational Periods and Key Pair Usage Periods
6.3.2. 证书操作周期和密钥对使用周期

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中说明。

6.4. Activation Data
6.4. 激活数据

Each CA MUST document in its CPS how it will generate, install, and protect its activation data.

每个CA必须在其CPS中记录其将如何生成、安装和保护其激活数据。

6.5. Computer Security Controls
6.5. 计算机安全控制

Each CA MUST document the technical security requirements it employs for CA computer operation in its CPS.

每个CA必须在其CPS中记录其用于CA计算机操作的技术安全要求。

6.6. Life-Cycle Technical Controls
6.6. 生命周期技术控制
6.6.1. System Development Controls
6.6.1. 系统开发控制

The CPS for each CA MUST document any system development controls required by that CA, if applicable.

每个CA的CP必须记录该CA要求的任何系统开发控制(如适用)。

6.6.2. Security Management Controls
6.6.2. 安全管理控制

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的系统的控制相称。

6.6.3. Life-Cycle Security Controls
6.6.3. 生命周期安全控制

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管理和分配设备的处理方式相称的方式进行。

6.7. Network Security Controls
6.7. 网络安全控制

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分配的计算机所采用的保护相称。

6.8. Timestamping
6.8. 时间戳

The RPKI does not make use of timestamping.

RPKI不使用时间戳。

7. Certificate and CRL Profiles
7. 证书和CRL配置文件

Please refer to the RPKI Certificate and CRL Profile [RFC6487].

请参阅RPKI证书和CRL配置文件[RFC6487]。

8. Compliance Audit and Other Assessments
8. 合规审计和其他评估

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必须说明使用了哪些审核和其他评估。

9. Other Business and Legal Matters
9. 其他商业及法律事宜

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节。

9.12. Amendments
9.12. 修正案
9.12.1. Procedure for Amendment
9.12.1. 修订程序

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的形式发出书面通知,更新或废弃本文件。

9.12.2. Notification Mechanism and Period
9.12.2. 通知机制和期限

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个月。

9.12.3. Circumstances under Which OID Must Be Changed
9.12.3. 必须更改OID的情况

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。

10. Security Considerations
10. 安全考虑

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进行了签名。

11. Acknowledgments
11. 致谢

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对格式的帮助。

12. References
12. 工具书类
12.1. Normative References
12.1. 规范性引用文件

[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月。

12.2. Informative References
12.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