[要約] RFC 6481は、リソース証明書リポジトリの構造に関するプロファイルであり、リソース証明書の管理と配布を効率化することを目的としています。
Internet Engineering Task Force (IETF) G. Huston
Request for Comments: 6481 R. Loomans
Category: Standards Track G. Michaelson
ISSN: 2070-1721 APNIC
February 2012
A Profile for Resource Certificate Repository Structure
リソース証明書リポジトリ構造のプロファイル
Abstract
概要
This document defines a profile for the structure of the Resource Public Key Infrastructure (RPKI) distributed repository. Each individual repository publication point is a directory that contains files that correspond to X.509/PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile defines the object (file) naming scheme, the contents of repository publication points (directories), and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and to facilitate certification path construction.
このドキュメントは、リソース公開キーインフラストラクチャ（RPKI）分散リポジトリの構造のプロファイルを定義します。各リポジトリの公開ポイントは、X.509/PKIXリソース証明書、証明書の取り消しリスト、および署名されたオブジェクトに対応するファイルを含むディレクトリです。このプロファイルは、オブジェクト（ファイル）ネーミングスキーム、リポジトリの公開ポイント（ディレクトリ）の内容、およびリポジトリの出版ポイントの分散コレクション全体で同期を促進し、認証パスを促進することを目的としたローカルリポジトリキャッシュの推奨される内部構造を定義します。工事。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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 Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、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/rfc6481.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6481で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. RPKI Repository Publication Point Content and Structure .........4
2.1. Manifests ..................................................5
2.2. CA Repository Publication Points ...........................6
3. Resource Certificate Publication Repository Considerations ......8
4. Certificate Reissuance and Repositories ........................10
5. Synchronizing Repositories with a Local Cache ..................10
6. Security Considerations ........................................11
7. IANA Considerations ............................................12
7.1. Media Types ...............................................12
7.1.1. application/rpki-manifest ..........................12
7.1.2. application/rpki-roa ...............................13
7.2. RPKI Repository Name Scheme Registry ......................13
8. Acknowledgements ...............................................13
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................14
To validate attestations made in the context of the Resource Public Key Infrastructure (RPKI) [RFC6480], relying parties (RPs) need access to all the X.509/PKIX Resource Certificates, Certificate Revocation Lists (CRLs), and signed objects that collectively define the RPKI.
リソースの公開キーインフラストラクチャ（RPKI）[RFC6480]のコンテキストで行われた証明を検証するには、依存関係者（RPS）は、すべてのX.509/PKIXリソース証明書、証明書の取り消しリスト（CRL）、およびまとめて署名されたオブジェクトにアクセスする必要があります。RPKIを定義します。
Each issuer of a certificate, CRL, or a signed object makes it available for download to RPs through the publication of the object in an RPKI repository.
証明書、CRL、または署名されたオブジェクトの各発行者は、RPKIリポジトリにオブジェクトの公開を通じてRPSにダウンロードできるようにします。
The repository system is a collection of all signed objects that MUST be globally accessible to all RPs. When certificates, CRLs and signed objects are created, they are uploaded to a repository publication point, from whence they can be downloaded for use by RPs.
リポジトリシステムは、すべてのRPがグローバルにアクセスできる必要があるすべての署名されたオブジェクトのコレクションです。証明書、CRL、および署名されたオブジェクトが作成されると、RPSが使用するためにダウンロードできる場所からリポジトリの公開ポイントにアップロードされます。
This profile defines the recommended object (file) naming scheme, the recommended contents of repository publication points (directories), and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and facilitate certification path construction.
このプロファイルは、推奨されるオブジェクト（ファイル）ネーミングスキーム、リポジトリの公開ポイント（ディレクトリ）の推奨コンテンツ、およびリポジトリ出版ポイントの分散コレクション全体で同期を促進し、認証を促進することを目的としたローカルリポジトリキャッシュの推奨される内部構造を定義します。パス構造。
A resource certificate attests to a binding of an entity's public key to a set of IP address blocks and AS numbers. The subject of a resource certificate can demonstrate that it is the holder of the resources enumerated in the certificate by using its private key to generate a digital signature (that can be verified using the public key from the certificate).
リソース証明書は、IPアドレスブロックのセットと数字として、エンティティの公開鍵を拘束することを証明しています。リソース証明書の主題は、デジタルキーを使用してデジタル署名を生成することにより、証明書に列挙されているリソースの所有者であることを実証できます（証明書の公開キーを使用して確認できます）。
It is assumed that the reader is familiar with the terms and concepts described in "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC5280], and "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779].
読者は、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」[RFC5280]に記載されている用語と概念に精通していると想定されています。[RFC3779]。
In addition, the following terms are used in this document:
さらに、このドキュメントでは、次の用語が使用されています。
Repository Object (or Object): This refers to a terminal object in a repository publication point. A terminal object is conventionally implemented as a file in a publicly accessible directory, where the file is not a directory itself, although another form of object that has an analogous public appearance to a file is encompassed by this term.
リポジトリオブジェクト（またはオブジェクト）：これは、リポジトリの公開ポイントの端子オブジェクトを指します。端子オブジェクトは、ファイルがディレクトリ自体ではない公開ディレクトリ内のファイルとして従来に実装されていますが、ファイルに類似した公開外観を持つ別の形式のオブジェクトは、この用語で囲まれています。
Repository Publication Point: This refers to a collection of Repository Objects that are published at a common publication point. This is conventionally implemented as a directory in a publicly accessible filesystem that is identified by a URI [RFC3986], although another form of local storage that has an analogous public appearance to a simple directory of files is also encompassed by this term.
リポジトリの公開ポイント：これは、一般的な公開ポイントで公開されているリポジトリオブジェクトのコレクションを指します。これは、URI [RFC3986]によって識別される公開されたファイルシステムのディレクトリとして従来で実装されていますが、ファイルの単純なディレクトリに類似した公開外観を持つ別の形式のローカルストレージもこの用語に含まれています。
Repository Instance: This refers to a collection of one or more Repository Publication Points that share a common publication instance. This conventionally is implemented as a collection of filesystem directories that share a common URI prefix, where each directory is also identifiable by its own unique URI.
リポジトリインスタンス：これは、共通の公開インスタンスを共有する1つ以上のリポジトリ出版ポイントのコレクションを指します。これは、一般的なURIプレフィックスを共有するファイルシステムディレクトリのコレクションとして実装されています。各ディレクトリは、独自のURIによっても識別できます。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The RPKI does not require that a single repository instance contain all published RPKI objects. Instead, the RPKI repository system is comprised of multiple repository instances. Each individual repository instance is composed of one or more repository publication points. Each repository publication point is used by one or more entities referenced in RPKI certificates, as defined in the certificate's Subject Information Access (SIA) extension.
RPKIは、単一のリポジトリインスタンスに公開されているすべてのRPKIオブジェクトを含むことを必要としません。代わりに、RPKIリポジトリシステムは複数のリポジトリインスタンスで構成されています。各リポジトリインスタンスは、1つ以上のリポジトリの公開ポイントで構成されています。各リポジトリの公開ポイントは、証明書の主題情報アクセス（SIA）拡張で定義されているように、RPKI証明書で参照されている1つ以上のエンティティによって使用されます。
This section describes the collection of objects (RPKI certificates, CRLs, manifests, and signed objects) held in repository publication points.
このセクションでは、リポジトリの公開ポイントに保持されているオブジェクト（RPKI証明書、CRL、マニフェスト、および署名されたオブジェクト）のコレクションについて説明します。
For every Certification Authority (CA) certificate in the RPKI, there is a corresponding repository publication point that is the authoritative publication point for all current certificates and CRLs issued by this CA. The certificate's SIA extension contains a URI [RFC3986] that references this repository publication point and identifies the repository access mechanisms. Additionally, a certificate's Authority Information Access (AIA) extension contains a URI that references the authoritative location for the CA certificate under which the given certificate was issued.
RPKIのすべての認証機関（CA）証明書について、このCAによって発行されたすべての現在の証明書およびCRLの権威ある公開ポイントである対応するリポジトリの公開ポイントがあります。証明書のSIA拡張機能には、このリポジトリの公開ポイントを参照し、リポジトリアクセスメカニズムを識別するURI [RFC3986]が含まれています。さらに、証明書の権限情報アクセス（AIA）拡張には、指定された証明書が発行されたCA証明書の権威ある場所を参照するURIが含まれています。
For example, if the subject of certificate A has issued certificates B and C, then the AIA extensions of certificates B and C both point to the publication point for the certificate A object, and the SIA extension of certificate A points to a repository publication point (directory) containing certificates B and C (see Figure 1).
たとえば、証明書Aの主題が証明書BとCを発行した場合、証明書BとCのAIA拡張は証明書Aオブジェクトの公開ポイントをポイントし、証明書のSIA拡張はリポジトリ公開ポイントにポイントを指します（ディレクトリ）証明書bとcを含む（図1を参照）。
+--------+
+--------->| Cert A |<----+
| | AIA | |
| +--------- SIA | |
| | +--------+ |
| | |
| | +-------------------|------------------+
| | | | |
| +->| +--------+ | +--------+ |
| | | Cert B | | | Cert C | |
| | | CRLDP-------+ | | CRLDP-----+ |
+----------- AIA | | +----- AIA | | |
| | SIA------+ | | SIA------------+
| +--------+ | | +--------+ | | |
| | V V | |
| | +-----------------+ | |
| | | CRL issued by A | | |
| A's Repository| +-----------------+ | |
| Directory | | |
+---------------|----------------------+ |
| |
+----------------+ | +----------------+ |
| B's Repository |<-------+ | C's Repository |<--+
| Directory | | Directory |
+----------------+ +----------------+
Figure 1. Use of AIA and SIA Extensions in the RPKI
図1. RPKIでのAIAおよびSIA拡張機能の使用
In Figure 1, certificates B and C are issued by CA A. Therefore, the AIA extensions of certificates B and C point to (certificate) A, and the SIA extension of certificate A points to the repository publication point of CA A's subordinate products, which includes certificates B and C, as well as the CRL issued by A. The CRL Distribution Points (CRLDP) extension in certificates B and C both point to the CRL issued by A.
図1では、証明書BとCはCa Aによって発行されます。したがって、証明書BとCのAIA拡張は（証明書）Aを指し、証明書のSIA拡張は、Ca Aの従属製品のリポジトリ出版ポイントのポイントAポイントです。これには、証明書BとC、およびAによって発行されたCRLが含まれます。CRL分布ポイント（CRLDP）証明書BとCの拡張は両方ともAが発行したCRLをポイントします。
In this distributed repository structure, an instance of a CA's repository publication point contains all published certificates issued by that CA, and the CRL issued by that CA. This repository also contains all published digitally signed objects that are verified by an end-entity (EE) certificate issued by this CA.
この分散リポジトリ構造では、CAのリポジトリ公開ポイントのインスタンスには、そのCAが発行したすべての公開された証明書と、そのCAによって発行されたCRLが含まれています。このリポジトリには、このCAによって発行されたエンドエンティティ（EE）証明書によって検証された公開されたすべてのデジタル署名オブジェクトも含まれています。
Every repository publication point MUST contain a manifest [RFC6486]. The manifest contains a list of the names of all objects, as well as the hash value of each object's contents that are currently published by a CA or an EE.
すべてのリポジトリの公開ポイントには、マニフェスト[RFC6486]が含まれている必要があります。マニフェストには、すべてのオブジェクトの名前のリストと、現在CAまたはEEによって公開されている各オブジェクトのコンテンツのハッシュ値が含まれています。
An authority MAY perform a number of object operations on a publication repository within the scope of a repository change before issuing a single manifest that covers all the operations within the scope of this change. Repository operators SHOULD implement some form of directory management regime function on the repository to ensure that RPs who are performing retrieval operations on the repository are not exposed to intermediate states during changes to the repository and the associated manifest. (It is noted that if no such access regime is in place, then RPs MAY be exposed to intermediate repository states where the manifest and the repository contents may not be precisely aligned. Specific cases and actions in such a situation of misalignment of the manifest and the repository contents are considered in [RFC6486].)
当局は、この変更の範囲内ですべての操作をカバーする単一のマニフェストを発行する前に、リポジトリ変更の範囲内で公開リポジトリ上で多くのオブジェクト操作を実行する場合があります。リポジトリオペレーターは、リポジトリに何らかの形のディレクトリ管理体制機能を実装して、リポジトリで検索操作を実行しているRPがリポジトリと関連するマニフェストの変更中に中間状態にさらされないようにする必要があります。（そのようなアクセス制度が整っていない場合、RPSは、マニフェストとリポジトリの内容が正確に整列されていない中間リポジトリ状態にさらされる可能性があることに注意してください。リポジトリの内容は[RFC6486]で考慮されています。
A CA certificate has two accessMethod elements specified in its SIA field. The id-ad-caRepository accessMethod element has an associated accessLocation element that points to the repository publication point of the certificates issued by this CA, as specified in [RFC6487]. The id-ad-rpkiManifest accessMethod element has an associated accessLocation element that points to the manifest object, as an object URI (as distinct to a directory URI), that is associated with this CA.
CA証明書には、SIAフィールドで指定された2つのAccessMethod要素があります。ID-AD-CarePository AccessMethod要素には、[RFC6487]で指定されているように、このCAが発行した証明書のリポジトリ公開ポイントを指す関連するアクセスロケーション要素があります。ID-AD-RPKIMANIFEST AccessMethod要素には、このCAに関連付けられているオブジェクトURI（ディレクトリURIとは異なる）として、マニフェストオブジェクトを指す関連アクセスロケーション要素があります。
A CA's publication repository contains the current (non-expired and non-revoked) certificates issued by this CA, the most recent CRL issued by this CA, the current manifest, and all other current signed objects that can be verified using an EE certificate [RFC6487] issued by this CA.
CAの出版物リポジトリには、このCAが発行した現在の（既存および非採取されていない）証明書、このCAによって発行された最新のCRL、現在のマニフェスト、およびEE証明書を使用して検証できる他のすべての現在の署名されたオブジェクトが含まれています[このCAによって発行されたRFC6487]
The CA's manifest contains the names of this collection of objects, together with the hash value of each object's contents, with the single exception of the manifest itself.
CAのマニフェストには、このオブジェクトのコレクションの名前が、各オブジェクトのコンテンツのハッシュ値とともに、マニフェスト自体の単一の例外を含みます。
The RPKI design requires that a CA be uniquely associated with a single key pair. Thus, the administrative entity that is a CA performs key rollover by generating a new CA certificate with a new subject name, as well as a new key pair [RFC6489]. (The reason for the new subject name is that in the context of the RPKI, the subject names in all certificates issued by a CA are intended to be unique, and because the RPKI key rollover procedure creates a new instance of a CA with the new key, the name constraint implies the need for a new subject name for the CA with the new key.) In such cases, the entity SHOULD continue to use the same repository publication point for both CA instances during the key rollover, ensuring that the value of the AIA extension in indirect subordinate objects that refer to the certificates issued by this CA remain valid across the key rollover,
RPKI設計では、CAを単一のキーペアと一意に関連付ける必要があります。したがって、CAである管理エンティティは、新しい件名名を持つ新しいCA証明書と新しいキーペア[RFC6489]を生成することにより、キーロールオーバーを実行します。（新しい件名名の理由は、RPKIのコンテキストでは、CAによって発行されたすべての証明書の件名が一意であることを意図しているため、RPKIキーロールオーバー手順が新しいインスタンスを作成したために新しいインスタンスを作成するためです。キー、名前の制約は、新しいキーを使用してCAの新しいサブジェクト名の必要性を意味します。）そのような場合、エンティティはキーロールオーバー中に両方のCAインスタンスに同じリポジトリ公開ポイントを引き続き使用し、値が値を保証する必要があります。このCAによって発行された証明書を参照する間接的な下位オブジェクトのAIA拡張のうち、キーロールオーバー全体で有効なままです。
and that the reissuance of subordinate certificates in a key rollover is limited to the collection of immediate subordinate products of this CA [RFC6489]. In such cases, the repository publication point will contain the CRL, manifest and subordinate certificates of both CA instances. (It is feasible for the entity to use distinct repository publication points for the old and new CA keys, but, in such a case, very careful coordination would be required with subordinate CAs and EEs to ensure that the AIA pointers in the indirect subordinate levels of the RPKI hierarchy are correctly aligned to the subordinate products of the new CA.)
また、主要なロールオーバーでの下位証明書の再発行は、このCA [RFC6489]の即時の下位産物の収集に限定されていること。そのような場合、リポジトリの公開ポイントには、両方のCAインスタンスのCRL、マニフェスト、および従属証明書が含まれます。（エンティティが古いCAキーと新しいCAキーに異なるリポジトリの公開ポイントを使用することは可能ですが、そのような場合、間接的な下位レベルでのAIAポインターが確実に行うために、下位のCASおよびEEと非常に慎重な調整が必要になります。RPKIの階層は、新しいCAの下位製品に正しく整合しています。
The following paragraphs provide guidelines for naming objects in a CA's repository publication point:
次の段落では、CAのリポジトリ公開ポイントでオブジェクトを命名するためのガイドラインを提供します。
CRL: When a CA issues a new CRL, it replaces the previous CRL (issued under the same CA key pair) in the repository publication point. CAs MUST NOT continue to publish previous CRLs in the repository publication point. Thus, it MUST replace (overwrite) previous CRLs signed by the same CA (instance). A non-normative guideline for naming such objects is that the file name chosen for the CRL in the repository be a value derived from the public key of the CA. One such method of generating a CRL publication name is described in Section 2.1 of [RFC4387]; convert the 160-bit hash of a CA's public key value into a 27-character string using a modified form of Base64 encoding, with an additional modification as proposed in Section 5, table 2, of [RFC4648]. The filename extension of ".crl" MUST be used to denote the file as a CRL. Each ".crl" file contains exactly one CRL encoded in DER format.
CRL：CAが新しいCRLを発行すると、リポジトリの公開ポイントで以前のCRL（同じCAキーペアの下で発行）を置き換えます。CASは、以前のCRLをリポジトリの公開ポイントに公開し続けてはなりません。したがって、同じCA（インスタンス）で署名された以前のCRLを置き換える（上書き）する必要があります。そのようなオブジェクトを命名するための非規範的なガイドラインは、リポジトリ内のCRLに選択されたファイル名がCAの公開鍵から派生した値であるということです。CRLの公開名を生成するそのような方法の1つは、[RFC4387]のセクション2.1で説明されています。CAの公開キー値の160ビットハッシュを、[RFC4648]のセクション5、表2で提案されている追加の変更を加えて、Base64エンコーディングの変更された形式を使用して27文字の文字列に変換します。「.crl」のファイル名拡張機能を使用して、ファイルをCRLとして示す必要があります。各「.crl」ファイルには、der形式でエンコードされた1つのCRLが含まれています。
Manifest: When a new instance of a manifest is published, it MUST replace the previous manifest to avoid confusion. CAs MUST NOT continue to publish previous CA manifests in the repository publication point. A non-normative guideline for naming such objects is that the filename chosen for the manifest in the publication repository be a value derived from the public key part of the entity's key pair, using the algorithm described for CRLs above for generation of filenames. The filename extension of ".mft" MUST be used to denote the object as a manifest.
マニフェスト：マニフェストの新しいインスタンスが公開されている場合、混乱を避けるために以前のマニフェストを置き換える必要があります。CASは、リポジトリの公開ポイントで以前のCAマニフェストを引き続き公開してはなりません。そのようなオブジェクトを命名するための非規範的なガイドラインは、公開リポジトリのマニフェストに選択されたファイル名は、ファイルの生成について上記のCRLについて説明したアルゴリズムを使用して、エンティティのキーペアの公開キー部分から派生した値であることです。「.mft」のファイル名拡張は、オブジェクトをマニフェストとして示すために使用する必要があります。
Certificates: Within the RPKI framework, it is possible that a CA MAY issue a series of certificates to the same subject name, the same subject public key, and the same resource collection. However, a relying party requires access only to the most recently published certificate in such a series. Thus, such a series of certificates SHOULD share the same filename. This ensures that each successive
証明書：RPKIフレームワーク内で、CAは、同じ件名名、同じ主題公開キー、および同じリソースコレクションに一連の証明書を発行する可能性があります。ただし、依存している当事者は、このようなシリーズで最近公開された証明書にのみアクセスする必要があります。したがって、そのような一連の証明書は同じファイル名を共有する必要があります。これにより、それぞれが連続することが保証されます
issued certificate in such a series effectively overwrites the previous instance of the certificate. It is feasible to use different filenames, but this imposes a burden on the validating user. A non-normative guideline for naming such objects is for the CA to adopt a (local) policy requiring a subject to use a unique key pair for each unique instance of a certificate series issued to the same subject, thereby allowing the CA to use a file name generation scheme based on the subject's public key, e.g., using the algorithm described above for CRLs above. Published certificates MUST use a filename extension of ".cer" to denote the object as a certificate. Each ".cer" file contains exactly one certificate encoded in DER format.
このようなシリーズで発行された証明書は、証明書の前のインスタンスを効果的に上書きします。異なるファイル名を使用することは可能ですが、これは検証型ユーザーに負担を課します。そのようなオブジェクトを命名するための非規範的なガイドラインは、CAが同じ主題に発行された証明書シリーズの一意のインスタンスに一意のキーペアを使用する必要がある（ローカル）ポリシーを採用することです。上記のCRLについて上記のアルゴリズムを使用して、被験者の公開鍵に基づくファイル名生成スキーム。公開された証明書は、「.cer」のファイル名拡張機能を使用して、オブジェクトを証明書として示す必要があります。各「.cer」ファイルには、der形式でエンコードされた正確な1つの証明書が含まれています。
Signed Objects: RPKI signed objects [RFC6488] are published in the repository publication point referenced by the SIA of the CA certificate that issued the EE certificate used to validate the digital signature of the signed object (and are directly referenced by the SIA of that EE certificate). A general non-normative guideline for naming such RPKI signed objects is for the filename of such objects to be derived from the associated EE certificate's public key, applying the algorithm described above. Published RPKI signed objects MUST NOT use the filename extensions ".crl", ".mft", or ".cer".
署名されたオブジェクト：RPKI署名されたオブジェクト[RFC6488]は、署名されたオブジェクトのデジタル署名を検証するために使用されるEE証明書を発行したCA証明書のSIAが参照されるリポジトリ公開ポイントに公開されています（およびそのEEのSIAによって直接参照されます証明書）。このようなRPKI署名されたオブジェクトを命名するための一般的な非規範的ガイドラインは、そのようなオブジェクトのファイル名が、上記のアルゴリズムを適用して、関連するEE証明書の公開キーから導き出されることです。公開されたRPKI署名されたオブジェクトは、ファイル名拡張機能 ".crl"、 ".mft"、または「.cer "を使用してはなりません。
One form of signed object defined at the time of publication of this document is a Route Origination Authorization (ROA) [RFC6482]. Published ROAs MUST use a filename extension of ".roa" to denote the object as a ROA.
このドキュメントの公開時に定義された署名されたオブジェクトの1つの形式は、ルートオリジネーション認証（ROA）[RFC6482]です。公開されたROASは、「.roa」のファイル名拡張機能を使用して、オブジェクトをROAとして示す必要があります。
Each issuer MAY publish its issued certificates and CRL in any repository. However, there are a number of considerations that guide the choice of a suitable repository publication structure:
各発行者は、発行された証明書とCRLを任意のリポジトリに公開できます。ただし、適切なリポジトリの公開構造の選択を導く多くの考慮事項があります。
* The publication repository SHOULD be hosted on a highly available service and high-capacity publication platform.
* 出版物リポジトリは、非常に利用可能なサービスと大容量の出版プラットフォームでホストする必要があります。
* The publication repository MUST be available using rsync [RFC5781] [RSYNC]. Support of additional retrieval mechanisms is the choice of the repository operator. The supported retrieval mechanisms MUST be consistent with the accessMethod element value(s) specified in the SIA of the associated CA or EE certificate.
* 出版物リポジトリは、RSYNC [RFC5781] [RSYNC]を使用して利用できる必要があります。追加の検索メカニズムのサポートは、リポジトリオペレーターの選択です。サポートされている検索メカニズムは、関連するCAまたはEE証明書のSIAで指定されたAccessMethod要素値と一致する必要があります。
* Each CA repository publication point SHOULD contain the products of this CA, including those objects that can be verified by EE certificates that have been issued by this CA. The signed products of related CA's that are operated by the same entity MAY share this CA repository publication point. Aside from subdirectories, any other objects SHOULD NOT be placed in a repository publication point.
* 各CAリポジトリの公開ポイントには、このCAによって発行されたEE証明書によって検証できるオブジェクトを含む、このCAの製品を含める必要があります。同じエンティティによって運用される関連CAの署名済み製品は、このCAリポジトリの公開ポイントを共有する場合があります。サブディレクトリは別として、他のオブジェクトはリポジトリの公開ポイントに配置しないでください。
Any such subdirectory SHOULD be the repository publication point of a CA or EE certificate that is contained in the CA directory. These considerations also apply recursively to subdirectories of these directories. Detection of content that is not a CA product has the potential to cause confusion to RPs, and in such a case RPs should exercise caution not to invalidate the valid CA products found at the CA's repository publication point.
このようなサブディレクトリは、CAディレクトリに含まれるCAまたはEE証明書のリポジトリ公開ポイントである必要があります。これらの考慮事項は、これらのディレクトリのサブディレクトリにも再帰的に適用されます。CA製品ではないコンテンツの検出は、RPSに混乱を引き起こす可能性があり、そのような場合、RPSはCAのリポジトリ公開ポイントで見つかった有効なCA製品を無効にしないように注意する必要があります。
* Signed objects are published in the location indicated by the SIA field of the EE certificate used to verify the signature of each object. Signed objects are published in the repository publication point of the CA certificate that issued the EE certificate. The SIA extension of the EE certificate references this object rather than the repository publication directory [RFC6487].
* 署名されたオブジェクトは、各オブジェクトの署名を確認するために使用されるEE証明書のSIAフィールドで示される場所に公開されています。署名されたオブジェクトは、EE証明書を発行したCA証明書のリポジトリ公開ポイントに公開されています。EE証明書のSIA拡張は、リポジトリの出版ディレクトリ[RFC6487]ではなく、このオブジェクトを参照しています。
* Section 2.1 states that repository operators SHOULD implement some form of directory management regime function on the repository to ensure that RPs who are performing retrieval operations on the repository are not exposed to intermediate states during changes to the repository and the associated manifest. Notwithstanding the following commentary, RPs SHOULD NOT assume that a consistent repository and manifest state are assured, and they SHOULD organize their retrieval operations accordingly (see Section 5).
* セクション2.1は、リポジトリオペレーターがリポジトリに何らかの形のディレクトリ管理体制機能を実装して、リポジトリで検索操作を実行しているRPがリポジトリおよび関連するマニフェストの変更中に中間状態にさらされないようにする必要があることを述べています。次の解説にもかかわらず、RPSは一貫したリポジトリとマニフェスト状態が保証されていると仮定すべきではなく、それに応じて検索操作を整理する必要があります（セクション5を参照）。
The manner in which a repository operator can implement a directory update regime that mitigates the risk of the manifest and directory contents being inconsistent, to some extent, is dependent on the operational characteristics of the filesystem that hosts the repository, so the following comments are non-normative in terms of any implicit guidelines for repository operators.
リポジトリオペレーターが、マニフェストとディレクトリのコンテンツが一貫性のないリスクを軽減するディレクトリ更新制度をある程度緩和する方法は、ある程度、リポジトリをホストするファイルシステムの運用特性に依存するため、次のコメントは非存在です。 - リポジトリオペレーターの暗黙的なガイドラインの観点から規範的。
A commonly used technique to avoid exposure to inconsistent retrieval states during updates to a large directory is to batch a set of changes to be made, create a working copy of the directory's contents, and then perform the batch of changes to the local copy of the directory. On completion, rename the
大規模なディレクトリの更新中に一貫性のない検索状態への露出を回避するための一般的に使用される手法は、行われる一連の変更をバッチし、ディレクトリのコンテンツの作業コピーを作成し、次に変更のバッチを実行することです。ディレクトリ。完了時に、変更を変更します
filesystem symbolic link of the repository directory name to point to this working copy of the directory. The old repository directory contents can be purged at a slightly later time. However, it is noted that the outcomes of this technique in terms of ensuring the integrity of client synchronization functions performed over the directory depend on the interaction between the supported access mechanisms and the local filesystem behavior. It is probable that this technique will not remove all possibilities for RPs to see inconsistent states between the manifest and the repository. Because a repository has the potential to be in an partially updated state, it cannot be guaranteed to be internally self consistent all the time.
Files -Systemリポジトリディレクトリ名のシンボリックリンクは、ディレクトリのこの作業コピーを指します。古いリポジトリディレクトリのコンテンツは、わずかに後にパージできます。ただし、ディレクトリを介して実行されるクライアント同期関数の整合性を確保するという点で、この手法の結果は、サポートされているアクセスメカニズムとローカルファイルシステムの動作との間の相互作用に依存することに注意してください。この手法では、RPSがマニフェストとリポジトリの間に一貫性のない状態を見ることができるすべての可能性を削除しない可能性があります。リポジトリには部分的に更新された状態になる可能性があるため、常に内部的に自己一貫性があることを保証することはできません。
If a CA certificate is reissued, e.g., due to changes in the set of resources contained in the number resource extensions, it should not be necessary to reissue all certificates issued under it. Because these certificates contain AIA extensions that point to the publication point for the CA certificate, a CA SHOULD use a name for its repository publication point that persists across certificate reissuance events. That is, reissued CA certificates SHOULD use the same repository publication point as previously issued CA certificates having the same subject and subject public key, such that certificate reissuance SHOULD intentionally overwrite the previously issued certificate within the repository publication point.
CA証明書が再発行された場合、たとえば、番号リソース拡張機能に含まれるリソースのセットの変更により、その下で発行されたすべての証明書を再発行する必要はありません。これらの証明書には、CA証明書の公開ポイントを指すAIA拡張機能が含まれているため、CAは、証明書の再発行イベント全体で持続するリポジトリの公開ポイントの名前を使用する必要があります。つまり、再発行されたCA証明書は、以前に発行されたCA証明書と同じ主題と主題の公開鍵と同じリポジトリ公開ポイントを使用する必要があります。そのため、証明書の再発行は、リポジトリの公開ポイント内で以前に発行された証明書を意図的に上書きする必要があります。
It is noted in Section 2.2 that when a CA performs a key rollover, the entity SHOULD use a name for its repository publication point that persists across key rollover. In such cases, the repository publication point will contain the CRLs and manifests of both CA instances as a transient state in the key rollover procedure. The RPKI key rollover procedure [RFC6489] requires that the subordinate products of the old CA be overwritten in the common repository publication point by subordinate products issued by the new CA.
セクション2.2では、CAがキーロールオーバーを実行する場合、エンティティはキーロールオーバー全体で持続するリポジトリの公開ポイントの名前を使用する必要があることに注意してください。そのような場合、リポジトリの公開ポイントには、主要なロールオーバー手順の一時的な状態として、両方のCAインスタンスのCRLとマニフェストが含まれます。RPKIキーロールオーバー手順[RFC6489]では、古いCAの下位製品を、新しいCAによって発行された下位製品によって一般的なリポジトリの公開ポイントに上書きされることを要求しています。
It is possible to perform the validation-related task of certificate path construction using the retrieval of individual certificates, and certificate revocation lists using online retrieval of individual certificates, sets of candidate certificates and certificate revocation lists based on the AIA, SIA, and CRLDP certificate fields. This is NOT recommended in circumstances where speed and efficiency are relevant considerations.
個々の証明書の取得を使用して、証明書パス構築の検証関連タスク、および個々の証明書のオンライン検索、候補証明書のセット、およびAIA、SIA、およびCRLDP証明書に基づく証明書取消リストを使用して、証明書の取り消しリストを実行することが可能です。田畑。これは、速度と効率が関連する考慮事項である状況では推奨されません。
To enable efficient validation of RPKI certificates, CRLs, and signed objects, it is recommended that each relying party maintain a local repository containing a synchronized copy of all valid certificates, current certificate revocation lists, and all related signed objects.
RPKI証明書、CRL、および署名されたオブジェクトの効率的な検証を有効にするには、すべての有効な証明書、現在の証明書の取り消しリスト、および関連するすべての署名されたオブジェクトの同期コピーを含むローカルリポジトリを維持することをお勧めします。
The general approach to repository synchronization is one of a "top-down" walk of the distributed repository structure. This commences with the collection of locally selected trust anchor material corresponding to the local choice of Trust Anchors, which can be used to load the initial set of self-signed resource certificate(s) that form the "seed" of this process [RFC6490]. The process then populates the local repository cache with all valid certificates that have been issued by these issuers. This procedure can be recursively applied to each of these subordinate certificates. Such a repository traversal process SHOULD support a locally configured maximal chain length from the initial trust anchors. If this is not done, then there might be a SIA pointer loop, or other degenerate forms of the logical RPKI hierarchy, that would cause an RP to malfunction when performing a repository synchronization operation with the RP's local RPKI cache.
リポジトリの同期への一般的なアプローチは、分散リポジトリ構造の「トップダウン」ウォークの1つです。これは、このプロセスの「シード」を形成する自己署名リソース証明書の初期セットをロードするために使用できる、ローカルに選択された信頼のアンカー資料のコレクションから始まります。。このプロセスは、これらの発行者によって発行されたすべての有効な証明書をローカルリポジトリキャッシュに入力します。この手順は、これらの従属証明書のそれぞれに再帰的に適用できます。このようなリポジトリトラバーサルプロセスは、初期トラストアンカーからローカルに構成された最大チェーン長をサポートする必要があります。これが行われない場合、RPのローカルRPKIキャッシュでリポジトリ同期操作を実行するときにRPが誤動作を起こすため、SIAポインターループまたはその他の論理RPKI階層が存在する可能性があります。
RPs SHOULD ensure that this local synchronization uses the retrieved manifests [RFC6486] to ensure that they are synchronizing against a current, consistent state of each repository publication point. It is noted in Section 3 that when the repository publication point contents are updated, a repository operator cannot assure RPs that the manifest contents and the repository contents will be precisely aligned at all times. RPs SHOULD use a retrieval algorithm that takes this potential for transient inconsistency into account. For the RP to mitigate this situation, possible algorithms include performing the synchronization across the repository twice in succession, or performing a manifest retrieval both before and after the synchronization of the directory contents, and repeating the synchronization function if the second copy of the manifest differs from the first.
RPSは、このローカル同期が検索されたマニフェスト[RFC6486]を使用して、各リポジトリの公開ポイントの現在の一貫した状態と同期していることを確認する必要があります。セクション3では、リポジトリの公開ポイントコンテンツが更新されると、リポジトリオペレーターがマニフェストコンテンツとリポジトリの内容が常に正確に整列されることをRPSに保証できないことに注意してください。RPSは、一時的な矛盾のこの可能性を考慮した検索アルゴリズムを使用する必要があります。RPがこの状況を緩和するために、可能なアルゴリズムには、リポジトリ全体で2回連続して同期を実行するか、ディレクトリコンテンツの同期の前後にマニフェスト検索を実行すること、およびマニフェストの2番目のコピーが異なる場合の同期関数を繰り返すことが含まれます。最初から。
Repositories are not assumed to be integrity-protected databases, and repository retrieval operations might be vulnerable to various forms of "man-in-the-middle" attacks. Corruption of retrieved objects is detectable by a relying party through the validation of the signature associated with each retrieved object. Replacement of newer instances of an object with an older instance of the same object is detectable through the use of manifests. Insertion of revoked, deleted certificates is detected through the retrieval and processing
リポジトリは整合性保護されたデータベースであるとは想定されておらず、リポジトリの検索操作は、さまざまな形式の「中間者」攻撃に対して脆弱である可能性があります。検索されたオブジェクトの破損は、各検索されたオブジェクトに関連付けられた署名の検証を通じて、頼る当事者によって検出可能です。オブジェクトの新しいインスタンスを同じオブジェクトの古いインスタンスに置き換えると、マニフェストを使用することで検出できます。取り消された削除された証明書の挿入は、取得と処理によって検出されます
of CRLs at scheduled intervals. However, even the use of manifests and CRLs will not allow a relying party to detect all forms of substitution attacks based on older (but not expired) valid objects.
スケジュールされた間隔でのCRLの。ただし、マニフェストとCRLの使用でさえ、頼る当事者が古い（しかし期限切れではない）有効なオブジェクトに基づいてあらゆる形態の置換攻撃を検出することを許可しません。
Confidentiality is not provided by the repository or by the signed objects published in the repository. Data that is subject to controlled access should not be included in signed objects in the repository unless there is some specified mechanism used to ensure the confidentiality of the data contained in the signed object.
機密性は、リポジトリまたはリポジトリで公開されている署名されたオブジェクトによって提供されません。制御されたアクセスの対象となるデータは、署名されたオブジェクトに含まれるデータの機密性を確保するために使用されるいくつかの指定されたメカニズムがない限り、リポジトリ内の署名されたオブジェクトに含めるべきではありません。
IANA has registered the following two media types:
IANAは、次の2つのメディアタイプを登録しました。
application/rpki-manifest application/rpki-roa
アプリケーション/RPKI-MANIFESTアプリケーション/RPKI-ROA
This document also uses the .cer and .crl file extensions from the application/pkix-cert and application/pkix-crl media registries defined in [RFC2585].
このドキュメントでは、[RFC2585]で定義されているアプリケーション/PKIX-CERTおよびApplication/PKIX-CRLメディアレジストリからの.cerおよび.crlファイル拡張機能も使用します。
MIME media type name: application
MIME subtype name: rpki-manifest
Required parameters: None
Optional parameters: None
Encoding considerations: binary
Security considerations: Carries an RPKI Manifest [RFC6486]
Interoperability considerations: None
Published specification: This document
Applications that use this media type: Any MIME-complaint transport
Additional information:
Magic number(s): None
File extension(s): .mft
Macintosh File Type Code(s):
Person & email address to contact for further information:
Geoff Huston <gih@apnic.net>
Intended usage: COMMON
Author/Change controller: Geoff Huston <gih@apnic.net>
MIME media type name: application
MIME subtype name: rpki-roa
Required parameters: None
Optional parameters: None
Encoding considerations: binary
Security considerations: Carries an RPKI ROA [RFC6482]
Interoperability considerations: None
Published specification: This document
Applications that use this media type: Any MIME-complaint transport
Additional information:
Magic number(s): None
File extension(s): .roa
Macintosh File Type Code(s):
Person & email address to contact for further information:
Geoff Huston <gih@apnic.net>
Intended usage: COMMON
Author/Change controller: Geoff Huston <gih@apnic.net>
IANA has created the "RPKI Repository Name Scheme" registry. The registry contains three-letter filename extensions for RPKI repository objects. The registry's contents are managed by IETF Review [RFC5226]. The initial contents of this registry are the following:
IANAは「RPKIリポジトリ名スキーム」レジストリを作成しました。レジストリには、RPKIリポジトリオブジェクトの3文字のファイル名拡張機能が含まれています。レジストリの内容は、IETFレビュー[RFC5226]によって管理されます。このレジストリの最初の内容は次のとおりです。
Filename extension RPKI Object Reference
.cer Certificate [RFC6481]
.crl Certificate Revocation List [RFC6481]
.mft Manifest [RFC6481]
.roa Route Origination Authorization [RFC6481]
This document has benefitted from helpful review comments and input from Stephen Kent, Matt Lepenski, Michael Elkins, Russ Housley, and Sean Turner.
この文書は、Stephen Kent、Matt Lepenski、Michael Elkins、Russ Housley、Sean Turnerからの有益なレビューのコメントと入力の恩恵を受けています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012.
[RFC6482] Lepinski、M.、Kent、S。、およびD. Kong、「Route Origin Authorizations（ROAS）のプロファイル」、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.、Huston、G.、Kent、S。、およびM. Lepinski、「リソース公開キーインフラストラクチャ（RPKI）のマニフェスト」、RFC 6486、2012年2月。
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, February 2012.
[RFC6487] Huston、G.、Michaelson、G。、およびR. Loomans、「X.509 PKIXリソース証明書のプロファイル」、RFC 6487、2012年2月。
[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, February 2012.
[RFC6488] Lepinski、M.、Chi、A。、およびS. Kent、「リソース公開キーインフラストラクチャ（RPKI）の署名されたオブジェクトテンプレート」、RFC 6488、2012年2月。
[RSYNC] rsync web pages, <http://rsync.samba.org/>.
[rsync] rsync webページ、<http://rsync.samba.org/>。
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May 1999.
[RFC2585] Housley、R。およびP. Hoffman、「インターネットX.509公開キーインフラストラクチャ運用プロトコル：FTPおよびHTTP」、RFC 2585、1999年5月。
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC3779] Lynn、C.、Kent、S。、およびK. Seo、「IPアドレスおよび識別子としてのX.509拡張」、RFC 3779、2004年6月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。
[RFC4387] Gutmann, P., Ed., "Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP", RFC 4387, February 2006.
[RFC4387] Gutmann、P.、ed。、「Internet X.509公開キーインフラストラクチャ運用プロトコル：HTTP経由の証明書ストアアクセス」、RFC 4387、2006年2月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648] Josefsson、S。、「Base16、Base32、およびBase64データエンコーディング」、RFC 4648、2006年10月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、RFC 5280、2008年5月。
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI Scheme", RFC 5781, February 2010.
[RFC5781] Weiler、S.、Ward、D。、およびR. Housley、「Rsync URIスキーム」、RFC 5781、2010年2月。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
[RFC6480] Lepinski、M。およびS. Kent、「安全なインターネットルーティングをサポートするインフラストラクチャ」、RFC 6480、2012年2月。
[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.
[RFC6489] Huston、G.、Michaelson、G.、およびS. Kent、「認定局（CA）リソース公開キーインフラストラクチャ（RPKI）のキーロールオーバー」、BCP 174、RFC 6489、2012年2月。
[RFC6490] Huston, G., Weiler, S., Michaelson, G., and S. Kent, "Resource Public Key Infrastructure (RPKI) Trust Anchor Locator", RFC 6490, February 2012.
[RFC6490] Huston、G.、Weiler、S.、Michaelson、G。、およびS. Kent、「リソース公開キーインフラストラクチャ（RPKI）Trust Anchor Locator」、RFC 6490、2012年2月。
Authors' Addresses
著者のアドレス
Geoff Huston APNIC
Geoff Huston Apnic
EMail: gih@apnic.net
URI: http://www.apnic.net
Robert Loomans APNIC
ロバートルーマンズアペニック
EMail: robertl@apnic.net
URI: http://www.apnic.net
George Michaelson APNIC
ジョージ・マイケルソン・アペニック
EMail: ggm@apnic.net
URI: http://www.apnic.net