[要約] RFC 7382は、Resource PKI（RPKI）の認証実践声明（CPS）のテンプレートに関するものです。このRFCの目的は、RPKIのCPSを作成するためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) S. Kent
Request for Comments: 7382 D. Kong
BCP: 173 K. Seo
Category: Best Current Practice BBN Technologies
ISSN: 2070-1721 April 2015
Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI)
リソースPKI（RPKI）の認定実務声明（CPS）のテンプレート
Abstract
概要
This document contains a template to be used for creating a Certification Practice Statement (CPS) for an organization that is part of the Resource Public Key Infrastructure (RPKI), e.g., a resource allocation registry or an ISP.
このドキュメントには、リソース公開レジストリ（ISP）などのリソース公開鍵インフラストラクチャ（RPKI）の一部である組織の認証実践ステートメント（CPS）を作成するために使用されるテンプレートが含まれています。
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（Internet Engineering Task Force）の製品です。これは、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/rfc7382.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7382で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
Preface ............................................................8
1. Introduction ....................................................9
1.1. Overview ..................................................10
1.2. Document Name and Identification ..........................10
1.3. PKI Participants ..........................................11
1.3.1. Certification Authorities ..........................11
1.3.2. Registration Authorities ...........................11
1.3.3. Subscribers ........................................11
1.3.4. Relying Parties ....................................11
1.3.5. Other Participants .................................12
1.4. Certificate Usage .........................................12
1.4.1. Appropriate Certificate Uses .......................12
1.4.2. Prohibited Certificate Uses ........................12
1.5. Policy Administration .....................................12
1.5.1. Organization Administering the Document ............12
1.5.2. Contact Person .....................................12
1.5.3. Person Determining CPS Suitability for the Policy ..12
1.5.4. CPS Approval Procedures ............................13
1.6. Definitions and Acronyms ..................................13
2. Publication and Repository Responsibilities ....................14
2.1. Repositories ..............................................14
2.2. Publication of Certification Information ..................14
2.3. Time or Frequency of Publication ..........................14
2.4. Access Controls on Repositories ...........................15
3. Identification and Authentication ..............................15
3.1. Naming ....................................................15
3.1.1. Types of Names .....................................15
3.1.2. Need for Names to Be Meaningful ....................15
3.1.3. Anonymity or Pseudonymity of Subscribers ...........15
3.1.4. Rules for Interpreting Various Name Forms ..........15
3.1.5. Uniqueness of Names ................................16
3.1.6. Recognition, Authentication, and Role of
Trademarks .........................................16
3.2. Initial Identity Validation ...............................16
3.2.1. Method to Prove Possession of Private Key ..........16
3.2.2. Authentication of Organization Identity ............16
3.2.3. Authentication of Individual Identity ..............17
3.2.4. Non-verified Subscriber Information ................17
3.2.5. Validation of Authority ............................17
3.2.6. Criteria for Interoperation ........................17
3.3. Identification and Authentication for Re-key Requests .....18
3.3.1. Identification and Authentication for
Routine Re-key .....................................18
3.3.2. Identification and Authentication for
Re-key after Revocation ............................18
3.4. Identification and Authentication for Revocation Request ..18
4. Certificate Life Cycle Operational Requirements ................18
4.1. Certificate Application ...................................18
4.1.1. Who Can Submit a Certificate Application ...........18
4.1.2. Enrollment Process and Responsibilities ............19
4.2. Certificate Application Processing ........................19
4.2.1. Performing Identification and
Authentication Functions ...........................19
4.2.2. Approval or Rejection of Certificate Applications ..19
4.2.3. Time to Process Certificate Applications ...........19
4.3. Certificate Issuance ......................................19
4.3.1. CA Actions during Certificate Issuance .............19
4.3.2. Notification to Subscriber by the CA of
Issuance of Certificate ............................20
4.3.3. Notification of Certificate Issuance by the
CA to Other Entities ...............................20
4.4. Certificate Acceptance ....................................20
4.4.1. Conduct Constituting Certificate Acceptance ........20
4.4.2. Publication of the Certificate by the CA ...........20
4.4.3. Notification of Certificate Issuance by the
CA to Other Entities ...............................20
4.5. Key Pair and Certificate Usage ............................20
4.5.1. Subscriber Private Key and Certificate Usage .......20
4.5.2. Relying Party Public Key and Certificate Usage .....21
4.6. Certificate Renewal .......................................21
4.6.1. Circumstance for Certificate Renewal ...............21
4.6.2. Who May Request Renewal ............................21
4.6.3. Processing Certificate Renewal Requests ............22
4.6.4. Notification of New Certificate Issuance to
Subscriber .........................................22
4.6.5. Conduct Constituting Acceptance of a
Renewal Certificate ................................22
4.6.6. Publication of the Renewal Certificate by the CA ...22
4.6.7. Notification of Certificate Issuance by the
CA to Other Entities ...............................22
4.7. Certificate Re-key ........................................22
4.7.1. Circumstance for Certificate Re-key ................22
4.7.2. Who May Request Certification of a New Public Key ..23
4.7.3. Processing Certificate Re-keying Requests ..........23
4.7.4. Notification of New Certificate Issuance to
Subscriber .........................................23
4.7.5. Conduct Constituting Acceptance of a
Re-keyed Certificate ...............................23
4.7.6. Publication of the Re-keyed Certificate by the CA ..23
4.7.7. Notification of Certificate Issuance by the
CA to Other Entities ...............................23
4.8. Certificate Modification ..................................23
4.8.1. Circumstance for Certificate Modification ..........23
4.8.2. Who May Request Certificate Modification ...........24
4.8.3. Processing Certificate Modification Requests .......24
4.8.4. Notification of Modified Certificate
Issuance to Subscriber .............................24
4.8.5. Conduct Constituting Acceptance of Modified
Certificate ........................................24
4.8.6. Publication of the Modified Certificate by the CA ..24
4.8.7. Notification of Certificate Issuance by the
CA to Other Entities ...............................24
4.9. Certificate Revocation and Suspension .....................25
4.9.1. Circumstances for Revocation .......................25
4.9.2. Who Can Request Revocation .........................25
4.9.3. Procedure for Revocation Request ...................25
4.9.4. Revocation Request Grace Period ....................25
4.9.5. Time within Which CA Must Process the
Revocation Request .................................25
4.9.6. Revocation Checking Requirement for Relying
Parties ............................................25
4.9.7. CRL Issuance Frequency .............................26
4.9.8. Maximum Latency for CRLs ...........................26
4.10. Certificate Status Services ..............................26
5. Facility, Management, and Operational Controls .................26
5.1. Physical Controls .........................................26
5.1.1. Site Location and Construction .....................26
5.1.2. Physical Access ....................................26
5.1.3. Power and Air Conditioning .........................26
5.1.4. Water Exposures ....................................26
5.1.5. Fire Prevention and Protection .....................26
5.1.6. Media Storage ......................................26
5.1.7. Waste Disposal .....................................26
5.1.8. Off-Site Backup ....................................26
5.2. Procedural Controls .......................................27
5.2.1. Trusted Roles ......................................27
5.2.2. Number of Persons Required per Task ................27
5.2.3. Identification and Authentication for Each Role ....27
5.2.4. Roles Requiring Separation of Duties ...............27
5.3. Personnel Controls ........................................27
5.3.1. Qualifications, Experience, and Clearance
Requirements .......................................27
5.3.2. Background Check Procedures ........................27
5.3.3. Training Requirements ..............................27
5.3.4. Retraining Frequency and Requirements ..............27
5.3.5. Job Rotation Frequency and Sequence ................27
5.3.6. Sanctions for Unauthorized Actions .................27
5.3.7. Independent Contractor Requirements ................27
5.3.8. Documentation Supplied to Personnel ................27
5.4. Audit Logging Procedures ..................................28
5.4.1. Types of Events Recorded ...........................28
5.4.2. Frequency of Processing Log ........................28
5.4.3. Retention Period for Audit Log .....................28
5.4.4. Protection of Audit Log ............................28
5.4.5. Audit Log Backup Procedures ........................28
5.4.6. Audit Collection System (Internal vs.
External) [OMITTED] ................................29
5.4.7. Notification to Event-Causing Subject [OMITTED] ....29
5.4.8. Vulnerability Assessments ..........................29
5.5. Records Archival [OMITTED] ................................29
5.6. Key Changeover ............................................29
5.7. Compromise and Disaster Recovery ..........................29
5.8. CA or RA Termination ......................................29
6. Technical Security Controls ....................................29
6.1. Key Pair Generation and Installation ......................29
6.1.1. Key Pair Generation ................................29
6.1.2. Private Key Delivery to Subscriber .................30
6.1.3. Public Key Delivery to Certificate Issuer ..........30
6.1.4. CA Public Key Delivery to Relying Parties ..........30
6.1.5. Key Sizes ..........................................30
6.1.6. Public Key Parameter Generation and Quality
Checking ...........................................30
6.1.7. Key Usage Purposes (as per X.509 v3 Key
Usage Field) .......................................30
6.2. Private Key Protection and Cryptographic Module
Engineering Controls ......................................31
6.2.1. Cryptographic Module Standards and Controls ........31
6.2.2. Private Key (n out of m) Multi-Person Control ......31
6.2.3. Private Key Escrow .................................31
6.2.4. Private Key Backup .................................31
6.2.5. Private Key Archival ...............................31
6.2.6. Private Key Transfer into or from a
Cryptographic Module ...............................31
6.2.7. Private Key Storage on Cryptographic Module ........31
6.2.8. Method of Activating Private Key ...................32
6.2.9. Method of Deactivating Private Key .................32
6.2.10. Method of Destroying Private Key ..................32
6.2.11. Cryptographic Module Rating .......................32
6.3. Other Aspects of Key Pair Management ......................32
6.3.1. Public Key Archival ................................32
6.3.2. Certificate Operational Periods and Key
Pair Usage Periods .................................32
6.4. Activation Data ...........................................32
6.4.1. Activation Data Generation and Installation ........32
6.4.2. Activation Data Protection .........................32
6.4.3. Other Aspects of Activation Data ...................33
6.5. Computer Security Controls ................................33
6.6. Life Cycle Technical Controls .............................33
6.6.1. System Development Controls ........................33
6.6.2. Security Management Controls .......................33
6.6.3. Life Cycle Security Controls .......................33
6.7. Network Security Controls .................................33
6.8. Time-Stamping .............................................33
7. Certificate and CRL Profiles ...................................33
8. Compliance Audit and Other Assessments .........................34
9. Other Business and Legal Matters ...............................34
9.1. Fees ......................................................34
9.1.1. Certificate Issuance or Renewal Fees ...............34
9.1.2. Certificate Access Fees [OMITTED] ..................34
9.1.3. Revocation or Status Information Access
Fees [OMITTED] .....................................34
9.1.4. Fees for Other Services (if Applicable) ............34
9.1.5. Refund Policy ......................................34
9.2. Financial Responsibility ..................................34
9.2.1. Insurance Coverage .................................34
9.2.2. Other Assets .......................................34
9.2.3. Insurance or Warranty Coverage for End-Entities ....34
9.3. Confidentiality of Business Information ...................34
9.3.1. Scope of Confidential Information ..................34
9.3.2. Information Not within the Scope of
Confidential Information ...........................34
9.3.3. Responsibility to Protect Confidential
Information ........................................34
9.4. Privacy of Personal Information ...........................34
9.4.1. Privacy Plan .......................................34
9.4.2. Information Treated as Private .....................35
9.4.3. Information Not Deemed Private .....................35
9.4.4. Responsibility to Protect Private Information ......35
9.4.5. Notice and Consent to Use Private Information ......35
9.4.6. Disclosure Pursuant to Judicial or
Administrative Process .............................35
9.4.7. Other Information Disclosure Circumstances .........35
9.5. Intellectual Property Rights (if Applicable) ..............35
9.6. Representations and Warranties ............................35
9.6.1. CA Representations and Warranties ..................35
9.6.2. Subscriber Representations and Warranties ..........35
9.6.3. Relying Party Representations and Warranties .......35
9.7. Disclaimers of Warranties .................................35
9.8. Limitations of Liability ..................................35
9.9. Indemnities ...............................................35
9.10. Term and Termination .....................................35
9.10.1. Term ..............................................35
9.10.2. Termination .......................................35
9.10.3. Effect of Termination and Survival ................35
9.11. Individual Notices and Communications with Participants ..35
9.12. Amendments ...............................................35
9.12.1. Procedure for Amendment ...........................35
9.12.2. Notification Mechanism and Period .................35
9.13. Dispute Resolution Provisions ............................35
9.14. Governing Law ............................................35
9.15. Compliance with Applicable Law ...........................36
9.16. Miscellaneous Provisions .................................36
9.16.1. Entire Agreement ..................................36
9.16.2. Assignment ........................................36
9.16.3. Severability ......................................36
9.16.4. Enforcement (Attorneys' Fees and Waiver of
Rights) ...........................................36
9.16.5. Force Majeure .....................................36
10. Security Considerations .......................................36
11. References ....................................................37
11.1. Normative References .....................................37
11.2. Informative References ...................................37
Acknowledgments ...................................................38
Authors' Addresses ................................................38 Preface
This RFC contains text intended for use as a template as designated below by the markers <BEGIN TEMPLATE TEXT> and <END TEMPLATE TEXT>. Such Template Text is subject to the provisions of Section 9(b) of the Trust Legal Provisions.
このRFCには、以下のマーカー<BEGIN TEMPLATE TEXT>および<END TEMPLATE TEXT>で指定されているテンプレートとして使用するためのテキストが含まれています。このようなテンプレートテキストは、Trust Legal Provisionsのセクション9（b）の規定に従うものとします。
This document contains a template to be used for creating a Certification Practice Statement (CPS) for an organization that is part of the Resource Public Key Infrastructure (RPKI). (Throughout this document, the term "organization" is used broadly, e.g., the entity in question might be a business unit of a larger organization.)
このドキュメントには、Resource Public Key Infrastructure（RPKI）の一部である組織のCertification Practice Statement（CPS）を作成するために使用されるテンプレートが含まれています。 （このドキュメント全体で、「組織」という用語は広く使用されています。たとえば、問題のエンティティはより大きな組織の事業単位である場合があります。）
There is no expectation that a CPS will be published as an RFC. An organization will publish the CPS in a manner appropriate for access by the users of the RPKI, e.g., on the organization's web site. As a best current practice, organizations are expected to use this template instead of creating one from scratch. This template contains both text that SHOULD appear in all Certification Practice Statements and places for text specific to the organization in question (indicated by <text in angle brackets>).
CPSがRFCとして公開されることは期待されていません。組織は、RPKIのユーザーによるアクセスに適した方法で、たとえば組織のWebサイトでCPSを公開します。現在のベストプラクティスとして、組織は最初からテンプレートを作成するのではなく、このテンプレートを使用することが期待されています。このテンプレートには、すべての認定実務ステートメントに表示すべきテキストと、問題の組織に固有のテキストの場所（<山括弧内のテキスト>で示される）の両方が含まれています。
The user of this document should:
このドキュメントのユーザーは次のことを行う必要があります。
1. Extract the text between the <BEGIN TEMPLATE TEXT> and <END TEMPLATE TEXT> delimiters.
1. <BEGIN TEMPLATE TEXT>と<END TEMPLATE TEXT>区切り文字の間のテキストを抽出します。
2. Replace the instructions between the angle brackets with the required information.
2. 山かっこ間の説明を必要な情報に置き換えます。
This document has been generated to complement the Certificate Policy (CP) for the RPKI [RFC6484]. Like RFC 6484, it is based on the template specified in RFC 3647 [RFC3647]. A number of sections contained in the template were omitted from this CPS because they did not apply to this PKI. However, we have retained the section numbering scheme employed in that RFC to facilitate comparison with the section numbering scheme employed in that RFC and in RFC 6484.
このドキュメントは、RPKI [RFC6484]の証明書ポリシー（CP）を補完するために生成されました。 RFC 6484と同様に、RFC 3647 [RFC3647]で指定されたテンプレートに基づいています。テンプレートに含まれるいくつかのセクションは、このPKIに適用されなかったため、このCPSから省略されました。ただし、そのRFCおよびRFC 6484で採用されているセクション番号付け方式との比較を容易にするために、そのRFCで採用されているセクション番号付け方式を保持しています。
Conventions Used in This Document:
このドキュメントで使用される規則：
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
<BEGIN TEMPLATE TEXT>
<テンプレートテキストの開始>
<Create a title page saying, e.g., "<Name of organization> Certification Practice Statement for the Resource Public Key Infrastructure (RPKI)" with date, author, etc.>
<たとえば、「<組織名>リソース公開鍵インフラストラクチャ（RPKI）の認証実務声明」と記載したタイトルページを日付、作成者などとともに作成します>
<Create a table of contents.>
<目次を作成>
This document is the Certification Practice Statement (CPS) of <name of organization>. It describes the practices employed by the <name of organization> Certification Authority (CA) in the Resource Public Key Infrastructure (RPKI). These practices are defined in accordance with the requirements of the Certificate Policy (CP) [RFC6484] for the RPKI.
この文書は、<組織名>の認定実務声明（CPS）です。リソース公開キーインフラストラクチャ（RPKI）の<組織名>証明機関（CA）で採用されているプラクティスについて説明しています。これらのプラクティスは、RPKIの証明書ポリシー（CP）[RFC6484]の要件に従って定義されています。
The RPKI is designed to support validation of claims by current holders of Internet Number Resources (INRs) (Section 1.6) in accordance with the records of the organizations that act as CAs in this PKI. The ability to verify such claims is essential to ensuring the unique, unambiguous distribution of these resources.
RPKIは、このPKIでCAとして機能する組織の記録に従って、インターネット番号リソース（INR）（セクション1.6）の現在の所有者によるクレームの検証をサポートするように設計されています。そのような主張を検証する機能は、これらのリソースの一意で明確な配布を確実にするために不可欠です。
This PKI parallels the existing INR distribution hierarchy. These resources are distributed by the Internet Assigned Numbers Authority (IANA) to the Regional Internet Registries (RIRs). In some regions, National Internet Registries (NIRs) form a tier of the hierarchy below the RIRs for INR distribution. Internet Service Providers (ISPs) and network subscribers form additional tiers below registries.
このPKIは、既存のINR配布階層に対応しています。これらのリソースは、Internet Assigned Numbers Authority（IANA）によって地域インターネットレジストリ（RIR）に配布されます。一部の地域では、National Internet Registry（NIR）が、INR配布のRIRの下に階層の階層を形成しています。インターネットサービスプロバイダー（ISP）とネットワークサブスクライバーは、レジストリの下に追加の層を形成します。
Conventions Used in This Document:
このドキュメントで使用される規則：
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This CPS describes:
このCPSについて説明します。
o Participants
o 参加者
o Publication of the certificates and Certificate Revocation Lists (CRLs)
o 証明書および証明書失効リスト（CRL）の公開
o How certificates are issued, managed, re-keyed, renewed, and revoked
o 証明書の発行、管理、鍵の更新、更新、および取り消しの方法
o Facility management (physical security, personnel, audit, etc.)
o 施設管理（物理的なセキュリティ、人事、監査など）
o Key management
o キー管理
o Audit procedures
o 監査手順
o Business and legal issues
o ビジネスおよび法的問題
This PKI encompasses several types of certificates (see [RFC6480] for more details):
このPKIには、いくつかのタイプの証明書が含まれます（詳細については、[RFC6480]を参照してください）。
o CA certificates for each organization distributing INRs and for each subscriber INR holder.
o INRを配布する各組織および各サブスクライバーINR保有者のCA証明書。
o End-entity (EE) certificates for organizations to use to validate digital signatures on RPKI-signed objects (see definition in Section 1.6).
o 組織がRPKI署名されたオブジェクトのデジタル署名を検証するために使用するエンドエンティティ（EE）証明書（セクション1.6の定義を参照）。
o In the future, the PKI also may include end-entity certificates in support of access control for the repository system as described in Section 2.4.
o 将来的には、セクション2.4で説明するように、PKIにはリポジトリシステムのアクセス制御をサポートするエンドエンティティ証明書も含まれる可能性があります。
The name of this document is "<Name of organization> Certification Practice Statement for the Resource Public Key Infrastructure (RPKI)". <If this document is available via the Internet, the CA can provide the URI for the CPS here. It SHOULD be the same URI as the URI that appears as a policy qualifier in the CA certificate for the CA, if the CA elects to make use of that feature.>
このドキュメントの名前は、「<組織名>リソース公開鍵インフラストラクチャ（RPKI）の認証実務声明」です。 <このドキュメントがインターネット経由で入手できる場合、CAはここでCPSのURIを提供できます。 CAがその機能を利用することを選択した場合、CAのCA証明書のポリシー修飾子として表示されるURIと同じURIにする必要があります。
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参加者の一部は個人であっても、常に組織またはエンティティと呼ぶことに注意してください。
<Describe the CAs that you will operate for the RPKI. One approach is to operate two CAs: one designated "offline" and the other designated "production". The offline CA is the top-level CA for the <name of organization> portion of the RPKI. It provides a secure revocation and recovery capability in case the production CA is compromised or becomes unavailable. Thus, the offline CA issues certificates only to instances of the production CA, and the CRLs it issues are used to revoke only certificates issued to the production CA. The production CA is used to issue RPKI certificates to <name of organization> members, to whom INRs have been distributed.>
<RPKIで運用するCAを説明します。 1つのアプローチは、2つのCAを運用することです。1つは「オフライン」に指定され、もう1つは「本番」に指定されます。オフラインCAは、RPKIの<組織名>部分のトップレベルCAです。本番CAが危険にさらされたり、使用できなくなったりした場合に備えて、安全な失効および回復機能を提供します。したがって、オフラインCAは証明書を本番CAのインスタンスにのみ発行し、発行するCRLは本番CAに発行された証明書のみを取り消すために使用されます。本番CAは、INRが配布されている<組織名>のメンバーにRPKI証明書を発行するために使用されます。
<Describe how the Registration Authority (RA) function is handled for the CA(s) that you operate. The RPKI does not require establishment or use of a separate Registration Authority in addition to 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 organizations already perform the RA function implicitly, since they already assume responsibility for distributing INRs.>
<運用するCAの登録局（RA）機能の処理方法を説明します。 RPKIは、CA機能に加えて、別個の登録機関の確立または使用を必要としません。 RA機能は、CAとして動作しているのと同じエンティティ、たとえばセクション1.3.1にリストされているエンティティによって提供されなければならない（MUST）。このPKIでCAとして機能するエンティティは、INRを配布する各組織と正式な関係をすでに持っています。これらの組織はすでにINRを配布する責任を負っているので、すでにRA機能を暗黙的に実行しています。>
Organizations receiving INR allocations from this CA are subscribers in the RPKI.
このCAからINR割り当てを受け取る組織は、RPKIの加入者です。
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を参照してください。）
<Specify one or more entities that operate a repository holding certificates, CRLs, and other RPKI-signed objects issued by this organization, and provide a URL for the repository.>
<証明書、CRL、およびこの組織が発行したその他のRPKI署名付きオブジェクトを保持するリポジトリを操作する1つ以上のエンティティを指定し、リポジトリのURLを提供します。>
The certificates issued under this hierarchy are for authorization in support of validation of claims of current holdings of INRs.
この階層の下で発行された証明書は、INRの現在の保有の主張の検証をサポートするための承認用です。
Additional uses of the certificates, consistent with the basic goal cited above, are also permitted under RFC 6484.
上記の基本的な目標と一致する証明書の追加の使用も、RFC 6484で許可されています。
Some of the certificates that may be issued under this PKI could be used to support operation of this infrastructure, e.g., access control for the repository system as described in Section 2.4. Such uses also are permitted under the RPKI certificate policy.
このPKIの下で発行される可能性がある証明書の一部は、このインフラストラクチャの操作をサポートするために使用できます。このような使用は、RPKI証明書ポリシーでも許可されています。
Any uses other than those described in Section 1.4.1 are prohibited.
セクション1.4.1に記載されている以外の使用は禁止されています。
This CPS is administered by <name of organization>. <Include the
mailing address, email address, and similar contact info here.>
<Insert organization contact info here.>
<ここに組織の連絡先情報を挿入します。>
Not applicable. Each organization issuing a certificate in this PKI is attesting to the distribution of INRs to the holder of the private key corresponding to the public key in the certificate. The issuing organizations are the same organizations as the ones that perform the distribution; hence, they are authoritative with respect to the accuracy of this binding.
適用できません。このPKIで証明書を発行する各組織は、証明書の公開鍵に対応する秘密鍵の所有者へのINRの配布を証明しています。発行組織は、配布を実行する組織と同じです。したがって、これらはこのバインディングの正確性に関して信頼できます。
Not applicable. Each organization issuing a certificate in this PKI is attesting to the distribution of INRs to the holder of the private key corresponding to the public key in the certificate. The issuing organizations are the same organizations as the ones that perform the distribution; hence, they are authoritative with respect to the accuracy of this binding.
適用できません。このPKIで証明書を発行する各組織は、証明書の公開鍵に対応する秘密鍵の所有者へのINRの配布を証明しています。発行組織は、配布を実行する組織と同じです。したがって、これらはこのバインディングの正確性に関して信頼できます。
BPKI Business PKI. A BPKI is an optional additional PKI used by an organization to identify members to whom RPKI certificates can be issued. If a BPKI is employed by a CA, it may have its own CP, separate from the RPKI CP.
BPKIビジネスPKI。 BPKIは、RPKI証明書を発行できるメンバーを識別するために組織が使用するオプションの追加のPKIです。 CAがBPKIを採用している場合、BPKIはRPKI CPとは別の独自のCPを持つことができます。
CP Certificate Policy. A 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. The CP for the RPKI is [RFC6484].
CP証明書ポリシー。 CPは、特定のコミュニティや一般的なセキュリティ要件を持つアプリケーションのクラスへの証明書の適用可能性を示す名前付きのルールセットです。 RPKIのCPは[RFC6484]です。
CPS Certification Practice Statement. A CPS is a document that specifies the practices that a Certification Authority employs in issuing certificates.
CPS認定実践ステートメント。 CPSは、認証局が証明書の発行に採用する慣行を指定する文書です。
Distribution of INRs A process of distribution of the INRs along the respective number hierarchy. IANA distributes blocks of IP addresses and Autonomous System Numbers (ASNs) to the five Regional Internet Registries (RIRs). RIRs distribute smaller address blocks and Autonomous System Numbers to organizations within their service regions, who in turn distribute IP addresses to their customers.
INRの分布それぞれの番号階層に沿ったINRの分布のプロセス。 IANAは、IPアドレスのブロックと自律システム番号（ASN）を5つの地域インターネットレジストリ（RIR）に配布します。 RIRはより小さなアドレスブロックと自律システム番号をサービスリージョン内の組織に配布し、組織は顧客にIPアドレスを配布します。
IANA Internet Assigned Numbers Authority. IANA is responsible for global coordination of the Internet Protocol addressing systems and ASNs used for routing Internet traffic. IANA distributes INRs to RIRs.
IANA Internet Assigned Numbers Authority。 IANAは、インターネットトラフィックのルーティングに使用されるインターネットプロトコルアドレッシングシステムとASNのグローバルな調整を担当します。 IANAはINRをRIRに配布します。
INRs Internet Number Resources. INRs are number values for three protocol parameter sets, namely:
INRsインターネット番号リソース。 INRは、次の3つのプロトコルパラメータセットの数値です。
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 ASNs.
o インターネットのドメイン間ルーティングで使用される識別子。現在はボーダーゲートウェイプロトコル4 ASN。
ISP Internet Service Provider. An ISP is an organization managing and selling Internet services to other organizations.
ISPインターネットサービスプロバイダー。 ISPは、インターネットサービスを管理し、他の組織に販売する組織です。
NIR National Internet Registry. An NIR is an organization that manages the distribution of INRs for a portion of the geopolitical area covered by a Regional Internet Registry. NIRs form an optional second tier in the tree scheme used to manage INR distribution.
NIR National Internet Registry。 NIRは、Regional Internet Registryがカバーする地政学的なエリアの一部のINRの分布を管理する組織です。 NIRは、INR分布の管理に使用されるツリースキームのオプションの第2層を形成します。
RIR Regional Internet Registry. An RIR is an organization that manages the distribution of INRs for a geopolitical area.
RIR Regional Internet Registry。 RIRは、地政学的な地域のINRの分布を管理する組織です。
RPKI-signed object An RPKI-signed object is a digitally signed data object (other than a certificate or CRL) declared to be such an object by a Standards Track RFC. An RPKI-signed object 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署名付きオブジェクトは、Standards Track RFCによってそのようなオブジェクトであると宣言された（証明書またはCRL以外の）デジタル署名されたデータオブジェクトです。 RPKI署名付きオブジェクトは、このPKIの下で発行された証明書を使用して検証できます。これらのデータ構造の内容と形式は、INRの現在の保有の主張の検証が行われる状況に依存します。これらのオブジェクトの例は、リポジトリマニフェスト[RFC6486]とルート発信元承認（ROA）[RFC6482]です。
As per the CP, certificates, CRLs, and RPKI-signed objects MUST be made available for downloading by all relying parties, to enable them to validate this data.
CPに従って、証明書、CRL、およびRPKI署名付きオブジェクトは、このデータを検証できるようにするために、すべての証明書利用者がダウンロードできるようにする必要があります。
The <name of organization> RPKI CA will publish certificates, CRLs, and RPKI-signed objects via a repository that is accessible via <insert IETF-designated protocol name here> at <insert URL here>. This repository will conform to the structure described in [RFC6481].
<組織の名前> RPKI CAは、<URLをここに挿入>の<IETF指定のプロトコル名をここに挿入>を介してアクセス可能なリポジトリを介して、証明書、CRL、およびRPKI署名付きオブジェクトを公開します。このリポジトリは、[RFC6481]で説明されている構造に準拠します。
<Name of organization> will publish certificates, CRLs, and RPKI-signed objects issued by it to a repository that operates as part of a worldwide distributed system of RPKI repositories.
<組織名>は、発行された証明書、CRL、およびRPKI署名付きオブジェクトを、RPKIリポジトリの世界的な分散システムの一部として動作するリポジトリに公開します。
<Describe here your procedures for publication (to the global repository system) of the certificates, CRLs, and RPKI-signed objects that you issue. If you choose to outsource publication of PKI data, you still need to provide this information for relying parties. This MUST include the period of time within which a certificate will be published after the CA issues the certificate, and the period of time within which a CA will publish a CRL with an entry for a revoked certificate, after the CA revokes that certificate.>
<ここで、発行する証明書、CRL、およびRPKI署名付きオブジェクトの（グローバルリポジトリシステムへの）公開手順を説明します。 PKIデータの公開を外部委託することを選択した場合でも、依拠当事者にこの情報を提供する必要があります。これには、CAが証明書を発行した後に証明書が公開される期間、およびCAがその証明書を取り消した後、失効した証明書のエントリを含むCRLを公開する期間を含める必要があります。>
The <name of organization> CA will publish its CRL prior to the nextUpdate value in the scheduled CRL previously issued by the CA.
<組織名> CAは、以前にCAによって発行されたスケジュール済みCRLのnextUpdate値の前にCRLを公開します。
<Describe the access controls used by the organization to ensure that only authorized parties can modify repository data, and any controls used to mitigate denial-of-service attacks against the repository. If the organization offers repository services to its subscribers, then describe here the protocol(s) that it supports for publishing signed objects from subscribers.>
<承認された関係者のみがリポジトリデータを変更できるようにするために組織が使用するアクセス制御と、リポジトリに対するサービス拒否攻撃を緩和するために使用される制御について説明します。組織がサブスクライバーにリポジトリサービスを提供している場合は、サブスクライバーからの署名付きオブジェクトの公開用にサポートするプロトコルをここで説明します。>
The subject of each certificate issued by this organization is identified by an X.500 Distinguished Name (DN). The distinguished name will consist of a single Common Name (CN) attribute with a value generated by <name of organization>. 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.
この組織が発行する各証明書のサブジェクトは、X.500識別名（DN）によって識別されます。識別名は、<組織名>によって生成された値を持つ単一の共通名（CN）属性で構成されます。オプションで、同じエンティティに関連付けられた証明書の連続するインスタンスを区別するために、serialNumber属性を共通名とともに含めることができます（端末相対識別名セットを形成するため）。
The Subject name in each certificate SHOULD NOT be "meaningful", in the conventional, human-readable sense. The rationale here is that these certificates are used for authorization in support of applications that make use of attestations of INR holdings. They are not used to identify subjects.
各証明書のサブジェクト名は、従来の人間が読める意味で「意味のある」ものであってはなりません。ここでの理論的根拠は、これらの証明書が、INR保有の証明を利用するアプリケーションをサポートする承認に使用されることです。被験者の識別には使用されません。
Although Subject names in certificates issued by this organization SHOULD 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
なし
<Name of organization> certifies Subject names that are unique among the certificates that it issues. Although it is desirable that these Subject names be unique throughout the PKI, to facilitate certificate path discovery, such uniqueness is not required, nor is it enforced through technical means. <Name of organization> generates Subject names to minimize the chances that two entities in the RPKI will be assigned the same name. Specifically, <insert Subject name generation description here, or cite RFC 6487>.
<組織名>は、発行する証明書の中で一意のサブジェクト名を認証します。これらのサブジェクト名はPKI全体で一意であることが望ましいですが、証明書パスの検出を容易にするために、そのような一意性は必要ではなく、技術的な手段によって強制されることもありません。 <組織名>は、RPKI内の2つのエンティティに同じ名前が割り当てられる可能性を最小限に抑えるために、サブジェクト名を生成します。具体的には、<ここにサブジェクト名生成の説明を挿入するか、RFC 6487を引用してください>。
Because the Subject names are not intended to be meaningful, <name of organization> makes no provision either to recognize or to authenticate trademarks, service marks, etc.
件名は意味のあるものではないため、<組織名>は商標やサービスマークなどを認識または認証するための規定を設けていません。
<Describe the method whereby each subscriber will be required to demonstrate proof-of-possession (PoP) of the private key corresponding to the public key in the certificate, prior to certificate issuance.>
<証明書を発行する前に、各サブスクライバーが証明書の公開キーに対応する秘密キーの所有証明（PoP）を示す必要がある方法を説明してください。>
Certificates issued under this PKI do not attest to the organizational identity of subscribers. However, certificates are issued to subscribers in a fashion that preserves the accuracy of distributions of INRs as represented in <name of organization> records.
このPKIに基づいて発行された証明書は、加入者の組織IDを証明しません。ただし、証明書は、<組織名>のレコードに示されているように、INRの分布の正確さを維持する方法でサブスクライバーに発行されます。
<Describe the procedures that will be used to ensure that each RPKI certificate that is issued accurately reflects your records with regard to the organization to which you have distributed (or sub-distributed) the INRs identified in the certificate. For example, a BPKI certificate could be used to authenticate a certificate request that serves as a link to the <name of organization> subscriber database that maintains the INR distribution records. The certificate request could be matched against the database record for the subscriber in question, and an RPKI certificate would be issued only if the INRs requested were a subset of those held by the subscriber. The specific procedures employed for this purpose should be commensurate with any you already employ in the maintenance of INR distribution.>
<発行された各RPKI証明書が、証明書で識別されたINRを配布（またはサブ配布）した組織に関する記録を正確に反映することを保証するために使用される手順を説明します。たとえば、BPKI証明書を使用して、INR配布レコードを保持する<組織名>サブスクライバーデータベースへのリンクとして機能する証明書要求を認証できます。証明書要求は、問題のサブスクライバーのデータベースレコードと照合できます。RPKI証明書は、要求されたINRがサブスクライバーが保持しているもののサブセットである場合にのみ発行されます。この目的で使用される特定の手順は、INR分布のメンテナンスですでに使用しているものに見合ったものにする必要があります。>
Certificates issued under this PKI do not attest to the individual identity of a subscriber. However, <name of organization> maintains contact information for each subscriber in support of certificate renewal, re-key, and revocation.
このPKIに基づいて発行された証明書は、加入者の個人IDを証明するものではありません。ただし、<組織名>は、証明書の更新、再キー化、および失効をサポートするために、各サブスクライバーの連絡先情報を保持します。
<Describe the procedures that are used to identify at least one individual as a representative of each subscriber. This is done in support of issuance, renewal, and revocation of the certificate issued to the organization. For example, one might say "The <name of organization> BPKI (see Section 3.2.6) issues certificates that MUST be used to identify individuals who represent <name of organization> subscribers." The procedures should be commensurate with those you already employ in authenticating individuals as representatives for INR holders. Note that this authentication is solely for use by you in dealing with the organizations to which you distribute (or sub-distribute) INRs and thus MUST NOT be relied upon outside of this CA/subscriber relationship.>
<各加入者の代表として少なくとも1人の個人を識別するために使用される手順を説明してください。これは、組織に発行された証明書の発行、更新、および失効をサポートするために行われます。たとえば、「<組織の名前> BPKI（セクション3.2.6を参照）は、<組織の名前>サブスクライバーを表す個人を識別するために使用する必要がある証明書を発行します。」手順は、INR保有者の代表者として個人を認証する際にすでに採用している手順に対応している必要があります。この認証は、INRを配布（またはサブ配布）する組織を処理する場合にのみ使用するため、このCA /サブスクライバーの関係外では信頼してはならないことに注意してください。>
No non-verified subscriber data is included in certificates issued under this certificate policy except for Subject Information Access (SIA) extensions [RFC6487].
サブジェクト情報アクセス（SIA）拡張[RFC6487]を除き、この証明書ポリシーに基づいて発行された証明書には、検証されていないサブスクライバーデータは含まれていません。
<Describe the procedures used to verify that an individual claiming to represent a subscriber is authorized to represent that subscriber in this context. For example, one could say "Only an individual to whom a BPKI certificate (see Section 3.2.6) has been issued may request issuance of an RPKI certificate. Each certificate issuance request is verified using the BPKI." The procedures should be commensurate with those you already employ in authenticating individuals as representatives of subscribers.>
<サブスクライバーを代表すると主張する個人が、このコンテキストでそのサブスクライバーを代表する権限を与えられていることを確認するために使用される手順を説明してください。たとえば、「BPKI証明書（セクション3.2.6を参照）が発行された個人のみがRPKI証明書の発行を要求できます。各証明書発行要求は、BPKIを使用して検証されます。」手順は、加入者の代表として個人を認証する際にすでに採用しているものに相応している必要があります。>
The RPKI is neither intended nor designed to interoperate with any other PKI. <If you operate a separate, additional PKI for business purposes, e.g., a BPKI, then describe (or reference) how the BPKI is used to authenticate subscribers and to enable them to manage their resource distributions.>
RPKIは、他のPKIと相互運用することを目的としても設計もされていません。 <BPKIなどのビジネス目的で別の追加のPKIを運用する場合は、BPKIを使用してサブスクライバーを認証し、サブスクライバーがリソースの配布を管理できるようにする方法を説明（または参照）してください。>
<Describe the conditions under which routine re-key is required and the manner by which it is requested. Describe the procedures that are used to ensure that a subscriber requesting routine re-key is the legitimate holder of the certificate to be re-keyed. State the approach for establishing PoP of the private key corresponding to the new public key. If you operate a BPKI, describe how that BPKI is used to authenticate routine re-key requests.>
<定期的な鍵の再発行が必要となる条件と、それが要求される方法を説明します。定期的な鍵の再発行を要求するサブスクライバーが、鍵の再発行される証明書の正当な所有者であることを確認するために使用される手順を説明してください。新しい公開鍵に対応する秘密鍵のPoPを確立するためのアプローチを述べる。 BPKIを運用している場合は、そのBPKIを使用して定期的なキー更新要求を認証する方法を説明してください。>
<Describe the procedures used to ensure that an organization requesting a re-key after revocation is the legitimate holder of the INRs in the certificate being re-keyed. This MUST also include the method employed for verifying PoP of the private key corresponding to the new public key. If you operate a BPKI, describe how that BPKI is used to authenticate re-key requests. With respect to authentication of the subscriber, the procedures should be commensurate with those you already employ in the maintenance of INR distribution records.>
<失効後にキーの再発行を要求する組織が、キーが再発行される証明書のINRの正当な所有者であることを確認するために使用される手順を説明してください。これには、新しい公開鍵に対応する秘密鍵のPoPを検証するために使用される方法も含まれている必要があります。 BPKIを運用している場合は、そのBPKIを使用してキー更新要求を認証する方法を説明します。加入者の認証に関して、手順は、INR配布記録の維持にすでに採用している手順に対応している必要があります。>
<Describe the procedures used by an RPKI subscriber to make a revocation request. Describe the manner by which it is ensured that the subscriber requesting revocation is the subject of the certificate (or an authorized representative thereof) to be revoked. 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. These procedures should be commensurate with those you already employ in the maintenance of subscriber records.>
<失効要求を行うためにRPKIサブスクライバーが使用する手順を説明します。失効を要求する加入者が失効する証明書（またはその承認された代表者）の主体であることを保証する方法を説明してください。正当なサブジェクトが元の秘密キーをまだ所有している場合は、そのキーにアクセスできなくなった場合とは異なる手順があることに注意してください。これらの手順は、加入者の記録の管理にすでに採用している手順に対応している必要があります。>
Any subscriber in good standing who holds INRs distributed by <name of organization> may submit a certificate application to this CA. (The exact meaning of "in good standing" is in accordance with the policy of <name of organization>.)
<組織名>から配布されたINRを保持している良好な状態の加入者は、このCAに証明書アプリケーションを提出できます。 （「良好な状態」の正確な意味は、<組織名>のポリシーに準拠しています。）
<Describe your enrollment process for issuing certificates both for initial deployment of the PKI and as an ongoing process. Note that most of the certificates in this PKI are issued as part of your normal business practices, as an adjunct to INR distribution, and thus a separate application to request a certificate may not be necessary. If so, reference should be made to where these practices are documented.>
<PKIの初期展開時と継続的なプロセスの両方で証明書を発行するための登録プロセスを説明してください。このPKIの証明書のほとんどは、INR配布の補助として、通常のビジネスプラクティスの一部として発行されるため、証明書を要求するための個別のアプリケーションは必要ない場合があります。その場合は、これらのプラクティスが文書化されている場所を参照してください。>
<Describe the certificate request/response processing that you will employ. You should make use of existing standards for certificate application processing (see [RFC6487]).>
<採用する証明書の要求/応答処理について説明してください。証明書申請処理には既存の標準を利用する必要があります（[RFC6487]を参照）。>
<Describe your practices for identification and authentication of certificate applicants. Often, existing practices employed by you to identify and authenticate organizations can be used as the basis for issuance of certificates to these subscribers. Reference can be made to documentation of such existing practices.>
<証明書申請者の識別と認証に関する慣行を説明してください。多くの場合、組織を識別および認証するためにユーザーが採用している既存の手法は、これらのサブスクライバーへの証明書の発行の基礎として使用できます。このような既存のプラクティスのドキュメントを参照できます。>
<Describe your practices for approval or rejection of applications, and refer to documentation of existing business practices relevant to this process. Note that according to the CP, certificate applications will be approved based on the normal business practices of the entity operating the CA, based on the CA's records of subscribers. The CP also says that each CA will follow the procedure 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.>
<申請の承認または却下に関する慣行を説明し、このプロセスに関連する既存のビジネス慣行の文書を参照してください。 CPによると、証明書の申請は、CAの加入者の記録に基づいて、CAを運営する事業体の通常のビジネス慣行に基づいて承認されることに注意してください。 CPはまた、各CAがセクション3.2.1で指定された手順に従い、リクエスターが、CAがリクエスターに発行する証明書にバインドされる公開キーに対応する秘密キーを保持していることを確認することも述べています。
<Specify here your expected time frame for processing certificate applications.>
<証明書申請の処理に予想される時間枠をここに指定してください。>
<Describe your procedures for issuance and publication of a certificate.>
<証明書の発行と発行の手順を説明してください。>
<Name of organization> will notify the subscriber when the certificate is published. <Describe here your procedures for notifying a subscriber when a certificate has been published.>
<組織名>は、証明書が公開されたときに加入者に通知します。 <証明書が発行されたときに加入者に通知する手順をここに記述してください。>
<Describe here any other entities that will be notified when a certificate is published.>
<証明書の発行時に通知される他のエンティティをここに記述します。>
When a certificate is issued, the <name of organization> CA will publish it to the repository and notify the subscriber. <This may be done without subscriber review and acceptance. State your policy with respect to subscriber certificate acceptance here.>
証明書が発行されると、<組織名> CAはそれをリポジトリに公開し、サブスクライバーに通知します。 <これは、加入者のレビューと承認なしで行われる場合があります。サブスクライバー証明書の受け入れに関するポリシーをここに記載してください。>
Certificates will be published at <insert repository URL here> once issued, following the conduct described in Section 4.4.1. This will be done within <specify the time frame within which the certificate will be placed in the repository and the subscriber will be notified>. <Describe any additional procedures with respect to publication of the certificate here.>
証明書は、セクション4.4.1で説明されている行為に従って、発行後に<insert repository URL here>で公開されます。これは、<証明書がリポジトリに配置され、加入者に通知される時間枠を指定>以内に行われます。 <証明書の発行に関する追加の手順をここに記述してください。>
<Describe here any other entities that will be notified when a certificate is published.>
<証明書の発行時に通知される他のエンティティをここに記述します。>
A summary of the use model for the RPKI is provided below.
RPKIの使用モデルの概要を以下に示します。
The certificates issued by <name of organization> to subordinate INR holders are CA certificates. The private key associated with each of these certificates is used to sign subordinate (CA or EE) certificates and CRLs.
<組織名>が下位のINR保有者に発行した証明書はCA証明書です。これらの各証明書に関連付けられた秘密鍵は、下位（CAまたはEE）の証明書とCRLの署名に使用されます。
The primary relying parties in this PKI are organizations that use RPKI EE certificates to verify RPKI-signed objects. Relying parties are referred to Section 4.5.2 of [RFC6484] for additional guidance with respect to acts of reliance on RPKI certificates.
このPKIの主要な証明書利用者は、RPKI EE証明書を使用してRPKI署名付きオブジェクトを検証する組織です。 RPKI証明書への依存行為に関する追加のガイダンスについては、証明書利用者に[RFC6484]のセクション4.5.2を参照してください。
As per RFC 6484, a certificate will be processed for renewal based on its expiration date or a renewal request from the certificate Subject. The request may be implicit, a side effect of renewing a resource holding agreement, or explicit. If <name of organization> initiates the renewal process based on the certificate expiration date, then <name of organization> will notify the subscriber <insert the period of advance warning, e.g., "2 weeks in advance of the expiration date", or the general policy, e.g., "in conjunction with notification of service expiration">. The validity interval of the new (renewed) certificate will overlap that of the previous certificate by <insert length of overlap period, e.g., 1 week>, to ensure uninterrupted coverage.
RFC 6484に従い、証明書は、有効期限または証明書のサブジェクトからの更新要求に基づいて、更新のために処理されます。要求は暗黙的、リソース保持合意の更新の副作用、または明示的である可能性があります。 <組織名>が証明書の有効期限に基づいて更新プロセスを開始した場合、<組織名>はサブスクライバーに<事前警告の期間を挿入します（例：「有効期限の2週間前」）、または一般的なポリシー、たとえば「サービスの有効期限の通知と組み合わせて」。新しい（更新された）証明書の有効期間は、前の証明書の有効期間と<重複期間の長さ（例：1週間）を挿入>して、中断されない範囲を保証します。
Certificate renewal will incorporate the same public key as the previous certificate, unless the private key has been reported as compromised (see Section 4.9.1). If a new key pair is being used, the stipulations of Section 4.7 will apply.
秘密鍵が危険にさらされていると報告されていない限り、証明書の更新には、以前の証明書と同じ公開鍵が組み込まれます（セクション4.9.1を参照）。新しい鍵ペアが使用されている場合、セクション4.7の規定が適用されます。
The subscriber or <name of organization> may initiate the renewal process. <For the case of the subscriber, describe the procedures that will be used to ensure that the requester is the legitimate holder of the INRs in the certificate being renewed. This MUST also include the method employed for verifying PoP of the private key corresponding to the public key in the certificate being renewed or the new public key if the public key is being changed. With respect to authentication of the subscriber, the procedures should be commensurate with those you already employ in the maintenance of INR distribution records. If you operate a BPKI for this, describe how that business-based PKI is used to authenticate renewal requests, and refer to Section 3.2.6.>
加入者または<組織名>が更新プロセスを開始できます。 <加入者の場合は、更新される証明書に申請者がINRの正当な所有者であることを保証するために使用される手順を記述してください。これには、更新される証明書の公開鍵に対応する秘密鍵、または公開鍵が変更されている場合は新しい公開鍵のPoPを検証するために使用される方法も含める必要があります。加入者の認証に関しては、手順は、INR配布記録の保守にすでに採用している手順に相応している必要があります。このためにBPKIを運用する場合は、ビジネスベースのPKIを使用して更新要求を認証する方法を説明し、セクション3.2.6を参照してください。
<Describe your procedures for handling certificate renewal requests. Describe how you verify that the requester is the subscriber or is authorized by the subscriber, and that the certificate in question has not been revoked.>
<証明書の更新リクエストの処理手順を説明してください。リクエスターがサブスクライバーであること、またはサブスクライバーによって許可されていること、および問題の証明書が取り消されていないことを確認する方法を説明してください。>
<Name of organization> will notify the subscriber when the certificate is published. <Describe your procedure for notification of new certificate issuance to the subscriber. This should be consistent with Section 4.3.2.>
<組織名>は、証明書が公開されたときに加入者に通知します。 <新しい証明書の発行を加入者に通知する手順を説明してください。これはセクション4.3.2と一致している必要があります。
See Section 4.4.1. <If you employ a different policy from that specified in Section 4.4.1, describe it here.>
セクション4.4.1を参照してください。 <4.4.1で指定されているものとは異なるポリシーを採用している場合は、ここで説明してください。>
See Section 4.4.2.
セクション4.4.2を参照してください。
See Section 4.4.3.
セクション4.4.3を参照してください。
As per RFC 6484, re-key of a certificate will be performed only when required, based on:
RFC 6484に従って、証明書の再キー化は、以下に基づいて、必要な場合にのみ実行されます。
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. 関連する鍵ペアの暗号化の有効期限の期限
If a certificate is revoked to replace the RFC 3779 extensions, the replacement certificate will incorporate the same public key, not a new key.
証明書を取り消してRFC 3779拡張機能を置き換えると、置き換えられた証明書には、新しい鍵ではなく同じ公開鍵が組み込まれます。
If the re-key is based on a suspected compromise, then the previous certificate will be revoked.
鍵の再生成が侵害の疑いに基づいている場合、以前の証明書は取り消されます。
Only the holder of a certificate may request a re-key. In addition, <name of organization> may initiate a re-key based on a verified compromise report. <If the subscriber (certificate Subject) requests the re-key, describe how authentication is effected, e.g., using the <name of registry> BPKI. Describe how a compromise report received from other than a subscriber is verified.>
証明書の所有者のみが鍵の再発行を要求できます。さらに、<組織名>は、検証済みの侵害報告に基づいて鍵の再発行を開始する場合があります。 <サブスクライバー（証明書のサブジェクト）がキーの再発行を要求する場合は、<レジストリの名前> BPKIなどを使用して、認証がどのように行われるかを説明します。サブスクライバー以外から受信した侵害レポートの検証方法を説明してください。>
<Describe your process for handling re-keying requests. As per the RPKI CP, this should be consistent with the process described in Section 4.3, so reference can be made to that section.>
<鍵の再発行リクエストを処理するプロセスを説明してください。 RPKI CPに従って、これはセクション4.3で説明されているプロセスと一致している必要があるため、そのセクションを参照できます。>
<Describe your policy for notifying the subscriber regarding availability of the new re-keyed certificate. This should be consistent with the notification process for any new certificate issuance (see Section 4.3.2).>
<新しい鍵の再発行された証明書の入手可能性について加入者に通知するためのポリシーを説明してください。これは、新しい証明書の発行に関する通知プロセスと一致している必要があります（セクション4.3.2を参照）。
When a re-keyed certificate is issued, the CA will publish it in the repository and notify the subscriber. See Section 4.4.1.
鍵の再発行された証明書が発行されると、CAはそれをリポジトリに公開し、加入者に通知します。セクション4.4.1を参照してください。
<Describe your policy regarding publication of the new certificate. This should be consistent with the publication process for any new certificate (see Section 4.4.2).>
<新しい証明書の発行に関するポリシーを説明してください。これは、新しい証明書の公開プロセスと一致している必要があります（セクション4.4.2を参照）。
See Section 4.4.3.
セクション4.4.3を参照してください。
As per RFC 6484, modification of a certificate occurs to implement changes to the RFC 3779 extension values or the SIA extension in a certificate. A subscriber can request a certificate modification when this information in a currently valid certificate has changed, as a result of changes in the INR holdings of the subscriber, or as a result of change of the repository publication point data.
RFC 6484に従って、証明書の変更は、証明書のRFC 3779拡張値またはSIA拡張に対する変更を実装するために行われます。サブスクライバーは、現在有効な証明書のこの情報が変更された場合、サブスクライバーのINR保有の変更の結果として、またはリポジトリ公開ポイントデータの変更の結果として、証明書の変更を要求できます。
If a subscriber is to receive a distribution of INRs in addition to a current distribution, and if the subscriber does not request that a new certificate be issued containing only these additional INRs, then this is accomplished through a certificate modification. When a certificate modification is approved, a new certificate is issued. The new certificate will contain the same public key and the same expiration date as the original certificate, but with the incidental information corrected and/or the INR distribution expanded. When previously distributed INRs are to be removed from a certificate, then the old certificate will be revoked and a new certificate (reflecting the new distribution) issued.
サブスクライバーが現在の配布に加えてINRの配布を受け取る場合、およびサブスクライバーがこれらの追加のINRのみを含む新しい証明書の発行を要求しない場合、これは証明書の変更によって行われます。証明書の変更が承認されると、新しい証明書が発行されます。新しい証明書には、元の証明書と同じ公開鍵と同じ有効期限が含まれますが、付随情報が修正され、INR分布が拡張されます。以前に配布されたINRを証明書から削除する場合、古い証明書は取り消され、新しい証明書（新しい配布を反映）が発行されます。
The subscriber or <name of organization> may initiate the certificate modification process. <For the case of the subscriber, state here what steps will be taken to verify the identity and authorization of the entity requesting the modification.>
加入者または<組織名>が証明書の変更プロセスを開始する場合があります。 <サブスクライバーの場合は、変更を要求しているエンティティのIDと承認を確認するためにどのようなステップが実行されるかをここに記述してください。>
<Describe your procedures for verification of the modification request and procedures for the issuance of a new certificate. These should be consistent with the processes described in Sections 4.2 and 4.3.1.>
<変更要求の確認手順と新しい証明書の発行手順を説明してください。これらは、セクション4.2および4.3.1で説明されているプロセスと一致している必要があります。
<Describe your procedure for notifying the subscriber about the issuance of a modified certificate. This should be consistent with the notification process for any new certificate (see Section 4.3.2).>
<変更された証明書の発行について加入者に通知する手順を説明してください。これは、新しい証明書の通知プロセスと一致している必要があります（セクション4.3.2を参照）。
When a modified certificate is issued, <name of organization> will publish it to the repository and notify the subscriber. See Section 4.4.1.
変更された証明書が発行されると、<組織名>はそれをリポジトリに公開し、サブスクライバーに通知します。セクション4.4.1を参照してください。
<Describe your procedure for publication of a modified certificate. This should be consistent with the publication process for any new certificate (see Section 4.4.2).>
<変更された証明書の発行手順を説明してください。これは、新しい証明書の公開プロセスと一致している必要があります（セクション4.4.2を参照）。
See Section 4.4.3.
セクション4.4.3を参照してください。
As per RFC 6484, certificates can be revoked for several reasons. Either <name of organization> or the subject may choose to end the relationship expressed in the certificate, thus creating cause to revoke the certificate. If one or more of the INRs bound to the public key in the certificate are no longer associated with the subject, that too constitutes a basis for revocation. A certificate also may be revoked due to loss or compromise of the private key corresponding to the public key in the certificate. Finally, a certificate may be revoked in order to invalidate data signed by the private key associated with that certificate.
RFC 6484によると、証明書はいくつかの理由で取り消される可能性があります。 <組織の名前>またはサブジェクトのいずれかが、証明書で表現された関係を終了することを選択する場合があるため、証明書を取り消す原因となります。証明書の公開鍵にバインドされている1つ以上のINRがサブジェクトに関連付けられなくなった場合、それも失効の基礎となります。証明書の公開鍵に対応する秘密鍵の紛失または侵害により、証明書が取り消される場合もあります。最後に、証明書は、その証明書に関連付けられた秘密鍵によって署名されたデータを無効にするために取り消される場合があります。
The subscriber or <name of organization> may request a revocation. <For the case of the subscriber, describe what steps will be taken to verify the identity and authorization of the entity requesting the revocation.>
加入者または<組織名>が失効を要求する場合があります。 <サブスクライバーの場合は、失効を要求するエンティティのIDと承認を確認するためにどのような手順を実行するかを説明してください。>
<Describe your process for handling a certificate revocation request. This should include:
<証明書失効リクエストを処理するプロセスを説明してください。これには以下が含まれます：
o Procedure to be used by the subscriber to request a revocation.
o サブスクライバーが失効を要求するために使用する手順。
o Procedure for notification of the subscriber when the revocation is initiated by <name of organization>.>
o 失効が<組織名>によって開始されたときに加入者に通知するための手順。>
A subscriber is required to request revocation as soon as possible after the need for revocation has been identified.
加入者は、失効の必要性が確認された後、できるだけ早く失効を要求する必要があります。
<Describe your policy on the time period within which you will process a revocation request.>
<失効リクエストを処理する期間に関するポリシーを説明してください。>
As per RFC 6484, a relying party is responsible for acquiring and checking the most recent, scheduled CRL from the issuer of the certificate, whenever the relying party validates a certificate.
RFC 6484に従って、証明書利用者は、証明書利用者が証明書を検証するたびに、証明書の発行者から最新のスケジュールされたCRLを取得してチェックする責任があります。
<State the CRL issuance frequency for the CRLs that you publish.> Each CRL contains a nextUpdate value, and a new CRL will be published at or before that time. <Name of organization> will set the nextUpdate value when it issues a CRL, to signal when the next scheduled CRL will be issued.
<発行するCRLのCRLの発行頻度を記載します。>各CRLにはnextUpdate値が含まれており、新しいCRLはその時間以前に発行されます。 <組織名>は、CRLを発行するときにnextUpdate値を設定し、次にスケジュールされているCRLが発行される時期を通知します。
A CRL will be published to the repository system within <state the maximum latency> after generation.
CRLは、生成後、<最大レイテンシの状態>内でリポジトリシステムに公開されます。
<Name of organization> does not support the Online Certificate Status Protocol (OCSP) or the Server-Based Certificate Validation Protocol (SCVP). <Name of organization> issues CRLs.
<組織名>は、オンライン証明書ステータスプロトコル（OCSP）またはサーバーベースの証明書検証プロトコル（SCVP）をサポートしていません。 <組織名>はCRLを発行します。
<As per RFC 6484, describe the physical controls that you employ for certificate management. These should be commensurate with those used in the management of INR distribution.>
<RFC 6484に従って、証明書の管理に使用する物理的な制御について説明します。これらは、INR分布の管理に使用されるものに対応している必要があります。>
<As per RFC 6484, describe the procedural security controls that you employ for certificate management. These should be commensurate with those used in the management of INR distribution.>
<RFC 6484に従って、証明書管理に採用する手続き型セキュリティ管理について説明します。これらは、INR分布の管理に使用されるものに対応している必要があります。>
<As per RFC 6484, describe the personnel security controls that you employ for individuals associated with certificate management. These should be commensurate with those used in the management of INR distribution.>
<RFC 6484に従って、証明書管理に関連する個人に採用する人的セキュリティ管理について説明してください。これらは、INR分布の管理に使用されるものに対応している必要があります。>
<As per the CP, describe in the following sections the details of how you implement audit logging.>
<CPに従って、監査ログを実装する方法の詳細を次のセクションで説明します。>
Audit records will be generated for the basic operations of the Certification Authority computing equipment. Audit records will 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 時計の調整
<List here any additional types of events that will be audited.>
<ここで、監査される追加のタイプのイベントをリストします。>
<Describe your procedures for review of audit logs.>
<監査ログの確認手順を説明してください。>
<Describe your policies for retention of audit logs.>
<監査ログの保持に関するポリシーを説明してください。>
<Describe your policies for protection of the audit logs.>
<監査ログの保護に関するポリシーを説明してください。>
<Describe your policies for backup of the audit logs.>
<監査ログのバックアップに関するポリシーを説明してください。>
<Describe any vulnerability assessments that you will apply (or have already applied) to the PKI subsystems. This should include whether such assessments have taken place and any procedures or plans to perform or repeat/reassess vulnerabilities in the future.>
<PKIサブシステムに適用する（または既に適用した）脆弱性評価を記述します。これには、そのような評価が行われたかどうか、および将来的に脆弱性を実行または再評価/再評価するための手順または計画が含まれます。>
The <name of organization> CA certificate will contain a validity period that is at least as long as that of any certificate being issued under that certificate. When <name of organization> CA changes keys, it will follow the procedures described in [RFC6489].
<組織名> CA証明書には、少なくともその証明書に基づいて発行される証明書の有効期間と同じ有効期間が含まれます。 <組織名> CAがキーを変更すると、[RFC6489]で説明されている手順に従います。
<Describe your plans for dealing with CA key compromise and how you plan to continue/restore operation of your RPKI CA in the event of a disaster.>
<CAキーの侵害に対処するための計画と、災害発生時にRPKI CAの運用を継続/復元する方法を説明してください>
<Describe your policy for management of your CA's INR distributions in case of its own termination.>
<独自の解約の場合のCAのINR分布の管理に関するポリシーを説明してください。>
This section describes the security controls used by <name of organization>.
このセクションでは、<組織名>が使用するセキュリティ制御について説明します。
<Describe the procedures used to generate the CA key pair and, if applicable, key pairs for subscribers. In most instances, public-key pairs will be generated by the subscriber, i.e., the organization receiving the distribution of INRs. However, your procedures may include one for generating key pairs on behalf of your subscribers if they so request.>
<CAキーペア、および該当する場合はサブスクライバーのキーペアを生成するために使用される手順を説明します。ほとんどの場合、公開鍵のペアはサブスクライバー、つまりINRの配布を受け取る組織によって生成されます。ただし、サブスクライバーが要求した場合、サブスクライバーの代わりにキーペアを生成する手順が手順に含まれる場合があります。>
<If the procedures in Section 6.1.1 include providing key pair generation services for subscribers, describe the means by which private keys are delivered to subscribers in a secure fashion. Otherwise, say this is not applicable.>
<セクション6.1.1の手順に、サブスクライバーへのキーペア生成サービスの提供が含まれている場合は、秘密キーを安全な方法でサブスクライバーに配信する方法を説明してください。それ以外の場合、これは該当しないと言います。>
<Describe the procedures that will be used to deliver a subscriber's public keys to the <name of organization> RPKI CA. These procedures MUST ensure that the public key has not been altered during transit and that the subscriber possesses the private key corresponding to the transferred public key.> See RFC 6487 for details.
<サブスクライバーの公開キーを<組織名> RPKI CAに配信するために使用される手順を説明します。これらの手順では、送信中に公開鍵が変更されていないこと、およびサブスクライバーが転送された公開鍵に対応する秘密鍵を所有していることを確認する必要があります。
CA public keys for all entities (other than trust anchors) are contained in certificates issued by other CAs and will be published to the RPKI repository system. Relying parties will download these certificates from this system. Public key values and associated data for (putative) trust anchors will be distributed out of band and accepted by relying parties on the basis of locally defined criteria, e.g., embedded in path validation software that will be made available to the Internet community.
（トラストアンカー以外の）すべてのエンティティのCA公開鍵は、他のCAによって発行された証明書に含まれており、RPKIリポジトリシステムに公開されます。証明書利用者は、これらの証明書をこのシステムからダウンロードします。 （推定）トラストアンカーの公開鍵の値と関連データは、帯域外で配布され、インターネットコミュニティで利用できるようになるパス検証ソフトウェアに組み込まれているなど、ローカルで定義された基準に基づいて証明書利用者によって受け入れられます。
The key sizes used in this PKI are as specified in [RFC6485].
このPKIで使用される鍵のサイズは、[RFC6485]で指定されているとおりです。
The public key algorithms and parameters used in this PKI are as specified in [RFC6485].
このPKIで使用される公開鍵アルゴリズムとパラメータは、[RFC6485]で指定されているとおりです。
<If the procedures in Section 6.1.1 include subscriber key pair generation, EITHER insert here text specifying that the subscriber is responsible for performing checks on the quality of its key pair and saying that <name of organization> is not responsible for performing such checks for subscribers OR describe the procedures used by the CA for checking the quality of these subscriber key pairs.>
<セクション6.1.1の手順にサブスクライバーキーペアの生成が含まれる場合、サブスクライバーがキーペアの品質のチェックを実行する責任があることを指定し、<組織名>がそのようなチェックの実行を担当しないことを示すテキストをここに挿入しますサブスクライバーの場合、またはこれらのサブスクライバーキーペアの品質をチェックするためにCAが使用する手順を説明します。
The KeyUsage extension bit values employed in RPKI certificates are specified in [RFC6487].
RPKI証明書で使用されるKeyUsage拡張ビット値は、[RFC6487]で指定されています。
6.2. Private Key Protection and Cryptographic Module Engineering Controls
6.2. 秘密鍵の保護と暗号化モジュールのエンジニアリング管理
<Describe the standards and controls employed for the CA cryptographic module, e.g., it was evaluated under FIPS 140-2/3, at level 2 or 3. See [FIPS] for details.>
<CA暗号化モジュールに採用されている標準と制御を説明してください。たとえば、FIPS 140-2 / 3でレベル2または3で評価されました。詳細については、[FIPS]を参照してください。>
<If you choose to use multi-person controls to constrain access to
your CA's private keys, then insert the following text. "There will
be private key <insert here n> out of <insert here m> multi-person
control.">
<No private key escrow procedures are required for the RPKI, but if the CA chooses to employ escrow, state so here.>
<RPKIには秘密鍵のエスクロー手順は必要ありませんが、CAがエスクローの採用を選択した場合は、ここにその旨を記載してください>
<Describe the procedures used for backing up your CA's private key. The following aspects should be included. (1) The copying should be done under the same multi-party control as is used for controlling the original private key. (2) At least one copy should be kept at an off-site location for disaster recovery purposes.>
<CAの秘密鍵のバックアップに使用する手順を説明します。次の側面を含める必要があります。 （1）コピーは、元の秘密鍵を制御するために使用されるのと同じマルチパーティ制御下で行われる必要があります。 （2）災害復旧のために、少なくとも1つのコピーをオフサイトの場所に保管する必要があります。>
See Sections 6.2.3 and 6.2.4.
セクション6.2.3および6.2.4を参照してください。
The private key for the <name of organization> production CA <if appropriate, change "production CA" to "production and offline CAs"> will be generated by the cryptographic module specified in Section 6.2.1. The private keys will never leave the module except in encrypted form for backup and/or transfer to a new module.
<組織名>の本番CAの秘密鍵<該当する場合は、「本番CA」を「本番およびオフラインCA」に変更してください>は、セクション6.2.1で指定された暗号モジュールによって生成されます。秘密鍵は、バックアップや新しいモジュールへの転送のために暗号化された形式を除いて、モジュールを離れることはありません。
The private key for the <name of organization> production CA <if appropriate, change "production CA" to "production and offline CAs"> will be stored in the cryptographic module. It will be protected from unauthorized use <say how here>.
<組織名>のプロダクションCAの秘密キー<適切な場合は、「プロダクションCA」を「プロダクションおよびオフラインCA」に変更します ">が暗号化モジュールに格納されます。不正使用から保護されます<方法はこちら>。
<Describe the mechanisms and data used to activate your CA's private key.>
<CAの秘密鍵をアクティブ化するために使用されるメカニズムとデータを説明してください。>
<Describe the process and procedure for private key deactivation here.>
<秘密鍵の非アクティブ化のプロセスと手順をここに記述してください。>
<Describe the method used for destroying your CA's private key, e.g., when it is superseded. This will depend on the particular module.>
<CAの秘密鍵を破棄するために使用された方法を説明します（たとえば、置き換えられた場合）。これは特定のモジュールに依存します。>
<Describe the rating of the cryptographic module used by the CA, if applicable.>
<該当する場合、CAが使用する暗号化モジュールの評価を記述します。>
<Because this PKI does not support non-repudiation, there is no need to archive public keys. If keys are not archived, say so. If they are, describe the archive processes and procedures.>
<このPKIは否認防止をサポートしていないため、公開鍵をアーカイブする必要はありません。キーがアーカイブされていない場合は、アーカイブしてください。ある場合は、アーカイブのプロセスと手順を説明してください。>
The <name of organization> CA's key pair will have a validity interval of <insert number of years>. <These key pairs and certificates should have reasonably long validity intervals, e.g., 10 years, to minimize the disruption caused by key changeover. Note that the CA's key lifetime is under the control of its issuer, so the CPS MUST reflect the key lifetime imposed by the issuer.>
<組織名> CAのキーペアの有効期間は、<年数を挿入>です。 <これらのキーペアと証明書は、キーの切り替えに起因する中断を最小限に抑えるために、妥当な間隔（たとえば、10年）が必要です。 CAのキーの有効期間は発行者の管理下にあるため、CPSは発行者が課したキーの有効期間を反映する必要があることに注意してください。
<Describe how activation data for your CA will be generated.>
<CAのアクティベーションデータが生成される方法を説明してください。>
Activation data for the CA private key will be protected by <describe your procedures here>.
CA秘密鍵のアクティベーションデータは、<ここに手順を説明>によって保護されます。
<Add here any details you wish to provide with regard to the activation data for your CA. If there are none, say "None".>
<CAのアクティベーションデータに関して提供したい詳細をここに追加します。ない場合は、「なし」と言います。>
<Describe your security requirements for the computers used to support this PKI, e.g., requirements for authenticated logins, audit capabilities, etc. These requirements should be commensurate with those used for the computers used for managing distribution of INRs.>
<このPKIをサポートするために使用されるコンピューターのセキュリティ要件を説明します。たとえば、認証されたログイン、監査機能などの要件です。これらの要件は、INRの配布の管理に使用されるコンピューターに使用される要件に対応している必要があります。>
<Describe any system development controls that apply to the PKI systems, e.g., use of Trusted System Development Methodology (TSDM).>
<PKIシステムに適用されるシステム開発管理策を説明します（例：Trusted System Development Methodology（TSDM）の使用）。>
<Describe the security management controls that will be used for the RPKI software and equipment employed by the CA. These security measures should be commensurate with those used for the systems used by the CAs for managing and distributing INRs.>
<CAが使用するRPKIソフトウェアおよび機器に使用されるセキュリティ管理コントロールを説明する。これらのセキュリティ対策は、INRを管理および配布するためにCAが使用するシステムに使用されているものに対応している必要があります。>
<Describe how the equipment (hardware and software) used for RPKI functions will be procured, installed, maintained, and updated. This should be done in a fashion commensurate with the way in which equipment for the management and distribution of INRs is handled.>
<RPKI機能に使用される機器（ハードウェアおよびソフトウェア）の調達、設置、保守、更新の方法を説明します。これは、INRの管理と配布のための機器の取り扱い方法に見合った方法で行う必要があります。>
<Describe the network security controls that will be used for CA operation. These should be commensurate with the network security controls employed for the computers used for managing distribution of INRs.>
<CAの運用に使用されるネットワークセキュリティコントロールについて説明する。これらは、INRの配布を管理するために使用されるコンピューターに採用されているネットワークセキュリティコントロールに対応している必要があります。>
The RPKI does not make use of time-stamping.
RPKIはタイムスタンプを使用しません。
See [RFC6487].
[RFC6487]を参照してください。
<List here any audit and other assessments used to ensure the security of the administration of INRs. These are sufficient for the RPKI systems. However, additional forms of security assessments are a good idea and should be listed if performed.>
<INRの管理のセキュリティを確保するために使用される監査およびその他の評価をここにリストします。これらはRPKIシステムには十分です。ただし、セキュリティアセスメントの追加の形式を使用することをお勧めします。実行する場合はリストに記載してください。
<The sections below are optional. Fill them in as appropriate for your organization. The CP says that CAs should cover Sections 9.1 to 9.11 and 9.13 to 9.16, although not every CA will choose to do so. Note that the manner in which you manage your business and legal matters for this PKI should be commensurate with the way in which you manage business and legal matters for the distribution of INRs.>
<以下のセクションはオプションです。組織に応じて適切に入力してください。 CPは、すべてのCAが選択するわけではないが、CAはセクション9.1から9.11および9.13から9.16をカバーする必要があると述べています。このPKIのビジネスおよび法的問題を管理する方法は、INRの配布のためのビジネスおよび法的問題を管理する方法に対応している必要があります。>
<END TEMPLATE TEXT>
<テンプレートテキストの終了>
The degree to which a relying party can trust the binding embodied in a certificate depends on several factors. These factors can include
証明書に組み込まれたバインディングを信頼パーティが信頼できる度合いは、いくつかの要因に依存します。これらの要因には、
o the practices followed by the Certification Authority (CA) in authenticating the subject
o サブジェクトの認証において認証局（CA）が従う慣行
o 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)
o CAの運用ポリシー、手順、および技術的セキュリティ管理（サブスクライバーの責任の範囲を含む（たとえば、秘密鍵の保護における））
o the stated responsibilities and liability terms and conditions of the CA (for example, warranties, disclaimers of warranties, and limitations of liability)
o CAの明記された責任と責任の条件（たとえば、保証、保証の否認、および責任の制限）
This document provides a framework to address the technical, procedural, personnel, and physical security aspects of Certification Authorities, Registration Authorities, repositories, subscribers, and relying party cryptographic modules, in order to ensure that the certificate generation, publication, renewal, re-key, usage, and revocation are done in a secure manner. Specifically, the following sections are oriented towards ensuring the secure operation of the PKI entities such as CA, RA, repository, subscriber systems, and relying party systems:
このドキュメントは、証明書の生成、公開、更新、更新を確実にするために、認証局、登録局、リポジトリ、サブスクライバー、および証明書利用者の暗号モジュールの技術的、手続き的、人的、および物理的なセキュリティの側面に対処するフレームワークを提供しますキー、使用法、失効は安全な方法で行われます。具体的には、以下のセクションは、CA、RA、リポジトリ、サブスクライバーシステム、証明書利用者システムなどのPKIエンティティの安全な運用を保証することを目的としています。
Section 3 ("Identification and Authentication" (I&A)) Section 4 ("Certificate Life Cycle Operational Requirements") Section 5 ("Facility, Management, and Operational Controls") Section 6 ("Technical Security Controls") Section 7 ("Certificate and CRL Profiles") Section 8 ("Compliance Audit and Other Assessments")
セクション3（「識別と認証」（I＆A））セクション4（「証明書のライフサイクルの運用要件」）セクション5（「施設、管理、および運用管理」）セクション6（「技術的セキュリティ管理」）セクション7（「証明書」およびCRLプロファイル」）セクション8（「コンプライアンス監査およびその他の評価」）
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)", BCP 173, RFC 6484, February 2012, <http://www.rfc-editor.org/info/rfc6484>.
[RFC6484] Kent、S.、Kong、D.、Seo、K。、およびR. Watro、「Resource Public Key Infrastructure（RPKI）の証明書ポリシー（CP）」、BCP 173、RFC 6484、2012年2月、< http://www.rfc-editor.org/info/rfc6484>。
[RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)", RFC 6485, February 2012, <http://www.rfc-editor.org/ info/rfc6485>.
[RFC6485] Huston、G。、「Resource Public Key Infrastructure（RPKI）で使用するアルゴリズムとキーサイズのプロファイル」、RFC 6485、2012年2月、<http://www.rfc-editor.org/ info / rfc6485>。
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, February 2012, <http://www.rfc-editor.org/info/rfc6487>.
[RFC6487] Huston、G.、Michaelson、G。、およびR. Loomans、「X.509 PKIXリソース証明書のプロファイル」、RFC 6487、2012年2月、<http://www.rfc-editor.org/info / rfc6487>。
[FIPS] Federal Information Processing Standards Publication 140-3 (FIPS-140-3), "Security Requirements for Cryptographic Modules", Information Technology Laboratory, National Institute of Standards and Technology, Work in Progress.
[FIPS]連邦情報処理標準出版物140-3（FIPS-140-3）、「暗号化モジュールのセキュリティ要件」、国立標準技術研究所、IT研究所、作業中。
[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, <http://www.rfc-editor.org/info/rfc3647>.
[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、 <http://www.rfc-editor.org/info/rfc3647>。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012, <http://www.rfc-editor.org/info/rfc6480>.
[RFC6480] Lepinski、M。およびS. Kent、「An Internet to Support Secure Internet Routing」、RFC 6480、2012年2月、<http://www.rfc-editor.org/info/rfc6480>。
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, February 2012, <http://www.rfc-editor.org/info/rfc6481>.
[RFC6481] Huston、G.、Loomans、R。、およびG. Michaelson、「リソース証明書リポジトリ構造のプロファイル」、RFC 6481、2012年2月、<http://www.rfc-editor.org/info/rfc6481 >。
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012, <http://www.rfc-editor.org/info/rfc6482>.
[RFC6482] Lepinski、M.、Kent、S。、およびD. Kong、「A Route for Route Origin Authorizations（ROAs）」、RFC 6482、2012年2月、<http://www.rfc-editor.org/info / rfc6482>。
[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, February 2012, <http://www.rfc-editor.org/info/rfc6486>.
[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, February 2012, <http://www.rfc-editor.org/info/rfc6486>.
[RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)", BCP 174, RFC 6489, February 2012, <http://www.rfc-editor.org/info/rfc6489>.
[RFC6489] Huston、G.、Michaelson、G.、およびS. Kent、「Certification Authority（CA）Key Rollover in the Resource Public Key Infrastructure（RPKI）」、BCP 174、RFC 6489、2012年2月、<http：/ /www.rfc-editor.org/info/rfc6489>。
Acknowledgments
謝辞
The authors would like to thank Matt Lepinski for help with the formatting, Ron Watro for assistance with the editing, and other members of the SIDR working group for reviewing this document.
著者は、フォーマットの支援をしてくれたMatt Lepinski、編集の支援をしてくれたRon Watro、およびこのドキュメントをレビューしてくれたSIDRワーキンググループの他のメンバーに感謝します。
Authors' Addresses
著者のアドレス
Stephen Kent BBN Technologies 10 Moulton Street Cambridge, MA 02138 United States
Stephen Kent BBN Technologies 10 Moulton Street Cambridge、MA 02138 United States
Phone: +1 (617) 873-3988
EMail: skent@bbn.com
Derrick Kong BBN Technologies 10 Moulton Street Cambridge, MA 02138 United States
Derrick Kong BBN Technologies 10 Moulton Street Cambridge、MA 02138 United States
Phone: +1 (617) 873-1951
EMail: dkong@bbn.com
Karen Seo BBN Technologies 10 Moulton Street Cambridge, MA 02138 United States
Karen Seo BBN Technologies 10 Moulton Street Cambridge、MA 02138 United States
Phone: +1 (617) 873-3152
EMail: kseo@bbn.com