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)
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.
この文書は、インターネット番号リソース（INR）保有についてアテステーションをサポートするために使用される公開鍵基盤（PKI）の証明書ポリシーを記述する。組織に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 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.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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
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
6.1.3. Public Key Delivery to Certificate Issuer ..........27
6.1.4. CA Public Key Delivery to Relying Parties ..........27
6.1.5. Key Sizes ..........................................27
6.1.6. Public Key Parameters Generation and
Quality Checking ...................................28
6.1.7. Key Usage Purposes (as per X.509 v3 Key
Usage Field) .......................................28
6.2. Private Key Protection and Cryptographic Module
Engineering Controls ......................................28
6.2.1. Cryptographic Module Standards and Controls ........28
6.2.2. Private Key (N out of M) Multi-Person Control ......28
6.2.3. Private Key Escrow .................................28
6.2.4. Private Key Backup .................................28
6.2.5. Private Key Archival ...............................28
6.2.6. Private Key Transfer into or from a
Cryptographic Module ...............................29
6.2.7. Private Key Storage on Cryptographic Module ........29
6.2.8. Method of Activating a Private Key .................29
6.2.9. Method of Deactivating a Private Key ...............29
6.2.10. Method of Destroying a Private Key ................29
6.2.11. Cryptographic Module Rating .......................29
6.3. Other Aspects of Key Pair Management ......................29
6.3.1. Public Key Archival ................................29
6.3.2. Certificate Operational Periods and Key
Pair Usage Periods .................................29
6.4. Activation Data ...........................................30
6.5. Computer Security Controls ................................30
6.6. Life-Cycle Technical Controls .............................30
6.6.1. System Development Controls ........................30
6.6.2. Security Management Controls .......................30
6.6.3. Life-Cycle Security Controls .......................30
6.7. Network Security Controls .................................30
6.8. Timestamping ..............................................30
7. Certificate and CRL Profiles ...................................31
8. Compliance Audit and Other Assessments .........................31
9. Other Business and Legal Matters ...............................31
9.12. Amendments ..............................................31
9.12.1. Procedure for Amendment ...........................31
9.12.2. Notification Mechanism and Period .................31
9.12.3. Circumstances under Which OID Must Be Changed .....32
10. Security Considerations .......................................32
11. Acknowledgments ...............................................33
12. References ....................................................33
12.1. Normative References .....................................33
12.2. Informative References ...................................33
This document describes the certificate policy for a Public Key Infrastructure (PKI) used to attest to Internet Number Resource (INR) holdings (IP addresses or Autonomous System (AS) numbers). An organization that distributes INRs to another organization MAY, in parallel, issue a (public key) certificate reflecting this distribution. These certificates will enable verification that the resources indicated in the certificate have been distributed to the holder of the associated private key and that this organization is the current holder of these resources.
この文書は、インターネット番号リソース（INR）ホールディングス（IPアドレスまたは自律システム（AS）番号）を証明するために使用される公開鍵基盤（PKI）の証明書ポリシーを記述する。並行して、別の組織MAYにINRSを配布組織は、この分布を反映した（公開鍵）証明書を発行します。これらの証明書は、証明書に示されたリソースは、関連する秘密鍵の所有者に配布し、この組織は、これらのリソースの現在の所有者であることをされていることの検証を可能にします。
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の文脈において、その証明書の公開対応する証明書に含まれる鍵、及び検証を使用して検証されるデータに署名するエンティティの能力：アサーションの検証は、2つの基準に基づいています。
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は、現在のINR保有に関連する請求の検証のサポートで使用するために専用に設計されています。これは、このインフラストラクチャの操作のサポートに発行された証明書が含まれ、例えば、2.4節で説明したリポジトリシステムの整合性やアクセス制御のために。証明書のような推移の用途にもこの方針の下で許可されています。証明書と証明書失効リスト（CRL）の使用は、他の目的のために、このPKIの下で管理することは、このCPに違反しており、信頼者（RPS）は、このような用途のために提示された証明書を拒否すべきです。
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]で指定されたテンプレートは、Internet Engineering Task Force（IETF）ストリームの製品に基づいています。彼らはこのPKIには適用されませんので、妥当な限り短い文書を保つことの興味では、テンプレートに含まれているセクションの数は、このポリシーから省略されています。 （「規定なし」証明書ポリシーで（CP）/認定実践書として読まれるべきであるこれらの省略の各セクションしかし、我々は、RFC 3647.のセクション6でのアウトラインとの比較を容易にするために、RFC 3647で採用セクション番号スキームを保持しています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].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
This PKI is designed to support validation of claims by current holders of INRs, in accordance with the records of the organizations that act as Certification Authorities (CAs) in this PKI. The ability to verify such claims is essential to ensuring the unambiguous distribution of these resources [RFC6480].
このPKIは、このPKIでの証明機関（CA）として機能し、組織の記録に基づいて、INRSの現在の保有者がクレームの検証をサポートするように設計されています。このような主張を検証する能力は、これらのリソース[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の構造は、インターネットの数リソース割り当てフレームワークと合同です。 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
INRSを配布、各組織のとINR保有者のためのO CA証明書
o End-entity (EE) certificates for organizations to validate digital signatures on RPKI signed objects
O RPKIのデジタル署名を検証する組織のためのエンドエンティティ（EE）証明書オブジェクトに署名しました
The name of this document is "Certificate Policy (CP) for the Resource PKI (RPKI)".
このドキュメントの名前は、「リソースPKI（RPKI）のための証明書ポリシー（CP）」です。
This policy has been assigned the following OID:
このポリシーは、次のOIDが割り当てられています。
id-cp-ipAddr-asNumber OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1)
識別組織（3）DOD（6）インターネット（1）
security(5) mechanisms(5) pkix(7) cp(14) 2 }
セキュリティ（5）メカニズム（5）PKIX（7）CP（14）2}
Note that in a PKI, the term "subscriber" refers to an individual or organization that is a subject of a certificate issued by a CA. The term is used in this fashion throughout this document, without qualification, and should not be confused with the networking use of the term to refer to an individual or organization that receives service from an ISP. In such cases, the term "network subscriber" will be used. Also note that, for brevity, this document always refers to PKI participants as organizations or entities, even though some of them are individuals.
PKIには、用語「加入者」は、CAによって発行された証明書の対象である個人または組織のことをいいます用語は資格なしに、本書を通じてこのような方法で使用され、ISPからサービスを受ける個人や組織を参照するために用語のネットワーキングの使用と混同してはなりません。このような場合には、用語「ネットワーク加入者は、」使用されます。また簡潔にするため、この文書は、常にそれらのいくつかは、個人であっても、組織や事業体としてのPKIの参加者を指し、ということに注意してください。
The organizations that distribute IP addresses and AS numbers (IANA, RIRs, NIRs, ISPs) act as CAs in this PKI.
このPKI CAとしてIPアドレスを配布し、AS番号（IANA、のRIR、NIRが、ISPの）行為の組織。
Organizations that do not distribute INRs but hold such resources also act as CAs when they create EE certificates.
彼らはEE証明書を作成するときにINRSを配布するが、そのようなリソースを保持していない組織はまた、CAとして機能します。
This PKI does not require establishment or use of a registration authority (RA) function separate from the one provided inherently in conjunction with the CA function. The RA function MUST be provided by the same entity operating as a CA, e.g., entities listed in Section 1.3.1. An entity acting as a CA in this PKI already has a formal relationship with each organization to which it distributes INRs. These entities (the CAs) already perform the RA function implicitly since they already assume responsibility for distributing INRs.
このPKIは、CA機能と連動して、本質的に提供される一つから別の登録機関（RA）機能の確立または使用する必要はありません。 RA機能がCAとして動作する同じエンティティによって提供されなければならない、例えば、エンティティは、セクション1.3.1に記載されています。このPKIでCAとして動作するエンティティは、すでにそれがINRSを配布するために、各団体との正式な関係を持っています。彼らはすでにINRSを配布するための責任を負うため、これらの事業体（CAS）は、すでに暗黙のうちRA機能を実行します。
These are the organizations receiving distributions of INRs: RIRs, NIRs, ISPs, and other organizations.
RIR、NIRが、ISPの、およびその他の組織：これらは、INRSの分布を受ける組織です。
Note that any of these organizations may have received distributions from more than one source over time. This is true even for RIRs, which participate in inter-registry exchanges of address space. This PKI accommodates such relationships.
これらの組織のいずれかが時間をかけて複数のソースから配布を受けた可能性があることに注意してください。これも、アドレス空間の間のレジストリ交換に参加のRIR、についても同様です。このPKIは、そのような関係に対応しています。
Entities or individuals that act in reliance on certificates or RPKI signed objects issued under this PKI are relying parties. Relying parties may or may not be subscribers within this PKI. (See Section 1.6 for the definition of an RPKI signed object.)
証明書やこのPKIに基づいて発行されたRPKI署名オブジェクトへの依存で動作するエンティティまたは個人が当事者に依存しています。依拠当事者は、あるいはこのPKI内の加入者であってもなくてもよいです。 （RPKI署名されたオブジェクトの定義については、セクション1.6を参照）。
Every organization that undertakes a role as a CA in this PKI is responsible for populating the RPKI distributed repository system with the certificates, CRLs, and RPKI signed objects that it issues. The organization MAY operate its own publication point, or it MAY outsource this function (see Sections 2.1 and 2.2).
このPKI内のCA証明書を持つRPKI分散リポジトリシステムに取り込むための責任があるとして役割を引き受けるすべての組織は、CRLを、とRPKIは、それが発行したオブジェクトに署名しました。組織は、独自の出版ポイントを動作させることができる、またはそれは（セクション2.1および2.2を参照）は、この機能をアウトソーシングするかもしれません。
The certificates issued under this hierarchy are for authorization in support of validation of claims of current holdings of INRs.
この階層の下で発行された証明書は、INRSの現在の保有の特許請求の範囲の妥当性を支持して承認するためのものです。
Additional uses of the certificates, consistent with the basic goal cited above, also are permitted under this policy. For example, certificates may be issued in support of integrity and access control for the repository system described in Section 2.4. Such transitive uses are permitted under this policy.
上記引用した基本的な目標と一致した証明書の追加の使用は、また、このポリシーの下で許可されています。たとえば、証明書は2.4節で説明したリポジトリシステムの整合性とアクセス制御をサポートするために発行することができます。このような推移の用途は、このポリシーの下で許可されています。
Any uses other than those described in Section 1.4.1 are prohibited under this policy.
1.4.1項に記載されているもの以外の使用は、このポリシーで禁止されています。
This CP is administered by
このCPはで投与され、
Internet Engineering Steering Group c/o Internet Society 1775 Wiehle Avenue, Suite 201 Reston, VA 20190-5108 U.S.A.
インターネットエンジニアリング運営グループのC / Oインターネット協会1775 Wiehleアベニュー、スイート201レストン、バージニア州20190から5108 U.S.A.
The contact information is
連絡先情報です
EMail: iesg@ietf.org Phone: +1-703-439-2120 (Internet Society)
メールアドレス：iesg@ietf.org電話：+ 1-703-439-2120（インターネット協会）
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を廃止された場合、RFC 2026 [RFC2026]で定義されるように、次いで置換BCPは、IETF標準化過程の手順に従ってIESGによって承認されなければなりません。
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.
INRSの分布 - それぞれの数の階層に沿ってINRSの分布のプロセス。 IANAは、IPアドレスのブロックを配布し、5つの地域インターネットレジストリ（RIRが）へのAS番号。 RIRは小さなアドレスブロックを配布し、順番に顧客にIPアドレスを配布し、そのサービス領域内の組織へのAS番号。
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アドレス指定のシステムのグローバルな連携のためのインターネット・トラフィックをルーティングするために使用AS番号を担当しています。 IANAは、地域インターネットレジストリ（RIRが）にINRSを配布しています。
INRs - Internet Number Resources. INRs are number values for three protocol parameter sets, namely:
INRS - インターネット番号リソース。 INRS、すなわち、3つのプロトコルパラメータセットのための数値です。
o IP version 4 addresses,
IPバージョン4つのアドレス、O、
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識別子、現在のボーダーゲートウェイプロトコル-4 AS番号。
ISP - Internet Service Provider. This is an organization managing and providing Internet services to other organizations.
ISP - インターネットサービスプロバイダ。これは、管理し、他の組織にインターネットサービスを提供する組織です。
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 - 国別インターネットレジストリ。これは、地域レジストリによってカバーさ地政学的な領域の一部のためのINRSの配布を管理する組織です。 NIRは、INRSを管理するために使用されるツリースキームにおける任意の第二層を形成します。
RIR - Regional Internet Registry. This is an organization that manages the distribution of INRs for a geopolitical area.
RIR - 地域インターネットレジストリ。これは、地政学的な領域のINRSの配布を管理する組織です。
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署名オブジェクト標準化過程RFCによって、このようなことを宣言され、そしてそれは、このPKIの下で発行された証明書を使用して検証することができます（証明書またはCRL以外の）デジタル署名されたデータオブジェクトです。これらのデータ構造の内容と形式は、INRSの現在の保有の特許請求の範囲の検証が行われるコンテキストに依存します。これらのオブジェクトの例としては、リポジトリマニフェスト[RFC6486]およびルート起源権限（資産収益率）[RFC6482]です。
Certificates, CRLs, and RPKI signed objects (intended for public consumption) MUST be made available for downloading by all relying parties, to enable them to validate this data. This motivates use of a robust, distributed repository system. Each CA MUST maintain a publicly accessible online repository and publish all RPKI-signed objects (intended for public consumption) via this repository in a manner that conforms with "A Profile for Resource Certificate Repository Structure" [RFC6481]. (This function MAY be outsourced, as noted in Section 2.2 below.) The collection of repositories forms the RPKI distributed repository system.
証明書は、CRLを、とRPKIは（公共の消費のために意図した）オブジェクトに署名し、このデータを検証するためにそれらを可能にするために、すべての信頼者によってダウンロードするために利用可能にする必要があります。これは、堅牢、分散リポジトリシステムの使用を動機付けます。各CAは、公的にアクセス可能なオンラインリポジトリを維持し、「リソース証明書リポジトリの構造のためのプロフィール」[RFC6481]に準拠した方法でこのリポジトリ経由（公共の消費のために意図した）すべてのRPKI署名されたオブジェクトを公開する必要があります。 （以下のセクション2.2で述べたように、この機能は、外部委託されるかもしれません。）リポジトリのコレクションは、RPKI分散リポジトリシステムを形成します。
Each CA MUST publish the certificates (intended for public consumption) that it issues via the repository system.
各CAは、リポジトリシステムを介して発行する（公共の消費のために意図した）証明書を発行しなければなりません。
Each CA MUST publish the CRLs (intended for public consumption) that it issues via the repository system.
各CAは、リポジトリシステムを介して発行する（公共の消費のために意図）CRLを公開する必要があります。
Each CA MUST publish its RPKI signed objects (intended for public consumption) via the repository system.
各CAリポジトリシステムを介して（公共消費のために意図される）そのRPKI署名されたオブジェクトを公開しなければなりません。
Each CA that issues certificates to entities outside of its administrative domain SHOULD create and publish a CPS that meets the requirements set forth in this CP. Publication means that the entities to which the CA issues certificates MUST be able to acquire a copy of the CPS, and MUST be able to ascertain when the CPS changes. (An organization that does not allocate or assign INRs does not need to create or publish a CPS.)
その管理ドメインの外のエンティティに証明書を発行する各CAは、このCPに記載された要件を満たしているCPSを作成し公開する必要があります。パブリケーションは、エンティティがCA発行の証明書がCPSのコピーを取得できなければならないためにどの、いつCPSの変更を確認することができなければならないことを意味します。 （割り当てまたはINRSを割り当てていない組織が作成またはCPSを公開する必要はありません。）
An organization MAY choose to outsource publication of RPKI data -- certificates, CRLs, and other RPKI signed objects.
証明書、CRLの、および他のRPKI署名オブジェクト - 組織は、RPKIデータの公表を外部委託することを選択するかもしれません。
The CP will be published as an IETF-stream RFC and will be available from the RFC repository.
CPは、IETFストリームRFCとして公開され、RFCリポジトリから利用できるようになります。
The CPS for each CA MUST specify the following information:
各CAのCPSは、以下の情報を指定する必要があります。
The period of time within which a certificate will be published after the CA issues the certificate.
CAが証明書を発行した後、証明書が公開される範囲内の期間。
The period of time within which a CA will publish a CRL with an entry for a revoked certificate after it revokes that certificate.
それはその証明書を取り消した後、CAは、取り消された証明書のエントリでCRLを公開しますその中の期間。
Expired and revoked certificates SHOULD be removed from the RPKI repository system, upon expiration or revocation, respectively. Also, please note that each CA MUST publish its CRL prior to the nextUpdate value in the scheduled CRL previously issued by the CA.
期限切れや失効した証明書は、それぞれ、満了または失効時に、RPKIリポジトリシステムから除去されるべきです。また、各CAが以前のCAによって発行されたスケジュールされたCRLに先立ちnextUpdateの値にそのCRLを公開しなければならないことに注意してください
Each CA or repository operator MUST implement access controls to prevent unauthorized persons from adding, modifying, or deleting repository entries. A CA or repository operator MUST NOT intentionally use technical means of limiting read access to its CPS, certificates, CRLs, or RPKI signed objects. This data is intended to be accessible to the public.
各CAまたはリポジトリオペレータは、追加、変更、またはリポジトリエントリを削除する権限のない者を防ぐために、アクセス制御を実装しなければなりません。 CAまたはリポジトリオペレータは、意図的に、そのCPSへの読み取りアクセスを制限する技術的手段を使用する証明書、CRLに、またはRPKIは、オブジェクトに署名してはなりません。このデータは、公衆にアクセスできるように意図されます。
The distinguished name for every CA and end-entity consists of a single CommonName (CN) attribute with a value generated by the issuer of the certificate. Optionally, the serialNumber attribute MAY be included along with the common name (to form a terminal relative distinguished name set), to distinguish among successive instances of certificates associated with the same entity.
すべてのCAとエンドエンティティの識別名は、証明書の発行者によって生成された値を有する単一のCommonName（CN）属性から成ります。必要に応じて、serialNumber属性は、同じエンティティに関連付けられた証明書の連続したインスタンスを区別するために、（端末相対識別名のセットを形成するために）共通の名前と一緒に含まれるかもしれません。
The subject name in each certificate SHOULD NOT be "meaningful", i.e., the name is not intended to convey the identity of the subject to relying parties. The rationale here is that certificates issued under this PKI are used for authorization in support of applications that make use of attestations of INR holdings. They are not used to identify subjects.
各証明書のサブジェクト名は「意味のある」すべきではない、すなわち、名前が依拠当事者へのサブジェクトの識別情報を伝えることを意図されていません。ここでの理論的根拠は、このPKIに基づいて発行された証明書がINR保有のアテステーションを利用するアプリケーションのサポートに承認のために使用されているということです。彼らは、被験者を識別するために使用されていません。
Although subject (and issuer) names need not be meaningful, and may appear "random," anonymity is not a function of this PKI; thus, no explicit support for this feature is provided.
被験者（及び発行者）の名前が意味である必要はない、と思われるかもしれないが、「ランダム」匿名このPKIの関数ではありません。したがって、この機能のための明示的なサポートが提供されていません。
None.
無し。
There is no guarantee that subject names are globally unique in this PKI. Each CA certifies subject names that MUST be unique among the certificates it issues. Although it is desirable that these subject names be unique throughout the PKI, name uniqueness within the RPKI cannot be guaranteed.
サブジェクト名は、このPKIでグローバルに一意であるという保証はありません。各CAは、それが発行する証明書の中で一意でなければならないのサブジェクト名を認定します。それはこれらのサブジェクト名は、PKI全体で一意であることが望ましいが、RPKI内の名前の一意性を保証することはできません。
However, subject names in certificates SHOULD be constructed in a way that minimizes the chances that two entities in the RPKI will be assigned the same name. The RPKI Certificate Profile [RFC6487] provides an example of how to generate (meaningless) subject names in a way that minimizes the likelihood of collisions.
しかし、証明書でサブジェクト名は、RPKIで2つのエンティティが同じ名前が割り当てられます可能性を最小限に抑えるようにして構築されるべきです。 RPKI証明書プロファイル[RFC6487]は、衝突の可能性を最小限に抑えるように（無意味な）対象名を生成する方法の例を提供します。
Each CA operating within the context of this PKI MUST require each subject to demonstrate proof of possession (PoP) of the private key corresponding to the public key in the certificate, prior to issuing the certificate. The means by which PoP is achieved is determined by each CA and MUST be declared in the CPS of that CA.
このPKIのコンテキスト内で動作する各CAは、前の証明書を発行する証明書の公開鍵に対応する秘密鍵の所有（POP）の証拠を示すために各被験者を必要としなければなりません。 POPが達成される手段は、各CAによって決定され、そのCAのCPS内で宣言されなければなりません
Each CA operating within the context of this PKI MUST employ procedures to ensure that each certificate it issues accurately reflects its records with regard to the organization to which the CA has distributed the INRs identified in the certificate. The specific procedures employed for this purpose MUST be described by the CPS for each CA. Relying parties can expect each CA to employ procedures commensurate with those it already employs as a registry or ISP in the management of the INRs. This authentication is solely for use by each CA in dealing with the organizations to which it distributes INRs, and thus should not be relied upon outside of this CA-subscriber relationship.
このPKIのコンテキスト内で動作する各CAは、それが正確に発行した各証明書は、CAが証明書で識別INRSを配布したために、組織に関連して、そのレコードを反映していることを確認する手順を使わなければなりません。この目的のために使用される特定の手順は、各CAのCPSによって記述されなければなりません依拠当事者は、各CAは、それがすでにINRSの管理にレジストリまたはISPとして採用したものに見合った手続きを採用することを期待することができます。この認証は、それがINRSを配布先の団体に対処する上で、各CAによって使用のみであるため、このCA-加入者の関係の外に依拠すべきではありません。
Each CA operating within the context of this PKI MUST employ procedures to identify at least one individual as a representative of each organization that is an INR holder. The specific means by which each CA authenticates individuals as representatives for an organization MUST be described by the CPS for each CA. Relying parties can expect each CA to employ procedures commensurate with those it already employs as a registry or ISP in authenticating individuals as representatives for INR holders.
このPKIのコンテキスト内で動作する各CAは、INRホルダ各組織の代表のような少なくとも1つの個人を識別するための手続きを採用しなければなりません。各CAは、組織の代表として、個人を認証することにより、特定の手段は、各CAのCPSによって記述されなければなりません依拠当事者は、各CAは、それがすでにINR保有者のための代表として、個人を認証するレジストリまたはISPとして採用したものに見合った手続きを採用することを期待することができます。
A CA MUST NOT include any non-verified subscriber data in certificates issued under this certificate policy except for Subject Information Access (SIA) extensions.
CAは、サブジェクト情報アクセス（SIA）の拡張子を除いて、この証明書ポリシーの下で発行された証明書のいずれかの非検証加入者データを含んではいけません。
Each CA operating within the context of this PKI MUST employ procedures to verify that an individual claiming to represent an organization to which a certificate is issued is authorized to represent that organization in this context. The procedures MUST be described by the CPS for the CA. Relying parties can expect each CA to employ procedures commensurate with those it already employs as a registry or ISP, in authenticating individuals as representatives for INR holders.
このPKIのコンテキスト内で動作する各CAは、証明書が発行されるために、組織を表現するために主張している個人は、この文脈でその組織を代表する権限があることを確認する手順を使わなければなりません。手順はCAのCPSによって記述されなければなりません依拠当事者は、それがすでにINR保有者のための代表として、個人を認証するには、レジストリまたはISPとして採用したものに見合った手続きを採用する各CAを期待することができます。
This PKI is neither intended nor designed to interoperate with any other PKI.
このPKIは意図もなく、他のPKIと相互運用するように設計もされていません。
Each CA operating within the context of this PKI MUST employ procedures to ensure that an organization requesting a re-key is the legitimate holder of the certificate to be re-keyed and the associated INRs, and MUST require PoP of the private key corresponding to the new public key. The procedures employed for these purposes MUST be described in the CPS for the CA. With respect to authentication of the holder of the INRs, relying parties can expect each CA to employ procedures commensurate with those it already employs as a registry or ISP, in the management of INRs.
このPKIのコンテキスト内で動作する各CAは、再鍵を要求する組織が再キーイングする証明書および関連INRSの正当な所有者であり、に対応する秘密鍵のPOPを必要としなければならないことを確実にするための手順を採用しなければなりません新しい公開鍵。これらの目的のために用いられる手順は、CAのCPSに記載されなければなりませんINRSの所有者の認証に関しては、依拠当事者は、それがすでにINRSの管理には、レジストリまたはISPとして採用したものに見合った手続きを採用する各CAを期待することができます。
Note: An issuer MAY choose to require periodic re-keying consistent with contractual agreements with the recipient. If so, this MUST be described by the CPS for the CA.
注意：発行者は定期的に受信者との契約上の合意と矛盾再キーイング要求するように選ぶかもしれません。もしそうなら、これはCAのCPSによって記述されなければなりません
Each CA operating within the context of this PKI MUST employ procedures to ensure that an organization requesting a re-key after revocation is the same entity to which the revoked certificate was issued and is the legitimate holder of the associated INR. The CA MUST require PoP of the private key corresponding to the new public key. The specific procedures employed for these purposes MUST be described by the CPS for the CA. With respect to authentication of the holder of the INRs, relying parties can expect each CA to employ procedures commensurate with those it already employs as a registry or ISP, in the management of INRs. Note that there MAY be different procedures for the case where the legitimate subject still possesses the original private key as opposed to the case when it no longer has access to that key.
このPKIのコンテキスト内で動作する各CAは、失効後の再鍵を要求する組織が取り消された証明書が発行されたために、同じエンティティと関連付けられたINRの正当な所有者であることを確認するための手続きを採用しなければなりません。 CAは、新しい公開鍵に対応する秘密鍵のPOPを必要としなければなりません。これらの目的のために使用される特定の手順は、CAのCPSによって記述されなければなりませんINRSの所有者の認証に関しては、依拠当事者は、それがすでにINRSの管理には、レジストリまたはISPとして採用したものに見合った手続きを採用する各CAを期待することができます。合法的な主題はまだそれがもはやそのキーへのアクセス権を持つ場合とは逆に、元の秘密鍵を所有している場合の異なる手順があるかもしれないことに注意してください。
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が証明書で識別INRSを配布したために、組織に関してそのレコードを反映した正確に取り消されます。
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.
これらの目的のために使用される特定の手順は、CAのCPSによって記述されなければなりません依拠当事者は、それがすでにINRSの管理には、レジストリまたはISPとして採用したものに見合った手続きを採用する各CAを期待することができます。
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.
INRSを配布する任意のエンティティは、証明書を獲得しなければなりません。これは、インターネットレジストリやISPが含まれています。さらに、マルチホームしているインターネットレジストリからINRSを保有する事業体、またはが、このPKIの下で証明書を取得することができます。必要に応じて、RFC 3779 [RFC3779]で定義された拡張機能、「IPアドレスとAS識別子のためのX.509拡張機能」の一方または両方を、含まなければならないこれらの事業体に発行された（CA）の証明書。
The application procedure MUST be described in the CPS for each CA.
申請手続きは、各CAのCPSに記載されなければなりません
The enrollment process and procedures MUST be described by the CPS for each CA. An entity that desires one or more certificates should contact the organization from which it receives its INRs.
登録プロセスおよび手順は、各CAのCPSによって記述されなければなりません1つ以上の証明書を希望する企業は、そのINRSを受け、そこから組織に連絡してください。
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.
CAは、証明書申請の処理のための既存の標準を利用するべきです。リソース証明書プロファイル[RFC6487]のセクション6がサポートしなければならない標準的な証明書要求のフォーマットを定義します。
Each CA MUST define via its CPS, the certificate request/response standards that it employs.
各CAは、それが採用そのCPS、証明書要求/応答基準を経由して定義しなければなりません。
Existing practices employed by registries and ISPs to identify and authenticate organizations that receive INRs form the basis for issuance of certificates to these subscribers. It is important to note that the Resource PKI SHOULD NOT be used to authenticate the identity of an organization, but rather to bind subscribers to the INRs they hold. Because identity is not being vouched for by this PKI, certificate application procedures need not verify legal organization names, etc.
INRSを受ける組織を識別し、認証するために、レジストリやISPが採用し、既存の慣行は、これらの加入者への証明書の発行のための基礎を形成します。リソースPKIは、組織の身元を認証するために使用されるべきではなく、むしろ彼らが保持INRSへの加入をバインドすることに注意することが重要です。アイデンティティは、このPKIによってためvouchedされていないので、証明書の申請手続き等、法的組織名を確認する必要はありません
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 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.
証明書のアプリケーションは、INR保有者のCAの記録に基づいて、CAを操作するエンティティの通常のビジネス慣行に基づいて承認されなければなりません。各CAは、要求者が要求者にCA発行の証明書にバインドされる公開鍵に対応する秘密鍵を保持していることを確認するために、3.2.1項で規定された手順に従わなければなりません。証明書申請が承認されている方法の詳細は、問題のCAのCPSに記述されなければなりません。
No stipulation. As part of its CPS, each CA MUST declare its expected time frame to process (approve, issue, and publish) a certificate application.
規定なしません。そのCPSの一環として、各CAは、証明書の申請を処理する（、問題を承認、およびパブリッシュ）するために、その予想される時間枠を宣言する必要があります。
If a CA determines that the request is acceptable, it MUST issue the corresponding certificate and publish it in the RPKI distributed repository system via publication of the certificate at the CA's repository publication point.
CAは、要求が受け入れ可能であると判断した場合、それは対応する証明書を発行したCAのリポジトリ出版点における証明書の公開を介しRPKI分散リポジトリシステムでそれを公開する必要があります。
The CA MUST notify the subscriber when the certificate is published. The means by which a subscriber is notified MUST be defined by each CA in its CPS.
証明書が発行されている場合、CAは、加入者に通知しなければなりません。加入者が通知される手段は、CPSの各CAによって定義されなければなりません。
Within the timeframe specified in its CPS, the CA MUST place the certificate in the repository and notify the subscriber. This MAY be done without subscriber review and acceptance. Each CA MUST state in its CPS the procedures it follows for publishing of the certificate and notification to the subscriber.
そのCPSに規定している期間内に、CAは、リポジトリに証明書を配置し、加入者に通知しなければなりません。これは、加入者のレビューと受け入れずに行うことができます。各CAは、CPSに、それが加入者に証明書と通知の発行のために以下の手順を述べなければなりません。
Certificates MUST be published in the RPKI distributed repository system via publication of the certificate at the CA's repository publication point as per the conduct described in Section 4.4.1. The procedures for publication MUST be defined by each CA in its CPS.
証明書は、セクション4.4.1に記載の行為当たりとしてCAのリポジトリ出版点における証明書の公開を介しRPKI分散リポジトリシステムに掲載されなければなりません。出版のための手順は、CPSの各CAによって定義されなければなりません。
The CPS of each CA MUST indicate whether any other entities will be notified when a certificate is issued.
各CAのCPSは、証明書が発行されたとき、他のエンティティに通知するかどうかを指定する必要があります。
A summary of the use model for the RPKI is provided below.
RPKIのための使用モデルの概要は以下のとおりです。
Each holder of an INR is eligible to request an X.509 [X.509] CA certificate containing appropriate RFC 3779 extensions. Holders of CA resource certificates also MAY issue EE certificates to themselves to enable verification of RPKI signed objects that they generate.
INRの各ホルダーは適切なRFC 3779のに拡張機能を含むX.509 [X.509] CA証明書を要求する資格があります。 CAリソース証明書の保有者はまた、RPKIの検証を可能にするために、自分自身にEE証明書を発行することができる、彼らが生成するオブジェクトに署名しました。
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証明書の拡張検証アルゴリズムを指定RPKI証明書プロファイル[RFC6487]と一貫した方法で証明書を検証しなければなりません。
This section describes the procedures for certificate renewal. Certificate renewal is the issuance of a new certificate to replace an old one prior to its expiration. Only the validity dates and the serial number (the field in the certificate, not the DN attribute) are changed. The public key and all other information remain the same.
このセクションでは、証明書の更新のための手順を説明します。証明書の更新は、その満了前の古いものを置き換えるために新しい証明書を発行しています。唯一の有効期間と（証明書ではなく、DN属性のフィールド）のシリアル番号が変更されます。公開鍵と他のすべての情報は同じまま。
A certificate MUST be processed for renewal based on its expiration date or a renewal request from the subscriber. Prior to the expiration of an existing subscriber's certificate, it is the responsibility of the subscriber to renew the certificate to maintain continuity of certificate usage. If the issuing CA initiates the renewal process based on the certificate expiration date, then that CA MUST notify the holder in advance of the renewal process. The validity interval of the new (renewed) certificate SHOULD overlap that of the previous certificate to ensure continuity of certificate usage. It is RECOMMENDED that the renewed certificate be issued and published at least 1 week prior to the expiration of the certificate it replaces.
証明書は、その有効期限または加入者からの更新要求に基づいて、更新のために処理しなければなりません。既存の加入者の証明書の有効期限の前に、証明書の使用方法の連続性を維持するために証明書を更新するために、加入者の責任です。発行CAは、証明書の有効期限に基づいて更新プロセスを開始する場合、そのCAは、更新プロセスの前に所有者に通知しなければなりません。新しい（更新された）証明書の有効期間は、証明書の使用の継続性を確保するために、前の証明書のそれと重複すべきです。更新された証明書が発行され、少なくとも1週間前にそれが置き換えられた証明書の有効期限に公開されることが推奨されます。
Certificate renewal SHOULD incorporate the same public key as the previous certificate, unless the private key has been reported as compromised. If a new key pair is being used, the stipulations of Section 4.7 apply.
妥協として秘密鍵が報告されていない限り、証明書の更新は、以前の証明書と同じ公開鍵を組み込むべきです。新しい鍵ペアが使用されている場合は、4.7節の規定が適用されます。
Only the certificate holder or the issuing CA may initiate the renewal process. The certificate holder MAY request an early renewal, for example, if it expects to be unavailable to support the renewal process during the normal expiration period. An issuing CA MAY initiate the renewal process based on the certificate expiration date.
唯一の証明書の所有者または発行CAは、更新プロセスを開始することができます。それは、通常の有効期限の間、更新プロセスをサポートするために使用できないことを期待している場合、証明書の所有者は、例えば、早期の更新を要求することができます。発行元CAは、証明書の有効期限に基づいて更新プロセスを開始することができます。
Renewal procedures MUST ensure that the person or organization seeking to renew a certificate is in fact the subscriber (or authorized by the subscriber) of the certificate and the legitimate holder of the INR associated with the renewed certificate. Renewal processing MUST verify that the certificate in question has not been revoked.
更新手順は、証明書を更新しようとする個人または組織が実際に証明書と更新された証明書に関連付けられたINRの正当な所有者の加入者（又は加入者によって承認）であることを保証しなければなりません。更新処理は、当該証明書が失効していないことを確かめなければなりません。
No additional stipulations beyond those of Section 4.3.2.
4.3.2項のものを超えて追加の規定はありません。
No additional stipulations beyond those of Section 4.4.1.
4.4.1のものを超えて追加の規定はありません。
No additional stipulations beyond those of Section 4.4.2.
4.4.2項のものを超えて追加の規定はありません。
No additional stipulations beyond those of Section 4.4.3.
4.4.3項のものを超えて追加の規定はありません。
This section describes the procedures for certificate re-key. Certificate re-key is the issuance of a new certificate to replace an old one because the key needs to be replaced. Unlike with certificate renewal, the public key is changed.
このセクションでは、証明書の再キーのための手順を説明します。キーを交換する必要があるため、証明書の再キーは、古いものを置き換えるために新しい証明書を発行しています。証明書の更新とは異なり、公開鍵が変更されます。
Re-key of a certificate SHOULD be performed only when required, based on:
再鍵証明書の必要な場合にのみに基づいて、実行する必要があります。
1. knowledge or suspicion of compromise or loss of the associated private key, or
1.知識や関連する秘密鍵の妥協や損失の疑い、または
2. the expiration of the cryptographic lifetime of the associated key pair
2.関連する鍵ペアの暗号寿命の満了
A CA re-key operation has dramatic consequences, requiring the reissuance of all certificates issued by the re-keyed entity. So it should be performed only when necessary and in a way that preserves the ability of relying parties to validate certificates whose validation path includes the re-keyed entity. CA key rollover MUST follow the procedures defined in "CA Key Rollover in the RPKI" [RFC6489].
CAの再キー操作は、再キーイングエンティティによって発行されたすべての証明書の再発行が必要な、劇的な結果を持っています。だから、必要なときだけ、その検証パス再キー付きエンティティを含んでいる証明書を検証するために依拠当事者の能力を維持するような方法で実行する必要があります。 CAキーロールオーバーは、「RPKIでCAキーロールオーバー」[RFC6489]で定義された手順に従わなければなりません。
Note that if a certificate is revoked to replace the RFC 3779 extensions, the replacement certificate MUST incorporate the same public key rather than a new key. This applies when one is adding INRs (revocation not required) and when one is removing INRs (revocation required (see Section 4.8.1)).
証明書はRFC 3779の拡張機能を置き換えるために取り消された場合、交換用の証明書ではなく、新しいキーと同じ公開鍵を組み込まなければならないことに注意してください。 1は、（取り消しが必要ではない）INRSを追加されたときに、もう1つはINRS削除されたときにこれが適用されます（失効が必要（第4.8.1項を参照））。
If the re-key is based on a suspected compromise, then the previous certificate MUST be revoked.
再キーが疑わ妥協に基づいている場合、その前の証明書は取り消されなければなりません。
The holder of the certificate may request a re-key. In addition, the CA that issued the certificate MAY choose to initiate a re-key based on a verified compromise report.
証明書の所有者は、再鍵を要求することができます。また、証明書を発行したCAを検証妥協報告に基づいて再キーを開始することを選ぶかもしれません。
The re-key process follows the general procedures of certificate generation as defined in Section 4.3.
セクション4.3で定義されるようにリキー処理が証明書生成の一般的手順に従います。
No additional stipulations beyond those of Section 4.3.2.
4.3.2項のものを超えて追加の規定はありません。
No additional stipulations beyond those of Section 4.4.1.
4.4.1のものを超えて追加の規定はありません。
No additional stipulations beyond those of Section 4.4.2.
4.4.2項のものを超えて追加の規定はありません。
No additional stipulations beyond those of Section 4.4.3.
4.4.3項のものを超えて追加の規定はありません。
Modification of a certificate occurs to implement changes to selected attribute values in a certificate. In the context of the RPKI, the only changes that are accommodated by certificate modification are changes to the INR holdings described by the RFC 3779 extension(s) and changes to the SIA extension.
証明書の変更は、証明書内の選択した属性値の変更を実装するために発生します。 RPKIの文脈では、証明書の修正によって収容されている唯一の変更は、INRのRFC 3779拡張（S）によって記載保有し、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.)
以前に配布さINRSが証明書から削除された場合、古い証明書が取り消されなければならないと、新しい証明書が変更されたINRの保有を反映し、発行する必要があります。 （影響を受けたINRホルダが新しいSIA値を供給しない限り、新しい証明書でSIA拡張は、変更されません。）
Either the certificate holder or the issuer may initiate the certificate modification process.
証明書所有者または発行者のいずれかが、証明書の修正プロセスを開始することができます。
The CA MUST determine that the requested modification is appropriate and that the procedures for the issuance of a new certificate are followed (see Section 4.3).
CAは、要求された変更が適切であると判断しなければならないと、新しい証明書を発行するための手順は、（4.3節を参照）が続いていること。
No additional stipulations beyond those of Section 4.3.2.
4.3.2項のものを超えて追加の規定はありません。
No additional stipulations beyond those of Section 4.4.1.
4.4.1のものを超えて追加の規定はありません。
No additional stipulations beyond those of Section 4.4.2.
4.4.2項のものを超えて追加の規定はありません。
No additional stipulations beyond those of Section 4.4.3.
4.4.3項のものを超えて追加の規定はありません。
A certificate MUST be revoked (and published on a CRL) if there is reason to believe that there has been a compromise of a subscriber's private key. A certificate also MAY be revoked to invalidate a data object signed by the private key associated with that certificate. Other circumstances that justify revocation of a certificate MAY be specified in a CA's CPS.
加入者の秘密鍵の妥協があったと信じるに足る理由がある場合、証明書が失効した（とCRLに公開）されなければなりません。証明書はまた、その証明書に関連付けられた秘密鍵によって署名されたデータオブジェクトを無効にするために取り消すことができます。証明書の失効を正当化する他の状況は、CAのCPSに指定することができます。
Note: If new INRs are being added to an organization's existing distribution, the old certificate need not be revoked. Instead, a new certificate MAY be issued with both the old and the new resources and the old key. If INRs are being removed or if there has been a key compromise, then the old certificate MUST be revoked (and a re-key MUST be performed in the event of key compromise).
注：新しいINRSは、組織の既存のディストリビューションに追加されている場合は、古い証明書を失効させる必要はありません。代わりに、新しい証明書は、古いものと新しいリソースと古いキーの両方を発行することができます。 INRSは削除されているか、キー妥協があった場合は、古い証明書を失効させる必要があります（再キーは、キーの妥協のときに実行されなければならない）場合。
This MUST be defined in the CPS of the organization that issued the certificate.
これは、証明書を発行した組織のCPSで定義する必要があります。
A subscriber MAY submit a request to the certificate issuer for a revocation. This request MUST identify the certificate to be revoked and MUST be authenticated. The procedures for making the request MUST be described in the CPS for each CA. The RPKI provisioning document [RFC6492] describes a protocol that MAY be used to make revocation requests.
加入者が失効の証明書発行者に要求を提出することができます。この要求は、失効する証明書を特定しなければなりませんし、認証される必要があります。要求を行うための手順は、各CAのCPSに記載されなければなりませんRPKIプロビジョニングドキュメント[RFC6492]は失効要求を行うために使用されるかもしれプロトコルを記述します。
A certificate issuer MUST notify the subscriber when revoking a certificate. The notification requirement is satisfied by CRL publication. The CPS for a CA MUST indicate the means by which the CA will inform a subscriber of certificate revocation.
証明書を失効するとき、証明書発行者は、加入者に通知しなければなりません。通知要求はCRL公開によって満たされます。 CAのためのCPSは、CAが証明書失効の加入者に通知しますする手段を示さなければなりません。
A subscriber SHOULD request revocation as soon as possible after the need for revocation has been identified. There is no specified grace period for the subscriber in this process.
加入者は、できるだけ早く失効の必要性が確認された後に失効を要求すべきです。このプロセスでは、加入者のための指定された猶予期間はありません。
No stipulation. Each CA SHOULD specify its expected revocation processing time in its CPS.
規定なしません。各CAは、そのCPSにその期待失効処理時間を指定する必要があります。
A relying party MUST acquire and check the most recent, scheduled CRL from the issuer of the certificate, whenever the relying party validates a certificate.
依存者が証明書を検証するたびに依拠当事者は、証明書の発行者から最新のスケジュールCRLを取得し、チェックしなければなりません。
The CRL issuance frequency MUST be determined by each CA and stated in its CPS. Each CRL carries a nextScheduledUpdate value, and a new CRL MUST be published at or before that time. A CA MUST set the nextUpdate value when it issues a CRL to signal when the next scheduled CRL will be issued.
CRLの発行頻度は、各CAによって決定され、そのCPSに記載されなければなりません。各CRLはnextScheduledUpdate値を搬送し、新しいCRLは、その時またはそれ以前に公表しなければなりません。それは次のスケジュールされたCRLが発行される際に通知するためにCRLを発行するCAは、nextUpdateの値を設定しなければなりません。
The CPS for each CA MUST specify the maximum latency associated with posting its CRL to the repository system.
各CAのCPSは、リポジトリシステムへのCRLを投稿に関連付けられた最大待ち時間を指定しなければなりません。
This PKI does not make provision for use of the Online Certificate Status Protocol (OCSP) [RFC2560] or Server-Based Certificate Validation Protocol (SCVP) [RFC5055]. This is because it is anticipated that the primary RPs (ISPs) will acquire and validate certificates for all participating resource holders. These protocols are not designed for such large-scale, bulk certificate status checking. RPs MUST check for new CRLs at least daily. It is RECOMMENDED that RPs perform this check several times per day, but no more than 8-12 times per day (to avoid excessive repository accesses).
このPKIは、オンライン証明書状態プロトコル（OCSP）[RFC2560]またはサーバーベースの証明書の検証プロトコル（SCVP）[RFC5055]を使用するための準備をしません。主のRP（ISPが）を取得し、すべての参加リソースの所有者のための証明書を検証することが予想されるためです。これらのプロトコルは、このような大規模な、バルク証明書状態のチェックのために設計されていません。 RPは少なくとも毎日新しいCRLをチェックしなければなりません。 （過度のリポジトリにアクセスを避けるために）RPは、このチェックに1日に数回を実行することをお勧めしませんが、一日あたりせいぜい8-12倍されます。
Each CA MUST maintain physical security controls for its operation that are commensurate with those employed by the organization in the management of INR distribution. The physical controls employed for CA operation MUST be specified in its CPS. Possible topics to be covered in the CPS are shown below. (These sections are taken from [RFC3647].)
各CAは、INRの分布の管理に組織が用いられているものに見合ったその動作のための物理的なセキュリティ制御を維持しなければなりません。 CAの操作に使用する物理的なコントロールは、そのCPSで指定する必要があります。 CPSでカバーすることが可能なトピックは以下のとおりです。 （これらのセクションは[RFC3647]から取られています。）
Each CA MUST maintain procedural security controls that are commensurate with those employed by the organization in the management of INR distribution. The procedural security controls employed for CA operation MUST be specified in its CPS. Possible topics to be covered in the CPS are shown below. (These sections are taken from [RFC3647].)
各CAは、INRの分布の管理に組織が用いられているものに見合った手続きセキュリティコントロールを維持しなければなりません。 CAの操作に使用する手続きのセキュリティコントロールは、そのCPSで指定する必要があります。 CPSでカバーすることが可能なトピックは以下のとおりです。 （これらのセクションは[RFC3647]から取られています。）
Each CA MUST maintain personnel security controls that are commensurate with those employed by the organization in the management of INR distribution. The details for each CA MUST be specified in its CPS.
各CAは、INRの分布の管理に組織が用いられているものに見合った人員のセキュリティコントロールを維持しなければなりません。各CAの詳細は、そのCPSで指定する必要があります。
Details of how a CA implements the audit logging described in Sections 5.4.1 to 5.4.8 MUST be addressed in its CPS.
CAは5.4.8に、セクション5.4.1で説明した監査ログは、そのCPSに取り組まなければならないの実装方法の詳細。
Audit records MUST be generated for the basic operations of the certification authority computing equipment. Audit records MUST include the date, time, responsible user or process, and summary content data relating to the event. Auditable events include:
監査レコードは、認証局のコンピューティング機器の基本的な操作のために生成されなければなりません。監査レコードは、日付、時刻、責任あるユーザーまたはプロセス、およびイベントに関連する要約コンテンツデータを含まなければなりません。監査可能なイベントは次のとおりです。
o Access to CA computing equipment (e.g., logon, logout)
OアクセスCAのコンピューティング装置（例えば、ログイン、ログアウト）
o Messages received requesting CA actions (e.g., certificate requests, certificate revocation requests, compromise notifications)
Oメッセージは、要求元のCAのアクション（例えば、証明書要求、証明書失効要求、妥協通知）を受け
o Certificate creation, modification, revocation, or renewal actions
O証明書の作成、変更、取り消し、または更新アクション
o Posting of any material to a repository
リポジトリへの材料のOの投稿
o Any attempts to change or delete audit data
監査データを変更または削除するために、任意の試みO
o Key generation
O鍵の生成
o Software and/or configuration updates to the CA
CAへのOソフトウェアおよび/または構成の更新
o Clock adjustments
Oクロックの調整
Each CA MUST establish its own procedures for review of audit logs.
各CAは、監査ログのレビューのために、独自の手順を確立しなければなりません。
Each CA MUST establish its own polices for retention of audit logs.
各CAは、監査ログの保持のための独自のポリシーを確立する必要があります。
The audit log SHOULD be protected based on current industry standards.
監査ログには、現在の業界標準に基づいて保護されなければなりません。
The audit log SHOULD be backed up based on current industry standards.
監査ログには、現在の業界標準に基づいてバックアップする必要があります。
The RPKI subsystems of a registry or ISP SHOULD participate in any vulnerability assessments that these organizations run as part of their normal business practice.
レジストリまたはISPのRPKIサブシステムは、これらの組織が通常のビジネス慣行の一部として実行するすべての脆弱性の評価に参加すべきです。
When a CA wishes to change keys, it MUST acquire a new certificate containing its new public key. See [RFC6489] for a description of how key changeover is effected in the RPKI.
CAキーを変更したい場合は、その新しい公開鍵を含む新しい証明書を取得する必要があります。 RPKIに行われるか、キーの切り替えの詳細については、[RFC6489]を参照してください。
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では、各加入者は、そのエンティティに配布された指定INRSの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機能（セクション1.3.2を参照）CAとして動作する同じエンティティによって提供されなければならないので、RAのための別個の規定は存在しません。
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 organizations. Details of each CA's security controls MUST be described in the CPS issued by the CA.
ネットワーク加入者にINRSを配布する組織は、これらの分布に対して権限のあります。このPKIは、彼らがそれらに配布されているINRSの保有者であることを実証するためにISPやネットワーク加入者を有効にするために設計されています。したがって、このPKIのためのCAと加入者が使用するセキュリティコントロールは、唯一現存する組織でINRデータの配信を管理するための手続きに適用されるものと同様に安全である必要があります。各CAのセキュリティコントロールの詳細については、CAによって発行されたCPSに記述しなければなりません
In most instances, public key pairs will be generated by the subject, i.e., the organization receiving the distribution of INRs. However, some CAs MAY offer to generate key pairs on behalf of their subjects at the request of the subjects, e.g., to accommodate subscribers who do not have the ability to perform key generation in a secure fashion. (The CA has to check the quality of the keys only if it generates them; see Section 6.1.6.) Since the keys used in this PKI are not for non-repudiation purposes, generation of key pairs by CAs does not inherently undermine the security of the PKI. Each CA MUST describe its key pair generation procedures in its CPS.
ほとんどの場合、公開鍵ペア、すなわち、組織がINRSの配布を受け、被験者によって生成されます。ただし、一部のCAは安全な方法で鍵生成を実行する能力を持っていない加入者に対応するために、例えば、被験者の要求に応じてそれぞれの科目に代わって鍵ペアを生成するために提供することがあります。 （CAはそれがそれらを生成した場合にのみ、キーの品質をチェックする必要があります。セクション6.1.6を参照してください。）このPKIで使用されるキーは、否認防止の目的ではないので、CAによって鍵ペアの生成は、本質的に弱体化しませんPKIのセキュリティ。各CAは、そのCPSにその鍵ペアの生成手順を説明しなければなりません。
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は、加入者のための鍵ペアの生成サービスを提供している場合は、そのCPSは、秘密鍵を安全な方法で加入者に配信される手段を記述しなければなりません。
When a public key is transferred to the issuing CA to be certified, it MUST be delivered through a mechanism ensuring that the public key has not been altered during transit and that the subscriber possesses the private key corresponding to the transferred public key.
公開鍵が認証される発行CAに転送される場合には、公開鍵が輸送中及び加入者が転送された公開鍵に対応する秘密鍵を有すること変更されていないことを保証する機構を介して送達されなければなりません。
CA public keys for all entities (other than trust anchors) are contained in certificates issued by other CAs. These certificates MUST be published in the RPKI distributed repository system. Relying parties download these certificates from the repositories. Public key values and associated data for (putative) trust anchors are distributed out of band and accepted by relying parties on the basis of locally defined criteria.
（トラストアンカーを除く）すべてのエンティティのためのCAの公開鍵は、他のCAによって発行された証明書に含まれています。これらの証明書は、RPKI分散リポジトリシステムに公開する必要があります。依拠当事者は、リポジトリからこれらの証明書をダウンロードしてください。公開キーの値と（推定）トラストアンカーのための関連するデータは、帯域外に分布し、ローカルに定義された基準に基づき、依拠当事者によって受け入れられています。
The algorithms and key sizes used in the RPKI are specified in "A Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure" [RFC6485].
アルゴリズムとRPKIに使用されるキーのサイズは、「リソースの公開鍵インフラストラクチャで使用するためのアルゴリズムと鍵のサイズのためのプロフィール」[RFC6485]で指定されています。
The public key parameters used in the RPKI are specified in [RFC6485]. Each subscriber is responsible for performing checks on the quality of its key pair. A CA is not responsible for performing such checks for subscribers except in the case where the CA generates the key pair on behalf of the subscriber.
RPKIに使用される公開鍵のパラメータは、[RFC6485]で指定されています。各加入者は、その鍵ペアの品質にチェックを実行する責任があります。 CAは、CAが加入者に代わって鍵ペアを生成する場合を除き、加入者のために、このようなチェックを実行するための責任を負いません。
The Key usage extension bit values used in the RPKI are specified in RPKI Certificate Profile [RFC6487].
RPKIに使用される鍵使用拡張ビット値はRPKI証明書プロファイル[RFC6487]で指定されています。
6.2. Private Key Protection and Cryptographic Module Engineering Controls
6.2. 秘密鍵の保護、及び暗号モジュール技術管理
The cryptographic module standards and controls employed by each CA MUST be described in the CPS issued by that CA.
各CAが採用した暗号モジュールの標準とコントロールは、そのCAによって発行されたCPSに記述しなければなりません
CAs MAY employ multi-person controls to constrain access to their private keys, but this is not a requirement for all CAs in the PKI. The CPS for each CA MUST describe which, if any, multi-person controls it employs.
CAは、マルチ人は自分の秘密鍵へのアクセスを制限するために制御し使用することができるが、これはPKIにおけるすべてのCAの要件ではありません。各CAのCPSは、もしあれば、マルチ人は、それが採用制御し、説明しなければなりません。
No private key escrow procedures are required for the RPKI.
いいえ、秘密鍵エスクロー手順がRPKIのために必要ありません。
Because of the adverse operational implications associated with the loss of use of a CA private key in the PKI, each CA MUST employ a secure means to back up its private keys. The details of the procedures for backing up a CA's private key MUST be described in the CPS issued by the CA.
そのためPKI内のCA秘密鍵の使用の損失に関連する有害運用意味合いで、各CAは、その秘密鍵をバックアップするための安全な手段を使わなければなりません。 CAの秘密鍵をバックアップするための手順の詳細については、CAによって発行されたCPSに記述しなければなりません
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の秘密鍵をアーカイブするために使用されるプロセスと手順の詳細については、CAによって発行されたCPSに記述しなければなりません
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の秘密鍵を転送するために使用されるプロセスと手順の詳細については、CAによって発行されたCPSに記述しなければなりません
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の秘密鍵を格納し、不正使用から保護するために使用されるプロセスと手順の詳細については、CAによって発行されたCPSに記述しなければなりません
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の秘密鍵をアクティブにするために使用されるプロセスと手順の詳細については、CAによって発行されたCPSに記述しなければなりません
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の秘密鍵を無効化するために使用されるプロセスと手順の詳細については、CAによって発行されたCPSに記述しなければなりません
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の秘密鍵を破壊するために使用されるプロセスと手順の詳細については、CAによって発行されたCPSに記述しなければなりません
The security rating of the cryptographic module MUST be described in the CPS issued by the CA.
暗号モジュールのセキュリティ評価は、CAによって発行されたCPSに記述しなければなりません
Because this PKI does not support non-repudiation, there is no need to archive public keys.
このPKIは、否認防止をサポートしていないため、公開鍵をアーカイブする必要はありません。
The INRs held by a CA may periodically change when it receives new distributions. To minimize disruption, the CA key pair MUST NOT change when INRs are added to its certificate.
それは新しいディストリビューションを受信したときにCAが保持しているINRSは定期的に変更されることがあります。 INRSは、その証明書に追加されたときに混乱を最小限に抑えるために、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 case, the validity period for certificates MUST be chosen by the issuing CA and described in its CPS.
ISPやネットワークの加入者証明書はサービス契約の期間に関連付けられている場合は、これらの証明書は、これらの契約の期間に見合った有効期間を持つ必要があります。いずれの場合においても、証明書の有効期間は、発行元CAによって選択されなければならなくて、そのCPSに記載します。
Each CA MUST document in its CPS how it will generate, install, and protect its activation data.
各CAには、それは、生成、インストール、およびその活性化データを保護する方法をそのCPSに文書化しなければなりません。
Each CA MUST document the technical security requirements it employs for CA computer operation in its CPS.
各CAは、そのCPSでCAのコンピュータ操作のために採用して技術的なセキュリティ要件を文書化しなければなりません。
The CPS for each CA MUST document any system development controls required by that CA, if applicable.
該当する場合は、各CAのCPSは、そのCAが必要とするシステム開発のコントロールを文書化しなければなりません。
The CPS for each CA MUST document the security controls applied to the software and equipment used for this PKI. These controls MUST be commensurate with those used for the systems used by the CAs for managing the INRs.
各CAのCPSは、このPKIのために使用するソフトウェアや機器に適用されるセキュリティコントロールを文書化しなければなりません。これらのコントロールは、INRSを管理するためにCAが使用されるシステムに使用されるものと相応でなければなりません。
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のCPSは、このPKIのために使用される機器（ハードウェア及びソフトウェア）は、調達設置、維持、および更新する方法を文書化しなければなりません。これは、INRSの管理や配布のための機器が処理される方法に見合った方法で行われなければなりません。
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のCPSは、CAの操作に使用するネットワークセキュリティ統制を文書化しなければなりません。これらは、それがINRSの配布を管理するために使用されるコンピュータのために利用し保護に見合っでなければなりません。
The RPKI does not make use of timestamping.
RPKIは、タイムスタンプを使用しません。
Please refer to the RPKI Certificate and CRL Profile [RFC6487].
RPKI証明書とCRLプロフィール[RFC6487]を参照してください。
The certificate policy for a typical PKI defines the criteria against which prospective CAs are evaluated and establishes requirements that they must meet. In this PKI, the CAs are already authoritative for the management of INRs, and the PKI simply supports verification of the distribution of these resources to network subscribers. Accordingly, whatever audit and other assessments are already used to ensure the security of the management of INRs is sufficient for this PKI. The CPS for each CA MUST describe what audits and other assessments are used.
典型的なPKIの証明書ポリシーは、将来のCAが評価し、それらが満たさなければならない要件を確立しているそれに対して基準を定義します。このPKIでは、CAはすでにINRSの管理のための権威であり、PKIは、単にネットワークの加入者にこれらの資源の配分の検証をサポートしています。したがって、すでにINRSの管理のセキュリティを確保するために使用されているものは何でも監査及びその他の評価このPKIのために十分です。各CAのCPSを使用しているかの監査及び他の評価を説明しなければなりません。
As noted throughout this certificate policy, the organizations managing the distribution of INRs are authoritative in their roles as managers of this data. They MUST operate this PKI to allow the holders of INRs to generate digitally signed data that attest to these distributions. Therefore, the manner in which the organizations in question manage their business and legal matters for this PKI MUST be commensurate with the way in which they already manage business and legal matters in their existing roles. Since there is no single set of responses to this section that would apply to all organizations, the topics listed in Sections 4.9.1 to 4.9.11 and 4.9.13 to 4.9.17 of RFC 3647 SHOULD be covered in the CPS issued by each CA, although not every CA may choose to address all of these topics. Please note that the topics in the above sections of RFC 3647 become sections 9.1 to 9.11 and 9.13 to 9.17 in the CPS.
この証明書ポリシー全体で述べたように、INRSの配布を管理する組織では、このデータの管理職としての役割に権威あります。彼らはINRSの保有者は、これらの分布を証明するデジタル署名されたデータを生成できるようにするには、このPKIを操作しなければなりません。そのため、当該の組織がこのPKIのために彼らのビジネスや法的な問題を管理する方法は、彼らはすでに彼らの既存の役割で、ビジネスや法的な問題を管理する方法に見合っでなければなりません。すべての組織に適用されるこのセクションへの応答の単一のセットが存在しないため、RFC 3647の4.9.17に4.9.11および4.9.13へのセクション4.9.1に記載されているトピックは、各によって発行されたCPSに含まれるべきですCAは、ありませんが、すべてのCAは、次の項目のすべてに対処することもできます。 RFC 3647の上記のセクションのトピックでは、CPSで9.17に9.11と9.13に9.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を修正するための手順は、このドキュメントを更新または廃止新しい（BCP）RFCの形でIESGから書面による通知を介してです。
Successive versions of the CP will be published with the following statement:
CPの連続したバージョンでは、次のステートメントで公開されます。
This CP takes effect on MM/DD/YYYY.
このCPは、MM / DD / YYYYに有効になります。
MM/DD/YYYY MUST be a minimum of 6 months from the date of publication.
MM / DD / YYYYは、発行日から6ヶ月の最小値でなければなりません。
If the IESG judges that changes to the CP do not materially reduce the acceptability of certificates issued for RPKI purposes, there will be no change to the CP OID. If the IESG judges that changes to the CP do materially change the acceptability of certificates for RPKI purposes, then there MUST be a new CP OID.
CPに変更IESGの裁判官が著しくRPKIの目的のために発行された証明書の受容性を低下させない場合は、CPのOIDへの変更はありません。 CPに変更IESGの裁判官が著しくRPKIの目的のために証明書の受容性を変えなければ、新しいCP OIDがあるに違いありません。
According to X.509, a certificate policy (CP) is "a named set of rules that indicates the applicability of a certificate to a particular community and/or class of applications with common security requirements." A CP may be used by a relying party to help in deciding whether a certificate and the binding therein are sufficiently trustworthy and otherwise appropriate for a particular application. This document describes the CP for the Resource Public Key Infrastructure (RPKI). There are separate documents (CPSs) that cover the factors that determine the degree to which a relying party can trust the binding embodied in a certificate. The degree to which such a binding can be trusted depends on several factors, e.g., the practices followed by the CA in authenticating the subject; the CA's operating policy, procedures, and technical security controls, including the scope of the subscriber's responsibilities (for example, in protecting the private key), and the stated responsibilities and liability terms and conditions of the CA (for example, warranties, disclaimers of warranties, and limitations of liability).
X.509によると、証明書ポリシー（CP）は、「特定のコミュニティおよび/または共通のセキュリティ要件を持つアプリケーションのクラスへの証明書の適用可能性を示したルールの名前付きセット」です。 CPは、証明書と結合そこには十分に信頼できると特定のアプリケーションのためにそうでなければ適切であるかどうかを決定する際に役立つように、依拠当事者によって使用されてもよいです。この文書では、資源公開鍵インフラストラクチャ（RPKI）のためのCPを説明しています。依存者が証明書に具体バインディング信頼できる程度を決定する要因をカバーし、別の文書（CPSS）があります。そのような結合が信頼できる度合いは、慣行は、対象の認証に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に2つの以上のCAが同じ発行者名の下に証明書とCRLを発行するおそれがあります。リソース認証パス検証アルゴリズムに準拠パス検証実装は同じ鍵が対象（リソース証明書）と対応するCRLの両方に署名するために使用されたことを確認する（[RFC6487]を参照します）。だから、名前の衝突が、結果は変わりません。名前の一意性を前提とし、基本的なX.509パス検証アルゴリズムの使用は、有効または取り消さとして拒否されている有効な証明書として受け入れられて、取り消された証明書につながる可能性があります。依拠当事者は、彼らがこのポリシーの下で発行された証明書を検証するために使用するソフトウェアは、[RFC6487]で指定したのと同じキーは、証明書とそれに対応するCRLの両方に署名するために使用されたことを確認することを確認する必要があります。
The authors would like to thank Geoff Huston, Randy Bush, Andrei Robachevsky, and other members of the RPKI community for reviewing this document and Matt Lepinski for his help with the formatting.
著者は、フォーマットを持つ彼の助けのために、この文書やマットLepinskiを見直すためにジェフ・ヒューストン、ランディブッシュ、アンドレイRobachevsky、およびRPKIコミュニティの他のメンバーに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、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]リン、C.、ケント、S.、およびK.ソ、 "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]ヒューストン、G.、Loomans、R.、およびG.マイケルソン、 "リソース証明書リポジトリの構造用プロフィール"、RFC 6481、2012年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]ヒューストン、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]ヒューストン、G.、マイケルソン、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.
"RPKIでCAキーロールオーバー" [RFC6489]ヒューストン、G.、マイケルソン、G.、およびS.ケント、BCP 174、RFC 6489、2012年2月。
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC2560]マイヤーズ、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC.アダムス、 "X.509のインターネット公開鍵暗号基盤のオンライン証明書状態プロトコル - OCSP"、RFC 2560、1999年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.、フォード、W.、Sabett、R.、メリル、C.、およびS.ウー、 "インターネット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]フリーマン、T.、Housley氏、R.、Malpani、A.、クーパー、D.、およびW.ポーク、 "サーバーベースの証明書の検証プロトコル（SCVP）"、RFC 5055、2007年12月。
[RFC5736] Huston, G., Cotton, M., and L. Vegoda, "IANA IPv4 Special Purpose Address Registry", RFC 5736, January 2010.
[RFC5736]ヒューストン、G.、コットン、M.、およびL. Vegoda、 "IANAのIPv4特別目的アドレスレジストリ"、RFC 5736、2010年1月。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
[RFC6480] Lepinski、M.とS.ケント、 "安全なインターネットルーティングをサポートするインフラストラクチャ"、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.、ケント、S.、およびD.コング、 "ルート起源権限のプロファイル（資産収益率）"、RFC 6482、2012年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.、ヒューストン、G.、ケント、S.、およびM. Lepinski、 "リソース公開鍵インフラストラクチャのためのマニフェスト（RPKI）"、RFC 6486、2012年2月。
[RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A Protocol for Provisioning Resource Certificates", RFC 6492, February 2012.
[RFC6492]ヒューストン、G.、Loomans、R.、Ellacott、B.、およびR. Austeinと、RFC 6492、2012年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
スティーブン・ケントBBNテクノロジーズ10モールトンストリートケンブリッジMA 02138 USA
Phone: +1 617 873 3988 EMail: skent@bbn.com
電話：+1 617 873 3988 Eメール：skent@bbn.com
Derrick Kong BBN Technologies Moulton Street Cambridge MA 02138 USA
デリック・香港BBNテクノロジーズモールトンストリートケンブリッジMA 02138 USA
Phone: +1 617 873 1951 EMail: dkong@bbn.com
電話：+1 617 873 1951 Eメール：dkong@bbn.com
Karen Seo BBN Technologies 10 Moulton Street Cambridge MA 02138 USA
カレンソBBNテクノロジーズ10モールトンストリートケンブリッジMA 02138 USA
Phone: +1 617 873 3152 EMail: kseo@bbn.com
電話：+1 617 873 3152 Eメール：kseo@bbn.com
Ronald Watro BBN Technologies 10 Moulton Street Cambridge MA 02138 USA
ロナルドWatro BBNテクノロジーズ10モールトンストリートケンブリッジMA 02138 USA
Phone: +1 617 873 2551 EMail: rwatro@bbn.com
電話：+1 617 873 2551 Eメール：rwatro@bbn.com